Linux-Advocacy Digest #705, Volume #27           Sat, 15 Jul 00 21:13:04 EDT

Contents:
  Re: New Linux user & damn glad!! (richard harlos)
  Re: New Linux user & damn glad!! (richard harlos)
  Re: Linsux as a desktop platform (ZnU)
  Re: Linsux as a desktop platform ("Colin R. Day")
  Re: Linsux as a desktop platform (T. Max Devlin)
  Re: Linsux as a desktop platform ([EMAIL PROTECTED])
  Re: Linsux as a desktop platform ("Colin R. Day")
  Re: Linsux as a desktop platform ("Colin R. Day")
  Re: Linsux as a desktop platform (ZnU)
  Re: Linsux as a desktop platform ("Colin R. Day")
  Re: Tholen digest, volume 2451741.4533^-.0000000000000000001 ([EMAIL PROTECTED])
  Re: Linsux as a desktop platform ("Colin R. Day")
  Re: Linsux as a desktop platform (T. Max Devlin)

----------------------------------------------------------------------------

From: richard harlos <[EMAIL PROTECTED]>
Subject: Re: New Linux user & damn glad!!
Date: Sun, 16 Jul 2000 00:25:40 GMT

rich wrote:
> 
> Also schrieb richard harlos:
> >Hi, all.
> >
> >I'm just about messin' my shorts for joy!
> >
> >I installed Slackware 7.1 (BigSlack, the UMSDOS install) on my PC and am
> >now happily up and running on the 'net.
> >
> 
> I'm hopefully going to join you this weekend.  I'm FTPing Slack 7.1 in
> another Win95 window as we speak.  It's a company owned PC, so I'll only
> be able to do U-Mess-Dos on it for a filesystem.
> 
> Actually, I have a Red Hat installation at home.  Problem is, I don't
> appear to have a monitor that survived the move into our new house.  So
> there it sits at the login: prompt, impotent.  :-{(
> 
> Ah well.  Computer show at the end of the month.  I'll find something
> cheap there.
> 
> I am dying to try Slackware on this Compaq LTE 5380 laptop.  We shall
> see how much fun I can have without trashing the company-maintained
> filesystem.  ;-{)
> 
> --
> Catch the cluetrain.  http://www.cluetrain.com
> ALL programs are poems, it's just that not all programmers are poets.
>     -- Jonathan Guthrie in the scary.devil.monastery

Ah, you're a bit of a risk-taker with the company property.  I admire
that  :)

I did the same thing a while back except I actually used Partition Magic
and went for the gusto!  It was only a minimal install, with no network
access but still, enough to get familiar with the commandline and some
of the more basic commands -- reminiscent of my old MS-DOS3.3 days

Good luck with your home-monitor situation (what?  you mean you can't
learn linux without a monitor??  be a  *man* about it!  <LOL!>   :)
--
 richard harlos

 quote loading; please wait...

------------------------------

From: richard harlos <[EMAIL PROTECTED]>
Subject: Re: New Linux user & damn glad!!
Date: Sun, 16 Jul 2000 00:27:15 GMT

"Colin R. Day" wrote:
> 
> richard harlos wrote:
> 
> > Hi, all.
> >
> > I'm just about messin' my shorts for joy!
> >
> > I installed Slackware 7.1 (BigSlack, the UMSDOS install) on my PC and am
> > now happily up and running on the 'net.
> >
> > Aside from a little tweaking to get my cheap, ISP-supplied network card
> > enabled, I'm good to go.
> >
> > And even though it's going to take some time to learn my way around X
> > and Linux in general, I'm much happier to be  *doing*  something about
> > my dissatisfaction with Microsoft product (by not using them anymore
> > than necessary!) than just  *talking*  about it.
> >
> > Don't flame this newbie too bad   :)
> 
> Don't worry, and welcome aboard.

Thanks.  I finally made it to c.o.l.advocacy after all.

Hey, that looks like "Col. Advocacy" -- cool!   :)
--
 richard harlos

 quote loading; please wait...

------------------------------

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 00:27:24 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
wrote:

