DragonFly BSD 4.0 released | Hacker News Reader

DragonFly BSD 4.0 released

dragonflybsd.org

189 pointsfcambus49 comments

Out of the BSDs, I would say DragonFly is the most innovative. Its implementation of virtual kernels, HammerFS, thread scheduling via message passing and it has been rock solid as an NFS file server, serving all my local media to other *nix nodes on my LAN. Wikipedia gives a great rundown on the innovations and why Matt decided to fork.

http://en.wikipedia.org/wiki/DragonFly_BSD

I would almost term it as a permanent research platform for FreeBSD. Never would I recommend someone run it in production, but if I'm looking for cutting-edge parallel OS techniques, Dragonfly is definitely on the short list. Come to think of it, it might be the only one on my short list—OS innovations seems to be driven by virtualization, container, filesystem, and network concerns more than anything these days.

Indeed.. although they are aiming for a production quality platform with the upcoming release of the HAMMER2 filesystem.

>I would almost term it as a permanent research platform for FreeBSD

DragonFly BSD was forked from FreeBSD because of fundamental design disagreements between Matthew Dillon and the rest of the FreeBSD developers. Thus I doubt that the characterization as "research platform for FreeBSD" fits. You might as well say OpenBSD is a research platform for NetBSD.

Well, OpenBSD has goals beyond "trying out new shit" on NetBSD... That's not entirely clear with DragonflyBSD.

DragonFly actually adopts a lot of tech from freebsd.

As far as I know, all of the BSDs have adopted code from each other over time. It might simply be a side of effect of the common heritage and license, but it seems to be one that none of the people involved have a problem with and often consider desirable.

But that does not make Dragonfly a "research platform" for FreeBSD. Both systems have different priorities and goals.

(Although I wonder if any of the things that Dragonfly set out to do differently has been adopted back into FreeBSD?)

What's wrong about running DragonFly BSD in production ? It has been rock solid for years for my uses -- mostly smtp+imap servers.

Don't forget it was originally FreeBSD 4, one of the most stable Unix-like operating systems of its time.

... and FreeBSD 4 was the most stable, polished and mature release of FreeBSD, ever.

Agreed - I loved 4.11! Though I have been really happy with 10.x so far.

What about 2.2.8 ?

Unfortunately, little if any of the development is ported in the direction Dragonfly -> FreeBSD.

The last time somebody tried porting HAMMERFS it was discovered that the systems are already divergent enough that it would be a huge job because to stay true to form, other Dragonfly's systems upon which HAMMERFS is built would also need to be ported, and as such systems include such basic stuff as the threading model, the effort was abandoned.

Also worth mentioning, BSDTalk has an interview with Matthew Dillon about the 4.0 release of DragonFly BSD : http://bsdtalk.blogspot.com/2014/11/bsdtalk248-dragonflybsd-...

Just listened to this BSD Talk episode yesterday. Matt is doing some extremely interesting work, not only on the kernel and file system research side, but also in terms of their completely customised networking stack, which utilises multi-core non-blocking networking I/O to achieve really high speeds. I would like to see some of that incorporated back into the FreeBSD kernel (not sure if it has been done, but I doubt it).

"The drm/i915 driver is now mostly based on the Linux 3.8.13 implementation and is no longer similar to the FreeBSD driver. Many Linux APIs and data structures have been implemented in the DragonFly kernel in order to reuse as many parts as possible of the Linux drm/i915 code without modifications."

I was wondering how did they deal with licensing issue. I thought Linux drivers are all under GPL. And DragonFly is (obviously) under BSD. Then I've noticed gpu/drm/i915 has a permissive (MIT?) license. E.g.:

https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

Is it true for everything else under gpu/drm directory? What license does DRM have?

The DRM code itself as well as most of the drm drivers is under a MIT/X11 license. It was only integrated in Linux in 2008 (not 100% sure of the date) and was maintained in a separate tree before that. It also had to be compatible with X11, hence the choice of license.

> I thought Linux drivers are all under GPL.

Nope, in fact some of Linux's drivers are licensed with the old-style BSD license with the advertising clause: https://github.com/torvalds/linux/search?q=%22advertising+ma...

I'd love to see these 2.5 year old performance benchmarks re-ran.

http://www.dragonflybsd.org/performance/

Does anyone know where I can gain the benchmark config/setup so that I can re-run myself?

I ran the Postgres benchmarks again in March of this year and DragonFly was the fastest of all the operating system I tested.

Look at page 20 of these PGCon slides: https://www.pgcon.org/2014/schedule/events/754.en.html

I also published the methodology along with results in the pdf files I originally posted to the DragonFly mailing-lists. Direct link to one of these: http://dl.wolfpond.org/benchs/Pg-benchmarks.2012-10.pdf

Is there any reason why the DBSD website isn't updated with your data?

Nice report btw

