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

8 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. The difference is... by mrogers · · Score: 5, Funny

    You can't buy SVR4 bumper stickers.

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

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

  5. 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?
  6. 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

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