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.
Oh no! Who will pay the administrators the big bucks now?
There are two kinds of egotists: 1) Those who admit it 2) The rest of us
Dragonfly BSD is dying...
--Life may have no meaning, or, even worse, it may have a meaning of which you disapprove.
...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!
POW!
All the various BSDs share code when one solution seems to fit more than just the distribution that developed it. If DragonFly is going to focus on something that the other four aren't, then more power to them. I'm sure the others will adopt any good ideas that come out.
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.
Are they talking about replacing the ports system? I thought that that was one of those most revered parts of the original FreeBSD
What were they thinking when they named their project after a bug?
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?
The problem with BSD is that there are too many Albert Einstein-like people involved with its development... and Matt Dillion is one of them. I don't mean that in a bad way. These guy are *smart* probably one in a billion kind of smart. The problem with that is they can't work together very well. Theo (Open BSD), Matt (FreeBSD) Both these guys forked over differences of opinion with other developers.
Imagine what these guys could actually *do* if they put aside their differences and worked together!! No unsolved CS problem would be safe.
Dragonflies live longer than 24 hours. See the British Dragonfly Society FAQ.
This isn't the actor, it's the lawman. Jeez, Slashdotters are so ignorant!
Wow. Matt Dillon. :) There's a name that brings back memories.
:)
Matt: if you're reading this, I loved DICE, and all your other work on the Amiga - your compiler is one of the reasons I'm a programmer today. I hadn't been keeping up with your work but it's good to see you're still out there doing stuff.
(seems a lot of the old Amiga 'big names' have gone on to do interesting stuff in the time since)
(Spudley Strikes Again!)
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
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.
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.
- Not Theo, but not Bill either
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