Linux-Advocacy Digest #321, Volume #28            Wed, 9 Aug 00 02:13:06 EDT

Contents:
  Re: Am I the only one that finds this just a little scary? ("Anthony D. Tribelli")
  Re: Would a M$ Voluntary Split Save It? (Leslie Mikesell)

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

From: "Anthony D. Tribelli" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Am I the only one that finds this just a little scary?
Date: 9 Aug 2000 04:54:04 GMT

Perry Pip <[EMAIL PROTECTED]> wrote:
> Anthony D. Tribelli <[EMAIL PROTECTED]> wrote:
>>Perry Pip <[EMAIL PROTECTED]> wrote:

>>> Interesting. That URL you posted to an apology from a
>>> GCN editor: 
>>> http://206.144.247.86/archives/gcn/1998/november23/20.htm
>>> which supposedly absolves NT has a link to this as the supposedly 
>>> accurate account:
>>> http://206.144.247.86/archives/gcn/1998/november9/6.htm
>>>
>>>    "The Yorktown uses dual 200-MHz Pentium Pro systems from 
>>>    Intergraph Corp. of Huntsville, Ala., to run NT over a 
>>>    fiber-optic, asynchronous transfer mode LAN."
>>>
>>> Dual P-pro's running NT on an ATM LAN. From the same URL:
>>>
>>>    "The Yorktown last September suffered an engineering LAN 
>>>    casualty when a petty officer calibrating a fuel valve 
>>>    entered a zero into a shipboard database, officials 
>>>    said. The resulting database overload caused the ships 
>>>    LAN, including 27 dual 200-MHz Pentium Pro miniature 
>>>    remote terminal units, to crash, they said."
>>>
>>> 27 dual 200-MHz Pentium Pro's running Windows NT crashed. That's plain
>>> english. No semantics. 
>>
>>Yet again you are falsely equating "LAN" and "terminals" with WinNT. 
>
> The terminals were running WinNT. They crashed. Now if it wasn't a
> hardware problem, the OS is at fault. There are no mention of any
> hardware failure in all the press about this incident. If you want to
> have a twisted interpretation 'application crash == terminal unit
> crash', that's your perogative ...

Nothing twisted about that at all. When a computer is dedicated to running
a single application and when that application is dead and the terminal
unusable people will often use language like the "terminal is crashed". To
assume that the OS is at fault is an awfully big assumption. 

> ... Face it Anthony, neither of us can fully prove it either way ...

I'm not asking you to prove it. I'm merely asking where you learned that
WinNT itself crashed, and following up your offerings asking if you have
anything that is not guesswork based on other people's guesswork. I'm not
trying to prove WinNT did or did not crash. I don't really care if it did
or did not. I'm just looking for clear and accurate information. 

> ... My interpretion isn't going to change on
> your account. So why do you waste your time?? You are the one
> stretching the English language more than me.

Covered by both paragraphs above.

>>If I run a SVGA game on my Linux box
>>and it locks up the console and I have to hit the reset switch should we
>>call that a Linux crash? Using your logic we would have to. 
>
> No, becuase in Linux, GDI is not in the kernel, so you can crash a
> console without crashing the OS. In WinNT you can't.

The Linux box was unusable and unresponsive, hitting the reset button was
required. If someone utters the words "this computer crashed", using the
logic you present with respect to WinNT we must also say that Linux has
crashed. 

>>Please provide a credible reference to the app crashing WinNT in this
>>incident. Nothing you have offered shows WinNT itself had crashed. 
>
> Find a *credible* refernce to WinNT not crashing. Face it Anthony,
> neither of us can fully prove it either way.

You claimed it did, it's your burden of proof. I just want to know if your
opinion is an informed one or one of the typical polticial and/or
religious ones. Also, you are asking me to prove a negative, I remember
something from a math class about ... 

>>You are quoting the original GCN article that GCN later disconfirmed:
>>
>
> Disconfirmed for political reasons. Furthermore, the original GCN
> article contains quotes from people you cannot disconfirm, as that
> would imply GCN blatantly misquoted those people.

You have offered no evidence of such political maneuvers covering up for a
WinNT crash being responsible for the incident. You seem to conveniently
trust articles from a period when less was known, and agree with you, and
to conveniently manufacture political intrigue for articles written when
more was known, and disagree with you. 

