DragonFlyBSD 1.0 Released

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."

Comments

Serious question:

[Anonymous Coward]

What was the reason behind this fork?

Re:Serious question:

[RupertJ]

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.

Re:Serious question:

[Bloody Pulp]

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

Re:Serious question:

[bsd_usr]

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.

Re:Serious question:

[m.dillon]

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

Re:Serious question:

[aanantha]

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.

Re:Serious question:

[MavEtJu]

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

FreeBSD 5

[CaptainPinko]

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

Packages?

[RLiegh]

What is the ports/packages situation look like for Dragonfly? Have they ported the old ones over, or is their selection severely limited?

Re:Packages?

[m.dillon]

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

Re:And we care... why?

[eeg3]

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.

Six Syllable Names Suck

[Anonymous Coward]

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

Maybe they could name it Firebird. Oh wait...

Re:Examining this FreeBSD train wreck

[Eil]

Attention moderators:

This is a very old troll. Don't fall for it. It's already scored at 4.