Linux-Advocacy Digest #707, Volume #27 Sat, 15 Jul 00 23:13:05 EDT
Contents:
Re: Korean Linux ("Colin R. Day")
Re: Linsux as a desktop platform (ZnU)
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform (ZnU)
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
Re: one step forward, two steps back.. ("Colin R. Day")
Re: Linsux as a desktop platform (T. Max Devlin)
Re: Linsux as a desktop platform (Gary Hallock)
Re: Linsux as a desktop platform (Bob Hauck)
Re: Linsux as a desktop platform (Gary Hallock)
Re: Richard Stallman's Politics (was: Linux is awesome! (Jay Maynard)
Re: Web Browsers? (M. Vogelgesang)
----------------------------------------------------------------------------
From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: Korean Linux
Date: Sat, 15 Jul 2000 21:53:25 -0400
David Brown wrote:
> Does anyone know what Linux distributions are best for Korean speakers? I
> know that many distributions have at least some support for Korean, but
> there must be some that have more Korean support than others. Does anyone
> have any pointers to appropriate websites, either of distributions or Korean
> linux sites? Failing that, I would also be interested in Chinese (written
> Korean and Chinese have a lot in common, so there might be a fair amount of
> overlap) or Japenese (my Korean friend also speaks Japenese).
www.turbolinux.com
Colin Day
------------------------------
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: Sun, 16 Jul 2000 01:57:11 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Said ZnU in comp.os.linux.advocacy;
> >This is a constant issue. Every app yields essentially according to the
> >whims of whoever designed it (one of those clueless engineers you seem
> >to hate so much), with no regard for whatever other processes might be
> >running. A CMT system making efficient use of CPU time is the exception,
> >not the norm.
>
> Efficient according to whose definition? If you're going to say 'there
> is only one', then I'm going to be forced to accuse you of "thinking
> like an engineer".
Efficient according to anyone using the system. A PMT system allows
background tasks to proceed at almost full speed (on a CPU with some
idle time) while simultaneously ensuring that the system remains
responsive. A CMT system not only slows background tasks to a craw, but
also fails to keep the system responsive.
Under full load, the difference is even greater.
> There is another, the Mac used it, apps *did* "behave properly", and
> the system worked.
I'm using a Mac right now. You're not. Who do you think is more
qualified to comment on the Mac's multitasking performance?
> That the "next generation Mac OS", which has passingly little to do
> with the original Mac OS, does not use it is *not* an assumption that
> CMT doesn't work; it does and it did.
Nobody said it didn't work. Just that it worked _badly_.
> And there is some reason to believe, whether you can understand it or
> not, that it provided efficiencies that were vastly under-utilized,
> simply because of the limited development that CMT was given, since
> every engineer apparently were taught in school to think that it is
> really bad idea.
Every "engineer" understands exactly why it is a bad idea. And has
explained it to you. This isn't just something people go around blindly
parroting because they're closed minded.
There are no efficiencies inherent in the CMT approach that apply to
general purpose multitasking desktop operating systems. There are
several serious deficiencies.
--
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: 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: Sat, 15 Jul 2000 22:01:43 -0400
Reply-To: [EMAIL PROTECTED]
Said Ray Chason in comp.os.linux.advocacy;
>T. Max Devlin <[EMAIL PROTECTED]> wrote:
>
>>No. Can you find a way to make PMT as user-responsive as CMT? Then all
>>you're doing is implementing CMT. The result is the value, not the
>>process. I don't care *how* you do the scheduling. As long as whatever
>>program I'm working in has, as far as I am concerned 100% of the
>>available time to keep up with me, even if it spends a lot of that time
>>waiting. Of course, background processes shouldn't be ignored, but they
>>only rarely have true priority.
>
>You seem to assume that your current app needs, say, 90% of the CPU to
>respond quickly to user input. That just isn't so; a process that is
>waiting for a mouse click doesn't need the CPU at all. What it needs,
>rather, is priority. It needs the privilege of telling some other process
>to get off the CPU.
I know; that's the whole point. In PMT terms, the "performance" of a
process is a measure of how much CPU time it gets. But response isn't
predicated on performance in this regard. It is when, not how much, CPU
time an app can get which is the decisive factor. In simple
implementations, this is a notable weakness. But that doesn't mean it
is never an issue. It isn't the app which has the "privilege" of
telling some other process to get off the CPU, it is the scheduler.
Neither is more cognizant of why the process might need to be *on* the
CPU, though, although a scheduler does have many other pieces of
information at its disposal with which to make the decision. But none
of them could possibly be as decisive as *why* the process is on the
CPU, and that, is ultimately, the issue, and why both the user and a CMT
system may disagree with the scheduler as to which process should use
the next CPU timeslice, whether both user and CMT would agree or not.
>In a PMT system, that can happen at any time. In a CMT system, that can
>happen only when the other process is good and ready. CMT effectively
>assigns top priority to whatever process happens to be running, whether
>it's your current app or not.
Yes, I know. But at least it assigns the app, not the scheduler, the
ability to make that determination. An app is not aware of what else is
running, necessarily. That doesn't mean it has to be ignorant.
Something more adaptive than a scheduler, but more controlled than a
daisy-chain, might be called for.
>Assignment of priority is by a simple rule: Processes that mostly wait
>(I/O bound) get higher priority than processes that mostly do (CPU bound).
>This is contrary to intuition, yes, but to do it the other way starves the
>I/O bound process -- leading to the very complaints of unresponsiveness
>that you raise here, since interactive applications are I/O bound almost
>by definition.
Yes, I caught that. On first reading, it does seem counter-intuitive.
Is there a high correlation between this low-level cycling and the UI
response, though? I assume it is safe to have I/O bound processes have
higher priority simply because I/O is the bottleneck; even when the
waiting is over, its going to start again and last a while.
Why not give priority to a single very high I/O bound process which
mitigates between all the other I/O bound processes, freeing the bulk of
the cycling for the higher load of the CPU bound stuff when it is
appropriate? Would that increase the UI response without wasting cycles
waiting for I/O from processes which are waiting because of the I/O
bottlenecks inherent in the system, or slow down I/O bound processes
that aren't? Would such a mitigating program be able to balance the
needs of the CPU load with the different I/O bottlenecks?
I can't believe that, if there is really so much magnitude of difference
in time-frames between UI work and CPU cycles, even a modern Unix system
becomes very slow on the human level when the CPU loading gets high. I
realize it is a trade-off and that problems can occur if non-UI
functions are not performed in a timely and regular manner. But again,
those slices are small, and my perception is large; isn't there any way
to understand the difference between slowing down what the computer is
doing and slowing down the computer's operation? It seems, as often
happens, that the goal of raising the average may need to be balanced
with the ideal of raising the peak. That this might ultimately be
considered a PMT or a CMT or an RT or even an ODMT (on demand
mutli-tasking, which I just imagined) system is academic, in my view.
--
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: 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: Sun, 16 Jul 2000 02:04:18 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
[snip]
> I was under the impression that this is what I had, by way of these
> advocacy groups, yes. Imagine my surprise when I get ridiculed, not for
> being so clueless as to ask questions, but for knowing enough to ask
> them in ways that contradict the easy answers.
You are getting ridiculed for asking questions, receiving answers,
dismissing the answers on no solid grounds, and then asking the
questions again.
It also doesn't help that you continually insist everyone who disagrees
with you is some kind of narrow-minded specialist who refuses to
question assumptions. PMT's superiority for general purpose multitasking
desktop operating systems is not an assumption, it is a logical
conclusion that anyone who understands the issues will come to, and it
is one that holds up very well in the real world.
[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: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Sat, 15 Jul 2000 21:07:24 -0500
On Sat, 15 Jul 2000 20:43:28 -0400, "Colin R. Day"
<[EMAIL PROTECTED]> wrote:
>Christopher Smith wrote:
>
>> "John Jensen" <[EMAIL PROTECTED]> wrote in message
>> news:8kn61l$bk7$[EMAIL PROTECTED]...
>> > John Jensen <[EMAIL PROTECTED]> writes:
>> > : Christopher Smith <[EMAIL PROTECTED]> writes:
>> >
>> > : : I would have thought, wrt to hardware resources, it had more to do
>> with the
>> > : : amount of CPU grunt available - wouldn't the overhead of a PMT
>> scheduler
>> > : : have a quite noticable impact on a GUI OS with such a slow CPU ?
>> >
>> > I should have said, as someone who had been assembly programming 8080s
>> > running a 1 MHz, a 8 MHz 68000 did not seem remotely slow ;-).
>>
>> But to run a GUI system like the Mac ?
>
>On my computer, X is taking up about 1-2% of a 233 MHz CPU, with spikes
>when I change virtual desktops (Did/does Mac have those?) That's about
>2-5 MHz (although I don't know how that scales).
At what resolution and what color depth? The Amiga managed a GUI and
PMT very well in 1985, but back then things were very different - with
512k you could easily 'get' a full-featured (for the time) BBS
terminal (remember those? ANSI-terminals for your modem? Run by
private individuals, often out of a spare room in their house, with
all of one (!!) phone line?) complete with ZModem and fairly decent
scripting, and have about 220k or so left over for 'other stuff'. If
you wanted the GUI, there went 80k; I chose to use the GUI only when
initially learning AmigaOS; after that I needed the RAM more than the
GUI until I moved up to a full 1.5MB. Oh, and the "GUI" as it was was
very simple - a program loader and file renamer and place to edit and
change preferences, and not a whole lot more; it looked a lot like
System 6 without control panels (or whatever they were called back
then). It ran at 640x200, overscanned to around 660x225 or so, and
ran in 4 colors (the GUI, that is - programs could use 16 colors or
4096 colors, and up to 724x480 or so resolution, albeit going >400 let
to horrid interlacing on the early Amiga models). And we liked it.
:) Seriously, it blew away anything else at the time in many
respects.
CPU chip speed didn't enter into the picture. It just wasn't an
issue. RAM was the issue. This was in the era of floppy disks, too -
file compression programs (to compress-as-executable) were popular; I
remember having a CLI program that (when I had a full (wow!) 1.5M of
RAM) loaded an entire floppy disk of programs and things into RAM,
assigned RAM: as my system directory, and at that point I really
didn't need the floppy disk anymore, which made things significantly
faster. It was amazing what fit on a floppy in 1986 or 1987.
It wasn't until the 14.4k modems came out (1988 or so? 1990?) that it
became obvious a CPU boost was needed (in order to multitask without
getting errors when downloading at 14.4k - it never ceased to amaze me
that a Mac with double or triple the CPU horsepower just couldn't
reliably do that!) but otherwise, it was a very nice, fast, and
efficient system. Incredibly spartan by today's standards, of course,
but it worked well, fast, and cheap.
------------------------------
From: "Colin R. Day" <[EMAIL PROTECTED]>
Subject: Re: one step forward, two steps back..
Date: Sat, 15 Jul 2000 22:10:30 -0400
[EMAIL PROTECTED] wrote:
> >Desktop domination?-- it's a LONG way off, if at all. And I think that's a
> >good thing for Linux. And computer users in general.
>
> My PERSONAL opinion is that Linux should focus on the server/technical
> user market and should forget going for the desktop.
>
But Linux isn't a single company. Should the KDE people drop KDE
and write server code?
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: Sat, 15 Jul 2000 22:11:39 -0400
Reply-To: [EMAIL PROTECTED]
Said The Ghost In The Machine in comp.os.linux.advocacy;
[...]
>However, at least the kernel has the option of forcibly moving
>things around; on a pure CMT system, this isn't really possible.
So would you say that a suggestion might be warranted that it might be
feasible and beneficial to consider making it unnecessary, as well as
impossible, instead of simply taking the opposite approach of making it
possible?
--
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! ======
------------------------------
Date: Sat, 15 Jul 2000 22:11:45 -0400
From: Gary Hallock <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
"T. Max Devlin" wrote:
>
> Yes, I know. But at least it assigns the app, not the scheduler, the
> ability to make that determination. An app is not aware of what else is
> running, necessarily. That doesn't mean it has to be ignorant.
> Something more adaptive than a scheduler, but more controlled than a
> daisy-chain, might be called for.
>
WRONG. With CMT, it is not the app that needs the cpu now that determines
when to get control, it is the OTHER app that currently has control that
determines when to give up control. In other words, it is the wrong app that
has the power. Can't you see that? With PMT it is precisely the opposite,
assuming the app that needs control has a higher prioriy - which it will if it
is a user interface request that causes to app to need to gain control.
Gary
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Reply-To: bobh{at}haucks{dot}org
Date: Sun, 16 Jul 2000 02:15:00 GMT
On Fri, 14 Jul 2000 16:35:14 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>Said Bob Hauck in comp.os.linux.advocacy;
>>On Thu, 13 Jul 2000 21:13:47 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>>
>>>So why isn't everyone using a realtime OS on their client desktop PCs?
>>
>>Because most current desktop systems were not designed for multimedia.
>>They originated before multimedia became popular. Realtime features
>>are not easily "tacked on" after the fact, although there are packages
>>for both NT and Linux that "slide a realtime OS underneath".
>>
>>There are also disadvantages to realtime systems for desktop use that
>>are similar to the disadvantages of CMT systems.
>>For home entertainment, it certainly would be appropriate to have
>>realtime features in the OS.
>
>But I don't think it is appropriate to have home entertainment in the
>OS. Fantasies of consolidating all home electronics equipment into the
>PC itself are counter-productive. I want my PMT (which should look like
>CMT to me, both magically and automagically) computer to interface with
>my RT DVD player, not *be* my DVD player.
Oh, sure, I can agree with that. A computer, which we can take to mean
a desktop workstation that can run user-installed mass-market software,
should probably not run a realtime OS. It might be appropriate to make
sure that the OS does not make things unnecessarily bad for multimedia
by, for example, minimizing kernel latencies. But a full realtime OS
might bring more disadvantages than advantages for general use.
On the other hand, it would be appropriate to have such for the DVD
player and the TV set themselves, environments where the designer can
control what software will be running. More and more embedded devices
actually do have operating systems these days you know. And many of
them are sprouting computer-like interfaces such as on-screen menus.
If you want to be able to talk on the network and have some sort of user
interface beyond pushing some buttons on the remote, having an OS makes
the product much easier to design and debug. The fact that 32-bit
chips and memory are getting really cheap makes the additional overhead
negligible compared to the benefits.
>I'll go further to say that I think anyone who maintains the fantasy of
>wanting their OS to be realtime for home entertainment purposes has
>simply based their expectations on an assumption proffered by the
>manufacturers that this would be a good thing.
I think the manufacturers would like to sell a special "home
entertainment computer" with some kind of realtime OS. This might
actually make sense for the consumer too. The interface could be
specialized for multimedia and the device would not need to run
off-the-shelf software, minimizing administration. I visualize a sort
of "multimedia appliance".
I'm not competent to comment on the legal issues you raise. It does
seem though, that there is a developing market for specialized
computing devices that deal with the problems of a particular niche.
Email appliances, entertainment, internet gateways, and so on. Each of
these could benefit from some amount of customization of the OS that
controls them.
>There's a difference between "I want my MTV", and "I want my MTV along
>with 14 other channels in a package with bloated a la carte pricing, if
>any at all is available to begin with".
Isn't that what we already have?
>If you want to know if Linux makes a good desktop platform, look to the
>*real* market requirements, not the technical ones, or the *marketing*
>requirements.
There is more than one "market" on the desktop. The requirements of an
engineer doing finite-element analysis are different from those of a
secretary are different than those of a home user who wants to write a
letter to grandma. I don't think any one configuration of one OS can
fulfill them all.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.bobh.org/
------------------------------
Date: Sat, 15 Jul 2000 22:16:54 -0400
From: Gary Hallock <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
"T. Max Devlin" wrote:
> Said The Ghost In The Machine in comp.os.linux.advocacy;
> [...]
> >However, at least the kernel has the option of forcibly moving
> >things around; on a pure CMT system, this isn't really possible.
>
> So would you say that a suggestion might be warranted that it might be
> feasible and beneficial to consider making it unnecessary, as well as
> impossible, instead of simply taking the opposite approach of making it
> possible?
>
Gibberish. Look, if you are trying to suggest that a CMT system could be
designed to allow forcibly moving thongs around, then no that is not
possible. Why, you ask? Because it would require preempting processes
which, by definition, is not CMT.
Gary
------------------------------
From: [EMAIL PROTECTED] (Jay Maynard)
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: 16 Jul 2000 02:22:53 GMT
Reply-To: [EMAIL PROTECTED]
On 15 Jul 2000 18:45:19 -0500, Leslie Mikesell <[EMAIL PROTECTED]> wrote:
>It is actually the pseudo-PD restrictions that are incompatible
>with the GPL that keep it free. Otherwise anyone would be
>able to slap a GPL on it and force any new additions to
>be GPL'd (or prevent getting any from people who don't want
>their work to be GPL-restricted).
Ah, but you see, Leslie, GPVists don't understand that it's valid for folks
not to want their work to be GPV-restricted. They think (as has been posted
in this very thread) that those who favor non-infective licenses just want
to shill for the proprietary software industry. They don't understand the
concept of a developer actually wanting to make his code available for free,
to *everyone*, no matter what he wants to do with it, so they just slam
those who favor such a concept as wanting to steal others' work and profit
from it.
------------------------------
From: M. Vogelgesang <[EMAIL PROTECTED]>
Subject: Re: Web Browsers?
Date: Sun, 16 Jul 2000 04:14:34 +0200
On Fri, 14 Jul 2000 00:00:39 GMT, [EMAIL PROTECTED] (Bob
Hauck) wrote:
>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).
I simply had the opposite experience.
Netscape 4.72 (glibc 2.0 version) is very unstable if I have java and/or
javascript disabled. And netscape fills up all my RAM.
Examples: www.webwasher.com - www.radio-france.
I am lucky if I still have enought time for kill -9...
On the other hand, if java and javascript are enabled, there is no
problem with all RAM being (mis)used.
My hypothesis is that this huge RAM consumption is connected with
stylesheets in certain pages, and as far as I know, Netscape for X has
some weirdness with stylesheets, because they are disabled once
javascript is disabled (even if using stylesheets seems to be marked).
These problems don't happen with Netscape for win95.
Manfred
--
To reply remove all the numbers in my e-mail address.
Alle Zahlen sind aus der e-mail-Adresse zu entfernen,
um mir per e-mail zu antworten.
------------------------------
** 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
******************************