The quotes you refer to, some of which you offer below, do not say WinNT
itself crashed or contributed to the incident. That is an erroneous
extrapolation some have made, that is part of the "early speculation". It
is this "early speculation" that has been disconfirmed. 

>>>       "Ron Redman, deputy technical director of the Fleet Introduction
>>>       Division of the Aegis Program Executive Office, said there
>>>       have been numerous software failures associated with NT
>>>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>       aboard the Yorktown."
>>>       ^^^^^^^^^^^^^^^^^^^
>
> This quote still stands.

Stands as out of context, ambiguous, and unclear as to whether it refers
to WinNT itself or a system built on a WinNT-based platform as opposed to
a Unix-based platform. See below. 

>>>       "Refining that is an ongoing process", Redman said. Unix is a
>>>       better system for control of equipment and machinery, whereas
>>>       NT is a better system for the transfer of information and data.
>>>       NT has never been fully refined and there are times when we
>>>                                           ^^^^^^^^^^^^^^^^^^^^^^^
>>>       have had shutdowns that resulted from NT.
>
> This quote still stands.

Stands as out of context, ambiguous, and unclear ..., see above, and see
below. 

>>Is he refering to the WinNT operating system specifically or the switch
>>from a UNIX environment to a WinNT environment? 
>>These statements are
>>unclear and from reading the entire article as a whole and in context it
>>seems to refer to the switch to a WinNT environment. 
>
> The article towards the end says some "command and control"
> applications are being moved to NT. Redman does not say the problems
> he is pointing out are associated with that coversion. Again, you are
> trying to stretch the English language more than me.

He also does not say WinNT crashed and contributed to the incident. As I
said the statements are unclear in context reading the article as a whole. 

>>For example the above
>>individual also says: 
>>
>>    If we used Unix, we would have a system that has less of a
>>    tendency to go down.
>>
>>So either we have Unix crashing also or these people are speaking of an
>>entire system not one specific component of the system which is the OS. 
>
> It would be unreasonable for him to claim that Unix never crashes. But
> it is certainly reasonable to claim that Unix is much more reliable
> than NT. Your struggling.

Bad guess, previously you offered evidence of WinNT being able to crash in
a completely unrelated incident as evidence against it in this particular
incident. 

>>>      "Because of politics, some things are being forced on 
>>>       ^^^^^^^^^^^^^^^^^^^
>>>       us that without political pressure we might not do, 
>>>       like Windows NT," Redman said. 
>>>            ^^^^^^^^^^
>>>
>>> Because of politics, Anthony, that's why the chief engineer and the
>>> software developer are lying. Exactly what time of the day yesterday
>>> were you born??
>>
>>Politics forced a shift from Unix to WinNT, OK, but that's a different
>>issue. You have offered no evidence that they are lying. 
>
> Politics is the issue. It explains why the story has *changed*. If
> their were no politics, stories like this one wouldn't change. Nor
> would the real facts (specifically how a database failure cascades to
> an engine failure) be left out.

Again, you are assuming that the story has changed, and that it is not
simply that initial speculation was off. 

>>Oh and don't
>>forget the news agency, you accuse them as well. 
>
> The editor is merely appealing to his readers. Again politics.

Another politically self-serving guess on your part? :-)

>>Also you are extremely naive if you don't think there is politics at work
>>on both sides here.
>
> Sure, but Redman and others have no apparent reason to cover their
> asses, or to appeal to someone.

I'm speaking of those who interpret their statements as to saying WinNT
crashed and contributed to the incident. However since you seem to be able
to manufacture intrigue on the pro-NT side and incapable of imagining
intrigue on the other side I'll play Devil's Advocate and manufacture
intrigue on the pro-Unix side. These guys know Unix and would rather stay
with Unix, regardless of whether WinNT can or can not do the job equally
well. They are covering their careers, a shift to WinNT weakens their
employability. Again, I AM NOT saying this is occurring. I am only
demonstrating that politics and intrigue could be manufactured on either
side. I think the political motives you have offered in all seriousness
and those I have offered only as a hypothetical example are both equally
uninformed. 

>>assumptions. 
>>
>>> No semantic's please:
>>> http://www.cs.clemson.edu/~steve/Spiro/stories/node75.html
>>>  
>>>      "crash all Lan Consoles and miniature remote terminal units"
>>
>>Again, no one says the OS crashed, 
>
> Just the machines running the OS.

