Slashdot Mirror
WSJ Says Linux Lags
TroyD sent us a link to
a
WSJ Article on Linux
that Says Linux is Good, but that it lags behind its rivals.
Troy also sent a choice quote from the article:
"...Linux currently lacks some of the features
demanded by corporations. [...] Among them are the
ability to run
simultaneously on many processors in a single computer and
to keep a log of what the computer has done."
Cool. I can save a lot of diskspace: rm -rf /var/log.
The underlying study is actually a very responsible view of how Linux stacks up against the highest-end commercial OSs. It says that the main shortcomings of Linux are that it lacks proven SMP ability (we're talking 6 or 8 processors here), file system journaling (which is what the clueless WSJ meant when it talked about "keeping a log of what the system has done"), and very-large file support (like, on the TB scale). The big problem with SMP, apparently, is that it takes years of working hand-in-glove with the hardware mfgr to get a properly tuned SMP system. Probably correct.
While the study ranked NT at about the same level as Linux, it expressly did not consider stability. The study said that stability evidence was almost entirely anecdotal, and there were no real MTBF studies to review.
- You can't run a 64-processor SMP box on Linux.
- You can't get a government B1 security rating on Linux (You can on "Trusted Solaris" or on AIX)
- Inclusive with the above, we need a journaled filesystem
- You can't get highly-available failover clusters with Linux. [though the linux-HA project is working on it]
- You can't get single-system-image clusters for scalability with Linux (Beowulf uses a low-level messaging API that essentially ties your app to Linux)
- You can't have terabyte files for large databases [that means no data warehouses]
- You can't have > 100,000 users on a Linux box for very large networks [Solaris & AIX can]
etc.
By now you're all probably hopping mad at me, but please folks: take a deep breath. Is this really FUD? Or is it merely pointing out some small nitpicks? My, my... people are so quick to criticize and yet so hyper-sensitive to their own medicine.
Let's get real: we're only talking some minimal feature-lack, and not very "widely used" features at that. Wanna fix it? Contribute code. This is how Linux makes FUD irrelevant - not through whining about the WSJ's misleading prose.
The underlying study by D.H. Brown is rooted in fact, and it means one thing: we now have specific target areas that Linux "could" be improved, provided someone with the time+need will contribute.
-Stu
Actually, mainframe CPUs themselves are not that much more overwhelmingly powerful then desktop CPUs. The mainframe benefits mainly from I/O channels, block mode devices (including terminals), and better scheduling algorithms.
... as opposed to receiving an interrupt when each block transfer completes.
I/O channels are CPUs dedicated to supervising I/O operations, so that if you need to read in 100 blocks from disk, you build a list of the blocks along with their addresses, and start the channel. The transfer is done, and you receive an interrupt when it is complete
This really pays off when you include block mode terminals, like 3270s. A 3270 contains a screen buffer. When you are working in a text editor like VM XEDIT, everything you type is stored in the terminal until you press return, or a function key. At that point, the terminal transmits a list of all the screen fields that have been changed. If you were running VI on a unix system, you would be peppering the computer with console interrupts with each keystroke. More if you are running X. This is how mainframes can efficiently support 1000+ online terminal users.
Mainframe scheduling algorithms are specifically designed to separate the workload into interactive and non-interactive users. If the scheduler decids that you are an interactive user, you get small timeslices and more of them. When you start your big program, and it goes CPU bound, the scheduler notices that you are using your full timeslice, and quickly moves you into a different queue, so that, for instance, after a while, your program will receive a timeslice that is 16 times as long, but only receive the timeslice 1/16 as often as an interactive user. So your background process lurches along, but you don't notice because the instant it starts doing I/O to the terminal, it becomes an interactive process again.
These sorts of tricks are what keep mainframes from appearing to be "bogged down" even when their resources are massively overcommitted.
These algorithms have been fine tuned for about 30 years, and are specifically designed to best utilize block mode I/O devices, and large numbers of interactive users attached to boring 3270 terminals. It's a VERY different workload then you'd find on a Unix system, and the two workloads don't compare well.
In fact, one of the biggest problems with mainframes is running TCPIP efficiently, because TCPIP *does* pepper the system with interrupts.
- jms
Was that Linux was being compared to Big Iron and found lacking. Linux logging is no worse (and often better) than most commercial Unices, but the only place I've seen absurd levels of multi-processor and system logging are in the "Real Computer" world.
I think the writer's opinion seems somewhat biased (surprise, surprise) but he brings out some reasonable questions: just how far can a single Linux box scale, and for what tasks?
Now we should get out there and improve all the little things that need improvement to help Linux, and *nixes in general, reach these entrenched Heavy Hardware markets.
Complete aside: I believe the reason mainframes need massive CPU power has nothing to do with capacity and everything to do with the tremendous overhead of the monitoring, accounting, tracking, logging, and process/resource management features of most Real OSes (e.g. OS/360).