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 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.
DragonFly is rearchitecting for SMP, just in a different way than FreeBSD 5.x.
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?
'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?
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, especially on multiprocessor systems, will generally be quite better. NetBSD has always had its primary focus on portability, whereas FreeBSD's has been primarily on performance. Microbenchmarks indicate, if anything, that FreeBSD has chosen higher overhead implementations which increase overall performance, whereas NetBSD has implementations whose simplicity incurs lower overhead on microbenchmarks.
Firefly has taken a radically different approach and is attempting to refactor a BSD kernel into a more microkernel-like operating system. So while FreeBSD decided to take the SunOS/Solaris-like approach, DragonFly has gone the way of Mach. This is a rather fundamental design schism, and is more indicative that microkernel concepts are still quite valid than any kind of mass disillusionment over FreeBSD 5.x. I think it's great that they're introducing microkernel concepts to a stable and mature POSIX compatible OS rather than starting from scratch, but sadly I think DragonFly will be an OS that has trouble finding its niche.
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 things.
"When in doubt, use brute force." Ken Thompson
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.
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