When a computer is dedicated to running a single application and when that
application is dead and the terminal unusable people will often use
language like the "terminal is crashed". To assume that the OS is at fault
is an awfully big assumption. 

>>>       "A major computer crash...."
>>
>>Again, no one said the OS crashed. Again, words being tossed about rather
>>loosely. 
>
> Just the machines running the OS.

As I said, words being loosely used. See above paragraph.

>>> And what do you do when an NT system crashes??
>>> http://jerrypournelle.com/reports/jerryp/Yorktown.html
>>>
>>>      "out of service for half an hour or so while the 
>>>       NT system was restarted"
>>>       ^^^^^^^^^^^^^^^^^^^^^^^
>>
>>System, not OS, see earlier arguments. 
>
> So then why not say "Pentium Pro system was restarted", or "Database
> system was restarted", or just "system was restarted". Why do they
> always include NT??

Why not? I often refer to my NT-box doing this job, my Linux-box doing
that job, my Mac doing some other job. 

>>>      "an NT system blew up"
>>
>>System, not OS, see earlier arguments, and again you greatly distort
>>things. This is a reader's general characterization of the incident.
>>This same reader starts his email with:
>
> Again, why not "Pentium Pro system blew up", or "Database
> system blew up", or just "system blew up". Why do they
> keep saying NT??

Not "they", "he". "He said ..." Why he said "an NT system blew up", well
maybe his also saying "I don't know a lot about the specific incident" is
a clue. 

>>    I don't know a lot about the specific incident.
>>
>>This is what you consider evidence that WinNT crashed, an offhand comment
>>by someone who starts off admitting they don't really know a lot about
>>what happened? 
>
> No worse than a Government official covering his ass. I personally was
> not in the Oval Office with Bill and Monica. Does that mean it was
> innapropriate for people to second guess Bill of and accuse him lying
> in the testimony where he did??

The big money and politics against Microsoft would probably have uncovered
an actual coverup regarding WinNT itself. To continue with your theme,
where's the DNA stain showing unambiguously and clearly that WinNT crashed
and contributed to the incident? :-)

> Face it Anthony, neither of us can fully prove it either way. But one
> thing we do know is that NT crashes, ...

As does Unix, however WinNT being able to crash does not demonstrate that
it did crash or contribute to this incident. 

> ... ALOT. The following study,
> provided under contract with Microsoft, shows that NT4, running
> desktop applications crashes on average once every 919 hours
>
> http://www.nstl.com/html/windows_2000_reliability.html
>
> And this is desktop use. In a custom application environment like the
> Navy uses you are likely to get even more failures ...

Why, it is a simpler environment with fewer variables? Known verified
hardware vs what? The study does not name the hardware used, who knows
what the folks in the "real world environment" had. A computer/remote
terminal running one dedicated application vs a general purpose desktop
computer running what kind of variety? How much testing and review will
the Navy's final product receive compared to the desktop's apps? I don't
think the two environments are comparable. 

> ... So it not
> unreasonable at all to make my judgement call that NT4 crashed on the
> Yorktown, and that the Government officials involved in the decision
> to use NT are trying to cover up that fact. You, of course, can make
> your own judgement call your own way. Neither of us can absulotely
> prove it.

Well if you are going to refer to WinNT crashing as being your judgement
call rather than a known fact we don't have much to argue about. 

>>The press is interested getting readers not providing accurate
>>information. 
>
> And GCN is interested in protecting their readership: Government
> officials.

Then it doesn't make sense to protect WinNT. Government officials seem to
be against Microsoft. Politics is not as one sided as you suggest. :-)

>>> ... If you want a system to be the most reliable, you have to
>>> expect components to fail and be ready for it, no matter what
>>> OS/hardware you use. Othewise, it's not a "smart" system at
>>> all. Hell...even the fscking controls for air conditioning systems at
>>> shopping malls have some sort of manual overide. This is why I believe
>>> the Navy is hiding something from the public. 
>>
>>Where are you getting this notion that there are no manual controls?
>>The fact that there are these terminals spread around the ship and that
>>they want to use any one of these to control equipment does not mean
>>there are no manual controls. 
>
> I was referring to both manual controls and manual commanding. Manual
> commanding would be the ability to send commands directly to the
> engines from a remote console not in the engine room, but without the
> use of a "smart system" or it's database. Manual control would be from
> the engine room.

