DragonFlyBSD 1.0 Released

← Back to Stories (view on slashdot.org)

Posted by timothy on Tuesday July 13, 2004 @12:30PM from the made-by-a-famous-actor dept.

eeg3 writes "One year after starting the project as a fork of the FreeBSD-4.x tree, the DragonFly Team is pleased to announce its 1.0 release. Check out the project's diary for a list of the improvements the project has implemented. Also, be sure to grab it from one of the mirrors."

29 of 272 comments (clear)

Serious question: by Anonymous Coward · 2004-07-13 12:34 · Score: 5, Interesting

What was the reason behind this fork?
1. Re:Serious question: by RupertJ · 2004-07-13 12:42 · Score: 5, Informative
  
  IIRC, the DF team wanted to implement SMP in a different way and weren't happy with the over-complicated approach in parts of FreeBSD. They're also ripping out a fair bit of the Perl dependent stuff too.
  
  Check the DF interview article for more info.
2. Re:Serious question: by swb · 2004-07-13 12:48 · Score: 3, Informative
  
  Isn't Perl supposed to be dropped from FreeBSD's base real soon now? AFAIK it wasn't supposed to be a permenant part of 5, and wasn't going to be necessary to build world.
  
  For a project that wanted to get away from FreeBSD, the final diary entry shows at least two imports from FreeBSD.
  
  I can't be critical of a group of people that release their own BSD in their spare time, but I guess I'm not seeing SMP as being important enough to fork an entire BSD system.
3. Re:Serious question: by Bloody+Pulp · 2004-07-13 12:51 · Score: 5, Informative
  
  DragonFlyBSD project is intended to take over development of the FreeBSD 4.X branch. Using a different method SMP and rewrite of packaging system.
  
  Check out the original announcement of DragonFlyBSD on the FreeBSD stable list:
  
  http://lists.freebsd.org/pipermail/freebsd-stabl e/ 2003-July/002183.html
4. Re:Serious question: by RupertJ · 2004-07-13 13:01 · Score: 3, Interesting
  
  Totally agree on the SMP thing. I work with some seriously "into it" techies (including myself) who live and breathe Linux/OpenBSD/FreeBSD/Solaris/HP-UX/IRIX at both work and home. Not a single one of them has a personal box with more than one CPU. Maybe that's a European, or maybe even specifically UK trend for developer's own kit at home. Weird. Maybe others would like to chip in here.
  
  As for the "two imports" thing, the only OSS project that I was aware of a serious initial temporary code-freeze on was when Theo forked NetBSD into OpenBSD and audited the lot. But that said, they're now using NetBSD's SMP code as a starting point. Not that that is a bad thing, by any stretch of the imagination.
  
  With Perl being dropped from FreeBSD, what are they actually replacing it with? (I know very little about the FreeBSD project and it shows =).
  
  RJ
5. Re:Serious question: by Anonymous Coward · 2004-07-13 13:18 · Score: 3, Insightful
  
  They're not "trying to get away from FreeBSD". They think FreeBSD 5 has taken the wrong direction in some areas. They consider DFly to be the logical continuation of the FreeBSD 4 tree.
  
  Because they're aware of how high quality FreeBSD is, they're very comfortable taking lots of code (drivers, etc) that would be impossible for such a small team to write/maintain. All they have to do is modify the code to work with their kernel modifications.
  
  In addition to their kernel changes, they plan on (eventually) having a "better" ports system, with support for things like multiple versions installed concurrently, and selectable with variant symlinks.
  
  Really, there's a lot more to Dfly than just improved SMP. Take the time to peruse the site and mailing list archives to learn more.
6. Re:Serious question: by bsd_usr · 2004-07-13 13:21 · Score: 5, Informative
  
  They're dropping Perl from the base. Meaning that it won't be required in order to build the system. Also, it will be installed as a third party port (add-on software).
  
  Actually, the 4.X branch still has Perl in the base system. The 4.X branch is where DFBSD forked from. The 5.X branch is where Perl was removed.
  
  Before, there were quite a few "system" programs that were perl scripts. Those programs were rewritten as "C" programs in order to rid the dependency of Perl in the base system.
  
  It's not a bad thing. A Unix OS really doesn't need Perl. And if you really do need it, you can easily install it via the ports system or via the package system. No biggie. Makes the base install smaller and neater.
