Slashdot Mirror
DragonFly BSD Announced
JoshRendlesham writes "Matt Dillon announced today on the freebsd-hackers mailing list the creation of the DragonFly BSD project. It seeks to build on the work of FreeBSD 4.x, including a rewrite of the packaging and distribution system, among other goals."
Brad Pitt announced a new fork from the -AC kernel tree.
This is great news. God knows we need another BSD, I don't think anyone is happy that currently we only have FreeBSD, NetBSD, OpenBSD, TrustedBSD, XMach, Darwin, and Microsoft Windows.
...packages and ports system. They're part of the best things FreeBSD has above Linux right now!
That doesn't make sense to me. Thats like deciding there are too many car manufacturers and complaining to Ford that there should be fewer and better car manufacturers. In fact, it would be EASIER to do this in the car industry because you can probably get the major car manufacturers together. No one ever said this new BSD was going to be good, just that it was here. No one said you should support it, but then again maybe you should. Each distro of anything is subject to the people that make it. If you want one final all encompassing sent-from-God BSD then go and make it!
I'd like to see Gentoo's Portage move onto BSD, it was originally inspired by the BSD ports system, but has become very easy to use and refined. It's time for a BSD to try out Portage (Mac OS X is geting Portage soon!)
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
I find this project exciting. Having tried gentoo's portage it has become clear to me that ports could be a lot better. While ports does work, it has a bunch of tools which make its use easier which arent included by default and could be integrated into ports.
Oh well, it's probably about hurt egos again. :(
In a way it is. Matt Dillon got lost commit access to cvs a while ago because he was trying to get some stuff into 4.8 and got rebuffed. Looked like he violated their code of conduct a few too many times, got kicked out, and started a project where he made the rules. TdR in the house?
Matt Dillon's early background as an Amiga programmer is really showing through here. He's basically proposing doing a piecewise conversion of BSD to an Amiga-style message-passing operating system.
He's basically doing the reverse of what so many folks (NeXT, HURD) have done or tried to do.. not taking a microkernal and putting a UNIX layer over it, but taking a UNIX and scooping out the inside to replace it with a message-passing microkernal.
This will definitely be a fun one to watch. Go, Matt, go.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
My first reaction was "oh, forking is bad, we don't need another". But in truth, this is no more remarkable than the fact that there are 100s if not 1000s of different flavors of GNU/Linux.
So there.
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
-Matt
Anonymous Howard, who made a career of proclaiming the demise of the *BSD Operating Systems, was found dead at his keyboard this afternoon. He had just turned 16. An unnamed police spokeswoman said it was an apparent case of "autoerotic asphyxiation gone haywire". [You know the rest of the story.]
Having NetBSD/FreeBSD seperate was good in many ways because it kept mutually incompatable folks away from each others throats. Once things cooled down, technology began to flow in both directions between NetBSD and FreeBSD. Later on, OpenBSD came along. All sorts of good things came from that. Can you say OpenSSH?
It would be nice if DragonFlyBSD (gah, ENAMETOOLONG) was a similar deal. As a FreeBSD developer, I hope that there will be plenty of opportunities to take good stuff in both directions. If we can keep people away from each others throats and work on making the code better, then everybody wins.
Diversity is good. Developers fighting each other is bad. Forks can be a good way to relieve the stress. There is no need to make a Big Deal(TM) about it.
Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.
It's more than just replacing ports with portage, or apt-get, or some other userspace packaging system.
What they're talking about doing is having kernel support for packaging. Multiple versions of the same library could be installed with the same filename simultaneously. An application would see the correct versions of the things it needs, and it would see only the things it needs, despite what else might be installed. This is to allow for piecemeal/partial upgrades among other things.
To which I say: HALLELUJAH BROTHER!
This is exactly what I've been wanting to graft onto Linux for some time now; my latest thinking is that it could be done with a userspace filesystem (to make files visible/invisible), extended attributes (to associate the visibility contexts with application binaries), and a bit of extra process state. If the DragonFlyBSD folks make it work, it'll be intrestesting to see how this behaves from an administrative point of view.
In any case, this is not just a userspace change. This involves the kernel itself.
Technically its not a job but they refuse all his patches and he lost write access. The chances now of it being merged into FreeBSD are remote.
He had no choice but to fork if he wanted to continue developing. That or join the Openbsd team or Linux.
Infact Dillion help fixed the vm bug in Linux 2.4. He actually has already developed Linux code.
http://saveie6.com/
Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.
To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.
Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.
The problem with the GPL is that it doesn't trust its fate to human nature but instead tries to force an effect that tends to be against human nature. GPL is a license based on fear and uncertainty, at least from an idealogical standpoing. The BSD license recognizes human nature and works with it to far greater effect for the society as a whole. I prefer trust to fear. I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it. That is the reality of the GPL. I use it occassionally, but for commercial reasons only. Everything else I do under the BSD.
-Matt