DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. Prominent former FreeBSD developer Matthew Dillon is a major player in the development. According to the website, DragonFly gives “the BSD base an opportunity to grow in entirely new direction from the one taken in the FreeBSD-5 series.”
FreeBSD 4.x Forked Into DragonFly
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
is this new direction?
Well, apparently you didn’t even bother to check the website. I mean, I don’t care much about BSD and yet another fork is not something I give a damn about, but Dillon appears to address your concerns http://www.dragonflybsd.org/Goals/“> .
“DragonFly” these *BSD people surely come up with cool names. Nothing beats “Darwin” sounds really mean – hehe.
But sadly the opensource OS with the most dumb looking mascot and the most dumb name rules the show.
Another healthy fork of BSD? But how can this be? We all know BSD is dyi^h^h^h….<squelch />
Care to explain about this?
http://www.osnews.com/comment.php?news_id=4035
Another BSD…the more the merrier!!!
Keep up the good work all of you BSDs…you’re all great in your own ways!!!
This was more than expected, especially with Matt Dillon comming into play
It’s not dying, it’s resting.
Who wants to start a “Linux is dying” crapflooding campaign? We’ll see how much they like it!
Windows is dying
.
PS: Please mod down this “Xxx is dying” threads.
It’s not dying. It’s… pining for the fjords.
BSD’s been dying almost as long as Apple has
Yet BeOS lives…computer geeks are strange ones…LOL
(Disclaimer: not meant as a slam to any of the OSes mentioned, this is just a joke, I love ALL OSes in some form)
There site’s “goals” page isn’t very helpful!
I am not trying to start trouble but I need someone to clarify something for me. I have been reading all this press on Linux 2.6. What the features/improvements are for desktop and enterprise people, and then recently reading about how Linux will displace UNIX and other variants in the coming future (Not saying I believe this just putting it out there). But the counter argument to this is that Linux is missing a whole bunch of enterprise features that UNIX has (i.e. hot swappable CPU’s or something like that). Now my question is (By the way I am not claiming that Linux is superior or that BSD is or Solaris etc….) being that Linux is a UINX variant and it has so much popularity and momentum, why not just cease innovations/forking in these UNIX variants and just take what makes these UNIX variants so TECHNICALLY great and apply all your energies and make Linux what you want BSD to be. Basically why not just pool your resources and concentrate on one UNIX variant. I am not saying to abandon the others just maintain them until Linux is as powerful as other UNIX OS’s. Or if you wish you can forget Linux as an example and use BSD in place of Linux. Just curious.
Forks exist because people have different ideas on what the focus should be, and one size fits all usually ends up fitting no one comfortably.
I agree about the one size fits all problem but thier is not what 4 or 5 or 6 diff versions of BSD doesn’t this slow this downa bit
The primary goal seems to be to move the kernel to a very microkernel-like message passing architecture. System calls have been replaced with messages sent from the userspace to the kernel. Messages are used to regulate the caching architecture. The locking model sounds quite interesting as well.
I’ll wish them luck, but this seems in many ways more ambitious than FreeBSD 5.x, and I don’t expect major headway to be made any time in the near future.
1) Because UNIXs aren’t hemogenous. While the architecture of all thse UNIXs are similar, the actual code is different enough that its almost as much trouble to write a new piece of functionality from scratch as it is to port it from another UNIX.
2) Because not everyone has the same goals. There is no way to get the “ideal” system. There are trade-offs that make different systems more suitable for different tasks. For example, FreeBSD’s uniprocessor performance is still probably the best of the free UNIXs. But its SMP performance pales in comparison to Linux’s. Even something like kernel preemption (which made it into Linux 2.6) is controversial because the server people don’t want to give up throughput to allow the desktop people to have lower latency.
3) Because projects often need to approach something in different ways. DragonflyBSD, in this case, is a drastic rethinking of some core UNIX kernel algorithms. These sweeping changes could not have taken place within the FreeBSD project, because the FreeBSD project is expected to keep releasing stable OSs on a regular schedule, and already has its hands full with the 5.0 codebase.
4) Because people have an established interest in certain OSs.
Right now, IBM couldn’t just give everything up and move all their AIX developers to Linux. They’re contributing a lot of Linux developers, to be sure, and have committed to Linux being their UNIX in the future, but AIX customers will demand support for a long time to come.
5) Because software development just doesn’t work that way. A project has a certain number of participants that leads to optimal development speed. For OSS projects, this number is comparatively smaller than for large commercial projects, because organization is more of a burden in a distrubuted development environment. Once you get past this optimal number of developers, your productivity decreases, because of the coordination requirements between the people. This is also why OSS software tends to be composed of a number of small, independent modules, because that allows different projects to achieve maximum development efficiency. Its all a matter of parallelism (or lack thereof) in the development process. Tannebaum cites an apt quote in Modern Operating Systems — “It takes 9 months to bear a child, no matter how many women you assign to the job.”
first thanks bascule for summing things up, cause the page did nothing for me in explaining it. There was no simple summary. Also looks like it was made in frontpage in a few minutes, but oh well.
I suppose this fork makes sense, but with what it sounds like their doing it sounds almost like there won’t be much BSD left in it when they are done. I think these forks are ok when they have a much differant goals then others and not a fork for the sack of forking to be cool and have your own OS.
Now how long till someone forks fbsd and intergrates 1 graphical system based on opengl to the core of it with one and only one define GUI, ala a OSX if you will. That would be a nice fork.
Why in earth is Matt Damon starting a new BSD fork, i am telling you guys after he started thinking he could do intelligent movies he is megalomanic, Boycott Matt Damon !
BTW this is yet another BSD fork based on the ego of a single hacker who couldn’t get along with the rest of the team. Well some people think OpenBSD is useful so this might not be a bad thing but still shouldn’t we rename the *BSDs into *EGOs.
Imagine if every Linux hacker who gets his patches rejected would start a fork…
Hmmm. Sounds interesting. Unfortunately, a lot of the Goals section is over my head, not knowing BSD internals. The thing that the micro kernels got right (some would say the only thing) is message passing. It’s nice to see them moving towards better message passing, which IMO is a downfall of the classic unix API.
They talk about having threads move between CPUs as little as possible. I’d like to know how this would affect CPU load balancing on large machines running heavy-duty, multi-threaded programs.
>ala a OSX if you will. That would be a nice fork.
Not exactly what you want but still very OSXy:
http://simplygnustep.sourceforge.net/
I’m really looking forward to this one.
Also forks can end up being a good thing. FreeBSD has benefited from both OpenBSD and NetBSD. While I’m no OS expert I feel FreeBSD would not be as good as it is today without NetBSD and OpenBSD. Would the NetBSD people have been able to pursue their interests of portablility? Would stuff like OpenSSH exist if OpenBSD was never forked? No matter the reasons it was forked. The BSDs regularly merge stuff from one another that they find useful. What makes you think, that if the devs all worked under one roof that they would have been free to do what they wanted? Instead being forced code what the other devs felt were within the goals of FeeBSD. For that matter can’t what you asked be applied to anything? Why create any other chip architecture other than x86? Why have all those engineers waste millions of man hours developing PPC, Sparc, Alpha or Itanium? When they could devote all their skills and talent into making x86 the be all and end all of chips?
Well said.
Isn’t it sounds similar to Amiga’s stuff for the messaging layer? I think, I read Amiga somewhere about messaging layer, so I might be wrong.
BTW this is yet another BSD fork based on the ego of a single hacker who couldn’t get along with the rest of the team.
Matt Dillon talked about forking 4.x way back when 5.x was in planning stages. He didn’t like the direction they were taking it. I don’t know that much about why he lost commit priveleges, nor do I care. But I think he’s doing this because he has some ideas he wants to work on and the FreeBSD project isn’t going the direction to allow that. I don’t think it’s purely an ego thing.
You mean “EXACTLY my way or no way” isn’t an ego thing?! “Compromise” seems to be an unknown term in the *BSD world.
Considering the amount of egos involved in the creation of the BSDs, having only four BSD is a strong indication that BSD developers indeed can compromise.
No, the important point is that the four BSDs pursue goals which are not just different, but in part simply incompatible, regardless of the egos involved, so that a separation of the different projects is necessary.
Not like Linux, where everybody and their dog seems to have their own distro just because they can.
“Imagine if every Linux hacker who gets his patches rejected would start a fork… ”
I think in the Linux world you would do a distro. From what I gather the kernel’s and other parts of the OS in the most populair distro’s are not GNU standard and can differ a lot between the distro’s.
You mean “EXACTLY my way or no way” isn’t an ego thing?! “Compromise” seems to be an unknown term in the *BSD world.
I don’t really know what you’re talking about. Like I said, I don’t really care. I’ve followed the FreeBSD lists for years, and I never knew him to say what you’ve quoted. Could be I wasn’t paying attention that closely. I also never said this new BSD isn’t an ego thing. Reread what I said. I said I don’t think it’s “purely” ego. But this is also about implementing new ideas.
“Isn’t it sounds similar to Amiga’s stuff for the messaging layer? I think, I read Amiga somewhere about messaging layer, so I might be wrong.”
I found this comment on slashdot:
“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.”
Read the article here: http://bsd.slashdot.org/article.pl?sid=03/07/16/217259&mode=nested&…
Slackware Linux is 10 years old!!!
Happy birthsday!!!
HAIL B0B!!!
http://www.slackware.com
Get the latest current and have fun!!!
Has anyone used this??
http://templeofhate.com/tglaser/MirBSD/
That link is something that crashes IE….
Internet Explorer sux anyway…lol…
reading over his site, it seems very interesting indeed! and reading his diary page shows a lot of headway has been made already in regards to turning it in a lightweight kernel threading and message passing.
i think this will be one to keep an eye of, if it keeps going the way it is.
yes.. very interesting!
for those that dont wade/chew through slashdot, here is a message from matt on the messaging.. pretty interesting.
———————-
There are many Amiga-like concepts incorporated into the model, and plenty of new stuff as well. The Amiga had a highly optimal messaging system oweing to the fact that it ran on such a slow cpu making every cycle golden. Two features have been taken from the Amgia I/O model. First, the idea that the target can choose to perform an operation synchronously or asynchronously entirely independant of the type of operation the client has requested. In the Amiga model the client passes a hint which the target may choose to act on or choose to ignore and so do we.
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
—————-
All this microkernel talk reminds me of:
http://www.mklinux.org/
-magg
Though I’m a NetBSD user, the texts on dragonflybsd.org deeply impressed me, since they describe exactly what needs to be done to make Unix into something better (IMHO).
This is very exciting. More power to Matt & Co.!!
Nice to see Matt returning (in a sense) to his Amiga roots
I’ll be keeping an eye on this.
(For info, Matt wrote the DICE C development environment a fairly slick and professional but free/low-cost alternative to something like SAS/C or StormC.)
This is the most interesting development for a long time. I am not a BSD user except on my firewall, but something like this might make me switch from Linux.
But this is a very radical change. Wouldn’t that require major userspace modifications?
I will keep an eye on this project.
I really like the mascot they chose. I think the Dragon fly represents the ultimate in speed and robustness, all the features that Matt is looking to incorporate into DragonFlyBSD.
As with all the Linuxes I am a firm believer that the reason why Linux isn’t more widely used and accepted (than it already is) is because there are so many of them to chose from, with little standards to unite them (packages, directory structure, etc). I hope this doesn’t become the case with the *BSDs because I feel that the BSDs are much more mature operating systems than Linux every will be and I hope that maturity isn’t lost.
I wish Matt luck!
– J
To everyone who was trying to “debunk” me… hello… I am on your side. It’s a joke. An attempt at irony, but never mind.
As I was trying to point out, another fork of BSD could be quite a healthy thing, giving certain people the opportunity to try some more radical changes that would never make it into the conservative FreeBSD code tree.
“Slackware Linux is 10 years old!!! ”
Slackware – the most BSD-like Linux around.
What if there’s a diaspora (say, for example, interstellar flight becomes a reality?) We ain’t all going to the same place.
When I see questions like these, I’m always reminded of the time QNX challenged the Linux developers to get Linux to run on a single floppy like they had done. On the advocacy page, I saw a lot of posts to the effect that taking the challenge wasn’t worthwhile. I answered it this way:
Linux is for everyone, and we can do with it what we will (within the limits of the licences, of course.) But it’s there for all of us. If something can be done, why *shouldn’t* we do it? Maybe we and the folks working on QNX can learn from each other.
Well, that was just before the Embedded Linux movement got going.
Anyway, I’d love to see another BSD fork. Hopefully, the developers in that new fork remain true to the idea of sharing ideas, too. If they take a direction that the current FreeBSD people won’t take, then later on both groups might be able to learn something from one another.
…and don’t forget, where there are forks, there are also merges. Think about corn.
…kinda looks like they’re going to build an OS that’s a cross between the mach unix system and NT.
I like some of the ideas,but I’m always skeptical of the hardware abstraction layer thingy. I happen to be into audio stuff (music composition, in particular.) For folks like me, there are always times when I want that “pedal-to-the-metal” performance that you can’t get with anything like a real-time OS. The Linux folks seem to be getting to the point where almost-real-time access is possible from user space (for applications like, for example, CSOUND, where I want to get a software synth to respond immediately o the keyboard, while at the same time running effects like echo and reverb.)
Musicians often don’t have a lot of money to spend; having this kind of bare-metal control in a free OS could be important to us.
“Nice to see Matt returning (in a sense) to his Amiga roots
I’ll be keeping an eye on this.”
Well…made a fool out of me! I guess if this guy has Amiga roots, I should be expecting to be a-rockin’ and a-rollin’ soon…..
So long as Dragonfly remains similar enough to the other *BSDs, it and the BSDs will benefit from each other. However, changing to a message-passing architecture for the VFS and other sys-calls strikes me as a very significant difference.
That’s not to say that Dragonfly diverging from the *BSDs is a bad thing. As long as the userland APIs remain similar (to either Linux or the FreeBSD’s), it will be able to benefit from Open Source packages , and the venue it presents for new ideas will help inspire the *BSDs (and Linux, I would hope) to better things. That kind of thing already helps both the *BSDs and Linux.
In fact, if Dragonfly does become successful, it should only help Linux by reminding the Linux community that there are successors chasing after it, should it falter.
B.T.W.: I use FreeBSD and Solaris professionally, and FreeBSD to manage a home network / file system with Samba and CUPs. The home FreeBSD box is an ancient Pentium/120Mhz CPU that serves files up quite nicely, and only takes a day to do a “make buildworld – mergemaster – make installworld – make kernel” sequence 😉
One Last Thing: The above seems very Pollyannish, doesn’t it.
I happen to be into audio stuff (music composition, in particular.) For folks like me, there are always times when I want that “pedal-to-the-metal” performance that you can’t get with anything like a real-time OS. The Linux folks seem to be getting to the point where almost-real-time access is possible from user space (for applications like, for example, CSOUND, where I want to get a software synth to respond immediately o the keyboard, while at the same time running effects like echo and reverb.
A HAL and a low-latency sound interface are not mutually exclusive.
Unfortunately FreeBSD’s sound API is essentially OSS, ensuring high latency until someone ports ALSA or the like.
If you want an OS with a good low-latency sound API and lots of great audio software like Cubase, ProTools, and Reason, might I suggest OS X? CoreAudio is the best sound interface implementation in existance.
Meanwhile in Windows, it seems that about 0.1% of the sound devices in the world have drivers that support ASIO…
I’ll answer your question with a question. Why don’t Ford, GM, Chrysler, Mercedes, Toytota, Nissan, etc all come together and make one car company?
They all make something with 4 wheels and takes people from place to place. So why have so many different ones?
Just think about that one, and when you come up with the answer then you’ll have the answer to your question. It might be a bad analogy, but it’s about as close as I can think of.
I believe that this will be everything that the Hurd was ever meant to be, and significantly more featureful and robust “out of the box” so to speak. I have always had an interest in microkernels in general and of message passing specifically, and as a BSD lover, to have a message passing BSD kernel seems a dream come true.
The scalability, performance, stability, robustness and security potential that this new design offers is enough for me to switch from FreeBSD 5.x, something that I have long been awaiting for the many advances that it offers. This is truely a wonderful project!