Linux-Advocacy Digest #530, Volume #28 Mon, 21 Aug 00 03:13:04 EDT
Contents:
Re: Windows stability: Alternate shells? (R.E.Ballard ( Rex Ballard ))
Re: Linus says Mindcraft was accurate ("Mike Byrns")
Re: Would a M$ Voluntary Split Save It? ("Mike Byrns")
Re: Would a M$ Voluntary Split Save It? (Courageous)
Re: Would a M$ Voluntary Split Save It? ("Mike Byrns")
Re: Richard Stallman's Politics (was: Linux is awesome! (T. Max Devlin)
Re: Would a M$ Voluntary Split Save It? (tholenbot)
Re: Would a M$ Voluntary Split Save It? (Courageous)
Re: Would a M$ Voluntary Split Save It? (Courageous)
----------------------------------------------------------------------------
From: R.E.Ballard ( Rex Ballard ) <[EMAIL PROTECTED]>
Subject: Re: Windows stability: Alternate shells?
Date: Mon, 21 Aug 2000 06:37:23 GMT
In article <yr0n5.6505$[EMAIL PROTECTED]>,
"Erik Funkenbusch" <[EMAIL PROTECTED]> wrote:
> "R.E.Ballard ( Rex Ballard )" <[EMAIL PROTECTED]> wrote in message
> news:8nhokh$v4f$[EMAIL PROTECTED]...
> > > You do realize that AT&T and the bells have always used
redundancy.
> > > switches fail, but they've always had extensive cutovers and the
> > > ability to re-route around failures.
> >
> > Yes. I was a developer on one of the first computerized Directory
> > Assistance systems to go nationwide.
>
> Then why did you insinuate that Unix stability
> was the reason phone systems
> genearlly have zero to little downtime?
Because modern telephone switching systems are controlled
by UNIX based switches such as the #5ESS and similar switches
from Northern Telecomm.
Nearly every carrier and regional uses UNIX in some flavor for it's
mission-critical systems.
> >We had developed the original
> > using PDP-11s and a hacked up version of RT-11, with one of the
> > very first clustered systems. We ran 8 PDP-11/44 processors per
> > cluster, connected to up to 32 group controllers, each group
> > controller supported up to 24 8085/8088 processors and up 20
> >terminal
> > cluster controllers.
>
> With that kind of redundancy, you could run a 24/7/365 shop
> on Dos 4 (the most unstable version ever released).
> What OS you're using is irrelevant to
> the overall reliability in this case.
Not entirely. The one critical requirement was that the entire OS
had to be available in Source code format because problems needed
to be FIXED in a very short period of time. When a bug affected
one machine, it usually hit all of them very quickly. The bug
had to be fixed before multiple machines were lost.
In one case, after an operator had taken down the system 3 times
(we had ways of finding these things out) we paid him $500 cash
to show us what he did. We fixed the bug in 7 hours. At no time
during this "test phase" was the entire system down for more than
a few minutes, but in production, with money due back to the client
if downtime exceeded 15 minutes/year, this was a bug that had to
be fixed. On numerous occaisions, it was only because we had
the source code to *everything* that we could quickly handle the
problems that did come up.
> > Keep in mind that this in 1983, about 7 years before the first SQL
> > databases appeared for UNIX.
>
> Hmmm.. Strange that Oracle was founded in 1977. And I certainly
remember
> using Informix on DG/UX in the late 80's.
But Oracle wasn't offered for UNIX. I could be wrong about that, but
my understanding was that they were targeting the Series 1, VMS, and
low-end mainframe markets with some PC market. I remember Ingres in
the mid 1980s, and Oracle and Informix in the very late 1980s. I
know that some vendors had begun to support UNIX, but the real discovery
of UNIX as a database platform was around 1990. This is when Oracle
cleaned up it's customer support program and established itself as an
enterprise class company for the UNIX platform.
> > > Although these systems were primarily
> > > mainframe based until recent years.
> >
> > Mainframe - as in OS/370?
> >
> > Most of the tactical and strategic systems were implemented on
> > supercomputers using either ADA or a combination of ADA and UNIX.
>
> ADA is a programming language. Unix is an OS. ADA was designed to be
OS
> independant, and was (I think) first developed on CDC Cyber systems.
I was
> using ADA in 1985 when I was in the army.
Good. I'm sure you know more about this than I do then. About all I
remember of that period was doing the Dahlgren tests for the Navy.
At least that's all I'm *allowed* to remember :-)
>
> > I'd read it about 3 years ago, and it correlated to an article in a
> > print publication (Info-World?) where vendors who were frustrated
> > with Microsoft for not supporting their Windows 3.51 and Windows 95
> > porting attempts, resorted to testing with Linux systems using
> > interchangable wrapper APIs. Many early winsock implementations
> > were based on the adapter software written by the same person who
> > wrote net3 and many of the packet drivers for interface cards.
>
> Really? 3 years ago vendors were not providing Linux drivers. They
were
> all written by Linux enthusiests. Drivers being supplied by vendors
is a
> very recent thing.
Actually, the KA9Q drivers and the Linux drivers were among the first
ported to Winsock. It was easier to plug a simple veneer between the
working driver and the winsock API. You could pretty easily slip NDIS,
ODI, or KA9Q over any of the packet drivers, Winsock needed NDIS.
I believe the NE2000 driver was running on Linux before it was available
under Windows 95.
> > In windows, interprocess communication wasn't really formalized
until
> > MSMQ. Prior to that, NT provided DCOM, but with a 95% loss of
> > performance (20 times slower) when switching from COM (in-process)
> > to DCOM (out of process), it was avoided like the plague.
>
> More Rex-no-babble. DCOM is a remoting architecture.
DCOM can be used for either interconnecting two remote machines,
OR for interconnecting to independently running processes. We
evaluated this capability at Prudential (since this would have
reduced the instability between 3rd party vendor libraries.
Unfortunately performance was so slow that we decided do go with
in-process COM instead. The decision killed 2 projects (which had
problems with library cross-talk).
> It has nothing to do
> with out of process IPC (which occurs on the same machine).
> IPC has been "formalized" since NT in 1993, when it provided
> such things as pipes, named pipes, mail slots, shared memory,
> and message passing.
Unfortunately, most of these offer poor memory protection and/or
increase the risk of deadlocks. Prior to NT 4.0 Svc Pack 3, which
put semephores everywhere, BSODs due to corrupted IPC, Video, and
Winsock were very common. Even under NT4/SP3 applications written
directly to lower level MFC and OLE APIs were notorious for BSODs.
Eventually, the ISVs revised all of their applications to support
the new APIs, and usually had to distribute them freely. Many
vendors also opted to load the older versions of some of the DLLs.
> DCOM is much slower because it's used between machines,
> over a network. Not between processes on the same machine.
It's not practical to use DCOM between processes on the same
machine, but it is possible. When you have two processes which
are independent, they can be connected via in-proccess, out-of-process,
or networked objects. When you wanted independence to the point of
being able to change the components at run-time, you had to at least
go out-of-process. Behind the covers, you were running DCOM over
Winsock.
> > Again, Microsoft is aware of these problems in NT, and has made a
> > number of changes to Windows 2000 to eliminate them. In some cases,
> > they preserved the windows APIs while cleaning up the back-end. In
> > other cases, they introduced new APIs like COM+, MTS, and MSMQ.
>
> Again, you have no idea what COM+, MTS, or MSMQ are, do you? They're
> transactioning technologies for use in large scale database
applications.
> They have nothing to do with IPC in general.
MSMQ can be used for IPC, similar to MQSeries (which I know a GREAT DEAL
about). MTS provides protection between the threads when hundreds of
connections are made to a single server process, similar to the way
UNIX or LINUX ip deamons fork processes and let the child handle
the accepted connection.
COM+ is an abscraction of COM for C++ that hides most of the ugliness
of thread management, object management, and DCOM from the application
programmer. Essentially it makes the C++ version look more like the
friendlier VB and J++ versions.
At least that's what this here book from Alex Homer and David Sussman
says (boiling down a 493 page book into 3 paragraphs).
> > Of course, these are proprietary interfaces, incompatible with any
> > other platform, which assures that you will have to do a major
rewrite
> > to port to other platforms, depend on very expensive software for
> > Windows2000->UNIX migration, and because you are depending on 3rd
> > party software, you risk instability resulting from Service Packs
that
> > may accidentally or deliberately render these 3rd party products
> > disfunctional.
>
> Incompatible with any other platoform? I guess that's why COM and
DCOM
> exist for Solaris and HP/UX. You should know that almost nothing is
> incompatible with another platform, it just takes someone to write it.
Only a very limited subset of COM and DCOM exist for these platforms.
Microsoft first farmed it out, and later took it back, partly because
the third party vendor was providing too many of the hooks needed for
CORBA Client GUI objects.
Many of the features of COM, such as drag-and-drop, dde, and embedding
are not supported for X11 interfaces. Gnome and KDE provide similar
functions that can be mapped via CORBA, but not without more than
Microsoft makes available. Otherwise, it would be trivial to run
Microsoft COM/DCOM applications via Linux/UNIX or X11 clients.
> > In UNIX a much higher percentage of the executable and static memory
> > is shared by all processes. Futhermore, a larger percentage of
> > the buffer memory is also shared.
>
> And how do you quantify this statement?
Compare memory utilization, number of processes on UNIX vs
number of Processes on Windows. Number of threads on UNIX vs
number of Threads on UNIX. Compare the memory utilization for
UNIX vis the memory utilization for Windows for the same number
of processes. It's not at all unusual to see 200 to 300 processes
on a Linux workstation, and 2000 to 3000 processes on a Linux server.
The statistics on both machines can be easily monitored.
Of course, we're comparing apples and oranges. Linux runs thousands
of processes that all call a very small number of highly optimised
(to reduce thrashing, swapping, and cache misses) library routines
that are rarely paged out. Each process has only a few kbytes of unique
code. Many contain only a few hundred. The "biggies" are X (neary
12 meg) and ld-linux.so (sharable verion of the Motif library used by
Netscape).
> > > MS has had pipes for years.
> >
> > Yes they did. From 1982 to 1995, you could pipe output from one
> > command into another command. Of course the implementation left
> > something to be desired. You ran the first program and stored
> > all of the output into a huge hidden file, when the first program
> > completed, the second program would read the hidden file. When
> > the receiver program was finished, it erased the file. Disk space
> > was critical.
> >
> > Windows 95 improved things a bit, using memory between the
processes.
> > Eventually, NT did it the "UNIX way" - filling a very small block of
> > memory, passing the small block to the receiver, and the receiver
> > would pass control back to the sender when the block was drained.
>
> NT had "Unix way" pipes from day one. It didn't "eventually" do it
that
> way. My first edition "Inside Windows NT" by Helen Custer (1992)
describes
> them in detail. You're confusing DOS and Win32. Windows 95 was not
the
> first Win32 architecture.
Correct. NT 3.51, if you considered that a viable and successful
product
(which didn't sell very well as anything other than a file-server)
then you *could* say that NT has had UNIX style pipes since 1994. After
over 10 years of making pipes unworkable. The key is that it wasn't
considered a strategic means of communicating between processes.
Microsoft discouraged the use of direct access to pipes and sockets.
They discouraged the use of streams. They prefered that programmers
call their proprietary APIs which would grab values from the stream,
or put values onto the stream, but which gave the programmer little
or no control of the the data being streamed. Even ISAPI tries to hide
the formats of HTTP and HTML.
Compare this to UNIX, where parsers and scanners like Yacc and PERL
give the application programmer direct access and control over both
input streams and output streams. Compare this to CORBA where backward
compatibility is carefully protected.
Backword compatibility of Windows in an oxymoron, and it's contrary
to the revenue and marketing intrests of Microsoft's current revenue
structure. If Microsoft DOES start selling service contracts, backward
compatibility will suddenly become a VERY strategic benefit.
Personnally, as someone who does still have to deal with NT and
Microsoft pretty regularly, I'd LOVE to see Microsoft adopt a
support based revenue model. It would make my job as an integrator
and architect MUCH easier.
> > Actually, the "UNIX way" is to have two blocks of memory. This way,
> > the sender can fill blocks WHILE the receiver is draining them.
> >
> > Unfortunately, unless you have the NT resource kit, most Windows
> > programs are still written to a paradigm based on huge monolithic
> > objects that must be read into memory in their entirity before the
> > methods of the object can be invoked to modify the object. If you
> > have a large object such as a BMP file, or a Word document, this
> > can involve megabytes between the processes.
>
> What the hell are you talking about?
> What does the NT resource kit have to do with anything?
I first found out about it when investigating the possibility of
getting an MCSE. Everyone I talked to, online and offline said
that the first step was to read the NT resource kit cover to cover
(pretty good reading, some of Microsoft's best).
Of course, the NT resource kit also has all of the POSIX tools, and
a bunch of UNIX-like tools that I also found VERY Interesting.
This is ONE Microsoft product I was GLAD I purchased. To me,
NT isn't complete without the standard NT resource kit installation.
> > > > Finally, Microsoft depends on proprietary file formats that
can't
> > > > be parsed by either stream parsers or by human beings. This is
> > > > because Microsoft wants it's content to be managed as objects
> > > > created exclusively for and by Microsoft Applets rather than as
> > > > information created by and used by the end-user.
> > >
> > > Anything can be parsed.
> >
> > Yes, but if you must know the length of the entire object before
> > you can send the first bytes of the header, which contain the
> > size of the rest of the entire object, parsing takes quite a bit
> > more memory. Furthermore, if you have to allocate memory for the
> > entire object and read the contents of the entire object into memory
> > before you can execute methods against the object, you have
additional
> > latency as well as memory.
> >
> > By using streams of smaller objects, such as words, lines,
paragraphs,
> > and similarly delimited tokens, whether the objects are sent via
> > XML or unix strings, you can parse smaller tokens using very little
> > memory and pass information to the next stage of the chain while
> > you work on the chunk coming from the previous stage of the chain.
> > If you have enough processors, you can even put the machine into
> > a trivial multiproccessing mode that speeds the chain considerably.
>
> Please, pray tell, let us know how Unix changes all this.
UNIX used delimited streams from the very beginning and established a
set of standards for creating, passing, and parsing delimited streams
rarely required more than a few hundred bytes of memory. I've created
stream processors that handled reconciliation, auditing, and
summarization
of multiple 30 gigabyte tables with only a few hundred lines of PERL
code.
Even though PERL is fully available on NT and Linux (though the NT
version
is a bit crippled by lack of many UNIX functions) Microsoft has strongly
discouraged the use of it, promoting VBScript instead.
> > > If text based file formats are so cool, why does
> > > the Red Hat packaging system use binary fiiles for it's file
format?
> > > Check out the files in /var/lib/rpm.
> >
> > Look at the details more closely. They use a combination of
compressed
> > tar files, along with a series of scripts and dependency databases
> > (similar to make-files) that help the package manager identify which
> > dependencies have already been satisfied, which ones need to be
> > satisfied, and how to satisfy them.
> >
> > Sure, some of the files are actually compressed binary executables.
> > More building blocks. Most of the packages however are essentially
> > a combination of simple components combined with some PYTHON, PERL,
> > or TCL scripts along with some BASH scripts.
>
> I'm not talking about the packages.
> I'm talking about the database files used by RPM.
Notice that these are orthagonal. You can dump the database in text
format if you'd like.
--
Rex Ballard - I/T Architect, MIS Director
Linux Advocate, Internet Pioneer
http://www.open4success.com
Linux - 42 million satisfied users worldwide
and growing at over 5%/month! (recalibrated 8/2/00)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Mike Byrns" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Linus says Mindcraft was accurate
Date: Mon, 21 Aug 2000 06:51:22 GMT
"mark" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What Microsoft wanted from those tests was to give the impression
> that NT was 'better'. What was proven was that for the kind of
> scenario tested, it was. Great for all those static HTML providers
> out there with multi-NICed machines running NT with etc. etc. etc.
>
> Linux will continue to be improved - if some improvement is at the
> direct result of Microsoft paying - well fine. How was NT improved
> as a result of those tests?
Windows 2000. Stop squirming, you'll be assimilated eventulally.
------------------------------
From: "Mike Byrns" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 06:56:46 GMT
"ZnU" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <8npc8d$4l2$[EMAIL PROTECTED]>, "Christopher Smith"
> <[EMAIL PROTECTED]> wrote:
>
> > "Courageous" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >
> > > > >The "citizens", as you put it, are buying Windows because there is
no
> > other
> > > > >viable alternative. It is not Microsoft's fault...
> > >
> > >
> > > It is not illegal to be a monopoly. What *is* illegal is to
> > > "monopolize". It *is* Microsoft's fault that they have engaged
> > > in anticompetive practices, specifically forbidden in law.
> > > For that, they have earned a spanking.
> >
> > Which is totally irrelevant to the fact it ain't Microsoft's fault
no-one
> > has come up with a compelling alternative.
>
> Microsoft has taken every action in its power to try to prevent
> alternatives from becoming compelling.
That's called free market. When we return to it with Bush you will see how
relevant losers are.
------------------------------
From: Courageous <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 06:58:21 GMT
> to monopolize. This would include establishing a monopoly, maintaining
> a monopoly, defending a monopoly, and, in essence, keeping a monopoly.
> So I would have to say that 'a monopoly' is illegal. Accept, of course,
> when you didn't do anything...
But doing something, in this case, is called "monopolizing".
Interesting how the words fold in on eachother. But this is
neither here nor there; the law allows for serendipitous
monopoly, and in some cases monopoly by intent; this latter
situation generally evolves when the government itself grants
the monopoly (patent, copyright, natural monopoly, et al).
C//
------------------------------
From: "Mike Byrns" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 07:00:10 GMT
"ZnU" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <8npgjf$ehg$[EMAIL PROTECTED]>, "Christopher Smith"
> <[EMAIL PROTECTED]> wrote:
>
> > "david raoul derbes" <[EMAIL PROTECTED]> wrote in message
> > news:ZtXn5.23$v3.279@uchinews...
> > > In article <8npc8d$4l2$[EMAIL PROTECTED]>, Christopher Smith
> > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > >"Courageous" <[EMAIL PROTECTED]> wrote in message
> > > >news:[EMAIL PROTECTED]...
> > > >>
> > > >> > >The "citizens", as you put it, are buying Windows because
> > > >> > >there is no
> > > >other
> > > >> > >viable alternative. It is not Microsoft's fault...
> > > >>
> > > >>
> > > >> It is not illegal to be a monopoly. What *is* illegal is to
> > > >> "monopolize". It *is* Microsoft's fault that they have engaged
> > > >> in anticompetive practices, specifically forbidden in law. For
> > > >> that, they have earned a spanking.
> > > >
> > > >Which is totally irrelevant to the fact it ain't Microsoft's fault
> > > >no-one has come up with a compelling alternative.
> > >
> > > "Alternative" to what?
> > >
> > > Microsoft is *not* being subjected to the will of the Judge
> > > *because of its operating systems monopoly*. It is perfectly legal
> > > to have a monopoly (as the prior poster said.)
> >
> > So when were Microsoft ruled to have a monopoly ?
>
> Are you serious?
>
> "34. Viewed together, three main facts indicate that Microsoft enjoys
> monopoly power. First, Microsoft's share of the market for
> Intel-compatible PC operating systems is extremely large and stable.
That's their competitors fault.
> Second, Microsoft's dominant market share is protected by a high barrier
> to entry.
Because people LIKE Windows.
> Third, and largely as a result of that barrier, Microsoft's
> customers lack a commercially viable alternative to Windows."
Mac and Linux. It's up to them to make it viable.
<snipin yer piffle at yer request>
------------------------------
From: T. Max Devlin <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Richard Stallman's Politics (was: Linux is awesome!
Date: Mon, 21 Aug 2000 03:01:21 -0400
Reply-To: [EMAIL PROTECTED]
Said Lee Hollaar in comp.os.linux.advocacy;
>In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>>Said Lee Hollaar in comp.os.linux.advocacy;
>>>In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>>>>If you accept the theory that statute models the reality of intellectual
>>>>property ...
>>>
>>>I guess that's my problem. I don't accept that theory. I think that
>>>the copyright statute is the result of a series of compromises between
>>>various interests. (That's one of the reasons why it took twenty years
>>>to draft the Copyright Act of 1976.)
>>
>>The problem is that your theory would require some *compromise* between
>>*various* interests, and it doesn't. Congress accepted the
>>recommendations of a committee made up only of those who have a *fiscal
>>interest* in *producing* copyrighted works, turning their
>>recommendations into statute practically verbatim.
>
>Mad Max clearly makes this stuff up as he goes along. The Copyright Act
>of 1976 was the written by a committee and then Congress just accepted
>it. The Copyright Office in the Library of Congress played a major role
>in its drafting.
According to Jessica Litman, Professor of Law at Wayne State University:
"Sometime around the turn of the century, we here in the United States
reached the collective judgment that copyright was too complicated for
mere mortals (or indeed for mere Senators) to appreciate, and we
settled on an approach whereby we assembled all of the copyright experts
-- that is, the entities whose businesses involved printing, reprinting,
publishing and vending -- and assigned them the task of sorting out the
relationships among them. So, whenever we need a major revision of the
copyright law, it has become traditional to assemble all of the current
stakeholders in informal negotiations, and present whatever they agree
on to Congress. "
http://www.msen.com/~litman/no.htm
>If he is, instead, referring to the CONTU committee which made the
>recommendations that led to Section 117, its chair was former judge and
>it included the author of the leading treatise on copyright law, the
>former Register of Copyrights, an academic librarian, a winner of the
>Pultizer Prize for fiction, the executive director of Consumers Union,
>the excutive director of the American Library Association, the Librarian
>of Congress, the Register of Copyrights, Professor Arthur Miller (of
>PBS fame), the director of a network for libraries, and three people
>from publishers.
>
>Not exactly "a committee made up only of those who have a *fiscal
>interest* in *producing* copyrighted works."
>
>And the recent DMCA amendments were the result of a number of compromises
>between different interests. Every exception can be read as a
>compromise.
Take it up with Professor Litman. I'm not qualified to care.
>>Since 'intellectual property' doesn't *exist* outside of the statutes
>>which provide it protection, we must presume that the statute models the
>>reality of intellectual property, or we must believe the law is wrong.
>>I'm happy with a bit of both as a reasonable alternative to absolutist
>>doctrinism, and luckily the courts agree.
>
>What a bunch of nonsense.
>
>>>But, assume the theory is correct -- that the statute models the reality
>>>of intellectual property. Then how do you explain the substantial
>>>differences in the copyright statute before the 1976 Act and after its
>>>adoption? Was there some change in reality that took place about that
>>>time?
>>
>>Yes; the nature of intellectual property changed, because the laws
>>defining it changed. The changes in reality which prompted this was the
>>development of the technologies which the revised statute addressed
>>which the previous copyright law did not.
>
>So, what technological development prompted the change from a fixed
>copyright term starting at publication to a term running until a number
>of years after the author's death?
Just how obfuscating are you planning on being, here? If you've no
intent to discuss the issues, save your breath, and all of our time.
--
T. Max Devlin
-- Such is my recollection of my reconstruction
of events at the time, as I recall. Consider it.
Research assistance gladly accepted. --
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: tholenbot <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 03:04:04 -0400
In article <[EMAIL PROTECTED]>, Marty <[EMAIL PROTECTED]>
wrote:
> Eric Bennett wrote:
>
> > What polls?
> >
> > I've only seen two polls that can actually be considered reliable;
>
> Perhaps you are forgetting about the KOTM polls. ;-)
Aren't you certain?
--
On what basis do you ask me to listen to your "story about a man named Jed"?
------------------------------
From: Courageous <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 07:04:41 GMT
> > Microsoft has taken every action in its power to try to prevent
> > alternatives from becoming compelling.
>
> That's called free market.
In a perfectly free market, a competitor could decide that you
may have a winning technology, loss lead their competing product
for years, and create other effectively insurmountable barriers
to entry against you, driving you out of business. They might
even buy your intellectual property rights from you at bargain
basement prices after your business has utterly crumbled, simply
because they decided to do it: make your business crumble, that is.
But this is neither here nor there. We, The People of The
United States of America, being sensible folks, decided that
this was a bad idea. Proceed to a Freshman economics class
near you.
C//
------------------------------
From: Courageous <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy,comp.sys.mac.advocacy
Subject: Re: Would a M$ Voluntary Split Save It?
Date: Mon, 21 Aug 2000 07:06:58 GMT
> > > So when were Microsoft ruled to have a monopoly ?
> >
> > Are you serious?
> >
> > "34. Viewed together, three main facts indicate that Microsoft enjoys
> > monopoly power. First, Microsoft's share of the market for
> > Intel-compatible PC operating systems is extremely large and stable.
>
> That's their competitors fault.
This is a dodge. Even if we were to allow you a generous
argumentative leeway of taking your statement at face
value (to wit: "that's their competitors fault"), this
particular retort of yours dances around the point:
Microsoft is a monopoly.
C//
------------------------------
** 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
******************************
