Linux-Advocacy Digest #664, Volume #27 Fri, 14 Jul 00 02:13:06 EDT
Contents:
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Linsux as a desktop platform (ZnU)
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Richard Stallman's Politics (was: Linux is awesome! (Mike Stump)
Re: Linsux as a desktop platform
Re: Linsux as a desktop platform (ZnU)
----------------------------------------------------------------------------
From: "Christopher Smith" <[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 15:02:42 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Quoting Christopher Smith from comp.os.linux.advocacy; Thu, 13 Jul 2000
> >"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
> >> [...]
> >> >Single-user or not, nobody wants their computer locked up because one
> >> >application has a serious bug. Operating systems should be resilient
> >> >against programmer error, because bugs happen and they happen a lot.
> >>
> >> No, desktop client operating systems need to be more resilient to user
> >> errors.
> >
> >True.
> >
> >> Programmers are assumed to have done their job correctly.
> >
> >No. Programmers should never be assumed to have done their job
correctly.
> >They are the single most fallible part of the development process.
>
> Sorry, I know this isn't going to get any better, so I'm going to cut
> you off here. I'm not sure when the last time you checked through all
> your source code to verify that your programs were done correctly, but I
> know I have no interest in doing that, and wouldn't even if I was a
> programmer.
It would make no difference. People make mistakes, often. Especially when
they're dealing with anything non trivial.
Maybe in 50 years when the software development process has matured more,
there will be a set, repeatable methodology that will efficiently produce
verifiably bug-free code (or, at the very least, allow bugs to be
quantified). But right now there isn't, so mass-production software is
buggy and is likely to remain that way for the foreseeable future.
That's just the way life is down here in the real world.
> Programmers are assumed to have done their job correctly.
>
> Would you like to start over?
Sure.
"Programmers are assumed to have done their job correctly" is a stupid,
dangerous and pointless assumption to make when there are well understood,
mature and often practiced methods to avoid having to make that stupid,
dangerous and pointless assumption.
It would be like building a modern highly strung engine without giving it a
knock sensor and electronic ignition and just *assuming* that the owner will
always be able to find 98RON fuel - stupid, dangerous and pointless. Or not
rust-proofing a car and *assuming* that the owner will never take it
anywhere near salt water.
CMT has no place in a general purpose desktop system. It has no advantages
and many, many disadvantages which are addressed by PMT. There is no reason
to use CMT, with its inherent flaws, when a superior system exists.
------------------------------
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 04:57:29 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Quoting Aaron R. Kulkis from comp.os.linux.advocacy; Thu, 13 Jul 2000
> >"T. Max Devlin" 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. I don't *need* it
> >> right
> >> now. What I *need* is for absolutely nothing on that system to slow
> >> down the *foreground* netscape from rendering. And I don't care what
> >
> >Actually, if you have ANY idle time, the *foreground* rendering and
> >the *background* printing are BOTH proceeding as quickly as possible.
> >
> >Very few problems are actually CPU bound.
>
> Then other than buggy applications, there's no benefit to PMT, right?
Wrong.
> Except its easier for the engineers, and doesn't work the way I want
> when I *don't* have any idle time. What happens in PMT if I *don't*
> have idle time?
That's where a PMT system really excels.
CPU time is still dealt out according to task priority, and, as has been
pointed out, user interface processes tend to accumulate priority
because they don't do anything most of the time. And what you have to
realize here is that we're working on such small time scales that even
if you're typing away like mad, from the computer's point of view the
time between keystrokes is so long that you're not doing anything most
of the time. Why shouldn't it be using that time to get other things
done?
Additionally, GUI PMT systems typically give priority bonuses to the
foreground app. This means everything tends to stay nice and responsive.
In a CMT system with no idle time, you end up with apps fighting over
the CPU. A heavily loaded CMT system can literally take _minutes_ to
respond to a user interface event as simple as registering a mouse click.
[snip]
--
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>
------------------------------
From: "Christopher Smith" <[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 15:08:37 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Quoting Matthias Warkus from comp.os.linux.advocacy; Thu, 13 Jul 2000
> 22:16:29 +0200
> >It was the Wed, 12 Jul 2000 21:58:29 -0400...
> >...and T. Max Devlin <[EMAIL PROTECTED]> wrote:
> >> >Can you find a way to make cooperative multitasking as robust as
> >> >preemptive multitasking?
> >>
> >> No. Can you find a way to make PMT as user-responsive as CMT? Then
all
> >> you're doing is implementing CMT.
> >
> >Preemptive multitasking can, if decently implemented, do everything
> >CMT does, and it is more stable because it protects you from buggy
> >programs. That's the core issue.
>
> Can't CMT not be said to follow the same rule?
No. No matter how good your CMT system is, you can't escape the inherent
weakness that any app can still grab the CPU and refuse to yield.
> If the only reason PMT
> exists is to protect me from buggy programs, it ain't doin' a tremendous
> job of it, let me tell you. Of course, I'm on Windows, not Linux, yet.
The thing(s) that make(s) Windows (95, I assume) unstable is not its
scheduler.
> I think maybe the core issue here (and Chris's note was helpful in
> bringing me to think of this) is that OS engineers necessarily consider
> the needs of the OS. And if you want to make sure that the computer
> doesn't crash and you're designing an OS, it makes sense to make it PMT,
> and CMT sounds like a really really stupid idea.
CMT is a really stupid idea in any system where the developers and
applications writers cannot operate in full collaboration. It just won't
work.
> But I will refer, once again, to the case of the Macintosh. For years
> it has continued to function while seeming to prove, to the markets
> satisfaction if not engineers', that this core issue can be inverted.
> Application developers, no doubt, will agree with the OS designers, as
> they would not want the burden of having to try to figure out how to
> know how much CPU time they might need, and how to gracefully share that
> requirement with the other apps.
>
> 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?
Modern PMT systems already do this. They have for years. There are a
plethora of algorithms around for dynamically allotting CPU time to maximise
whichever part of the system you want to - responsiveness, throughput, CPU
time etc.
------------------------------
From: "Christopher Smith" <[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 15:09:46 +1000
"Peter Ammon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> [EMAIL PROTECTED] wrote:
> >
> > On Thu, 13 Jul 2000 20:41:34 -0700, Peter Ammon <[EMAIL PROTECTED]>
> > wrote:
> >
> > >The more fundamental reason is that the Mac simply didn't have the
> > >memory to do it. So there is at least one example of a benefit:
> > >cooperative multitasking is more efficient in terms of memory used.
> >
> > The Amiga did it - beginning with the 256k Amiga - and color and a
> > bigger screen, too. And it did it quite well, too, for 1985 or so.
>
> But the Mac had half that amount of memory.
The Amiga also did a great deal of processing off the main CPU, IIRC.
------------------------------
From: "Christopher Smith" <[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 15:14:34 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Quoting Christopher Smith from comp.os.linux.advocacy; Thu, 13 Jul 2000
> >"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Quoting Christopher Smith from comp.os.linux.advocacy; Wed, 12 Jul 2000
> >> >"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
> >> [...]
> >> >No, there is not. CMT has no place and absolutely zero advantages on
any
> >> >general purpose machine where the operating system developer does not
> >have
> >> >absolute and total control over every instruction that is ever
executed
> >on
> >> >it.
> >>
> >> What the hell does the operating system developer have to do with it?
> >
> >How else can you guarantee the programs are going to co-operate unless
the
> >developers of all of them, and the OS, have collaborated ?
>
> Because if they haven't, they won't sell very many products.
That's a nice thought, but real life doesn't work that way. Stuffit, for
example, is one of the most popular [de]compression tools on the Mac, yet it
multitasks *dismally*, even by Mac standards.
You just cannot have apps co-operating unless they *know* how to co-operate
with whatever else is running - IOW they have to know about whatever they're
running with.
> Market
> behavior, not technical requirements, are the more flexible method of
> ensuring co-operation. You can tell which program is not "being nice",
> so to speak, and programs might even differentiate themselves by whether
> they get something done fast, or whether they get it done optimally
> while cooperating optimally. I think this relates to your reference to
> the OS developer having "absolute and total control over every
> instruction". To me, that sounds like the job of the owner of the
> computer, and generally the operator.
No, the point of the developer having such control is that with that
knowledge, they can tune the applications to work together and then, in
_theory_, you could have a multitasking CMT system that worked as well as a
PMT system.
------------------------------
From: "Christopher Smith" <[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 15:15:27 +1000
"Peter Ammon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> "T. Max Devlin" wrote:
> >
> > Quoting Peter Ammon from comp.os.linux.advocacy; Thu, 13 Jul 2000
> > [...]
> > >It is nice to have the complete attention of the CPU when you're doing
> > >something. I miss it in Classic dialogs in OS X, which feel jumpy.
> > >Windows is the same way.
> >
> > So, Peter, you seem to support my point. But is it really the PMT/CMT,
> > or are you just noticing differences in effect, but not process? Do
> > you know what I mean?
>
> ...no...
>
> > Do you have technical indications this is CMT, or
> > might it not just be a mirage which is conveniently explained as CMT?
>
> It's the only explanation I can think of for why classic modal dialogs
> would feel less responsive under OS X, especially when OS X is under
> heavy load.
>
> >
> > One of the reasons I ask is that, as the PMT advocates will tell you,
> > you don't really have "the complete attention of the CPU".
>
> That's true. There are still those bits that are preemptively scheduled
> in the Mac OS. But the foreground is certaintly receiving a lot more
> attention than the background.
I would say it would have a lot more to do with the virtual machine, and the
overhead therein, than the CPU scheduling.
It's not like a G4 is short on processing grunt.
------------------------------
From: "Christopher Smith" <[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 15:18:03 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Quoting Christopher Smith from comp.os.linux.advocacy; Thu, 13 Jul 2000
> >"Peter Ammon" <[EMAIL PROTECTED]> wrote in message
> [...]
> >> Then why did the original Mac OS team implement CMT?
> [...]
> >Insufficient hardware resources. Coupled with the, at the time, thinking
> >that desktop computers were really not going to be used for multitasking.
> >
> >The Lisa was PMT, IIRC.
>
> Well it certainly didn't have more resources than the Mac. Could you
> explain what you mean?
It had 2 or 4 times the memory, IIRC - 512k vs 128. Not sure if the CPU was
faster.
> >> It is nice to have the complete attention of the CPU when you're doing
> >> something. I miss it in Classic dialogs in OS X, which feel jumpy.
> >> Windows is the same way.
> >
> >I really must say I don't understand what you're talking about.
>
> He's talking about the fact that desktop operating systems might be used
> for multi-tasking, but desktop interfaces are still single-tasking. And
> that seems a reason to us who are ignorant of the technical details to
> wonder what difference it makes what kind of multitasking the OS uses,
> and whether one that requires cooperation on an open platform might not
> be more useful in its way then the one that was designed for systems
> that require time-sharing.
On any remotely modern system (ie anything faster than about a 386/33) it
shouldn't make a schmick of difference. THe delay Peter's noticing, I'd
wager, is most likely due to the inherent overhead in running MacOS Classic
under OS X.
------------------------------
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 05:03:33 GMT
In article <[EMAIL PROTECTED]>,
T. Max Devlin <[EMAIL PROTECTED]> wrote:
>In case you aren't aware, a dollar is a promise of a future dollar's
>worth of stuff, in just the same way as a credit card in your context.
Yes, but the difference is who is doing the promising... That subtle
difference is enough for me to switch from virtual to real. Remember,
like free, virtual is also kinda an opinion.
>The word "virtual" translates, in modern parlance, and particularly
>technical jargon, directly, entirely, and without exception, the word
>"not".
Wrong.
Virual memory you claim is not memory, but not memory is more
unqualified. A catfish is not memory, yet saying a catfish is virtual
memory doesn't seem quite right to me.
------------------------------
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: Fri, 14 Jul 2000 05:15:25 GMT
On Fri, 14 Jul 2000 15:09:46 +1000, Christopher Smith <[EMAIL PROTECTED]> wrote:
>
>"Peter Ammon" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>>
>>
>> [EMAIL PROTECTED] wrote:
>> >
>> > On Thu, 13 Jul 2000 20:41:34 -0700, Peter Ammon <[EMAIL PROTECTED]>
>> > wrote:
>> >
>> > >The more fundamental reason is that the Mac simply didn't have the
>> > >memory to do it. So there is at least one example of a benefit:
>> > >cooperative multitasking is more efficient in terms of memory used.
>> >
>> > The Amiga did it - beginning with the 256k Amiga - and color and a
>> > bigger screen, too. And it did it quite well, too, for 1985 or so.
>>
>> But the Mac had half that amount of memory.
>
>The Amiga also did a great deal of processing off the main CPU, IIRC.
That was one of it's redeeming qualities...
...and a flaw in the early Macs.
--
The LGPL does infact tend to be used instead of the GPL in instances
where merely reusing a component, while not actually altering that
component, would be unecessarily burdensome to people seeking to build
their own works.
This dramatically alters the nature and usefulness of Free Software
in practice, contrary to the 'all viral all the time' fantasy the
anti-GPL cabal here would prefer one to believe.
|||
/ | \
------------------------------
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 05:16:24 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> 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.
But the user interacts with more than one process at a time. Process !=
application, even if some people have used them interchangeably in this
thread. If the 3D program you're running grabs the entire CPU, a mouse
click won't register (even in that program), because the process
responsible for that won't be getting any CPU time.
> >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.
CMT should really be called "cooperative," because it isn't. Cooperation
requires communication, but processes in a CMT system don't communicate
to determine how much they should yield CPU time. They essentially yield
it whenever it was convenient for the developer to allow that.
PMT is a far more cooperative system, in that processes take only as
much CPU time as they need, and give the rest up to other apps.
> 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.
CMT makes things much harder for programers, and provides an inferior
user experience.
> >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.
The fact that its a separate process is the problem. It leaves the OS
with no CPU time to process UI events.
> >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.
On a PMT system, the worst the app can do it lock itself up for 30
seconds. On a CMT system, it locks the entire system up for 30 seconds.
> [...]
> >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".
And the "thing" users "want" is a fast and responsive system....
--
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
******************************