OK, but there was no suggestion that manual controls or commanding was
missing at all. The missing backup systems referred to were electronic in
nature, and reported to be missing only because it was a test platform. 

>>In fact you need to read your own citations
>>more carefully. They refer to captains locking the crew out of the engine
>>room during automated runs, no need to do so if there are no controls
>>in there.
>
> And so the crew doesn't need to know at all how to use the manual
> controls (or manual commanding)?? On any automated system with a
> manual back up, one of the biggest concerns is that operators will not
> know how to take advantage of the manual backup. What happens if enemy
> fire takes out the machines that this "smart ship" database
> on. Training the crew to recognize failures of the automated systems
> and how to manually intervene to me would seem critical.

I think your imagination is overworked again. I think the room was emptied
as part of a fully automated test, not any sort of standard procedure or
practice. 

Tony
==================
Tony Tribelli
[EMAIL PROTECTED]

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

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: 9 Aug 2000 00:10:10 -0500

In article <Sunj5.497$[EMAIL PROTECTED]>,
Daniel Johnson <[EMAIL PROTECTED]> wrote:

>> >Being under the "control" of multiple vendors is hardly
>> >an improvement. :D
>>
>> With multiple vendors, you are the one in control.  They are
>> legally constrained from even discussing prices with each
>> other.  If one or more of the choices are free, so much the
>> better.
>
>Prices are just not the problem.

They may not be for the basic system and the bundled clients,
some of which claim to use standard interoperable protocols.
However, the price becomes a big problem when the claimed
interoperability fails and you are annoyed into installing
MS Advanced Server, Exchange, IIS, RAS, etc. and then try
to keep them working.

>[snip]
>> >But aren't you glad that MS provides the services you
>> >require, even though apparently nobody else does? :D
>>
>> No, I don't care to be trapped into using this server, even though the
>> clients are tied to an OS with a monopoly on the desktop.
>
>Hmm. Is it bad for another company to provide
>a service you need, if that company is the only
>one doing it?

Yes, when that same company is bundling the thing that
causes you to need that service with every PC.

>Or is it just when Microsoft does it, that it is bad?

No one but Microsoft does that, or can do it.  It would be equally
wrong for any other company that had an effective monopoly on the
PC OS market to keep adding things that require you to buy more
expensive server side programs.

>> No, it would be nice if the client would interoperate with
>> other systems correctly.
>
>I think we've gone round on this one enough times. :D

No, nothing has changed yet.

>[snip]
>> That is not the correct way to do IP name resolution and it can
>> indeed cause interoperability problems.
>
>That isn't DNS name resolution. That's what happens when Windows
>is using DNS and also NetBEUI, with NetBEUI configured to
>go first.
>
>It tries NetBEUI, and if it finds the target- that's it, you've got 'im.
>
>If it doesn't, it tries the next thing. Maybe DNS.

Actually it does netbios broadcasts over all configured protocols
including netbios-over-IP first, or it will check with a
WINS server.  DNS comes last.

>[snip]
>> >I realize you don't like being dependant on one vendor; I, on the
>> >other hand, don't like being dependant on one protocol.
>>
>> There is more than one cross-platform standard protocol.    Who
>> ever said you should use only one?
>
>I must do so to make your 'interoperability' approach have
>any prospect of working.

What does that mean?  There are protocols for each purpose.

>Of course, I realize that what you are after is standards *for their
>own sake*, and not to facility communication or anything.

Not quite.  Each layer just has to perform its function
correctly.  The correctness of the software layers are just
as critical as the hardware.  Non-conforming software
is as annoying as an ethernet card that sends 10% of
its packets in a non-standard way that causes other brands of
cards to reject them.  And the Microsoft approach to standards
has approximately that effect.

>> >That is why Microsoft does not endanger their own grip on their
>> >customers when they pour so much effort into interoperating;
>> >the barrier they are removing is not the one keeping their customers
>> >in the fold.
>>
>> And how do you describe that particular barrier?
>
>I thought I had described it.
>
>They do things for their customers their competitors
>do not do.

BSOD's, GPF's?  Bundled client software that doesn't quite
work with a competitors server even though it uses the
names of the same protocols?

