DragonFly 2.4 Released 73
electrostaticcarrot writes "DragonFly — that fourth major BSD — has had its 2.4 release. The 'most invasive change' is the addition and usage of a DevFS for /dev; building on this, drives are now also recognized by serial number (along with /etc/devtab for aliases) as listed in /dev/serno. This is also the first release with a x86-64 ISO, stable but with limited pkgsrc support. Other larger changes include a ported and feature-extended (with full hotplug and port multiplier support) AHCI driver (and SILI driver based on it) originally taken from OpenBSD, major NFS changes, and HAMMER updates. A pkgsrc GIT mirror has also been set up and put in use to make future pkgsrc updates quicker and smoother. Here are two of the mirrors."
How close are we coming to blending Linux and BSD? (Score:3, Interesting)
I'm not up on the beastie's progress these days, but reading about the /dev filesystem reminds me of the penguin. Does this bring them closer together? Are things coming closer together in other ways as well?
I think it would be phenomenal to be able to select between Ubuntu Linux and Ubuntu BSD, for example.
Re:Can someone enlighten me why (Score:2, Interesting)
The major BSD systems (FreeBSD*, NetBSD, OpenBSD, and DragonflyBSD) have all been carefully designed from the original 386BSD codebase. Originally, there were just FreeBSD and NetBSD, based off of the 386BSD codebase. Developer conflicts within NetBSD caused a split, spawning OpenBSD. A similar thing happened in FreeBSD, spawning DragonflyBSD. I will not go into details as you can research that for yourself, but this is how we got from 386BSD to where we are now. Keep in mind that there was a rather large uproar in the NetBSD community before OpenBSD was created; it was certainly not done on a whim.
Most *BSD developers believe their time is better spent working on new problems than re-inventing old problems. Why take 10 developers and spread them out, all to work on their own version of X when together they could collectively build X, Y, and Z. This is not always the case (see the NetBSD conflict which spawned OpenBSD), but for the most part this is the reason you do not see hundreds of *BSD variants.
As I said earlier, it is relatively easy to bolt together your own Linux distribution. In fact, something like LFS can have a complete novice building his own "distribution" in a very short time span. Basically, anyone can make their own distro. What about *BSD? Could a complete novice take FreeBSD, fork it, and make his own JoeBSD variant? Yes, but he wouldn't get very far. Unless he knew what he was doing and had a good knowledge of the code, most of the *BSD crowd would simply ignore his efforts. Not because they're mean, coldhearted, etc., but because they aren't going to waste time on JoeBSD when it is a fork of FreeBSD, which still works perfectly fine.
If JoeBSD brought something genuinely new to the table, people would support it. If JoeBSD was just a copy of FreeBSD with a different package manager, people would ignore it. *I did not include DesktopBSD or PCBSD because they are not separate derivatives, they are FreeBSD with easy-to-use installers and pre-configurations. Think Ubuntu and Xubuntu.
Re:Can someone enlighten me why (Score:3, Interesting)
If you tell me I can do what ever the hell I want to with your code when I work on it I'm more apt to work on code than if you tell me I have to follow your rules when I use it.
Maybe *you* would be more likely to work on the code, but that's not very relevant. Most of the heavy lifting in Linux kernel development is done by corporations.
If you analyze the situation with some basic game theory, it's clear that corporations are unlikely to publicly license the source to any of their significant development efforts unless GPL-style restrictions go along with it. They don't want their competitors taking their hard work and going proprietary with it. (I'm talking about writing new code as open source here. This doesn't count the common case of companies dumping unprofitable proprietary products into unrestrictive open source licenses, often in a last-ditch attempt to devalue their competitors' proprietary products. (See Sun Microsystems.))
This may be why the Linux kernel is less likely to fork. All of the big players are in the same boat, and they enjoy a network effect by sticking together and adding all the improvements to the same codebase. Having to sync improvements between multiple forks (even if they were all GPLd) would add significant overhead to the process. Thus the big contributors would tend to shun any fork.