How to Kill Linux (PC Magazine)

Posted Feb 23, 2005 16:52 UTC (Wed) by vblum (guest, #1151) [Link]

Is it correct that Microsoft "sued, the bought off the Lindows folks" ? [quote from the article]

Posted Feb 23, 2005 17:29 UTC (Wed) by stevenj (subscriber, #421) [Link]

That means tearing away the entire top of Linux from the driver layer—and that would be MS-Linux.

No, I believe that would be called "Cygwin."

Posted Feb 23, 2005 17:44 UTC (Wed) by dmarti (subscriber, #11625) [Link]

This plan doesn't actually require MSFT to do anything -- anyone can put together an easy-to-install Xen/Linux distribution that runs on top of a low-priced Microsoft OS product.

Posted Feb 23, 2005 18:09 UTC (Wed) by clugstj (subscriber, #4020) [Link]

There are so many logic lapses in this article that I don't know where to begin. Suffice to say that this scenario will not play out and this guy is CLUELESS (as many of his past articles have demonstrated.)

Posted Feb 23, 2005 18:10 UTC (Wed) by danielpf (subscriber, #4723) [Link]

Next time just ignore Dvorak please. This article is a waste of time.

Posted Feb 23, 2005 19:43 UTC (Wed) by hathawsh (subscriber, #11289) [Link]

Microsoft has worked for years on building a solid kernel and core libraries. Whether Linux is technically superior or not, can anyone really expect Microsoft to give up their own kernel? Microsoft has smart developers; if the Linux kernel has some advantage, there's no reason Microsoft developers wouldn't copy the idea (using different code) and catch up.

It's more likely that Microsoft will create a syscall emulation layer that allows Linux-oriented binaries to run inside Windows. The emulation layer might be stable enough to sway desktop Linux users back to Windows. It wouldn't sway me, but it would probably sway people who don't tinker with code all day.

Posted Feb 24, 2005 0:07 UTC (Thu) by petegn (guest, #847) [Link]

Does he not actually mean "Plug and Pray" (which seems to be the norm) not "plug and play" which would be the Exception.

Pete ,.

Posted Feb 25, 2005 6:22 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

When I read this article, I think he's talking about running Linux under
something like VMware.

It's already possible to run Linux "as a task under Windows" using VMware.
Linux thinks it's running on a specific set of hardware, but VMware
rewrites the code on the fly so that e.g. what used to be I/O commands to
a Buslogic SCSI controller turn into read requests on a virtual disk image
file.

Microsoft already has a virtual machine emulator as one of the standard
products you can order from wherever it is that you order huge amounts of
Microsoft software. It's used to make all those mission-critical Windows
3.11 applications run on modern 3200MHz SMP processors with USB and PCI
instead of a 16 MHz 386 processor with PS/2 and ISA. I'd be surprised if
MS couldn't make Linux work under that emulator as well, since a Windows
3.11 runtime environment is fairly close to the bare metal, and the basic
techniques to do machine emulation would work with any OS as host and
guest--all the specialisation is done to improve performance after the
basic code translator is working.

Dvorak then suggests that what users really want is something not like
VMware but more like User Mode Linux running as a Windows process. This
is certainly technically feasible as well. These are not all of the ways
to get Linux applications running on top of another OS. It's not clear
that any of these approaches is a winner in all cases--there are subtle
trade-offs among performance, functionality, and compatibility between the
various approaches.

A UML on Windows would be just another multithreaded Windows application
that called on the usual Windows APIs to access devices. The Linux
"drivers" would just be translation layers. From the Linux side, it would
look like a UML kernel does--almost, but not quite, like Linux. A virtual
machine emulator on Windows running Linux would look more like Linux
internally, but would look more like having a smaller computer trapped
inside a larger one externally.

MS could make any modifications they like to make Linux run inside a
Windows process and put them under the GPL--the only people who would care
about having that source code would already be Microsoft licensees. The
GPL conveniently excludes proprietary libraries that already ship with the
target operating system, and it's difficult to argue that calling a
Windows API call is in some legal way different from passing a few bits of
data in a register to a device controller running proprietary firmware.
The Sony Playstation port of Linux, mkLinux and the GNU Hurd all use
"device drivers" that really drive a software abstraction layer, and in
some of those cases that layer is also an intellectual property ownership
boundary.

"Users who needed to add the driver layers" would just rebuild the Linux
kernel with drivers for real devices instead of Windows API calls. The
"utility program" that would "sew the drivers back into Linux" I believe
is known to the rest of us as "make". Presumably there would be a reboot
required to make the final transition.

Users who pay for the Windows drivers would get a stripped version of
Windows with nothing but the Linux runtime support. Dvorak describes this
as "pay[ing] for the Windows drivers and attach[ing] those to Linux", but
the reality is the other way around (it must be, otherwise TC-style DRM
wouldn't work). To the uninformed user the results look the same either
way.

"the PnP benefits of Windows" is probably a typo...it should have read
"the millions of dollars of hand-holding that mainstream computer vendors
and consumers pour onto Windows from their own pockets."

Hosting non-trivial Windows drivers on Linux is out of the question. In
general Windows drivers have significant parts of their device drivers
embedded in device-specific application code. The best an OS could
provide is low-level data transport. This means you'll need to use
Windows userspace to run the application that talks to your fancy
hardware, even if Linux has a working device driver for the USB controller
or I2C bus it is connected to. Most of the trivial device drivers already
work on Linux.

Towards the end of the article Dvorak has basically lost his mind. Here
are some of the more absurd premises:

* Most Linux users are really Windows users who are forced against their
will to use Linux because of some application or other that only runs on
Linux.

* Developers will stop working on Linux because Microsoft will some day
make money from it. This will occur suddenly--Linux will "die."

* Microsoft will become dominant in the Linux market, then begin making a
profit from it. Presumably in that order.

* Microsoft would do the world a favor by joining the Linux community.
Dvorak put the word "joining" in quotation marks--I find the premise just
as absurd without. ;-)

* Users will never doubt Microsoft's good intentions, or compare the
Microsoft EULA with the GPL (at least, not until it's too late).

One thing that could arise from these premises is that MS "renegotiates"
with hardware vendors so that machines are sold as "no-OS" machines will
actually have preloaded on them a minimal Windows-based virtual machine
(with license fee paid to MS by the vendor) ready to run Linux. This does
satisfy many of Dvorak's premises:

* MS is already dominant and making a profit in the preinstalled OS market

* users might not notice the EULA if the installation is done at the
factory and the runtime environment is transparent enough

* there would be fewer developers writing device drivers for Linux than
there would be otherwise. This doesn't necessarily mean fewer developers
in absolute terms, but we can expect a few dozen developers who would
otherwise have written a Linux driver for their own use to be satisfied
with using the one that was supplied for Windows, and a few dozen vendors
may decide not to write their own Linux drivers. The growth rate will be
nominally lower in the short term, but there would still be thousands upon
thousands of developers.

* it might be slightly more convenient to install Linux on top of the
virtualization layer, which casual users will probably like.

This would be a huge undertaking for MS (similar in scope to providing the
BIOS software for PC's, but with fewer opportunities for monopoly
lock-in). MS has boldly declared in the past that they "are not in the
BIOS business", and I don't really see how MS gets enough out of the deal
to bother initiating it.

On the other hand, I do see how MS might be forced into tactics like these
to survive or to further its larger goals.

If there is a significant consumer drift away from the Windows OS family,
hardware vendors may consider drivers for the latest Linux to be as
important to customers as the drivers for the latest Windows. When that
happens there will be a giant hole in the Microsoft OS business model, and
with the way things are going for MS these days, it could be a hole that
MS will never be able to repair. Speaking of giant holes...

Another thing to consider is the Trusted Computing initiative, which MS
desparately wants to sell, but no informed consumer wants to buy. The
most transparent way to make TC usable by Linux users would be to run the
entire Linux kernel under a TC microkernel. The microkernel would provide
codecs, decryption, audio and video devices, and remote monitoring by
Microsoft, while the Linux media player running above the microkernel
would do the necessary data plumbing but never actually have access to the
cleartext of the data moving between the DVD drive and the video screen.
The pro is that you can play DVD's by typing
'cat /dev/dvd>/dev/big-screen-tv', and the con is that command might cost
you $1.50 to run, or might give I/O errors the fourth time it is run.

Posted Feb 25, 2005 16:33 UTC (Fri) by forthy (guest, #1525) [Link]

The last c't (4/2005) had a nice project: IPCop running in UML Linux
within Windows as firewall and small server (complete Debian-based CD with
the magazine). Unlike the "secret project" Dvorak is rambling about, this
is for real. And it's actually something useful for Windows home users:
They don't need a separate firewall, and they can trust this firewall more
than a "personal firewall" within Windows. It gets PPPoE packets from the
DSL side, and returns scanned packets to Windows.

This sort of "several OSes in one box" is inevitable. Intel and AMD are
about to integrate virtualization support in their CPUs. IBM already did,
and with the Cell, even Sony's Playstation will have that feature. With
all the legacy and the untrustworthy platforms (especially Windows), this
has a market. Once you have a VM monitor (like Xen), you can start and
stop (and freeze) different OSes on your PC as if they were user-level
applications.

This won't kill Linux. It won't kill Windows, either (if you don't have to
do a hard transition, you can keep using it).

Posted Mar 3, 2005 13:11 UTC (Thu) by scharkalvin (guest, #7372) [Link]

The only lopped off head is Dvorak, who seems to be talking out
of his butt in this article.