> Said Ray Chason in comp.os.linux.advocacy; 
> >T. Max Devlin <[EMAIL PROTECTED]> wrote:
> >
> >>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?)
> >
> >How fast might a professional secretary type?  75 words per minute?  
> >Let's
> >assume 4.5 characters per word at 75 wpm.  That's about 5.6 characters 
> >per
> >second.
> >
> >Now consider the humble 56K modem, running flat out at 56,000 bits per
> >second.  At ten bits per byte (eight data bits, one start bit, one stop
> >bit) the modem is "typing" 5600 bytes per second -- *one thousand times*
> >as fast as the secretary!

[snip explanation of extremely basic issues]
 
> IF: CMT systems require less memory for a given set of tasks
> AND: The failure of CMT is applications which can maintain control
> counter-productively 
> THEN: The optimal system is one in which CMT is used and no applications
> maintain control counter-productively

In practice, it is impossible to create CMT applications that never 
maintain control counter-productively. To actually do it would require 
very significant amounts of additional code and interprocess 
communication. That means more bugs, slower program execution, larger 
memory footprint, and longer time to market. For certain small 
applications, the multitasking code would be many times larger than the 
rest of the application. And even if you could pull it all off, you 
wouldn't get anything better than what PMT provides.

Any efficiencies CMT might have don't really apply to modern hardware or 
operating systems. On the original Mac, which only ran one program at a 
time, perhaps there was some benefit. In any system that runs more than 
one app at once, CMT wastes resources right and left.

> Now down to brass tacks; you can illustrate how this doesn't play out in
> real life, or you can argue whether its true.  But you can't say it
> doesn't make sense to begin with to wonder if it isn't true, and how it
> would best be played out in real life.

I've got a better idea. Why don't you explain what you don't like about 
PMT, why it's bad, and how a CMT system such as the one you describe 
above actually addresses it. Because from what I can tell, a CMT system 
such as you describe would be totally impractical and wouldn't be better 
than PMT even if it could be implemented.

And please no "I don't want algorithms running my life." Perhaps you'd 
like to do error correction in your CD-ROM drive manually as well?

