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 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