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.
My biggest beef with NT is the filesystem. How can you have a system where when one file is corrupted, say NTFS.SYS or other important file, with a filesystem that you cannot write to from DOS or anywhere, you have to reinstall the entire OS (the repair bit fails many times)?
It's ridiculous how anyone is willing to put their entire company on that OS...
"NO ONE paid for this study."
Heh, it would be funny if no one bought the full study as well. All that work, and no $995 checks to make up for it.
Anyway, no one paid for the study beforehand, but they are in it for the money, obviously.
As to logging: Most free Unixes do a pretty good job of logging, although most commercial Unixes do better. The difference isn't substantial, but it is the kind of stuff you can only do with intimate knowledge of the hardware. As compared to NT, every Unix flavor I've seen blows the pants of NT w.r.t. logging.
AFAIK Linux doesn't have a general system level statistics logging ala Performance CoPilot. This makes Linux a little more difficult to determine exactly where the bottleneck is on a loaded system. (Is my system slow because I'm out of System Time, or am I always waiting for disk I/O, or maybe the PCI bus is jammed up?)
As to your aside: most big systems spend a very small fraction of their time with all of the resource management tasks, and these tasks are necessary when you have to determine what to add to a system. It is extremely difficult to determine where the bottleneck is in a system when you don't have statistical information on every subsystem over a period of time, especially when the bottleneck isn't something obvious like memory or CPU time, but something more fundimental like contention on your SCSI busses or memory bandwidth issues.
I read the internet for the articles.
Posted by patg:
Has anyone refuted them? Is there any way to publicly show them to be in error?
This falls into the disinformation category. This is about the most uninformed article yet.
Posted by Nino the Mind Boggler:
"This article is automatically bad just because it's posted on MSNBC."
C'mon folks. We have to do better than that. I don't know the details on what Linux is and is not capable of, so I need some assistance sorting out the FUD from the valid criticism. What is Linux capable of as far as SMP and logging? What are Linus, AC, et al working on in those areas?
UltraLinux is known to run on a 16-processor UltraSPARC box (an Enterprise 450 IIRC) and that same version of our beloved OS will theoretically run on a 64-processor E10K, though AFAIK nobody has actually done so - they're rather hard to come by. Such a machine certainly constitutes Big Iron, though, and I'd love to see the results, whatever they show, of Linux vs. Solaris on such a box, or Linux-E10K vs almost any mainframe solution.
Still, since all hardware supported by NT is also supported by Linux, to rank NT ahead is ridiculous. It would be nice to know exactly how DH Brown arrived at its rankings for "general business computing." Size of monetary contributions to the DH Brown slush fund? Cost of the OS? Survey of PHB's? Engineers? Users? Or did they run real, objective tests in the field or in a lab? And even if the latter is true, what tests were run and how? The article does not even attempt to inform us what the DH Brown report was attempting to assess, much less disclose any real information. There are cases where Linux may lose, especially on Intel; that's fine. But any report that ranks NT ahead of Linux has a pretty bad odor about it, regardless of whether we are considering Big Iron.
go to www.infoworld.com and read their take on the D.H. Brown study. They focused on commercial unicies. NT was included for balance.
-Stu
I'm very glad to hear this. I think this was my point.. we need to counteract FUD by "just doing it" - creating the features the market thinks it needs.
Of course, this is for Linux 2.3... and it will be a long... long.. time before it is "produciton quality" and released in Linux 2.4/3.0 (12-18 months?) So my observations [about Linux not competing with high-end unicies] were very valid for the time being.
-Stu
- 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.
Pure and simple. But the problem is, it's really going to affect Linux's perception in a lot of many very influential minds. Does the gray lady have an agenda here? I remember when Steve Jobs was starting up NeXT, and the WSJ bashed the endeavour really badly. It essentially shot down NeXT's enterprise market for a long, long time, until he dropped the hardware. Some of the facts here could be contradicted by basic fact-checking of the kind normally done by the editorial team in a paper like the Journal - that is, the author writes the article, submits it, and the editors will do fact-checking. It looks like this article wasn't fact-checked. I wonder why. -p
--
The real Paul Vallee is slashdot userid 2192, and, what do you mean it's not cool to point out your low userid?
NTFS does do some journaling, but I believe it's of a limited level. It is not the same as Veritas or JFS, etc.
For instance, if an NT(well or a standard Unix) partition of say 500 Gigs or larger were to go down hard. When the machine came back up, to run a full fsck on it would take several hours... You'd be down for the better part of a day or two.
But with Veritas, it can recover quite quickly without having to do a full integrity check on the filesystem, and your back up and running in only a handful of minutes.
As far as your other comment...
NTFS also allows you to extend a logical partition with additional space from another physical partition.
NTFS has some journaling, but I think it may only be of the metadata. Windows 2000 is going to include functionality from Veritas, and may result in a full journaling filesystem. I'm not clear on that part.
When the article discusses SMP, they're talking about larger scale than say 4 processors. More like 32 or so. Obviously IBM leads the way with this, with Sun close behind.
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.
Linux does run on 2 or 4 processors. That's basically the limit based on presently available motherboard technology. What Linux doesn't do is scale like say AIX or IRIX does, where you can run on dozens, hundreds or thousands of processors. I think this will be partially addressed in the coming months as the big iron vendors start adopting Linux as part of their road map. They will have to modify the kernel to work on a switch based architecture rather than a bus based architecture, which will take some time.
Again this is partially true. The contents of
I think if the Linux community decides they want to address these concerns then it will take much less time. Linux moves fast on things the community wants.
I would have to think this is true, though it didn't have anything to do with the scalability or logging concerns. NT has application support which at the moment Linux lacks. I think the ranking conclusion was misleadingly tied in with the above statements. It may or may not have been done on purpose.
Anyway, somebody should post a response (a well written response, not "you're all morons and will be the first up against the wall when the revolution comes!") that does a fair disection of the article.
Journaling is frequently provided by high-end database programs, which grab an entire partition at a time and write to it however they see fit.
Providing it at the filesystem level helps ensure reliability of all data, not just data stored in high-end databases.
I recall someone was working on a journaling filesystem for Linux - a French graduate student, if memory serves - but I can't find the webpage anymore. Last I checked was a few months ago and it was still pre-beta.
Jamie McCarthy
Jamie McCarthy
jamie.mccarthy.vg
Solaris is designed to run on up to 64 processors (an E10000 Starfire), each of up to 400MHz. It's only really IRIX and Cray stuff that goes over 64 processors, although you could argue that Beowulf can go that high, but that's clustering, not SMP.
Journaling would be good, as it would dramatically improve the reliability of linux under system crashes (rare under linux) or other hardware failures (isn't a lot you can do if the power supply dies). Bear in mind, however, that Solaris has only just put this in by default; before you had to pay for things like Solstice disk suite to get a journaling filesystem, so linux doesn't lag that far behind.
--
The consensus was that the article was talking about "many" processors meaning more than two or four... does Linux run on 128 processors?
In terms of "logging" people felt that this was referring to a journaling filesystem. Granted, I don't know what this means. :-)
I'll admit, though, that the way it's written, it certainly does look a bit like FUD.
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
NT can act as a router, but is not so by default. Setup is simlar to unix, with a ROUTE command. (Or MS has a no cost routing add-on with a GUI.)
NT does broadcast all the time, which seems to be a characteristic of the NetBIOS-over-TCP/IP protocol. Is OS/2 or Samba any better in this regard? Need to find someone with a network monitor to check
--
Business. Numbers. Money. People. Computer World.
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
-----Original Message-----
From: dhbrown.com
Sent: Tuesday, April 06, 1999 1:02 PM
To: tcooper
Subject: Re: Feedback
Tom,
The report carefully defines its terms and conclusions,
summarized briefly in a free summary on our website at
www.dhbrown.com.
The news report you cited is indeed somewhat inaccurate
(it is a paraphrase rather than a quote). Linux
does "run simultaneously on many processors" if
many equals, say 4 to 14. Our report however does
also look at systems that have proven performance in
both production and industry-standard benchmarks up
to 64-way SMP. Linux has not yet reached that level.
In fact, we were mildly shocked that, despite reading
various kernel lists and talking to various Linux
vendors, there is currently no really good publicly
verifyable benchmark evidence of Linux's scalability
even on 2-way or 4-way workloads (although I would be
surprised if we didn't see some in 6 months). It boots
on a 14-way as David Miller demonstrates, but the
scalability claims are still a little in the air.
I wouldn't make a claim that Linux doesn't scale.
I would make the claim that Linux advocates have yet
to reasonably demonstrate that it does.
"Keeping a log" is a similar over-simplification. I believe
the reference was to "event management" facilities just
now becoming available in UNIX where all the system
logs can be accessed from a single console in a consistent
manner. Managing various logs in UNIX has long been
more painful than it needs to be.
Thanks for your respectful feedback.
Regards,
Greg Weiss
Research Analyst, Systems Software
D.H. Brown Associates
tcooper on 04/06/99 11:41:00 AM
To: DHBA Systemsw/DHBA
cc: tom_cooper@bigfoot.com
Subject: Feedback
According to http://www.msnbc.com/news/256197.asp Your study claims
that
"Linux currently lacks some of the features demanded by corporations
that intend to run their entire business on computers. 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."
What sources can you cite for this assertion? Linux is multi-processor
scalable, and does provide logs that are at least as detailed as
anything that you can retrieve from an NT box.
Respectfully,
Tom Cooper
But Herr Heisenberg, how does the electron know when I'm looking?
Well, Linus has said that he doesn't plan on making Linux scale above 16 processors, because after that you're hurting people who only have one.
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).
The following are from an email from Greg Weiss (grweiss@dhbrown.com) :
The news report you cited is indeed somewhat inaccurate (it is a paraphrase rather than a quote). Linux does "run simultaneously on many processors" if many equals, say 4 to 14. (me: but they are also looking at up to 64 SMP, and linux hasn't reached that level)
In fact, we were mildly shocked that, despite reading various kernel lists and talking to various Linux vendors, there is currently no really good publicly verifyable benchmark evidence of Linux's scalability even on 2-way or 4-way workloads (although I would be surprised if we didn't see some in 6 months)
I wouldn't make a claim that Linux doesn't scale. I would make the claim that Linux advocates have yet to reasonably demonstrate that it does.
"Keeping a log" is a similar over-simplification. I believe the reference was to "event management" facilities
So, If you have Linux running on a SMP system, PLEASE mail Greg Weiss (grweiss@dhbrown.com) and tell him!
[I've based this post on the PDF document someone, I've forgotten who, kindly posted on this board - not on the whole report. I don't have $995 to spare, funnily enough.]
;)
Considering the amount of hype Linux has received in the past few months, it is only to be expected that a report such as this would be forthcoming. I think it is important to bear in mind that while the report does not truly compare like for like, it is probably necessary that a report such as this _is_ produced before the general populace start expecting too much of the Linux community, and when they are disappointed, turn away from you never to return.
The report does bring to light a number of reasons why I and other other sysadmins I know have generally steered clear of Linux in favour of *BSD and commercial UNIX systems - and, when the occasion has demanded it, Windows NT. I know this may seem like blasphemy to many readers, but corporate necessity wins over any prejudices or principles.
Pricing: I don't think anyone will argue about this. Linux is, in fact, cheaper than all the others.
Scalability: Linux is not as scalable as operating systems such as Solaris and HP/UX because it was never designed to be so. It was originally designed for an x86 platform, and has only relatively recently emerged as a contender in the mid-range server market. Thus it is to be expected that it is perhaps not quite as scalable as its commercially-available counterparts. I doubt that anyone would seriously care to dispute this.
Reliability, availability, serviceability: I believe the same holds to be true. Linux was originally designed as a home hacker's system, not as a mission-critical server platform. While great strides have been made in this area as Intel and other x86 systems have become bigger and better - and thus thrust the PC into the low-end server arena - there is still a long way to go. Beowulf (not investigated in the report) is to my knowledge the only Linux clustering solution currently available. SMP resource management is still rather limited.
Here the report admits to a lack of hard evidence about system stability, at least in terms of mean time between system failures. To quote the report verbatim, "anecdotal evidence abounds." (I've heard of Linux systems whose uptime has exceeded a year, though in my rather limited experience with Linux I have yet to witness this. I've seen uptimes of about six months with FreeBSD, and a maximum of about three weeks under Windows NT. The HP9000 I'm logged into only has a current uptime of four days, but since it's a development machine that doesn't mean a lot.)
Internet functions: the only gripe here is about availability of good commercial e-commerce applications for Linux - something of which the readership here is only too aware, I hope!
Distributed Enterprise Services: likewise.
System Management: The report has quite a few good things to say about linuxconf, and does list a number of shortcomings in the system management tools of alternative OSes, so I don't see a problem here.
PC Client Support: Samba gets a mention (which is good), but again the gripe here is lack of good commercial software for Linux.
So, in short, the report doesn't really slag off Linux all that badly. The general tone of the report, if you ask me, seems to be that Linux is getting there but for any serious large-scale server applications, it is an idea whose time has not yet come. And I for one am inclined to agree. It doesn't yet have the scalability and resilience of those operating systems designed for high-end servers (notwithstanding the operating system itself may be more stable -- but what good is a stable OS if your data is lost on the day when it _does_ crash?) and it doesn't yet have the commercial software to make a good system a great system.
So, in short, I don't believe the report is saying that Linux is a bad system. It's also not telling us anything new. It _is_ a viable system, for the low-end server market; and it's a damn sight cheaper than anything else out there. The WSJ editorialized it to death. The report itself is quite reasonable.
"If it's a bad idea, trash it. If it's a good idea, steal it and release the source code."
--
"This isn't the post you're looking for. Move along."