Interview with Matthew Dillon of DragonFly BSD

JigSaw writes "Well-known FreeBSD/DragonFly/Linux/Amiga system hacker Matthew Dillon discusses a number of interesting points regarding where the BSDs are going, the status and goals of his latest project DragonFly BSD, the status of his innovative Backplane distributed database, his exciting plans to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image) which is something that no other operating system can do today, and more."

Comments

I guess that'll show em.

[AltGrendel]

BSD isn't dead.

Re:I guess that'll show em.

[ScrewMaster]

This is Slashdot, where any sufficiently advanced opinion is indistinguishable from fact.

Re:I guess that'll show em.

[Rick the Red]

I think of the various Linux distros as "forks" of whatever Linus himself runs. There are literally dozens of Linux forks. Too bad Linus doesn't release a distro, so we'd know what Linux is supposed to look like. If you sit down at a Linux system you have no idea what you're going to find. From a Systems Administration standpoint alone that makes *BSD a better choice for corporations with a large number of hosts, but Linux gets all the press.

Re:I guess that'll show em.

[SillyNickName4me]

Hmm.. yeah, since a recent update I can no longer run a.out binaries from the 2.x era... but for as far as external packages and ports are concerned, thats about the first case where you can't get software for older releases to work with a current version using one of the compatxx packages.

That said, some tools (esp those using kmem) should be kept in sync with the kernel, and when at it, why not just build a new userland, its easier then figuring out what you have to update.

The concurrently developing BSD variatiens allow trying out a variety of low level solutions to problems while sharing a lot of their experiences.

Such diversity doesn't really exist in Linux despite its zillion distributions (which provide a lot of variation in user experience tho)

Re:I guess that'll show em.

[UID500]

Um, linux is a kernel, not a distro. the linux kernel is what "linux is supposed to look like" to linus.

Re:I guess that'll show em.

[Anonymovs Coward]

Um, linux is a kernel, not a distro.

Which is unfortunate in many ways. For example, Matt has introduced variant symlinks into DragonFly, and has major plans involving vfs namespaces etc which will really solve a lot of problems in package management, like allowing two different conflicting versions of a package to exist at the same time. He can do all this because he's looking at the whole picture, and so are the others: the entire source tree for the base system is there on my machine, in one nicely-arranged subdirectory. I don't foresee major changes happening in the linux kernel driven by distributors. To this day, breakages with binary-incompatible glibc etc are constant annoyances with linux unless you choose a stable distributed version from a branded linux distro and stick to it. the linux kernel is what "linux is supposed to look like" to linus.

What is "the linux kernel"? There's a Red Hat kernel, a Mandrake kernel, a SuSE kernel, and you can't really drop a generic Linus kernel into any of the commercial distros and expect it to work properly. (Debian and Gentoo are better.)

I'm not dissing linux, it's better than the mainstream alternatives and has far better hardware support and graphical system administration tools than the BSDs. In fact after 2 years with FreeBSD I myself had switched to Linux on my new machine because of hardware issues (I've now mostly switched to DragonFly and the hardware issues are mostly gone). And I use Linux at work and have no desire to change that. But there are reasons why a lot of technically aware people find the BSDs nicer systems to play with.

Re:I guess that'll show em.

[anthonyrcalgary]

As I'm sure we're all aware, market share is not necessarily indicitive of quality or suitability for a given purpose. Just think about what that would say about Windows if it were true.

Re:I guess that'll show em.

[Anonymovs Coward]

Linux really has very few problems with userspace backward compatibility. What did you have in mind?

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible? And a zillion similar but smaller-scale annoyances, well expressed by Bill Paul many years ago and the years haven't eased the pain all that much.

And BSDs are more likely to introduce binary incompatibilities

Clearly you haven't used the BSDs. You may have library incompatibilities between major versions, but just install the earlier "compat libraries" and you're set. I upgraded from FreeBSD 4 to FreeBSD 5 -- a huge upgrade, over 2 years in the making -- and all my software just worked, even complex stuff like KDE and Mozilla that had been compiled under 4.x.

Re:I guess that'll show em.

[Rick the Red]

I feel that from an administration standpoint with a large number of hosts it wouldn't matter if you were using RedHat, Gentoo, FreeBSD, OpenBSD, or any other *nix for that matter as long as the machines you were running were using the same distro.

You haven't actually been an admin at a company with a large number of machines, have you? I worked for a large aerospace company and our Management (he wasn't even a PHB) wanted to know why we had an average of one admin for 20 machines when HP said one admin should be able to handle 200. Then HP explained that those 200 machines were absolutely identical -- same exact hardware, same exact OS patch level, and same exact applications. In the Real World, we had no two machines alike and thus needed the 1/20 ratio. And this was all the same brand of hardware and OS! Each department was different, which basically made vacation and illness backups a matter of "pray they don't call you." The admins who had the easiest time of it were those who worked on BSD boxes; the VR4 boxes were all over the map; even the users understood that if their admin was away, they were better off not bothering the backup on call for any more than password resets because they'd as likely break something else as fix your problem.

