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
First, here's the original "Overview" of the report (the full report is stupidly expensive). Basically what they do (DH Brown) is compare on a feature for feature basis on shipping systems. If we go on this basis, RH5.2 lacks many commercial OS features, such as Journalling, high end SMP, Transaction services, Corba/COM integration, etc that these more expensive OS's offer. The msnbc overview glossed over the report quite a bit - the report actually stated that Linux is good for a lot of things, such as web services, even for high end systems provided you have a very close fit - that's what Linux is good for.
There are issues with Linux, like shipping security out of the US that commercial OS's can get around with licences from the govt. That's a big problem for Linux - you can't just download, or buy for 2 bucks, a SSL enabled Web and News server. You can't even get it for $3000. Not that it's hard to setup mind - I've done it myself - configuring Apache for SSLeay was quite easy, but that's not what DH Brown measures - and it's not something that can easily be measured (unfortunately, for the free s/w croud).
There are some serious shortcomings in the report though. Such as looking at 2.0, not 2.2 (hence why Linux appears to fall down in comparisons of SMP, large file support, Max memory support - 2GB in 2.0). The section on SMP testing simply has a big blank space for the performance of Linux - which makes it look like it comes last at first sight. I wouldn't mind betting it's better than NT with a 2.2 kernel.
Unfortunately there's also the issue that the report just discusses the features that go into NT (and the others) that provide high reliability, such as HA clustering (which is shite on NT), resource management (also shite on NT) etc. They don't actually take into account how stable the system is in every day use. If they did, NT would come last.
I'm not sure about how Linux is worse off than commercial Unixes vis-a-vis internet services. Can someone clear up what AIX and Tru64 offer over Linux in terms of IP protocols/tools, TCP/IP extensions, bundled web browsers/servers, bundled email servers and e-commerce tools. Perhaps it's just that very last one, which comes down to issues about SSL again... Sigh.
Other than those things, I'm not quite sure how they have Linux so far down the scale. I'm inclined to believe they just got it plain wrong. What am I missing?
Matt.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
When they're talking about logging, they are most likely talking about Audit logs.
Who opened a file, who ran a program, who wrote to a file, when this occured, etc.
This is a pretty critical piece for many businesses in terms of security policy, etc.
Having a journaling filesystem available such as Veritas is also important, which is what some others assumed was being talked about.
I'm rather amazed at the number of comments calling this FUD when nobody seems to be quite sure what is being talked about. Of course this lack of understanding appears to have been encouraged by the initial poster.
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
It's true that Linux doesn't scale like Solaris on the Big Iron to 128+ processors. On the other hand, neither does NT, and NT was ranked in front of Linux. I know that VA research demoed an 8 CPU Xeon system at Linux Expo, and I've heard about someone running linux on a 12 CPU Sun system. Can NT even do that? Why on earth would NT be grouped with the Big Iron OSes like Solaris, Irix, Aix, etc?
As for the journaling file system, I think that that's on its way, though I don't know for sure.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
As far as journaling file systems, it's my understnading that that's on its way, but it definitely isn't here yet.
:-) I know that I don't have the year 2038 problem, nor do I have the 2(4?)Gig RAM limit on my Alpha.
As far as SMP systems, ask VA research how their 8-CPU Xeon system runs. Care to comment, Chris?
As for terabyte files, try an Alpha, or any other 64-bit platform. I'm fairly sure that my Alpha could do terrabyte files, if I only had the hard drive for it...
Now, can NT do 6-8 CPUs worth a damn? I'm fairly certain that NT can't do 64+ CPUs worth anything. And does it have a journaling file system worth mentioning? I've never really dealt with journaling file systems. Does anyone know (btw, worth a damn/worth mentioning means on the same sort of caliber as Solaris/Irix/Aix/etc. can do it)?
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I would be reasonably comfortable in saying that slashdot is a biased source of information too
Slashdot does not pretend to be a journalistic site that provides impartial reporting. The opinions you see on slashdot are very obviously those of individuals. MSNBC purports to provide unbiased information. That is the distinction. If a Time/Warner media outlet is biased towards Windows NT, we might be able to effect a change in that, but if an MS-owned media outlet is biased, there is little likelihood of change.
Since most people who administer commercial Unix boxen don't enable them, many people don't even realize that some systems have rather verbose extensive logging mechanisms. The best that is out there is the Sun Basic Security Module (BSM) audit facility. It'll generate lots of logs and sure it takes a fair bit of resources not to mention disk space, but it allows you to run fairly sophisticated host-based intrusion detection systems and very good post-mortems!
Because of Linux's open nature, it would be very useful to have a verbose audit trail mechanism. This would allow security researchers like myself to base new systems on Linux more easily. (and yes, it would most likely end up being GPL'd!)
A journaling file system would be super neato as well. From a security standpoint, one could get a much better idea of what an attacker did to the system files even without running tripwire.
In closing, these are somewhat advanced features and there is no reason why they can not be added to Linux. I believe most of the commercial Unices had them added to an existing system as well. Well, Nuff said.
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).