Linux-Advocacy Digest #550, Volume #27 Sun, 9 Jul 00 12:13:08 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: Sun, 09 Jul 2000 15:51:02 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8jqi6k$26o0$[EMAIL PROTECTED]...
> In article <Yr185.4272$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
[snip]
> >If you want to say that the vendors of dial-up terminal servers
> >were 'forced' to re-write their firmware or go out of
> >business, you should provide some evidence for it.
>
> If you want to claim that dropping an incompatible dialer
> on every desktop didn't break the standards-conforming
> existing hardware, you should provide the evidence, except
> there obviously isn't any.
If you want to play the "shifting the burden of proof" game,
you really ought to do it more subtlely.
You are being *so* blatant about it that the only people who
will be convinced are the sort of people who would
had already agreed in advance, for other reasons entirely.
[snip]
> >They were, after all, somehow able to get by before
> >MSCHAP got along. They had to have *some* way to
> >distribute their dialers.
>
> No, they just worked with standard PPP dialers before. No
> need to distribute anything proprietary.
Who cares about "propretary" versus "standard"? They
had to distribute their dialers *somehow*, regardless
of what protocol.
[snip]
> >Well, at least you admit to your double standard there.
> >
> >But I had thought better of you. Oh well.
>
> Better?
You know, *consistant*. I did praise your consistance, if you
recall. :D
> I have a keen sense of the obvious. Competition
> takes care of such problems. MS doesn't have any
> compitition.
MS has, of course, got competition. Remember, "monopoly" as its
being used today means "big, successful and influential" not
"without competition".
> >[snip]
> >> That is fine if you have several vendors competing on an equal
> >> footing. We don't and you know it.
> >
> >Indeed; we don't, we never did, and we never will.
> >We don't need it.
>
> You speak only for yourself here.
Not unlike you, that way. :D
But the preference of computers buyers for a single dominant
provider is very clear and widespread: it is not limited to Microsoft,
or Operating Systems, or any such thing. It is a broad pattern
in virtually every part of the computer industry.
[snip]
> ><Shrug>; Unix's problems are sufficiently obvious, and
> >sufficiently oft commented upon, that if you don't know about
> >them, it's because you don't want to.
>
> In other words you can't think of any...
I have already gone through some of them; I don't feel like
going 'round again. I'm getting dizzy. :D
> >[snip]
> ...monopolies..
> >I guess so. I meant that the meaning of the term has changed
> >so that it no longer resembles what it once did, and in particular
> >no longer implies a lack of competition, or control of a market.
>
> In regard to what company?
Any, that I'm aware of. This isn't limited to Microsoft.
------------------------------
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: Sun, 09 Jul 2000 15:51:05 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8jvlm6$2orq$[EMAIL PROTECTED]...
> In article <%r185.4273$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
[snip]
> >> >> Exactly - and none of them should involve having to make
> >> >> changes on the other end of the wire.
> >> >
> >> >Why not?
> >>
> >> Because doing so takes away your choice of ever using anything
> >> (a) not under your control or
> >
> >What does this mean?
>
> Interoperating with anyone you can't force to install the
> plug-in that happens to match your API-of-the-day. Like
> the rest of the world.
I'm sorry, but I'm having difficulty parsing your comments
here.
I am guessing you did too much violence to that sentance
in your effort to work the word "force" in. Perhaps you could
try to say it without it?
> >> (b) not from a vendor that happens to match.
> >
> >No, this is backwards. If you are allowed to make
> >changes at the other end of the write, you can support
> >products that support *none* of your current protocols;
> >you just add one their do support.
> >
> >Inconvinient, yes, but better than simply being unable
> >to communicate at all.
>
> If you follow standards, you are never in the position of
> being unable to communicate so that comparison never happens.
Sure you are: as soon as you try to install a product that
does *not* follow the standards your happen to prefer.
> So, why make the inconvenient choice?
Well, if you are willing and able to insist on a protocol
that all your clients used, you can avoid it: but this is true
of *any* protocol, standard or not. WIth plug-ins you get
your choice of protocols.
[snip]
> >Hmmm.. I sense a bit of waffling here. Will you admit that
> >COM is a standard?
> >
> >Not "might make sense as a standard". Is it one?
>
> I didn't see any evidence that it was offered to or accepted
> by the IETF, or ISO, which would determine if it is an
> accepted standard or not.
I see. So the IETF and ISO are the only standards making
bodies that you accept, and apparently ANSI is out as is
the open group.
Why those two, then?
> >I'll admit that CORBA is, if it helps.
>
> Why, because Microsoft is a member of OMG?
I'm just trying to be accomodating.
[snip]
> >This isn't true of computers. Most of their value is
> >rather more self contained. Don't get fixated on the
> >Web.
>
> No, that value was provided by typewriters, where you only
> get back what you put it. Computers gain their added value
> by being able to store data and exchange it.
Computers, well, compute, and were very popular before
the web came along. "Exchanging" data you can do with
the post office; Computers can do much more.
Don't get fixated on the web. Comptuers are used for
much, much more.
> >Further, you have to show that its ability to interoperate
> >depends on standardisation, as you know I said
> >that it doesn't. If I'm right, halting progress (in this area)
> >isn't justifiable.
>
> Halting progress has never happened.
Admittedly. I don't want it to, is all.
> It is your claim that it has that isn't justifiable.
I did not mean to imply that it is; I meant to say
that it *would* be halted, if "open standards" were really
universally adopted, as would be required to use them
for interoperability.
> It is standardization of exchange
> formats and protocols that allows progress and prevents a
> single vendor from destroying it.
You keep saying that, and I keep not believing it.
[snip]
> >> >> My real complaint about IE is that it puts non-standard HTML
> >> >> extensions on a majority of desktops, encouraging designers
> >> >> to use them in ways that break standards-conforming software.
> >> >
> >> >Sort of like Netscape, then?
> >>
> >> No, Netscape didn't claim to be inseperable from the OS,
> >
> >That has nothing to do with it.
>
> Yes it does. If it didn't the claim would be unnessary (as well
> as being untrue...).
I did not *make* that claim; therefore I would suggeswt that
the claim *is indeed* unnecessary.
[snip- MS is Evil! Is not! Is so, etc. This is getting dull.]
[snip]
> >You want to keep people from *using* IE's addition features.
> >
> >You've no right to do that.
>
> Well, whatever consenting adults want to do in private is
> OK, I guess. But in public, there are certain standards
> to follow.
You don't get to dictate them for your own convinience,
however much you may wish to.
[snip]
> >Why? Why do you get to dictate to web-page authors what
> >features they may use?
>
> Because people call me to complain when our web pages are
> not viewable.
So what? Why does the whole bloody world have to be rearranged
for *your* convinience?
> This happens when the developers are tricked
> by the MS tools that generate non-conforming pages.
You really, honestly, think that people who use IE's extensions
don't mean to? That its all a trick, and that somehow nobody
every *notices* but you?
[snip]
> >That is because you are using Unix or a reasonable
> >facsimile thereof, not just POSIX.
>
> That happens to be true, but it isn't necessary.
In practice, if you want Unix you gotta get Unix, not
POSIX.
But it *is* true that Unix isn't necessary. :D
It's just that if you are going to eschew Unix, you might
as well forget POSIX anyway.
> There
> are even versions that manage to run under MS-Windows,
> although judging from the prices, this must be somewhat
> difficult.
Well, the demand is low.
[snip]
> >> But GUI based programs aren't easily automated.
> >
> >Aren't they? Do you know about WSH?
>
> No. Why should I?
It's one of the ways to automate a GUI based program.
> Is it well documented in the help system?
Sadly no, you have to download the docs from MS's web site.
I can't really think of a way to present that as a good thing. :(
> >> Command
> >> driven programs generally take the same commands when
> >> run non-interactively as when interactively.
> >
> >This is not a particularly good thing. It means that
> >both UI forms are compromised.
>
> How so?
Well, the command line must be made *terse* for interactive
use and it must be able to do as much as possible implicitly.
These are not usually good things for a reusable program.
However, it must remain *textual* so that it can be placed
in a text file. Good interactive UIs are so rarely textual.
> Giving the computer commmands is often the
> best way to accomplish a task.
Why?
This certainly isn't the convential wisdom.
> Being able to automatically
> have them repeated after getting the steps right manually
> is sometimes even better.
Yes, but it's hard to do without making serious compromises
elsewhere.
As I mentioned, Apple did *try* to do this, with, well,
mixed results.
[snip]
> >Okay. This is all fine, but "two serial ports" is in and of itself
> >different from the 'wire protocols' hitherto used. Because
> >UUCP depended upon that protocol, it had no way to cope.
>
> No, as I said, it did work with smart type modems but it required
> the carrier detect lead to be up as though it were already on
> line.
Well, okay. Nevertheless, UUCP depended on a detail of
the protocol- the carrier detect lead must be up- that
was only true of some modems.
This is just a pitfall you get with protocols that drivers
provide a solution for. That's all.
[snip]
> >Sure, it was a user-level program. But you can't expect
> >real users to alter it when something like this comes up;
> >it's far better to be able to give them an installer that put
> >a driver in.
>
> You can't expect a user to be able to obtain a driver for
> every possible program/device interaction.
Wanna bet? :D
> It would certainly
> have been impossible in this case.
No, had UUCP used a modem API a la Windows,
it would have been quite ordinary to download
a modem driver for that particular modem.
True, Unix does not support such things. But
that's Unix's problem.
> Getting a large company
> to fix its software turned out to only be 'almost' impossible,
> but then it was fixed for everyone.
No, only for UUCP users. Anyone *else* whose apps
were making the same assumptions about the modems
behavior would remain broken.
> I probably should dig
> out that 'closed problem report' from AT&T and frame it.
Well, if you are into that kind of thing.
> >Alternately, you can just stick to your standard protocol
> >religiously. But realistically, that isn't always an option.
>
> Why not?
Because it won't be followed. Consider your UUCP example:
the modem in fact *did* deviate from the protocol that
earlier modems had used. It's not like it was such an obscure
protocol, or even that UUCP was some bizzare unheard of software
that they couldn't have tested with.
Yet in spite of this, the modem did not work with UUCP. This
was an interoperability problem of the *easiest* sort,
and Standard Protocols failed to solve it.
> If the software vendor won't allow using generic
> hardware without specific support, change the software.
This is out of the question on the desktop, and very expensive
elsewhere.
[snip]
> >> If you have decent character based programs on the other end,
> >> using telnet isn't a restriction.
> >
> >"Character based programs" is a restriction in my book.
>
> If you are used to the ones supplied by MS, I suppose that
> is understandable. But they work fine for anything dealing
> with text. Not surprisingly, most things can be described
> with text...
I guess I have higher standards than you about user
interfaces. :D
But serious, *even if you think text is king*, surely you
would agree that being restricted to text *is* a limitation?
[snip]
> >> >> they
> >> >> unintentionally break the competitors product by using
> >> >> the non-standard changes.
> >> >
> >> >You do keep saying this. And I keep not believing you.
> >>
> >> That doesn't make it any less true.
> >
> >Maybe so. If it is true, we've got much bigger problems
> >than Microsoft, though.
>
> Who is bigger than Microsoft?
IBM, I think. But what does that have to do with anything?
Honestly, sometimes I think this thread has
degenerated into so much free-association.
Not that that's a *bad* thing, mind you. :D
[snip]
> >> That's not even close to what I said.
> >
> >Then I didn't understand what you said; perhaps you could
> >rephrase it?
>
> Did you have trouble with the 'unmodified' word? I mean actual
> interoperation, not changing the client.
That is interoperation in my book; I realise its not
*Unix*, but that's where we always get hung up: you
mean something different from "interoperability" than
I do.
[snip]
> >You said you wouldn't be willing to touch each client; how
> >are you going to support new version fo SMTP without
> >doing that?
>
> SMTP announces its capabilities as it answers a connection.
> The sender sends what the receiver can handle.
Sounds like you aren't going to be able to support new
capabilities, but you will be able to keep using the old
ones. Is that a fair statement?
> >Your strategy only avoids touching the clients when the
> >protocol *coesn't* change.
>
> And when it does. It might come as a surprise to someone
> used to MS software, but when new capabilities were added
> to SMTP, all the email systems in the world did *not* have
> to be upgraded on the same day.
Of course they didn't, of course not. It's not like you have to
do that with *anyone's* systems.
But they had to be touched to use the new capabilities.
[snip]
> >> The posix subsystem was supposed to run all your old unix
> >> programs.
> >
> >When did MS say *that*?
>
> I haven't been able to pin it down,
That's what I thought.
[snip]
> >But seriously; why isn't this a standard? If you mean
> >to say "its not a standard because its not open";
> >then please tell me what it means to be "open", and
> >why it matters.
>
> There are different types of standards. One is mostly to
> assure that consenting adults know what they are getting
> into when they agree to do something privately. Another is
> for public interaction.
Which, if you have anything to say about it, will not involve
consent!
> The Open Group fits in the first
> category. However, something can be open without being a
> standard by simply making a reference version available without
> unacceptable restrictions on copying or use.
Okay. So the Open Group is open but not standard then?
So why isn't it a standard? It looks like a standard. What's it
take to be a standard.
You seem to be saying that somehow, something
imbues real standards with *moral* force: It's *wrong*
to disobey standards. What imbues them with this,
that the open group hasn't got?
[snip- Motif history lesson]
> >"Correctly" for you, as always, means "standard conforming,
> >no extensions".
>
> It is irrelevant if your browser has extensions, but publically
> available web pages should not break standards-conforming
> browsers.
Do they have to be in English too, so you can read them?
> >And they *do* have the choice of using other browsers like
> >that; they just aren't as good. But that MS should be brought
> >down to their level hardly seems reasonable.
>
> On a private MS-only net, anyone can do anything they want.
> On the internet, having pages that do not display correctly
> is bad, particularly when this is a side effect of using
> a development tool and not intended by the author. This
> deception does not meet the 'consenting adults' test and comes
> closer to outright fraud.
What is your "consenting adults" test then? Why should
I, or anyone, care about it?
[snip]
> >> It fails to work under correctly operating JVM's. A user
> >> can no longer choose to use those JVM's.
> >
> >Again, I don't see why MS shouldn't be allowed to
> >create Windows-specific development tools;
>
> They can and do. They just shouldn't be allow to call
> something java when the byte-code generated isn't.
Byte-codes are *never* Java.
Now, you may have a point about "calling it Java"; Sun
has that trademark and proposes to be *much* more
restrictive about it that has been the practice with
other languages.
> Why
> bother with the pretense of portability with byte-code
> for something that will only run on one CPU/OS anyway?
Byte-codes buy you CPU, not OS, portability. Perhaps they
thought Windows 2000 would run on this 'Itanium' thing
or something.
> Also, if it is allowed to touch native methods not bounded
> by the expected java sandbox security it shouldn't be
> allowed in applets anyway.
I would expect the browser to enforce that, though.
> >I think that Sun's efforts to prevent this has cost Java
> >one of its more influential supporters. It's too bad.
>
> With support like that, they don't need any enemies.
:D
Hey, it's a two-for-one deal.. :D
> >Java coulda been a contendah. :D
>
> If MS hadn't killed it...
MS hasn't, yet. But Sun has seriously impeded
it by insisting that Java can *only* be used for
what Sun wants it to be for.
That is no doubt Suns right, but it's hardly smart.
[snip]
> >What you said was that they should keep their own product
> >at the same level as LDAP- or else the other way around,
> >and it's not clear to me what you meant.
>
> It is a simple lookup and there is no reason to make the LDAP
> version take more user steps than local files or the exchange
> directory service - unless perhaps it is to punish people for using
> a product not sold by MS.
I don't see any reason to take your word for there being "no reason";
I expect that LDAP is somehow inadequate compared to the
other mechanisms. MS, presumably, chose not to extend it.
[snip]
> >> And how does this compare to the number of seats using
> >> visual c++?
> >
> >No idea, but that's a different market, one with substantially
> >different needs.
>
> I suppose most of the visual c++ crowd doesn't compile custom-tuned
> kernels very often, but I don't see how the application programming
> needs would be different.
Well, they are. g++ is widely used to do reimplementations of
Unix tools in open-source form; for this purpose an open-source
compiler is, of course, de-rigure. A highly portable compilers
is *also* clearly required; you must be able to compile your
stuff for many CPUs, and nobody can touch g++ there.
For this market, Visual C++ is not competitive.
Visual C++ is a full service IDE, with pretentions of being a RAD
tool. People use it pretty strictly to write Windows apps, either
custom or shinkwrap. It kinda straddles the line there.
> >> Or encouraged to use MFC?
> >
> >MFC is not comparable; it is just a class library, and it
> >does not use any language extensions.
>
> Can source using MFC be expected to compile and run on
> other platforms?
Yes, if it uses *only* MFC. There's a Macintosh version of the
class library.
If you wanted to go somehwere MS doesn't want to go with it,
you'd have to write your own port of MFC. Such is always
the problem with 'portable' libraries, and it is a big problem.
> If not, how is this any different from
> using (say) the alloca() extension of gcc?
It's actually *less* portable than alloca(); alloca()
works on quite a lot of compilers for quite a lot of
OSes.
alloca() isn't standards conforming, but I bet its more
portable than trigraphs. :(
------------------------------
** 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
******************************
