Slashdot Mirror
DragonFly 2.4 Released
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."
Mac OS X doesn't count as a BSD?
No. Mac OS X doesn't use a *BSD-derived kernel and is therefore not a *BSD. Mac OS X's kernel is called 'XNU' and it's based on Mach 3.0. It does have a BSD subsystem in the kernel, and the userland is a mix of BSD and GNU utilities, but it's not *BSD. (The BSD subsystem itself is derived from FreeBSD 5.x.) I guess you could say Mac OS X has stuff that is derived from BSD, but on whole I'd have to say OS X is something other than BSD.
My blog
I've never experienced "shakiness" under high load on 6.x, but 7.x saw the introduction of a much improved SMP, and a new scheduler which saw dramatic performance increases under many usage types.
Early 5.x was a bit flaky, though it was fairly stable by the end of the line. 6.x was late in coming though, so many were eager to migrate. 5.x is in many ways too old to be a valid comparison anymore though, as I don't see many complaints about linux kernel 2.4.x even though they had their own set of issues. Every OS I've ever used has had it's own sets of gotchas, but stability on BSD has never been one with proper planning.
brandelf -t FreeBSD
HAMMER is considered production-stable now. It was usable a year ago and what few bugs existed were found and fixed since then. Performance is much improved though we are still not happy with small file lookups, and fsyncs are still quite costly, but there isn't much we can do about it without some major on-media changes and those will probably not be made until after the cluster work ramps up. In anycase, HAMMER has been the default filesystem for a while. There is really no other choice for DragonFly (just as ZFS is the only real choice for FreeBSD) when it comes to dealing with today's huge drives. UFS (and UFS2) don't cut it.
-Matt
that fourth major BSD â" has had its 2.4 release
Six more BSDs and they will officially go from "mindless roving undead" to "collectively intelligent zombie horde."
Trolling is a art,
BSD distributions tend to be full vertical integrations. Linux distros tend to be horizontal integrations. There are, in fact, dozens of linux distros in various states of repair or disrepair. It's very easy for anyone to slap stuff together and call it a linux distro. It isn't so easy to slap together a BSD system and call IT a distro.
The various BSDs focus on different things though they do try to stay within shouting distance of each other. FreeBSD focuses on performance, OpenBSD on security, NetBSD on portability, and DragonFly focuses on a lofty filesystem clustering & SSI goal.
The HAMMER filesystem is a major stepping stone towards that goal. There is really no reason to use DragonFly if you do not also intend to use HAMMER, so it is probably lost on people who expect a pretty GUI and just want to play with DragonFly a little in a VirtualBox or VMWare or other VM with a tiny little virtual disk (VirtualBox doesn't even implement proper disk synchronization!). Real DragonFly consumers use it primarily for the filesystem, secondarily for the stability, and are willing to spend the extra time tuning the typical server applications that any UNIX-like OS can run in the mean time.
The differentiation here is that while something like ZFS focuses on redundancy, it does so using a monolithic filesystem model which is still vulnerable to software failures. HAMMER is designed to evolve into the core for DragonFly's clustering goals... HAMMER does not focus on individual filesystem redundancy but instead focuses on the components that will be needed to make the future multi-master clustering work efficiently. This also means that HAMMER must be rock solid and essentially bug free, which is a major task unto itself.
Thus HAMMER's mirroring components are designed to support live streaming replication (with near real-time backups being a convenient side effect) at the logical layer (HAMMER's B-Tree) as well as designed to become the bulk data transport component for the future clustering. This is very different from the discrete snapshots which numerous other filesystems support, and also very different from the traditional block-level mirroring slap-on model used to implement (for example) numerous Linux redundancy solutions.
In order to realize this multi-year goal we still need to provide what is basically a complete system solution in the mean time, otherwise there simply would not be enough users to keep the system well tested. And, unfortunately, keeping all the other components of a major distribution up-to-date take a huge amount of time just by themselves, but there's really no other way to do it. Politics make it virtually impossible to make the necessary changes to core OS structural mechanics required for the goal using someone else's distribution, so we have our own.
I've been around enough to know that no software lasts forever. Algorithms survive the test of time, but actual software typically does not. Small monolithic programs tend to survive the test of time too, simply because they are easier to port. A great deal of the linux infrastructure today is not small or monolithic and while it provides a very valuable service to its users it is also extremely vulnerable to obsolescence. If a linux distro dies all the work that went into it also tends to disappear. If a BSD distro dies the components are at least small and compact enough to survive in other forms. So in that respect the point of doing it should be obvious.
-Matt
..why there are so many BSD variants while the linux kernel only has one?
Because BSDs are operating systems and linux is just a kernel. If you look at distrowatch, you will realise that there are HUNDREDS of Linux distributions.