Linux-Advocacy Digest #607, Volume #27 Wed, 12 Jul 00 01:13:06 EDT
Contents:
Re: Why use Linux? ([EMAIL PROTECTED])
Re: Linux code going down hill (T. Max Devlin)
Re: Linux code going down hill (T. Max Devlin)
Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
Re: Linsux as a desktop platform (void)
Re: Microsoft's new ".NET" ([EMAIL PROTECTED])
Re: Linsux as a desktop platform (ZnU)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Why use Linux?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 12 Jul 2000 03:49:05 GMT
Phill <[EMAIL PROTECTED]> writes:
>Pete Goodwin wrote:
>> Rubbish! We have a file server here running Windows 98 SE. It rarely
>> crashes, and we rarely reboot it. I think its been rebooted three or
>> four times in the last one and a half years, and that only to fix a
>> hardware problem!
>Win98 SE fixed the above problem. Bit of a poor show that this was ever
>an issue.
Just out of interest --- wasn't Win98SE released less than a year and a half
ago?
Bernie
--
It is easier to make war than to make peace
Georges Clemenceau
French Prime Minister 1906-09
Verdun, 20 July 1919
------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Subject: Re: Linux code going down hill
Date: Tue, 11 Jul 2000 23:49:18 -0400
Reply-To: [EMAIL PROTECTED]
Quoting abraxas from comp.os.linux.advocacy; 11 Jul 2000 17:06:22 GMT
>> You realize they still suck at being anything but Mainframes, don't you?
>> ;-)
>
>Depends, methinks. Classical mainframe computing: ASCII blah blah blah...
>perhaps.
>
>But I have to admit, the baby S/390s look quite nice.
Don't believe anything anyone tells you different; the baby S/390s are
hosts, not mainframes. What used to be called "mini-computers", which
is generally equivalent in today's terms to "unix box". The classical
mainframes are still mainframes. That isn't a cut; indeed, a mainframe
(this is operational functionality, not architecture, I'm referring to
as "mainframe") is a very important and useful tool for its market.
--
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]>
Subject: Re: Linux code going down hill
Date: Tue, 11 Jul 2000 23:50:44 -0400
Reply-To: [EMAIL PROTECTED]
Quoting Aaron Kulkis from comp.os.linux.advocacy; Tue, 11 Jul 2000
[...]
>(Remember, Deskview and everyone else was EXCLUDED from the market
>after MickeySoft insisted on Windows being bundled in)
Minor clarification: Deskview and everyone else were excluded long
before Windows bundling. It just didn't become really obvious until
that coup de grace.
--
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: Wed, 12 Jul 2000 00:08:22 -0400
Reply-To: [EMAIL PROTECTED]
Quoting Austin Ziegler from comp.os.linux.advocacy; Tue, 11 Jul 2000
[...]
>Because the protocol itself was left for vendor specification, it would
>not have mattered at all that the protocol's reference implementation
>was -- except that the few Unix vendors who have expressed any support
>for it at all wouldn't have bothered to express the minimal support
>that they have. I don't think they would have bothered doing a clean
>room implementation.
Unix vendors are rapidly learning that they have no need to keep their
source code secret. Again, you argue historical reality, which was
valid at the time. To suggest that vendors both don't use reference
implementations, and would find a GPL reference implementation to make
the protocol unacceptable, doesn't make sense. If vendors don't use
reference implementations, but re-implement the protocol, then it
wouldn't make any difference if the reference implementation is GPL. If
vendors won't use GPL reference implementations, then they would
re-implement the protocol. It is only when they would use the reference
implementation, and would not support the protocol, that the application
of GPL matters. And that, of course, would be the argument for GPLing
reference implementations, because the very purpose of GPL is to induce
more software to be GPL. Would it inhibit development of protocols?
No, just reference implementations. Would that be a bad thing? Only if
vendors were using the reference implementation, which is profiteering
off of the intellectual work of someone else. Unless the reference
implementation is public domain, which I will again point out is the
optimal solution. All reference implementations for anything that wants
to call itself an "open protocol" must be considered public domain, as
far as I'm concerned.
>> Nevertheless, if you can try
>> to ignore that absolutely correct and valid point you have, you might be
>> able to see that aside from the lunacy of making a source implementation
>> GPL, Microsoft would not have been able to do what they did with
>> Kerberos if it had been GPL.
>
>But the *would* have, because the protocol itself has this open spot.
But if you implement a protocol, even if the protocol is published, and
then implement the protocol, and your implementation works interoperates
very easily with the reference implementation, than it is reasonable to
assume that you have simply copied the reference implementation, without
innovating or adding value while maintaining interoperability. We don't
write protocols so that people can profiteer off of them; we write them
so that they can be used by people who are earning an honest profit by
using them, not by controlling them. If the reference implementation
were GPL, it would force the resulting product to be open source, and we
could look to see if the reference implementation had been directly
copied or not. If the reference implementation is not GPL, we cannot
look, unless the implementor gives us permission, and we must "take
their word for it". Since we can't look, we can't know, but we can
assume, because there is no benefit of the doubt unless the source code
can be examined to begin with. Then they have the benefit of the doubt,
and somebody would have to *prove* that the code you are seeing is a
copy of the reference implementation, and allow them to defend the
technical differences in their implementation of the protocol.
>It appears that MS has used *enough* of the reference code to merit mention
>of MIT's copyright in their documentation (I went searching). Given that, the
>section in question was still an area to extend in the protocol itself.
But that's the point; even from appearances of the resulting execution,
they acknowledged MIT's ownership, without specifying (unless I'm
misconstruing your statement) whether theirs was a derivative work or a
re-implementation. Had MIT GPLed the reference implementation, this
would be more than sufficient reason to believe that this was the case,
in which case MS cannot release their Kerberos without opening their
source, which allows us to examine the case to see for ourselves. This
open source is abhorrent to Microsoft's very reason for extending the
protocol as they did, and would have deterred their strategy to the
point where they never would have contemplated it to begin with. Say
"open source", and MS starts acting like old man Sanford doing one of
his "heart attack" routines.
--
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: [EMAIL PROTECTED] (void)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: 12 Jul 2000 04:10:53 GMT
On Tue, 11 Jul 2000 23:20:00 -0400, T. Max Devlin <[EMAIL PROTECTED]> wrote:
>
>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?
I'm not.
>Anyone who has ever been interrupted repetitively in the
>middle by a dialog box popping and re-popping in front of them because a
>background applications somehow thinks its vitally important, knows that
>requiring the foreground application (the one the operator of the
>computer has designated as most important, because that's the one
>they're using) to yield, rather than to provide pre-emptive
>multi-tasking might be considered a bit more appropriate for a desktop
>computer almost exclusively used as a client platform.
You can build a GUI that behaves however you like on top of a preemptively-
multitasking system. Your argument doesn't hold water.
>MacOS just "successfully solved" how to run multi-tasking in a different
>way. It isn't necessarily inferior if it is more appropriate to their
>requirements.
OK, so explain why Apple is telling its customers and everybody that
their new OS will be better partially because it has preemptive
multitasking?
--
Ben
220 go.ahead.make.my.day ESMTP Postfix
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft's new ".NET"
Date: Wed, 12 Jul 2000 04:15:17 GMT
In article <VVca5.2798$[EMAIL PROTECTED]>,
"TimL" <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
> (RealCea) wrote:
> > Might as well put Microsoft on your right hand or forehead.
> >
> > I cannot believe those guys. Did you know that Microsoft's ".NET"
> > project is nearly identical to a Netscape project in 1995 that was
never
> > finished
> > (probably due to Microsoft) called Costellation. Back then they were
> > just
> > developing Windows 98. They are just a bunch of "has beens". Shove
> > everyone in the market around and steal other peoples ideas. Isn't
that
> > the worst type of monopoly this country has ever seen? Innovation my
> > ASS!! Whats up with the crappy BIOs/IRQ architecture? You'd think
they
> > would develop something beyond
> > 1970 technology there. All I see is a lucky man who got his OS
(MS-DOS)
> > on all
> > of IBM's PC's. And that was not even developed by him!!!
> >
> > P.S. Internet Explorer was originally developed by Spry, Inc.
>
> Uhm, what does Microsoft has to do with BIOS/IRQ architecture? For
that
> matter, who can change "BIOS/IRQ" architecture? I am not knowledgable
> enough to answer that, however at some point the ball gets to MS'
court,
> assuming that the OS must be adapted to however the PC architecture is
> changed. No one entity really controls PC architecture, perhaps it's
great-
> est strength and its greatest weakness.
>
> /TimL
>
Well, who else would change it? I mean if a hardware vendor changes it
it is not compatable with windows, rendering it useless unless made for
Linux or Mac. Microsoft developed the Plug & Play bios didn't they?
Isreal
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
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: Wed, 12 Jul 2000 04:44:14 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
> Quoting ZnU from comp.os.linux.advocacy; Tue, 11 Jul 2000 08:27:44 GMT
> >In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
[snip]
> > Typing something in a news readers uses what? 2% of the
> >CPU? Yet if you're decompressing something in the background, it will
> >get dramatically slower.
>
> 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. 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.
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. 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.
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. 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).
[snip]
> >Issues like what you suggest with the dialog are really just the result
> >of badly designed UI. From what I've seen of Mac OS X DP4, it seems like
> >Apple has done an ingenious job of avoiding such problems while also
> >totally eliminating the extremely irritating modality problems with
> >current Mac OS dialogs.
>
> I'm mostly thinking of Mac OS 4.2 and 6.00.004, as that's where the bulk
> of my Apple experience lies. I haven't used Macs much in the last five
> years, but my comments are still entirely valid, and will remain so even
> after everyone is using Linux on their desktop. It wouldn't surprise me
> if it was a Linux which allowed adjustment to just how pre-emptive the
> multi-tasking is.
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.
> 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. 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.
--
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>
------------------------------
** 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
******************************
