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."
FreeBSD, for sure.
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
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.
OpenBSD, definitely, since you're running it on a router/gateway.
ROMANES EUNT DOMUS
I don't know what the heck you've been reading, but performance has never been one of OpenBSD's strong points as compared to Linux and the various other BSD's.
Free will is just an illusion
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
does this help?
- Teja
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
I don't think it's a big problem.
I started out with OpenBSD a year ago with basically zero *nix knowledge and didn't think it was very hard.
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.
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.
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.
It's partly that you don't want a router cracked and partly cause you want the best packet handler, pf is that.
Plus you can set it up as your mail relay and stop spam, and yadda, yadda, yadda... It's a generally nice small system and the ports with it almost all run without fuss.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
FreeBSD is the most polished and user-friendly BSD for your x86 box, by far.
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.)
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.
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-source person will not be missing a lot on their ports tree. Only if you need unsual software (unusual in terms of the average Unixhead), like some Common Lisp compilers, or cutting-edge programming languages (Alice, Oz, Mercury, etc) you will miss stuff in the ports tree. You can even install Java (you might miss Mono - but probably nobody's given a serious try at compiling Mono on OpenBSD (*)) But this is not your Linux-kid OS that wants a M$ replacement.
Please remember BSD has a long history of Unix development. It doesn't have the money that Linux currently is attracting from the suits, but please take an unbiased view: look at the security record of any BSD and compare with *this year's* Linux kernel exploits (25, IIRC). However, people have different needs (some want Java, some want security, some want performance, others have different different hardware and need portability, others need to work on a supercomputer - whatever), so that has to be taken into account. My point is: all this is Unix. And that's a Good Thing.
(*) A whole different problem, that seems to be growing, is people writing software full of Linuxisms, instead of writing stuff for *UNIX*, in which case it should be portable. This has been a cause of trouble for some programs, for me at least.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
> 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.
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
I'm aware of kqueue, but although it provides an I/O completion type mechanism, I believe the difference is, under the NT kernel and a couple other IOCP implementations, threads which are attached to an IOCP are put into a special scheduler which only activates N cpu threads at once, letting a thread run until it blocks again on I/O. Because threads attached to IOCPs are typically I/O bound, this leads to an excellent reduction of useless context switching, allowing longer bursts of execution between I/O events. Any type of blocking, be it sleep, waiting for events/handles, synchronous I/O operations, etc, will dequeue another thread from the runnable queue. The goal being to keep exactly N cpu threads from the IOCP program in the running state at all times (eliminating thread contention between threads in the same IOCP program). This also provides more optimal locking paths, because only N cpu threads are running at once, it is more likely that locks (critical sections) will be immediately available, and that the locks will be released before the context switch. This allows for maximum multi-threaded performance for I/O based systems, especially on SMP systems.
There's a little more to it than just queueing I/O requests.