Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software BSD

DragonFlyBSD 1.2 Released 184

Posted by timothy from the live-cd-bsd dept.
vsarunas writes "The DragonFlyBSD Team is pleased to announce the official release of DragonFly 1.2.0! Get it here, or here, or as a torrent. DragonFlyBSD is a continuation of the stable and high-performance FreeBSD 4 branch of FreeBSD with acpica5 and updated drivers so it runs on more and newer machines. DragonFlyBSD can execute FreeBSD 4 and Linux binaries and uses the FreeBSD ports collection. In addition, DragonFlyBSD is also officially supported by pkgsrc. This release represents a significant milestone in efforts to improve the kernel infrastructure. It features a standards-conformant SACK implementation, improvements to the VFS layer, and a multithreaded networking stack that utilizes the DragonFly lightweight message passing system to communicate among processors. More information can be found on Matt Dillon's journal and the Status page of the DragonFly wiki."
This discussion has been archived. No new comments can be posted.

DragonFlyBSD 1.2 Released More

DragonFlyBSD 1.2 Released

Comments Filter:

  • DragonFly is awesome! (Score:2, Funny)

    by Anonymous Coward
    Fly Fred Fly!!!!

  • FreeBSD alternatives on the rise... (Score:3, Interesting)

    by Ars-Fartsica ( 166957 ) on Monday April 11, 2005 @05:03PM (#12205321)
    NetBSD in particular and DragonFlyBSD to a lesser extent seem to be taking off in the wake of what seems like mass disillusionment in FreeBSD 5.x.

    I would be interested in hearing from people how either of these BSD alternatives stack up as a desktop box.

    • Re:FreeBSD alternatives on the rise... (Score:5, Interesting)

      by dinivin ( 444905 ) on Monday April 11, 2005 @05:08PM (#12205376)
      DragonFly doesn't stack up as a desktop box at the moment. Here's a post I made on osnews.com about it:

      Go ahead, install Dfly, and cvsup the latest FreeBSD ports tree and DragonFly dfports tree. Now try to build some useful apps... Way too many apps won't build from the ports tree. If you're lucky enough, there's a dfports override. If you're even luckier, it'll be the same version as the ports tree. Let's assume you actually get those apps installed... A few weeks later you cvsup the ports tree again and try to do a portupgrade. Suddenly SDL in the ports tree is upgraded... By SDL in the dfports tree isn't. Great... Now you have apps that want the newer SDL that keep building SDL from dfports, which you already have installed and which isn't up-to-date...

      You can always try pkgsrc, if you want.

      First, you need to build and install the bootstrap code. Then you need to update bmake from the bmake package (the forget to tell you that on the gobsd.com site). Forget about getting enlightenment running, imlib2 fails to build. You currently need to patch the gtk2 port (assuming the patch hasn't been committed yet). Firefox won't build, nor will SDL. If you want to build Blender, it'll try to build nasm, which requires the gcc3-c package... Which won't build. (You can edit the nasm Makefile to remove the gcc3-c dependency).

      Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO.
      • If you are not a developer you should use packages.
        Of course it's not yet perfect, but who would exepct that.
        And i've yet to see a desktop without problems.
        • If you are not a developer you should use packages.

          If that's the case, why not say that on their website? They don't (or as of this morning, they didn't). Instead, they point out that the FreeBSD ports, combined with the DragonFly dfports is the official method for installing software.

          Of course it's not yet perfect, but who would exepct that. And i've yet to see a desktop without problems.

          Nor did I ever make the claim that the developers said it'd be perfect. Far from it. I was simply responding
      • This shouldn't surprise you...

        From the installation readme:
        NOTE!!! DRAGONFLY IS UNDERGOING DEVELOPMENT AND IS CONSIDERED EXPERIMENTAL! BSD RELATED EXPERIENCE IS RECOMMENDED WHEN USING THIS CDROM.

        Honestly. I don't think they've advertised themselves as being anything else. They're trying to validate their kernel architecture before they needlessly start putting a lot of effort into packaging.

        Note, despite being experimental, the OS is quite stable and developers are willing to fix broken port/pkg
        • None of that means anything about whether it is a good desktop OS.

          And that's where we disagree. In my opinion, a good desktop OS should make it simple to update/upgrade software packages that are installed through the official method. Currently, DragonFly doesn't succeed at that. It certainly has potential, and you'll never hear me say that it's unstable, but unless a user has a very specific purpose for it, and knows that their needed packages/ports will install (and be up-to-date with what the need)
      • "Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO."

        Indeed.

        I don't see anything particularly wrong with that. They're breaking a lot of new ground, and I don't see any of the developers claiming that they're production ready. I think Dillon mostly wants regular releases to keep the system stable enough to build itself.
    • Unfortunately DragonFly doesn't yet have its own package manager, so some applications may not build or will require some extra effort like patches to build. But most if not all can be built using the DragonFly override of ports (DFPORTS) and PKGSRC

      • Re:FreeBSD alternatives on the rise... (Score:3, Interesting)

        by Anonymous Coward
        I think the "packaging" idea of dragonflybsd deserves a comentary

        Tha plan of matt is to move part of the VFS to userspace (ala plan9 it looks to me, but don't trust me).

        This will allow to do neat tricks too. Say,you have a app depending in randomlib 1.0. Now you want to install something that installs randomlib 2.0 and and breaks the previous app. With the packaging work, matt seems to expect to allow both packages to live at the same time - randomlib 1.0 will be showed to one app and randomlib 2.0 wi

    • Freebsd not dead, lot of things happening (Score:5, Insightful)

      by Anonymous Coward on Monday April 11, 2005 @05:20PM (#12205490)
      FreeBSD has not been the best FreeBSD release but it's *not* dead. 5.3 has been the *first* stable release of the 5.x series, and as expected is not as polished as it should be

      I read the mailing lists (I'm not a FreeBSD user tough), and lots of work is happening. All those benchmarks you've seen where freebsd 5.3 loses were done with the 5.3 code which didn't incorported lots of performance work, just to get a stable 5.3 release

      Expect 5.4 to be the real 5.x release ie: fast (LOTS of performance work is happening in the threading and VFS land) and stable (lots of critical bugs has been fixed, 5.3 was the first public release)

      And no, FreeBSD 5 is not dying. RIght now FreeBSD is the BSD with better SMP support (and getting better), and dual core CPUs are starting to be sold this quarter. NetBSD and OpenBSD are not even near of the SMP support Freebsd has (oth of them detect several CPUs, but it will take all the year s it took to freebsd 5.x to use them efficiently, and most of the benchmarks done against NetBSD/OpenBSD are with only one CPU, which doesn't measure all the work done in the 5.x branch.
    • I'm using DragonFlyBSD as my desktop without problems.
      You still need the libmap patch for flash, because they think it's too dirty to integrate.
      http://leaf.dragonflybsd.org/mailarchi ve/users/200 5-01/msg00045.html

      Packages are also availbale either built from netbsd pkgsrc of freebsd ports:
      wiki.dragonflybsd.org/index.php/Packages

      I also use the citrus patch to get wide char support:
      leaf.dragonflybsd.org/~joerg/citrus5.dif f

      Packages for use with the citrus patch are availble here:
      http://ftp.fortunaty.net/DragonFly/inoffici al/port s-packages-libc.so.5-gcc34/All/

      If you use gcc34 packages/world everything is compiled with stack protector.
      It's also very snappy :)
    • One problem with NetBSD is that despite nearly universal agreement that the 4-clause BSD license is stupid the NetBSD Foundation insists on keeping the advertising clause. This is a good reason to stick with FreeBSD or DragonFly.
      • How is it a good reason? It will only affect you if you want to use the few parts of software under the license in another project or embedded system. It doesn't make any difference to your usage or the quality of the operating system itself. I sincerely hope you're just trolling because you can't seriously believe what you say.

    • NetBSD in particular and DragonFlyBSD to a lesser extent seem to be taking off in the wake of what seems like mass disillusionment in FreeBSD 5.x.

      I certainly don't see any kind of "mass disillusionment". FreeBSD 5.x has brought about added complexity for the sake of performance, namely in the SMP and multithreading arenas. These are areas where you will find the performance of NetBSD rather lacking. While NetBSD may win at certain meaningless microbenchmarks, the real world performance of FreeBSD, es

    • I wouldn't call it disillusionment. It is more impatience. I've been using FreeBSD on the desktop since 5.0-Current in 2001, the only real glitch was when they broke signal delivery in 2002.

      As a desktop OS, FreeBSD is pretty healthy--the performance short-comings that still linger in 5.x are not so important on the desktop... imo.

  • BSD? (Score:2, Interesting)

    by stratjakt ( 596332 )
    If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?

    With linux, the choice of distro is pretty much irrelevant - to me at least - because I wind up with virtually the same system, the only differences being the layout of some rc scripts.

    The world of BSD isn't the same though, so which is the most prolific, or newbie-friendly, or has the widest support for common hardware, etc?

    About the only thing keeping me

    • Re:BSD? (Score:3, Informative)

      by swimmar132 ( 302744 )
      FreeBSD, for sure.

    • Re:BSD? (Score:3, Informative)

      by random_culchie ( 759439 )
      I would go with FreeBSD if I was in your shoes.

      Its Installer is a breeze to use and rarely have problems with com mon hardware.

      OpenBSD's Install is a nightmare for a new user (last time I used it!) and is clearly aimed at the security concious user. (The tin foil hat distro hehe)

      I have never used NetBSD but its claim to fame is the sheer number of platforms it supports.

      • Re:BSD? (Score:2, Funny)

        by compass46 ( 259596 )
        OpenBSD's Install is a nightmare for a new user

        http://www.openbsd.org/faq/faq4.html ;)

        Specifically section 4.5. I use both Free and Open and I like the Open installer MUCH better and find it actually easier to deal with. I printed out section 4 of the FAQ and read along as I installed one of my first times. That install was my first successful one.

      • Re:BSD? (Score:3, Informative)

        by synthespian ( 563437 )
        OpenBSD install is *not* a nightmare. It's regarded as pretty straightforward. You just have to have some attention span to read the FAQ. Can you do that?
        Otherwise, it's a smooth install. It's not a Linux install, though, it's different. And, also, they generally assume you will *not* be dual-booting.
        Let's dismistify this thing that OpenBSD in an alien OS. It's a rock-solid Unix, secure, peer-verified-code with mechanisms built-in to prevent attacks. It's ports tree is growing.
        The "average" open-sour
        • they generally assume you will *not* be dual-booting.

          Before the days of my house having tens of operational computers, I used to dual boot OpenBSD often. For a long while I had two Seagate 20GB disks which I was booting between OpenBSD, Debian GNU/Linux, Windows 2000, QNX, OpenBSD, FreeBSD, BeOS 5 PE and Windows NT 4.0. Yes, OpenBSD was on each disk. One was my main OS and the other I used for testing.

          This was mostly for my learning. Smart Boot Manager is great!

          I never could get Solaris 8 x86 or SCO Uni
      • OpenBSD's Install is a nightmare for a new user

        OpenBSD's installer might be a shock to a newbie who is used to typical Linux installers, or even FreeBSD or NetBSD. But I love it! It is fast, straight forward and functional. Just read the fine documentation and then enjoy it from then on.

        I have been trying to install NetBSD 2.0 across multiple spindles and I can't seem to find a way to do it without loosing my disk configuration when moving on to the next disk. I resorted to installing on one disk, bootin

    • Re:BSD? (Score:2, Informative)

      by niteice ( 793961 )
      OpenBSD, definitely, since you're running it on a router/gateway.

      • Re:BSD? (Score:5, Informative)

        by DesScorp ( 410532 ) on Monday April 11, 2005 @05:18PM (#12205477) Journal
        "which BSD is the one to cut your teeth on?"

        That implies he doesn't know much about BSD. Advocating Open as a first install then, might not be the best of ideas...

        • Re:BSD? (Score:3, Insightful)

          by CondeZer0 ( 158969 )
          From a conversation with a friend earlier today:

          "OpenBSD was my first *NIX, and I thank God for initiating me to Unix with the only barely sane *NIX at the time."

          Of course this days I know of better [bell-labs.com] things [vitanuova.com].

        • A lot of people have already responded, but I would like to add my experience.

          When I was beginning my transition to Unix, I started by trying to install Mandrake on my personal computer. I failed. Then I tried installing FreeBSD on a secondary computer. It sort of worked, but I didn't really know what to do with it.

          Then I installed OpenBSD on my file server. It was love at first sight.

          The installer was simple, fast. I could boot off the network easier than I could burn a CD. Nothing was running by

        • I actually think it would be one of the better ones to start off with. The main caution is doing the partitioning. Look at the FAQ section of the install and read the through the pamphlet in the cd cover to see how an install goes.

          Other than that part, it is actually pretty easy. Once you have it installed, working on it is very easy. For router / gateway configurations there are a load of web pages to explain what to do, including the excellent FAQ and PF FAQ.

          Weirdly, I actually have a lot more probl

        • That implies he doesn't know much about BSD. Advocating Open as a first install then, might not be the best of ideas...

          "Thrown into the deep end" mean anything to you?

          Read OpenBSD documentation, use OpenBSD, repeat and persist until it is crystal clear. What better way to learn than to be confronted with problems, research them and conquer them?

          I am not really impressed with NetBSD or FreeBSD documentation, especially compared with OpenBSD documentation. Do you advocate learning from a system that does
    • Ideally you will probably want OpenBSD on a router/gateway, since it's typically considered 'more secure' than the others. This is really 'more secure out-of-box', though, since a little effort with any *BSD will get you to the game point.

      However, having installed all four of them in the past 2 months, I can tell you that FreeBSD is the easiest to get up and running. The FreeBSD installer, and all it's well-documented problems, is still much better than the install process for OpenBSD or NetBSD. I would
      • This is really 'more secure out-of-box', though, since a little effort with any *BSD will get you to the game point.

        Which of the other BSD's has gone all out nuts with active protection mechanisms? None to the point of OpenBSD.

        W^X, Propolice, Stackghost, priv sep, priv revocation, etc etc etc...

        Not to mention the passive efforts such as the audits and wholesale migrations away from potentially dangerous code.

        Sure it might not be perfect (what is?), but I don't see how anyone can claim that any other BS
        • > W^X, Propolice, Stackghost, priv sep, priv revocation, etc etc etc...

          How about MAC and ACLs?

          privilege seperation is a technique that can be employed on any Unix and is nowhere OpenBSD specific, their developers do use it where they can tho it seems.
          • privilege seperation is a technique that can be employed on any Unix and is nowhere OpenBSD specific, their developers do use it where they can tho it seems.

            Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh. But after a lot of effort, they did it. So there is a huge gap between "can be" and "is".

            As I've said before, OpenBSD is not perfect (what is?). But it is still one of the best choices for security and conti
            • > Yes but priv sep requires code changes for each privilege seperated application. Some apps are particularly difficult to do this with, like ssh. But after a lot of effort, they did it. So there is a huge gap between "can be" and "is".

              The openssh team did a good job there, but openssh is far from OpenBSD exclusive. Privilege seperation is available for at least each unix like platform on which openssh runs.

              There is quite some overlap between the OpenBSD and OpenSSH teams, but as said, this is nowhere
              • In other words, this is a good reason to use openssh, but in itself not an argument for (or against) OpenBSD.

                An operating system is more than just a kernel.

                It was OpenBSD developers who developed OpenSSH and added priv sep functionality. OpenSSH is just one example of priv sep work done and ready to use in default OpenBSD installs and they continue to work in that area and many other security enhancing areas. That's my point. That they cover many areas with a focus on security and we now all have priv se
                • > This is a single example application out of many, using a single example security mechanism out of many, which has been developed (the code, not the concept) on and primarily for OpenBSD by OpenBSD developers.

                  And they did a good job there as I said already. However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have. Often those are Kernel level mechanisms that go beyond the basic Unix concept.

                  At any rate, as I have said elsewhere already,
                  • However, there are also other platforms which implement security mechanisms, and at times ones that OpenBSD does not have.

                    I wouldn't deny that.

                    My point has been that there are many active security mechanisms built into OpenBSD, which take it beyond what is just easily configurable on other BSD's. Privilege Seperation work is one small part of the whole and it is very far from the strongest example. W^X, Propolice and Stackghost (sparc) are transparent, effective and cheap on system resources and come as
                    • > But it seems to have the highest strength for general internet facing duties and is beyond taking another BSD and just adding a little extra effort to security.

                      And this is exactly where we seem to disagree.

                      In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team. They do a lot of good work, and if what I need happens to be within their area of focus, I will often use their work, but there are many more situations where OpenBSD simply does not offer the fu
                    • ...strength for general internet facing duties...

                      In my opinion, that is only true if what you need happens to fall within the focus of the OpenBSD team.

                      By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mec
                    • > By those general duties, I am refering to the usual suspects: DNS, FTP, HTTP, POP3, SMTP, etc. W^X, Propolice and Stackghost tackle some pretty generic security problems which can plague these services and are responsible for a large percentage of successful attacks. However these are not the only services that OpenBSD supports and the active security mechanisms work regardless of the application being protected.

                      Absolutely, and those features are extremely usefull to tackle specific classes of attacks
                    • Absolutely, and those features are extremely usefull to tackle specific classes of attacks.

                      Yes specific classes, however very often exploited attacks.

                      Quite a few security breaches result from simple misconfigurations, and none of the mentioned mechanisms does much to prevent those while of course they do help prevent exploitation of a whole bunch of possible bugs that can result in privilege escalation, so there is a level of containment there.

                      I'm not talking about user mess ups though. I'm talking ab
                    • Systems like FreeBSD and SOlaris (at least on specific hardware) allow for going quite a bit beyond a chroot. Please look into it soemtime

                      I didn't say OpenBSD was the best solution for this. You seem to be getting defensive now and reading way more into what I am writing. I am showing solutions which OpenBSD provides, without any claim of comparitive effectiveness. It's not like I came in and said Solaris containers or DSD are a waste of time since OpenBSD has chroot!

                      I find it pretty amusing that I'm bei

    • Re:BSD? (Score:2, Insightful)

      by Anonymous Coward
      'About the only thing keeping me from playing with BSD is the lack of a single "entry point".'

      So you're saying that out of the 200+ Linux distributions you can find an easy entry point, but with the 3 BSD OSs (DragonFly is for developers for now) you can't make up your mind?

    • FreeBSD (Re:BSD?) (Score:3, Informative)

      by argent ( 18001 )
      FreeBSD is the most polished and user-friendly BSD for your x86 box, by far.

    • Re:BSD? (Score:5, Informative)

      by onetruedabe ( 116148 ) on Monday April 11, 2005 @05:50PM (#12205799) Homepage
      The common mantra has always been:

      For security, choose OpenBSD.
      For portability, choose NetBSD.
      For usability, choose FreeBSD.

      About the only thing keeping me from playing with BSD is the lack of a single "entry point".

      That's also the biggest strength -- different (*cough*) "distros" have different strengths and weaknesses. (You said it yourself, Linux has become "beige".)

      If you want to breathe new life into an old Alpha you picked up online, NetBSD is the way to go. (Or if you have a handful of different architectures you would like to keep synced to a common source tree.)

      If you want a lean, mean, server machine, you should opt for OpenBSD. [My preference.]

      If you're looking to build a box to use on your desktop and start "fiddling" with, go with FreeBSD -- this is the likely first choice for 80% of the BSD population, and it sounds like what you're looking for.

      (My other criteria is "If you need to run X, run FreeBSD" because it supports the most graphics cards & monitors.)
    • honestly if you want the easiest newbie freindly BSD then get yourself a mac mini or an old imac with OS X.
      Other than that FreeBSD or one of the live cds
      http://www.freesbie.org/ or livecd.sourceforge.net(not sure how far along this one is) Though they are nowhere near as **newbie-freindly** as OS X .

    • OpenBSD (Score:3, Interesting)

      by ArbitraryConstant ( 763964 )
      This is my personal opinion, the biggest problem I had with other BSDs was the way they didn't fit with the way I prefer to do things. People with different preferences can easily have similar needs and come to different conclusions.

      OpenBSD's goal is security, but as a side effect it's very easy to set up (eg hard to screw up and have an insecure configuration), and there are very few bugs compared to FreeBSD.

      You don't tweak the kernel because the default one has almost everything that is supported. It ma
      • > You don't tweak the kernel because the default one has almost everything that is supported. It makes the kernel bigger than it might otherwise need to be, but if you've got more than 16 mb of memory it doesn't matter.

        If you are security consious, you should always be trying to only have those things installed and in memory that you need. Less code == les vulnerabilities, that even holds on OpenBSD.
    • If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?

      I moved to OpenBSD full time years ago after I discovered the high quality documentation (the man pages mostly). Sometimes when I need to use something other than OpenBSD I am reminded of how great their doco really is. Now there are also lots of great quality dead tree books too.

      OpenBSD-specific books [openbsd.org]

      For learning, I think good quality texts as a guide
  • Although it still looks a bit like it's playing catch-up with Linux (I'd swear they had a SACK implementation already) it's quite nice to have an alternative.

    This is probably the best BSD out there performance-wise however, and I wouldn't be surprised if it begins to usurp OpenBSD server space in performance-critical installations soon.

  • Does anyone have any metrics (Score:5, Interesting)

    by Timesprout ( 579035 ) on Monday April 11, 2005 @05:05PM (#12205344)
    for the performance differential between DragonFly and the regular FreeBSDs ?

  • I have to hand it to BSD (Score:5, Funny)

    by Anonymous Coward on Monday April 11, 2005 @05:05PM (#12205345)
    It outlived the Pope.

  • Curius about SMP (Score:5, Interesting)

    by thanasakis ( 225405 ) on Monday April 11, 2005 @05:23PM (#12205523)
    It was my impression that one of the reasons for FreeBSD-5.x was to rearchitecture several parts of the kernel for better SMP support. I know, I know, there were problems but it seems that it had to be done, and the sooner the better.

    Now, if DragonFlyBSD continues down the road that was set by the 4.x train, what is going to be done about multiprocessor systems? I mean, multicore processors are right around the corner and other OS's (besides the BSD's I mean) like Linux are getting better and better(I won't even bother to mention Solaris).

    I do not profess to be some kind of expert, anyone has anything informative to say about DragonFly's plans on this?

  • What exactly is the reason (Score:3, Insightful)

    by iamdrscience ( 541136 ) on Monday April 11, 2005 @05:33PM (#12205631) Homepage
    I was excited when I heard a while ago about a new BSD variant because there are areas where BSD isn't specifically tuned to. However, Dragonfly BSD doesn't seem to address any particular deficit of the other BSDs. Every other BSD split has had a mission, OpenBSD to concentrate on security and NetBSD to concentrate on remaining cross-platform portability. What exactly is the reason for Dragonfly BSD?

    • Re:What exactly is the reason (Score:2, Informative)

      by Anonymous Coward
      DragonFlyBSD is just FreeBSD 4 with a bunch of updates and bug fixes, with a saner development model than the FreeBSD "core" team. It builds on all the things that FreeBSD did right and tries to fix the things that it does wrong.

    • Re:What exactly is the reason (Score:4, Interesting)

      by drmerope ( 771119 ) on Monday April 11, 2005 @06:41PM (#12206258)
      DragonflyBSD is aiming to make a name in Single-System-Image distributed computing. Think Plan 9 but an evolutionary move from a well established code + user base (FreeBSD 4).

      On traditional single machine installations, DragonflyBSD is being optimized for batch processing performance. The kernel is being re-architected to handle heterogenous resources. You often hear about per-cpu/per-core on their mailing lists, this is a reference to their desire to respect and avoid the high costs of IPC except when not using IPC and processor migration would itself be a penalty. You also hear a lot about cache-coherency, which is a desire to not thrash the processor caches and attempt to localize information to as few caches as possible.

      If you can do this, then if you have m processors, you have m*per_cpu_cache_size fast memory. Conversely, if you aren't careful you approach having only per_cpu_cache_size of fast memory.

      If it all works out (which is still an if) then you'll have an OS that is performance competitive and scales from one to hundreds of processors. This should rival FreeBSD for the performance title in the end...

    • Re:What exactly is the reason (Score:3, Informative)

      by Anonymous Coward
      > What exactly is the reason for Dragonfly BSD?

      Speed. That used to be FreeBSD's claim to fame, and they're certainly improving, but Dragonfly thinks it can do one better. They also aim for HURD-like flexibility, which will be more of a side effect.

      NetBSD, by the way, isn't just portable, you could print out the kernel source and it would be a textbook. It's all wonderfully commented and very clean code.

    • Dragonfly is designed to make asynchronous communication between hardware resources very very lightweight and scalable. Right now SMP is not really very efficient. All of the locking that goes on to keep one processor from stepping on the other processor's toes ends up making all processors except the one with the lock wait for the lock to be released, for example. The idea is to organize the memory usage so that kind of waiting only happens when it is explicitly necessary.

      Now, all of the sudden, the OS w

  • Not Your Ordinary BSD.. (Score:3, Funny)

    by \\ ( 118555 ) on Monday April 11, 2005 @05:50PM (#12205800) Homepage
    ..features a standards-conformant SACK implementation..

    DragonFlyBSD: The BSD with Balls
  • I posted this [technocrat.net] on Technocrat today, but probably stand to get more answers here:

    I have a lot of respect for Matt Dillon (as does pretty much everyone who's ever owned an Amiga), but I'm not sure yet that this is a good idea. The early versions of FreeBSD-5 were a mess, sure, but they've somehow managed to wrangle the new complexity into something that really works and works well.

    Still, I wish nothing but the best for the whole DragonFly team. If their ideas pan out, then the whole *BSD culture can benefi

    • fbsd5 might be "fixed" somehow these days, but it's still a pretty complex piece of code.

      dfly attempts to remove this complexity (instead of routing around its problems, introducing more complexity), making it easier to work on productive code instead of fighting with thousands of locks.
    • DFly will remain relevant for having a pretty relaxed but surprisingly stable development model. While there were still bugs that kept me from using it as a gateway (and software support problems that kept me from using it as a desktop), it never actually crashed or did anything harmful - it just couldn't route packets the way they should be routed - and nobody replied to my message on bugs@ or the IRC channel. I switched to NetBSD 3.0-beta and the same configs (for PF and inetd) worked. So I stuck with tha

  • DragonFly Notes (Score:5, Informative)

    by m.dillon ( 147925 ) on Monday April 11, 2005 @11:01PM (#12208270) Homepage

    Well, I have to say the slashdot response to this release is a marked improvement over the response to the last release. Most people are actually getting the concepts right this time! Kudos!

    There are a few things I will clarify about the release, in particular about our approach to SMP and the inevitable comparisons against, FreeBSD.

    On the SMP front what we are doing is basically rearchitecting big chunks of the kernel to operate efficiently in both UP and SMP environments, to be NUMA-friendly, and to be as maintainable as possible. Rather then throw mutexes around existing code we are undertaking a huge effort to make as many of our subsystems as mutex-free as possible by localizing the subsystem's operation on a per-cpu basis. Most of the time that means rewriting them from scratch.

    One example of this is our core Light Weight Kernel Thread scheduler (LWKT). Each cpu has its own indepenant LWKT scheduler which means that any given copy of the scheduler itself does not have to deal with or worry about contention between cpus. The code is very, very clean. If you think about it a bit you will realize that such a beast would work just as efficiently in an SMP environment as it would in a UP environment, and that is indeed one of our major goals.

    A second example of this is our network protocol stack (whos major architect is Jeffrey Hsu). A TCP connection goes through a hash and is routed to a tcp protocol handling thread on a particular cpu. If you have N cpus then your TCP connections will generally be split about evenly between the cpus. Any given connection is localized to its cpu which means that all the work related to that connection occurs on a single cpu and thus does not have to worry about or deal with contention between cpus... and operates as efficiently on a UP system as on a SMP system. The L1/L2 cache effects are an important bonus as well but the winning ticket is the ability for the protocol threads to run in a tight loop without needing to obtain or release a single mutex, lock, or other synchronizing mechanism other then the occassional critical section (which is a cpu-localize synchronization mechanism against interrupts).

    Another major goal is to make the code more maintainable... readable, understandable, etc, without any major gotchas to an unwary programmer, especially new programmers who are attracted to the project. This does not mean that FreeBSD is less stable, but I certainly believe that DragonFly's code base is a lot easier to maintain and a lot easier for new programmers to work with, with a much shorter ramp-up time then someone trying to dig into the FreeBSD codebase and far fewer new bugs introduced. I am taking a long-term view here.

    The problem with building an SMP friendly algorithm which requires a lot of synchronization to avoid contention (the mutex model) is that it is really easy to make a mistake and introduce a hard-to-find bug, especially if you are just ramping up on the codebase. The solution is to use algorithms (aka cpu-localization algorithms) that avoid the contention in the first place, and that is what we are doing. Regardless of FreeBSD's current stability (and I believe that FreeBSD is now far more stable then it was a year ago), they had to go and stomp hundreds of bugs introduced by experienced programmers. That's a red flag in my book, one that I am making a major effort to avoid in the DragonFly codebase.

    In less then two years of work (with very little destabilization of the kernel during that period, by the way), we are now within shouting distance of FreeBSD's and Linux's SMP parallelism. The only area where we are still significantly behind is in boot-time interrupt routing. This release is the last release where the Big Giant Lock is going to be in the critical path. We spent a lot of time isolating subsystems in order to reach this point, to be able to now take the last few steps and actually turn the Big Giant Lock *off* on a thread by thread basis. Not only tha

    • Matt, as long as you're around I figure I'll ask you about your license policy; recently there was a spat between Theo de Raadt of OpenBSD and Scott Long of FreeBSD regarding openness and freedom versus functionality.

      How do you stand when it comes to adding binary stuff into your system when you cannot get at the code?

      Theo was very, almost violently, adamant that adding anything there isn't code that the system's developers can see it isn't worth having in the system. While Scott felt that it was better

      • Re:DragonFly Notes (Score:5, Insightful)

        by m.dillon ( 147925 ) on Tuesday April 12, 2005 @12:00AM (#12208666) Homepage

        I don't think it's a good idea to incorporate binary modules not buildable from openly availble source, but I'm not rabid about not using such modules when it makes something work that I need to make work. I have to use NDIS on my laptop to get the wireless working and frankly I'm a very happy guy because it works :-).

        But that doesn't mean I have to like it! I think it's a mistake to try to cow-tow to vendors that clearly don't understand the value open source gives them (specifically, the fact that they don't have to support the drivers themselves). There are many reasons why vendors don't like to give out source. For one thing, chipsets often have a lot of bugs in them that the driver code has to work around and the vendors don't like to reveal the fact that those bugs exist. Another reason is that vendors are often paranoid about their code, even when it is substandard compared to other drivers that might be available as open-source (commercial entities invariably believe that their hired guns can code better then we can, and they are invariably proven wrong when such code occassionally sees the light of day).

        The question is do we want to support the bozo vendors and just perpetuate the problem? Or do we want to focus on supporting vendors that do provide good information on their drivers (or at least don't go nuts when someone reverse engineers it)?

        Another problem with binary-only modules is that, well, they might have bugs which you can't fix because you don't have the source. Or they might rely on API breakages that you would really like to rip out of your system. Or they might not work with a later rev of the chip in question even when the later rev is only an incremental improvement over the previous chip. Or they may not work with a particular configuration that you want to make work. Then you are stuck with a substandard driver that only works on older machines.

        If I were to state a position it would be that the occassional exception might be necessary, but that it just isn't a good idea for the open-source community to rely on vendor-provided binary modules to make hardware work.

        This brings up a far more important question, which is whether it is possible for an open-source 'trust' to be setup for the purposes of maintaining a driver whos source a vendor does not want to be released to the general public. That is, an entity which any open source programmer can join and through the signing of a simple non-invasive license then have access to the source for the purposes of making it work for that vendor's product line on open-source operating systems. The source would not be open to the public, but it would still be under the effective control of whatever open source programmers are interested in working on it. That is something I could live with and I think vendors could live with too if they took the time to think about it.

        -Matt

        • Just a short note on avoiding the problems of drivers relying on API breakage or some given kernel semantics. An alternative approach to supporting such drivers (in source or binary form) is to embed these drivers in a virtual machine [l4ka.org]. Such an approach incurs a little bit of overhead, sure, but you also get the added benefit that the direver need not necessarily be trusted by the rest of the system.
    • > The only area where we are still significantly behind is in boot-time interrupt routing.

      "Boot-time interrupt routing"?

      Can someone explain what this means to me?
      I'm thinking about 'interrupt latency' (Linux has a low latency patch) but I'm not sure if I understand correctly..

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close