IRC Forum with Matthew Dillon of DragonFly BSD

weebl writes "Thursday October 9th at 6:00PM PDT (9PM EDT/1AM GMT) SlashNET's #forum channel will be hosting a Q&A session with Matthew Dillon of the DragonFly BSD Project. This is your opportunity to ask about DragonFly BSD, BSD in general, or any other questions you might have for him. DragonFly BSD was first announced this past July." If you can't make it to the forum, SlashNET will have a bot running earlier in the day for question submissions, and logs available afterward.

Comments

Shame....

[NightSpots]

His contributions to FreeBSD will be missed.

I'm sure I represent a large portion of the community who greatly appreciated his work on the VM subsystem (he even pointed the Linux folks in the right direction on more than one occassion), and am disappointed to see him leaving the project.

I understand that not everyone gets along, that goals differ between members; it's just a shame to see it happen.

focus

[endx7]

This will be a good chance to find out what DragonFly BSD will be standing for.

We all know the 3 main (free) BSDs have their focuses, namely:
FreeBSD: ease-of-use and i386 platform (plus a few others)
NetBSD: portability
OpenBSD: security, plus some focus on ease-of-use
and then there are a few other minors, and Mac OS X

But the question is, what is DragonFly BSD's focus? What will it offer for us? How will it be useful?

Perhaps we'll learn at this chat session.

Why Dragonfly?

[Valar]

If I am a happy Linux or BSD (of some non-Dragonfly kind), then what would you say to entice me to switch? In other words, what do you think Dragonfly is particularly good at, that maybe is lacking elsewhere?

Re:Why Dragonfly?

[m.dillon]

DragonFly's first official release will be in a little less then a year. Half of that time is going to be spent rewriting the infrastructure, which is outlined on the site www.dragonflybsd.org We already have light weight threads and our slab allocator in place (which are a biggies) and the basic infrastructure for syscall messaging and DEV messaging in place. We are also steadily bringing in those elements from FreeBSD-5.x that make sense. At the moment my focus is on fixing inherited bugs and rewriting the namecache code. Other DragonFly developers are focused on syscall sepraration, networking, and userland bits. We are being very, very careful to preserve and improve upon the stability inherent in earlier 4.x releases. In fact, the namecache stage-3 work has been delayed over two weeks now while I have backed up and refocused on fixing a number of unrelated bugs.

The biggest topic on our lists right now is the discussion on the infrastructure required to support a good binary and source-based package management system. FreeBSD's package management system currently suffers greatly from bitrot and upgrade-breakage (where upgrading one package breaks half a dozen others), amoung other problems. We are discussing the use of variant symlinks and VFS-based 'environments' for deploying and validating port dependancies in a manner that allows multiple versions of anything to coexist on the same system.

Basically you can think of DragonFly as being all the things I've always wanted to do but couldn't due to politics in the FreeBSD camp. FreeBSD-5 has gone down a road that I believe will lead to a slow, cumbersome, and unmaintainable result. There are plenty of examples of this but the most aggregious is thread preemption in the kernel, preemptive thread movement between cpus (also while in the kernel), and a ridiculously complex API for various types of mutex operations. There are good things in FreeBSD-5, and we will snarf them as appropriate.

The timing is appropriate. FreeBSD-4.x is nearing its end-of-life, and it is obvious that less care is being taken in preserving its vaunted stability then in the past. DragonFly will be the logical successor to FreeBSD-4.x statring in around a year, and I also fully expect to beat the shit out of FreeBSD-5 SMP-performance-wise by the time too.

DragonFly's kernel model is basically to operate on cpus in isolation, with movement beween cpus strictly managed. For example, there is a separate light weight kernel scheduler on each cpu which handles all operations related to that cpu and requires the use of no mutexes. The slab allocator is also per-cpu and mutexless. If an operation needs to work on a data structure owned by another cpu an asynchronous IPI (message) is sent to that cpu rather then performing a locking/mutex operation. For example, if cpu #1 needs to free data owned by cpu #2's slab allocator, cpu #1 queues the work to cpu #2 (and in the case of a memory free, the work does not have to be done immediately). The term 'asynchronous' is important in this context, because it means that the IPI latency between cpus can be entirely absorbed and that sequences of messages (in more heavily loaded systems) can be processed in a tight loop. When we get into more complex entities such as the networking stack, the intention is to run the protocol stacks as threads (possibly multiple threads, one on each cpu or as needed by the situation) and assign protocol control blocks to particular threads on particular cpus. This eliminates nearly all locking and mutex operations related to any given protocol control block and guarentees cache locality of reference. If done properly the individual cpu caches on SMP systems will wind up with less duplication and far higher efficiencies then one gets using a fine-grained locking mutex model. In fact, DragonFly's model works equally well in both UP and SMP environments and we expect the SMP support will cause virtually no loss in performance on UP boxes.

-Matt

Is this the guy that wrote dcron?

[kingLatency]

Since this guy shares the name with that actor, I remembered the name. Is this the same Matt Dillon who is responsible for dcron on my Gentoo system?

Re:Is this the guy that wrote dcron?

[m.dillon]

Yah. I still get an occassional email regarding dcron. DCron was written because, at the time anyway, the VixieCron that Linux was using had a huge number of bugs in it. For example, just changing the time could cause VixieCron to suddenly execute hundreds of jobs all at once. This was a long time ago and I expect VixieCron has been fixed since then, but that was the original motivation for writing DCron. I just wanted something small, simple, and dependable, with per-user capabilities.

It is gratifying to see that DCron is still being used regularly, but I am a bit miffed that nobody has gone and made any truely significant improvements to it. That is part of the nature of open-source, I guess.

-Matt

Lets make a bet...

[Billly Gates]

.. on how many hundreds of trolls from slashdot posting the ever so popular FreeBSD is dieing story and goatse.cx in ascii will head on over to the channel?

Or better yet fooling the irc admins into thinking its a DDOS attack. :-)

Wouldn't it be easier to use the handy slashdot moderation? I think CmdTaco would be willing to hand him 30 of the most highly rated questions.

Re:Owned by SCO

[m.dillon]

Which, very soon now, will hopefully bite SCO in the ass. It's hard to justify significant damages (or any damages at all) for a measily 200 lines of potentially 'stolen' code (SysV->Linux) when all 200 lines have either already been put in the public domain or are obsolete versions of things which ALREADY have equivalent or better functionality in the BSD codepath (the key being that the BSD codepath is completely protected from SCO's foolishness due to the USL lawsuit that AT&T lost).

I've seen companies go down this road before. In many respects it is a holdover from the pre-internet days (or the pre-widely-dissemenated-internet days), where companies could obfuscate facts and possibly succeed in their absurdities simply due to a lack of collaboration and coordination by their opponents. But in the age of the internet, the truth becomes viral and companies like SCO and VeriSign have a much harder time playing the system.

This isn't to say that the Media has clued in yet. Up until recently SCO got only glowing reports from investment media sources and research, primarily because most media and research sources simply parrot official press releases from the company and the open-source community has no 'official' source. But even the total idiots writing the glowing press articles are finally clueing into SCO's criminality. Not enough of them, yet, but the tide is turning.

-Matt