Granted, if you ran an all RedHat shop or an all Mandrake shop things would be easier than simply an all Linux shop, but the same would be true for an all OpenBSD shop vs an all FreeBSD or NetBSD shop. But if each department is free to buy what they want I'd rather find who-knows-which-BSD on the box than who-knows-which-Linux.

Re:I guess that'll show em.

[yanestra]

Merely my brief experience with Gentoo, when they first upgraded glibc (from 2.2 to 2.3 iirc) and broke half the packages, then downgraded it again and broke everything else. This is really a pet peeve: aren't minor versions supposed to be compatible?

There's a big difference between binary executable and logical compatibility. You have compiled several files with newer libraries and then downgraded. You expected that the newly compiled programs to run with old libraries - which they in fact do, as long as there has no special feature of the newer libraries been used - inherently.

If you are unhappy with your executables be broken, simply keep a copy of the older libraries. (With Gentoo, simply delete the old package file in /var/db/pkg before updating.)

Different threading model

[Mr. Darl McBride]

It looks like the gist of the threading model for Dragonfly is that threads all stay on one processor. I assume this is for user processes only, and that this isn't pervasive through the kernel?

Re:Different threading model

[Anonymous Coward]

No BSD secrets for you, Darl!

Re:Different threading model

[Mr. Darl McBride]

It looks like the gist of the threading model for Dragonfly is that threads all stay on one processor. I assume this is for user processes only, and that this isn't pervasive through the kernel?

Nevermind, found an overview here.

Re:Different threading model

[Kaladis Nefarian]

No this is to do with kernel threads. The userland threading is the same as in FreeBSD 4.x atm, AFAIK. The idea is to keep the model simple, unlike in FreeBSD 5.x where they are having trouble keeping it all sane with their fine-grained mutex model. Have a look at the dragonfly.kernel newsgroup, in nntp.dragonflybsd.org for more details on the SMP model, Matt talks about it regularly earlier on.

Re:Different threading model

[Mr. Darl McBride]

No BSD secrets for you, Darl!

It is important that I discover what they have created so that I may license it back to them.

~Darl

Re:Different threading model

[m.dillon]

Not exactly. All this means is that threads do not migrate preemptively, nor do they migrate while blocked or switched out while in kernel mode. Threads only migrate if (a) the thread itself wants to move to another cpu or (b) the thread is returning to user mode and the userland scheduler decides to migrate the thread to balance the load out (which only applies to threads associated with user processes since no other type of thread can 'return to usermode').

Kernel threads almost universally stay on the cpu they were originally assigned to. High performance threaded subsystems, such as the network stack, are replicated. That is, the network stack creates multiple threads (one per cpu) and those threads do not migrate because, obviously, they do not need to.

Generally speaking, the purpose of making thread migration explicit instead of automatic is to partition a larger data set across available cpu caches rather then cause the same data to be shared amoungst all cpu caches. The processors operate a lot more efficiently and SMP scales a lot better. Most people do not realize the horrendous cost of moving threads between cpus because the cache mastership change is invisibly handled by hardware, but the cost is still there and still very real.

-Matt

Re:Different threading model

[m.dillon]

The system core is lockless... there are no mutexes. For example, the LWKT scheduler core operates entirely without mutexes. Only critical sections are used to protect against local interrupts. A critical section is per-cpu, and really only needs to increment and decrement a per-cpu variable. As such the crit_enter()/crit_exit() code does not need to use any locked bus-cycle instructions or anything fancy at all, really.

The LWKT scheduler on any given cpu is only allowed to operate on threads owned by that cpu. If you attempt to wakeup a thread owned by a different cpu, an asynchronous IPI message is sent to the target cpu's LWKT subsystem requesting that the specified thread be woken up. It's really that simple. Same goes for cross-cpu scheduling.

