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."
as for the rest, I'm not talking about GUIs. I'm talking about support for the whole system.
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.
that is the reason i use bsd.
i dont want my operating system to be a political statement or substitue penis, i just want the bugger to work reliably (my os, not my penis, which works fine thankyou). The ui is fine. maybe it is a little bare bones, but at least i can easily see exactly what is going on.
and you are wrong, they are very vocal when it matters, ie propriety systems/intefaces. something a lot of linux people ignore and just sign nda's.
We don't need a GNU/BSD distribution. There is no reason to through out the superior BSD userland. Everything that GNU offers which BSD needs is already in BSD.
Yes, I said "superior BSD userland." The only advantages to the GNU tools to their BSD counterparts are twenty thousand additional command line options. This isn't a "good UI", this is feature creep. Oh, the GNU tools are more portable, but that doesn't add any advantage because the BSD tools are already there and native.
Speaking of "good UI", where is Darwin's? It doesn't have one! Yet it's still the operating system for Mac OSX desktop.
Don't blame me, I didn't vote for either of them!
But OS X, wonderfulness thereof aside, isn't FreeBSD!
Really, it's the XNU microkernel with a userland that's an amalgamation of Free-, Net-, and OpenBSD. The majority of
Darwin (the underlying "UNIX" of OS X) isn't FreeBSD and when you add in the other parts that make up OS X, you're left with something that only vaguely resembles FreeBSD.
For me, the biggest point is that the kernel is not FreeBSD-based (although, admittedly, the UNIX parts bolted onto XNU are pretty reminiscent of FreeBSD).
Don't even get me started on the large amount of GNU utilities included.
Hopefully Matt Dillon and his team of developers can come through for us, and make a great OS that meets the hype. Currently, I feel that DragonflyBSD has a high sticker-to-horsepower ratio, which is not so much the fault of the developers, but rather the fault of a large pack of fanboys having premature ejaculations over an OS that is by no means finished yet.
Years ago, FreeBSD fanboys said that FreeBSD's SMP implementation was going to be the best the world ever saw. Now, those same people are saying how much it sucks, and that DragonFlyBSD's is the boss of the boat. How about instead of all of this talk, we let the installations speak for themselves? FreeBSD is approaching a fully mpsafe kernel (albeit somewhat asymptotically) and I continue to be impressed with each release of the 5.x series. DragonFlyBSD has had one release, and it looks fine, but fact of the matter is, it's just not finished yet. I'm getting a little tired of all of the talk. Show me these DragonFlyBSD machines making water into wine. What we are dealing with is the classic "penis size" argument, and yet no one has brought a ruler to the scene.
I hope that DragonFly _does_ trounce FreeBSD in both performance and useability, so that I have a new OS that is greater than the greatest. I'm just going to wait until it's finished and showing it's stuff before I start playing with myself.
NeXT is no more BSD Unix based or descended from then OS X is based or descended from FreeBSD. NeXT was a commercial implementation of the Mach kernel from CMU. Now like Linux, Mach was just a kernel, and in places an incomplete one. In the spirit that BSD Unix was distributed with, instead of waiting to make an entire OS, when they wanted to show this new-fangled micro-kernel they had created, they ported some Userland tools, and later tacked on some networking from BSD Unix and showed it off. NeXT takes that reference and makes it better, a better desktop, nice programming tools and many new utilities, at the same time as updating the system from its original sources. Apple acquires NeXT and begins to make the NeXT parts better, and once again updates the Unix sources. Neither descended from Unix, they just make use of it in certain areas of the system.
"I use a Mac because I'm just better than you are."
English is easier said than done.
"OSX is not FreeBSD based. It borrows from FreeBSD and recognizes it as th successor to UCB's BSD. Apple uses FreeBSD as the reference platform for "what constitutes BSD Unix"."
Well, a number of points.
-It's a different kernel but Apple made it system call compatible. Mostly[1]. They have some extra ones I think.
-They took a lot of FreeBSD userland libraries and programs. With a compatible kernel there's simply no point in duplicating this work. A lot of the man pages are even marked FreeBSD.
-I've heard vague talk about FreeBSD kernel code making its way into Darwin (the OS X kernel). It's legal so it seems plausible enough. I have not specifically investigated this.
I don't know what it takes to be considered a BSD. OS X is missing a ports tree (Fink is available but not included by default). It's also not a direct genetic decendant of BSD, at least not in the kernel. It also doesn't feel like a BSD when you're at the command line.
1 - They don't have jail(). Grr.
I rarely criticize things I don't care about.
Oh, and *BSD is more ready for the desktop than Linux in at least one form - I've been using OS X on a desktop for some time now.
I am TheRaven on Soylent News
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
You miss a key point that BSD has over GNU: the licensing terms are commercially friendly, because a vendor can modify and embed a BSD into a product without having to offer the source code -- and this is really important for a large number of (but not all, mind you) products.
I would use it just to confuse people.
"So what do you run?"
"BSD/Linux"
"Uh...yeah...which one? Both?"
"Both? What do you mean? I just run BSD/Linux."
"Err...you men GNU/Linux?"
"No No, BSD/Linux. Linux is just a kernel, remember."
"Uhh..."
Actually, I *HAVE* updated an entire FreeBSD system from 5.2 to 5.3 remotely. Dropping down to single mode is highly highly recommended, but I didn't want to walk over to the other machine to do it, so I tried it without. And it worked.
But that aside, how does Debian get away from it? Because in Debian everything, including the kernel, is a package. Even the package manager is a package. This was been planned for FreeBSD so that everything was a package, but the project (libh) died through overengineering (second system syndrome). DragonflyBSD is working on a similar project, and I have no doubts that it will back backported.
p.s. Of course the FreeBSD documentation is four pages long. That's because the documentation is COMPLETE.
Don't blame me, I didn't vote for either of them!
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.
No. Actually I'm not.
/etc/defaults/rc.conf). This does more than simply switch programs on and off. Lots of configuration functionality is unified here. Moreover, the programs are all self-consistent. They each only depend on the features actually present and working in the other programs. e.g., a rather pedestrian example: tar has all the features in a functional state as is required by all the components in the base system.
/etc/make.conf. e.g. You dislike bind? ok, set NO_BIND=yes.
I tried the binary route, the binary version that worked only a year ago cannot work now because of the incompatibilities introduced in the system libraries. Okay fine. So I tried the source version via the packaging system. Ooops, that's broken too. So I finally built it myself _because I had to_.
But why did I have to? What was the root issue that I was trying to highlight? The system library introduced a change that broken both ABI and API without bumping library version numbers.
There lies the point I was making. That sort change is not tolerated in the FreeBSD community. It is much more tolerated in the linux community which is why the glibc maintainers could get away with it.
Now there are lots of linux distributions, and people like Red Hat take considerable pains to protect their users against changes like that. They do this because they have lots of corporate customers who tend to take the view of the FreeBSD community.
There are also plenty of linux distributions that don't seem to care.
And the glibc people seem not to care either. And as they service most of the linux community, I alleged this indicates a cultural difference.
In my experience few linux distributions seriously care about abi and api stability. e.g.., like I've said, Red Hat seems to care but in my experience Debian and Gentoo do not.
3)
At the most basic level the tools are integrated to use a common configuration system (/etc/rc.conf overriding
Assurance things are done right: sshd, sendmail, bind all come preconfigured to operate using privledge seperation. Moreover these programs are integrated into the automated maintence and reporting system. e.g., sendmail integrates with the security auditing scripts to provide weekly reports and statistics of possibly suspicious activity.
Obviously you can accomplish these sorts of things using Linux, but I have yet to find a linux distribution that had done and packaged up all the work already. For me the difference is in spending hundreds of hours configurating what I now consider basic functionality versus being assured of having it right out of the box.
3a The argument is that I'd rather use something that made one way work really well and consistently than use something that gave me several choices none of which were particularly evolved.
3b The FreeBSD base system has few required components per se. More then anything the trouble is with sysinstall which is a 10 year old program that was intended only as a stop-gap when written. The consequence of this program is that a minimal install can be as you say too bulky. However, once a system is up you can merrily disable components using
Also, your constant references to Debian are quite confusing, since Debian is one of the most conservative Linux distributions. Unless you were running another Debian version than stable in which case you should know what you are doing and you get all troubles you asked for. Debian stable has the all features you describe in BSD, and more, like backported security fixes (while all BSDs I know of offer them as upgrades to program versions). Debian stable is -STABLE, debian testing is beta and debian unstable is alpha.
You lost me completely on the tar example.
As for integration, ports routinely lack the ability to, in case of daemons auomatically include package invocation in
As for your
Obviously you can accomplish these sorts of things using Linux, but I have yet to find a linux distribution that had done and packaged up all the work already. i have to disappoint you, debian has all this stuff and fedora core too. Automated is: installing python modules, emacs packages, info files, cron jobs, boot time startups, and more, there is unified configuration system across all packages: if a package needs a particular information, there is a unified way to ask the user for it (or not, if the user wishes, this is a configuration option of configuration system).
Again, lack of a decent installation system in BSD is only the fault of BSD developers (who aren't interested in programming a decent userland).
As for choice, when you install a major distribution (Debian, SuSE, Redhat), you get one syslogger and one default desktop system. You may get and enable the alternatives later, but at the beginning there is one of a kind of each.
Your experience seems to be gentoo based, and gentoo is no major, nor a serious distribution.