Linux-Advocacy Digest #684, Volume #27 Fri, 14 Jul 00 19:13:07 EDT
Contents:
Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
Re: Linsux as a desktop platform ("Aaron R. Kulkis")
Re: Linux lags behind Windows ("Aaron R. Kulkis")
Re: Linux lags behind Windows ("Aaron R. Kulkis")
Re: Linsux as a desktop platform ("Christopher Smith")
----------------------------------------------------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Fri, 14 Jul 2000 18:40:07 -0400
Reply-To: [EMAIL PROTECTED]
Said Mike Stump in comp.os.linux.advocacy;
>In article <8kkrhe$ljr$[EMAIL PROTECTED]>,
>Roberto Alsina <[EMAIL PROTECTED]> wrote:
>>Well, I'd like not to work and have money. I just don't see it
>>happening.
>
>Then you're doing something wrong. :-)
>
>Hint find a pre-IPO company that is gonna do well, get in early, get
>stock, lots of it, wait until just before they IPO, sell just before
>it tanks (but before anyone else can because they are all insiders),
>invent in boarder instruments, and presto...
>
>(Dyson, did I get that right?)
No, its a LOT trickier than that. Because if you "get in early" before
an IPO, you *are* an insider.
I mean, effectively it comes out pretty close. I got some stock out of
it, but it wasn't that much. But Mr. B. did *much* better, because he
founded the company. He's still sitting on a couple million, even after
the stock tanked. Then again, he's an honest businessman, a guy with
integrity, that recognizes his social responsibility is no less
important than his desire for personal wealth. Of course, that's why
he's getting pushed out of the "corporation" management. And that's why
I'm selling my stock. (Once it goes up a *little* more. Well, a little
more than that... a...)
And that's the nice part about insisting that business people show
integrity and social responsibility. You don't have to muck around with
trying to figure out their morals. You just judge by their actions "Do
I want to owe this guy money, if it comes down to it? Or want him to
owe me money?" If the answer is "no", don't buy anything from him. And
then you ask "Which would be worse?" If the answer is "I don't know",
then you shouldn't sell anything to him, either, and tell other people
not to buy from him, until he gets some social responsibility.
--
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: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Fri, 14 Jul 2000 18:41:41 -0400
Reply-To: [EMAIL PROTECTED]
Said [EMAIL PROTECTED] () in comp.os.linux.advocacy;
>On Fri, 14 Jul 2000 16:08:30 GMT, George Russell <[EMAIL PROTECTED]>
>wrote:
>>On Thu, 13 Jul 2000 17:32:32 GMT, Roberto Alsina <[EMAIL PROTECTED]> wrote:
>>>> If he's countering the FUD and lies you are spreading that
>>>> would be a considerable service.
>>>
>>>You know, you keep calling me a liar and not point to any lies I say.
>>>Are you lying?
>>>
>>>I know you don't like me, but could you at least keep an appearance of
>>>honesty in your actions?
>>
>>Give up roberto.
>>Thats Jedi....
>>
>>You could port krn to kde 2 quicker than get a sensible reasoned answer.
>
> Bad rhetoric.
I'll say. The concept of "mixed metaphor" rapidly comes to mind. ;-)
--
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: "Aaron R. Kulkis" <[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 18:41:20 -0400
"T. Max Devlin" wrote:
>
> Said Christopher Smith in comp.os.linux.advocacy;
> [...]
> >It would make no difference. People make mistakes, often. Especially when
> >they're dealing with anything non trivial.
>
> Yes, but we've got a new way of dealing with it that is perhaps less
> efficient in the individual case, but vastly more powerful in the
> aggregate, because it is self-correcting. Its called the market. The
> old way, of assuming that engineers are all brilliant, software is very
> expensive, and omniscience is available to software developers, doesn't
> go as far as you think. It is simply not as efficient.
>
> >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.
>
> How about 50 sets of repeatable methodologies that will efficiently
> produce almost bug-free code, right now? You think you can handle the
> concept. According to your thinking, the Internet wouldn't work,
> because there's no central control mechanism to make sure everything
> works perfectly. Mass produces software is buggy now because the market
> hasn't gotten anywhere near most of it yet; people are still buying
> trade secrets, instead of software.
>
> >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.
>
> There's only one that reliably works, though. Competition between
> programmers. All of the other methods are based on stupid, dangerous,
> and pointless assumptions which have the added problem of contributing
> to engineer's egos and user's lack of control of *their* computers.
Quite true.
The reason I'm "comfortable" with Unix systems, and not Windows
systems, is because it scares me to death to even think of all the
problems I would have to deal with if we let the users control
"their" computers.
I wish there was a way of letting them have control, becuse I end
up also wasting a lot of time doing trivial work.
We need more tools to allow users to configure their workstation to
a certain degree (up to, but not including, making it unusable)
>
> >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.
>
> So the conventional wisdom goes... I just wish it weren't so pig-headed
> so it could consider that maybe CMT has a "place", even if it isn't
> where you think it might be, oh all-knowing, all-seeing most high
> engineer. I wouldn't disagree with your comment at all, if it weren't
> an annoying side-stepping of my real issue. Which is that software
> engineers have a tendancy to use annoying side-stepping to avoid
> contemplating that they make assumptions that what they learned in
> school cannot be contradicted, regardless of context or circumstance.
>
> --
> 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! =-----
--
Aaron R. Kulkis
Unix Systems Engineer
ICQ # 3056642
I: "Having found not one single carbon monoxide leak on the entire
premises, it is my belief, and Willard concurs, that the reason
you folks feel listless and disoriented is simply because
you are lazy, stupid people"
A: The wise man is mocked by fools.
B: "Jeem" Dutton is a fool of the pathological liar sort.
C: Jet plays the fool and spews out nonsense as a method of
sidetracking discussions which are headed in a direction
that she doesn't like.
D: Jet claims to have killfiled me.
E: Jet now follows me from newgroup to newsgroup
...despite (D) above.
F: Neither Jeem nor Jet are worthy of the time to compose a
response until their behavior improves.
G: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
adultery while concurrently committing adultery with Tammy Hahn.
H: Knackos...you're a retard.
------------------------------
From: "Aaron R. Kulkis" <[EMAIL PROTECTED]>
Subject: Re: Linux lags behind Windows
Date: Fri, 14 Jul 2000 18:44:21 -0400
Perry Pip wrote:
>
> On Thu, 13 Jul 2000 19:31:16 -0400,
> Aaron R. Kulkis <[EMAIL PROTECTED]> wrote:
> >
> >
> >Pete Goodwin wrote:
> >>
> >> In article <[EMAIL PROTECTED]>,
> >> "Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote:
> >>
> >> If you're talking multiprocess or multithreaded processing then I can
> >> see why race conditions are important, but I still don't see why anyone
> >> would need to know how the scheduler works.
> >>
> >>
> >> Previously you said I would need to know about the scheduler. Now you
> >> seem to think I need to know about race conditions.
> >>
> >> Please expand on what you mean. I can't see that every application
> >> needing to consider race conditions - which is what you appear to be
> >> saying.
> >
> >I never implied that *EVERY* application has race conditions.
> >However, any programmer who keeps himself IGNORANT of process
> >scheduling and race conditions is going to step on a land mine,
> >and NEVER figure it out.
> >
>
> There is a difference between knowing what the scheduler might do and
> the knowing internals of how the scheduler works. For race conditions
> you need to know what the scheduler might or might not do. For hard
> real-time applications you need to know and possibly control
> deterministicly what the scheduler does. For soft real time apps, or
> in cases where performance is an issue, it's a big help to understand
> the scheduler more deeply.
>
> >
> >Multi-process simulations.
>
> I am currently writing code for hard real-time high-fidelity flight
> simulations that will be used in a number of engineering
> testbeds. These include testbeds for embedded flight software
> verification, flight dynamics verification, avionics hardware
> integration, and crew training. It's part of the design and
> development of an experimental research vehicle scheduled to
> fly in 2002.
>
> >Let's suppose I'm simulating a battlefield, and, to make the task of
> >modelling each entity, I have decided to model each unit, weapon,
> >building, even the terrain, as a seperate processes.
>
> Uhm...The first question that comes to my mind is does this sim need
> to be real time?? If it's just a pure simulation for analysis,
> probably not at all. If it's an action game, probably soft real
> time. If it's integration testing for some new Army "smart weapon", it
> may need to run in hard real time. Just how much real time performance
> you need determines how much you really need to know/control the
> scheduling.
It's the basic structure my in-head plan for how to implement the
Avalon Hill Game Company's "Squad Leader" series of games. I then
realize that it could be used for *any* table-top cardboard counter
on map-board simulation game.
>
> <warning - alternate OS advocacy rant> For hard real performance we
> use IRIX's Real time extensions from SGI:
> http://www.sgi.com/Products/React.html which provides to the user full
> control of of up to all but one system processor for dedication to
> real time tasks. (Leaving at least processor left behind for the OS
> and daemons). You can also redirect hardware interrupts towards or
> away from your realtime processors, depending on whether they are from
> real-time critical devices or from devices you don't want to
> interference from. Thus you can take complete control of both
> scheduling and user level interrupt handling on those processors.
> And IRIX supports up to 512 CPU's. So that's up to 511 processors
> available for real time tasks. </warning - alternate OS advocacy
> rant>
>
> >Now...all you have to do is to have each process write to an "input"
> >pipe or socket of another process which it is interacting with.
>
> Well for even soft real time I would recommend shared memory and
> semaphores. On distributed realtime testbeds we use reflective memory
> rings, which have latencies as low as a few microseconds, hundreds of
> times faster than sockets/ethernet.
>
> >Let's say that all messages to the map consist of 3 parts
> >
> >A) Header (which Process is sending this message?)
> >B) Map Coordinate
> >C) Information request (elevation, terrain type, etc.)
> > or Action (small-arms fire, tank running through building, etc.)
> >
> >
> >Let's say we have 3 processes:
>
> OK
>
> >Process A which is a "target" for the actions of two different
> >processes.
> >
> >Process 100 is the map, and listens to pipe /tmp/pipe_100
> >Process 105 is a unit which is moving, and needs to ask the map
> >what kind of terrain it is traversing.
> >Process 123 is another unit which is firing a cannon at some
> >some point on the map.
> >
> >Process 123 writes the "preamble" of it's message to /tmp/pipe_100.
> >Before it gets to the main body of it's message, Process 123 loses
> >the CPU. In the intervening time, Process 105 writes to /tmp/pipe_100
> >with a simple request for terrain information at it's location.
> >Sometime later, Process 123 finishes writing it's message to
> >/tmp/pipe_100
> >
>
> You don't even have to lose the CPU to get race condition on a
> multiprocessor system.
>
> >[race condition for dummies snipped]
> >
> >Someone who doesn't understand the task scheduler is likely to
> >allow this sort of situation.
>
> Well certainly not to much depth of knowledge of the scheduler to
> prevent race conditions. All the devloper needs to know about
> scheduling it that he can't predict what the scheduler will do.
>
> >Conversely, someone who DOES understand process scheduling will
> >realize that
> >
> >a) write(2) is guaranteed to NOT be interrrupted by a context switch.
> > that is...the context switch will be ignored until the write(2)
> > requests transfers the data into the filesystem I/O buffers.
>
> NOT!! There is a maximum number of bytes that you can write(2) to a
> pipe or FIFO and still be guaranteed atomicity. Above that number,
> called PIPE_BUF as required by Posix, their is no guarantee you will
> get a full write. In that case, write(2) will return the number of
> bytes written. PIPE_BUF is defined in limits.h in your Linux kernel
> source. So now there are some unseen bugs in your code if your
> messages are too long.
>
> >b) printf(3) is NOT guaranteed to transfer the output into the
> > buffers completely uninterrupted by context switches.
>
> I think you mean fprintf(3), printf(3) writes to stdout.
>
> >c) the use of printf(3) allows the race condition above to occur.
> >
> >d) the use of 3 seperate writes (proc ID, co-ordinate n-tuple,
> > and request/event) ALSO allows the race condition above
> > to occur
> >
>
> and e) if your messages are larger than PIPE_BUF, allows the race
> condition above to occur.
>
> >therefore
> >
> >e) EACH PROCESS ***MUST*** scribble it's own output into it's
> > own internal buffer,
>
> and verify the message is smaller than or equal to PIPE_BUF.
>
> and then ***MUST*** use write(2)
> > to transfer the entire message in ONE PIECE to the
> > filesystem pipe.
> >
> >The programmer who is ignorant of the operation of the scheduler
> >is going to have unexplained errors which he will NEVER NEVER
> >NEVER understand until he learns about process scheduling.
>
> And you who is ignorant of limits will have unexplained errors.
>
> >
> >ANOTHER reason to learn the process scheduler's algorithm is to
> >prevent processes from suffering from CPU starvation.
> >
>
> Don't need to know that much about the scheduler, unless the app is
> real time. Do need to know about limits.
>
> >Aaron R. Kulkis
> >Unix Systems Engineer
>
> Engineer?? As in a four year degree that ends in the Letter E, for
> Engineering?? I've got a BSME and am working on a MSCS.
>
> Perry
--
Aaron R. Kulkis
Unix Systems Engineer
ICQ # 3056642
I: "Having found not one single carbon monoxide leak on the entire
premises, it is my belief, and Willard concurs, that the reason
you folks feel listless and disoriented is simply because
you are lazy, stupid people"
A: The wise man is mocked by fools.
B: "Jeem" Dutton is a fool of the pathological liar sort.
C: Jet plays the fool and spews out nonsense as a method of
sidetracking discussions which are headed in a direction
that she doesn't like.
D: Jet claims to have killfiled me.
E: Jet now follows me from newgroup to newsgroup
...despite (D) above.
F: Neither Jeem nor Jet are worthy of the time to compose a
response until their behavior improves.
G: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
adultery while concurrently committing adultery with Tammy Hahn.
H: Knackos...you're a retard.
------------------------------
From: "Aaron R. Kulkis" <[EMAIL PROTECTED]>
Subject: Re: Linux lags behind Windows
Date: Fri, 14 Jul 2000 18:51:27 -0400
Perry Pip wrote:
>
> On Thu, 13 Jul 2000 19:31:16 -0400,
> Aaron R. Kulkis <[EMAIL PROTECTED]> wrote:
> >
> >
> >Pete Goodwin wrote:
> >>
> >> In article <[EMAIL PROTECTED]>,
> >> "Aaron R. Kulkis" <[EMAIL PROTECTED]> wrote:
> >>
> >> If you're talking multiprocess or multithreaded processing then I can
> >> see why race conditions are important, but I still don't see why anyone
> >> would need to know how the scheduler works.
> >>
> >>
> >> Previously you said I would need to know about the scheduler. Now you
> >> seem to think I need to know about race conditions.
> >>
> >> Please expand on what you mean. I can't see that every application
> >> needing to consider race conditions - which is what you appear to be
> >> saying.
> >
> >I never implied that *EVERY* application has race conditions.
> >However, any programmer who keeps himself IGNORANT of process
> >scheduling and race conditions is going to step on a land mine,
> >and NEVER figure it out.
> >
>
> There is a difference between knowing what the scheduler might do and
> the knowing internals of how the scheduler works. For race conditions
> you need to know what the scheduler might or might not do. For hard
> real-time applications you need to know and possibly control
> deterministicly what the scheduler does. For soft real time apps, or
> in cases where performance is an issue, it's a big help to understand
> the scheduler more deeply.
>
> >
> >Multi-process simulations.
>
> I am currently writing code for hard real-time high-fidelity flight
> simulations that will be used in a number of engineering
> testbeds. These include testbeds for embedded flight software
> verification, flight dynamics verification, avionics hardware
> integration, and crew training. It's part of the design and
> development of an experimental research vehicle scheduled to
> fly in 2002.
>
> >Let's suppose I'm simulating a battlefield, and, to make the task of
> >modelling each entity, I have decided to model each unit, weapon,
> >building, even the terrain, as a seperate processes.
>
> Uhm...The first question that comes to my mind is does this sim need
> to be real time?? If it's just a pure simulation for analysis,
> probably not at all. If it's an action game, probably soft real
> time. If it's integration testing for some new Army "smart weapon", it
> may need to run in hard real time. Just how much real time performance
> you need determines how much you really need to know/control the
> scheduling.
>
> <warning - alternate OS advocacy rant> For hard real performance we
> use IRIX's Real time extensions from SGI:
> http://www.sgi.com/Products/React.html which provides to the user full
> control of of up to all but one system processor for dedication to
> real time tasks. (Leaving at least processor left behind for the OS
> and daemons). You can also redirect hardware interrupts towards or
> away from your realtime processors, depending on whether they are from
> real-time critical devices or from devices you don't want to
> interference from. Thus you can take complete control of both
> scheduling and user level interrupt handling on those processors.
> And IRIX supports up to 512 CPU's. So that's up to 511 processors
> available for real time tasks. </warning - alternate OS advocacy
> rant>
>
> >Now...all you have to do is to have each process write to an "input"
> >pipe or socket of another process which it is interacting with.
>
> Well for even soft real time I would recommend shared memory and
> semaphores. On distributed realtime testbeds we use reflective memory
> rings, which have latencies as low as a few microseconds, hundreds of
> times faster than sockets/ethernet.
>
> >Let's say that all messages to the map consist of 3 parts
> >
> >A) Header (which Process is sending this message?)
> >B) Map Coordinate
> >C) Information request (elevation, terrain type, etc.)
> > or Action (small-arms fire, tank running through building, etc.)
> >
> >
> >Let's say we have 3 processes:
>
> OK
>
> >Process A which is a "target" for the actions of two different
> >processes.
> >
> >Process 100 is the map, and listens to pipe /tmp/pipe_100
> >Process 105 is a unit which is moving, and needs to ask the map
> >what kind of terrain it is traversing.
> >Process 123 is another unit which is firing a cannon at some
> >some point on the map.
> >
> >Process 123 writes the "preamble" of it's message to /tmp/pipe_100.
> >Before it gets to the main body of it's message, Process 123 loses
> >the CPU. In the intervening time, Process 105 writes to /tmp/pipe_100
> >with a simple request for terrain information at it's location.
> >Sometime later, Process 123 finishes writing it's message to
> >/tmp/pipe_100
> >
>
> You don't even have to lose the CPU to get race condition on a
> multiprocessor system.
>
> >[race condition for dummies snipped]
> >
> >Someone who doesn't understand the task scheduler is likely to
> >allow this sort of situation.
>
> Well certainly not to much depth of knowledge of the scheduler to
> prevent race conditions. All the devloper needs to know about
> scheduling it that he can't predict what the scheduler will do.
>
> >Conversely, someone who DOES understand process scheduling will
> >realize that
> >
> >a) write(2) is guaranteed to NOT be interrrupted by a context switch.
> > that is...the context switch will be ignored until the write(2)
> > requests transfers the data into the filesystem I/O buffers.
>
> NOT!! There is a maximum number of bytes that you can write(2) to a
> pipe or FIFO and still be guaranteed atomicity. Above that number,
> called PIPE_BUF as required by Posix, their is no guarantee you will
> get a full write. In that case, write(2) will return the number of
> bytes written. PIPE_BUF is defined in limits.h in your Linux kernel
> source. So now there are some unseen bugs in your code if your
> messages are too long.
>
> >b) printf(3) is NOT guaranteed to transfer the output into the
> > buffers completely uninterrupted by context switches.
>
> I think you mean fprintf(3), printf(3) writes to stdout.
>
> >c) the use of printf(3) allows the race condition above to occur.
> >
> >d) the use of 3 seperate writes (proc ID, co-ordinate n-tuple,
> > and request/event) ALSO allows the race condition above
> > to occur
> >
>
> and e) if your messages are larger than PIPE_BUF, allows the race
> condition above to occur.
You're correct. Foggy memory on my part.
I haven't written any intense C code in over a decade.
Minimum PIPE_BUF that I've ever seen is 2k. should be more
than adequate. If need be, an auxillary process with additional
storage space can be used to cache the I/O stream in
circular buffers.
>
> >therefore
> >
> >e) EACH PROCESS ***MUST*** scribble it's own output into it's
> > own internal buffer,
>
> and verify the message is smaller than or equal to PIPE_BUF.
>
> and then ***MUST*** use write(2)
> > to transfer the entire message in ONE PIECE to the
> > filesystem pipe.
> >
> >The programmer who is ignorant of the operation of the scheduler
> >is going to have unexplained errors which he will NEVER NEVER
> >NEVER understand until he learns about process scheduling.
>
> And you who is ignorant of limits will have unexplained errors.
Fortunately, these messages are real short. A handful of bytes
for the header, grid location, and coordinates.
I can't see any message for ANY part of the complete architecture
for my simulation taking even 512 bytes, so this is pretty safe.
>
> >
> >ANOTHER reason to learn the process scheduler's algorithm is to
> >prevent processes from suffering from CPU starvation.
> >
>
> Don't need to know that much about the scheduler, unless the app is
> real time. Do need to know about limits.
True.
In this case, NONE of the messages are going to be any where close
to the limits of write(2)
>
> >Aaron R. Kulkis
> >Unix Systems Engineer
>
> Engineer?? As in a four year degree that ends in the Letter E, for
> Engineering?? I've got a BSME and am working on a MSCS.
Yes. Purdue University.
Thanks for the critique. I haven't worked on a major programming
project in C in almost a decade.
>
> Perry
--
Aaron R. Kulkis
Unix Systems Engineer
ICQ # 3056642
I: "Having found not one single carbon monoxide leak on the entire
premises, it is my belief, and Willard concurs, that the reason
you folks feel listless and disoriented is simply because
you are lazy, stupid people"
A: The wise man is mocked by fools.
B: "Jeem" Dutton is a fool of the pathological liar sort.
C: Jet plays the fool and spews out nonsense as a method of
sidetracking discussions which are headed in a direction
that she doesn't like.
D: Jet claims to have killfiled me.
E: Jet now follows me from newgroup to newsgroup
...despite (D) above.
F: Neither Jeem nor Jet are worthy of the time to compose a
response until their behavior improves.
G: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
adultery while concurrently committing adultery with Tammy Hahn.
H: Knackos...you're a retard.
------------------------------
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: Sat, 15 Jul 2000 08:09:22 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said void in comp.os.linux.advocacy;
> >On Thu, 13 Jul 2000 23:05:40 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
> >>us who are ignorant of the technical details to
> >>wonder what difference it makes what kind of multitasking the OS uses,
> >
> >Stay ... right ... there.
> >
> >OK -- now that you're ignorant, and wondering, why don't you ask all of
> >the non-ignorant people around here why things are done the way they
> >ware, AND LISTEN TO THE BLOODY ANSWER.
>
> Because I'm not the least bit interested in why things are done the way
> they are. All I'm concerned with is why things aren't done the way they
> aren't. No wonder you are confused and can't figure out how to answer.
> LISTEN TO THE BLOODY QUESTION.
This has been answered already, *multiple times*. Things "aren't done the
way they aren't" ("aren't" presumably referring to CMT) because "things"
were already tried like that decades ago and replaced by a superior system.
------------------------------
** 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
******************************