IPI messages themselves are lockless and require no mutexes to operate because the cpucpu messaging uses a software crossbar (array of FIFOs) approach.

Re:Different threading model

[m.dillon]

No, the critical section code simply increments and decrements a per-cpu variable. No locking is required at all... critical sections are local to the cpu, not global to the system.

In regards to cache issues, lets say you have a quad opteron system. Each cpu has a 1MB L2 cache. If you migrate threads willy nilly you basically wind up in a situation where each of the four cpu's L2 caches contain the same data. In effect, you wind up with a system that globally has only a tad more then 1MB of L2 cache. If you partition data (such as TCP protocol data) across distinct threads, and place those threads on different cpus, then you are in effect partioning your system's memory across all four cpu caches and you wind up with a system that globally has 3-4MB of L2 cache instead of 1-2MB.

There are two costs being saved here. (1) the cost of having to go to main memory when a piece of data is not in the L1/L2 cache, which can run into the hundreds of cpu cycles, and (2) the cost of cache mastership changes for all the data associated with the thread that was migrated (repeated each time the thread migrates).

-Matt

Re:Different threading model

[m.dillon]

I don't think it's anyone's design in particular, but I tend to sit down and write things from scratch rather then copy other people's ideas. In the case of the thread replication used by the network stack, it is primarily Jeffrey Hsu's work and since he is big on reading papers I'm sure it's a combination of his own design and ideas gleaned from various published papers.

For a project that gets no press

[RLiegh]

Dragonfly BSD seems to be chugging along quite nicely.

The further away they get from their 4.x FreeBSD roots, though, the more I wish they'd release an ISO. Particularly since the last ISOs for the 4 series of FreeBSD are probably going to be totally gone in a few months.

Re:For a project that gets no press

[Anonymovs Coward]

They do have ISOs, click the "download" link on their main page. The ISO is a liveCD, so you can boot your computer with it, like knoppix (no X or GUI stuff though). What they don't have is a friendly installer. But the /README file has detailed instructions on installing it to the hard disk, which should be easy if you have BSD experience, or if you're a brave newbie you can try it anyway.

Re:What?!

[RLiegh]

It's official. ftp.FreeBSD.org/pub/FreeBSD/iso confirms it. FreeBSD 4.x is dying. kreskin... usenet... falling dead last in the number of ISO's distributed on ftp.freebsd.org ....all practical purposes...stephen king is dead.

Divide and conquer

[florin]

Yeah yeah forking is always sweet and this sure sounds like a lot of fun already, but what I'm really waiting for is for someone to put together a BSD-from-scratch distribution! I mean, I know I could just build one with Linux.. BUT only having a single kernel to choose means my grimy little subculture won't be as obscure as it could be. Just think how exclusive I'd be if I could pick one of the NetBSD, OpenBSD, either of the active branches of FreeBSD, and PicoBSD, Dragonfly BSD or Darwin kernels..

Re:Divide and conquer

[Anonymous Coward]

There is no need for BSD-from-scratch disto.

1: All the BSDs are entirely different operating systems, which are lumped into one category becuase of their roots.
2: Since no extra bullshit is thrown in like linux, there is less need for reworking the base.
3: BSD is not obscure in the least, it is rather alive and florishing.

BTW you forgot to mention Solaris, which has it's roots in BSD too.

Re:Divide and conquer

[Anonymovs Coward]

From that interview, it sounds like DragonFly is going to have a different package management system in the future. Which means either the base is going to change,

The BSD base isn't packaged. BSD types like having a source tree for their entire base system and being able to do "make buildworld" and "make installworld" to upgrade it. The package management system is entirely for third party applications. This is not Debian or Gentoo who have no code maintained by themselves other than installation and package management stuff. The BSDs maintain the kernel, the libc, other key libraries, and all the base utilities like ls, cp, mount, etc. And there's also a lot of "contrib" software in the base system -- some of it necessary to build the system (gcc and binutils), some of it just there out of tradition or regarded as "too useful to be moved to ports" (bind, sendmail).

Re:Divide and conquer

[Anonymous Coward]

Oh well you know, just all sorts of functionality that was driven by Linux, like finely grained SMP, support for enterprise level hardware, USB, SANE, ACPI, DRI/DRM and what have you more. And let's not get started on the apps. I mean, there's a reason why all the BSDs make an effort to run Linux binaries, not the other way around.

hold on cowboy...
linux drove usb support? check your history...

