Slashdot Mirror

← Back to Stories (view on slashdot.org)

Comparing Linux To System VR4

Posted by timothy on 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.'"

16 of 208 comments (clear)

  1. Distribtuion method by niteice · · Score: 5, Funny

    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
  2. Sigh by devphil · · Score: 4, 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...

    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  3. The difference is... by mrogers · · Score: 5, Funny

    You can't buy SVR4 bumper stickers.

  4. Being that this is /. by Anonymous Coward · · Score: 5, Insightful

    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.

  5. L-A-M-E by johnthorensen · · Score: 5, Insightful

    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:

    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 /. comments, not on an actual computing news site.

    -JT

  6. What does this say? by aluser · · Score: 5, Interesting
    There are several paragraphs in the article which, I think, don't actually say anything. Example:
    Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now, for obvious design reasons consequent to an underlying sequential processing assumption, but it shouldn't be impossible. "All" it would take is a complete re-appraisal of everything we know about optimization and related issues in a truly concurrent, shared-everything, multi-threading environment with enough threads.
    Am I completely out of my depth? What does threading have to do with efficient one-pass optimizing compilers? What's his issue with concurrency under linux anyway?
    Or this:
    On the other hand, this variation on the main question also raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial -- meaning that they don't seem to be direct continuations of code evolution up to 2.4 and thus raise the suspicion that the SCO/IBM lawsuit might be having some unexpected design consequences.
    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?
    1. Re:What does this say? by ScrewMaster · · Score: 4, Funny

      Well, doing a little reading between the lines, as it were, I think what he's really saying is "I want to pay off my mortgage early and this is the best way I've found to do it."

      --
      The higher the technology, the sharper that two-edged sword.
  7. The guy's a phony. by kma · · Score: 4, Insightful
    An actual technical comparison between SVR4 and some of its derivatives with Linux would be interesting. However, this guy is utterly incompetent to perform such a comparison. His babblings about the x86 and threads are just word salad. Consider:


    Indeed, I'm starting to believe that threading doesn't have a legitimate role in the Intel (Nasdaq: INTC) x86 hardware environment because the hardware defeats the goal of true concurrency between threads -- and if you can't achieve concurrency, what point is there in threading?


    Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.
  8. I read the FA by thogard · · Score: 4, Informative

    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...

  9. Off the top of my head, here you go by Anonymous Coward · · Score: 5, Informative

    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.

    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. :P

    1. Re:Off the top of my head, here you go by idiotnot · · Score: 4, Insightful

      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.

      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.

  10. The GPL is Linux's hallmark by andrel · · Score: 4, Insightful

    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.

  11. Re:RTFA by Bruce+Perens · · Score: 5, Interesting
    He's not interested in data either. The article's a troll, with almost zero real technical content.

    Bruce

    --
    Bruce Perens.
  12. Reasons to use threads on uniprocessor x86 by pslam · · Score: 5, Informative
    He's obviously quite unqualified to write the article and didn't even bother to ask anyone. A single processor can emulate multiple processors, and this is often a convenient and even efficient programming model. To elaborate:
    • 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.
  13. Re:The difference is... by 0racle · · Score: 4, Funny

    Apples are BSD based not SysV.

    --
    "I use a Mac because I'm just better than you are."
  14. WARNING: BACKGROUND AHEAD by Anonymous Coward · · Score: 4, Interesting
    The author of TFA thinks that SCO has a case. Hopefully, that should alert you all which corner this guy is in. I've tried reasoning with him over e-mail, but:
    • 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:
    • "Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now" - Except TCC.
    • "raises new issues because many of the changes made to process and memory management between the 2.4 and 2.6 Linux kernels look a bit artificial" - Bold claims (and no reference) for someone who claims to be ignorant. But historically, a large fraction of Linux gets re-written between major versions anyway. Compare V2.0 and V2.2 or V2.2 to V2.4. I dare you!
    • "which kernel would better illustrate the implementation ideas? [..] the right answer here is System VR4, mainly because it's almost equally portable but simpler and clearer." - It also performs terribly. An O(1) scheduler will look messier than an O(n) scheduler. Hmm, MINIX is even simpler and clearer still.. Hey, I see where this is going!
    • "Compare Microport's AT&T Unix port [..] in 1992 to CDE running under Linux 2.4 [..] today and there are enormous practical differences, but few conceptual ones." - Maybe because they both stick to the POSIX API? Look at it the other way: Windows XP is conceptually the same as Windows 3.1. You just send messages and handle events, right?
    • "they didn't come from the Minix/SysV foundation." - Aha! Here he is red-handed implying that Linux was "founded" on Minix/SysV. Go read Groklaw you SCO shill.