Linux-Advocacy Digest #962, Volume #27 Tue, 25 Jul 00 19:13:04 EDT
Contents:
Re: Hardware: ideal budget Linux box? (Re: I'm Ready! I'm ready! I'm (Bloody
Viking)
Re: Tinman digest, volume 2451743 (Tholen) ([EMAIL PROTECTED])
Re: Linsux as a desktop platform (void)
Re: The Failure of the USS Yorktown ("Joseph T. Adams")
Re: Would a M$ Voluntary Split Save It? (Leslie Mikesell)
Re: The Failure of the USS Yorktown
Re: Would a M$ Voluntary Split Save It?
Re: Would a M$ Voluntary Split Save It?
Re: Tinman digest, volume 2451743 (Tholen) (tinman)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bloody Viking)
Crossposted-To: alt.comp.hardware.pc-homebuilt
Subject: Re: Hardware: ideal budget Linux box? (Re: I'm Ready! I'm ready! I'm
Date: 25 Jul 2000 22:35:38 GMT
Aaron R. Kulkis ([EMAIL PROTECTED]) wrote:
: Which is why I am prepared to go overseas on short notice.
But there may be no place to run to. Becuse if our economy conks out, it'll
drag the rest of the planet down with it. Sort of a super-size global version
of the Asian debacle.
: Hey, if you didn't avail yourself to the education which was
: offered to you while you were young, then that's your problem.
Yeah, in Chicago public schools. If you like to talk about government
failures, you can have fun with this one.
: Maybe your purpose in life is to be a warning to others.
Yeah, the warning is choose your parents wisely.
: And government is no different from big business, fool.
If you really want job security and be a mercenary bully, you could be a cop.
That's a growth industry!
: You never know. Keep a certain amount of assets in cold, hard GOLD.
Exactly. You can't ever know until the crash occurs. If you have some land and
want a sure-to-keep-value asset, stockpile _petrol_. Petrol will get
ridiculously valuable come the inevitable oil crunch!
: big deal. When it happens, sell short and get on with your life.
But you better have the fastest modem! Selling short in a crash is like a
radio call-in contest. In the scenario of a full-blown Wall Street crash (for
any reason) everyone will be trying to modem- sell short. Also, you better
hurry too, as there's a 500 DOW point cut-off that drops the modem carriers
off the bus. Then, it's the people in the pit that only can sell short.
A better strategy is to attempt to anticipate the crisis on Wall Street to
beat everyone to the punch. The trick is being able to. Come the time of the
global oil production peak, inflation will rise and the economy will stagnate,
like in the late 1970s. But the peak will happen when about half the oil is
sucked out of the ground.
But it's possible that we may find alternatives to augment the energy supply to
power the economy, reasonably preserving its function. Then, we'll finish
using up all the fossil fuels, causing worse global warming. A good investment
for your retirement in this scenario is cheap land up north. Rich eco-refugees
can then buy homes on your development!
--
DANGER: Charles Darwin is the lifeguard of the gene pool. Swim at own risk.
------------------------------
Crossposted-To:
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
From: [EMAIL PROTECTED]
Subject: Re: Tinman digest, volume 2451743 (Tholen)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 25 Jul 2000 22:37:41 GMT
Jeff Glatt writes:
>> It was a Philip Glass joke
> Using the newsgroups for "entertainment purposes" again, I see
Having reading comprehension problems again, I see. I didn't
bring up Philip Glass.
------------------------------
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: 25 Jul 2000 22:32:45 GMT
On Wed, 19 Jul 2000 18:10:13 GMT, The Ghost In The Machine
<[EMAIL PROTECTED]> wrote:
>
>But there are a lot of issues here -- not the least of which being
>interrupt latency, the time it takes to switch from user mode running
>a process to kernel mode servicing the interrupt. (NT is notoriously
>bad in that respect, for some reason.) Of course, if someone does
>a mouse click and the GUI is paged out, all bets are off; might as well
>ask whether one can read a page in a given book which happens to be
>packed away in a shipping crate in the basement -- as opposed to stored
>in an open cardboard box in the closet, on a shelf in the library,
>or sitting on an endtable, propped open to that very page.
>
>I suspect that's a bigger problem than the PMT/CMT thing. (Note that
>VMS had the concept of "page locking", which means that a page in
>the working set could never be swapped out. Properly used, this
>could in theory increase responsiveness; improperly used, of course,
>it could gum up things horribly.)
How is "working set" defined by VMS? It seems to me that the VM
implementation can't guarantee sufficient physical core (for whatever
definition of "sufficient") to every process without some kind of
admission control.
Unix does have a mechanism for the superuser to explicitly lock pages
into core: see mlock(2). I checked three systems, running FreeBSD,
Linux and Solaris, and all support this call.
--
Ben
220 go.ahead.make.my.day ESMTP Postfix
------------------------------
From: "Joseph T. Adams" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: The Failure of the USS Yorktown
Date: 25 Jul 2000 22:42:08 GMT
In comp.os.linux.advocacy Loren Petrich <[EMAIL PROTECTED]> wrote:
: And another military folly: the battles of World War I. Generals
: would sometimes order large numbers of their troops to charge enemy lines
: -- lines with machine gunners in them. Rat-tat-tat-tat-tat, and large
: numbers of troops would be slaughtered. IIRC, the battles of Verdun and
: Gallipoli were particularly bad in that respect.
By the time of Vietnam, some folks discovered a better way to
deal with such "orders." Often by means of fragmentation grenades.
Joe
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: 25 Jul 2000 17:45:24 -0500
In article <RLJe5.5137$[EMAIL PROTECTED]>,
Daniel Johnson <[EMAIL PROTECTED]> wrote:
>> Daniel Johnson <[EMAIL PROTECTED]> wrote:
>[snip]
>> >Sure. What you do is you get a plug in that speaks the IBM 390's
>> >langauge (or the Sparcs). Somebody has to write one of course;
>> >in this case I believe Microsoft *has* written one, but if they
>> >haven't then IBM can do so. Or heck, you can hire someone
>> >to do so. Or even do it yourself, if you've the skill.
>>
>> It takes more than skill to write code that makes 2 proprietary
>> products interoperate.
>
>That's right- it takes *tools*; but Microsoft will gleefully sell
>you the tools you need.
Which tool is it that Novell needs to be able to write a
replacement for Active Directory that will fully interoperate
with everything else MS is shipping?
>> It also requires trade secret knowledge
>> about both products.
>
>Well, it make take trade secret knowledge about the IBM/390,
>I don't know, but what you need to know about Windows is
>available on the Web. MSDN rocks.
When every protocol is documented to the extent that it
takes to write a compatible replacement for the
product that uses it you might get away with saying
that. I don't think it is even close now.
>> However, if it doesn't
>> exist there may be no way to create one since you may not
>> be able to get access to the necessary secrets.
>
>Then again, you may. Certainly MS isn't standing in the
>way.
I'll believe that when I see fully compatible Active Directory
replacements.
>> And if it
>> doesn't work reliably you have no way to diagnose the problem
>> if it doesn't follow a published protocol.
>
>If you want to talk to an unmodified IBM/390, you'd better
>know the protocol its using. But if IBM wrote the plug in
>for you, presumably they'd know the protocol.
IBM provides most standard protocols. Why would I want to
obtain as many non-standard add-ins as I have machines instead
of just using the normal cross-platform standard programs on each?
>> >Plug in that plug in. Now you are speaking the IBM 390's
>> >protocol, and it can talk to you without itself being modified
>> >at all.
>>
>> To make this approach work you need a plug in for every
>> possible source to match every possible destination.
>
>No, only the ones you are using.
Yes, that's what I mean. I'd need a different set for each
possible combination of the ones I am using.
>> >Now, how do standard protocols help you with this, if
>> >the IBM 390 is going to be uncooperative. I had options:
>> >I can change the plugs in on my computer. What can
>> >you do but abandon your protocol?
>>
>> Using standard protocols, it is a 1-1 problem,
>
>A "1-1 problem"?
Each one provides only it's own implementation of the
cross-platform standard. One platform, one program,
regardless of the number of other endpoints.
>> every
>> endpoint only needs to know it's own trade secret
>> information to implement open standard protocols,
>> and by now most things have done so.
>
>You are still fixating on the Internet, I think. Many
>things have implemented the protocols needed on
>the Internet, but that's just one little corner of the
>industry.
If you do internet networking right, you automatically
do local networking right. Why do it twice?
>[snip]
>> >Such products are often the *best*, actually; in this industry,
>> >one often tries to differentiate oneself from ones competitors
>> >on quality and features.
>>
>> Or, by doing things that intentionally break the competitors
>> products...
>
>That doesn't work. What you do is offer features your
>competitor doesn't have. Once your users depend
>on those features, you've got them.
Exactly, but advertising features as being standard
when they aren't should be illegal. For the 'got them'
to happen, the customers have to be deceived.
>Microsoft has the insight to see that it doesn't matter
>if you *also* support the 'open' protocols. You've
>still got them.
Only if the open protocols aren't quite usable, and they
have carefully made sure of that and made it difficult
to tell what is standard and what is a MS-specific
extension. XML/XSL is the hot new thing. The standards
have nothing to do with Microsoft, and certainly nothing
to do with COM. But, poke around the examples that MS
provides and I suspect you will find that they show COM
objects as the way to do things - follow them and you might
as well forget that there is a cross-platform standard.
And they still don't do a standards-compliant XSLT.
>> >With plug-ins, you can plug in the module for the protocol the
>> >other end is using. Without them, you just need to make sure
>> >every 'end' is using the same protocol.
>>
>> An n x n choice versus an n x 1 choice.
>
>Hey, more choices are *good* right?
Having choices is good. Needing them is bad. Needing them and
finding out that you don't have them and can only get them for
one platform is worse.
>> >But it does not matter whether it is an open standard or not;
>> >proprietary standards work just as well as a 'common
>> >protocol'.
>>
>> That depends on the nature of the proprietary standard.
>
>Oh?
If the nature of the protocol allows a transparent transformation
between the open standard and a (perhaps more efficient) proprietary
version then it doesn't hurt to use the proprietary version
where it works.
>> Is it implemented for your target platform?
>
>This problem is no less great with 'open standards'.
Examples?
>> Can it be implemented?
>
>Well, if you have plug-ins, sure it can! :D
Where's that Active Directory server for the Sparc, then?
>[snip]
>> >So, what they define are standards because they defined
>> >the standeards for publuch interaction.
>> >
>> >Seems a bit circular.
>>
>> Yes, as are all matters of definition.
>
>No, not as a rule. Usually you define things in
>thems of *other* things.
Oh, then we can define the usefulness of Active Directory
in terms of how well the server runs under Solaris?
>[snip]
>> >However, I would submit that when you posted your
>> >message, you only gave me one alternative, not
>> >two: "MS has made a lot of non-standard stuff
>> >that won't interoperate with other things"; so
>> >I don't see that there was much to choose from.
>>
>> There isn't. But pick your own example of what
>> you think represents Microsoft's 'progress' that
>> you keep expounding has to be done in non-standard
>> ways.
>
>Given that choice, I'll take progress over standards! :D
What choice?
>But is that what you meant in the first place?
I was asking for examples of something that MS has
done that can't be done by following cross-platform
standards. Please give some examples of this 'progress' that
can only be done at the expense of trapping the user into
a single platform.
>[snip]
>> >> No, I think many people notice - they just don't know what
>> >> to do about it. After all, if they were expert HTML
>> >> producers they wouldn't be using FrontPage.
>> >
>> >Is that beause there is no other product that non-experts
>> >can use to make HTML?
>>
>> No, it is because Microsoft is very good at selling their
>> products, or bundling them with other products if they
>> have an ulterior motive to get them on more desktops.
>
>I think part of your argument is missing. This doesn't
>seem to lead anywhere as it stands.
Sell, give away, embed tools that claim to follow standards
but in fact only work correctly with other MS products. I
don't have to make this argument - the Halloween document
explains the philosophy.
>[snip]
>> >Hmmm? I hate to say this, but carrying attachments does
>> >mean *some* kind of protocol to say "this bits an attachment";
>> >if the sender does not know it, it can't attach files. If the
>> >receive does not know it, it can't decode them.
>>
>> Ah, that would be a problem for systems that build everything
>> into one program.
>
>IE, not Windows. :D
Hmmm, apparently the applications don't understand the concept.
>How many programs are involved are irrelevant, however.
>> On systems were it is easy to manipulate
>> data through pipes or use files as intermediate storage,
>
>IE, Windows. :D
Which Windows mailer lets you easily pipe individual messages to
your choice of other programs?
>> programs other than the mail client can be added to
>> handle the decoding of attachements and manipulation of
>> the multimedia parts.
>
>Oh course. But those programs must know the protocol;
>I don't think you've bought yourself anything here.
Yes, for an incremental change: you just add an extra content-processing
program in the places that need it without distrupting anything
else, including the way people have been reading their mail.
At his convenience, each user can switch to a new mailer
if he wants, and is ready.
>> >I think you are mistaken. While transport changes wouldn't
>> >be requiried, some kind of addition or change the the
>> >protocols is needed to add attachments to a protocol that
>> >hasn't got them.
>>
>> Since the protocol is publicly known, programs to deal with
>> them can be added without needing any trade secrets.
>
>Yes. But this is true even if the protocol isn't publically
>known.
How do you add a protocol to a new platform if you don't
know it?
>> If
>> the attachment is text, you can just ignore the wrappers
>> that make it an attachment and view it with any mailer
>> that knows about text.
>
>Really. How do you deal with CR/LF translation then?
The transport already takes care of the local text conversions,
even to non-ascii platforms. That's the point of cross-platform
protocols.
>> If it isn't, you can hand it off
>> to a program that does know about it, or just knows how to
>> extract the attachment to a file. If the file itself
>> turns out to be some proprietary format, you are still
>> screwed, though.
>
>Well, unless you have a program that can cope with
>that format. Proprietary or not, makes no difference.
Of course it makes a difference. If you know the format
you can write the program, unless someone else beats
you to it. If it is kept secret you are forced to wait
until someone wants to sell you the ability to read
your own data.
>[snip]
>> >Oh, good. Then you've no objection to Micorosft making up
>> >their own protocols, or whatnot.
>> >
>> >I apologize for insinuating that you felt otherwise.
>>
>> I do feel that they should be advertised as such, though,
>> instead of using the same names that others use for
>> something different (domains, java, html, etc.).
>
>I think it's possible to be too picky about that;
>Calling IE's language something other than
>"HTML" is going to obfuscate more than it clarifies,
>in my view.
No, the correct way would be to use the version number
of the specification that it completely supports. Anything
else is deceptive although knowing about the extensions
might be of use to the few people who want to abuse them.
>[snip]
>> >This is, of course, where we part company:
>> >I don't define "interoperation" like this.
>> >
>> >But suppose we did. Why should anyone
>> >*want* to be interoperable, if it is merely
>> >synonymous with "follows standards"?
>>
>> So that you remain free to choose the vendor
>> of the next product you will use.
>
>Why does "follows standards" buy you anything
>that way?
The cross-platform standards assure you that you
can change any component without modifying the
others.
>> Why would
>> anyone want to give up this choice by installing
>> something that does not follow standards?
>
>I would claim that following standards doesn't
>give you any choices you didn't already have.
And you would be wrong.
>[snip]
>Did you? I've forgotten already.
>
>> Would you consider it acceptable to have
>> to buy every network component from the same vendor
>> to get them to interoperate at the hardware level?
>
>Yes, of course that's acceptable. It's just not *ideal*,
>and it is not the situation we see with software, either.
Except J++, Frontpage, anything that uses COM, Active Directory,
MS-CHAP, and the list goes on.
>> If not, why is it OK for the software protocols
>> to have to come from a single vendor?
>
>They don't.
Where's that non-MS Active Directory server?
>> >The flexibility is useful to have.
>>
>> But that is not what you are describing for software.
>> You are allowing one vendor to dictate a proprietary
>> protocol.
>
>Surely. But I'm also 'allowing' that vendor to support
>*multiple* protocols- like that PCI-and-ISA computer.
Also? Why would anything ever limit this ability? It
is doing the standard ones correctly that is important,
though, as opposed to propagating vendor-specific extensions.
>Heck, I'm 'allowing' that vendor to provide APIs to
>add new protocols later. Find hardware that'll do that!
Hardware very often does that. Otherwise we wouldn't be
able to plug 10 or 100M Ethernet into the same connector
or call a 56k modem with a 2400 baud one. There have been
modems that only talked to others of the same brand and
vintage. Users wisely dumped them in favor of ones that
followed standards for interoperability.
>[snip]
>> >Nope. But I don't see that I have to use *your* solution
>> >to this problem, when I don't think it works as well
>> >as Microsoft's does.
>>
>> Buy some non-Intel compatible CPUs and see how well
>> Microsoft's solution works.
>
>Ah, you cut me to the quick! Well, as quick as I ever
>get, anyway. :(
Which part of cross-platform don't you understand?
>But the *idea* of plug-in software libraries is,
>one hopes, not unique to Microsoft. I don't see
>any fundamental reason why a non MS OS can't
>do it just as well as Microsoft.
Don't all systems use software libraries? MS hardly
invented the concept. They just gave everything it's
own bizarre API so the programs you write can't easily
be ported to other platforms.
>[snip]
>> Standards are defined for character sets. If the page
>> mentions it correctly, then a conforming browser can
>> be made to display it correctly.
>
>Not so. You have to have the appropriate fonts installed,
>and some of them are *big*; they are not standard issue.
>
>Conforming browsers are sometimes quite unable
>to display these pages.
I don't see how needing to have a standard component that
would have a fail-over substitute mapping relates in any way
to needing extensions that are only available from a
single vendor on a certain platform.
>[snip]
>> >> The parties involved should know exactly what they are
>> >> doing.
>> >
>> >Pretty harsh. Only experts are allowed on your Internet then?
>>
>> No, just informed consumers.
>
>Perhaps your notion of "exact" is not as severe as
>mine.
>
>Are "informed consumers" expected to know the ins-and-outs
>of protocols and formats?
They have to now, or they are deceived into using vendor-specific
extensions that will not work with competing products. I'd
prefer that they did not need to know this and that they
not fall into the vendor's trap.
>[snip]
>> >So you say. There is a middle ground: There are lots
>> >of people who Just Don't Care (tm).
>>
>> Even so, I think they should be permitted to know that
>> they are assisting Microsoft in their evil plan instead
>> of just thinking they are generating normal web pages.
>
>I think they might not agree with you about the Evil Plan (tm)
>part.
I think they would if they understood it. We should have
a truth-in-labeling for software, where anything that
uses a name of a cross-platform standard had to be specified
with a version number where it has full compliance with
the standard, and vendor specific extensions had to be
listed separately.
>[snip]
>> >> The same browser that permits active-X? Fat chance?
>> >
>> >:D You may have something there.
>> >
>> >If the browser will not enforce the sandbox, you are just out of
>> >luck, standard Java or no.
>>
>> If COM objects are allowed in applets, how can the browser
>> enforce anything?
>
>How about if it only allows *server side* COM objects?
Then it's not an applet and the security doesn't apply anyway,
and it doesn't have to be portable - why use java?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: The Failure of the USS Yorktown
Date: Tue, 25 Jul 2000 22:50:23 GMT
On 25 Jul 2000 22:42:08 GMT, Joseph T. Adams <[EMAIL PROTECTED]> wrote:
>In comp.os.linux.advocacy Loren Petrich <[EMAIL PROTECTED]> wrote:
>
>: And another military folly: the battles of World War I. Generals
>: would sometimes order large numbers of their troops to charge enemy lines
>: -- lines with machine gunners in them. Rat-tat-tat-tat-tat, and large
>: numbers of troops would be slaughtered. IIRC, the battles of Verdun and
>: Gallipoli were particularly bad in that respect.
>
>By the time of Vietnam, some folks discovered a better way to
>deal with such "orders." Often by means of fragmentation grenades.
I know someone from Force Recon that turned down OCS
due to this. Apparently, 2nd Louie's were more prone
to being shot by their own command than by the Cong
or NVA.
--
Unless you've got the engineering process to match a DEC,
you won't produce a VMS.
You'll just end up with the likes of NT.
|||
/ | \
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Tue, 25 Jul 2000 22:51:56 GMT
On Tue, 25 Jul 2000 21:40:50 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article
><[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
>-- snip --
>
>> You clearly don't understand the difference between 1) not *allowing*
>> Linux boxes to be sold, which you haven't proven and 2) there being no
>> demand for Linux boxes. And if there was demand, I have every reason
>> to believe CUSA would stock Linux boxes.
>
>You clearly don't understand that 1) "*allowing* Linux boxes to be sold"
That is also an issue as well. Infact, this effective lockout
of the major players probably influences the smaller players
quite a bit due to the associated network effects.
>is *NOT* the issue and 2) the real reason why "there [is] no demand for
>Linux boxes."
>
>Hint: you have already admitted to that real reason.
[deletia]
--
Unless you've got the engineering process to match a DEC,
you won't produce a VMS.
You'll just end up with the likes of NT.
|||
/ | \
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To:
comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Tue, 25 Jul 2000 22:53:55 GMT
On Tue, 25 Jul 2000 21:35:35 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>In article
><[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> On Mon, 24 Jul 2000 15:51:03 GMT, [EMAIL PROTECTED] wrote:
>
>-- snip --
>
>> Did you miss the part where I said CompUSA can add whatever machines
>> they want and put any OS they want on them?
>
>Nope, didn't miss it at all. I simply ignored it due to its being
>*completely irrelevant* to the discussion.
...such an example is a bit closer to being meaningful.
However, you still have the problem of the mundane
consumer being more interested in going into CompUSA and
just buyind a box as they would a DVD player in BestBuy
or an iMac in CompUSA.
[deletia]
--
Unless you've got the engineering process to match a DEC,
you won't produce a VMS.
You'll just end up with the likes of NT.
|||
/ | \
------------------------------
From: [EMAIL PROTECTED] (tinman)
Crossposted-To:
comp.sys.mac.advocacy,comp.os.os2.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Tinman digest, volume 2451743 (Tholen)
Date: Tue, 25 Jul 2000 18:55:00 -0400
In article <VEof5.3242$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Jeff Glatt writes:
>
> >> It was a Philip Glass joke
>
> > Using the newsgroups for "entertainment purposes" again, I see
>
> Having reading comprehension problems again, I see. I didn't
> bring up Philip Glass.
Reading comprehension problems, Davie? You told a joke (or tried to), and
that's entertainment (well, not really, but an attempt at same). ("
--
______
tinman
------------------------------
** 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
******************************