linux has better support for smp? right... 'cos the linux smp support isn't a rip of free-bsd's first smp incarnation, and free's 'new' smp code is some hack up by a big school kid is it?

linux has better support for enterprise hardware? shall we start with... i dunno... scsi support... get your history book out and do some experimenting with old linux v's old *bsd installs - try backing up a raid and restoring, then come back and tell me how good scsi isn't fundamental enterprise computing...

next you'll tell me that open's code auditing and goal of bug-free secure code is inferior to linux's free for all crap-code fest

excuse my rant, i'd don't mean to bag linux - every OS has its place - even windows.

but man... linux zealots and their damn superiority complex, re-writing history... i even heard someone try to explain the sco crap the other day... he actually said that 'unix is a brand of linux'

Not by a long shot.

[Tony-A]

"The reason for this excitement is that it is becoming clear to us that we can develop very clean-looking, elegant, debuggable, SMP scaleable software using this model whereas using the mutex model generally results in much less elegant (even ugly), difficult-to-debug code. Code complexity and code quality is a very important issue in any large piece of software and we believe we have hit on a model that directly addresses the issue in an SMP environment without compromising performance."

I don't really know what he's talking about, but:
If he's right, everybody wins.
Even if he's wrong and we find out why, everybody wins.
It sounds like Linux isn't hurting BSD any, and methinks for a number of reasons, Linux wouldn't be what it is today without the BSD's.

Amazing.

[xeeno]

There's actually something on the front page about BSD. And it says nothing about SCO or linux.

Something no other OS can do?

[fmayhar]

It's simply not true that "a transparently cluster-capable system implementing native SSI" is "something that no other operating system can do today." We were doing it at Locus in 1994 with SVR4 then with Tandem in 1996 with NonStop Clusters for Unixware. Now some of the same folks at HP have introduced OpenSSI, which is essentially the same code, less all the Unixware-related bits, ported to Linux and placed under the GPL. They are coming up hard on their 1.0 release, which is not bad for five people and such a large task.

OpenSSI is the real thing, it has processes that migrate from node to node, distributed file systems, the works. And it's running now on clusters literally all over the world. (Not many clusters, true, but maybe that will change if the Slashdot crowd finds out about it.)

I'm happy to say that there's a lot of my code in that system, as well.

I know a little about what Matt wants to do with his SSI in Dragonfly, but he should certainly take a look at OpenSSI; we had to solve a lot of the problems you run into when you build such a beast.

(And a beast it is. As complex as a kernel can be, when you have what is essentially a distributed kernel across several nodes, the complexity goes up by orders of magnitude. Makes tracking down those weird hangs pretty exciting, in a painful, time-consuming kind of way.)

Re:Something no other OS can do?

[fmayhar]

Not so much, no. The bits that were ported were never tainted and the bits that were tainted weren't ported. Because of the way we did our development, what belonged to us was never mixed with what was merely licensed. So when I said "strip out all the bits related to Unixware" I meant precisely that. Not "strip out all the Unixware bits" but strip out all the stuff in the locally-developed code that was Unixware-specific.

Of course, I was only there for the very beginning of the port; by the time the code was placed under the GPL I had been at BSDi for a while.

Re:Something no other OS can do?

[Anonymous Coward]

It's simply not true that "a transparently cluster-capable system implementing native SSI" is "something that no other operating system can do today."

He didn't say that, here's the paragraph from the interview (emphasis mine)..

Well I strongly believe that any project needs to have an unattainable goal, and our unattainable goal (which I hope actually winds up being attainable) is to develop DragonFly into a transparently cluster-capable system implementing native SSI (Single System Image). It is something that no non-commercial system today can do (the type of clustering Linux supports isn't even close to the type of clustering that we have as our goal, and clustering has never been one of the other BSD's goals as far as I can tell).

Re:Here we go again

[buffer-overflowed]

Because BSD users have a mascot called "Beastie" who is a devilish little chap and they use "daemons" to accomplish things that seem like magic to normal people.

So, you see, it's obvious... BSD made a deal with the devil! And it's users weigh the same as ducks, therefor they are made of wood, and since they're made of wood, they are witches!

I mean, didn't you ever wonder why we call them "holy wars"?

Re:SSI?

[Kaladis Nefarian]

If you read the article, Matt says (about SSI): "It is something that no non-commercial system today can do"...

Linux has no SSI?

[Anonymous Coward]

