Slashdot Mirror
McVoy Strikes Back
cranos writes "Fast on the heels of his previous article claiming the kernel is at risk of Bad Things over the BitKeeper fuss, Daniel Lyons has released a new article where Larry McVoy attacks the Open Source movement as non-innovative and dependent on the kindness of corporations. The following quote says it all: 'The open source guys can scrape together enough resources to reverse engineer stuff. That's easy. It's way cheaper to reverse engineer something than to create something new. But if the world goes to 100% open source, innovation goes to zero. The open source guys hate it when I say this, but it's true.'"
Here are some of the biggest problems in computing.
This is the fundamental source of buffer overflows and most software crashes. No language since C (other than C++) has worked that way. The Pascal/Modula/Ada family, Java, and all the scripting languages have subscript checking. But C does not. We pay a huge, huge price for this. Most of the instability in software worldwide comes from this one mistake.
Back when transistors were expensive, the cheapest way to build I/O devices was to put them on the same bus as the memory and store directly into their registers. IBM mainframes had "channels" between devices and memory, but minicomputers couldn't afford that. So mainframes had secure I/O, where the device couldn't write all over memory and device drivers couldn't tell the device to do so. But minicomputers did not. In the mainframe world, drivers could be in user space, and unprivileged. In the minicomputer world, drivers were deeply embedded in the operating system. PCs followed the minicomputer approach, because it was cheaper and that mattered back in 1980. Transistor count stopped being an issue years ago, and peripheral controllers are more complex than IBM channels ever were. But the unprotected I/O model stayed, long after it was no longer necessary. Now, hardware designers are so used to the minicomputer model that they design new interfaces, like FireWire, to emulate register-oriented I/O, even though they're really packet networks. So we have drivers in the kernel and thus huge, unreliable, ever-changing kernels.
UNIX traditionally has lousy interprocess communcation. In the original UNIX implementations, the machines were so small that you assumed you were talking to a swapped-out process, so the only mechanisms were pipes (which were really files) and signals (which emulated hardware interrupts). These were terrible constructs. Yet what we have today in UNIX tends to be minor modifications to the pipe/signal model. Sockets are very like pipes, as is System V interprocess communication. Both are unidirectional and stream-oriented. What you want is a subroutine call between processes; what the OS gives you is an I/O operation. You can make one out of the other, but the overhead is high. (Check out any CORBA ORB.) This led to the One Big Program approach to software. It also leads to the temptatation to put too much in the kernel, because calling the kernel works well, while calling another program doesn't. Linux gives in to that temptation far too much.
The open source world can't fix any of these problems, because they require wrenching design-level changes. The Wintel world has at least tried to fix these problems, although their own legacy issues keep them from making much progress.