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

5 of 208 comments (clear)

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

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

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

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