Linux-Advocacy Digest #697, Volume #26 Fri, 26 May 00 10:13:03 EDT
Contents:
Re: Why only Microsoft should be allowed to create software (Illya Vaes)
Re: Would a M$ Voluntary Split Save It? (Seán Ó Donnchadha)
Re: Fun with Brain Dead Printers. (Donal K. Fellows)
Re: PHP vs Java (Andreas Kahari)
----------------------------------------------------------------------------
From: Illya Vaes <[EMAIL PROTECTED]>
Crossposted-To:
comp.sys.mac.advocacy,comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy
Subject: Re: Why only Microsoft should be allowed to create software
Date: Fri, 26 May 2000 15:16:42 +0200
Erik Funkenbusch wrote:
>>>>>DOS and Windows are OS's. They're not applications.
>>>>>Windows cannot run without DOS, thus Windows and DOS are joined.
>>>>(Then) Windows is not an OS. An OS runs without the help of another OS.
>>>Gee, I guess DOS/VSE under VM isn't an OS then. I guess NeXT and MacOS X
>>>aren't an OS then, since they rely on mach to function (actually there is
>>>more than a passing similarity between the way mach and it's client OS's
>>>run and the way DOS and Windows run.)
>>*You* gave the criterion "X cannot run without Y, thus X and Y are
>>joined".
>>Another strawman ofcourse...
>What? I stated that X could not run without Y. You stated that this meant
>that X wasn't an OS and I gave examples of other OS's that also required a
>different OS to run. What's your point? How is it a strawman? It
>directly refutes your statement.
Then what's the information in "Windows and DOS are joined"?
By the same logic, WordPerfect 5.1 and DOS were joined. You bought (or could
buy) them separately as Windows and DOS, you installed DOS first and WP second
like DOS first and Windows second and WP doesn't run without DOS.
If you want to maintain isn't a (special) DOS app like WP but *also* don't
mean to say Windows isn't an OS without DOS, then you've added no information.
It's a strawman because you deflect the discussion from "what the hell has
Windows to do with DOS internal structures" (or some such) to "Windows is or
is not an OS". I'm not arguing that one either way.
>>>>DOS is an OS, and DOS+Windows is an OS. Windows without DOS is not, it
>>>>doesn't run (Windows NT excluded ofcourse).
>>>And Darwin doesn't run without Mach either. mklinux doesn't run without
>>>mach.
>>And anything that uses Mach, if you want to look at it that way, just uses
>>the public API of Mach, not some internal data structures.
>The source for MACH is available, thus everything can be a public API, even
>code that is meant to be internal.
"Can be" != "is".
Linux is entirely available in source code, but that doesn't mean the internal
data structures of the kernel are available to me or they are suddenly exposed
in an API. You're reaching here...
>>>>Windows is as much an application as Borland C++ 3, Doom, GEOS, Dark
>>>>Forces, ... All are "DOS Extenders" (which I don't have to explain to
>>>>you).
>>>>Windows just has a pretty complete (but not always consistent) API that
>>>>"happens" to be used a lot (which is where their monopoly comes in).
>>>Doom and Dark Forces arent dos extenders either,
>>>they used DOS/4GW which was a DOS extender.
>>And Schulman showed that Windows "used a DOS extender" too. The nature of
>>these DOS extenders is such that they're included in the product
>>("binding") such that they themselves have become the DOS extender if they
>>expose an API to applications.
>You're saying that Doom and Dark Forces expose API's to applications?
I'm not saying they do or don't.
>Yes, the *CAN* extend DOS, and other than memory allocation, they generally
>do not. For instance, they do not provide their own file system services,
>Windows does.
You keep banging on the 'own' file system services that DOS Extender Windows
happens to provide. Is that your criterion for 'extending' DOS, providing your
own file system services??? You must be running out of arguments...
>>Providing an API has nothing whatsoever to do with the complexity needed
>>to accomplish that fact.
>>They provide an API 'equal' to the API a real PC box provides; if they've
>>done it successfully, the OS running on it sees no difference.
>I'm sorry, but emulating a CPU is not an API.
Ah, that does it, Erik has spoken so it's not.
What a crock.
A macro is an application of eg. a word processor + OS + machine.
A word processor is an application of an OS + machine.
An OS is an application of a machine.
A PC is an application of semiconductor technology.
See any similarities?
An API is a concept; any limitation to "programming an application for a
certain operating system" is purely your own "I don't want to see more than
this because it doesn't suit me".
>>So you want to argue that something becomes "more than a DOS extender"
>>because it happens to extend more of DOS than other DOS extenders that
>>happened to also have been _marketed_ as such?
>>I'd suggest a careful reread of Schulman's book.
>>There is *no* _qualitative_ difference between Windows (excl. NT) and a
>>general "DOS extender", only quantitative.
>There's no qualitative difference between a chimpanzee and a human either.
>We share almost the exact same DNA. There is however a huge quantitive
>difference, using qualitative and quantitive as you do.
Read the book (carefully) instead of trying to weasel out of it with
inappropriate comparisons.
>>If you want to argue something stops being a DOS extender when it
>>"replaces" more than xx% of DOS services in its own implementation, then
>>fine, name the number and come up with the number for Windows and other
>>DOS extenders.
>My argument isn't that it's not a DOS extender (I already said it provides
>one).
"Provides" != "is".
>My argument is that it's a great deal *MORE* than that.
Yeah, Windows extends X, Y and Z and handles A and B in its own code, while
DOS Extender "ACME" extends only X and handles C in own code.
>>Note, I'm not denying your tack of "Windows is an OS", but by the same
>>logic any DOS extender is an OS as well. If the latter isn't true
>>according to you, then Windows isn't an OS either. Pick one.
>An OS is something that provides OS-like services.
An ape is an ape-like creature, to stay in your inappropriate comparison.
Talk about circular reasoning.
>Not just
Here come the random 'criteria'...
>memory allocation, but file services,
>graphical input/output,
Ah, so DOS isn't an OS after all. Nor VMS or Unix when you're not running the
X Window System (DECWindows) or those pesky mainframes...
Gee, intelligent criterion, Erik... What did you have in mind, only Windows
must qualify???
>device management, etc.. Windows clearly provides those services,
Not very coincidental when you name only Windows 'services' as "OS-like
services".
How'bout rock-solid stability? Windows doesn't provide that service (and no,
NT doesn't qualify for me anymore, when it freezes on me at least once a week,
just running some apps)...
>and for the most part they're seperate implementations from the underlying
>DOS. Simple DOS extenders do not.
You said it right, *simple* DOS extenders do not.
We agree Windows is not a *simple* DOS extender...
>>>>>Untrue. MS is a large company that many of it's clients expect certain
>>>>Just keep beating that strawman!
>>>>Next you'll tell us that MS has to guarantee AutoCAD to run on Windows.
>>>Then why do they get blasted everytime an upgrade breaks someones
>>>software?
>>Because it's (usually) needless / on purpose and/or the broken software
>>used the API as documented???
>But you claim that MS has no responsibility to maintain such compatibility.
>Are you now changing that statement?
What part of "needless" don't you understand???
Since we're talking about "internal data structures" here (if you still
remember the topic after all your strawmen), you can hardly call 'not causing
software that uses the API as documented' the same as 'guaranteeing that
software to run'. *They* published the API and they should therefore
'guarantee' that correctly using it won't break your app. The can't guarantee
to *users* that the programmers from AutoCAD will use the API as documented
and nobody expects them to except a Winvocate looking for a strawman...
>>>And why is that called an example of their Monopolistic behavior?
>>Because it always happens to be competitor's products if there still is
>>competition in that app area or their own product if they've already
>>practically established a monopoly in the area of the app being broken??
>MS apps are occasionally broken as well. But usually they aren't. MS tests
>it's own apps against updates, it doesn't test every competitors app.
Which ofcourse isn't monopolistic either eh? Still want to maintain the app
competitors aren't disadvantaged.
They should test API conformance, not specific apps.
>>>What you fail to realize is that MS is the one that will be blamed for
>>>problems caused by the other code.
>>Get real. Applications get blamed for faults with Windows than the other
>>way around.
>By people that know. Your average joe will blame MS though, rather than the
>App.
a) Rubbish
b) Aren't buying decisions done by people who know???? (you don't need to
answer this, we know this not to be true)
>>I'm sure the knee-jerk reaction of MS weenies to my NT machine freezing
>>completely on a very regular basis is along the lines of "ah, but you
>>shouldn't run Netscape but IE!". So much for a stable and robust OS...
>Bugs happen.
"stable, enterprise class, mission critical..."
"bugs happen"
Uh-huh!!
Oh and BTW Gates disagrees with you, you know he said there a no bugs in
Windows 95.
>>>>If you think not, please tell us why you expected DOS apps to run on
>>>>"OS" Windows and Windows NT (apps that just use the public DOS API)?
>>>>Should they refuse to run on "whatever junk pretends it's MS-DOS"???
>>>That's their right. In fact, many apps DO refuse to run in a Windows dos
>>>box.
>>(So much for your esteemed "MS backward compatibility")
>>There's a difference between not running because you don't get enough base
>>memory or are denied direct access to resources under control of the OS
>>and refusing to run because this isn't MS-DOS 6.21 but MS-DOS 6.22, DR-DOS
>>instead of MS-DOS or because you didn't find some signature in some
>>internal data of DOS.
>>But I guess that's too subtle a distinction for you...
>No, you missed the point. I'm talking about apps that don't even bother to
>check if the services or memory they need is available. They just check for
>running under Windows and fail.
OK, let me rephrase this especially for those boneheaded app programmers
"there's a difference between not checking whether or not the services are
available and refusing to run somewhere where those services are known to be
specified as available".
>An example of this is the many DirectX games that checked for NT and failed
>to run or install if it was, assuming that NT didn't have DirectX. This
>obviously failed when NT4 later got DirectX and with Windows 2000 which has
>Direct3D.
And what MS did was the equivalent of ACME game programmer looking to see if
this was ACME Mindblows 2000 with Direct3D or Microsoft Windows 2000 with
Direct3D, which both implement the same game programming APIs, and refusing to
run on the MS one (or just giving a warning at beta time to see if they can
get away with it or that a stink is raised).
>>MS seeking out DR-DOS / non-MS-DOS in order to give some bogus warning
>>message (and if they'd got away with it later no doubt refusing to run)
>>doesn't mean there are / can be no _real_ compatibility problems.
>>So there was a real bug. It had nothing to do with the bogus message.
>Whatever the purpose of the message is really irrelevant to this
>conversation, which is simply that MS *DOES* have the right to warn people
>of incompatibilities.
At last you're starting to show your true colours: "they can do whatever they
want".
We knew that, that's why we call it a monopoly. We want to change that, so
that a really open marketplace acan actually *punish* them for completely
unnecessary 'warnings' that are only for anti-competitive objectives.
>And what makes you think it was for one reason only? I've offered several
>other viable reasons for it.
Apparantly I and others disagree with the viability of the reasons. You can't
argue one separately and then use all your other bogus partyline 'reasons' to
'support' the one, while you do the same for every other one.
>I'm not saying that my reasons were the only
>reasons either. Clearly, MS was also trying to protect it's monopoly, but
>my point was that there *ARE* legitimate reasons to do this as well. Don't
>take my arguments as being absolutes. Nothing is ever absolute (You'll
>notice many of my arguments are arguing the absolute nature of the
>statements made such as "for one reason only").
Everybody agrees there are good reasons to keep internal data structures
internal. But that then goes for everything. If the API is good enough for WP,
it's good enough for Windows.
Those reasons were not why this AARD code was put in, that was just to cut off
DR-DOS.
>>>>>As an example, car companies frequenly provide circumstances in which
>>>>>their
>>>>>warranty will be voided if they do things which can cause the product
>>>>>to malfunction. Example, putting in unapproved motor oil. Since GM >>>>>can't
>modify their engines to prevent unapproved motor oil from being >>>>>added to their
>cars, their only choice is to void the warranty.
>>>>Does GM sell (inferior) motor oil?
>>>How does that relate to the DOS/Window example?
>>Hey, you gave the example...
>And i'm asking you how it is relevant. What does inferior have to do with
>anything?
Everybody agreed DR-DOS was better than MS-DOS, and especially until MS
finally caught up with DR (feature-list wise, not in practice) they had an
inferior DOS.
But you can leave off the 'inferior' if you'll really get hung up on it...
>No, the whole point is that both Windows and DOS are OS's or at least
>OS-like. They provide similar services, and thus are roughly peers. A
>radio is not a peer of a vehicle. A radio is an application, clear cut.
>There is no such clear division between DOS and Windows.
The point isn't at all about "OS or not OS".
It's about APIs ("internal data structures" *implies* an API), and that API
should be the only deciding factor in the working of the application.
If it conforms it must run, and that goes both ways, regardless of what the
actual API (AP _Interface_) is...
>As I said, MS has a legitmate right to limit it's products to work with the
>products it knows will work. It doesn't matter if there are actual
>incompatibilities or not.
Then the discussion stops, doesn't it???
"MS is right"
You're a real consumer advocate...
>>>Well, if that was it's intention, YOU should seriously consider your use
>>>of the language.
>>I guess you still deny any possibility of you putting things "wrong".
>>Too bad, your problem.
>You're avoiding the statement. Your response, as you claim it was intended,
>did not convey that message.
Please, start calling me names, I'm sure that will convince me you are right
and make me see exactly how you meant everything.
>>>I doubt anyone else saw the phrase your way.
>>I doubt that. We'll let the reader decide, which is just what I mean:
>>regardless of how *you* say something was meant, the reader decides how it
>>comes across.
>Which is why you and others statements about what I intended with mine are
>hypocritical.
We can only say how it comes across with _us_.
If you have not problem with it coming across differently than you intended,
then there is no problem. If you have, blasting us for us isn't likely to make
us see the light....
>I'm not defending WHY they did them per se. I'm only saying that they have
>a right to do them for legitimate reasons. I'm not saying that all their
>reasons were legitimate, but I am arguing that not all their reasons were
>nefarious in nature. I'm arguing the middle ground, which is that there
>are neither all good reasons or all bad reasons, it's a mixture.
You must be a high MS executive, since you were obviously there when they went
over the possible reasons.
Anyone else can only speculate and look at what and how they have done and
what emails accompanied the actions and draw logical conclusions from them.
There's only one logical conclusion: cut off DR-DOS.
>>>If MS marketed the product as an add-on to DR-DOS and then caused
>>>deliberate failures, that would be one thing. But it wasn't marketed for
>>>that, thus the buyers use of an unauthorized co-package is not MS's
>>>fault.
>>A "co-package"?? What a load of crap!!!
>>You sure you're not a lawyer for MS (puke)???
>co-package was the only way I could phrase it. What would you call darwin
>and mach? I call them co-packages.
You buy and install Darwin and Mach separately like DOS and Windows???
The term seems designed to facilitate the argument, not the other way around.
>>>>Which has nothing to do with the public face they happened to have put
>>>>on at the same time. If you were to do that, would you say "we're
>>>>singling out our competitor's product with this" or try to side-step it
>>>>by lyin...eh... marketing?
>>>MS's handling of the situation was poor in many ways.
>>You mean they got caught (yet) again?
>No, I mean their handling of it was poor. Rather than discuss legitimate
>reasons for what they did, they choose instead to try and wash it all away.
If there are no credibly applicable legitimate reasons to discuss (seeing the
emails, the AARD code, the encryption of said code ...) they had little choice
but to get caught...
--
Illya Vaes ([EMAIL PROTECTED]) "Do...or do not, there is no 'try'" - Yoda
Holland Railconsult BV, Integral Management of Railprocess Systems
Postbus 2855, 3500 GW Utrecht
Tel +31.30.2653273, Fax 2653385 Not speaking for anyone but myself
------------------------------
From: Seán Ó Donnchadha <[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: Fri, 26 May 2000 09:18:52 -0400
[EMAIL PROTECTED] (Donovan Rebbechi) wrote:
>>
>>Unfortunately, although he *SHOULD* be deciding on a remedy, this
>>particular nutjob is obviously on a bloodtrail...
>
>So what kind of remedy would you propose ? I agree that action taken should
>not be punitive, but I find it hard to believe that anything less than a
>structural remedy will be effective.
>
I don't know what the remedy should be, but I don't see how a breakup
along product lines will accomplish anything. Then again, neither will
any behavioral remedy. I suppose I could go along with some kind of
breakup, but not any that have been proposed so far. The worst thing
that could happen is for Windows to lose (a) any of the components
that are currently integrated into it, or (b) the ability to amass
further functionality.
Someone else here said that the problem with software is that it's
infinitely pliable. I think it goes beyond that; pliability isn't just
a peculiar property of software; it's the very nature of it. That
which Mr. Jackson is calling "illegal tying" in this case is nothing
less than the lifeblood of the software business. All software, in all
application categories, survives by gradually absorbing functionality
that previously resided elsewhere. That's why word processors have
grown spell checkers, drawing tools, and file managers. That's why
spreadsheets have grown word processing and graphics features. That's
why the Java framework started out bare-bones and is now a rich API
for everything from database access to 3D graphics. Software *MUST*
adapt with the times and absorb new capabilities; otherwise it dies.
To say that a software product can no longer evolve this way is to
kill it, plain and simple. But to say that the most important software
product (Windows) cannot adapt to the most important technological
trend in decades (Internet/Web) is outright insanity.
So no, I don't know what the remedy should be. Everything proposed so
far has been either ineffective or harmful. There seems to be no
middle ground. One thing's for certain, though: antitrust laws must be
overhauled for the information age. In their current form, they just
give assholes like Joel Klein the power to destroy it.
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: comp.os.linux.hardware
Subject: Re: Fun with Brain Dead Printers.
Date: 26 May 2000 13:36:55 GMT
In article <c%8X4.60$[EMAIL PROTECTED]>,
Bloody Viking <[EMAIL PROTECTED]> wrote:
> In comp.os.linux.advocacy 2:1 <[EMAIL PROTECTED]> wrote:
>> That's one of the best flames I've heard in a while! LOL!!!
> Yeah, it's not every day you come across someone with a Winmodem for a
> brain.
Conclusive proof that you don't hang around in cemetaries or morgues...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- I may seem more arrogant, but I think that's just because you didn't
realize how arrogant I was before. :^)
-- Jeffrey Hobbs <[EMAIL PROTECTED]>
------------------------------
From: Andreas Kahari <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.help,comp.unix.programmer,comp.os.linux.misc
Subject: Re: PHP vs Java
Date: Fri, 26 May 2000 13:44:06 GMT
I don't know of any links to the info you want and I'm not an authority
on neither PHP nor Java but I do know that PHP is executed by the server
and that Java programs are executed by the client. So if you expect to
have a lot of clients connecting to your server you have to remember
that large PHP codes might slow things down for you (this might not be a
big issue).
And as usual, the choice of programming language depends on what you
want to do. Are you looking at PHP and Java for doing queries to
databases or for doing GUI stuff or something completely different?
Which language have the best API for the tasks that you want to perform?
/A
In article <[EMAIL PROTECTED]>,
Ben Chausse <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We have a webserver on Debian 2.2 with apache 1.3.12 & mod_perl 1.21
and
> I would like to know what is the best between PHP and Java (.php or
> .jsp) ????
>
> Do you know any web pages about benchmark test on PHP and Java ???
>
> Thanks ...
>
> Ben0iT ...
>
>
--
# Andreas Kähäri, <URL:http://hello.to/andkaha/>.
# All junk email is reported to the appropriate authorities.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
