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

Comments

Off the top of my head, here you go

[Anonymous Coward]

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

Reasons to use threads on uniprocessor x86

[pslam]

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.