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.
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.
a) linux is FAR more diverse, both in distros and in software available
A smaller, but stable and fully functional software base is far better than a greater software base full of software that is broken and can't even build (Gentoo has bad bad kung fu and you know that USB support on Linux is a joke). Not every kind of diversity is productive and Linux proves that point very well, its diversity is typical of inbreeding, you keep getting more and more horrible freaks all in the same family.
b) linux performance in LAMP applications is generally accepted to be better now, sorry but it's true. Unless you take your statement to mean that performance AND tranquility in which case it's just a preference either way.
Keep dreaming, FreeBSD beats the pants off Linux (1Mpps vs. 100kpps). And if you were not a Linux user you would see the poem was a counter-troll to a troll about BSD dying. Linux has its merits, but BSD is my favorite for many reasons and as long as you Linux folk keep badmouthing BSD you will get a very bitter taste of your own medicine because it's based on undeniable facts. Read it and go weep with Tux, he could use some company.
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!
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.