Slashdot Log In
Comparing Linux To System VR4
Posted by
timothy
on Mon Jan 17, 2005 07:14 PM
from the pick-your-perspective dept.
from the pick-your-perspective dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Various differences (Score:3, Informative)
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 [over-yonder.net] on the fundamental difference between BSD and UNIX (although BSD is not technically SVR4 it's still a good read).
Re:Various differences (Score:4, Insightful)
more of the technical aspects, ie like threads and smp and
stuff like that and how its implemented differently. Not
that the qualitative differences aren't of some import too
but I just see that more as the color of the cars vs the
types of engines/trannies.
nice link on bsd philosophy.
Parent
Re:Various differences (Score:2, Insightful)
> # GNU/Linux has a wider variety of software
> natively written for it
There is a huge base of professionally written
and supported apps for SVR4/Solaris/UnixWare/...
The GNU compiler and toolchain, while useable,
perhaps even good, is inferior to the offerings
from Sun, IBM, HP, and the commercial vendors.
The same can be said for nearly, if not every,
category of GNU/Linux/Open-Source software.
Linux may in fact have more "stuff" available
for it but when you weed out the crap, it isn't
t
Re:Various differences (Score:2)
Define "price". Having to wait around for days on end while somebody on the mailing list or web forum decides to answer your question (or some- times not at all)is unacceptable. Sun, HP, and IBM, provide guaranteed response times and they do it well. When your systems are down and costing you $5000 an hour open-source "support" don't cut and ends up costing you a lot more.
What the hell? You don't get enterprise support for free as a result of popping in a Solaris installation disc. Why would you expe
Re:Various differences (Score:3, Insightful)
Here, have a few goats...
Correct, kind of. There are arguably more commercially supported apps for Unix or Solaris than for Linux, and generally speaking, more money is involved. (That is, the apps in question are serious ones that companies rely on; if the software fails, the company goes south.)
Having said that, there are probably more "professionally written" apps for Linux, it's just that most of them a
Re:Various differences (Score:2, Informative)
You are such a fucking loser your monger.
I'll give you a rundown of the categories on that page, in case you are too lazy to read it.
Linux on POWER
Linux on Intel processor-based servers
Linux on AMD processor-based servers
Linux on Mainframe
The Linux s390 and PPC and PPC64 (and even m68k) architecture maintainers all work for IBM. The POWER5 processor had features designed with Linux in mind to better suit its low level memory management system. The IBM Linux guys go do Linux bringup and verific
Re:Various differences (Score:3, Insightful)
The flip side of that is CPU performance doesn't mean squat on a multiprocessor system if the interconnect and memory systems are not up to snuff.
Opteron could "go up to as much SMP" as US provided the glue logic is there.
Are you sure about that?
The high end US chips have provisions for maintaining cache coherency in systems with up to 1023 processors. I don't recall seeing a similar feature in the O
Re:RTFA (Score:5, Interesting)
Bruce
Parent
Re:RTFA (Score:2)
Re:RTFA (Score:3, Informative)
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
Re:RTFA (Score:3, Interesting)
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
Re:RTFA (Score:2)
Maybe, just maybe this isn't part of the great SCO/MS conspiracy and you're just confused cause you don't have half the article cause you don't read the news site it is posted on and you don't follow this author's work?
Re:RTFA (Score:3, Insightful)
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
Distribtuion method (Score:5, Funny)
The difference is... (Score:3, Funny)
Lets compare apples to apples, would'ya?
Re:The difference is... (Score:5, Funny)
Parent
Re:The difference is... (Score:2)
And, on a kernel level, OSX isn't BSD, either. It's mach, which has things like native threading, and its own message-passing facility...separate from what you'd find in a traditional unix kernel. (NetBSD supports Mach IPC now, too, to support Darwin binary emulation)
Re:The difference is... (Score:2)
Sigh (Score:5, Informative)
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...
Re:Sigh (Score:2)
Exactly what I thought. I have been using System V since R2, and SVR4 since it first came out (before Solaris came out even).
I have seen it as : SVR4, System V Release 4, or SysVr4 even ...
But System VR4 ? Never saw it spelled this way, and indicates little familiarity with the subject matter.
The difference is... (Score:5, Funny)
Looks like a troll to me... (Score:3, Interesting)
Re:Looks like a troll to me... (Score:2)
Being that this is /. (Score:5, Insightful)
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.
L-A-M-E (Score:5, Insightful)
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
Re:L-A-M-E (Score:4, Interesting)
I'm surprised that Slashdot gave this latest garbage a front page headline. Hopefully if enough people ignore LinuxInsider it'll go away...
Parent
What does this say? (Score:5, Interesting)
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?
Re:What does this say? (Score:5, Funny)
Parent
bahaha (Score:2)
Re:What does this say? (Score:3, Insightful)
I didn't get that either. I had some (very serious) issues with concurrency in Linux, but they've all been fixed in 2.6/NPTL.
One thing I did like was his comment that the distinction between desktops and servers is mostly one of marketing. I thought that was quite insightful, if not entirely original.
Re:What does this say? (Score:3, Insightful)
The guy's a phony. (Score:5, Insightful)
Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.
Re:The guy's a phony. (Score:4, Funny)
Parent
Re:The guy's a phony. (Score:2)
But yeah, he really didn't re-edit his article to make that blindingly clear.
I read the FA (Score:5, Informative)
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...
Re:I read the FA (Score:4, Informative)
My impression of the SystemV series was that the proprietary status of Unix was in doubt and SystemV was intended to fix that.
Unix was written before the US copyright law was were extended to apply to software, and before the "program as component of patentable invention" hack was invented and debugged. So the only IP protection AT&T had on it was trade secret. Trade secret goes "poof!" when the secret is out, and AT&T had distributed several generations of source and documentation to universities around the world.
(This was also before the breakup of the Bell System, and there was some mandate on them publishing releasing certain telephone-related work as part of their monopoly mandate which, separately, might have imperiled its IP status. I don't recall the details. But it was probably made moot by the court-mandated breakup later.)
Unix had been a back-room project by a team that had been explicitly forbidden, at least initially, from building an OS. (Indeed, one factor driving the kernel's simplicity and the design goal of pushing as much out to the application layer as possible was the creation of plausable deniability: "An OS does X, Y, and Z and this doesn't. So it's not an OS. Right?")
Since they weren't writing something viewed as productizable or proprietary, they were at Bell Labs (where publishing was the usual route for most work), and software in those days wasn't productized anyhow, they felt no need to keep it under their hats.
The broad circulation of source and docs spawned the era of the commodity unix box. A new hardware vendor, rather than writing his own OS, could just port Unix to the box - a matter of hacking a couple thousand lines of hardware-interface code. AT&T would look the other way as long as they weren't selling it. Once they got it working, AT&T would cut a licensing deal on very good terms. (For them it was free money.)
This continued until the University of New South Wales built a course around System 6 (i.e. release 6 of the documentation set, which was how System N was named). They printed a two-volume coursebook - volume 1 being the kernel source pretty-formatted, while volume 2 was a textbook walking you through the guts. This immediately became an underground classic, and finally got onto the administrative radar screen at AT&T. The lawyers "Cease and Desist"ed the University.
The SystemV project, if I recall correctly, started shortly after the CONTU (Committee On New Technological Uses - charged with studying and proposing to Congress whether/how software should receive copyright protection) reported and Congress explicitly extended copyright to cover software. Now that IP protection was available, AT&T got together with several of the big Unix players and together they reimplemented the kernel from scratch, and tried to move everybody to the result.
They gave a number of plausable-sounding reasons for the work - claiming it was a great improvement on the previous stuff. But they didn't include the Berkeley work (especially noticible: no Berkeley Signals) which had its own proprietary issues. The resulting functionality of SystemV was both incompatible with and lower than both BSD and some other System N derivatives. So the general consensus (at least among the people I hung out with at the time) was that the whole exercise was to clean up the IP status of Unix for its future as a product.
Parent
Re:I read the FA (Score:3, Informative)
Ok, from this little statement it is obvi
Off the top of my head, here you go (Score:5, Informative)
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.
Re:Off the top of my head, here you go (Score:3, Interesting)
Re:Off the top of my head, here you go (Score:5, Insightful)
Not. OpenBoot/OpenFirmware are vastly superior to the cheesy i-must-look-like-a-floppy system that crippled pcs have. When grub supports testing hardware, or listing the devices present inside the system over a serial console, let me know. List the scsi busses and the devices present? I've used OpenBoot(sun), OpenFirmware(Apple), the NeXT Rom monitor, as well as the stuff on Alpha and PA-RISC, which I can't remember the names of right now -- they're all much more flexible than grub.
Grub also still doesn't work on all PC hardware. I've never gotten it to work with a Compaq SmartArray card. Never. Several different versions of Grub, several different SmartArrays.
Granted, Grub is a massive improvement over crap like lilo, but it's nowhere near as flexible as what you'd find on a good unix machine.
Parent
Re:Off the top of my head, here you go (Score:2)
However, you can list devices present with tab completion. Type root (hd and you will get a list of all your disks. At least the ones that Grub can see through the PC BIOS calls. *shudder*. God knows how you're supposed to boot off a PCI IDE controller, I sure as hell can't.
Re:Off the top of my head, here you go (Score:3, Informative)
Of course, if I have a dozen network ports, several hard drives with several operating systems, and another dozen CD-ROM and DVD drives, OpenBoot will allow me to easily boot from any of them. Also, I recommend you look up documentation regarding devalias and nvramrc.
OpenBoot is so superior to the PC BIOS that it is the main reason I would hesitate to buy another PC.
Re:Off the top of my head, here you go (Score:3, Informative)
Re:Off the top of my head, here you go (Score:3, Informative)
Still, that literally blows Sun's biggest machine out of the water. Especially in absolute performance, when you consider a new 9MB cache I2 is probably a clear twice the speed of the fastest of sun's sparcs.
Second, Sun's machines are NUMA as well. That's right, they have Non Uni
The difference is easy... and surprisingly simple (Score:2, Insightful)
Euh? (Score:2, Funny)
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 enhanc
In other news today (Score:2)
I mean, no shit, OSs doing similar things, what an insight.
The GPL is Linux's hallmark (Score:5, Insightful)
Reasons to use threads on uniprocessor x86 (Score:5, Informative)
- 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.WARNING: BACKGROUND AHEAD (Score:4, Interesting)
- 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: