DragonFlyBSD 1.2 Released

vsarunas writes "The DragonFlyBSD Team is pleased to announce the official release of DragonFly 1.2.0! Get it here, or here, or as a torrent. DragonFlyBSD is a continuation of the stable and high-performance FreeBSD 4 branch of FreeBSD with acpica5 and updated drivers so it runs on more and newer machines. DragonFlyBSD can execute FreeBSD 4 and Linux binaries and uses the FreeBSD ports collection. In addition, DragonFlyBSD is also officially supported by pkgsrc. This release represents a significant milestone in efforts to improve the kernel infrastructure. It features a standards-conformant SACK implementation, improvements to the VFS layer, and a multithreaded networking stack that utilizes the DragonFly lightweight message passing system to communicate among processors. More information can be found on Matt Dillon's journal and the Status page of the DragonFly wiki."

Comments

FreeBSD alternatives on the rise...

[Ars-Fartsica]

NetBSD in particular and DragonFlyBSD to a lesser extent seem to be taking off in the wake of what seems like mass disillusionment in FreeBSD 5.x.

I would be interested in hearing from people how either of these BSD alternatives stack up as a desktop box.

Re:FreeBSD alternatives on the rise...

[dinivin]

DragonFly doesn't stack up as a desktop box at the moment. Here's a post I made on osnews.com about it:

Go ahead, install Dfly, and cvsup the latest FreeBSD ports tree and DragonFly dfports tree. Now try to build some useful apps... Way too many apps won't build from the ports tree. If you're lucky enough, there's a dfports override. If you're even luckier, it'll be the same version as the ports tree. Let's assume you actually get those apps installed... A few weeks later you cvsup the ports tree again and try to do a portupgrade. Suddenly SDL in the ports tree is upgraded... By SDL in the dfports tree isn't. Great... Now you have apps that want the newer SDL that keep building SDL from dfports, which you already have installed and which isn't up-to-date...

You can always try pkgsrc, if you want.

