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."
for the performance differential between DragonFly and the regular FreeBSDs ?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
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.
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?
Microkernel-like because they're going to a messaging / IPC based system instead of traditional syscall implementation maybe?
I support both DragonFly and FreeBSD. As an admin, I need FreeBSD to step up to the plate and offer scalable SMP support because I run 100% SMP boxes. I am willing to wait for FreeBSD 5.x to clean up and show the performance benefits.
However, I am highly interested in Matt's work on DragonFly because in my opinion, most of the popular "*nix" variants today stick too closely to the vanilla unix design which is why our socket code still uses select() and most I/O is done synchronously. I hope Matt expands his work to include super-scalable I/O systems like I/O Completion Ports. I heard there are Linux developers working on IOCP right now, so I'm hoping eventually this spawns a similar BSD effort.
DragonFly will probably work very nicely with multi-core systems down the road. I believe in the long run NetBSD will continue to destroy FreeBSD 5.x in single CPU benchmarks.
But there's the catch...
How many multi-core processors have to roll off the production line for everyone to realize that all of this anti-FreeBSD naysaying is going to turn into a huge crow eating contest because when everything is dual or quad core down the road and FreeBSD scales nicely to match, nobody will give a god damn that NetBSD is faster on a single CPU system.