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."
I've used DragonFly to build some appliances for remote network monitoring, like having something as solid as FreeBSD 4.x from which it was forked but with ability to compile latest BSD packages and small footprint. I've kind of lost faith in FreeBSD after 5.x and 6.x shakiness under high load, maybe they've fixed it.
That said, I've yet to use Hammer and wonder if/when it's production stable like some of the other parts.
devfs? and the next release will switch to udev presumably?
Additionally it will be called 'Dreamy DragonFly,' and feature a suspiciously familiar-looking brown GNOME theme....
My blog
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'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.
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,
Isn't it funny that at the very moment there is a discussion about including devtmpfs into the Linux kernel to get rid of udev?
Because Linux is just a kernel, it is rather trivial to take Linux, bolt on some programs, and call it a "new distribution." The design philosophy of Linux enables and encourages this kind of behavior.
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.
Here you go, it seems they do a lot of work with multiprocessor systems clustered environments and the like.
http://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems
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
Most people commenting here are not clearly aware why there is DragonFly BSD, how it is different from the other BSD/etc.
In my view, DragonFly BSD is unique, timely and exceptionally forward thinking system.
You can see these days somewhat incoherent approaches to scalability in Google MapReduce, Apache Hadoop, etc -- basically rewritting existing technologies such that with less functionality and new code the processing can be scaled
across multiple computers at the same time.
Commercial offerings such as TerraData and Netezza have been doing parallel clusters for Data mining for years and built I guess profitable business around it. Then Google hypes MapReduce, and then Hadoop project (and the small companies) around Hadoop startup to be the 'next-best-thing' for cloud computing.
Of course MPI library (allowing applications to share data across multiple computers) have been available for long time.
However all of theses things above, force a complete rewrite (or a major rewrite) of the application or paying gazzillions
of dollars to TerraData/Netezza if you have 'Database-like' processing needs
I think that the job of process scheduling/priorotirzation/caching/memory sharing across multiple machines
is a job of an operating system.
That is exactly what Dragon Fly's ultimate goal is (with its file system and kernel design).
http://www.informit.com/articles/article.aspx?p=766375&seqNum=2
There will be time, hopefully soon. When I can configure 4 Dragon Fly machine to be presented as SSI,
install on that image postgres (or MySQL if it is still around), apache (or lighthttpd) -- and have
a endlessly scalable system that I can just add more inexpensive computers to increase performance.
I do not have rewrite anything, use obscure libraries and tools -- instead I just keep programming my C++/PHP/Java stuff
accessing databases when I need to, service web requests, open up files -- all being managed by the OS designed for this.
Linux is used in some projects to achieve SSI (Single System Image)
http://www.linuxlabs.com/nimbus.shtml
http://www.kerrighed.org/wiki/index.php/Main_Page
but nothing at the scale and deepness of the architecture as Dragon Fly BSD.
..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.
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.