This is great news, the DragonFly project keeps doing really interesting things. The interview linked elsewhere in the thread give a good overview of how the project is doing. Matthew Dillon mentions in the interview that DragonFly will be able to be much more than an experimental operating system.

This project has intrigued me for a long time. I seriously believe it could eventually become the premiere BSD-flavor OS. Although given all the low-level changes they've made it may not be easy to "label" it BSD in the future.

FreeBSD itself has diverged significantly from its own 4.x release, which is where DFBSD forked. I would still call DragonFlyBSD a "BSD" now and in the future since it still leverages a lot of work from FreeBSD (and other BSDs) to this day. It would be stupid to not continue to leverage the upstream work.

Agreed. I think it's a fantastic ecosystem, and they should all continue to feed off one another. A great example was discussed in the interview. The decision to integrate FreeBSD ports will almost certainly make it easier for folks who are considering adopting / experimenting with it. (not a recent decision, but an important one)

I would say the primary identifier of BSD systems are their interface with the kernel, the userland, and the license. DragonflyBSD is a true BSD to the kernel; the implementation details may differ, but you can compile most freebsd code for dragonfly with no changes and have it run perfectly (or as well as dragonfly can swing it).

Not disagreeing, but I found the following quote from the site interesting and helpful to understand where they're coming from:

http://www.dragonflybsd.org/docs/howtos/howtonewkerneldevelo...

"While DragonFly was forked off FreeBSD and has generally quite a few similarities to other *BSD, you definitely cannot rely on understanding FreeBSD to understand what's going on here."

The first OS to drop 32 bit support, thus eg fixing the year 2038 problem the easy way. Not sure if any others will though, at least not until arm64 is more widespread.

> The first OS to drop 32 bit support

The first? What about Windows Server 2008 R2? Or PC-BSD 9.2?

Or freenas or soon, pfSense.

I'm not sure PC-BSD qualifies as an OS unto itself.

Last time I checked, they were mostly a FreeBSD distribution with a bunch of user friendly sugar coating on top (an easier package manager, default installation includes a fully configured desktop environment, ...)

I don't mean that as a bad thing - I used PC-BSD for a while and it was great. Not everyone needs to reinvent the wheel and reimplement drivers etc. But I see it more as a distribution of an OS than an OS.

OpenBSD fixed it in 5.5 released in May.

Over 2 years ago NetBSD released[1] the 6th major version and introduced 64-bit time_t[2].

[1] http://www.netbsd.org/releases/formal-6/

[2] http://www.netbsd.org/releases/formal-6/NetBSD-6.0.html

Yes, that was the more difficult way I was contrasting with just dropping 32 bit support...

The graphics support sounds neat for (developer) workstation usage, hope it gets at least a basic suspend/hibernate support soon to complete the picture.

What single feature/change caused this to be a major release as opposed to a minor release?

In reading the OP link, nothing in particular stood out to me.

(Please don't take offense to my statement. The changes are all great. I'm just typically use to major releases to be when something foundational has changed and I'm just not seeing that here)

Dropping i386 can be considered a big feature.

Certainly qualifies as a "breaking" change that could justify a major version bump.

Version numbers are arbitrary. Sometimes an incriment denotes features, sometimes it is age. And sometimes version numbers get incremented just for publicity.

Does anyone know if DragonFly's code gets merged inro the FreeBSD codebase?

> Despite this, the DragonFly BSD and FreeBSD projects still work together contributing bug fixes, driver updates, and other system improvements to each other.

http://en.wikipedia.org/wiki/DragonFly_BSD

sometimes yes, like the new procctl(2)

Seems like mostly drivers -

http://fxr.watson.org/fxr/search?string=DragonFly

Wow, nice set of features. It's time I checked Dragonfly BSD again!

http://www.dragonflybsd.org/features/

Apple has a lot invested in Darwin, but DragonFly BSD would be a nice foundation for OS X.

I'd take HAMMER over HFS+

I'd take just about any new filesystem over HFS+.

Did a search on code, and seems like fairq in Darwin is taken from DragonFly BSD[0]

[0] http://fxr.watson.org/fxr/search?v=xnu-2050.18.24&string=Dra...

True, but there are many issues that might not seem obvious at first. For starters, XNU is _not_ a FreeBSD kernel. It’s a hybrid kernel, there is a Mach 3 based kernel at the very bottom with a FreeBSD kernel ontop. Mach takes care of providing, well, Mach IPC, but also virtual memory, threads, processes, scheduling and all that kind of stuff. The FreeBSD part is, in a lot of ways, only a shim down into Mach land, but also brings its own systems like the VFS and networkstack and most of the other userland facing things.

I feel like it would be very non-trivial to switch to DragonFly BSD, because then a lot of the shims have to be re-designed in order to still work, simply because of the highly different design of DragonFly BSD. Disclaimer: I haven’t studied the DragonFly BSD source code yet.

Really nice to see DragonFly is still alive and progressing. I tend to like OpenBSD but choices are good!

Reply on news.ycombinator.com