Linux-Advocacy Digest #269, Volume #28 Sun, 6 Aug 00 21:13:04 EDT
Contents:
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
----------------------------------------------------------------------------
From: "Daniel Johnson" <[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: Mon, 07 Aug 2000 00:34:58 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8m50dc$fls$[EMAIL PROTECTED]...
> In article <AkFg5.13437$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
> >[snip]
[snip]
> >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.
[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?
Or is it just when Microsoft does it, that it is bad?
> >In that case, of course, you've no choice but to use
> >the proprietary technology; but wouldn't it be nice to be
> >able to interoperate with *other* systems too?
>
> 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
> >If you standardize on a protocol, you have to standardize
> >on one that does whatever it is you need; maybe that
> >one will be proprietary. If you use a more sophisticated
> >approach, you can use more than one protocol.
>
> You can't standardize on a proprietary protocol. The words
> don't make sense in the same sentence.
Sure they do. You may chose not to understand them, because
they are inconvinient to your argument; but their meaning
is really pretty plain.
[snip]
> >> Odd, I've never seen a unix box direct a 'ping' to a machine
> >> where a user just happened to name his own machine with
> >> the target name instead of to the correct DNS-issued address.
> >
> >I *have* seen this happen; though it's IP numbers not computer names
> >in TCP/IP, naturally. On the Internet no less. It was quite a pain in the
> >ass.
> >
> >What this has to do with interoperability I don't know.
>
> I don't know what you are describing there, but I don't think it has
> anything to do with the situation I mentioned.
Sure it does; TCP/IP also permits users to identify their
machine so it 'looks like' someone elses. Causes trouble
when they do.
> I meant that a windows
> box will normally resolve names through netbios-broadcast before
> attempting DNS lookups even for IP-only commands like ping.
It can be configured so to do. The defaults for this have been
changing; I don't think Windows 2000 still ships configured
to do this.
> Therefore
> if someone on your LAN gives his machine a netbios name that is
> the same as some other machine's DNS name, your lookup will find
> the imposter instead of the machine officially registered in DNS.
Well, NetBEUI uses network-local names; there's no reason to
register them in the DNS.
> 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.
[snip]
> >I tought you just said "Correctness is not a problem?"
> >
> >Being "correct" achieves nothing by itself.
>
> I guess you wouldn't know if all you have is the less-than-correct
> version.
I prefer to think of it as "more than correct"
Given the way you've been playing with words, this
seems like a reasonable construct, no?
[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.
Of course, I realize that what you are after is standards *for their
own sake*, and not to facility communication or anything.
>From that point of view, there is no reason to be limited
to just one standard, I guess.
> >However, the real reason people become dependant on a vendors
> >is because that vendor offers something they need (or think they need)
> >that other vendors do not.
>
> That makes them dependant for about a month, when a competitor will
> offer something even better.
It almost never can be done so fast.
> Unless, of course the first vendor
> does something that makes it impossible to switch.
If they do, the competitor need only provide some sort
of compatibility solution.
No- better to provide a feature the competitor has not got;
he'll not find it so easy to catch up then.
> >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.
[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.
Admittedly, the protocol addition is part of the feature,
so you aren't completely off base. But that's not the
whole story.
> >You can run Windows and use strictly "open" standard
> >protocols, but you won't be substantially less vendor-locked
> >that way.
>
> 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?
Indeed, why should they?
[snip]
> >> Why not?
> >
> >Because there are ways to handle multiple protocols and
> >changing protocols, of course.
>
> 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.
[snip]
> >There are much better ways out there. Traps, if you
> >will, that are much, much harder to escape.
>
> Like getting everyone to consolidate their authentication
> data into a product that no one else understands?
Well, again, secrets aren't a good technique. "No one else"
understands it until someone reverse engineers it.
It's not a long term strategy.
There are better ways to lock in your users.
And Microsoft knows them.
[snip]
> >Well, I've already described some of Microsoft's "great efforts
> >to be interoperable", so it's not quite *pure* fantasy.
>
> I guess they spelled the names of the things that they
> claim to interoperate with right.
:D
> >As for the "tut-tutting" part, well, I guess I can present
> >you as exhibit A.
>
> 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.
[snip]
> >> If you are providing their software you can use something
> >> non-standard.
> >
> >Microsoft provides many people's software. Can they do this?
>
> Of course - for their employees.
Hmm. How 'bout if I pay them to provide *my* employees
software?
[snip]
> >> Because there isn't any.
> >
> >Sure there is. *Microsoft* "standards" form a very broad
> >common ground.
>
> No, they generally have little in common with standards.
Be that as it may, they have a lot in common with themselves.
"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.
> >They may not be endorsed by your committees, and they
> >sometimes are single vendor things, but they nevertheless
> >form a very workable common ground to interoperate with.
>
> 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.
Personally, though, I think that attitude shows a certain
disconnection from the reality that computers are tools
that solve problems.
> >> If there were, Microsoft would find a way to 'de-commoditize it'.
> >
> >They would sure try. But that does not, in and of it self, mean it
> >is not a common ground anymore.
>
> That is exactly what it means.
Is not! :D
> 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.
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.
[snip]
> >Standards bodies, in particular, have *less* influence over
> >the people actually implementing these things that
> >pointy-haired bosses do.
>
> The difference is that with open standards, if one implementation
> is bad you can easily switch to a better one, or it the problems
> are known ahead of time, just avoid using it. With a proprietary
> protocol, you have to live with the problems.
Or, just avoid using it. :D
Or, use a *different* proprietary protocol, for that matter.
[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?
Is there really a *difference* that matters?
[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.
[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 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.
> >That way, the DHCP server that gives you your IP number
> >is not your problem, it is your ISPs problem.
>
> 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.
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.
[snip]
> Or put in one of those $100 (or so) router/NAT/DHCP boxes if
> your network is small enough that you don't need an administrator
> that knows how to spell DHCP.
:D
There are always solutions to the problems using the wrong
technology for the job creates.
It's just too bad you have to use TCP/IP to interoperate
with the Internet. MS' solutions to this problem are not all
they need to be.
[snip]
> >Refusing to connect to someone because they *don't* use
> >cross-platform standarsd, on the other hand, is not
> >interoperability.
>
> Planning for interoperability using anything but cross platform
> standards isn't planning.
That's debatable. Perhaps it's *bad* planning.
Of course, predicting in advance which platform
will get the brass ring in 5 or 10 years is really,
really hard.
If it turns out to be "Microsoft", then you may well be
very sorry you went with "open" standards. You'll
be a second class citizen at best.
But the converse is also true.
[snip]
> >That is, of course, the point of producing a product with features
> >and capabilities that other products do not yet have: it locks
> >your customers in.
> >
> >This is a *good* thing. It's the major spur to technological
> >progress in this industry.
>
> It is good for the vendor whose customer no long have a choice.
> It means they no long have to make any progress or maintain
> competitive prices to keep their customers.
Ah, but they do. They do because their competitors
will try to catch up and overtake them. They have
no choice: they will get few new customers if
they don't.
(Well, that's the theory. Some days it seems like
they just go to court instead. :( )
[snip]
> >As I've explained, MS clients permit Novell to write their own
> >plug-ins to handle whatever extensions they like
>
> Can they get those plug-ins tied to a monopoly OS so the
> client needs no modifications?
Clients without modifications are nearly useless, actually.
You always need to install some software.
> >Indeed, ts how NetWare *always* worked, even when it was
> >a gross kludge on top of DOS.
>
> It was, of course a much, much, smaller kludge on top of
> DOS than the MS DOS network or even the WFWG one.
Well, if you say so. I don't accept the notion that MS can
keep them from doing this again, if they have to.
> >While MS does provide a NetWare client, you can't expect MS to
> >anticipate Novells improvements and pre-emptively provide
> >them. Nor would Novell be wise to limit themselves to the
> >features MS has so kindly provided in their NetWare client
> >module.
>
> 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.
> 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.
[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.
Clever, isn't it?
------------------------------
From: "Daniel Johnson" <[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: Mon, 07 Aug 2000 00:34:59 GMT
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said Daniel Johnson in comp.os.linux.advocacy;
[snip]
> >The market seems to have decided that it likes bundled
> >products and that it likes web browsers as part of the
> >software bundled with a computer.
>
> Bullshit.
No really. Everyone is doing it. It's not just Microsoft.
> The market complained when this was forced on them. I know
> that you didn't (and still don't) hear it, but perhaps that has more to
> do with the fact that you're covering your ears and yelling "LA LA LA LA
> LA" as loud as you can?
Please. I prefer "FOO FOO FOO FOO", thankyouverymuch. :D
But seriously, just because you can think of an excuse for
Netscape's failure, it doesn't mean that I have to take it
seriously.
> [...]
> >Do you find nonsense more bearable without the smilies?
>
> Alas, I must admit I don't. Your nonsense is still unbearable. Not
> being distracted by the smilies only highlights the nonsensical nature
> of your deluded arm waving.
Surely, then, you prefer I keep continue to use smilies for, um,
prophilactic purposes? :D
------------------------------
** 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
******************************
