It is nice, and quite usable, it features a good-looking installer. It uses NetBSD's pkgsrc, and you can have some 6,400 binary packages too.

Almost unchanged from the RC1, DragonFly BSD 1.10 was released, and a very interesting interview with Matthew Dillon raised some discussions.

It's good to know that the "new ATA" driver from FreeBSD was ported, but Matthew Dillon seemed quite evasive on anything unrelated to the final goal, a highly available clustering filesystem (which would be great, but obviously not for the desktop users), and the Syslink protocol.

What bugs me the most is some old news I didn't know about: it appears that DragonFly performs very poorly in the SMP department, and Matthew is very much aware of the "big giant lock".

To me, it looks like DragonFly BSD benefits from both NetBSD and FreeBSD, whereas following its goals. The supported hardware is severely limited (i386), and some newer computers might fail to work due to ACPI issues, however I like small, independent projects (and you can at least try the CD because it's a live one, and the installer should work even for blondes).

I'll most likely try DragonFly BSD 1.10 some time soon on the same hardware used for testing 1.8.1, just for my curiosity (and waiting for NetBSD 4.0 to be released, if ever; BTW, OpenBSD 4.2 turned beta two weeks ago).

My question is: will DragonFly be a "pet/hobby/tiny_niche BSD" for the two years to come, until it will prove its utility into clustering? If it currently has issues even with symmetrical multi-processing...

Boy, I am bored of all the political stuff in Linux. Everything is getting too political nowadays. OK, I will pamper myself with Matt's opinions on the BSD license vs. GPL:

How important to you is it that your code is released under the BSD license? Unbelievably important. I have never subscribed to the almost religious fervor surrounding the GPL, in particular I do not like the idea of trying to impose the concept of freedom on people by attaching strings. The GPL has created a misguided sense of self importance in the open source world. Simply getting openly specified software and algorithms into the mainstream has a far larger effect then any license. BSD conforms more to the concept of pure invention. More importantly, in large collaborative projects the BSD license allows the individual authors to use both the project as a whole and bits and pieces of collaborative work they have contributed to no matter where their life takes them, including into commercial settings and even proprietary commercial settings. BSD is a way of saying that we are not so greedy that we have to hog-tie anyone else who wants to use and profit from our work. Or, in another sense, BSD is a way of confirming that actually making money from an open-source project is a very rare event and some of us aren't really interested in that aspect of the work. Frankly it is not so easy to 'steal' open source projects as people seem to think. The BSD license acknowledges this fact while also acknowledging and even supporting both commercial use and the occasional commercial proprietization of project code. In a sense, it doesn't really matter whether code is proprietized or not because short of rewriting it completely any commercial success (take Apple's use of BSD and Mach for example) will inherently force that commercial entity into the use of a great deal of openly specified protocols. Just because they can add little proprietary bits and pieces here and there does not change the fact that 95% of their work base will not be proprietary, so the goal of forcing the world into using more open standards, something I *DO* want, is achieved just as well with BSD as it is with GPL. It is really unfortunate that the fanatics don't realize this. They hold up few and far-between examples of so-called 'stealing' and the so-called protection that the GPL affords against such 'stealing' without any real understanding of what is actually accomplished. There is very little difference between the concept of 'integration' and the concept of 'stealing' in the open-source world. They are more like shades of grey. If I were to write a large proprietary commercial application that happens to run on Linux (and many such examples exist), the integrated result is for all intents and purposes a black box, GPL or not. [...]
MySQL is a good example. As people have realized, just because the base code is free doesn't mean that anyone can continue to maintain and develop it. [...]

P.S.: Some friends might still be insisting that Linux has a much broader audience than *BSD because of the "moral and practical superiority" of the GPL. Sure thing, Karl Stallman and Friedrich Moglen have made a great fuss with their revolutionary statements, including The dotCommunist Manifesto and Anarchism Triumphant, but Linux is where it is because some corporations have seized the opportunity to head its development in the direction of their choice!

No, it's not about Red Hat, Mandriva, Novell, Canonical. It's about IBM, Intel, Hewlett-Packard, Oracle and the like -- those who have paid kernel developers to commit changes that were supposed to be serving their corporate interest. This way, Linux lacks independence, and the direction of its development can't be influenced very much by the public.

The "community" part of any Linux distro only applies to exactly that part of it: the userland software that is added to the kernel to form a distribution. The kernel itself has a restricted team (remember how Ingo's scheduler was preferred to CK's "amateur" implementation?), and the "democracy" part does not apply there.

BSD flavors have forked for several times already. The Linux kernel has never forked as of yet. Why is that so? Because it's by no means easy to gather a team to take care of such a huge code base. Once, again, it's not because it's under GPL...

In the meantime, hundreds of Linux distros are made up out of sand by bazillions of fanboys, but none of them has the slightest influence on where is the Linux kernel headed.

UPDATE: Matt Dillon tried to clarify the situation for the SMP (which «isn't on my priority list but that shouldn't stop anyone who wants to work on it»). An even more interesting message treats the current status of the project and its (non-)relation with FreeBSD-4. The whole issue can also be read in a so-called Mini-interview with Matt Dillon.

RE-UPDATE: Simon 'corecode' Schubert wrote that the SMP code is «nonexistant in the common kernel code path, except for the network threads. everybody knows this. ... if I like indenting all code and comments in the project more than doing MP work, so what? my time. my thing.»

1.10.1 IMMINENT! There is a mbuf leak in kernel, and Matt has found the bug: «This bug is pretty serious and will require 1.10.1 to be rolled this weekend.»