Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

OpenBSD SMP In The Works 260

Posted by timothy from the open-as-in-sights dept.
Cajal writes "Four students at the University of Waterloo are working to add SMP support to OpenBSD as part of the Spinlocks project. More information is available in a story at the OpenBSD Journal's site. They expect to have an initial working MP kernel in January."
This discussion has been archived. No new comments can be posted.

OpenBSD SMP In The Works More

OpenBSD SMP In The Works

Comments Filter:
  • ..is that I can never decide to buy a CD set because everytime I think wait one release, the next one will have new feature xxx included!! (Where xxx is some new pf feature, or systrace, or SMP, or....

    • Re:The problem with OpenBSD.. (Score:5, Insightful)

      by jfedor ( 27894 ) <jfedor@jfedor.org> on Monday December 09, 2002 @06:36PM (#4847827) Homepage
      It doesn't matter which CD set you buy, what's important is that the project gets the money.

      You can always get the latest release by FTP.

      So why don't you just buy the current release now.

      -jfedor
    • Well, you could always donate a few bucks instead. More than that, if you buy a 3.2 CD (latest), then you get a CD with the full sources, and when 3.3 is released, all you'll need to do is update your source tree via CVS, then build it. The bandwidth used to update is rather slim.

      But on the subject, the chances are slim to none that SMP will be stable and secure enough that it will be included in the next release, so you don't need to procrastinate this time. I haven't yet heard of major improvements fore 3.3 (except the altq & pf merge) so it will be mostly bug-fixes, and performance improvements.

  • Wow! (Score:5, Funny)

    by Jeffrey Baker ( 6191 ) on Monday December 09, 2002 @06:23PM (#4847609)
    In related news, the Egyptians are on the cusp of discovering Construction, which will allow them to build Aqueduct and Coliseum. However, this is not expected to improve the odds of their feared Chariot against invading Mechanized Infantry.

    • Re:Wow! (Score:5, Insightful)

      by ajs ( 35943 ) <ajs.ajs@com> on Monday December 09, 2002 @07:20PM (#4848405) Homepage Journal
      Ok, I grant your comment is funny, but I'm a Linux user (and sympathizer :) who grew up on BSD, and it really pains me to think that any OS (Solaris, Linux, HP/UX, etc) needs to be viewed as a competitor to BSD rather than a fellow citizen in the realm of UNIX and UNIX-derived OSes.

      Each has its niche, and while some of those niches wane over time (e.g. SCO, IRIX, DG/UX), others flourish (Linux, FreeBSD, Solaris) and that's a good thing. They continue to flow into the containers that they define, rather than having to attack eachother as many products do.

  • Great news (Score:4, Insightful)

    by ekrout ( 139379 ) on Monday December 09, 2002 @06:26PM (#4847661) Journal
    And it makes for a good research project as well.

    But I ask here, as an honest interested person, why one would wait until SMP is correctly and efficiently implemented into OpenBSD when they could simply use any old recent version of Windows or Linux on SMP hardware to get symmetric multiprocessor support for a high-load server?

    I understand that Research -> Products -> Corporate $$$, but is this perhaps too little too late for OpenBSD?

    • Re:Great news (Score:5, Informative)

      by bahwi ( 43111 ) on Monday December 09, 2002 @06:36PM (#4847816)
      Because OpenBSD is about security, not the lastest and greatest features. Linux is about the latest and greatest features. Since the economy went south, most of the peopl working on any of the BSD's lost their jobs or were unable to continue working on the BSD's during corporate time. Where the BSD's have corporate backing and private backing, Linux is mostly private backing, i.e. people at home working on it. Again, things are changing, but everyone has their preferences. No one is going to simply give up OpenBSD to go to Linux, if they need SMP, that is the best route. But from OpenBSD's web page:

      "Only one remote hole in the default install, in more than 7 years!"

      So they all have their uses, Linux, FreeBSD, OpenBSD, and NetBSD. =) Live together, work together, don't kill each other.

      • Re:Great news (Score:4, Funny)

        by Anonymous Coward on Monday December 09, 2002 @06:55PM (#4848082)
        MS-DOS - No root exploits, no patches since 1981!

      • Re:Great news (Score:5, Funny)

        by jfedor ( 27894 ) <jfedor@jfedor.org> on Monday December 09, 2002 @06:59PM (#4848132) Homepage
        "Only one remote hole in the default install, in more than 7 years!"

        What puzzles me is how they jumped [openbsd.org] from "nearly 6 years" to "more than 7 years" in less than a year. :)

        -jfedor
        • Because they changed the criteria after a local exploit via ssh. It used to read something like 'No exploit in the default install...'. Because the new statement applies to remote exploits, the time changed.
          • That's completely wrong.

            When I first came to OpenBSD (abround the 2.5 days), their website read something like:

            1 year without a local exploit in the default install
            3 years without a remote exploit in the default install

            They removed the first line when a couple local holes were found, and since that time there have been no changes to the style.

            The reason it has changed, is merely that they don't update it a precise intervals. They essentially stopped the clock last time they updated (I believe because of some claimed exploit near the 6 year mark that never worked out), and finally brought it up to date recently.

        • Must have been typed on an original Pentium with the floating point rounding error.

      • Re:Great news (Score:5, Insightful)

        by joib ( 70841 ) on Monday December 09, 2002 @07:14PM (#4848328)
        I'd say the main reason for Linux development continuing rapidly despite the economy is that the Linux market is orders of magnitude larger than the *BSD market, so the distro makers (and other companies who employ Linux kernel hackers) have the money to keep Linux kernel hackers employed.

    • Re:Great news (Score:4, Insightful)

      by jfedor ( 27894 ) <jfedor@jfedor.org> on Monday December 09, 2002 @06:50PM (#4848022) Homepage
      But I ask here, as an honest interested person, why one would wait until SMP is correctly and efficiently implemented into OpenBSD when they could simply use any old recent version of Windows or Linux on SMP hardware to get symmetric multiprocessor support for a high-load server?

      Because you like OpenBSD and would like to help them test the SMP-enabled version so that one day it runs properly?

      What's an "old recent version of Windows", BTW? :)

      -jfedor

  • Maybe now.. (Score:2, Interesting)

    by FuzzyMan45 ( 451645 )
    They can increase their userbase to (hopefully) include some of the larger companies and corporations that opt to use FreeBSD because of it's SMP support and greater performance than OpenBSD. Hopefully, this modification will also include some performance modifications so it can also compete speedwise with FreeBSD.

    While security takes precedence over performance in my book, there are definitely some things that need the performance of FreeBSD.

    This is one feature i've been looking forward to playing with (not NEEDING) for a while, i can't wait to try it when it's available somewhere.

    --Fuzz

  • Sweet Mother of Blowfish (Score:3, Funny)

    by echorun ( 629954 ) on Monday December 09, 2002 @06:30PM (#4847731) Homepage
    Sweet now I can have more than one fish in the box.

  • It's about friggin time they did... (Score:5, Informative)

    by CoolVibe ( 11466 ) on Monday December 09, 2002 @06:32PM (#4847767) Journal
    Although, the question remains if Theo will accept these patches...

    The last time I spoke to Theo in person, he wasn't too keen on SMP. That wasn't too long ago.

    • Re:It's about friggin time they did... (Score:4, Interesting)

      by aridhol ( 112307 ) <ka_lac@hotmail.com> on Monday December 09, 2002 @08:47PM (#4849365) Homepage Journal
      Possibly he wasn't keen on the time investment required to implement SMP. If these guys do all the work, it may well make it in.

      OTOH, it may be that SMP code is more difficult to audit, and that this is the reason it won't make it in. Remember, SMP allows for the possibility of race conditions within the kernel itself, which would be a nightmare to validate for security.

      • Re:It's about friggin time they did... (Score:4, Insightful)

        by CoolVibe ( 11466 ) on Monday December 09, 2002 @09:14PM (#4849606) Journal
        Possibly he wasn't keen on the time investment required to implement SMP. If these guys do all the work, it may well make it in.

        It might. Even if Theo doesn't accept these patches, the patches will still be available. I just hope they keep maintaining them and keep them up to date if Theo says no for any reason.

        OTOH, it may be that SMP code is more difficult to audit, and that this is the reason it won't make it in. Remember, SMP allows for the possibility of race conditions within the kernel itself, which would be a nightmare to validate for security.

        If Theo would deny this work, it would probably be on those grounds. It was indeed one of the reasons he mentioned to me.

        The most likely place for race conditions to occur on SMP systems is with threading. I have yet to see a totally solid threading implementation that is totally devoid of race conditions of any kind wrt locking/freeing/semaphores/etc. Usually kernel developers solve most of the problems by passing one big lock around (like linux does, and FreeBSD (ever heard of Giant?))

        All in all good news that these guys are working on it indeed. My main concern is seeing this project die because it has the chance of being shot down by Theo. I really hope they persist in pushing Theo to accept it. I also hope they have a lot of patience while dealing with Theo, he's also not the easiest to get along with :)

    • Well if worse comes to worse, they could always fork OpenBSD like Daren Reed did to include ipf. Of course then you lose the trustyworthyness of OpenBSD because it is no longer A) official or B) going under the microscope like OpenBSD does by the OpenBSD team.

      psxndc

      • For all their so called security auditing, they failed to find several holes, most notably in openssh. Holes not only in older code, but holes in the new code added by the openbsd team themselves.. So you trust people who write insecure code themselves to audit existing code for security?
  • We want the option of SMP on SUN kit as well. Seriously SMP is well needed seeing as most OpenBSD box's are yesterdays coperate kit. Also given intels SMP on a chip play along with Power4 dual cores on the market now that by the time they make it into your average geeks home SMP should be stable.

  • I guess they can forget about... (Score:3, Interesting)

    by Jacco de Leeuw ( 4646 ) on Monday December 09, 2002 @06:36PM (#4847830) Homepage
    ... ever working for Microsoft [uwaterloo.ca] then!

    Microsoft has been raiding the University of Waterloo for programmers for years now.

  • Those who don't use Linux are doomed to reimplement it... again.

  • XP and Linux comparisons are pointless (Score:5, Interesting)

    by flinxmeister ( 601654 ) on Monday December 09, 2002 @06:44PM (#4847932) Homepage
    I've been using OpenBSD in several mission critical networking roles for 3 years now, and I can safely say that I haven't needed SMP.

    The conventional wisdom that an operating system should be judged according to it's bells and whistles is what's wrong with the software industry. An OS should be judged by two things: Does it do the job I require of it, and does it do it well?

    There are many many jobs that do not require SMP. There are many many jobs being done on SMP boxes that do not require SMP. As the price of processors has diminished, SMP is just a cool thing to buy. I'd be willing to put money down saying that 75% of the SMP boxes out there aren't needed (if that was measurable).

    So, if you want to judge your OS based on features you don't need, then go for it. I use OpenBSD because it is the best choice for that particular need. If you want to assume that one OS is the Uber-OS because of the back panel of the box, then go for it. I'll assume a particular OS is best for the task at hand, and go with that.

    I'm not part of the OpenBSD project (nor do I play one on TV), but one of the central points behind it is that they don't put in things unless they are needed. So far it doesn't seem like SMP has been justified in the great scheme of things (no surprise given the actual need in the wild). I'd much rather have them working on things I'm going to be using instead of evaluating other products based on things I won't.

    • "I've been using OpenBSD in several mission critical networking roles for 3 years now..." blah blah blah...


      What are you using it for, and how reliable is it for networking? Uptime?



      • 7 production firewalls in varying degrees of importance. 6 of these guys have *never* gone down. The exception on one was one where squid had some compile issues and made the rest of the box unhappy (during implementation). This number includes one soekris box. 2 temporary firewalls where someone insists on using firewall-1 or Symantec on Solaris but doesn't have the Solaris hardware or the budget yet. One is a bridging firewall, so I don't know what they're going to do when they want to switch. To be honest, they'll probably end up keeping them. 3 Snort sensors. (2 have never crashed, uptime of over one year before massive power failure at the location). This includes 3 upgrades of snort. One crashed during some Gigabit experiments. A high volume syslog server/ftp logfile repository/mysql server. This one has been a bit flaky. Crashed twice in a one year period, 10 months between crashes. A web server that has a maximum uptime of 8 months. Could have gone longer but this location has a bad power situation. So total OpenBSD boxen for me is around 14.
    • "two things: Does it do the job I require of it, and does it do it well?" In every engineering project there's cost. You can choose two of the three: Better, Faster, Cheaper. You may have forgotten this, but the accountants won't
    • Yeah, just like Windows users were saying around '95, "who needs pre-emptive multitasking, I've never needed more than co-operative multitasking" (and Mac users until Mac Os X). Or linux users wondering why one needs a journaling file system, up until three of them get mature enough. And when the system does get what was formerly denounced as "unnecessary toy", it suddenly becomes indispensable commodity.

      Now, SMP is not necessarily something people "start needing"; you don't usually realize one day that "gee, now I really need SMP". For many things it isn't strictly required, like you say -- after all, most systems only scale up decently to 4- or perhaps 8-way systems, and common rule of thum is that you get about sqrt(num_procs) output (assuming you get enough CPU load for all processors)... and so you can same amount of work done by getting twice as fast CPU (instead of 4-way SMP system).

      However, having SMP capability as an option is a Good Thing. For servers it allows nice high-end scalability (esp. with Sun boxes, E10K and co. wouldn't rock if it wasn't their SMP-scalability coupled with kickass I/O.. but those beast scale well past 8 CPUs). For desktop systems it allows for better interactivity (especially on traditional unix[ish] system that have batch-job oriented scheduling), smoother UI.

  • Hacking on PowerBooks (Score:3, Informative)

    by scorpioX ( 96322 ) on Monday December 09, 2002 @06:49PM (#4848007)
    Did anyone else notice that these four students are using PowerBooks (I assume running OS X). Check out this picture [spinlocks.org]. You also have to love the reference to the cult movie Hackers.

  • So? (Score:1, Insightful)

    by Anonymous Coward
    I see tons of negativity from the clueless as usual. *sigh*

    Hey, people? Do you know how many people *don't* need SMP, as opposed to those who do? Did you ever think that, given the number of SMP-supporting *nixes out there, OpenBSD felt like concentrating on more important things (like security) first?

    Yeah.

    Congrats, OpenBSD! (Still the only operating system to pit Daemonettes against Catgirls in pits of pudding! Hehehe. Get it? Daemonettes? Catgirls? Script Kitties? HEHEHEHEHE. Sorry. :P)

  • A long wait... (Score:5, Informative)

    by evenprime ( 324363 ) on Monday December 09, 2002 @07:06PM (#4848204) Homepage Journal
    There's been talk of doing this since 1997 [sigmasoft.com]. In the past there was concern about the cost [sigmasoft.com] of SMP hardware to develop on and also on the huge amount of time [sigmasoft.com] needed to do it right:
    SMP is a big deal. OpenBSD does things, and it does them RIGHT. To do SMP right, we'd need to make the kernel fully-reentrant. This means that we'd clean up the kernel I/O functions so that they don't wait on one another (that's a really dumbed-down, bad explanation of it.) By making the kernel re-entrant, we wouldn't have the problem of spinlocks (one processor waiting on the other to finish I/O, etc.) This would mean almost a COMPLETE re-write of the kernel. This would be a six+ month ordeal for quite a few coders working 40-60 hour weeks. Remember, such a huge task needs to include not only the re-writing of existing code, but checking it to make sure it works on all supported platforms without breaking all the great existing features of OpenBSD.
    That bit about doing things the Right Way is a major consideration for the OpenBSD team. In 1998 [sigmasoft.com] jkatz pointed out that they probably wouldn't just use the code from another BSD because they wanted to make sure that OpenBSD's solution was more scaleable.

  • Very smart... (Score:4, Interesting)

    by Dahan ( 130247 ) <khym@azeotrope.org> on Monday December 09, 2002 @07:08PM (#4848249)
    Good to see that they're using NetBSD as a reference for this... OpenBSD is basically a less-active branch of NetBSD from a couple years back, so it should be a pretty straightforward process to merge in the SMP stuff from NetBSD (which, like just about every other OS, has had SMP for quite some time now).

    OpenBSD is a very promising OS, and SMP support will finally let it play with the big boys in the free *nix playground :)

    • OpenBSD is basically a less-active branch of NetBSD from a couple years back

      OpenBSD may have been branched from NetBSD, but there is practically no resemblance left anymore. Both, in source code and userland, there have been so many changes that the differences between Net and Open are bigger than the difference between either of them and FreeBSD.

      SMP support will finally let it play with the big boys in the free *nix playground

      OpenBSD has a very surprising acceptance. Sure, usually on routers, firewalls, gateways, VPN routers, etc., but in comparison to NetBSD, OpenBSD is doing incredibly well.

      • Re:Very smart... (Score:4, Interesting)

        by LizardKing ( 5245 ) on Tuesday December 10, 2002 @05:39AM (#4852665)

        OpenBSD may have been branched from NetBSD, but there is practically no resemblance left anymore. Both, in source code and userland, there have been so many changes that the differences between Net and Open are bigger than the difference between either of them and FreeBSD.

        I applaud your attempt to counter the accusation that OpenBSD is "less active" than Net, but you've got it a little wrong. The userland between the three *BSDs is very similar, and the kernels have similar subsystem layouts. Without this similarity, things like softdeps, systrace and IPv6 wouldn't have percolated so quickly into all three. Finally, note that this new OpenBSD SMP work builds on Bill Studenmunds NetBSD code.

        Chris

        • you've got it a little wrong. The userland between the three *BSDs is very similar, and the kernels have similar subsystem layouts.

          You should read my post more quickly next time. I said the differences between OpenBSD and NetBSD are now larger than the differences between NetBSD and FreeBSD (or between OpenBSD and FreeBSD).
  • Which of the popular applications and uses of OpenBSD would benefit from SMP support?
    • Which of the popular applications and uses of OpenBSD would benefit from SMP support?
      I don't suppose anybody is running apache on it? :) But seriously, the only requirement to benefit from SMP is that you run more than one cpu-intensive process on the computer at once. Servers (like apache) usually fork a process for each client.

    • Re:Uses of SMP? (Score:3, Informative)

      by Tuzanor ( 125152 )
      Dynamic web servering, of course. OpenBSD is also widely used as a VPN. Whilst some of the crypto cards work great a second proc. can only help. Also, firewalls for very large networks may benefit.

    • Re:Uses of SMP? (Score:4, Informative)

      by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Monday December 09, 2002 @08:39PM (#4849271) Homepage Journal
      In addition to what the siblings of this comment currently say: Everything that requires lots of CPU, or lots of processes running at the same time. A single thread is usually not relocated across processors, so the following is more or less true in the case where you have lots of processes of vaguely equal size and more than one processor: The number of context switches which have to be done is divided by the number of processors. That's one benefit. The other is that (in theory but not in practice of course) you can execute twice as many instructions at once. Obviously you still have operations which have to wait on things other than other instructions being retired (Though that too) which I suspect is the main reason why usable "speed" (let's say cycles for the sake of saying SOMETHING) does not tend to scale linearly with additional processors.

      Anyway anything that is relatively (or entirely) cpu-bound and involves lots of processes or threads will be sped up significantly. Also one process doesn't tend to monopolize your processor so badly.

  • --about time. Before I just didn't understand. I keep reading about open bsd being a server distro, very secure. Well, duh, servers are where you see multiple processors more than cheap(er) desktops. and if all it is is to be some sort of minimum home brewed gateway router thing, they can stop now, it's "done", go on to some other project.

    All in all, though, I'd say adding multiple processor support is a good thing. I wish them well, and perhaps I'll try it someday once this is more stable.

  • This would be nice (Score:5, Interesting)

    by QuietRiot ( 16908 ) <cyrus@80[ ]rg ['d.o' in gap]> on Monday December 09, 2002 @07:35PM (#4848607) Homepage Journal
    I'm curious how much of a rework will be required [by the OpenBSD core developers] once these guys are done. 4 guys on a one-year project. SMP. Good luck. Will this be a patch-type thing? Will the core team accept it, or reject it outright? Will the core team use some portion of it - cleaning it up along the way, or will it take a major rewrite?

    It's strange how things like this end up changing would would have been. Do it right the first time, because if it gets adopted, and it wasn't done right, efforts will be diluted.

    I'm glad to see it's happening though. At least somebody's throwing some brainpower at it rather than waiting around for Theo & friends. (no fault to Theo, I know SMP is "in the works" - OpenBSD is secure, first and foremost. That's what I, and many others, care about most. Kudos to you and your team on this! You have a highly-regarded, ultra secure OS that has kept many cracker-types and script-kiddies at bay for many years. You have saved many people many thousands or millions of dollars with the protection your software project has provided. You have given nothing to the headache medicine providers of the IT industry.)

    One more processor for my dual-capable Sun SS20 and I'll have a grand-ole time playing with this. Just too bad it comes with only a single 10-speed ethernet port. Anybody know about S-bus fast ethernet cards?

    To these brave deveopers: Way to go! Thanks for getting the ball rolling and best of luck with your project (and dealing with the publicity! :)

  • Sure its cool and isnt a bad thing, but for the target market that OBSD has, is SMP really *that* important?

  • Ok, it's oversimplification time. As I understand it, the three main flavors of BSD and their foci are:

    Free - Well-rounded BSD for popular architectures.
    Open - Ultrasecure BSD for many architectures. Lots of code auditing, but always just behind Free in some area or another.
    Net - Runs everywhere. Won't be done until it runs on toasters and wristwatches.

    I have much less experience with the BSDs than I do with the various GNU/Linux distros, so I hope someone will answer my question rather than flame in response. I've long been an advocate of reducing the number of different and nearly equal (in functionality) ways to do the same thing, regarding what I would call redundant software projects. In my view, the necessity of competition in a market for physical goods (the need to keep costs down and quality up by preventing monopolies) does not exist with OSS. If a company producing OSS decides to raise prices or slow development or include unpopular features, anyone else is free to keep using older versions at the very least or fork the project and continue development with positive goals at best. With the necessity for competition removed, a market containing multiple, redundant, competing (for mind share) OSS projects is inferior to a market containing a single, popular OSS project that satisfies a specific need. Incompatibilites crop up. The support base is divided. Developer time is divided. Skills must be learned twice. I would greatly prefer a single desktop environment (and widget set and cut 'n' paste mechanism) over the current situation. In Erpo's-the-emperor land, there is only one gnu/linux distro.

    Remember, these are just my opinions.

    My question is this: while there are a number of idealogical, license-, or ego-related reasons why maintainers of gnu/linux distros (or desktop environments, or whatever) would resist a merging of sofware or elimination of obviously inferior options (obviously inferior in the "there's 1001 gnutella clients and 99% of them suck" sense), is there the same kind of resistance in the BSD community to merging all three main flavors?

    • Re:a bsd question (Score:2, Interesting)

      by Walterk ( 124748 )
      Here's something more compact:
      "FreeBSD has tcsh installed as /bin/csh. OpenBSD and NetBSD don't. NetBSD runs on a Cobalt Qube2. OpenBSD and FreeBSD don't. OpenBSD can encrypt swap. NetBSD and FreeBSD don't."
      Can't remember where I picked that one up.

    • Re:a bsd question (Score:2, Interesting)

      by kjd ( 41294 )
      Three different projects with separate ideals and goals. Their code has not been "one" for a long time, but code is quite often swapped between the projects in large chunks where deemed useful and possible. Merging the three codebases is really not necessary, as they give and take each other's code as they please; and merging the focus and direction of the three projects would be plenty more difficult than the code. :)

      Also, keep in mind that these projects did used to be one. They're now three for many good reasons.
    • But linux has already [k12.or.us] done [ibm.com] both of those! Get a new goal!

    • Re:a bsd question (Score:2, Informative)

      by SN74S181 ( 581549 )
      I've long been an advocate of reducing the number of different and nearly equal (in functionality) ways to do the same thing

      I feel much the same, in a lot of ways. So I've focused on NetBSD.

      I have Sparc and Intel and various other pieces of hardware. With NetBSD I can run the same OS, built from the exact same source tree (kernal and userland, plus the packages) on it all. I've built a library of almost all the essential references for Unix, including a complete 'real' manual set from 4.3BSD (it's great to use the tutorials from the old days- I'm starting to appreciate 'ed' as a real editor after reading Kernighan's tutorials), the 'devil' BSD book (McKusick/Bostic/Karels/Quarterman), 'The Basic Kernel' 386BSD book (Jolitz and Jolitz), Bach and (of course) Tannenbaum. Throw in an assortment of O'Reilly books (the Vol 3 and 8 X11 books are especially good, along with 'Essential System Administration').. There's more than enough on my plate for me to study and learn from. I see Linux as generally growing away from it's UNIX roots, part of why as I came to like UNIX more and more I liked Linux less and less and gravitated to one of the BSDs.

      The BSD forks were probably a good thing, as it's allowed the BSD systems to thrive and grow in several directions. Generally there's a synergy there in the way the code gets passed around between the different groups that would probably be more destructive if they were one group with all the infighting that would entail.

    • Re:a bsd question (Score:4, Insightful)

      by cant_get_a_good_nick ( 172131 ) on Monday December 09, 2002 @11:33PM (#4850719)
      There are some ego questions, Theo used to work on NetBSD. As smart as he is, and productive as he is, they found him abrasive and let him go. He hasn't changed much, and isn't likely to, and the world's a better place for having OpenBSD. From what I understand FreeBSD and NetBSD forked around the same time from the original BSD code, and 386/BSD. 386/BSD was kind of showing its rough edges, and people wnated to clean it up. FreeBSD went the x86 route, NetBSD always tried to be multiplatform.

      That said, there is a lot of code sharing. The USB core is exactly the same in both Net and Free, probably OpenBSD as well. systrace was originally slated for NetBSD, ended up in Open. 5.0 is getting a new /etc/rc startup, pioneered in NetBSD. A lot of the userland is the same, and there's some action on getting a standard ports system.

      In some respects, there's more sharing in BSD than in some of the Linux distros. Since all the owners of the BSDs are essentially non-commercial, there's no real incentive to make proprietary stuff. In some situations, the BSD license is easier to share stuff, but it really doesn't in this case - if they were all GPL they could share things.

      I understand what you're saying, that it diverts attention and resources. But you also have to realize they pick up thing as well. There's some cross pollination. I believe the SMP stuff is kind of taken from BSDi, if not the actual code then at least the general idea.

      The other thing is "one-size fits all" gives you a huge XXXXL product. If all the things went into just one or the other, it would be pretty bloated. The focus of FreeBSD (optimized for Intel) is in respects incompatible with NetBSD (ultra-portability). Ask anyone who's worked on gcc about the problems of optimizing portable code.

    • Scissors, Paper, Stone (Score:3, Insightful)

      by Tony-A ( 29931 )
      Pick ONE.
      Different approaches, different world views. It's hard to tell which is better (and why) *after* it's been done, much less *before* it's been done.
      I don't think the duplication of effort is all that wasteful. Image the state of Linux and FreeBSD security if OpenBSD did not exist.

  • Note: Announcement Not From OpenBSD.org (Score:3, Insightful)

    by Nathan Ramella ( 629875 ) on Monday December 09, 2002 @08:50PM (#4849389) Homepage
    Please take note that this announcement didn't come from OpenBSD.org. The guys doing it as just doing it as their own project (which is neat). One of the main reasons people enjoy OpenBSD is that it's code has been audited by Theo and his folks and prepared to be the most security oriented distro around.

    • Re:Note: Announcement Not From OpenBSD.org (Score:5, Informative)

      by ISWalker ( 632807 ) on Tuesday December 10, 2002 @12:09AM (#4851043)
      Finally someone who is correct. I'm one of the students working on this. It is our computer engineering project. The plan is to have it somewhat working by January. We decided to this because we needed an idea for project and we thought it would be fun and allow us to learn a lot in the process. When the project is complete, we plan to release the code we have and if OpenBSD wants to use it he can, however, that wasn't necessarily the original intent.

  • I find it funny that all of these wonderful features are being added to a system that won't boot beyond 8G.

    I've been having my own personal hell getting grub or lilo to boot this system on a second HD. My only success so far is to use the entire disk and then chainload it. Suggestions are welcome.

  • I'm probably going to get modded down for this, but it's got to be said (and this is from experience; it's not mindless cheerleading) --

    This isn't the best use of OpenBSD developer time, if what they want is a better OpenBSD. Despite its good (but not perfect) security track record, this is an operating system that is riddled with mysterious problems when it comes to Unix compatibility.

    I've got a bunch of source code that builds and runs fine on FreeBSD, Solaris, Linux, and a bunch of other Unices, but OpenBSD introduces reliability problems and some serious performance problems. (The same computer processes the same data with the same program at about 20% of the speed of Linux.)

    SMP is a nice thing to have, but before OpenBSD can really be seriously considered for production use on any but the most trivial tasks, the reliability and performance issues need to be ironed out first.
    • Have you taken the effort to find out *why* it's taking 5 times longer to run on OpenBSD? There are a number of speed/safety tradeoffs where OpenBSD should be overly paranoid and everybody else overly trusting.

Slashdot Top Deals

BLISS is ignorance.

Close