Slashdot Mirror
Comparing Linux To System VR4
robyannetta writes "Paul Murphy from LinuxInsider.com asks the question
What's the difference between Linux and System VR4? From the article: 'If there's a real bottom line here, the one thing I'm clear on is that I haven't found it yet, but the questions raised have been more interesting that the answers -- so more help would be welcomed.'"
GNU/Linux has a wider variety of software natively written for it
the Linux kernel includes support for more hardware than SVR4
Linux is more popular as a desktop operating system than SVR4.
Another important factor to consider for many users is price, although there are inexpensive and free versions of UNIX.
Linux issues and bugs generally are often fixed extremely fast.
For a more in-depth technical reference, see this good article on the fundamental difference between BSD and UNIX (although BSD is not technically SVR4 it's still a good read).
Well, Linux can be downloaded in a friendly ISO format, but my SVR4 2.1 disks are in some wierd-ass format I can't use with anything except this one german program.
ROMANES EUNT DOMUS
That everyone says "What you said?" when they're asked about VR4.
Lets compare apples to apples, would'ya?
Eureka Science News - automatically updated
It took me three paragraphs before I figured out that the author of the article wasn't talking about an operating system called "VR4".
Whitespace matters, people. "SystemV R4" or "SVR4" or "SysVR4" woulda done just fine...
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
You can't buy SVR4 bumper stickers.
LinuxInsider has on several occasions in the past been a troll site for the SCO/IBM Linux dispute, coming down firmly on the FUD-mongers' side. They are a platform for people like Enderle, DiDio. Ignore, is my advice...
Call me old fashioned, but I like a dump to be as memorable as it is devastating - Bender
I'm sure nobody bothered to actually RTFA.
The article is basically worthless. It's like walking through a classroom about 20 minutes into the lecture, and walking out 15 minutes later.
It starts in the middle, and leads nowhere. Just a bleem of time that, for whatever reason, is, unfortunatley, recorded here for posteriry.
Could this guy TRY to be more disparaging in his tone? Sure, he tries to give a little back with a comment regarding the quality of Linux code, but for those that haven't RTFA, here's the gist:
/. comments, not on an actual computing news site.
1) Linux runs on a 'toy' platform (x86), and why the hell would a programmer want threads when there's not TRUE concurrency?
2) Linux does nothing significant that AT&T wasn't doing 10 years ago.
3) Generally speaking, Linux sucks.
IMHO I expect to see this sort of thing about half-way down in a thread of
-JT
Or this: What makes a patch "artificial" ? Whatever that means, how does it imply anything about the sco/ibm lawsuit? Weren't the 2.5 development line split and the major scheduler changes introduced before the lawsuit? Even if not, what would he consider a continuation of the development up to 2.4? In short, can somebody explain to me what this guy is saying?
Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.
They guy never saw the SVR4 code... talk about a mess. AT&T had nice clean code that worked well was efficient but didn't do networking very well at all. So they hopped into bed with Sun who had real good networking stuff from BSD. The result was the two of them spawned SVR4. The read system call in the old unix was short and sweet and fit on a vt100 screen. The new one took pages even when printed out and didn't do anything new. It was a rewrite for the sake of a rewrite.
There are some very clever things in Unix that you don't notice till someone redoes them and turns them into a stinking heap. For example the new Solaris 10 services. It does what init and inetd does but needs a binary config file which it rewrites on boots and when it changes stuff (ala windows registry for unix). Having been way too deep on too many broken systems, I don't like binary files that change that are essential for my os to work. But this is progress...
Here are some obvious differences from someone who's worked on both. These are just some quick things which come to mind, off the top of my head.
:P
1. Streams. ATT's streams was just a mistake. It was a great idea in theory. In practice, it adds too much overhead without enough advantages. Even at Sun, it's recognized among Engineers as a mistake, and it's significant that methods of speeding up the networking stack involve discussions on how to get away from streams.
2. The VM. Linux's VM in 2.6 is vastly superiour to stock ATT VM. And it's probably better than Sun's, in the 2.6 Kernel (NOT before 2.4 however). For example, the VM limitations are one reason why NFS sucks in 2.4 kernels; and even Trond has admitted this.
3. Boot-up code. Grub + Linux rocks. It's the best solution out there. Vastly superious to everything, including Sun's implementation. Of course, Sun is hobbled by that Open Boot nonsense, where you have to type an absolutely absurd amount of stuff to specify a device.
4. kernel debugging. Stock ATT blows here. Sun rules, with Linux becoming a close second. This is with respect to kgdb. Although some new technologies are under development in Linux which are interesting.
5. SMP. Stock ATT blows, but not much has been done lately here. Sun's implementation is superiour to everything, which is why you can support so many processors. Linux is starting to catch up though.
Well, that's just off the top of my head. There are probably other things, but I've got to get back to work.
On the other hand he seems a credible source of insight, being the author of the best seller "The Unix Guide to Defenestration". That my friends is a book I missed, somehow. Here's the beginning of the blurb for the book:
This book explains that most commercial systems work disappoints because the incentives favor exactly the kind of continuous low level failure we usually see. Systems management careers are enhanced by budget growth and staff expansion, both of which are maximized by maintaining a level of non performance that teeters on the edge of catastrophe. Correspondingly, systems budgets and staffing levels, and therefore management careers, are diminished by successful execution of the cost reduction, or cost avoidance, mandates that normally go with the job.
Maybe it's just me...
What can you do with Linux that you couldn't do with SVr4 in 1992? Freely share the source with all your friends and customers without fear of lawsuit and include pre-installed binaries on hardware without paying royalties. GPL licensing is the single most important feature distinguishing Linux from proprietary kernels such as UNIX and other free kernels like the BSDs. The GPL's copyleft provision and the dual-licensing opportunity it creates are why companies like IBM and SGI have contributed subsystems like JFS and XFS to Linux. They wouldn't have shared the same code under a BSD license. Linus has said that choosing the GPL is the best decision he made in the early days.
Bruce
Bruce Perens.
- Sometimes it's cheaper in memory and/or clock cycles to use context switching and multiple stacks than scheduling functions off a single thread. This can be true even if the threads aren't concurrent (e.g coroutines).
- It's often easier to use multiple threads even when not necessary, despite having to deal with mutexes. The amount of state in some protocols can lead to a mess.
- When you need low latency, threads are often the only solution.
- Single threaded apps cannot schedule tasks preemptively. Reason enough right there.
- If you need prioritisation of preemptive tasks. When you do, the kernel is best off doing the scheduling because you might not be the only process with priority needs.
- A thread is just a process without most of the baggage, and you don't see people arguing that processes don't belong on x86.
Then again, mindless use of threads does annoy me. So I'll list some "soft" indicators of when you shouldn't use threads:- When a single threaded app would be substantially faster.
- When you don't need preemption.
- When you're going to be using 8,000 of them. It's at least 4-16KB per thread, and thread switches aren't negligably cheap. Rewrite with poll().
- When you cannot say with certainty that you won't deadlock or race.
- When you don't understand what the previous point means.
- When your hardware/OS/platform has a hideous thread switching cost. Can't think of any reasonable system these days where this is a show stopper.
Leave criticism of OS features to those who are qualified, Murphy. Better still, try asking one of them - there's no shortage.It's a technical comparison between the Solaris and Linux kernels.
irony-on And the unsubtle implications concerning the changes in 2.6 respecting the SCO-IBM fracas are legitimate technical observations. irony-off
The article read like troll-bait to me. A serious journalist could have simply asked developers what the technical differences are and how they are affected by the intended platforms. A serious programmer could have answered his own questions. What class does that leave article's author in - bridge dweller?
------ The only greater hazard to your liberty than n politicians is n+1 politicians.
Is it a troll? I found it too confusing to say. The article is looking for technical differences between linux and SVR4. Consider this quote: "Specifically, what's needed here is the low level programmer view, not of what's out there by way of applications..."
The impression I got was the author was way over his depth writing it, and was largely aware of this. Consider the final conclusion "If there's a real bottom line here, the one thing I'm clear on is that I haven't found it yet". Now, that's either a very good troll or a genuine article.
As for answering the article. Well, the painfully obvious difference is in hardware support. SVR4 is a joke in terms of hardware support compared to linux.
In terms of 'features' like kgdb, ptrace, LVM, NUMA, SMP, well I don't think I even know enough to make an informed comment. I will note that the author's attempts to draw comparisons appear extremely weak to me (particularly WRT threading).
Also, the author also seemed to confuse a number of architectural weaknesses with kernel weaknesses. Run linux on a toy mainframe and it won't have mainframe hardware features. Well, Doh. Run Solaris on personal computer hardware and it won't either. Run linux on mainframe hardware and it will.
So, I consider the article very weak, and not worth the electrons it was distributed on. However, it is a fair enough question to ask. It is just a pity to ask it so badly and then slip in bits like the SCO lawsuit for extra hits.
- He would not respond to my argument that there is BSD code in UNIX.
- He thinks SCO has a case, but their lawyers are doing a bad job of explaining it.
- He thinks IBM's lawyers are in cahoots with Groklaw to make SCO look bad
Just for grins, I will now debunk TFA:Companies like Sun have PR firms that will synthesize buzz if they can't get any legitimate buzz. I'd suspect something like that is afoot, or it's just an ill-informed person biting off more than he can chew.
Bruce
Bruce Perens.