Slashdot Mirror
Interview With Matt Dillon of DragonFlyBSD
animus9 writes "There is an interesting interview with Matt Dillon regarding the current status and future of DragonFlyBSD. In it he compares the difference between serializing tokens and the mutex model (a nice contrast to the previously posted Scott Long SMPng interview). He also describes the work being done in the VFS, along with his plans for Journaling, SSI Clustering, packaging, and more."
First, put it in the Apple section. Then re-write it as:
"Jordan Hubbard, Apple's Darwin OS leader, and Matt Dillion, DragonFlyBSD founder & head guru, both formerly leading developers at the FreeBSD project that was the basis for Darwin, are refusing to confirm that the awesome new multi-processing and clustering technologies in DragonFlyBSD will be the rocket fuel that takes Darwin, Mac OS XI (G6 CPUs), and Mac OS XII (Cell-based CPUs) to #1 on the TOP500 Supercomputer list and keeps them there.
"With the run-away successes of the G5 Xserver and Mac Mini, Apple is clearly positioning itself to deliver blockbuster breakthrough distributed computing everywhere from average people's homes to the world's cutting-edge research laboratories...
"Continuing their 'hide it in plain sight' development of these awesome new technologies, Matt Dillion gave an interview..."
Do it that way, and i'll guarantee you 1000+ responses in 3 hours.
In a more sober vein, there probably aren't many people here who know much about DragonFlyBSD or are interested in the low-level technologies that Matt's focused on.
It's easy to make up & spread cool- and credible-sounding stuff. Finding & checking hard facts is hard work.
I think the 1.0 release was more of a "technology preview" type thing. I don't have a link handy, but Dillion mentioned that 1.0 was about getting a good chunk of the ideas working if not optimized. I imagine it will be a few years before we start seeing performance results.
But frankly I'm not in the habit of picking OSes for performance. I use OpenBSD instead of a faster OS because of the features (stability, security, very nice firewall (yes all the BSDs have ported PF, but Open is always a few months ahead of on features)).
With DragonFlyBSD, it's apparent that VERY cool features will be possible. I can't be sure they'll deliver, but if they do they can win without necessarily beating FreeBSD or Linux in terms of performance.
Also... if they can provide an efficient and reliable SSI cluster, they're going to be HUGE regardless of their performance on a single machine.
But as you say, it's all in the future. The biggest accomplishment of 1.0 was changing a bunch of behind the scenes stuff without breaking everything. We will see what happens in the future.
I rarely criticize things I don't care about.
Actually, I think what goes on is a philosphical difference rather than an inadequacy of *BSD.
First FreeBSD ports was so well regarded that someone decided to make gentoo which might well be called "FreeBSD Ports, linux style"
And here we get to the _key_ difference between the BSD culture and linux.
Recently, I downloaded some source (the pm3 compiler, ~1 year old). Much to my surprise the linux version didn't build cleanly. Why? Glibc introduced incompatibilities going from 2.2.5 to 2.3.x but the library version number was left unchanged. This forced me to spend a while fixing up the pm3 source to build against glibc 2.3.2. When I mentioned this to a friend of mine, he replied, "Well that's what you're supposed to do; that was an old outdated interface" I don't mind newer versions dropping outdated features or implementation but not when I must decide to put EITHER the new OR the old libraries on my systems.
This particular problem would never occur on a FreeBSD system. Changes like that simply are not tolerated. Breakage of that sort is confined to major releases and when that happens the library version number changes as well--allowing you to keep the old libc on your systems. Moreover, the old libc will continue to get security fixes for years.
I've often heard people complain that ports isn't very good at updating all the installed packages at once. I have almost no interest in doing this. I upgrade software selectively because I have a specific reason to do so. Updates tend to simply replace known bugs with unknown bugs and as such are not to be taken lightly. The linux breakage model simply is not acceptible in a corporate environment (it's great if you think maintaining your system is fun). This is the reason companies like redhat are slow to upgrade components and rely so heavily on internal patches.
As for your complaints about the base system versus packages. Packages are maintained not as agressively, but they are maintained. e.g., at the very least the FreeBSD security officer keeps track of vulnerabilities in ports. FreeBSD maintains a database of said vulnerabilties and my system emails me notices when a bit from ports has had a security advisory posted against it.
The base system exists:
1) To provide a self-hosting build system
2) To provide ABI, and API stability I mentioned earlier (you'll often see this as POLA - policy of least astonishment)
3) To create a set of tools which are integrated together and have known symantics.
3a) Choice simply isn't that useful to many people. e.g., I dislike that gentoo provides several different system loggers and makes no effort to have uniform and reasonable default configurations.
3b) Most of the BSD projects I am familar with are interested in creating complete systems. This is a priori missing from linux distributions because the kernel development is not well connected to any of the userlands. Redhat attemps some integration within the userland and through some patching of the kernel. But Debian or Gentoo have very minimist conceptions of a "system" which consists essentially of a packaging framework and not much else.
Overview: What you see as limitations/flaws others see as Features and Functionality. Luckily, I can have my feature and functionality running FreeBSD and you can have your knobs running whatever distribution you use.