Linux-Advocacy Digest #631, Volume #27 Wed, 12 Jul 00 22:13:06 EDT
Contents:
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linux lags behind Windows (Andres Soolo)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Are Linux people illiterate? (Mike Marion)
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: I hope you trolls are happy... (Jim Broughton)
----------------------------------------------------------------------------
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: Wed, 12 Jul 2000 21:09:09 -0400
Reply-To: [EMAIL PROTECTED]
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.
> The difference here being control and the ability to actually
> garauntee and verify the results you are seeking. A "lets all
> play nice" design philosophy just doesn't do that.
No, but you don't need to do that on a client desktop, where control and
the ability to verify results are inseparable, since the User staring at
the screen is doing both, simultaneously, interactively, and
continuously. We don't need the computer to second guess us about it,
even if we're 'clueless end users'.
> The same goes for UI design. If it's good enough to be a part
> of some "one true UI", it should be encoded into the enviroment
> such that potentially malicious or stupid individuals can't muck
> it up.
Not very flexible, kind of puts a damper on innovation and adaptation,
doesn't it? Yes, all software should be firmware should be hardware.
The world would be a better place, then. ???
[...]
> What the MacOS does was an engineering tradeoff for a more
> austere time and partially an issue of legacy support. One
> doesn't need CMT in order to suddenly pollute the user's
> display with messages or to assign them some heightened
> priority. Infact, a system with a real executive of some sort
> in control would be far more effective in delivering this sort
> of thing.
Nothing is ever entirely dependant on anything else when you're dealing
with software; its pretty mutable. 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.
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.
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
[A corporation which does not wish to be identified]
[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: Wed, 12 Jul 2000 21:28:02 -0400
Reply-To: [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. 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.
The program the operator is interacting with should get ALL available
CPU cycles unless IT decides to give them up.
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. Which is exactly why this is of value to the
operator/user/consumer. One bad app *can* screw it up. Which is why
cooperation is required of the vendors, as well as the code. Leaving
this "gaping hole" that scares you guys so much is actually a mandate
that *nobody* right bad software which hogs the CPU unnecessarily. 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.
>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. The
user, again, not theory, should decide if that is desirable. One bad
apple can spoil the bunch is a good thing. Its the only way you can be
sure you have a good bunch, instead of just a good apple.
>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.
>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.
>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!
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.
>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.
>You just need to give user interaction tasks very high priorities, so
>the system remains responsive under load.
We do. Its called CMT. :-)
>> Because it doesn't make any sense, when the primary
>> purpose of a computer is to provide a user interface, that that user
>> interface, and whatever interaction the user is executing, should always
>> have first dibs. Modal dialogs aren't any worse than BSOD or cascading
>> segmentation faults.
>
>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.
>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.
Maybe its this automatic assumption that PMT is always superior and CMT
is archaic that is why all those Mac developers are too clueless to use
modal dialogs efficiently on a desktop client system.
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
[A corporation which does not wish to be identified]
[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: Andres Soolo <[EMAIL PROTECTED]>
Subject: Re: Linux lags behind Windows
Date: 13 Jul 2000 01:32:41 GMT
Nathaniel Jay Lee <[EMAIL PROTECTED]> wrote:
> Since I think we are both coming at this from different areas, I will
> bow out of this conversation. In the Hyperion novels, the computers act
> as humans. As this is where this conversation started, this is what I
> am basing my side of the conversation on. You are basing yours on what
> could happen in the real world (as it appears at least). We are
Partially, yes. But my concept of sentient machines is pretty much formed
by vision of another sci-fi writer, Isaac Asimov. Then again, his robots
are of a most realistic kind I've found in sci-fi literature.
> In all actuallity I would hope we have enough common sense to build in
> some sense of *right and wrong* much like most (some? a few?) humans
> themselves have so that the computers don't assume they need to
We'll probably do. But then again, mistakes are human; on the third hand--
coming back to sci-fi--we'll might as well encounter a bunch of robots not
made by human beings :-) Well, interacting between such robots and humans
wouldn't probably be `intuitive' to eithr side.
> eliminate humanity or rid themselves of them. In reality, this would
> only make sense. But it's a long time before computers are actually
> this advanced. And I don't know what will actually happen by then.
With luck, the first practical Quantum Computers will ready in 2020s, so
that long time might be even shorter than a human lifespan.
--
Andres Soolo <[EMAIL PROTECTED]>
Fidelity, n:
A virtue peculiar to those who are about to be betrayed.
------------------------------
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: Wed, 12 Jul 2000 21:38:58 -0400
Reply-To: [EMAIL PROTECTED]
Quoting void from comp.os.linux.advocacy; 12 Jul 2000 05:12:33 GMT
>On Wed, 12 Jul 2000 04:44:14 GMT, ZnU <[EMAIL PROTECTED]> wrote:
>>
>>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. Thus, CPU
>>time should be allocated by the system.
>
>Well put.
But it isn't the app that is supposed to know; it is the user, and they
know, because its what they're working on.
>>The needs of a desktop system
>>are different than those of a multiuser system or a server, of course,
>>but PMT still wins out, it just needs to be tuned differently (e.g.
>>things like user input need to be giving high priorities).
>
>A modern scheduler is sufficently self-tuning to work well on servers or
>desktops without modification. When my FreeBSD machine runs its nightly
>2 am maintenance scripts, I can only tell if I'm physically present to
>hear the disk drive's noises.
All right, so I've been overstating the case. But when somebody says
that something which has been successful in the market does something
"wrong", I can't help but notice that they have to be making
assumptions. The fact is, it *did* make sense at the time, and changing
to PMT on the Mac would still not make a lot of sense. You don't *run*
nightly 2 am maintenance scripts on a Mac, and if you did, you probably
wouldn't be around to notice either way. Or so the thinking goes, and I
haven't heard anything to suggest that it isn't perfectly valid within
its context.
>>Virtually every PMT system allows priorities to be assigned to tasks.
>>You just need to give user interaction tasks very high priorities, so
>>the system remains responsive under load.
>
>It tends to do that anyway, because interactive tasks spend a lot of
>time waiting for user input, which causes them to accumulate priority.
Which may, indeed, be the exact *opposite*, again, of what is called for
on a desktop client system. If I have twelve apps waiting for user
input, it is because I want them to wait. I don't want them to slow
things down by increasing their priority; it isn't *that* kind of
"scheduling". This isn't my todo list, where things should rise to the
top of their own accord.
The software I'm interacting with has absolute priority, at all times,
as far as I am concerned. Anything else is bad design for a desktop
system.
Not a show-stopper, necessarily, and of course it doesn't have *as much*
importance on a modern super-desktop, and probably even less when you're
dealing with a desktop/host. But I still think it is important, and
would like to see the issue more directly addressed in practical ways,
rather than theoretical ones.
Let me close with yet another mea culpa. Because of my own experience
and inclinations, I have been arguing from the perspective of Windows
PMT, not Linux's. I have noticed that the situation is not entirely
alien to a Unix desktop (Solaris and HP, anyway), but it certainly isn't
anywhere near as bad.
--
T. Max Devlin
Manager of Research & Educational Services
Managed Services
[A corporation which does not wish to be identified]
[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: Mike Marion <[EMAIL PROTECTED]>
Subject: Re: Are Linux people illiterate?
Date: Thu, 13 Jul 2000 01:46:17 GMT
Brian Langenberger wrote:
> Your punctuation needs work. Also, the phrase "you all" is redundant,
> unless you're from the southern U.S.
No, no, no. The correct spelling in the south would be y'all. :P
--
Mike Marion - Unix SysAdmin/Engineer, Qualcomm Inc.
UNIX - live it,love it,fork() it !
------------------------------
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: Wed, 12 Jul 2000 20:48:45 -0500
On Wed, 12 Jul 2000 21:28:02 -0400, T. Max Devlin <[EMAIL PROTECTED]>
wrote:
>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. 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.
>The program the operator is interacting with should get ALL available
>CPU cycles unless IT decides to give them up.
Your arguments about CMT vs PMT seem rooted in the 1980s. It's really
amazing to hear someone talk like that in this day and age.
Previously that was the domain of uneducated Maccies, for the most
part. I thought I'd heard it all from them - the Mac CPUs weren't
fast enough was a big on in the late '80s and early '90s; they just
couldn't believe when an Amiga with the same processor could do
compared to a Mac.
>Again, this happens all the time. It gets fixed all the time, too. The
>user, again, not theory, should decide if that is desirable. One bad
>apple can spoil the bunch is a good thing. Its the only way you can be
>sure you have a good bunch, instead of just a good apple.
So you go with PMT, and you don't need to worry about such things.
>>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.
Nope, assuming W2k/WNT. It's been a while since I've heavily used
W98SE, but I don't think it happens there either.
>>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.
The problem isn't IE. It's the CMT system as a whole.
>>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.
Yeah, and if the user is doing a big render in the bg, he or she
shouldn't need to have the mouse sitting there, idle, doing nothing
while the rendering program runs.
A CMT system (well, MacOS) forces this on you. A PMT system (well,
Unix, NT, W2k, W98) doesn't. That's a major difference.
>These are not servers! They are not shared hosts!
>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.
Absolutely, if that was a CPU constraint. But you haven't illustrated
that.
>>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 moderm PMT systems can also handle it well dynamically.
>>You just need to give user interaction tasks very high priorities, so
>>the system remains responsive under load.
>
>We do. Its called CMT. :-)
LOL.
>>> Because it doesn't make any sense, when the primary
>>> purpose of a computer is to provide a user interface, that that user
>>> interface, and whatever interaction the user is executing, should always
>>> have first dibs. Modal dialogs aren't any worse than BSOD or cascading
>>> segmentation faults.
>>
>>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.
Modal dialogs are bad.
>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.
How? It's slower, it can't adjust to what the user wants, it was made
as a crutch before multitasking systems became commonplace. Why would
anyone WANT CMT?
>>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.
>
>Maybe its this automatic assumption that PMT is always superior and CMT
>is archaic that is why all those Mac developers are too clueless to use
>modal dialogs efficiently on a desktop client system.
Can you give an example of a commonly used *good* CMT system? The Mac
certainly isn't one; are there any?
------------------------------
From: Jim Broughton <[EMAIL PROTECTED]>
Subject: Re: I hope you trolls are happy...
Date: Wed, 12 Jul 2000 21:54:10 -0400
Reply-To: [EMAIL PROTECTED]
Brian Langenberger wrote:
>
> Jeff Szarka <[EMAIL PROTECTED]> wrote:
> : On 30 Jun 2000 18:44:10 GMT, Brian Langenberger
> : <[EMAIL PROTECTED]> wrote:
>
> :>I went out and bought a nice Logitech PS2/USB one, plugged it in,
> :>adjusted a couple of config files and had no trouble since.
>
> : No... There is where you are wrong. You're not susposed to edit any
> : config files. As far as I'm concerned, Linux does not support wheel
> : mice unless they just work.
>
> : Windows has been doing this for many years now.
>
> Ahh, this must be a definition of "work" of which I was not
> previously aware. If we take this definition to its logical
> extreme, we get:
>
> User: "Why doesn't Office work in Windows?"
> Tech: "Did you put in the CD?"
> User: "No, and I shouldn't have to. It should just work!"
>
> Fortunately, most people have a very different definition
> under which wheeled mice fall very nicely under Linux.
The last message on this thread is July 7 but what the hey.
Installing the wheel mouse with RedHat 6.1. with updated
X11r6 version 4.0 using KDE 1.1.2
install imwheel.rpm (not its full filename) from redhat cd.
add line ( option "ZAxisMapping
" "
4 5" ) to mouse section of
XF86config file in /etc/X11 directory. Do not include the parens.
start KDE find IMWHEEL executable with the
KDE File manager and drag and drop the imwheel
file into the KDE autostart folder.
Exit KDE completely and restart. NOTE restart KDE only do
NOT reboot the system.
Walla. Three button mouse with functional wheel.
Total time 5 minutes.
Installing wheel mouse with MS winbloat98
Select add new hardware in control panel.
Choose device from a list. Select MS intellimouse with wheel.
This is what I get for buying OEM parts Instead of retail packs.
I have since gotten a logitec optical mouse. retail (metalic dark blue
finish)
Insert Windows 98 CD. System gets drivers.
System installs software and then needlessly calls
for you to reboot system.
After reboot wheel still does not work WTF.
After thinking about problem for 2 minutes.
Check system applett in control panel.
It lists 2 mice. Great. Click on your new wheel mouse listed
in system applett. This device is currently not
active. Would you like to make it active. Click HELL YES!
You must reboot in order for the changes to take effect.
Reboot now (no) (yes) HELL YES!
Reboot number 2 now complete.
The wheel mouse is now only mouse listed in control
panel system applet. And the damn wheel now works.
total time 20 minutes.
If this had happend to a NEWBIE he would
have been plenty pissed. Finding and fixing the problem
would have been beyond his/her knowledge and experience.
As it was It happend to someone used to windows.
And I was still pissed. Granted the Inclusion and
setup of the wheel in linux is not readily aparent but
it is documented and it takes next to no time to install.
And best off all you dont have to reboot 2 times.
JIM
------------------------------
** 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
******************************