>[snip]
>> >Microsoft does not use protocols to lock you into their
>> >product; they try to offer features their competitors do not
>> >offer instead.
>>
>> Then why won't their kerberos client interoperate fully with
>> a standard kerberos server?  How can you describe this as
>> anything but using a protocol to lock you in?
>
>I would describe it as "using a feature to lock you in"; they've
>provided a feature standard Kerberos hasn't got, and
>they figure it will take awhile before other Kerberos vendors
>provide it.

If anyone 'needed' this feature before they bundled the clients
for it, you might have a point.  But it isn't a feature
the users needed in the first place.

>Admittedly, the protocol addition is part of the feature,
>so you aren't completely off base. But that's not the
>whole story.

It is the whole story until they give out enough information
for someone else to make a competing server.

>> In the cases where it works you are.  If you run your email
>> service over SMTP/POP/IMAP you are not vendor-locked at
>> all.
>
>Oh, I don't think that's true.
>
>After all, you were the one telling me how if you stuck
>to these protocols you didn't get access to all
>of Exchanges features. Are the users going to stand for
>for that?

No, it is only Outlook that doesn't provide the same features,
and that is mainly with the address book when you use LDAP.
The actual send/receive operations are OK.

>Indeed, why should they?

Yes, there are plenty of email clients so there is no reason
to put up with a problem in Outlook.  StarOffice has a
reasonable replacement...

>[snip]
>> None of which require proprietary extensions.
>
>They do not require them per se. But the box you
>are trying to interoperate with migth do so.
>
>>  If you do
>> use them, then there is only one way to handle them which
>> is to do whatever the vendor controlling it says, like it
>> or not.
>
>I'm not sure that's true. You do have to implement
>the proprietary protocol, if you are doing that kind of
>thing yourself, but it's hard to see what you are getting
>at beyond that.

It is pretty rare to be able to implement a proprietary
protocol without access to trade secret information.  So
you are back to dealing with the vendor who may or may
not care about your platform.  With standard protocols
you don't need secret information and anyone interested
in the target platform can implement them.

>[snip]
>> Pointing out the actual failures to interoperate isn't exactly
>> tut-tutting.
>
>That's true. However, the 'tut-tutting' I refer to i syour
>habit of saying that the proper response to computers
>is to declare them "incorrect" at leave it at that.
>
>That's tut-tutting. It isn't helpful for doing anything
>useful.

It is the same response I would have about finding an
ethernet card that generates a certain percentage of
non-standard packets that other vendors' cards don't
process correctly.  I'd say it is broken and stop using
it.  What else can I do?  If there is something more
I could do to stamp out interoperability problems
I might be willing to try, but switching to all
broken-but-matching equipment seems like the wrong
direction to me.

>[snip]
>"All Windows, All the Time" is at least a *possible* strategy;
>it seems to me to be no better than your "All Unix All The Time"
>approach, but there you go.

You seem to have a fixation about unix - I've only mentioned
cross-platform standards.

>> How can something interoperate if it is a single-vendor thing?
>
>I've explained the technical end of it to you. Now, I suppose
>you are going to tell me again that "interoperate" means
>"uses committee-defined standards, not vendor defined
>standards" or something like that.

No, you haven't explained why you continue to call it
interoperation when there is nothing 'inter' about it.

>Personally, though, I think that attitude shows a certain
>disconnection from the reality that computers are tools
>that solve problems.

No, it shows an observation that in fact not all computers
are Wintels and that the problems that need to be solved
cross many vendors' platforms and are going to continue
to do so.  In fact many of the problems that need to
be solved have to do with MS products' lack of compatibility.

>>  As long as you have a common ground
>> you have your choice of commodities to use it.
>
>Not necessarily. If I 'standardize' on Microsoft, as many
>have done actually, I have relinquishing my choices
>so as to get a common ground for all my systems.

Yes, you can sell your own soul, but what about everyone
else?

>Microsoft's great insight in this area has been that
>interoperability is a tool for getting people to do
>*exactly* that, not an insulation that somehow prevents it.

No, it is the pretense of interoperability that doesn't
quite work that forces people to do as you suggest
above and give up on real, working interoperability.
I don't advocate giving up.

>[snip]
>> >> What part of the phone network is allowed to make up their
>> >> own standards instead of interoperating across platforms?
>> >
>> >Remember MSCHAP? That 'standard' MS made up on its
>> >own? You were complaining about it earlier.
>>
>> That doesn't relate to the phone network standards (unless perhaps
>> you include something about foul language...).
>
>It is layered on top of them. Is it okay for MS to come up
>with their own web-page language, if its embedded
>inside of HTML, rather than as extensions to HTML?