Funny, the Slashdot blurb accuses him of saying that no other system today does SSI, while according to the article he simply said their (future, potential) SSI plans will beat Linux's (present, working) SSI clustering.

Anybody have thoughts comparing the DragonFly SSI(warning, PDF) and the Linux one?
(Open)Mosix has had craploads of work done on it, and by the time DragonFly's is done, it will be even further ahead. I somehow doubt DragonFly's will end up being better.

PK

Re:The Ballad of Matthew Dillon

[kfg]

There once was a Master of Screws
Who thought it most wonderful news
That the AC's post
was more funny than most
But not all mods agreed with his views.

KFG

Backplane non-free, non-relational

[leandrod]

This SSI stuff sounds interesting, but I'd like to see his stuff compared to OpenSSI. Now the Backplane SQL DBMS seems interesting, but... First, they make the common mistake of calling SQL relational. This in itself will prevent them becoming significantly better at the logic level, which is a pity. Second, it looks very interesting as far as the backend goes. But the question here as always is, why create something from scratch? Couldn't, say, PostgreSQL, which was born on BSD anyway, be retrofitted with their stuff? Won't Oracle or IBM leapfrog them if they prove successuful? Third, looks like we have yet another BitKeeper in the making... gratis for free software, but not free itself. Makes me want to stick with PostgreSQL for now. If I wanted something proprietary, I'd go Alphora Dataphor, which at least is fully relational and not yet another SQL.

Re:The Ballad of Matthew Dillon

[VValdo]

There once was a fellow named Dillon
Whom everyone thought was a villain,
He cried, "That's not me!"
"I use BSD!"
"Because I find it fulfillin'."

W

License contradiction?

[XaXXon]

If your application is licensed under the GPL or compatible OSI license (learn more at opensource.org) approved by Backplane, Inc., you are free and welcome to ship the Backplane open source database with your application.

followed by:

If you power an application using the Backplane database that you market or sell, or use that application to conduct any form of online commerce (selling/buying products or services over a website) you need to purchase the Backplane Commercial License.

The example given is if you run an email service from which you sell access to other companies, you must buy the commerical license.

My question is, what if the program that provides the email service is GPL. Do I have to buy a commercial license or not? One of the great things about GPL software is that if it's an internal piece of software, you can mix proprietary and GPL code as much as you want, as long as you never redistribute the program to anyone.

Also, how does dual licensing work with this? Can I license it under the GPL to myself, and then sell copies under another license to other people? Obviously THEY would have to buy a commercial license, but do I?

Just trying to point out some holes in the licensing..

Oops, just noticed the part at the end saying:
NOTE: In any of these examples, if the entire application or service is 100% GPL compatible, you may use the Backplane Free License.

But that still leaves open the question about dual licensing..

Re:Here we go again

[Ashish Kulkarni]

heh, you might want to take a look at this joke. ;-)

Re:SSI?

[funwithBSD]

Yeah, rules out OpenVMS too...

I am always amazed at the rockin' shit OpenVMS can do... just about everything that DragonFly is suggesting... plus the fact that a hacker that got in would likely just say WTF? and log out.

Re: SSI?

[molnarcs]

I don't think the parent post warrants such an outburst. You obviously need to see a doctor. Yes, now and then the items on your list (BSD is cleaner, more organized, etc..) do come up, but then, what the hell does operarc and mplayer.conf do in /etc??? (sorry, I couldn't resist :-P)

You need to take a break IMHO.

Jesus fucking christ give it a fucking rest already please? Just go about your BSD stuff and be happy. Just constantly rubbishing Linux at every opportunity just makes you look like an imbicile with Linux envy.

It seem it is you who has some sort of imbecile rage against BSD, as if it killed one of your relatives or something. Saying things like 'this will be better than what linux has or will probably have' shouldn't throw you in such a fit. Look. Matt might be up to something. He might succeed. He might not. Either way,(even linux) developers might/will learn something from this 'experiment'. Can't hurt, right?

Now go, fetch that valium before you have stroke.

ps: (modded as insightful? - come on ...)

Re:SSI?

[Alan Cox]

And to a great extent also things like MOSIX, which go back to V7 unix as well as Linux. Also for that matter OpenSSI (openssi.org)

The commercial world is full of SSI systems although its never been clear if transparent SSI is the right answer to any problem except "I need it to work now", because coding good apps for SSI setups is hard.

Dragonfly looks a good project, and looks like it has old BSD folks who actually knew what they were doing working on it.