7. Re:Serious question: by m.dillon · 2004-07-13 13:52 · Score: 5, Informative
  
  Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).
  In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.
  What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.
  On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.
  Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).
  -Matt
8. Re:Serious question: by NanoGator · 2004-07-13 13:57 · Score: 3, Interesting
  
  "Only downside (and maybe this is good for the reason mentioned just now) is that most apps don't take advantage of multiple cpus yet."
  
  It's still useful even when you don't have SMP software. If you have an app that's burnin all of one CPU up, you still have the other CPU available to do just about anything else. For example, I have a plugin for Lightwave that is a 3D renderer. It's not multi-threaded yet, so I couldn't make it go faster with both processors. So while that was rendering, I played a game of Quake. Q3 ran great, and the rendering still happened on time. Pretty slick.
  
  --
  "Derp de derp."
9. Re:Serious question: by aanantha · 2004-07-13 14:24 · Score: 4, Informative
  
  SMP will be mainstream very soon. You already need SMP support to use Hyperthreading/SMT. All recent Pentium 4's are 2-way hyperthreaded: so 2 logical processors. 2 sets of registers with shared functional units and cache.
  
  Intel and AMD will be coming out with dual core CPUs by the end of next year: 2 CPUs in one chip with a very speed interconnect between the two. A dual CPU configuration is often faster than a single CPU that's twice as fast. (On the other hand, Hyperthreading gives a measly 30% at most). A dual core Pentium series processor would have 2 real processors each with 2 logical processors: so a quad processor. Once all new computers have at least 2 processors in them, the operating systems that can utilize them effectively will be have a significant advantage.
10. Re:Serious question: by MavEtJu · 2004-07-13 14:24 · Score: 4, Insightful
  
  A Unix OS really doesn't need Perl.
  
  That was not the reason. The reason is that there is more than one Perl version out right now (5.0, 5.6, 5.8) and that different people need different versions. So to get rid of this, Perl is removed from the base-system and if you need whatever-version of perl, install it via the ports system. Much more flexible.
  
  Edwin
  
  --
  bash$ :(){ :|:&};:
11. Re:Serious question: by pyrrhonist · 2004-07-13 14:32 · Score: 3, Insightful
  
  Not a single one of them has a personal box with more than one CPU.
  Does any of your friends have a CPU with Hyperthreading? That uses an SMP kernel, doesn't it?
  Maybe others would like to chip in here.
  Ha! I get it!
  
  --
  Show me on the doll where his noodly appendage touched you.
12. Re:Serious question: by Alan+Hicks · 2004-07-13 15:17 · Score: 3, Informative
  
  Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).
  
  I can't speak for whatever you're VA-Linux machines are, but aren't those Dells 2U rack mounts with something like 800 Mhz processors. Comparing that to a modern Athlon64 or Opteron isn't exactly fair.
  
  For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP, even at a lower combined clock rate. They just seem to work better, balance things better, and never get particularly bogged down by any single process like a UP machine.
  
  --
  Slackware, what else when it must be secure, stable, and easy?
13. Re:Serious question: by LWATCDR · 2004-07-14 01:31 · Score: 3, Insightful
  
  "For the record, my purely anecdotal evidence follows. SMP machines are an order of magnitude better than a single UP"
  I do not think that you mean an order of magnitude. An order of magnitude would mean that you think an SMP machine is 10x better than a UP machine.
  
  It is an easy rule of thumb. You buy an SMP machine when you can not find an UP machine that is fast enough.
  
  --
  See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
