Linux-Advocacy Digest #661, Volume #27 Fri, 14 Jul 00 00:13:06 EDT
Contents:
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: Richard Stallman's Politics (was: Linux is awesome! (Mike Stump)
Re: Student run Linux server. ("Flacco")
Re: Linux development process model documented? ("Flacco")
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: What I've always said: Netcraft numbers of full of it (Mike Marion)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linux code going down hill (Donovan Rebbechi)
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: LINUX NFS SUX !!! (Donovan Rebbechi)
Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
Re: Student run Linux server. (Donovan Rebbechi)
Re: Linsux as a desktop platform (ZnU)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Thu, 13 Jul 2000 22:12:50 -0500
On Thu, 13 Jul 2000 22:47:23 -0400, T. Max Devlin <[EMAIL PROTECTED]>
wrote:
>Quoting [EMAIL PROTECTED] from comp.os.linux.advocacy; Wed, 12 Jul 2000
>>On Wed, 12 Jul 2000 22:06:35 -0400, T. Max Devlin <[EMAIL PROTECTED]>
>>wrote:
>>
>>>Quoting Aaron Kulkis from comp.os.linux.advocacy; Wed, 12 Jul 2000
>>> [...]
>>>>I disagree. By eliminating pre-emtptive multitasking, you eliminate
>>>>the ability to do a renderining (CPU-bound) in the background while
>>>>running netscape (mostly user-input bound, occassionaly network bound).
>>>
>>>You don't *eliminate* it. It gets much slower, potentially much much
>>>slower. But that's OK; ITS IN THE BACKGROUND.
>>
>>So what? Who cares if it's in the bg? Why is there even a *concept*
>>of bg? That's just archaic and old-time thinking.
>
>That's what I'm trying to tell you. It's not. Yes, there are
Yes, really, it is. The concept of only have one application that you
care about on the computer running at any given time is archaic - as
is the expectation that it would be the frontmost app.
>"user-oriented tasks" which need to be accomplished in the background,
>but its still the background. Its not *what I'm waiting for right now*.
However, "what you are waiting for right now" only rarely would stress
the CPU and more frequently would just be waiting for YOU, so it's
wise to have a more efficient way to distribute CPU cycles. PMT
offers that. CMT doesn't.
>I am not sure that PMT systems put enough emphasis on *the foreground*,
>or some even better way of determining what is important to the user.
NT/W2k lets you add a +1 priority to the app in the fg if you want.
That's a far superior solution to CMT and the "starve everything else"
method found in that solution.
>And it doesn't provide the mandate of cooperation that CMT does to
>benefit the market, either.
Err...huh?
>>>I don't *need* it right
>>>now.
>>
>>So what? Even if I don't "need" it right now, I still want it to keep
>>working on whatever I told it to do!
>
>Its not going to keep on working.
Exactly. That's the problem.
>Its just not going to get a "fair
>share" of the resources anymore, because it is not as important as what
>I need right now.
You fail to understand - what "I need right now" is so infrequent in
today's computers, and the "what I want to work on in the bg" so
frequently takes so little interaction, that you've got a lose-lose
system with CMT if the frontmost app gets the lion's share of CPU
time. The app that DOESN'T need time (the fg app, which is waiting on
you to type a letter to the editor) gets all the CPU time, and the
huge rendering jobs you put in the bg are all starved for time. This
is a very, very typical issue with CMT.
>Do you see what I'm saying.
I see exactly what you're saying. I also have enough knowledge of
MacOS and CMT to know that's a piss-poor solution.
>I know this isn't
>normally how process scheduling is considered, and it isn't in fact the
>same abstraction as the lowest level of consideration of PMT/CMT. But
>at the highest level, it doesn't seem to make that much of a difference,
>and the highest level is where I'm talking about. If the only benefit
>of PMT is at the lowest level, then it is a theoretical benefit which
>could be easily outweighed by factors outside that scope of reference.
You fail to take into account that the PMT system handles the 'right
now' business better, too - AND it handles the bg tasks better. That
makes the entire system faster and more responsive. It makes a
tremendous different in CPU speed and user efficiency.
>Thanks for your time. Hope it helps.
What system do you have in front of you as you read this?
------------------------------
Crossposted-To: gnu.misc.discuss
From: [EMAIL PROTECTED] (Mike Stump)
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Fri, 14 Jul 2000 03:11:36 GMT
In article <[EMAIL PROTECTED]>,
Austin Ziegler <[EMAIL PROTECTED]> wrote:
>Mixed metaphors are meaningless. Attempting to do an animate/inanimate
>metaphor (or even worse, an object-person metaphor) is mixed, and is
>therefore meaningless.
You say this, but do you have a reference?
Swimming in people seems a perfectly good metaphor to me, and yet, it
seems to be as much a violation as the first metaphor. Is it invalid
in your opinion?
------------------------------
From: "Flacco" <[EMAIL PROTECTED]>
Subject: Re: Student run Linux server.
Date: Thu, 13 Jul 2000 23:04:40 -0400
> Getting the hardware does not appear to be a problem, but I am sort of
> concerned that nobody (expect for the core group of admins) would ever
> use it. Are there any ideas out there on how we can teach people about
> Linux in a fun, and interesting way, but within the bound of a school
> environment; eg we don't want to teach them about Linux by letting them
> set up their own warez mirror, or even running a quake server...
What's wrong with setting up a quake server?
if they like quake:
Tell them if they can figure out how to do it, they can spend one class
period a week for the next four weeks fragging each other!
Tell them they have to find a way to automatically post high scores on the
web server.
Tell them that if they successfully set up Linux and XFree86 4.0 at home
they can connect and play on the server from home.
Of course, for the girls, replace "quake" with "The Care Bears Save
Christmas" :-)
< descending into fire-proof bomb shelter >
------------------------------
From: "Flacco" <[EMAIL PROTECTED]>
Subject: Re: Linux development process model documented?
Date: Thu, 13 Jul 2000 23:06:40 -0400
Well, in any case, let us know how you fare getting that back door into the
kernel :-)
"Michael W. Godfrey" <[EMAIL PROTECTED]> wrote in message
news:8kfbq8$767$[EMAIL PROTECTED]...
>
> Hello folks.
>
> I'm a Linux user since 0.99pl15 and I've even done a bit of research on
> some aspects of the linux kernel (see
http://plg.uwaterloo.ca/~migod/papers/
> if you're interested), 'tho I've never been a kernel hacker.
>
> What I'm looking for is a good explanation from someone who knows what
> they're talking about of the development process model (ie how the code is
> written and approved) for contributions. I am not looking to contribute
> any code myself, I'd just like a fairly detailed explanation as to how it
> happens.
>
> I'd like to know, for example, how many people look at contributed code,
> how the "chain of command" works, what and where flexibility is.
>
> Let's say I have
> (a) a skeleton of a driver for a new piece of hardware that provides
> some real functionality but is far from complete.
> (b) a more or less complete driver for a new piece of hardware.
> (c) some "performance improvements" to existing core i386 kernel code.
> (d) some new features to a central, stable piece of code
> (e) some bug fixes to a central piece of code.
>
> How would each of these likely be handled? Is this well documented
> somewhere?
>
> Is the non-i386 kernel code (ie in the arch subsystems) maintained
> differently by different people? Who (in general) has say over these
> paths?
>
> Enlightenment much appreciated (also pointers to a better place to submit
> this posting, if one exists).
>
> Thanks very much.
>
> -- Mike G.
>
>
> --
> Michael Godfrey PhD, Assistant Professor
> Univ of Waterloo, Dept of Computer Science
> email: [EMAIL PROTECTED]
> URL: http://plg.uwaterloo.ca/~migod
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Thu, 13 Jul 2000 22:17:29 -0500
On Thu, 13 Jul 2000 22:43:06 -0400, T. Max Devlin <[EMAIL PROTECTED]>
wrote:
>job of it, let me tell you. Of course, I'm on Windows, not Linux, yet.
Win 3.1?
You speak SO much about PMT and CMT - what CMT systems are you
experienced in? Why don't you run a CMT system, if it's so much
better?
>Perhaps I would like to hear that engineers are even now working on
>developing a more "autonomous multi-tasking", which would allow
>cooperative control by an OS that is knowledgable of all processes,
>applications which can present their requirements appropriately, and a
>user who can control the system easily and effectively. Perhaps someone
>is going to explain to me how this is indeed the system that's currently
>used. Being a non-engineer and discussing things with engineers doesn't
>do much for your technical knowledge, it seems. But I'd appreciate a
>little responsiveness. It certainly would be easy to prove me wrong (or
>has been, if you of that mindset), but are you up to the challenge of
>teaching? Or possibly, on some remote chance I happen to be providing a
>unique perspective that hasn't been addressed before, of learning?
I think NT/W2k do this now; have you used those systems?
------------------------------
From: Mike Marion <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: What I've always said: Netcraft numbers of full of it
Date: Fri, 14 Jul 2000 03:18:50 GMT
Drestin Black wrote:
> > b) a server that can only do ONE thing (mail, webserving, file serving)
> > and even then crashes every 45 days or less.
>
> like the sun boxes we replace often!
In your dreams. If those boxes were doing only one thing, then they
were either not setup right, so old it's pitiful, or seriously
underused. Our Sun workstations do plenty of stuff all the time. We
even use LSF so that every workstation is used to it's fullest
potential: All spare cycles are used as part of our compute farm.
--
Mike Marion - Unix SysAdmin/Engineer, Qualcomm Inc.
Jo-anna: "Bing? That's a great name."
Chandler: "Thanks, it's Gaelic for 'Thy turkey's done.'"
--Friends
------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Thu, 13 Jul 2000 23:20:19 -0400
Reply-To: [EMAIL PROTECTED]
Quoting ZnU from comp.os.linux.advocacy; Thu, 13 Jul 2000 18:57:37 GMT
[...]
>Unless the CPU is under 100% load (which is usually isn't), everything
>in a PMT system will run just as fast as it would if there was nothing
>else running. This isn't the case in a CMT system. Under load, a PMT
>system remains far more responsive because no single process can grab
>the entire CPU.
What do you mean by "responsive"? I think you're only considering the
average responsiveness of all applications. The whole point of CMT is
that, when under load, the *average* response can go to hell (to a
certain level; connections don't time-out in nanoseconds), as long as
the process the user interface is concerned with at the moment can grab
*almost* the entire CPU, if it needs it.
>In a CMT system, any app (including the foreground app) can become
>unresponsive if any other app hogs the CPU.
Thus providing the need for cooperation. Yes, any system that is based
on cooperation can screw up the system for everyone. Are you saying
Token Ring is better than Ethernet? TCP/IP sucks compared to X.25?
Microchannel was more successful than the original PC? All of these
very important technologies are all based on one thing: you cannot
mandate technical value in market-driven development. So stop trying.
Because there is always technical value in cooperation, and the market
LOVES cooperation. Its what its built for. System which mandate
cooperation end up being far superior than systems which attempt to
impose even egalitarian rules.
>Worse, if, for example,
>you're doing a 3D render that's hogging the CPU, everything else in
>_that app_ becomes unresponsive.
Sounds like renderer should be a separate process. Is that too tough?
You realize it would provide value all by itself, right? At least I
assume so, since multi-threaded programs seem to be very popular in the
market.
>One of the most frustrating things in
>Mac OS is hitting the cancel button and needing to wait for 30 seconds
>because the operation you're trying to cancel has hogged the CPU to such
>an extend that the cancel even can't be processed.
The same thing happens on other systems. Its your app; use it or don't.
Or its the developer's app; buy it or don't. Engineers are too smart
for their own good, and I say that with a great deal of admiration, but
very little envy.
[...]
>If you call it "second-guessing the operator" to assume that the user
>wants things to get done as fast as possible and the system to remain as
>responsive as possible....
Yes. Because you're talking about averages and policy, and I'm talking
about individual instances. The issue isn't with "fast as possible and
responsive as possible". The issue is "things" and "wants".
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
ELTRAX Technology Services Group
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
my employer, has to pay for them, subject to
applicable licensing agreement]-
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: Linux code going down hill
Date: 14 Jul 2000 03:20:42 GMT
On Thu, 13 Jul 2000 21:11:34 -0400, Colin R. Day wrote:
>Damn. I must have missed it, sorry.
I think this one is fairly new ( rpm >= 3 ).
Cheers,
--
Donovan
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Thu, 13 Jul 2000 22:19:48 -0500
On Thu, 13 Jul 2000 23:05:40 -0400, T. Max Devlin <[EMAIL PROTECTED]>
wrote:
>He's talking about the fact that desktop operating systems might be used
>for multi-tasking, but desktop interfaces are still single-tasking. And
Err...whaaaat? What in the world do you mean by that?
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: LINUX NFS SUX !!!
Date: 14 Jul 2000 03:23:52 GMT
On Thu, 13 Jul 2000 13:58:08 GMT, ne... wrote:
>Prepare to be flamed... sorry I can't help you tho.
As an advocacy veteran, I have asbestos skin (-; Anyway, it looks like
a few people helped out. THe userland NFS server's still working like charm
after a few hours an several logins/logouts from me ... fingers crossed (-;
Cheers,
--
Donovan
------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Thu, 13 Jul 2000 23:24:53 -0400
Reply-To: [EMAIL PROTECTED]
Quoting Austin Ziegler from comp.os.linux.advocacy; Thu, 13 Jul 2000
09:26:56 -0400
>On Wed, 12 Jul 2000, T. Max Devlin wrote:
>> Quoting Austin Ziegler from comp.os.linux.advocacy; Wed, 12 Jul 2000
>> [...]
>>>> Of course, they'd have all the source code to all the software, so I'd
>>>> guess they've been well compensated.
>>> That's a wonderful fantasy when it comes to actually putting food on the
>>> table and a roof over one's head.
>> You aren't actually still playing the "let's have sympathy for
>> programmers" card, are you? I thought I'd ridiculed that sufficiently
>> below:
>
>Better a programmer than a clueless manager/consultant feeb.
Oh! You meant *me*. It took me a minute to figure it out. Ha.
I don't need your sympathy, and haven't asked for it, so I guess your
only point was to call me a 'feeb', huh? Ha.
Thanks for your time. Hope it helps.
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
ELTRAX Technology Services Group
[EMAIL PROTECTED]
-[Opinions expressed are my own; everyone else, including
my employer, has to pay for them, subject to
applicable licensing agreement]-
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: Student run Linux server.
Date: 14 Jul 2000 03:28:01 GMT
On Fri, 14 Jul 2000 01:49:37 GMT, James deBoer wrote:
>That is an interesting idea, there is a couple business courses in the school
> where students learn about HTML, if approached I bet the teacher would be
> happy to incorparate Linux into the course.
Some of the cooler features of apache may be worth exploring too. Some like
CGI may be a bit complex, some like server side includes are pretty easy.
>However, the idea that we should teach 'them' (those people using the server)
> that the Internet is bigger than the web. The idea was to show them other
> things like IRC, etc...
Usenet, perhaps ? You wouldn't have to have an incoming newsfeed, maybe
just some "local" groups.
--
Donovan
------------------------------
From: ZnU <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Fri, 14 Jul 2000 03:30:22 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Quoting ZnU from comp.os.linux.advocacy; Thu, 13 Jul 2000 18:40:28
> GMT
> >In article <[EMAIL PROTECTED]>,
> >[EMAIL PROTECTED]
> [...]
> >You keep repeating such things. CMT doesn't put the user in control,
> >it puts the apps in control. This is bad, because the apps can't
> >know what else the system is doing, so they have no idea when they
> >should be yielding CPU time.
>
> What is bad is forgetting that the user is supposed to be in control
> of the apps, not the other way around.
The user can't control CPU scheduling manually. That isn't an option.
The choice is either to let the apps do (CMT) it or let the OS do it
(PMT), and the OS is much more qualified.
> [...]
> >Most innovation and adaptation in in the user interface department
> >just makes things worse. In the rare case where an application
> >developer does actually come up with something that works better for
> >a particular app than the standard, any potential productivity gains
> >are typically offset by the fact that the user needs to learn much
> >more to use the app, and has to consciously remember how things work
> >in that app vs. in everything else.
>
> It is *very* important that you realize that this last bit is
> counter-productive and mistaken. The cost of learning an interface
> cannot be considered a component of its *use*, merely of its
> adoption. User's don't have to "consciously remember how things work"
> if they are going to use the software.
They do if they have to constantly switch between applications that work
in totally different ways.
> Yes, software designed for
> infrequent use should have a simple interface. No, software designed
> for frequent use, should *not* have a simple interface. It should
> have an appropriate one, but it is the *user*, not the *app*, which
> is the determinant factor in what is appropriate, or useful.
An app should have an interface as complex as it needs, and no more. I'm
not arguing otherwise. What I'm saying is that an app should have a
_standard_ interface. Take a look at just about any of the KPT software.
In some respects. that kind of interface is better than a standard UI
for those programs. But that small superiority is totally offset by the
fact that they use interfaces that make any experience a user might have
with any other app useless.
It isn't just a matter of learning the apps. To give an example: when I
want to copy something, I select it an hit command-C. I do this without
even thinking, because it works like that in any app. If that worked
differently in every app, I wouldn't be able to do it nearly as fast. I
might not even notice that I'd be slower, but it would show up in tests.
> >This is one of my big fears about Microsoft's .Net platform: there
> >won't be any more UI standards than there are on the web in general.
> >Every app will work differently.
>
> That's already happened; MS is just trying to re-capitalize on it.
> Almost every non-engineer in the world is entirely and completely
> convinced that putting an interface on a web page makes it work *the
> same* as all the others, in direct and obvious contrast to their
> senses.
I can't wait for the first productivity studies....
> >This is also a big problem under the Unix OSes, of course, where
> >nobody can agree on a toolkit.
>
> Nobody should agree on a toolkit; innovation requires diversity. But
> I understand your point.
Innovation might require diversity, but usability requires consistency.
It seems to me that the innovation should be kept off the users'
desktops until its ready to become the standard. Of course, the open
source development model doesn't work like that.
> [...]
> >They can cooperate all they like. It still won't work as well as
> >PMT, because the apps don't know anything about what else is running
> >on the system.
>
> That is a valid reason not to put the apps in charge. In PMT, the
> apps are in charge (via the consistent and algorithmic rules of the
> scheduler.)
No. The scheduler is part of the OS. Apps don't get CPU time unless the
OS determines they "deserve" it, using extremely efficient algorithms
that have been refined over the course of several decades.
> In CMT, the user is in charge, not the apps. If the app
> I bring to the foreground doesn't yield sufficiently and stops my
> download, then I will get rid of that app and get one that works.
I don't see how that puts the user in charge. You're not choosing where
the CPU time is going, the app is. If an app yields to CPU too much, it
takes a performance hit. If it doesn't yield it enough, other apps take
a performance hit. Any given app has no idea how much it should be
yielding, because it has no idea what else is running on the system.
There's no way to write an app that is "friendly" under all conditions
in a CMT system.
> Personal computers should always put the user in charge. If the user
> cannot be assumed to know what they're doing, then it is the job of
> th engineer to present the choice through an interface analogy they
> can understand, not to make the decision for them, nor to put the
> software in charge.
Again, putting the user in charge is not an option here. The closest you
could come would be a PMT OS that provided a very easy interface for
setting priorities. But I suspect a good scheduling algorithm would be
better at it than any user could be in the vast majority of cases.
> Second guessing the user is what Windows does
> wrong. I'm not saying that putting PMT on a desktop is as bad as
> Windows. I am saying that the assumption that technical issues for
> the engineer are the same as, or even pre-eminent in comparison to,
> the operational issues of the PC user is something I've noticed
> causes a lot of subtle problems on down the road, while everyone is
> concentrating purely on the task at hand. No doubt the future system
> will do PMT, sure, because it is technically important when dealing
> with servers and high-speed I/O, and desktop need to do those things
> as well as be a client. But it will mimic a CMT system, if it is
> going to be optimized for efficiency by or for the user operations
> which is its purpose for being there.
I'm not sure what you mean by "mimic a CMT system." You mean it will
become unresponsive under load?
> >> which *does* require a mandate to be implemented, given the
> >> differing perspective of the vendor and the end user versus the
> >> ultra-geek that knows what a real-time OS is.
> >
> >A real-time OS is an OS that _guarantees_ a given response time. I'm
> >not quite sure why you seem to be against the idea, given what
> >you've said about the importance of the issue.
>
> For the same reason I am against the *ideal* of "guaranteed response
> time" in all guises and facets. Its a doomed proposition.
It's done every day. QNX is primarily used in embedded applications
(e.g. engines, robotics) where things will go very wrong if there aren't
guarantees for response time.
> The
> Internet only works because some very smart engineers back in the
> early 70s realized it wasn't necessary. Maybe someday soon software
> engineers will recognize the same. Build the apps so they don't
> *need* guaranteed response time, even if you think the operations
> they are supposed to perform seem to require it. Then, even if they
> don't get guaranteed response time, they will be able to handle it,
> and if they don't, they will be all the better off.
The _apps_ on a general purpose desktop computer have no problem with
waiting for the CPU. It doesn't bother them. It only bothers the user.
And a PMT system keeps the user waiting much less than a CMT system.
> To proffer a "virtual" guarantee, which is all any piece of software
> or hardware can do, is merely to encourage development of systems
> that depend on it, and will immediately and ungracefully fail when
> they don't get it, because they were designed to assume it and cannot
> do without it.
>
> Somewhere real-time OSes might be positively and unavoidably
> necessary. There is no reason to think that they are anywhere near
> where humans are trying to get work done.
That's right. A regular OS with a good PMT schedular does that very
nicely.
> >> It also contributes (without either guaranteeing or prohibiting
> >> the alternative) to allowing the operator to have control over
> >> which applications get priority, without having to actually
> >> implement a priority system, by simply assuming (and it is a valid
> >> assumption almost all the time on a desktop client system) that
> >> whatever program the user is working in is the one that should
> >> have priority.
> >
> >No. That isn't what happens in a CMT system. I've pointed this out
> >multiple times. Once the foreground app gives up the CPU, it can be
> >grabbed and held by any other app for as long as that app wants,
> >causing the foreground app to become unresponsive.
>
> I see your point. I did miss it; my apologies. Hmmm. See, the
> background app that grabbed it is even easier to identify than the
> foreground app that didn't yield it. Engineers are trained not to
> leave things to chance. But the market isn't, and this is a
> consumer/user/operator/end/client/desktop system we are talking
> about. CMT systems encourage proper app design.
Again, it is impossible to design an app that "plays nice" under all
circumstances, because the app doesn't even know what other processes
are running, or how much the user cares about them.
> PMT allows the app designers to handwave the issue because the OS has
> already taken the decision out of their hands. A much more
> responsive PMT system, responsive to *human* things, not just
> *interface* things, able to provide optimization to the user without
> second-guessing him, would be optimal. Like I said; a PMT system that
> pretend to be CMT might be optimal in practical terms.
I still have no idea what you mean by "pretend to be CMT."
> >> I'm glad we could find something to disagree on, Jedi, but I do
> >> hope you will consider that you might be over-extending your
> >> knowledge of the specialties involved, and making assumptions
> >> about the practical value of theoretical benefits.
> >
> >None of this is theoretical stuff. Compare the responsiveness of Mac
> >OS 9 vs. BeOS or Mac OS X DP4 or some Unix under load. There is no
> >contest. Mac OS becomes unusable. A PMT OS doesn't.
>
> None of this is theoretical stuff. Compare the performance of my
> Aunt Sue, who's sixty one and types 100 words a minute while also
> keeping books in Quicken, to my son Alex, who surfs the web at two
> clicks per cheat code, or Gary down the hall, who gets three stock
> tips per three vendor presentations. There is no contest; the human
> has to be in charge.
And again, the human can't be put in charge of CPU management. Unless
you'd like to return to systems which can only run one app at once, or
systems in which the foreground app _never_ yields, and background apps
just sit there doing nothing at all.
--
The number of UNIX installations has grown to 10, with more expected.
-- The Unix Programmer's Manual, 2nd Edition, June 1972
ZnU <[EMAIL PROTECTED]> | <http://znu.dhs.org>
------------------------------
** 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
******************************