Yes, there is a mechanism provided for that.  Or you
can use the HTTP transport protocol to deliver any kind 
of content you like.  People do that all the time without
making HTML that displays incorrectly on standards conforming
browsers.

>Is there really a *difference* that matters?

Yes.  The difference is that someone creating a page of
MS-proprietary stuff would not be fooled into thinking
they were following a standard that will display on
normal computers.  And back to the phone line standards,
doing something different *not* layered over the standard
hardware protocols would likely damage the connected equipment.

>[snip]
>> >I certainly *do* count that trouble.
>>
>> But for a LAN you don't need them.
>
>Then you do need to assign and track
>the addresses yourself. Cheaper, but
>more trouble. Or you need to set up
>a DHCP server. Trouble.

Well if you think MS and IE are responsible
for the popularity of browsing, you can
blame them for making everyone need IP.
(They aren't, of course, but you can think
that if you want)
 
>[snip]
>> >Using IP in the first place isn't really the "easy" route yet;
>> >though MS is apparently trying to make it so. It is easier
>> >to use NetBEUI for your LAN and let IE set up IP for
>> >your internet connection only.
>>
>> How can it possibly be easier to do something twice than
>> just one of the ways?
>
>You aren't doing the IP setup you'd have to do to make
>it work on a LAN. No DHCP server. No manual address
>tracking. Just let the wizard set it up. :D

And no browsing...  Even with IE glued tightly
to the OS.

>>  And what do you do when you need
>> one more machine on the network than Netbeui will support?
>
>Then you need to look for alternatives.
>
>Fortunately, out there in the real world, there's little
>stigma associated with that. You aren't somehow
>condemned for not using the same protocol
>the next guy is.

Really?  How many people will put up with a LAN where
a browser doesn't work and you can't easily share
information though a web server?

>> But that means everyone on the network has to have their
>> own separate ISP connection.  What is the point of having
>> the network?
>
>That is, indeed true. It's a good example of how Unix-
>type protocols don't interoperate, leaving it to other
>to do the heavy lifting.

I missed something here.  What are you talking
about?

>It's a pity, really, but fortunately companies like Microsoft
>have a strong incentive to pick up the slack and
>find some solution that will work.
>
>Or at least try. I don't think they've suceeded
>as yet.

At what?  Did you mean sharing an internet connection? Unix
has done that for years (it has done normal routing
from the beginning and address translation has been around
for quite a while).

>[snip]
>> I've tried to avoid NetWare but the one time I had to use
>> it (to get connectivity to the Postscript RIP for a Xerox
>> Docutec printer) I found the Win95 Netware client didn't
>> interoperate correctly (surprise?) and had to install Novell's
>> client instead.   Maybe this has been fixed by now...
>
>Betcha the MS NetWare client didn't have some nifty
>new feature the Novell one did.
>
>MS isn't the only one who can play that game.

No, it was just something in the MS client that did not
work.  I think this was very early win95 and perhaps
fixed in the service packs.  Or maybe it was just to
make the netware server look bad and encourage users
to replace them with NT servers instead.

>> Still, this has nothing to do with netware. It is the clients
>> tied to the desktop OS that need the services - they should
>> be able to get them from any server instead of requiring one
>> from the same vendor.
>
>You are trying to make "we can't let anyone offer services
>beyond what their competitors already have" sound good.
>
>You haven't a prayer of managing it.

So you *like* the concept of giving away clients that
pretend to, but don't quite, work with competitors'
servers?

>[snip]
>> >I know, I know, MS can't be "allowed" to produce a better product
>> >because it is very inconvinient for MS's competitors if they do.
>>
>> It is very inconvenient for everyone when they produce a product
>> that claims to be better, and uses the names of interoperable
>> protocols, but turns out not to interoperate.
>
>MS products generally  *do* interoperate- until you use the new
>features.

Sometimes, sometimes not.  But even then you can't tell when you
are using standard features and the ones that will not work
with a competing product, so users are deceived into doing
things that won't work on other platforms even though the
MS product claimed compatibility.

>Clever, isn't it?

I think I would choose a different word.

  Les Mikesell
   [EMAIL PROTECTED]

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


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