Slashdot Mirror
DragonFlyBSD 1.2 Released
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."
It's my understanding that this is currently on-par with FreeBSD 4.x (which I believe is faster than 5.x). The real performance imporvements are (supposedly) to come after everything has been ported over to use the messaging infrastructure (mainly the buffer cache). If the design holds true to its promise, then it should be a good step faster than FreeBSD 4.x in a few years. Especially in the area of SMP.
"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...
Life is hard, and the world is cruel
I'm using DragonFlyBSD as my desktop without problems.i ve/users/200 5-01/msg00045.html
f f
i al/port s-packages-libc.so.5-gcc34/All/
:)
You still need the libmap patch for flash, because they think it's too dirty to integrate.
http://leaf.dragonflybsd.org/mailarch
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.di
Packages for use with the citrus patch are availble here:
http://ftp.fortunaty.net/DragonFly/inoffic
If you use gcc34 packages/world everything is compiled with stack protector.
It's also very snappy
Wow, that's my weblog :)
That entry is pretty old, and the situation is hardly the same. As of today, FreeBSD 5.4 (soon to be out) performs much better than the previous releases, but for UP machines NetBSD 2.0 or DragonFlyBSD are IMHO better choices.
I run FreeBSD 5.4 on a SMP box and it's much better than it used to be. If/When I can allot some time I'll do some benchmarking of FreeBSD 5.4 vs DragonFlyBSD 1.2 on my dual PIII.
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.)
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