[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: "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: Sat, 15 Jul 2000 20:29:10 -0400

"T. Max Devlin" wrote:


> >> What the hell does the operating system developer have to do with it?
> >
> >How else can you guarantee the programs are going to co-operate unless the
> >developers of all of them, and the OS, have collaborated ?
>
> Because if they haven't, they won't sell very many products.  Market
> behavior, not technical requirements, are the more flexible method of
> ensuring co-operation.

Are you saying that people won't buy applications that don't do CMT
well? First people would have to know that sluggishness is due to a
bad application, rather than the OS or hardware. Also, if the problem
is in running certain combinations of applications, how do consumers
pull apart the interaction?



>  You can tell which program is not "being nice",
> so to speak,

How? Does Mac have top?


> and programs might even differentiate themselves by whether
> they get something done fast, or whether they get it done optimally
> while cooperating optimally.  I think this relates to your reference to
> the OS developer having "absolute and total control over every
> instruction".  To me, that sounds like the job of the owner of the
> computer, and generally the operator.
>

But the owner could shop among kernels as easily as among apps.
Those kernels that best allocated CPU time for a user would be
chosen (although how much can different Linux vendors tweak
the scheduling?). I find it hard to believe that many people would
choose applications on the basis of their CMT.


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 20:34:12 -0400
Reply-To: [EMAIL PROTECTED]

Said Christopher Smith in comp.os.linux.advocacy; 
>
>"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Said Christopher Smith in comp.os.linux.advocacy;
>>    [...]
>> >Given you are arguing from a position of complete, utter and blatant
>> >ignorance in this entire discussion, I find that paragraph somewhat
>amusing.
>>
>> Hey Chris; what does the number 53.7 Microseconds mean in Internet
>> connectivity, and how is it relevant to this discussion?  If you can
>> give me a half decent guess, even if you're wrong, I'll consider that
>> you might possibly be competent to begin to suggest whether I am
>> "utterly ignorant".   I'm not a system dweeb, no, if that's what you
>> mean.  I don't limit myself to one specialty.
>
>Max, you're trying to argue about the pros and cons of CPU scheduling after
>admitting (and demonstrating) you don't know even the basic concepts
>involved.  If that isn't arguing from a position of complete and utter
>ignorance (especially given how many people have explained, calmy and
>rationally, *why* you're wrong) I don't know what is.

The reason 53.7 microseconds is relevant is, I'll admit, a bit abstract.
The number itself refers to the maximum round-trip propagation delay of
an Ethernet signal.  This is a broadcast, and must reach every physical
point in the transmission channel before the transmitter can assume that
its signal has been received, and thus cleared the channel through the
carrier detect mechanism of Ethernet.  If it takes longer than 53.7
microseconds for the signal to reach "the other end" and for any other
signal transmitted in that same instant to be received, then both
systems may assume they have cleared the channel and begin transmitting.
This causes what is known as a "late collision", which causes a failure
but is not internally identifiable as an error to the Ethernet system
itself.

The reason it is relevant to this discussion is because I am no more an
expert on Ethernet than I am on CPU scheduling, from your perspective.
The reason it is relevant from my perspective is that the ease at which
late collisions cause problems on an Ethernet is not dependant on the
lengths taken to avoid the problem.  Indeed, Ethernet is successful
because it took an innovative approach that hadn't been considered
possible: don't do that then.  You simply don't build an Ethernet that
exceeds 53.7 microseconds in propagation delay.  And when you get late
collisions, they are easy to detect on the hub.  So you identify where
and when they occur, and figure out which cable run ended up being
greater than the 100 meter specification.  It isn't a simple process by
any means.  But it is easier to occasionally to it than it is to not use
Ethernet at all, simply because it doesn't have any technical capability
for dealing with the problem.  Just because you'd like to avoid the
problem is no reason you need to solve the problem.  DDTT.  

Arguing from a position of ignorance is when you say just because
something isn't known it is true.  Questioning whether something is true
is not arguing from ignorance.  I've never assumed something isn't true
because you can't explain it to me.  But I won't assume that your
explanation of something makes it true.  If I can question your answer,
I've a right to do so, and free from ridicule, if you will pardon my
pointing it out.

So I'll ask again.  Is it true that a scheduler is necessary to provide
robust and reliable multi-tasking?  You don't need to solve all computer
problems; we're thinking mostly of what will work best on a desktop
platform.

--
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: [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 19:34:22 -0500

On Sun, 16 Jul 2000 00:27:24 GMT, ZnU <[EMAIL PROTECTED]> wrote:

>time, perhaps there was some benefit. In any system that runs more than 
>one app at once, CMT wastes resources right and left.

You know, it's really nice to see someone besides myself and a few
Windows users write that.  

------------------------------

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: Sat, 15 Jul 2000 20:36:02 -0400

"T. Max Devlin" wrote:


> >> 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.
>
> Until they weren't again, and now they are?  What are you, junior
> acolyte moron?
>

The only advantage that you have stated for CMT is user control, and
you have not shown how the user has any more control in CMT than
in PMT.


Colin Day


------------------------------

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: Sat, 15 Jul 2000 20:43:28 -0400

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).

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 00:51:52 GMT

In article 
<[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] wrote:

> On Sun, 16 Jul 2000 00:27:24 GMT, ZnU <[EMAIL PROTECTED]> wrote:
> 
> >time, perhaps there was some benefit. In any system that runs more than 
> >one app at once, CMT wastes resources right and left.
> 
> You know, it's really nice to see someone besides myself and a few
> Windows users write that.  

Lots of more experienced Mac users feel this way. Microsoft might have 
gotten lots of the technical details right (or better than Apple, 
anyway), but has no idea how to build a truly usable, coherent whole.

I'm willing to give up protected memory, PMT, cheaper and more flexible 
hardware, a larger software base, etc. just to escape the hideous kludge 
that Windows is from a usability standpoint.

-- 
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: "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: Sat, 15 Jul 2000 20:54:50 -0400

"T. Max Devlin" wrote:


>
> I mean, none of them here ever actually tried to make this point, but
> they hinted they might.  The process that needs most of the CPU's time
> in order to keep the "foreground responsive" might not be the foreground
> process.  The similar issue that the user might not know which program
> or process they want to speed up has been presented, but I think there
> is a difference.  I suspect the reason they might never have considered
> this is that an OS schedule isn't cognizant of what inter-relationships
> might incur between processes which are part of the same "program", and
> the art of multi-process programming is a very difficult one, I would
> guess, perhaps no more than some early guesses about what will someday
> be a very important area of development.  Which process needs to be
> given CPU in order to speed up the process the user wants done first
> would require input from the application developer, and that would
> require cooperative scheduling, whether it is CMT or not.  On the other
> hand, it could be because its a ludicrous idea, but nobody's had a
> chance to explain it to me before I presented it here as an idea,
> ludicrous or not.
>

Why should *we* have to bear the burden of proof? If you
believe that CMT is better, then tell us why.


Colin Day


------------------------------

Crossposted-To: 
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
From: [EMAIL PROTECTED]
Subject: Re: Tholen digest, volume 2451741.4533^-.0000000000000000001
Reply-To: [EMAIL PROTECTED]
Date: Sun, 16 Jul 2000 00:59:59 GMT

David T. Johnson writes:

> Joe Malloy wrote:

>>> You still haven't learned, Thorne.
 
>> And you still haven't learned to read, Tholen.

> Hey there, "Joe Malloy"  Everytime Dr. Tholen makes a Usenet post, you
> reply with a meaningless post about his words.  You have been trashing
> our comp.os.os2.advocacy newsgroup (and others unfortunately) for months
> now with this vendetta against Dr. Tholen.  Since we all have to read
> your drivel, do you think you could at least give us the reasons for
> your grudge?

Nice try, but don't expect to get any useful answer from Joe Malloy.
I've been trying to get a logical reason for his presence here for a
long time, but the best he can come up with is "entertainment".  In
lieu of any logical reason, you'll have to reach your own conclusion
on the basis of the evidence.  For example, Malloy is a Windows user.
I run OS/2 on my PCs.  This newsgroup has been one place where Windows
users have been trash-talking about OS/2 and singing the praises of
Windows.  I've been active in countering the FUD, bias, illogic, and
unfairness.

And the fact that I provided a sequitur response proves that Malloy
is full of it when he claims that I haven't learned to read.  If only
he knew just how badly he's making a fool of himself.


------------------------------

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: Sat, 15 Jul 2000 21:01:49 -0400

"T. Max Devlin" wrote:


>
> Thus providing the need for cooperation.  Yes, any system that is based
> on cooperation can screw up the system for everyone.  Are you saying
> Token Ring is better than Ethernet?  TCP/IP sucks compared to X.25?
> Microchannel was more successful than the original PC?  All of these
> very important technologies are all based on one thing: you cannot
> mandate technical value in market-driven development.  So stop trying.
> Because there is always technical value in cooperation, and the market
> LOVES cooperation.

Cooperation among people, yes (though try telling to Microsoft).
But among processes?



>  Its what its built for.  System which mandate
> cooperation end up being far superior than systems which attempt to
> impose even egalitarian rules.
>

Imposing egalitarian rules on people is bad, yes.
But on processes?


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 21:04:20 -0400
Reply-To: [EMAIL PROTECTED]

Said ZnU in comp.os.linux.advocacy; 
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
>wrote:
>
>> Said ZnU in comp.os.linux.advocacy; 
>>    [...]
>> >No. First, as has been said many times, it is impossible to make a CMT 
>> >app that behaves as it should. Moreover, in most cases it is simply 
>> >insane to thing a user can just abandon a particular app and switch to 
>> >another.
>> 
>> I think you're blowing smoke.  In the first case, Mac may have had lots
>> of apps that you say don't behave "as it should", but it was a
>> successful platform.
>
>What's your point?
>
>> In the second case, I 'abandon' one app and switch
>> to another on a dime, a thousand times a day.
>
>Let's try to live in the real world, shall we?
>
>Most people need to use specific apps, like Microsoft Word or Adobe 
>Photoshop. Something like Photoshop is essentially one of a kind. 
>There's nothing to switch to.
>
>> But maybe you're just saying "you need all your apps to be working 
>> all the time", though CMT doesn't prevent that any more effectively 
>> than PMT does,
>
>Yes it does.
>
>> outside the horror-story case of an app that doesn't yield.
>
>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".  There is another, the Mac used it, apps *did*
"behave properly", and the system worked.  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.

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.


--
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! ======

------------------------------


** 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
******************************

Reply via email to