Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Unix Sun Microsystems Linux

Comparing Linux To System VR4 208

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

Comparing Linux To System VR4 More

Comparing Linux To System VR4

Comments Filter:

  • Various differences (Score:3, Informative)

    by Lindsay Lohan ( 847467 ) on Monday January 17, 2005 @07:15PM (#11390490) Homepage Journal
    So what's the difference between SVR4 and Linux? At a glance they may look the same because they're both in the Unix family, but they're actually quite different.

    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)

      by Lawrence_Bird ( 67278 ) on Monday January 17, 2005 @07:30PM (#11390620) Homepage
      mmm.. when people ask a question like that I tend to think
      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.

    • It's a technical comparison between the Solaris and Linux kernels. He's not interested in your opinions of which makes a better embedded operating system for a toaster oven.

      • Re:RTFA (Score:5, Interesting)

        by Bruce Perens ( 3872 ) <bruce@perens.com> on Monday January 17, 2005 @08:14PM (#11390955) Homepage Journal
        He's not interested in data either. The article's a troll, with almost zero real technical content.

        Bruce

        • It's a follow on from another article. If you havn't read the other article then it makes no sense to read this article. The only reason why the brain dead Slashdot editors posted it is because the brain dead OSNews.com had it. I'm sure neither Eugenia over at OSNews, nor timothy here on Slashdot read anything more than the title of the article. Not even knowing what VR4 was refering to they posted it.

        • Re:RTFA (Score:3, Informative)

          by lakeland ( 218447 )
          Is it a troll? I found it too confusing to say. The article is looking for technical differences between linux and SVR4. Consider this quote: "Specifically, what's needed here is the low level programmer view, not of what's out there by way of applications..."

          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)

            by Bruce Perens ( 3872 )
            Well, I think it's a troll because he displays very little knowledge of systems programming and confuses CPU features and OS features, and yet takes every opportunity to say something snotty and disparaging.

            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

        • The article's a troll, with almost zero real technical content.

          No surprise here -- LinuxInsider.com is to Linux as MozillaQuest.com is to Mozilla. Move along, move along.

      • Re:RTFA (Score:3, Insightful)

        by j_w_d ( 114171 )
        It's a technical comparison between the Solaris and Linux kernels.

        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

    • Re:Various differences (Score:2, Insightful)

      by Anonymous Coward
      Okay, I call B.S.

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

      • 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

        • His point was that the potential time delays on the listed Linux support mechanisms may be much more expensive to a customer than a support contract.

          This isn't discounting the fact that one can get various levels of paid support for Linux as well.

          • His point was that the potential time delays on the listed Linux support mechanisms may be much more expensive to a customer than a support contract.

            The original poster stated Linux has good free support. The poster didn't come outright and say that SVR4 by contrast has terrible free support, but it's implied.

            The response was that free support doesn't cut it if you're doing something important! Paid support for SVR4 is ENTERPRISE grade, but it's a pointless argument since you can find enterprise grade

            • I wasn't trying to troll, just explain what looked like a misunderstanding. And yeah, comparing free Linux support to enterprise commercial unix support is thoroughly invalid, especially since you can get similar support offerings for Linux.

      • Here, have a few goats...

        There is a huge base of professionally written and supported apps for SVR4/Solaris/UnixWare/...

        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

      • Nice troll. I call BS. Ever try installing Solaris x86 on a PC? Good luck! The only configuration I found laying around that worked with *that* turd was an ol' Pentium Pro i440-based mobo. Solaris x86 - the only PC operating system these days that brings back the joys of hunting for crappy, unsupported or just plain non-existant drivers for your:
        a) Network card. Wow. Just... wow. And this wasn't something arcane either.
        b) Video... well.. "driver" heh. If the Xserver doesn't support it, have fun running CDE

      • > # Linux is more popular as a desktop operating
        > system than SVR4.
        >

        Maybe, but maybe not. People at home and dorm
        geeks dork'ing around don't count. I'll guarantee
        you their are more scientific and engineering
        shops that are using SVR4 based desktops than
        Linux.

        well as a postdoc fellow working in a university computer science department, i can tell you that the amount of linux desktops/workstations clearly outnumbers the amount of workstations running other unices (unixes? - whatever). oh ya, and

  • Distribtuion method (Score:5, Funny)

    by niteice ( 793961 ) <icefragment@gmail.com> on Monday January 17, 2005 @07:18PM (#11390507) Journal
    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.

  • The difference is... (Score:3, Funny)

    by FiReaNGeL ( 312636 ) <.moc.liamtoh. .ta. .l3gnaerif.> on Monday January 17, 2005 @07:20PM (#11390535) Homepage
    That everyone says "What you said?" when they're asked about VR4.

    Lets compare apples to apples, would'ya?

  • Sigh (Score:5, Informative)

    by devphil ( 51341 ) on Monday January 17, 2005 @07:23PM (#11390569) Homepage


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

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

    • I liked VR5. That was a cool series.

      Chris Mattern
      • I liked VR5. That was a cool series.
        Hey, me too - even though it was on late at night - eventually at something like three in the morning - in the UK, and I had to work at 7am, I persisted with it. I was always sure it wasn't as bad as it sounded when you tried to describe it to someone else ;-)
        - Derwen

  • The difference is... (Score:5, Funny)

    by mrogers ( 85392 ) on Monday January 17, 2005 @07:26PM (#11390597)
    You can't buy SVR4 bumper stickers.

  • Looks like a troll to me... (Score:3, Interesting)

    by jpetts ( 208163 ) on Monday January 17, 2005 @07:28PM (#11390609)
    LinuxInsider has on several occasions in the past been a troll site for the SCO/IBM Linux dispute, coming down firmly on the FUD-mongers' side. They are a platform for people like Enderle, DiDio. Ignore, is my advice...

  • Being that this is /. (Score:5, Insightful)

    by Anonymous Coward on Monday January 17, 2005 @07:31PM (#11390633)
    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.

  • L-A-M-E (Score:5, Insightful)

    by johnthorensen ( 539527 ) on Monday January 17, 2005 @07:35PM (#11390666)
    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
    • 1) Linux runs on a 'toy' platform (x86), and why the hell would a programmer want threads when there's not TRUE concurrency?

      It's not that a programmer would not want threads. However, if you want threads to handle truly concurrent events, as opposed to just multiple strongly related processes, the design of the threads will be entirely different. His point was that on an x86 any attempt to design truly concurrent threads is a waste of time b/c of the underlying architecture. Of course Linux runs on more

    • Re:L-A-M-E (Score:4, Interesting)

      by FyRE666 ( 263011 ) * on Monday January 17, 2005 @07:58PM (#11390848) Homepage
      As another comment above noted, "LinuxInsider" is not a computing news site in any real sense of the term. It is in fact little more than a FUD factory. The list of contributors reads like the who's who of Microsoft/SCO paid schills...

      I'm surprised that Slashdot gave this latest garbage a front page headline. Hopefully if enough people ignore LinuxInsider it'll go away...

    • Linux runs on a 'toy' platform (x86)... Linux does nothing significant that AT&T wasn't doing 10 years ago... Generally speaking, Linux sucks.

      As usual, what your eyes see depends on which glasses you have on when the text is in front of them. If you are expecting to find critique, you can always find it.

      Personally, I did not see any form of "Linux sucks" message in the article. He does not write "Linux, Linux, Hallelujah", but lack of worship does not mean that he condemns. The article is, from beg

      • Well, he re-defines what he's asking for at least 3 times. He wants stuff that Solaris can do that Linux can't. No, wait, he wants to know how Linux is different than SVR4. No, he wants to know which one is better for teaching.

        He's got a point that Linux isn't causing any revolutions in OS technology. But he dithers and blathers around so much it's hard to even see that statement for what it is - it almost sounds like he's saying you may as well use SVR4 instead because it's the same basic concepts(!).

        Ho

    • You left out "one of the cool things Linux can't do that AT&T SVR4 can is that Sun might be able to do some compiler stuff some day that nobody cares about".

      You know, because AT&T SVR4 is Solaris from a few years in the future.

  • SVR4 (Score:1, Funny)

    by tuxter ( 809927 )
    Sounds like a new performance vehicle.

  • What does this say? (Score:5, Interesting)

    by aluser ( 771756 ) on Monday January 17, 2005 @07:37PM (#11390677)
    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?

    • Re:What does this say? (Score:5, Funny)

      by ScrewMaster ( 602015 ) on Monday January 17, 2005 @07:48PM (#11390755)
      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."
    • What's his issue with concurrency under linux anyway?

      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.

    • 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 t

      • It was a major innovation when AT&T released a C++ compiler that worked by compiling the C++ code into C code instead of assembler. It allowed the new language to be supported in a fraction of the time required before.

        Er, no. The very first C++ compiler did this. So did a lot of the early ones. At least one still does (Cousteau C++).

  • Best part of the article (Score:1, Informative)

    by Anonymous Coward
    My request for help included a list of some things you can do with Solaris but not with Linux, and more than 40 readers sent me e-mail responding to this by telling me that Linux (or, in several cases, Windows) can do all of those things [...] those responses suggested a frightening thought for future exploration: that the knowledge gap between the Linux and Solaris communities might be much bigger than I think it is.
    • I'm curious, and trying to learn more about Solaris... what /can/ Solaris do that Linux can't?
    • "list of some things you can do with Solaris but not with Linux"

      Hey, you think this could be because Solaris was a closed source product for a while Linux is a re-engineered unix?

      "those responses suggested a frightening thought for future exploration: that the knowledge gap between the Linux and Solaris communities might be much bigger than I think it is."

      I can see why that would keep you up at nights, but consider that the vast number of Linux users you heard from are the next generation of sysadmi

  • The guy's a phony. (Score:5, Insightful)

    by kma ( 2898 ) on Monday January 17, 2005 @07:47PM (#11390745) Homepage Journal
    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.

  • I read the FA (Score:5, Informative)

    by thogard ( 43403 ) on Monday January 17, 2005 @07:48PM (#11390751) Homepage
    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...

    • Re:I read the FA (Score:4, Informative)

      by Ungrounded Lightning ( 62228 ) on Monday January 17, 2005 @09:35PM (#11391497) Journal
      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.

      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.
      • What you claim has been repeated by several others so I guess you got your incorrect info from a reliable source :-)

        Software could always be copyrighted in the US. You just had to print it out and send it to the copyright office. This was done at least in the 1960s. All that changed was the copyrightability of stuff like tapes and diskettes.

        There was little "trade secret" stuff in Unix. They shared the source with so many universities and the early contracts didn't mention trade secrests.

        You also see
    • I too find svc to be extremely annoying. However, replacing SYSV style inits with something else is not, on the face of it, a bad idea.

      Consider that for the vast majority of init scripts, a process is started, stopped, or restarted. Lots of UNIX systems (including debian) provide a special utility that starts and stops daemons in a standardized way, and virtually all startup scripts just call that program.

      Consider that everytime you run a startup script, you're loading a shell interpreter into memory, p
      • However, replacing SYSV style inits with something else is not, on the face of it, a bad idea.

        You might want to have a peek at the FBSD5 init setup. They took the useful bit of the SysV init (modularity, and the ability when push comes to shove to do as much work as necessary to get reliable startup etc because you have the ability to write any old script), removed the evil of run levels, added in dependencies and the existing FBSD sanity of having all the enable/disable settings and parameters (eg what p

      • Having an "enabled" and "disabled" state for services is thus a very good idea.
        man update-rc.d - disabling a service is as easy as update-rc.d -f remove . Re-enabling the service has a specific syntax to give the runlevels you want it started in, as well as its order number in that runlevel. You could put this in a fancy GUI if you wanted.

        • I appreciate your pointer, but you probably ought to have read what I wrote a little bit more carefully.

          But I definitely don't want this service enabled -- when I need it, I want to launch it manually. My using update-rc.d to remove the rc.d links to the init.d file are not seen as a configuration change by my debian system and it will reinstate them, and it will start dhcpd when I install a new version of it, even if I don't have it running.

          So as you can see, I'm quite aware of update-rc.d's exista

          • You could file a bug on the package to include a default file. Most packages' init scripts source an /etc/default/* script for their settings, which _is_ considered a configuration file and won't be overwritten on upgrades.
    • 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...

      Ok, from this little statement it is obvi

      • Ok, so they mix make with init as well. It was done over 20 years ago (and the current init file format allows for this)

        There is a binary file living in /etc that changes with every boot. If it is newer than the xml files, it doesn't get recreated. Its a sqLite file in fact. If you insert stuff in that file in the right spot,
        it gets run even if you never touch the xml code.

        I've never had dependency problems but the 1st thing I do when I get s solaris box is rename the Sxx to a proper order and nuke mo
        • Wow, so are you saying that complexity is bad and that we should all stick with DOS?

          The sql file gets recreated at every boot, unless you didnt change anything, then it doesnt (so it does not get changed at every boot? or does it? please pick one.)

          Ok, so you removed bad init files (standard security practice provided that it is documented) and always remember to verify your changes after patching. Yeah, I've been doing that for years... a real pain in the ass compared to using smf.

          But the kicker is that
          • On my system the binary file contains the last time when the service started. That means a file in /etc gets written with every boot.

            And yes I'm saying complexity is bad and we should stick with what works (and it isn't dos)

            the Solaris start order has been wrong since they 1st used the term solaris.

            I currently work as a team of 3 and I'm the point guy when junk hits the fan. I've been a member of much larger teams (nearly 100) and I'm always the point guy who gets called out to fix what can't be fixed.

  • Off the top of my head, here you go (Score:5, Informative)

    by Anonymous Coward on Monday January 17, 2005 @07:48PM (#11390754)
    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
    • Just so you know... best boot manager out there is called Gag. It has no problem supporting whatever operating systems it finds on your disk, and it finds new operating systems AT BOOT TIME.

    • Re:Off the top of my head, here you go (Score:5, Insightful)

      by idiotnot ( 302133 ) <sean@757.org> on Monday January 17, 2005 @09:02PM (#11391292) Homepage Journal
      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.
      • First of all, you are correct; Grub can't compare to OpenBoot/Firmware, etc.

        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.
        • But that just barfs out what's written in device.map, a file that's sitting in /boot/grub. If those devices change and you don't update it...

          Or if you want to boot from a device you've just inserted, or you manage to kill the filesystem where grub lived (/me raises hand there)....

          PCs have this problem with too much backwards compatibility. The fucked up 1981 boot code perfectly illustrates that. There is absolutely no good reason that a PC built in 2005 should be able to boot DOS. Not one.
      • You can use Grub over a serial console.
      • If the OS is set up correctly all the loader needs to do is start it. I have the BIOS for doing everything else. I don't WANT a loader that does everything , its just extra rubbish that can go wrong. Why do I NEED to check devices in a loader for fscks sake? Its not like its going to use them! Let the OS do the work , thats why its called an "operating system".
        • Because it's there when the OS is fubar. If you think a BIOS will do "everything else", you probably haven't used OBP or anything like it before. You NEED to check devices for many reasons. One of the best reasons is probe-scsi or probe-fcal. Wonder why you can't boot off your device? Check if your scsi/ata/fibre controller can even see it. Want to see if there is network activity on the interface you are trying to boot from? Easy. Do that on a BIOS. While some x86 servers come with a serviceable s
    • 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.

      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.
    • Gah, I loved your post but I disagree with GRUB being somehow better than OpenBoot/OpenFirmware. The drive enumeration is completely braindead, doesn't match up with anything in Linux (heck, doesn't even match up with the enumeration in Hurd, and Grub is the Hurd bootloader, dammit). Also, GRUB is just a bootloader - thats it. Sure, if you use the Multiboot format it can pass some information like memory size to the kernel, but OF/OB is a system monitor that manages all the hardware at start-up. The naming
  • One is completely and totally open source. The other is not.

  • Euh? (Score:2, Funny)

    by Anonymous Coward
    I'm not a native english speaker but does anybody can make head or tail of whatever he says?

    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

    • On the other hand he seems a credible source of insight, being the author of the best seller "The Unix Guide to Defenestration".

      The book is NOT a how-to about using Unix as a tool for completely purging Windows from your IT operation. He grabs the term "Defenistration" and defines it to mean something else - something unrelated to windows. So IMHO a significant part of the book's reason for existence is to co-opt the word and the book title.
  • ASDA boxer shorts are very similar to those sold in Tescos...

    I mean, no shit, OSs doing similar things, what an insight.
  • what??? I mean, sccs, you know... I kind of miss "what".

  • The GPL is Linux's hallmark (Score:5, Insightful)

    by andrel ( 85594 ) <andrel@yahoo.com> on Monday January 17, 2005 @08:12PM (#11390946) Journal
    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.

  • Reasons to use threads on uniprocessor x86 (Score:5, Informative)

    by pslam ( 97660 ) on Monday January 17, 2005 @08:32PM (#11391087) Homepage Journal
    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.

  • WARNING: BACKGROUND AHEAD (Score:4, Interesting)

    by Anonymous Coward on Monday January 17, 2005 @10:08PM (#11391713)
    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.
      • "Imagine, for example, trying to build a compiler able to produce an efficient executable in exactly one pass. Nobody does this now" - Except TCC.

      He said "efficent executable". No one tries to argue that TCC produces faster executables than GCC because it doesn't. TCC does however produce executables faster than GCC. So if you want a working executable as fast as possible, then you want TCC. If you want a fast executable even if it takes longer, then you want GCC.

      • "they didn't come from the Minix/S

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close