Linux-Advocacy Digest #915, Volume #27 Mon, 24 Jul 00 16:13:06 EDT
Contents:
Re: Would a M$ Voluntary Split Save It? (Mark Kelley)
Re: Would a M$ Voluntary Split Save It? (Arthur Frain)
Re: Linsux as a desktop platform ("John W. Stevens")
Re: Would a M$ Voluntary Split Save It? (Chris Wenham)
Re: Linsux as a desktop platform ("John W. Stevens")
Re: Linux = Yet Another Unix ("Nate Slater")
Re: Linsux as a desktop platform ("John W. Stevens")
----------------------------------------------------------------------------
From: Mark Kelley <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 24 Jul 2000 14:00:34 -0500
I think he must have meant Article 1, Section 8, Clause 8, which reads:
"To promote the Progress of Science and useful Arts, by securing for limited Times to
Authors and Inventors the exclusive Right to their respective Writings and
Discoveries;"
"Paul E. Larson" wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> >On Sun, 23 Jul 2000 21:49:28 GMT, Daniel Johnson
> > <[EMAIL PROTECTED]> wrote:
> >>"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
> >>news:[EMAIL PROTECTED]...
> >>> Said JS/PL in comp.os.linux.advocacy;
> >>[snip]
> >>> >Yes- they are free to tie whatever they want with their software
> >>(*including
> >>> >a ham sandwich), and it is their right to have their product distributed
> >>in
> >>> >a un altered state.
> >>>
> >>> They are free to have that right if there motivation is benefit to the
> >>> consumer, not if there motivation is to limit competition.
> >>
> >>I am pretty sure that copyright law doesn't say anything about their
> >>*motivation*; And anyway, if being *greedy* were grounds for a
> >
> > Actually, the copyright clause of the US Consitution quite
> > plainly justifies intellectual property entirely in terms
> > of public good.
> >
>
> You want to show us the clause you say is the copyright clause -
> http://tn.areaguide.com/constitu.htm
>
> Paul
>
> --
>
> "Mr. Rusk you not wearing your tie." -- Frenzy 1972
--
Mark Kelley
Agriculture Information Systems
Purdue University
------------------------------
From: Arthur Frain <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 24 Jul 2000 11:33:20 -0700
Chris Wenham wrote:
> Anal English Major
No offense intended, but is "Anal English" the
same as "talking out of your ass"? If so, you
could find a lot to study on Usenet.
Arthur
------------------------------
From: "John W. Stevens" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Mon, 24 Jul 2000 13:12:00 -0600
"T. Max Devlin" wrote:
>
> Said John W. Stevens in comp.os.linux.advocacy;
> >"T. Max Devlin" wrote:
> >>
> >> You are missing my point.
> >
> >Max, consider the possibility that your point was badly stated.
>
> Quite possible. If you have any suggestions, I'd be happy to hear them.
Learn correct terminology. Read the basic, simplified material
suggested to you, in order to avoid wasting your own, and others time.
Express yourself simply and concisely, with concrete examples.
These are all basic guidelines for any teacher.
Your response re: text books was incorrect and misguided. The total
number of paragraphs that you would have to read to understand basic PMT
theory is less than 30 . . . an hours worth of reading, at most.
> I think it may be so contrary to your experience
What, my experience as a teacher, my experience as an engineer, or my
experience as an expert in systems?
> that you might consider
> any statement of it to be difficult to understand.
I doubt that. In my experience, your communication patterns are
indicative of a deep and abiding confusion, most likely caused by a lack
of knowledge about the basic patterns underlying the subject you are
attempting to dicuss.
> >This assumes that running a game of solitaire is more efficient than
> >rendering your 3D image . . . the task you get paid for, while playing
> >solitaire is *NOT* something you get paid for.
>
> No, it assumes that rendering the 3D image would be so greatly optimized
> that you wouldn't have time to play solitaire while you wait. ;-)
Which response simply illustrates your lack of basic knowledge. No OS
is going to magically make the hardware cabable of performing tens of
billions of operations in less than a tenth of a second.
> >The blind assumption that the interactive task should be the highest
> >priority task at all times is just plain wrong.
>
> Again, I think this resolves on a preconception of a singular task,
You are wrong. This is not based on a "preconception of a singular
task".
> which I didn't take for granted. I would suggest that it could be
> reasonable to call any system which this statement applies to a
> "workstation".
You'd be wrong. Is a Mac automatically and always a desktop?
> On a desktop,
Again, you are trying to create dichotomies that are unneccessary, and
that mostly do not exist.
> not only is the interactive task the most
> important,
Your reasoning is flawed by placing far to much importance on
"interaction". The most productive computer user is the one who gets
their work done at zero cost in interaction (human time being the most
expensive).
The speed differential between a human being and a computer, in fact,
dictates a very simple rule: interactive work should receive the lowest
priority, while still providing a reasonable response time to human
input.
With modern, high speed processors on optimized user interfaces (NOT
GUI's!), the total CPU overhead is less than 2 percent.
> it is often the only end-user task to speak of.
Indicating a dire need for training on the part of the user. Computers
are not glorified sheets of paper. To use them properly, old habits
must be discarded, and new ones learned.
As an over all, abstract guideline: don't *DO* the work, specify how the
work is to be done and let the computer do it.
> >The highest priority task should always be that task that maximizes the
> >value of your CPU cycle investment.
>
> The priority of tasks is entirely independent, and certainly not
> determined, by CPU cycles.
This was a straw man response, or a misuse of the term: priority.
In fact, due to the lack of correctness in your use of the terminology,
plus your ambigous usage, your statment does not make sense. Please
restate.
> Tasks have priority for reasons end-users
> (and their bosses, often) determine, not CPUs and engineering
> efficiencies.
Once again, you create an "either-or" situtation that simply does not
exist. Efficieny is engineered into a system precisely *because* of the
needs of a user, not in spite of them.
You simply do not understand what I wrote, Max.
> >Stop. Before throwing such words around, you need to be very sure you
> >understand what they mean. What, in your mind, do the words "task" and
> >"process" mean? For a computer scientist, a process and a task are
> >differentiated primarily by which can contain the other.
>
> By process, I refer to the same concept, I believe, as the CS field. I
> didn't think that 'task' actually has a rigorous definition, even in CS.
In general, the term 'task' refers to an independently executing entity,
one that *may* contain only part of the processing neccessary to fulfill
the design responsibilities of an 'application'. Tasks are contained
within processes, but processes are never contained within tasks.
Also, all tasks contained within a single process run in the same
environment, while processes *define* an environment. Modern OS'es
define every process as containing at least one task.
> The 'task' is the higher order abstraction of 'why you're running the
> process'.
Nope. A 'task', in software engineering parlance, describes an
independently executing entity, one whose purpose is to perform *part*
of the processing requirements for an 'application'. Tasks exist within
a process as a method for prioritizing some kinds of information
processing over other kinds of information processing, and to make best
use of existing machine resources (such as multiple processors).
> While CS may recognize that a task can "contain" a process,
It does not.
> I
> believe that is simply a single order abstraction because that is all
> that the engineering disciplines are concerned with.
Wrong twice, in a single sentence. Once about the "single order
abstraction", and the second time about what "engineering disciplines"
are concerned with.
> What I am thinking
> of as a task is more of a "gestalt" of the ultimate purpose for using
> the computer, not a single step in a work procedure. I'm not sure what
> alternatives might be more appropriate, if there is a specific conflict.
What reasoning can you advance to even suggest that there is a conflict?
> >No, it's not. Here is where your understanding of PMT fails. PMT
> >increases the value of your CPU cycle investment.
>
> I can't help but think that you are starting with an assumption that I
> must be wrong,
Nope. I started with the assumption that you had a valid point, but
that you lacked the neccesary terminology and basic understanding of
"state of the art" to be able to express it.
> and further assuming that all those things I say which
> you didn't understand simply don't make sense to begin with.
Nope. I assume that the things you say that I don't understand are
simply poorly communicated, though I admit to some surprise at this, as
your signature suggests that you are a teacher.
> These are
> not necessarily incorrect assumptions, apart from the fact that all
> assumptions are by nature incorrect.
They are not neccesarily correct, either. In an engineering discussion,
you must be willing to engage in a rigourous test of your proposals.
> I was provided in no uncertain terms with an explanation of PMT which
> was almost literally "a matter of balancing load with responsiveness",
> which is to say "how to keep the system responsive under load". If you
> want to re-phrase it, feel free. But give me a reason for that beyond
> your intent to show I don't "understand" something.
Have you read my simplified description of how PMT works, yet?
I have no interest in, nor intent to, "show [you] don't "understand"
something". The exact opposite, in fact. I've made every effort to
help you understand.
Have you read my simplified description of how PMT works, yet?
> I think you have the wrong image of what I'm describing.
Probably. If you are criticizing existing design patterns, then the
assumption is that you understand these existing design patterns. If
this is not the case, say so.
> When
> considering "average versus peak", I'm talking an instantaneous set of
> tasks' and processes' requirements, not all possible processes and
> tasks.
PMT is not concerned with "all possible processes and tasks".
Therefore, your reasoning is not valid. Try again.
> A PMT system attempts to provide a level of service, if you will,
No. PMT systems attempt to maximize the return you get from your CPU
cycle. Please understand this basic concept before continuing.
> But other than kernel/user and CPU-I/O bound, it hasn't any
> more awareness of the actual characteristics or purposes or
> implementations of the tasks, the applications, the programs, or the
> processes.
This is incorrect. The OS knows the priorities assigned to a process
and task.
> My idea was one where the system can "know" whether to
> starve the renderer or not, because sometimes that makes the system more
> efficient at something of a higher "real" priority for the end user.
The system *CAN* and *DOES* know . . . through the priorities attached
to the process.
There *IS* *NO* *CONFLICT* between the priority of a process, and the
priority the user places on the process, because they are *IDENTICAL*.
The concept that a process has an "engineering" priority, which is
somehow different from the "user" priority, is simply wrong.
> I am speaking entirely of general
> purpose computing, and the fact that the same scheduling method is
> considered optimum at all points in time and for all sets of processes
> and tasks.
The same scheduling method?!
Nope. Modern day PMT implementations are not a "single scheduling
method". Also, modern PMT implementations are highly dynamic.
> >What is silly, is to believe that these factors are not even
> >considered. OF COURSE they are considered! But when you build a system
> >whose design purpose is to provide a generic, somewhat abstract service,
> >you cannot focus on the needs of a single user. You can build the
> >system to be flexible and configurable enough that the individual can
> >tune the system somewhat, but to build an entire system just for Max, is
> >a very, very expensive proposition. I estimate that a fully optimized
> >system for you alone would cost from between 1.5 and 3 billion dollars.
> >
> >Write me a check, and I'll be happy to start the process. . .
>
> If you considered my thoughts to be ludicrous, you misunderstood them,
False logic. Just 'cause you say it, does not mean that what you say is
not silly, Max.
And, Max, I used the word: silly, not ludicrous.
> They may not be incorrect, they may not even be
> worthwhile, but they are not ludicrous; they're ideas.
Yes. Silly ideas. You need to understand something: if your ideas are
not realistic, they are silly. A fun kind of silly, maybe, but still
silly.
> If you can only
> deal with them through ridicule,
I don't "only deal with them through ridicule". If you are unable to
understand, through my explanations, why your ideas are either wrong, or
unrealistic, then maybe you should just give up.
> then apparently you aren't up to the
> challenge of considering them thoroughly enough or addressing them
> directly.
More false logic. Max, it is equally possible that I *HAVE* considered
your ideas "thoroughly enough", and that my superior intellect and
abilities has discovered mistakes in your reasoning.
Possibilities aside, it is simply *true* that I have already addressed
your points directly.
> *Negatively* impacting the *average* 'efficiency' of a system in order
> to increase the particular performance of the overall system might be a
> more efficient mechanism for the "generally used for one task at a time"
> desktop PC,
See? Your respondents in general, and myself in particular have already
addressed this point: this is *PRECISELY* your mistake. There is no
conflict between efficiency and performance here.
> and might not, require the expense of a special-purpose
> system, as you grandly but accurately suggested.
"Grandly"? What was grand about my suggestion? You want it optimized
for just you, it's going to cost you. I suspect my estimate was
actually rather conservative, as the engineering and production costs
for specially designed hardware may well exceed that cost . . .
> A PC capable of
> running any set of tasks might be "self-optimizing", for whatever set of
> tasks are currently in use.
Not might: already is, if you are running a well written, modern OS.
> How this would be implemented or whether it
> would be efficient I must leave to those with both the engineering
> knowledge to ponder it and the ability to understand it.
It's a done deal, Max.
> You have side-swiped my original intent, I think. I don't need "fully
> optimized" for 2 billion dollars. Can I get "80% optimized" for $2000?
Define your task set, and what "optimized" means for you, and I'll let
you know.
> I don't want to have to tune it; can't the computer do that
> automatically?
How? From my standpoint, the OS already "automatically" tunes itself
within the constraints imposed on it. You have yet to suggest factors
that an OS should take into account that it does not already, or if you
have, you've suggested factors that you yourself cannot measure, or even
describe.
> PMT is certainly a very powerful way to run scheduling.
> I'm not the first to suggest, however, that something even better may be
> possible.
No, you're not. But credible people usually understand the state of the
art, and make specific suggestions.
--
If I spoke for HP --- there probably wouldn't BE an HP!
John Stevens
[EMAIL PROTECTED]
------------------------------
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
From: Chris Wenham <[EMAIL PROTECTED]>
Date: Mon, 24 Jul 2000 19:17:02 GMT
Arthur Frain <[EMAIL PROTECTED]> writes:
> Chris Wenham wrote:
>
> > Anal English Major
>
> No offense intended, but is "Anal English" the
> same as "talking out of your ass"? If so, you
> could find a lot to study on Usenet.
It's short for Anally Retentive. Like when you pick on someone for
improper use of "who" versus "whom".
There's /also/ a lot of that on Usenet.
(I wasn't an English Major, btw)
Regards,
Chris Wenham
------------------------------
From: "John W. Stevens" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Mon, 24 Jul 2000 13:21:11 -0600
"T. Max Devlin" wrote:
>
> Said Gary Hallock in comp.os.linux.advocacy;
> >"T. Max Devlin" wrote:
> >
> >> Quite possible. If you have any suggestions, I'd be happy to hear them.
> >> I think it may be so contrary to your experience that you might consider
> >> any statement of it to be difficult to understand.
> >
> >There you go with the insults again!
>
> There you go with the assumptions again. I meant that literally, not as
> an insinuation of a lack of experience on John's part.
And my literal response is: I not only understand your points, I
understand them better than you do, and that my superior intellect,
training, experience and abilities very quickly allowed me to discover
the flaws in your reasoning.
[ "Yours . . . is the superior . . . intellect!" ]
;-> ;-> ;->
I could *NOT* resist the irony! I really, really couldn't!
> >You have a very narrow view of "desktop", one that is quite antiquated.
>
> It was invented by the market, not me.
Markets can be created, or modified. Hence the existence of marketing
and advertising people.
> This is just the kind of silly statement which causes this to be a
> religious question, when it rightfully should be a technical issue.
What was silly about the statement?
> PMT's benefit is to allow the background processes to continue to
> function at optimal balance with *process switching*.
No, PMT's benefit is that it optimizes the return on your CPU cycle
investment.
> The matter of
> task switching at the human level does not really enter into it that
> much.
According to you in other postings (and I agree with you, there) it
*DOES* "enter into it".
> This leads to such common but badly interpreted statements as
> "Cooperative Multi-Tasking is not really multi-tasking."
Such statments are code phrases tossed around by trained individuals.
They are not meant to be taken literally, nor should they be directed at
the ignorant or incapable.
> Hence, hopefully someday, something better than PMT.
PMT is a design pattern. As such, it has a large number of different
implementations, some which have been modified to improve on previous
implementations of the pattern.
> Engineering
> efficiency is *not* the be-all and end-all of criteria for acceptability
> in the real world,
Wrong. Engineering efficiency *is* the primary measure of
acceptability, precisely because engineering efficiency results from
designing a realistic system to meet the needs of the user, and is based
on real world measurement, not theoretical hand waving.
> merely another advantage weighed against all others.
Incorrect. You cannot weight it "against all of the others", because
anything measurable at a realistic cost is already *INCLUDED* in the
"egineering efficiency" measurements, and all else cannot be "weighed
against", as no "weight" can be attached to it.
> An assumption that a single balance is possible is as meaningless as an
> assumption that a single balance is optimal.
Your assumptions about engineering practices are incorrect.
--
If I spoke for HP --- there probably wouldn't BE an HP!
John Stevens
[EMAIL PROTECTED]
------------------------------
From: "Nate Slater" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.alpha
Subject: Re: Linux = Yet Another Unix
Date: Mon, 24 Jul 2000 12:29:44 -0700
"Saul Goldblatt" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > Linux = Yet Another Unix. I think that every one of these Linux cult
> > members should be sentenced to one year of having to perform tech
support
> > for end-users of that OS.
>
> There aren't any end users running Linux, at least none that are
> officially supported by the corporate policy. There are however,plenty of
> idiots that take it upon themselves to wipe out the corporate pre-load of
> Windows and "TRY" and use Linux. When they hose up their entire system,
> not to mention flood the network with packets, they call me. I am a
> manager of a technical support help center and unfortunately we have a
> few bad apples that insist upon trying to run Linux on their corporate
> issued PC's.
> It usually ends in disaster.
We run a heterogenous environment at my office. We've got 'doze 98 clients
and NT boxes and linux boxes. Running tcpdump on the NIC of the internal
router is quite informative. The NT boxes, particularly the domain
controllers and WINS servers spew more unsolicited packets than any other
machine by far. One of the main reasons for this is that the NT machines,
particularly the domain controllers, are always having 'elections.' Plus,
the WINS machines seem to always be querying the network to see which boxes
are out there. For that reason, I've completely disabled WINS and now just
use DNS.
And, on the topic of DNS, we just recently noticed that the new 'doze 2000
box was spewing packets destined for port 53 on the DNS server attempting to
"update" the zone file with it's host information. Fortunately, this
annoying settting can be shut off. But it contributed to lots of annoying
network traffic and DNS problems. Too bad the only way to disable an NT PDC
is to rebuild the box.
<snip>
> It's run by anti-social, pencil necked geeks who need to get laid more
> often, even if they have to pay for it and chances are good they do.
>
> Tip: Make sure and pick a fresh one!!!
>
> Students are another source of Linux supporters. Green, starry eyed
> nymphs who have not a touch of reality having been shielded from the
> reall world for four or five years. They end up being clones of their
> professors, who wouldn't be professors if they actually had any talent.
>
> I see a couple every week here trying to get a job. They are textbook
> idiots with absolutely no grasp on reality.
Let me guess: you're an MCSE aren't you? I have written lots of code for
both Linux and Microsoft. In fact, for the last several years, I've been
working on a project that involves nothing but Microsoft technology. And
I've come across more mediocre programmers, systems adminstrators, and help
desk people during this project than you can possibly imagine.
The linux projects always seem to go smoother. True, linux is far from
bug-free. But (unlike Microsoft) the open-source community will more often
than not admit that there are bugs and fix them in a timely fashion. Not to
mention that the documentation on the technology is better and more
complete. And it's actually documentation, rather than marketing materials.
All the big software projects seem to involve a combination of different
technologies, including linux, unix, NT, and usually some sort of RDBMS.
I've found that the linux and unix folk are almost always capable of
developing in all environments, including NT. The NT folk, on the other
hand, are almost always helpless outside the 'doze world. IMO, this says a
lot about their overall talent as developers, and even more about their
understanding of how computers and networks function.
This isn't sermonizing; this is simply what experience in the industry has
revealed. I won't deny that there are certainly some very talented NT and
'doze programmers out there (many are my friends and co-workers). But like
I explained above, they all have knowledge in other OS's and environments,
and that's what sets them apart from the rest. And I have yet to come
across a linux or unix guru who didn't know how to work with NT.
Unfortunately, the converse simply isn't true.
> The joke is on Linux.
No, the joke is on those who deny that it is actually a viable, production
ready technology.
>
>
> Linux = Loser = Waste of time = no interest = sewerage = garbage.
>
>
> Linux is the collective septic system of all of the open sores waste that
> is given away (lord knows they could never sell such junk).
>
> We just sent out a memo today forbidding any alternative operating
> systems on the corporate personal computers including lap tops.
>
> The only thing Linux has going for it is that it is cheap. I can relate
> to that. After all, "Why pay retail, when you can get it wholesale"?
And why pay for NT when you can get a better, more reliable environment with
Linux for free?
>
> Saul Goldblatt
Nate Slater
------------------------------
From: "John W. Stevens" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Mon, 24 Jul 2000 13:47:22 -0600
Christopher Smith wrote:
>
> "John W. Stevens" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Christopher Smith wrote:
> > >
> > > "T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Quoting void from comp.os.linux.advocacy; 12 Jul 2000 05:05:24 GMT
> > > > Then all
> > > > you're doing is implementing CMT.
> > >
> > > You nearly emulate CMT in almost all PMT systems by upping the process
> > > priority as high as it will go. Much like CMT, this tends to lead to
> > > undesirable effects.
> >
> > CMT is a proper subset of PMT.
> >
> > Want CMT on a PMT machine? Turn off the timer interrupt.
>
> So how then does the app give the CPU back ?
Through making a system call to perform I/O . . . most drivers implement
a sleep/wakeup mechanism, which means that the calling task would go to
sleep (and thereby, generate a task switch), unless the conditions
neccessitating a switch were not present.
> I wasn't aware PMT had the
> equivalent of a "yield".
PMT, as a design pattern, incorporates the concept of a yield. Mind
you, very few if any *implementations* of PMT have a "yield" system
call.
> > Err . . . no. Early PC systems used CMT because the systems code was
> > not written in such a fashion as to allow for pre-emption, and the cost
> > of re-engineering the systems code was not only prohibitive, but when
> > added to the cost of modifying the existing applications software base,
> > was essentially impossible from a marketing/economic/mindshare point of
> > view.
>
> Then why was the Mac CMT ? It had no code to be re-engineered (and the
> "original", the Lisa, _was_ PMT).
The original Mac had no multi-tasking capabilities at all.
The Lisa pattern was abandoned (partially, it seems, due to memory
costs).
Later, when it became clear that MT of some kind was a requirement of
the market, Apple found that CMT was the easiest way to get some kind of
MT.
> I can see why it would matter in the case of, say, Windows 3.1, running on
> DOS, but I fail to see how that would have been relevant to the Mac.
Memory costs. A single tasking system needs less memory than a MT one,
regardless of the technology used to implement MT.
> Insufficient hardware resources is, to me, the only logical conclusion.
Yep. Got it in one.
> > I wrote a pre-emptive multi-tasking kernel that ran on the early IBM PC
> > compatibles (an XT, to be precise). I ran just fine, with more than
> > enough hardware resources, but the applications that it ran had to be
> > specially written for it.
> >
> > Mind you, the "non-reentrant" problem still bit: I had to lock the
> > scheduler while a task was running BIOS code. . .
>
> How much RAM ?
640 KiloBytes. No PM, of course.
> Did you have GUI running on it as well ?
Nope. I had a windowed, character based UI for it instead, and a mouse
driver plus cursor, but GUI's are inherently wasteful for systems that
do not need graphics. It was later ported to a 80186 and 80286 based
systems, then finally shelved.
I think I still have it around some where.
--
If I spoke for HP --- there probably wouldn't BE an HP!
John Stevens
[EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