First, you need to build and install the bootstrap code. Then you need to update bmake from the bmake package (the forget to tell you that on the gobsd.com site). Forget about getting enlightenment running, imlib2 fails to build. You currently need to patch the gtk2 port (assuming the patch hasn't been committed yet). Firefox won't build, nor will SDL. If you want to build Blender, it'll try to build nasm, which requires the gcc3-c package... Which won't build. (You can edit the nasm Makefile to remove the gcc3-c dependency).

Sorry folks, but DragonFly is really only suited for developers at the moment, IMHO.

Re:FreeBSD alternatives on the rise...

[Anonymous Coward]

I think the "packaging" idea of dragonflybsd deserves a comentary

Tha plan of matt is to move part of the VFS to userspace (ala plan9 it looks to me, but don't trust me).

This will allow to do neat tricks too. Say,you have a app depending in randomlib 1.0. Now you want to install something that installs randomlib 2.0 and and breaks the previous app. With the packaging work, matt seems to expect to allow both packages to live at the same time - randomlib 1.0 will be showed to one app and randomlib 2.0 with another.

Join that VFS work to a good packagin system, and you'll have a system where you can install ANY package without conflicting with other packages - everything could be manipulated by the VFS to avoid conflicts. This means you won't have the conflicts you can have in current systems. With fragonfly, you'll be able to run 5-years old apps at the same time than beta code without incurring in package conflicts.

Re:FreeBSD alternatives on the rise...

[dinivin]

If you are not a developer you should use packages.

If that's the case, why not say that on their website? They don't (or as of this morning, they didn't). Instead, they point out that the FreeBSD ports, combined with the DragonFly dfports is the official method for installing software.

Of course it's not yet perfect, but who would exepct that. And i've yet to see a desktop without problems.

Nor did I ever make the claim that the developers said it'd be perfect. Far from it. I was simply responding to the top posters question about how DragonFly stacks up as a desktop OS.

Dinivin

BSD?

[stratjakt]

If I wanted to install a BSD on my little home router/gateway, just for the sake of playing around with BSD, which BSD is the one to cut your teeth on?

With linux, the choice of distro is pretty much irrelevant - to me at least - because I wind up with virtually the same system, the only differences being the layout of some rc scripts.

The world of BSD isn't the same though, so which is the most prolific, or newbie-friendly, or has the widest support for common hardware, etc?

About the only thing keeping me from playing with BSD is the lack of a single "entry point".

Re:BSD?

[SillyNickName4me]

> OpenBSD is the suggested often for a router because it is a tight little system with a fair number of security enhancements

Definitely but it is still lacking FreeBSD style jails (not often an issue on a router but can be very nice for seperating your mail environment a bit better from the router itself, see below)

> and it's pf packet filter is native to OpenBSD, thus more tightly integrated and tuned for Open.

Its native for open, but integration in freebsd seems to be pretty good. What is more, FreeBSD gives a choice of 3 different packet filters

> It's partly that you don't want a router cracked and partly cause you want the best packet handler, pf is that. ...

> Plus you can set it up as your mail relay and stop spam, and yadda, yadda, yadda... It's a generally nice small system and the ports with it almost all run without fuss.

Uh, I can do the same with virtually any Unix, and setting this up with NetBSD, FreeBSD or Linux is really easy and well documented.

When you want your router to also handle your mail, I'd prefer a system where I can run the smtp services in a well seperated environment, which means more then a mere chroot. Despite all the good work of Wietse, smtp, esp together with virus and spam checking and blocking is a too complex thing to trust it running on my router without such seperation. (perl, substantial amount of perl scripts for amavis and spamassasin etc)

Regardless, I seconf your opinion that openbsd would be the better choice, but mostly because of the first reason, their very nice security enhancements.

Does anyone have any metrics

[Timesprout]

for the performance differential between DragonFly and the regular FreeBSDs ?

two thumbs up

[Anonymous Coward]

I've been running DragonFlyBSD for a while now and it's always been stable and fast for me. This latest release has been rock-solid. I'd give DragonFlyBSD two thumbs up.

Curius about SMP

[thanasakis]

It was my impression that one of the reasons for FreeBSD-5.x was to rearchitecture several parts of the kernel for better SMP support. I know, I know, there were problems but it seems that it had to be done, and the sooner the better.

Now, if DragonFlyBSD continues down the road that was set by the 4.x train, what is going to be done about multiprocessor systems? I mean, multicore processors are right around the corner and other OS's (besides the BSD's I mean) like Linux are getting better and better(I won't even bother to mention Solaris).

I do not profess to be some kind of expert, anyone has anything informative to say about DragonFly's plans on this?

Re:What exactly is the reason

[drmerope]

DragonflyBSD is aiming to make a name in Single-System-Image distributed computing. Think Plan 9 but an evolutionary move from a well established code + user base (FreeBSD 4).

On traditional single machine installations, DragonflyBSD is being optimized for batch processing performance. The kernel is being re-architected to handle heterogenous resources. You often hear about per-cpu/per-core on their mailing lists, this is a reference to their desire to respect and avoid the high costs of IPC except when not using IPC and processor migration would itself be a penalty. You also hear a lot about cache-coherency, which is a desire to not thrash the processor caches and attempt to localize information to as few caches as possible.

If you can do this, then if you have m processors, you have m*per_cpu_cache_size fast memory. Conversely, if you aren't careful you approach having only per_cpu_cache_size of fast memory.

If it all works out (which is still an if) then you'll have an OS that is performance competitive and scales from one to hundreds of processors. This should rival FreeBSD for the performance title in the end...

OpenBSD

[ArbitraryConstant]

This is my personal opinion, the biggest problem I had with other BSDs was the way they didn't fit with the way I prefer to do things. People with different preferences can easily have similar needs and come to different conclusions.

OpenBSD's goal is security, but as a side effect it's very easy to set up (eg hard to screw up and have an insecure configuration), and there are very few bugs compared to FreeBSD.

You don't tweak the kernel because the default one has almost everything that is supported. It makes the kernel bigger than it might otherwise need to be, but if you've got more than 16 mb of memory it doesn't matter.

There is a performance disadvantage (although PF performs well, and that's usually the only thing that matters), but things are easier to set up most of the time. If it's just a home gateway/router, your computer is probably bigtime overkill anyway, so you don't notice the performance disadvantage and you do notice the ease of configuration.

I probably wouldn't use it as a desktop OS because of the lack of software, but all the BSDs suffer from this. I couldn't even get by with FreeBSD as a desktop due to the lack of software. As a router, I haven't had any problems with getting software. What isn't in ports generally compiles fine. The one thing I haven't been able to get working with OpenBSD is a Haskell compiler, and the Haskell interpreter works fine so I don't care that much...

Re:Mass disillusionment is a myth

[BasharTeg]

Microkernel-like because they're going to a messaging / IPC based system instead of traditional syscall implementation maybe?

I support both DragonFly and FreeBSD. As an admin, I need FreeBSD to step up to the plate and offer scalable SMP support because I run 100% SMP boxes. I am willing to wait for FreeBSD 5.x to clean up and show the performance benefits.

However, I am highly interested in Matt's work on DragonFly because in my opinion, most of the popular "*nix" variants today stick too closely to the vanilla unix design which is why our socket code still uses select() and most I/O is done synchronously. I hope Matt expands his work to include super-scalable I/O systems like I/O Completion Ports. I heard there are Linux developers working on IOCP right now, so I'm hoping eventually this spawns a similar BSD effort.

DragonFly will probably work very nicely with multi-core systems down the road. I believe in the long run NetBSD will continue to destroy FreeBSD 5.x in single CPU benchmarks.

But there's the catch...

How many multi-core processors have to roll off the production line for everyone to realize that all of this anti-FreeBSD naysaying is going to turn into a huge crow eating contest because when everything is dual or quad core down the road and FreeBSD scales nicely to match, nobody will give a god damn that NetBSD is faster on a single CPU system.