Linux-Advocacy Digest #897, Volume #27           Sun, 23 Jul 00 18:13:05 EDT

Contents:
  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")
  Re: The Failure of the USS Yorktown (2:1)
  Re: Hardware: ideal budget Linux box? (Re: I'm Ready!  I'm ready!  I'm (Bloody 
Viking)
  Re: BASIC == Beginners language (Was: Just curious....
  Re: No win situation for Linux market (2:1)

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

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, 23 Jul 2000 21:49:34 GMT

"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said Daniel Johnson in comp.os.linux.advocacy;
[snip]
> >> This in the middle of a discussion of network protocols?  This attempt
> >> at mis-direction is a 1.3, at best; it may be buried deep, but its
> >> hardly subtle.
> >
> ><shrug> We all have our off days. I'll try to do better next time! :D
> >
> >However, network protocols aren't exactly limited to the internet
> >either. I do think he is being fixated one *one* application
> >of these technologies to the exclusion of all others.
>
> No, he's not.

He's not?

> He's using one example to show a constant and menacing
> predation on *all* interoperability with Microsoft systems.

So you are saying he *is* being fixated, but for good reason?

I disagree. He's not showing any "constant and menacing
predaction on all interoperability with Microsoft systems".

He hasn't actually bothered to even show non-compliance
with any standards, though I'm prepared to take that
as read, as it were.

>  You weren't talking about any other interoperability,

Admittedly. Perhaps I'm too fixated on the Web, too. :D

> and nobody was talking
> specifically about the Internet or HTTP.  Your intent in this statement
> was clearly to try to back-pedal from a conclusive argument illustrating
> that your position is invalid by refocusing attention on non-network
> interoperability issues entirely.

I don't think I mentioned "non-network interoperability". But
now that you mention it, I really should. Interoperability
*within a single computer* is a very important thing, and it's
a real strong point of Microsoft's "put it all in Windows!" approach.

Shall we discuss OLE? That's non-network interoperability
for you!

> Just so you know that readers notice these things.

And I'm so glad they, or rather you, did. You're quite right;
I'm playing right into Leslie's hands by being just as
fixated on the network as he is.

But the *problem* of making diverse systems work
together goes way beyond that! I've been crippling
my arguments for no better reason than a depressing
lack of imagination on my part.

Thank you! Whatever would I do without you?

> >Leslie's arguments on this subject isn't entirely clear to me,
> >but it does *seem* to depend upong computers being
> >simply "internet terminals", and no more.
>
> Leslie's arguments on the subject are decisively clear and poignant,

"Poignant"?

I dunno. He's a swell guy and all, but he's not Shakespear.

But I must point out that, even if his argument about "public access"
is clear to you, it isn't clear to *me*. No doubt due to the advanced
Artificial Stupidity (tm) technology I use, of course, but still. :D

> and
> is in no way reflective of the straw man you wish to build.  You, on the
> other hand, have no validity in your position, and have not been able to
> defend your vague and inaccurate notion of "interoperability" in the
> slightest bit.

Well, it hasn't been *attacked*,  you know.

Y'all seem quite content to simply treat "interoperable"
as a synonym for "standards compliant", and leave it
at that. Doesn't give me a lot ot defend against.

>  One would suspect from the behavior you've shown that
> you may indeed merely be an astroturfer,

Oh, I wish!

> as I've never seen a worse
> assault on logic to confuse the issues as you have demonstrated, outside
> of an intentional effort to obfuscate.

I've tread lightly on logic; I feel that it's best to let your opponent
bury himself. You've been quite obliging in this; all I need do is
pig-headedly keep the discussion on the appropriate topic,
and you'll spound on manner of entertaing, um, stuff.

I hardly *need* logic for that. :D




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

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, 23 Jul 2000 21:49:35 GMT

"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8kqk89$1rn7$[EMAIL PROTECTED]...
> In article <a2_b5.8056$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
[snip]
> >> The price is not so relevant as the quality.
> >
> >I see. So why does MS upset you so? Is it *so* bad for MS
> >to offer low-quality, cheap goods?
>
> I think what really bothers me is the deceptive representation.
> If the advertising mentioned that the products only worked
> part of the time, or maybe mentioned the engineering
> effort that went into *not* working with competitors products
> it would seem more reasonable.

Admittedly, Microsoft advertising doesn't exactly tell the
whole story. But you can't exactly single Microsoft
out on this one; There are very few software manufactures
willing to take *any* responsibility for defects in their
software. Microsoft ain't bucking that trend!

The "engineering effort that went into *not* working with
competitors products" is, of course, largely a figment
of your imagination. :D

> I suppose automobile manufacturers have a right to build
> cars that crash for no reason too, but you can't expect
> the customers to be happy when that comes as a surprise.

Yeah. But the thing is, the demand for software is so great,
consumers will put up with an awful lot of crud to get products
that do what they need.

That'll probably change someday, of course. Could be a whole
new world for the industry when it does!




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

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, 23 Jul 2000 21:49:37 GMT

"Leslie Mikesell" <[EMAIL PROTECTED]> wrote in message
news:8kqoln$23io$[EMAIL PROTECTED]...
> In article <62_b5.8055$[EMAIL PROTECTED]>,
> Daniel Johnson <[EMAIL PROTECTED]> wrote:
[snip]
> >Sure. What you do is you get a plug in that speaks the IBM 390's
> >langauge (or the Sparcs). Somebody has to write one of course;
> >in this case I believe Microsoft *has* written one, but if they
> >haven't then IBM can do so. Or heck, you can hire someone
> >to do so. Or even do it yourself, if you've the skill.
>
> It takes more than skill to write code that makes 2 proprietary
> products interoperate.

That's right- it takes *tools*; but Microsoft will gleefully sell
you the tools you need.

>  It also requires trade secret knowledge
> about both products.

Well, it make take trade secret knowledge about the IBM/390,
I don't know, but what you need to know about Windows is
available on the Web. MSDN rocks.

>  If such a thing exists and works 100%
> correctly it may turn out to be usable.

Software is never 100% correct, sad to say, but
it is likely to be usable even if imperfect.

>  However, if it doesn't
> exist there may be no way to create one since you may not
> be able to get access to the necessary secrets.

Then again, you may. Certainly MS isn't standing in the
way.

But if you really are dealling with a *firmly* closed system
that uses only undocumented, secret protocols and APIs,
*and* the vendor is not willing to do anything to help you-

They you are just out of luck.

But you are out of luck with 'standard protocols' too; that
firmly closed system won't use 'em, that's for sure.

>  And if it
> doesn't work reliably you have no way to diagnose the problem
> if it doesn't follow a published protocol.

If you want to talk to an unmodified IBM/390, you'd better
know the protocol its using. But if IBM wrote the plug in
for you, presumably they'd know the protocol.

> >Plug in that plug in. Now you are speaking the IBM 390's
> >protocol, and it can talk to you without itself being modified
> >at all.
>
> To make this approach work you need a plug in for every
> possible source to match every possible destination.

No, only the ones you are using.

> And in the likely event that it doesn't work, how do you
> tell what is wrong?

That will depends on the specifics on the case.

> >Now, how do standard protocols help you with this, if
> >the IBM 390 is going to be uncooperative. I had options:
> >I can change the plugs in on my computer. What can
> >you do but abandon your protocol?
>
> Using standard protocols, it is a 1-1 problem,

A "1-1 problem"?

> every
> endpoint only needs to know it's own trade secret
> information to implement open standard protocols,
> and by now most things have done so.

You are still fixating on the Internet, I think. Many
things have implemented the protocols needed on
the Internet, but that's just one little corner of the
industry.

[snip]
> >Such products are often the *best*, actually; in this industry,
> >one often tries to differentiate oneself from ones competitors
> >on quality and features.
>
> Or, by doing things that intentionally break the competitors
> products...

That doesn't work. What you do is offer features your
competitor doesn't have. Once your users depend
on those features, you've got them.

Microsoft has the insight to see that it doesn't matter
if you *also* support the 'open' protocols. You've
still got them.

> >> But unless you use standard protocols you won't be able to
> >> match them on the other end.
> >
> >With plug-ins, you can plug in the module for the protocol the
> >other end is using. Without them, you just need to make sure
> >every 'end' is using the same protocol.
>
> An n x n choice versus an n x 1 choice.

Hey, more choices are *good* right?

I say that in this case more options are good, because some
of the extra options that extra n buys you let you cope
with uncooperative systems- a very desirable thing.

> >But it does not matter whether it is an open standard or not;
> >proprietary standards work just as well as a 'common
> >protocol'.
>
> That depends on the nature of the proprietary standard.

Oh?

>  Is it implemented for your target platform?

This problem is no less great with 'open standards'.

>  Can it be implemented?

Well, if you have plug-ins, sure it can! :D

>  Is there enough published information to
> diagnose problems?

One should hope so.

[snip]
> >So, what they define are standards because they defined
> >the standeards for publuch interaction.
> >
> >Seems a bit circular.
>
> Yes, as are all matters of definition.

No, not as a rule. Usually you define things in
thems of *other* things.

> >Why the IETF and IEEE and not some *other*
> >organization?
>
> Don't forget ISO...  These are the organizations that
> set public standards.

Oh yes, can't forget them.

>  Other organizatons can provide
> documentation and standards-conformance testing
> for anything any group wants.

So who died and made IETF, IEEE, and ISO
king?

Why the IEEE and not the ACM, for instance?

[snip]
> >However, I would submit that when you posted your
> >message, you only gave me one alternative, not
> >two: "MS has made a lot of non-standard stuff
> >that won't interoperate with other things"; so
> >I don't see that there was much to choose from.
>
> There isn't.  But pick your own example of what
> you think represents Microsoft's 'progress' that
> you keep expounding has to be done in non-standard
> ways.

Given that choice, I'll take progress over standards! :D

But is that what you meant in the first place?

[snip]
> >> No, I think many people notice - they just don't know what
> >> to do about it.  After all, if they were expert HTML
> >> producers they wouldn't be using FrontPage.
> >
> >Is that beause there is no other product that non-experts
> >can use to make HTML?
>
> No, it is because Microsoft is very good at selling their
> products, or bundling them with other products if they
> have an ulterior motive to get them on more desktops.

I think part of your argument is missing. This doesn't
seem to lead anywhere as it stands.

[snip]
> >Hmmm? I hate to say this, but carrying attachments does
> >mean *some* kind of protocol to say "this bits an attachment";
> >if the sender does not know it, it can't attach files. If the
> >receive does not know it, it can't decode them.
>
> Ah, that would be a problem for systems that build everything
> into one program.

IE, not Windows. :D

How many programs are involved are irrelevant, however.

> On systems were it is easy to manipulate
> data through pipes or use files as intermediate storage,

IE, Windows. :D

> programs other than the mail client can be added to
> handle the decoding of attachements and manipulation of
> the multimedia parts.

Oh course. But those programs must know the protocol;
I don't think you've bought yourself anything here.

> >I think you are mistaken. While transport changes wouldn't
> >be requiried, some kind of addition or change the the
> >protocols is needed to add attachments to a protocol that
> >hasn't got them.
>
> Since the protocol is publicly known, programs to deal with
> them can be added without needing any trade secrets.

Yes. But this is true even if the protocol isn't publically
known.

>  If
> the attachment is text, you can just ignore the wrappers
> that make it an attachment and view it with any mailer
> that knows about text.

Really. How do you deal with CR/LF translation then?

> If it isn't, you can hand it off
> to a program that does know about it, or just knows how to
> extract the attachment to a file.  If the file itself
> turns out to be some proprietary format, you are still
> screwed, though.

Well, unless you have a program that can cope with
that format. Proprietary or not, makes no difference.

[snip]
> >Oh, good. Then you've no objection to Micorosft making up
> >their own protocols, or whatnot.
> >
> >I apologize for insinuating that you felt otherwise.
>
> I do feel that they should be advertised as such, though,
> instead of using the same names that others use for
> something different (domains, java, html, etc.).

I think it's possible to be too picky about that;
Calling IE's language something other than
"HTML" is going to obfuscate more than it clarifies,
in my view.

[snip]
> >This is, of course, where we part company:
> >I don't define "interoperation" like this.
> >
> >But suppose we did. Why should anyone
> >*want* to be interoperable, if it is merely
> >synonymous with "follows standards"?
>
> So that you remain free to choose the vendor
> of the next product you will use.

Why does "follows standards" buy you anything
that way?

>  Why would
> anyone want to give up this choice by installing
> something that does not follow standards?

I would claim that following standards doesn't
give you any choices you didn't already have.

[snip]
> >Yup. I don't see why we can't have ISA and PCI and
> >Microchannel if we want them all.
>
> You can.  But the software you accept would be the
> equivalent of a Compaq-PCI that would only accept
> cards blessed by Compaq.

That's not so. It's more like those "16 bit ISA" slots that
provided additional connectors so proprietary cards
could, at your discression be added. Some of these
cards could not be transfered to another computer
because it wouldn't have the proprietary extension.

But it *would* accept ordinary ISA cards.

Such things have existed. Think EISA. I've no problem
with it.

>  And a different Dell-PCI
> with different cards.  Didn't I mention ethernet
> before?

Did you? I've forgotten already.

>  Would you consider it acceptable to have
> to buy every network component from the same vendor
> to get them to interoperate at the hardware level?

Yes, of course that's acceptable. It's just not *ideal*,
and it is not the situation we see with software, either.

> If not, why is it OK for the software protocols
> to have to come from a single vendor?

They don't.

> >I've used many computers which failed to standardize
> >this- they had PCI and ISA both, and it was no problem.
> >
> >The flexibility is useful to have.
>
> But that is not what you are describing for software.
> You are allowing one vendor to dictate a proprietary
> protocol.

Surely. But I'm also 'allowing' that vendor to support
*multiple* protocols- like that PCI-and-ISA computer.

Heck, I'm 'allowing' that vendor to provide APIs to
add new protocols later. Find hardware that'll do that!

[snip]
> >Nope. But I don't see that I have to use *your* solution
> >to this problem, when I don't think it works as well
> >as Microsoft's does.
>
> Buy some non-Intel compatible CPUs and see how well
> Microsoft's solution works.

Ah, you cut me to the quick! Well, as quick as I ever
get, anyway. :(

But the *idea* of plug-in software libraries is,
one hopes, not unique to Microsoft. I don't see
any fundamental reason why a non MS OS can't
do it just as well as Microsoft.

I believe Apple *does* do it, for network protocols.
They call it "Open Transport", though I suspect it wouldn't
pass muster with you as "open"...

[snip]
> >So, non-English is okay. How about non-Roman character
> >sets? Many computers do not have Kanji characters
> >installed. Web pages using such characters display
> >incorrectly; should they be disallowed because on many
> >standards-conforming browsers, they will not
> >display correctly?
>
> Standards are defined for character sets.  If the page
> mentions it correctly, then a conforming browser can
> be made to display it correctly.

Not so. You have to have the appropriate fonts installed,
and some of them are *big*; they are not standard issue.

Conforming browsers are sometimes quite unable
to display these pages.

[snip]
> >> The parties involved should know exactly what they are
> >> doing.
> >
> >Pretty harsh. Only experts are allowed on your Internet then?
>
> No, just informed consumers.

Perhaps your notion of "exact" is not as severe as
mine.

Are "informed consumers" expected to know the ins-and-outs
of protocols and formats?

[snip]
> >So you say. There is a middle ground: There are lots
> >of people who Just Don't Care (tm).
>
> Even so, I think they should be permitted to know that
> they are assisting Microsoft in their evil plan instead
> of just thinking they are generating normal web pages.

I think they might not agree with you about the Evil Plan (tm)
part.

[snip]
> >> The same browser that permits active-X?  Fat chance?
> >
> >:D You may have something there.
> >
> >If the browser will not enforce the sandbox, you are just out of
> >luck, standard Java or no.
>
> If COM objects are allowed in applets, how can the browser
> enforce anything?

How about if it only allows *server side* COM objects?

(Not that that's what Active-X does, mind you, but just
hypothetically...)




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

From: 2:1 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: The Failure of the USS Yorktown
Date: Sun, 23 Jul 2000 23:05:40 +0100



> Great measures are taken to insure that circuitry all over the ship remain
> unaffected.  And this doesnt just go for ships and nuclear radiation, most
> of the research in the area has been for the purpose of guarding against
> EM pulse attacks on airplanes.  The sheilding required is pretty
> straightforward and can take the shape of a simple case.
>
> -----yttrx

A simple case is usually too simple. EM radation can leak in through very small
gaps, such as ventilation holes etc... This makes really good rad shielding quite
difficult at times.

-Ed


--
Did you know that the oldest known rock is the famous Hackenthorpe rock, which
is over three trillion years old?
                -The Hackenthorpe Book of Lies
remove foo and revers e-mail address to make it any use



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

From: [EMAIL PROTECTED] (Bloody Viking)
Crossposted-To: alt.comp.hardware.pc-homebuilt
Subject: Re: Hardware: ideal budget Linux box? (Re: I'm Ready!  I'm ready!  I'm
Date: 23 Jul 2000 21:51:30 GMT


Marada C. Shradrakaii ([EMAIL PROTECTED]) wrote:

: Same story as with hard drives.  Try to get someone who will stand behind it
: (all of mine have six-month halflives)

I have much better luck with hard drives, both IDE and SCSI. I've had hard 
drives last for years, even with the computer on 24/7. I've even had SCSI hard 
drives run Linux on unsupported SCSI cards. I've also got both SCSI and IDE 
hard drives running in the same computer. The latter can be an interesting 
challenge to do in DOS but far from impossible. 

--
DANGER: Charles Darwin is the lifeguard of the gene pool. Swim at own risk.

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

From: <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: BASIC == Beginners language (Was: Just curious....
Date: Sun, 23 Jul 2000 14:43:41 -0700
Reply-To: <[EMAIL PROTECTED]>


Arthur Frain <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jim Richardson wrote:
>
> > Given that perl python and java are note compiled to machine executable
code
> > until they hit the interpreter (or JVM) how in heavens name would you
write
> > an OS Kernel in one?
>
> Mind you I think this is a *terrible* idea, but you
> simply need to build the byte-code interpreter into
> the kernel. This is the original IBM PC design - if
> you didn't boot an OS off of floppy or HD, it defaulted
> to a ROM'd BASIC interpreter. Same as the Sinclair ZX-80,
> or Intel 8052-BASIC, which is (was?) an 8 bit
> microcontroller (8051 family) with BASIC built in.

Opps, it looks like you crossed over from considering an OS kernel written
in BASIC, into the realm of BASIC interpreters written in assembler and
burned as machine code into ROM.



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

From: 2:1 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: No win situation for Linux market
Date: Sun, 23 Jul 2000 23:18:58 +0100

Bob Hauck wrote:

> On Thu, 20 Jul 2000 23:53:06 -0400, Aaron R. Kulkis <[EMAIL PROTECTED]> wrote:
>
> >they are already relying on Linux, and the admins trust it MUCH
> >more than any version of windows.  Give them a big-league CAD
> >platform (CATIA, UniGraphics, or SDRC I-Deas), and they'll jump
>
> I want:
>
> Pro Engineer

This is a little off topic, but I feel the need to vent on this on. I hate Pro
E. It should die a horrible, flaming death, especially the C interface API,
which I have had to use.

It was nasty, convoluted and almost every problem I encountered, the help staff
came back with:
yep... It's a bug in the interface.

-Ed


--
Did you know that the oldest known rock is the famous Hackenthorpe rock, which
is over three trillion years old?
                -The Hackenthorpe Book of Lies
remove foo and revers e-mail address to make it any use



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


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