Linux-Advocacy Digest #424, Volume #27 Sun, 2 Jul 00 11:13:04 EDT
Contents:
Re: We WANT different enviroments (Was: Linux, easy to use? (Chris Shepherd)
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
Re: Would a M$ Voluntary Split Save It? ("Daniel Johnson")
----------------------------------------------------------------------------
From: Chris Shepherd <[EMAIL PROTECTED]>
Subject: Re: We WANT different enviroments (Was: Linux, easy to use?
Date: Sun, 02 Jul 2000 10:26:31 -0400
> Yes, but it requires a separate operation to delete the "replaced" text; it
> can't be done in one operation. I admit that the "habit" I'm trying to break
> is in fact a Wimp-dows one, but it is still more awkward to me. Like I said,
> I'd rather learn the more convenient if less universal alternatives.
Actually, I know how you feel, but the other way around. I went to my
friend's place to try and setup his windows box (what I learned on, so I
know it pretty well), and found that even only after a month of using
linux, I was getting flustered that CTRL + ALT + F(1-5) weren't dos
prompts, and that CTRL + ALT + F7 wasn't the gui. :P
That was a hard one to break.
--
Chris Shepherd
Vice President, GDPS Computers
Known in the SCA as William Silverlake
" Umm... Can I UN-cast that Fireball? I think it made him mad."
------------------------------
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, 02 Jul 2000 14:26:11 GMT
Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8j3k4p$24v9$[EMAIL PROTECTED]...
> In article <EN655.21964$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
>
> >> Yes, it is extremely hard to support such a claim when you
> >> think the RFC's stopped in the 700's.
> >
> >Oh, now that's cheap! Just cuz I was able to find the telnet
> >'standard', and it didn't mandate the feature you wanted to
> >be mandated...
>
> No, it is because you continue to claim that standards slow
> down development in spite of the fact that it is easy to
> see that standards continue to evolve to meet user's needs.
Those two statements are not in conflict, ya know.
[snip]
> >As you point out, it restricts innovation to *implementation*; no
> >new features, just faster/stabler implementations of the old one.
>
> It doesn't restrict anything, unless you want to claim that Windows
> is restricted to using NETBEUI. It does ensure that other
> implementations can co-exist and be changed independently.
Windows is not restricted to NetBEUI because MS can and
does change the protocols- and switch to new ones, too.
[snip]
> >Not at all, there are way to cope with multiple protocols; using
> >them gives you flexibility.
>
> Exactly - and none of them should involve having to make
> changes on the other end of the wire.
Why not?
> >> And note that no one except
> >> MS is forcing anyone to use anything.
> >
> >Sure, but you *would* force MS to use Unix protocols
> >if you *could*. No?
>
> Force is a strong word, and standard protocols have
> nothing to do with unix, so you are being as misleading
> as possible here
I don't think I am; I think that it's *Unix* protocols you favor,
regardless of 'standardization'; there is as I've mentioned
a standards body for COM, but I don't see you complaining
about Unix's vendors failure to support it.
>. But, as I've said before, computer
> files and networking have become at least as significant
> as communications equipment when the wire standards
> were established for interconnecting equipment. So
> I'd consider it perfectly reasonable to have similar
> standards for computer formats and protocols for the same
> reasons.
You haven't given a reason to want to halt progress; you've
just asserted that its like telephones somehow.
I don't see that it *is* like telephones, and I don't see why
that should mean halting progress.
> >I mean, if you'd force MS to sell Internet Explorer separately
> >and for a higher price, why *not*? Why's this different?
>
> 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?
> I'll leave the legal points to the lawyers. This repeating
> pattern of exploiting their market share to influence things
> that cause trouble for users of competing products is
> a problem for me regardless of the law.
I don't think they do cause trouble for users of competing
products; so far I haven't seen an example of this given.
[snip]
> >Tha doesn't force you to use it. Hell, you don't even have to
> >buy their product, if you so dislike it.
>
> How do I go about removing the web pages that (accidentally or
> otherwise) only work correctly with IE from the rest of the
> world?
You don't. You've no right to take IE away from the rest
of us, just because you don't like it.
> I have put a great deal of effort to keep them
> off the web servers I manage and understand how difficult
> it is if you use any of Microsoft's tools.
Why should you do this?
[snip]
> >Well, that's true. But much Unix software does not
> >strictly adhere to the POSIX standard at all- it uses
> >X to produce a GUI, and this goes beyond POSIX.
>
> If you have posix and sockets, you can have X without
> any extra requirements.
Not so. Just spewing an X protocol stream into an
arbitrary socket is useless; you need an X server to
do anything.
And you can't implement an X server with POSIX alone.
[snip]
> >I dunno; having the sysadm write scripts was your idea,
> >wasn't it?
>
> I forget now... I think it was in the context of setting
> up the machine for a user's particular needs, much like
> a network admin has to do for a typical Windows user.
> Most people learn to use the tools they need to do their job,
> so if writing scripts would help you it is nice to have have
> the option, and if it is a one-time thing letting a sysadmin
> do it is probably the best approach.
Well, that's okay if the tasks at hand are reasonable
scriptable.
[snip]
> >> Timed operations,
> >
> >What's this?
>
> I guess 'scheduled' would have been a better term.
> Cron is a normal part of the unix/linux environment. Anything
> that can run unattended can be run automatically at user
> specified intervals. There is also the 'at' command for
> one-shot runs at a specific time.
Both Windows 98 and NT/2000 have schedulers, too.
[snip]
> >I don't think most of the file transfers, charts and "assorted
> >other things" really can be so easily scripted; they vary
> >over time too much.
>
> Perhaps the things individuals do are more whimsical, but
> businesses often provide certain data in certain ways at
> specific times. I do anyway...
Yes; and scripting provides a way to program the computer
to handle well known tasks automatically.
It's programming, and you can do it in Windows too. Most
Windows users lack the skills to do it, though.
> >[snip]
> >
> >The alternative I favor- using drivers and like plug ins- also
> >solves the problem.
>
> At the expense of making the device an extension of that
> particular CPU and OS.
Well, each OS that it has a driver for.
> I don't object to the ability to
> do this as long as this restriction is exposed to the
> customer before purchase (and I don't think it always is).
Mistakes are sometimes made. :D But most of this hardware
does say what OSes it is for, right on the box.
> The ancient uucp example was the opposite, though. In that
> case the hardware was generic and the software was tied
> to specific models from the same vendor, but it produced
> the same effect until I got it changed.
I'm not sure what you mean here. The software depended
on a particular modem protocol and the modem didn't follow
it; surely *neither* was "generic"?
Drivers would solve this problem.
[snip]
> >How low bandwidth is low? I use RAS over 28.8 modems
> >regularly, and greatly prefer it to telnet.
>
> RAS is a transport layer and doesn't have much to do
> with telnet's application layer that would happily run
> over your RAS connection if it supplies TCP and you
> have a suitable server.
Admittedly; but you know what I mean: with a (slow!) remote
network connection, I don't need to be restricted to telnet.
> But for a reasonable comparison
> of capabilities, try doing a non-indexed search of a
> huge database with a local PC program accessing the remote
> file over RAS.
That's not a reasonable comparison; that's being deliberately
stupid.
> Then telnet to a character-based database
> program on the remote server and do the same query. Let
> me know which approach is faster...
Using a remote database program is faster, regardless of
whether you do it via RAS, or use telnet. At most you could
say that telnet is too limited to let you download the Whole
Damn File (tm) and search it locally.
But I'm at a loss to see why that's a good thing.
[snip]
> Mostly it is just different, and the market share makes
> people not pay attention to the differences so they
> unintentionally break the competitors product by using
> the non-standard changes.
You do keep saying this. And I keep not believing you.
[snip]
> >People who use telnet do know better, or they have
> >their system set up by someone who does: you can't
> >just have naive users telnetting into a Unix system and
> >expect them to be able to *do* anything without instruction.
>
> What are you talking about? Character based unix systems
> are often set up with menu systems that do not require
> any more knowlege about the system than a windows
> setup would.
Whoever set them up must know about telnet, surely.
> >*Someone* has to be the Unix guru at some point, and
> >he'll know the difference. He'll know enough to provide
> >a better telnet, if one is needed.
>
> Likewise someone designed the windows screen layout and
> menus that appear when you install your software. How
> convenient would you consider it if you had to find
> them to fix it?
So, you're saying that because your software is so much less
user-friendly than Microsoft, Microsoft is somehow obliged
to provide tools that make it as easy to set up and use
as their own?
I don't think MS thinks its in their interest to do that; if your
software is some awful telnet-based character driver thing,
MS software will certainly look good, and MS isn't going
to change it.
What boggles my mind is that you think they *should*.
[snip]
> >Indeed it is not. But MS doesn't do that. "Having features
> >your competitor has not" isn't the same thing as "breaking
> >your compeittors products".
>
> OK, technically correct. I'll back down to 'having features
> that encourage people to break the competitors products',
Well, "break" in the sense of "ignore the limitations of"- but that
is sometimes a reasonable way to look at it.
You're clearly thinking of the Web, where the two things
tend to be indistinguishable.
> but in the case of HTML editors that produce stuff that
> is not HTML and java compilers that produce something other
> than java I don't see much difference.
You could, at most, claim that MS's product is broken, not
that it breaks other people's.
> >And having bugs your competitor has not is breaking
> >your *own* product, not his.
>
> Not if it appears to work between your server and your
> client, but is broken when you use the other guy's.
It would seem to me that that isn't the case I was talking
about; I meant things like MS's telnet, which is no better
when pointed at an NT server than at a Unix one.
[snip]
> >That's not so. It may be that putting *Unix* into such a
> >system would be infeasible- but that's just because Unix's
> >interoperability is so weak.
>
> Hmmm, what OS isn't weak at interoperating with undocumented
> and rapidly changing protocols?
Microsoft's. :D
Really, you can change your protocol every second tuesday
without any serious problem; you need only distribute a new
plug in with your new protocol.
'Course, if you plan to do *that* you'd best automate the process,
but nothing prevents you form doing so.
> >Operating systems that are
> >really trying to be interoperable- like Windows- can adapt
> >to the protocol that is acutally being used- even if it isn't
> >the one protocol Unix likes.
>
> Changing components on every machine has nothing to
> do with interoperating. Why do you keep confusing the
> two?
Plug ins are a means of interoperating; I was just outlining
why it's a *better* means (in my view) than trying to get
everyone to use the same protocol everywhere.
It's the reason why you *can* plug a Windows box into
a non-MS network and have it work without changing
every other machine.
> >Interoperability is an *advantage* for Microsoft- it means you can
> >upgrade from Unix to Windows piecemeal.
>
> As I keep pointing out, they do understand the issues and exploit
> them perfectly. I'm just not interested in being exploited today.
You're an issue? :D
> When an unmodified windows client can interoperate with a
> a non-Microsoft version of Active Directory services, or an
> equivalent to the Kerberos-domain-controller, we can talk
> about interoperability.
They can. They come with plug-ins for other peoples networks;
maybe not *yours*, but they do support NetWare and Windows
2000 has added support for vanilla Kerberos, though vanilla
Kerberos doesn't offer the same features Active Directory does.
It may well not support whatever server you *want* to use, but
it does provide a mechanism to add such support.
[snip]
> >I see no reason to make special provision for Unix unless we
> >*expect* to switch to it.
>
> Do you expect to be locked into Intel-backwards-compatible CPU's
> forever?
For a long time yet, really. But what of it?
> The point is that you shouldn't need to know what
> better/cheaper OS/CPU might come along or make any special
> provisions to switch.
Sure you do. For instance, if you want to be able to switch
to Unix later, you'll be sorry if you aren't using Unix's protocols
*now*, because Unix isn't very good at interoperating
with other people's.
OTOH, if you want to switch to Macintoshes, there's an entirely
different set of services that are incompatible with Unix's
*and* Windows.
> If you only use standard wire protocals
> you don't need to predict the future, you can replace parts
> as you like.
If you use Unix protocols, youc an swap Unix it. Use Mac
protocols, and you can swap Macintoshes in.
MS's products can adapt to different network environments;
this lets you install them peicemeal.
Advantage: Microsoft, on this one.
> Otherwise you just have to plan to replace
> everything at once unless you are so foolish as to expect
> one vendor to have the best product forever.
Or if you are so foolish as to expect Unix to have the best
product forever. :D
[snip]
> >You can only do this is the standards already support the feature
> >you want.
>
> Yes, standards evolve to provide the features you want.
This does not help; aside from being way too slow to keep up
with more normal software development, this does nothing
to upgrade your existing computers- the ones you insist you
can't change in order to accomodate a new machine.
> >With a more flexibly approach, like Windows, you are not limiited
> >to this.
>
> Heh. Instead you get to replace every component at once.
This is true when you switch from Windows to Unix, but that
is because of Unix's poor interoperability; it is not true in
the reverse case.
[snip]
> >POSIX wasn't needed to do the job; it was one of those 'requirements'
> >that isn't really required.
>
> Where did you find this official statement?
I do not say the government has *admitted* it doesn't need POSIX;
but I do say that because it uses NT, and because POSIX in NT
is unusable, they must not have needed POSIX for the tasks NT
is used for. QED.
[snip]
> >No, the *X Library* has to do that. You don't. You don't need
> >to know how the X library does it.
>
> Yes, it is possible to modify the X library to work in
> environments that don't provide posix+sockets. But
> why should you have to?
Because some environments do not provide posix or
sockets.
This is actually one of the more compelling reasons
for *having* an X library in the first place.
[snip]
> >Copy the source and recompile works only between very
> >closely related OSes, like the different Unixes and the
> >different Windows.
>
> Then why did we have the misleading claims about subsystems when
> NT came out?
What misleading claims are those?
[snip]
> >"the platforms that follow standards" is Unix and a few
> >oddities like Linux. That's because "standards" means
> >"Unix technology' when you say it.
>
> That isn't true no matter who says it.
>
> >Let me put it this way. Is COM a standard?
>
> Why would it matter, since it has to run on the same machine
> under the same OS as the other components? Wh
What does that have to do with it?
> >No, of course not. We all know it isn't.
> >
> >Why not? It has a standards body.
>
> Which one, and what competing vendors participate?
The Open Group, the same folks you brought you Motif!
Okay, I don't think that's so promising either.
Here's the web page for this thing:
http://www.opengroup.org/comsource/
Why isn't this an open standard? Is it just the
lack of design-by-committee?
> >[snip]
>
> >One should not complain that Windows is bad because it does
> >not accept conforming Unix programs; one should say
> >it is not a Unix.
> >
> >Is that sufficiently clear?
>
> Of course. But things that claim to generate HTML should
> generate standards-conforming HTML. Things that compile
> java should generate real java. Things that offer LDAP
> address-book service should make it as handy to use as
> exchange address-book service.
Do you suppose these three things are equivalent?
".. should generate standard-conforming HTML" just amounts
to "no new features- it makes MS's competitors look bad"
"...should generate real java" is nonsensicle; Java
compilers emit .class files, or executables, or something,
not more Java.
"...should make it as handy to use as exchange address-book
services" is just weird; I don't know if it means that MS shouldn't
try to go beyond what LDAP offeers, or that they should
kludge LDAP to do what they want.
> >> MS doesn't seem to think you should.
> >
> >Nor anyone else. You *do* realise that g++ is simply
> >chock full of incompatible extensions, don't you?
>
> Sure. They have their own political agenda and play the
> same tricks to get people locked into it.
It is, quite simply, the way this business does business.
And it *works*; it's a powerful engine for progress, even
for innovation in its more extreme sense.
It's a good thing.
> The difference
> is that they don't have enough market share to get people
> to use the non-standard parts accidentally
They *don't*?
Surely they dominance in some markets- like the Linux
compiler market- is just overwhelming.
> and they
> don't produce tools that end up on every desktop that
> intentionally generate non-standard code.
Their tools do seem to wind up on a lot of Linux
desktops, though, and they do emit non-standard code;
they simply *is* no standard that would be relevant
to g++'s output, so they've no choice but to be
nonstandard.
They *is* a standard for their input, though, which they
do not seem to feel restricted to.
(Nor should they, of course, in my view.)
------------------------------
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, 02 Jul 2000 14:26:12 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8j3k8p$2542$[EMAIL PROTECTED]...
> In article <rN655.21957$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
>
> >> >If not, should Java be avoided until there is?
> >>
> >> The situation is less than ideal. But better than having
> >> windows-java and everything-else-java.
> >
> >Why is that?
>
> The whole point of java is that it is portable. Destroy
> the portability and you have destroyed the language.
Java has some strong points, but the portability Sun claims
for it is simply not real. It is if anything *less* portable than
C++.
But Java is a language with some *real* merits. It is just that
portability is not one of them; Java has not done anything new
on this front, and the problem remains as intractable as ever.
But Java is simpler and cleaner than C++ while oftering
many of the same features; it offers additional features like
garbage collection, dynamic class loading, and reflection.
And it offers a more predictable machine model than C++
does.
(Note that the latter point actually works *against* portability;
Java is difficult to port to machines which don't support 32
bit words well, for instance, where C++ can handle it.)
I don't think having "Microsoft Java" and "Unix Java" and
"Mac Java" is less than ideal; I think it's the best we can
hope for, and I think that it's unfortunate that Sun
stands in the way of this development.
------------------------------
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, 02 Jul 2000 14:26:13 GMT
"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8j3lrr$26qj$[EMAIL PROTECTED]...
> In article <vN655.21961$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
>
[snip]
> >> At the time, it was hard to make IIS keep working at all.
> >
> >If you say so.
>
> Just try to keep an NT box running with no service packs and
> whatever the original IIS version was. When it crashes,
> call up MS and pay them to tell you what to do. It was
> just as foolish to run that back then as it would be
> today.
So, you are suggesting that nothing has changed then?
> Yet they did everything they could to force
> ISPs into using it.
Well, I'll stick by what I said: If this is true, MS screwed up-
they hardly *want* to sell unstable software that makes
them look bad.
[snip]
> >> It gave them the opportunity to provide modules for apache
> >> that made the competing unix servers insecure. Is that
> >> an advantage?
> >
> >They hardly need FrontPage for that! :D
>
> Cheap shot. And untrue as well.
Yes, it was a cheap shot. And I loved it! :D
[snip]
> >The commercial "FrontPage" version may need special protocols
> >to do that web-overview pane thing it does, but the free version
> >does not support this feature at all.
>
> Since I don't use it, I've forgotten the details, but I think
> the original version did not have ftp and required the
> extentions on the server side to automatically publish
> the work to the real server.
It probably expected HTTP-PUT to work or something.
I take it from your reaction that Apache can support only
FTP. :D
> Or you had to use a separate
> ftp program, and since the stock Windows ftp is such a fine
> example of MS programming, users had a certain amount of
> trouble.
Windows stock ftp is just a plain-old command line FTP program,
just as you'd find on any Unix. So yes, it was quite lousy really, and
I'm not surprised people had trouble.
They have made some progress since they, though, for
what its worth.
[snip]
> >Just saying "No, you have to support standard protocols" isn't
> >enough. I'm glad Linux supports AppleTalk and IPX- it needs
> >to- but there's much more. Can Linux authenticate with a NetWare
> >directory server?
>
> Of course - the PAM configuration lets you drop in about any
> authentication mechanism you want, but this isn't a change
> you would want to introduce into a large established network
> because you have to modify every client at the same time.
Cool. So if you have a plug-in layer like this, why are you so
insistant that everyone else must use your protocols? Doesn't
this PAM work properly?
[snip]
> >But to interoperate, somebody has to support more than
> >his own stuff.
> >
> >It's *Microsoft* that is doing this, bring TCP/IP to the LAN.
>
> That's funny - especially to someone who added Windows for
> Workgroups to an existing TCP setup. It sort-of worked
> after downloading an assortment of beta drivers and knocking
> out all the other protocols because having more than one
> made it crash even more. If you had done that, I don't
> think you would try to make it sound like MS led the way
> to TCP on LANs.
That was before MS decided to embrace the Internet, and
brought TCP/IP to PCs. At that time, PC LANs ran on
NetBEUI or IPX/SPX or something like that.
What has changed since then is that Microsoft has
decided to make the sacrifices to interoperate with Unix
system. They realise that Unix is not going to do it-
they will stick to their own protocols, regardless of
what everyone else is doing.
MS has more than met you halfway on this one.
[snip]
> >It's the only fashion they *can* support; they can't *make*
> >anyone else support their protocols. (They can try, but I don't
> >see it working very well anywhere)
>
> It wasn't necessary to break java to implement it.
That's true. But you do have to undermine Sun's
"Java platform" strategy if you want to make Java
a decent Windows programming tool.
And that's what gets Sun so hot.
> It wasn't
> necessary to make their HTML editor produce non-standard
> HTML. And on and on.
Sure it was; standard HTML doesn't have the features they
wanted. If you want to use those features, you gotta do something
that isn't standard at some point.
[snip]
> >I have done the research in the past only to discover that you
> >won't accept it because you prefer not to believe it.
> >
> >I don't see why I should bother a second time.
>
> In other words you can't find anything but MS propaganda that
> supports your view.
:D
Well, if you believe technical documentation from MSDN is
"MS propaganda", there's no hope for you, really. It's a
hermetically sealed worldview; you reject sources of
information because they come from The Enemy.
I've seen it many times before from many different
people on many topics. I know I can't break through
it with mere facts.
------------------------------
** 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
******************************
