Linux-Advocacy Digest #657, Volume #27 Thu, 13 Jul 00 22:13:05 EDT
Contents:
Re: Linsux as a desktop platform ("Colin R. Day")
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linux code going down hill ("Colin R. Day")
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform ("Christopher Smith")
Re: Richard Stallman's Politics (was: Linux is awesome! (Mike Stump)
Re: Web Browsers? (Aravind Sadagopan)
----------------------------------------------------------------------------
From: "Colin R. Day" <[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 20:56:38 -0400
"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.
Just because a job doesn't need your direct attention doesn't mean that
the computer your take its sweet time with it. After all, you may have a
client waiting.
> What I *need* is for absolutely nothing on that system to slow
> down the *foreground* netscape from rendering.
How many people really need this?
> And I don't care what
> bounds it, because I'm not here for the theoretical value. I need to
> get a job done, and I want the computer to wait for me, not vice versa,
> regardless of the circumstances or what else the computer might be
> programmed to believe is important.
>
> How trivial would it be to configure the scheduler on Linux to give
> whatever window is on top of my display a priority orders of magnitude
> greater than everything else (unless I change it, of course)? If this
> can be done, I'm going to want to do it.
>
> And I'm going to expect that all the software is going to continue to
> function without screwing up because they assumed I'd give them a fair
> shot at the CPU. From there perspective, it should look like they're
> just one of four million other processes that want time, right? How
> prevalent is it for typical programs to get "choked to death" by lack of
> CPU time? And how does a Mac manage to run a TCP/IP stack if CMT is so
> bad when it comes to background processes?
>
> Maybe I'm not as done with this topic as I thought...
>
Colin Day
------------------------------
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 20:58:54 -0400
Reply-To: [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; 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
>> >> [...]
>> >> >OTOH, we get Mac advocates claiming Windows doesn't have PnP because
>it
>> >> >doesn't work perfectly with non-PnP hardware.....
>> >>
>> >> Yes, but you also get PC advocates who claim that Window's proprietary
>> >> version of PnP has trouble with PnP hardware, as well as non-PnP
>> >> hardware.
>> >
>> >Please detail how Windows' PnP is "proprietry".
>>
>> That's a good one. LOL.
>
>I didn't think you could.
I didn't think you'd get it. LOL
--
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: 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 21:04:34 -0400
Reply-To: [EMAIL PROTECTED]
Quoting Christopher Smith from comp.os.linux.advocacy; Thu, 13 Jul 2000
[...]
>Max, you spend hours every day adding nothing useful to discussions, why
>should this be any different ?
That's even funnier than the bit about asking me to supply you with
details of a proprietary specification. At least considering I don't
have any interest in PnP technical specs, and considering that I post so
much verbose exposition that several have remarked (correctly) that I
must not have a life.
I could really have fun with you over in alt.destroy.microsoft. Let's
all go over there and watch me take apart trolls, OK? Note the
cross-post; followup set to adm.
--
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: 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 21:06:38 -0400
Reply-To: [EMAIL PROTECTED]
Quoting void from comp.os.linux.advocacy; 13 Jul 2000 02:21:44 GMT
>On Wed, 12 Jul 2000 21:09:09 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>>
>>That doesn't mean that PMT is
>>magically superior to CMT. Quite the opposite in fact. It means CMT
>>*is* superior, as I've stated, because it, rather than being a simple
>>archaic approach, requires cooperation from app vendors, 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. 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.
>
>You still haven't answered me: if this is the case, why is MacOS the
>only shipping CMT desktop OS, and why is Apple phasing it out in favor
>of a PMT operating system?
Because there are too many engineers who get too wacked out at the idea
of supporting *cooperative* application implementations on a user's
desktop system and can't figure out how to provide the necessary
functionality without going to PMT.
--
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: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: Linux code going down hill
Date: Thu, 13 Jul 2000 21:11:34 -0400
Jim Richardson wrote:
> On Wed, 12 Jul 2000 20:48:09 -0400,
> Colin R. Day, in the persona of <[EMAIL PROTECTED]>,
> brought forth the following words...:
>
> >Donovan Rebbechi wrote:
> >
> >> On Tue, 11 Jul 2000 16:57:15 GMT, [EMAIL PROTECTED] wrote:
> >> >In article <[EMAIL PROTECTED]>,
> >>
> >> >Ick, platform specific packaging utilities always suck. If anything,
> >> >they eliminate your control, and you often have to put the software
> >> >where whoever packaged it thought it should go.
> >>
> >> In the case of say RPM, the above statement is just plain wrong.
> >
> >Not in all cases. I once tried to install KDE somewhere else besides
> >/opt, and RPM would not do it. Some packages are not relocatable.
> >
> ><snip>
> >
>
> From the RPM manpage ...
>
> --badreloc
> To be used in conjunction with --relocate, this
> forces the relocation even if the package isn't
> relocatable.
Damn. I must have missed it, sorry.
Colin Day
------------------------------
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 21:13:47 -0400
Reply-To: [EMAIL PROTECTED]
Quoting [EMAIL PROTECTED] () from comp.os.linux.advocacy; Thu, 13
>On Wed, 12 Jul 2000 21:09:09 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>>Quoting [EMAIL PROTECTED] () from comp.os.linux.advocacy; Wed, 12
>>>On Tue, 11 Jul 2000 23:20:00 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>>>>Quoting [EMAIL PROTECTED] () from comp.os.linux.advocacy; Tue, 11
>>>> [...]
>>>>Are you willing to consider, Jedi, being what I know to be a very bright
>>>>and reasonable person, that the MacOS doesn't do this *wrong*, for its
>>>>purposes? Anyone who has ever been interrupted repetitively in the
>>>
>>> Nope.
>>
>>That's a shame. I though you would be willing to consider it, but I
>>suppose you're too close to the subject.
>>
>>> QNX is a great counterexample: genuine realtime OS.
>>
>>Never heard of it, and don't see what it has to do with desktop clients,
>>where a "genuine realtime OS" is generally not necessary or indicated.
>
> Sure it is. There are plenty of things end users want to do with
> tight time constraints. The obvious example would be multimedia
> file decoding in realtime.
So why isn't everyone using a realtime OS on their client desktop PCs?
> Thus BeOS, a more 'real' OS that came out of the MacOS user culture.
It has't quite "come out" yet, as far as I'm concerned. I've heard
quite a bit about it from technical fans, but its just another
proprietary OS for the PC, to me, and I'll have none of it, nor will the
market, I'm sure. After the experience with Microsoft, I'm pretty sure
that unless people aren't even smart enough to be morons, Linux is going
to be the standard desktop OS, as well as the standard everything else
OS, for the PC platform. And Apple will keep the Mac architecture, and
the Mac OS, and the Mac platform, and do with it whatever they desire,
and that's a good thing. I'm hoping quite a few more proprietary
*computers* are developed; not everything can be open from the start.
But we got this PC thing down, and Linux is a good enough OS to start
with, so I have nothing against the Mac, but BeOS isn't a "real" OS any
more than Windows is, regardless of its technical capabilities, AFAIK.
Others, of course, may differ; only the market gets to decide.
> All it takes is a situation where an end user (plus the system) want
> to do more than one thing where one or more of those tasks have very
> stringent responsiveness requirements.
No, it takes a user wanting to do *2* things, at least, that both have
very stringent responsiveness requirements. Unless, of course, the
engineers have built in stringent responsiveness requirements where they
aren't needed, because there isn't a human sitting there staring at them
waiting for them to get done.
Such a person is running what I would call a "workstation", not a
desktop client. They *might* benefit from PMT; they would definitely
benefit from better design of applications to remove unnecessary
responsiveness requirements (responsive to what, if not the user?)
--
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: "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 11:29:50 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Quoting ZnU from comp.os.linux.advocacy; Wed, 12 Jul 2000 04:44:14 GMT
> >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> [...]
> >> Better something in the background gets slower than my typing into my
> >> newsreader, you betcha, damn right. Whatever *I* am interacting with
> >> should have absolute first shot at every cycle it needs.
> >
> >Sure, but it doesn't work that way. The foreground app in a CMT system
> >will often to something like hog 75% of the CPU when it doesn't need
> >more than 2%, slowing background tasks to a crawl and not providing any
> >benefit at all.
>
> Once again, you are making an assumption that it doesn't "need" it
> because it doesn't use it.
That's a logical conclusion, not an assumption.
> Any second now the user is going to click
> the button that is going to make it "need" much much more than 2%, and
> on a client desktop it makes sense to have it for them, instantaneously.
In the days of 386/25s the amount of extra CPU time needed might have been
relevant, and noticable. Today when pretty much any desktop computer you
sit down at has CPU cycles to burn, an extra couple of nanoseconds that are
imperceptible to the user cannot justify the inherent lack of robustness in
a CMT system.
> The program the operator is interacting with should get ALL available
> CPU cycles unless IT decides to give them up.
This is terrible design from an engineering *and* usability point of view.
THe thing with CMT is that it's not the program being interacted with that
gets all the CPU time it can grab, it's whichever program happens to have
control of the CPU.
What you are advocating - the foreground application receiving somewhat more
CPU time than it needs "just in case" is already served by PMT systems. In
a vastly more efficient and robust manner, as well.
> Now, the reason this idea horrifies you software engineers, I believe,
> is because you can't for the life of you believe that one bad app won't
> screw the hole thing up.
There are decades of software engineering experience behind that belief. I
have yet to see any non trivial piece of software without "screwups".
The horrifying thing is not that one app *might* screw it up, it's that one
app *can* screw it up.
> Which is exactly why this is of value to the
> operator/user/consumer. One bad app *can* screw it up.
The mind boggles at why anyone could possible think that the potential for a
single misbehaving application or elementary programming error (say, an
infinite loop) could result in the loss of every piece of user data that has
been modified since they last saved it is in any way a good thing.
> Which is why
> cooperation is required of the vendors, as well as the code.
It still couldn't be feasibly done. It would require every application
vendor to tune their application to run with every possible combination of
applications.
Application vendors can't even agree on file formats, and you serioulsy
think this is even remotely possible ?
> Leaving
> this "gaping hole" that scares you guys so much is actually a mandate
> that *nobody* right bad software which hogs the CPU unnecessarily.
Well written software can, will and does cause problems in a CMT
environment. It's simply an inherent problem with using that scheduling
scheme on a general purpose system.
> In a
> PMT system (though the cases, of course, can't really compare), that one
> app that takes 75% when it *really* only needs 2%, is still going to get
> its 75%, even when it *isn't* the focus of the user's attention.
You are describing a CMT system, not a PMT system.
> >Worse, when the foreground app yields, which any well
> >written app does constantly, any other app can grab and hog the
> >processor for as long as it wants, totally locking out the foreground
> >app. This happens all the time.
>
> "If". The phrase is "if the foreground app yields". ;-)
>
> Again, this happens all the time. It gets fixed all the time, too.
How can it be fixed ? It's an inherent problem in the scheduling method.
> The
> user, again, not theory, should decide if that is desirable.
This isn't "theory", as you seem so keen to dismiss it as. This is time
tested *practice* and *experience*.
> One bad
> apple can spoil the bunch is a good thing.
No, it is a critical flaw in the system.
> Its the only way you can be
> sure you have a good bunch, instead of just a good apple.
It does no such thing. It just means you have an inefficient, unresponsive
system
> >For example, if I'm typing in MT-Newswatcher and Internet Explorer loads
> >a complex page in the background and starts rendering it, MT-Newswatcher
> >will totally freeze up for several seconds.
>
> That happens to PC users, to.
Time to trade in that 386.
> >In a well designed PMT
> >system, I wouldn't even notice when IE started rendering. Could this
> >situation be improved if IE yielded the processor during rendering?
> >Sure, but you can't count on that.
>
> I don't need to count on it. I can verify it. You're just illustrating
> why IE sucks, not why CMT sucks.
No, it's a perfect example of why CMT sucks.
The *operating system* should be in control of the hardware, not the
applications.
You can only write apps that will co-operate if you can test and tune them
with every app they are supposed to co-operate with - there is simply no
other way.
> >The amount of processor time an app should yield depends on what else
> >the system is doing, which is something the app can't know.
>
> The amount of processor time an app should yield depends only on what
> the *user* is doing. These are not servers! They are not shared hosts!
This has been patently untrue ever since DOS was retired.
> There is no reason whatsoever to make *my* use of the software, *my*
> process, whatever is taking up my time and attention *now*, to be
> absolutely the fastest possible thing on the computer.
If your machine is only running a single process, that might be true.
However, as noted above, that concept went out with DOS.
> >Virtually every PMT system allows priorities to be assigned to tasks.
>
> Virtually no desktop client-only users have interest in dealing with
> such intricacies, or need to.
Which is why we have (and have had for a very long time) dynamic scheduling
algorithms that change priorities as necessary, depending on the scenario.
Such algorithms are one of the differences between NT Workstation and NT
Server - it's why Server is slower for interactive use (at the console).
You don't have a clue what you're talking about, Max, and it shows.
Take a few hours out of your life to read up on some basics of OS design and
in particular, CPU scheduling. You will find all your gripes and
hypothetical problems have already been addressed many, many years ago.
> >You just need to give user interaction tasks very high priorities, so
> >the system remains responsive under load.
>
> We do. Its called CMT. :-)
CMT is the *least* responsive under load.
> >Not worse, but much more avoidable. Modal dialogs aren't a bug or a
> >malfunction, they're just bad design for a multitasking system; they
> >require the user to deal with whatever they're asking RIGHT NOW, even if
> >the user is off doing something else in another app.
>
> Yes, that's the point. Because in a CMT system, an app should only use
> a modal dialog when the user has to deal with whatever they're asking
> RIGHT NOW, even if the user is off doing something else in another app.
> Not all dialog boxes are modal; few should be, in fact. Probably many
> fewer than are now. But that is a separate argument, and must examine
> the details of the case. In general, CMT with modal dialogs is a
> superior system for a desktop client system than PMT.
No, it is not.
> >Maybe this makes
> >sense for some things ("Your computer will explode in 15 seconds!"), but
> >I see no reason why you shouldn't be able to put "You have new mail" in
> >the background and deal with it when it's convenient for you. "The user
> >should always be in control" is one of the basic tennets of the
> >Macintosh philosophy, after all.
>
> I would never in my life expect a "you have mail" dialog to be modal,
> and would fault the app, not CMT, for the inconvenience. Just as, on
> Windows, I fault the OS for PMT (well, and the desktop shell, because it
> does it *so* badly), not the apps, because they're not the ones that
> determine if a dialog pops up in the middle of my work.
Eh ? If an app decides to pop a dialog to the top of the window stack
there's nothing the OS can do about it (or should). The problem is in the
apps, not Windows.
> Maybe its this automatic assumption that PMT is always superior and CMT
It's not an "automatic assumption", it's a *conclusion* made from a great
deal of problem solving, experience and engineering.
> is archaic that is why all those Mac developers are too clueless to use
> modal dialogs efficiently on a desktop client system.
There is no efficient way of using modal dialogs. They just get in the way.
------------------------------
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 01:24:57 GMT
In article <[EMAIL PROTECTED]>,
Hyman Rosen <[EMAIL PROTECTED]> wrote:
>The FSF would be terribly foolish to try to enforce a RIPEM policy in
>court. They would surely lose, and do great damage to the GPL. If the
>FSF ever decides to sue over the GPL, it will be over a blatant
>violation, not a subtle one.
Surely you have no clue what the FSF is or does or can do. Hint, hang
around here for another decade or two, hang around the FSF's lawyer
in court, watching him loose the first round of a case, undeterred,
fully prepared to go to the Count of Last Resort if necessary, spend
time with rms talking about stuff.
After you do this, then come back here with another assessment. I'd
be curious to see if it differs from your original one.
:-)
------------------------------
From: Aravind Sadagopan <[EMAIL PROTECTED]>
Subject: Re: Web Browsers?
Date: Thu, 13 Jul 2000 21:31:11 +0800
Reply-To: [EMAIL PROTECTED]
Why dont you try opera ..its still in beta but good enough
aravind
Bob Hauck wrote:
> On Thu, 13 Jul 2000 17:24:22 -0500, Christopher S. Arndt
> <[EMAIL PROTECTED]> wrote:
>
> >I have tried mozilla, but it really take a lot of memory, and is always
> >crashing, as does netscape 4.x and 6.x.
>
> Turn off java in Netscape and see if that helps. Also, 4.73 and 4.06
> have been pretty reliable for me (even with java).
>
> --
> -| Bob Hauck
> -| To Whom You Are Speaking
> -| http://www.bobh.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
******************************