14. Re:Serious question: by phoenix_rizzen · 2004-07-14 04:01 · Score: 3, Insightful
  
  Perl was removed from the source tree with the release of FreeBSD 5.0. The installer installs Perl from a package so that the installed system still has Perl. But, it can be removed with a simple "pkg_delete perl\*" or upgraded to whichever version the user wants/needs/requires. All the system administration scripts that were written in Perl have been rewritten in either C or sh.
  
  DragonFlyBSD doesn't "want to get away from FreeBSD". They want to try out new directions, new technologies, new ways of doing things. There have been several dozen imports from FreeBSD 4.x and 5.x, as well as from NetBSD and OpenBSD. That's the nice thing about the BSDs: they are all separate projects, but the source code flows freely between them all.
  
  Considering that SMP will soon become standard issue in the x86 world, I don't see how SMP can not be important. Both Intel and AMD are putting the finishing touched on their dual-core CPUs. In another year, two at the most, you'll be buying a system with one physical CPU "chip", but two physical CPUs on it, making every system an SMP system.
  
  There are several different ways to make an SMP system. FreeBSD 4.x used a simple "Big Giant Lock" on the kernel. FreeBSD 5.x uses fine-grained, mutex-based locking and Kernel Scheduled Entities. DragonFly will use a lockless, message-passing system based on Lightweight Kernel Threads. Very different beasts, and it's not possible to use both LWKT and KSE in the same system. Why not fork off another project, see if it works or not, and either let it live as a separate OS or fold the tech back into FreeBSD as needed?? Forks are not inherently bad things.
FreeBSD 5 by CaptainPinko · 2004-07-13 12:47 · Score: 5, Informative

They felt that the approach the FreeBSD was taking for FreeBSD 5 was going in the wrong direction. I believe they hada problem with all the Mutexs or something specific like that. The main focus of DragonflyBSD is scalability and clustering. The are hoping to have SIS (Single Image Systems) as a priority. It won't be hear anytime son but thats a long term goal. OSNews has had some stuff on them over that last while. Here is the thread http://osnews.com/comment.php?news_id=7660 and here is the torrent I used http://download.exodusmachine.net/torrents/dfly-1. 0REL.iso.gz.torrent . Let me be the first to say: I for one welcome our new Dragonflu overlords! http://www.dragonflybsd.org/main/mascot.cgi

--
Your CPU is not doing anything else, at least do something.
Re:And we care... why? by Teckla · 2004-07-13 12:48 · Score: 3, Informative

For those of us hearing about this fork for the first time, could somebody explain what these people felt was so wrong about the FreeBSD tree that they decided to go off on their own? Or, to put it another way... what's the diference between DragonFlyBSD and FreeBSD?

With all due respect, they answer your questions right on their home page! RTFHTML!
Packages? by RLiegh · 2004-07-13 12:50 · Score: 4, Interesting

What is the ports/packages situation look like for Dragonfly? Have they ported the old ones over, or is their selection severely limited?
1. Re:Packages? by eeg3 · 2004-07-13 12:56 · Score: 3, Informative
  
  Quoting Matt Dillon, the project creator:
  
  We have been in rigorous discussion over what kind of ports/packaging system we want to have. We have already agreed that the core ports/packaging system visible to end-users should be a binary system rather then a source build system. This isn't to say that sources would not be made available for customization purposes, just that most users just want to get a port/package installed as quickly as possible. While the BSD ports/packaging system does have a binary install capability it is insufficient for our needs.
  
  The other thing we've decided on is to give the ports/packaging system the ability to isolate installations. One of the biggest problems one has maintaining a large multi-use system is when upgrading a package for one particular subsystem. Upgrades to the packages for one subsystem can interfere with packages already installed for another, and sysops cannot afford to have upgrades break unrelated subsystems. So, for example, we want there to be isolation between the packages associated with, say, the mail subsystem, and packages associated with, say, a workstation user. The two subsystems might install the same package or might install different versions of the same package... we want that to work.
  
  Also... in response to whether they might use pkgsrc, he replies...
  
  We are considering everything. Nothing is set in stone yet.
2. Re:Packages? by m.dillon · 2004-07-13 13:00 · Score: 4, Informative
  
  It's a big hack at the moment... we have an override system that runs on top of FreeBSD ports to try to keep the more interesting ports operational.
  The DragonFly team has been discussing what ports/packages system to move to (or to build one) that supports our requirements. We've investigated several existing packaging systems so far and are right now investigating OpenPkg (www.openpkg.org), as it has the multi-instance support that is an absolute requirement for us.
  Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.
  -Matt
3. Re:Packages? by Hatta · 2004-07-13 15:03 · Score: 3, Funny
  
  Keep in mind that the DragonFly *USERLAND* is still primarily FreeBSD-4.xish (though with all the C99 stuff from FreeBSD-5 integrated), so anything that runs on 4.x will run on DFly with only minor tweaking.
  
  Now I'm really tempted to switch to BSD. Can't beat a system with integrated C99
  
  --
  Give me Classic Slashdot or give me death!
