How to Kill PC Magazine (Linux)
Posted Feb 25, 2005 6:22 UTC (Fri) by
zblaxell (subscriber, #26385)
Parent article:
How to Kill Linux (PC Magazine)
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.
(
Log in to post comments)