Re:And we care... why? by eeg3 · 2004-07-13 12:52 · Score: 4, Informative

Quoting Matt Dillon, the project creator:

However, while committer relations have always been an issue, DragonFly split off from FreeBSD-5 over major architectural differences, not anything else. We really do feel that FreeBSD-5 is taking the wrong approach to SMP and building something that is so complex that it will ultimately not be maintainable. We think we have a better way.

You can find more information if you actually visit the project homepage, or read a fairly recent ONLamp.com interview with the developers.
Re:Sounds cool by eeg3 · 2004-07-13 13:01 · Score: 3, Interesting

Although their team is small, it's compiled with very competent and capable developers such as Jeffrey Hsu and Matt Dillon, among others.

Also, a small commit team helps get things done at a faster rate, whereas it's not so hard to get things added.
Six Syllable Names Suck by Anonymous Coward · 2004-07-13 13:02 · Score: 4, Funny

The logo looks neat but the name is way too long to pronouce in conversation.

Maybe they could name it Firebird. Oh wait...
Re:*BSD is dying by Anonymous Coward · 2004-07-13 13:45 · Score: 3, Interesting

Good News Everyone!
Turns out that *BSD is stronger than ever!
According to an Inernetnews article, Netcraft has confirmed that *BSD has "dramatically increased its market penetration over the last year."
There has been a steady increase in *BSD developers over the past decade.
There are currently 307 FreeBSD developers as of the 2004 core team election.
You can read more about FreeBSD here

If you would like to try out a BSD, you can download: FreeBSD, OpenBSD, NetBSD, or DragonflyBSD
Enjoy!
Re:Does it run Linux? by kardar · 2004-07-13 14:28 · Score: 3, Interesting

FreeBSD (I am using 4.10) has a Gentoo "stage 1" port, actually.

There is a directory called /usr/compat/linux, under which you have all the usual /usr (that would be /usr/compat/linux/usr/, if you know what I mean) and /bin and /lib, and so on...

so you... "chroot" into /usr/compat/linux and then you can "make system" or whatevever. It's not bad.

The default is a Red Hat - I have what is essentially a basic Red Hat 9.0 system on my FreeBSD machine, there is also a port for Debian Stable.

So you can do vmware for Linux, or you can do vmware for FreeBSD, just like you can do Mozilla for Linux, or any other app for Linux. I imagine you could install portage under /usr/compat/linux/usr/portage by chrooting into /usr/compat/linux and emerging sync, and then emerge whatever you want - as long as you are chrooted, it should work (I haven't tried it). So everything you emerge should be done while you are chrooted into /usr/compat/linux - if I understand this correctly -- however, the Gentoo port, the Gentoo FreeBSD port, under /usr/ports/emulators/, would be installed like any other FreeBSD port - and actually, there are many FreeBSD "Linux" ports that can be installed automatically from the FreeBSD ports system, no chrooting or anything required. The chrooting would be if you wanted to leave FreeBSD behind and enter into Linux land - apparently this works, but I haven't tried it. Everything I have needed to install that is a Linux binary has been available as a FreeBSD port.

Another cool thing is that you can apparently upgrade from FreeBSD 4.9 and above to Dragonfly BSD, which is something I will probably be doing at some point in the future.
future vs. now by r00t · 2004-07-13 14:46 · Score: 3, Interesting

You're comparing future DragonflyBSD features
with current Linux features.

Hey, Linux has a future too. It isn't stagnant.
There are a number of active projects to give
seamless clustering to Linux. The filesystem
will be shared, including coherent page cache
and user-accesible (flock, etc.) locks. There
are a couple SSI projects. This stuff now has
a conference of it's own. Major developers care.
Re:Examining this FreeBSD train wreck by Eil · 2004-07-13 14:54 · Score: 4, Informative

Attention moderators:

This is a very old troll. Don't fall for it. It's already scored at 4.
Team Interview by No_Weak_Heart · 2004-07-13 17:28 · Score: 3, Interesting

Here's a nice, in depth interview at ONLamp with the core developer team from just last week. Covers a lot of ground, I found it very informative.