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."
I was just watching the movie "Over the Edge" the other day, and wondered whatever happened to Matt Dillon.
"There is an interesting interview with Matt Dillon..."
Nearly 3 hours later and nothing but Troll/AC posts. Either BSD really is dead and no one cares, or some people have a different understanding of the word interesting.
I don't usually answer AC & trolls, but in this case I have to put something straight.
Jordan Hubbard resigned mainly (AFAIK) because he was offered a job at Apple, which incorporated FreeBSD in OSX, making the # of UNIX installations in general and *BSD installations in particular a multiple of before in a flash.
At the moment, including OSX, FreeBSD is by far the most widespread Unix variant.
This troll rules. Not only do the same desktop GUIs work across all *NIX platforms, but you resurrected the Debian/BSD, which was abandoned. Bravo.
as for the rest, I'm not talking about GUIs. I'm talking about support for the whole system.
I know I should not feed the trolls, but I can inform you that Xfce works very well on OpenBSD, and so does KDE. If only Firefox could render Slashdot properly, but that is not an OpenBSD problem ;-)
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!
Shut up. Just shut the fuck up. Can't you help yourself? You've had 10 years to reply to BSD is dying trolls. You stupid moron, they don't do it because they think BSD is dying or because they care about being exposed as trolls. They do it because you respond.
The *BSDs must be dead by know! I've been hearing the same thing for the past 7 years! (Thats when I dropped Linux in favor of using FreeBSD)
:).
:)
BSD users in general love *NIX for *NIX sake! we don't dilike other OS's as much as some groups of people, so we tend to be lurkers with less political motivation driving us(there are always exceptions)
Hell is still a very hot place, just ask the Beastie
RPR.
HA HA WHAT ABOUT GCC
Hello? Bueller????
a;ldskjfadfjdjjdd
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". I understand more about FreeBSD than OSX but I believe OSX is decendend from NeXT which was descendend from BSD Unix but with a different kernel.
Like the post said, "it's already in BSD".
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.
All joking aside, I would like to see a *BSD get to the point where its "year of the desktop" might be as close as Linux's currently is. I tried Free and OpenBSD, and although they are both nice systems, they hold little appeal over Linux outside of the server market, and especially lag behind on the issue of desktop usage. That being said, I would pick OpenBSD for a public server over any Linux distro in a heartbeat... if it was important enough to justify learning the *BSD ins and outs.
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."
I completely agree with you about GNU/BSD. Although I think it would be interesting to see BSD running on a Linux kernel, BSD/GNU.
"so we tend to be lurkers with less political motivation driving us(there are always exceptions)"
What I find interesting is that so many of the prominant BSD people are former Amiga users. This is true of both Dillon and de Raadt (leaders of the two BSDs with recognizable leaders).
I rarely criticize things I don't care about.
What a lame post. Even if you have a point, your anger makes you sound like a linux user more than a bsd user... ;)
And:
"They do it because you respond".. nope. He does it (it's one person, if you still have't realized) to spread FUD over BSD.
But I totally agree that it's better *not* to reply.
"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.
There's one or two things I miss from GNU, but the sh-utils port has them...
I rarely criticize things I don't care about.
Yea, if there is a good userland in BSD - why cant I upgrade one release to another, automatically and remotely with the only reboot to switch kernels?
You can.
I don't understand what you're asking. The ability to do this has been around since day one.
Don't blame me, I didn't vote for either of them!
Shut up. Just shut the fuck up. Can't you help yourself? You've had 10 years to reply to BSD is dying troll responders. You stupid moron, they don't do it because they don't think BSD is dying or because they care about exposing trolls. They do it because you respond.
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.
It's not really missing a ports tree. Now there is Darwin Ports which is written, at least in part, by Jordan Hubbard, who also created the ports system on FreeBSD. It uses Tcl as its scripting language, and all the "portfiles", which are similar to the port makefiles on FreeBSD, are written in Tcl. It's fuller featured than FreeBSD's ports, but has far fewer ports available. I personally prefer it over Fink.
You had me at "dicks fuck assholes".
Kelley was a SysV fanboi.
The record is clear on one thing: no operating system has ever come back from the grave. Efforts to resuscitate *BSD are one step away from spiritualists wishing to communicate with the dead. As the situation grows more desperate for the adherents of this doomed OS, the sorrow takes hold. An unremitting gloom hangs like a death shroud over a once hopeful *BSD community. The hope is gone; a mournful nostalgia has settled in. Now is the end time for *BSD.
a) linux is FAR more diverse, both in distros and in software available
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.
I am tired of the constant BSD trolling that linux is technically inferior, they both have pros and cons so stfu.
I mentioned Fink, which does much the same thing. My point was that it's not included by default, which is still true.
I rarely criticize things I don't care about.
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..."
NeXT is no more BSD Unix based or descended from then OS X is based or descended from FreeBSD.
No more than, perhaps, but both statements are true to a certain extent. NeXTStep was the Mach microkernel with a 4.3 BSD userland (plus some GNU software, like gnutar and gcc) and NeXT's proprietary GUI (DisplayPostcript, etc.). OS X is the Darwin kernel with a (mostly) FreeBSD userland plus some GNU software and Apple's proprietary GUI (some parts of which are quite similar to DisplayPostscript, but PS is no longer used to due to Adobe's expensive licensing fees).
"It's better to keep your mouth shut and be thought a fool than to open it and remove all doubt."
I think the issue is actually deeper
According to the GNU/Linux/GPL philosophy a girl having sex only with you is against freedom - since it actually means that she's "closed", and this shouldn't happen because what is open for you must be open for anybody else as well - it's a matter of freedom.
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.
And this will almost for sure overwrite some config files.
If the upgrades would be the way I like, I wouldn't have to UNINSTALL applicaction packages before doing an upgrade, as this page suggests. I wouldn't have to add system users by hand.
To upgrade a Debian system to a next release, all I have to do is modify ONE config file, do
, , then answer a few questions and do a reboot. Description BSD way of system upgrade is FOUR pages long...This is the userland I'm talking of, not firefox.
BSD way of doing things is fine as long you have one machine to take care of. If you have a server farm to upgrade, good luck.
And yes, I did manage BSD servers for a living. Now I wouldn't touch them with a four meter pole.
Oh, there is plenty. Package management first comes to mind. Ports are a poor imitation of one.
Taking responsibility for the whole system and not only tiny handful of commands that are enough to make the system a DNS server or a firewall, but nothing more (almost all useful - in the real world sense - programs are in ports which aren't officially supported).
Commercial vendors can also write a proprietary driver withough causing a shitstorm in the kernel mailing lists.
Don't blame me, I didn't vote for either of them!
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!
Well, latest freebsd migration documentation is 9 screens long in my browser, twice as long as the one for openbsd.
Yes, in debian everything is a package. All I can say, is that it is really not my fault that great hackers working on FreeBSD couldn't make a decent packaging system. APT is a extendable system and probably could be adapted with less effort than making a whole new solution.
But again, this supports my original thesis, which is that BSD people aren't really interested in making a decent operating system, because a software management system is a essential part of one. But everyone wants to hack on a kernel it seems. A pity.
And (freebsd's) nineteen steps upgrade algorithm for a modern operating system in 21st century is simply [expletive redacted] ridiculous.
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.
>>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
In case you didn't know, they supposedly reached 1Mpps _forwarding_ in a highly specialised environment. The most significant thing was that fast forwarding was turned on, which basically takes the operating system out of the equation and does NIC-NIC forwarding on the bus. Of course, this breaks down if you want to do much useful with the packets.
But what's even funnier is that the FreeBSD guys have no idea what Linux can do. This guy is routing 2.1Mpps on a dual opteron with 4 NICs, 2 bound to each CPU. This shows that he could do over 1Mpps on a single opteron CPU with 2 NICs - more impressive than the FreeBSD result of 1Mpps with DUAL Xeons.
>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
And what's funnier again, is that the routing performance document you cited is a *very* specialised workload that not a lot of people will use FreeBSD (or Linux) i386 PCs for.
The OP was talking about LAMP performance, which is to say, a typical database driven webserver. In which case, you might find this enlightening.
DragonFly??? Can we get a name that doesn't
suck so much?
Yes, it would be nice to build a Linux distro that doesn't have the GNU userland.
"What OS does that thing run?"
"BSD+Linux"
"Don't you mean BSD+GNU/Linux?"
"No, the GNU userland isn't there, so it's not GNU/Linux"
*RMS' head explodes*
Moll.
What you hear in the ear, preach from the rooftop Matthew 10.27b
You tried to hand-compile something on linux, while you are comparing this to getting something from ports. You are comparing stuff from the wild, with prepackaged one. I didn't say that there is no packaging on BSDs, What I said is that ports are poor packaging system.
As for your troubles with pm3 installation: this is what you get when you want to use bleeding edge. I personally can't remember when I did compile some piece of software I'm not working on myself. I exclusively use precompiled packages, This way I can comcentrate on doing important stuff, while I don't have to waste my time on uninteresting things, like - for me - pm3 installation. I Would simply apt-get it then use it. The same as for your usage of ports.
As for rest of your comments:
1: This is not very interesting from the real world point of view (i.e. you can't make money out of it) isn't it?
2: All major Linux distributions give me this.
3: I don't see any way of tools integration in BSD, care to elaborate?
3a: this is not an argument
3b: The packaging framework is the core of an OS. I install the core, then I decide which role the system has to fullfill then I install the tools needed. There are 10000+ software packages in Debian, there is no sense in instaling all of those. There is no sense in having a compiler on DNS server. There is no sense in having Samba on database server, and so on and so on.
LiMP = Linux, Mysql, PHP
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.
"Well IF you OWERWRITTEN the system libc,by hand, with another version, thats asking for trouble. And I can't see a way you should do this. If you want to have another version of lib*, and necessarily put in by hand, yoou put it in /usr/local and dynamic loader gives the program the one it needs. If you upgrade libc via a system upgrade, all apps that reference the given ABI get upgraded too."
ld simply doesn't work the way you think it does. The only way to maintain ABI and API compat is to ensure any change that breaks either of those two things is coupled to a change in the library version number. I maintain that the glibc developers do not respect this idea. Now, they would have a way out if linux supported minor library version numbers (like Sun) but linux does not.
"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)."
No, it's a question of what is packaged up.
Many of us believe that the FreeBSD userland is superior to that available else where. In fact, that has been the entire point of my commentary. Thus, it is very unmoving for you to simply assert that they aren't interested in programming a decent userland. We obviously disagree as to what that entails. Thus, I reiterate, there is a cultural difference.
Debian's conservativism is not really relevant. The fact is that I need access to gcc >3.3 for it's c++ compliance. gcc >3.3 depends on glibc >= 2.2.5. Glibc 2.3 can not coexist on a system with glibc 2.2.5. Thus, being presented with a program that was broken with glibc > 2.2.5 I faced a problem. I assure you that Debian Stable does not resolve this conflict in any fundamental way.
Resolving it requires any of the following
1) Not breaking ABI/API within library versions
2) Permitting ld to understand minor library version numbers so that versions can be bumped for big and small changes
3) Forcing programs to be recompiled and/or souce modified.
FreeBSD is very aggressive about ensuring #1. To do that, they carefully control all the facets of the system. gcc is heavily patched on freebsd. they maintain libc themselves, etc. They ensure that the major iterations can coexist on the same system. Thus, I can install compat bits for FreeBSD 2.2, 3, 4, etc. The result being that on a brand new, gcc 3.4, freebsd libc.5 system, I can still run that binary that was built 8 years ago for FreeBSD 2.2 but whose developer has fallen off the face of the earth and taken the source with him.
Debian -STABLE does not to my knowledge offer such functionality. If you wish to argue otherwise, I'm listening...
That speed record is a joke because NetBSD doesn't even support SACK, which is basically a requirement for doing real work over long fat pipes.
There is no reason to through out the superior BSD userland
There is this tiiiiny little thing called GCC that you BSD guys use...
Open Source Java Web Forum with LDAP authentication
I think one could avoid the libc problems using some options of ld, and linux supports versioned symbols in libraries, but checking this would be a long and boring process. I won't check it unless someone pays my consulting fee to do it.
As for the rest: ability to run the very rare and usually not needed 8-years old binary is not an advantage when you have to spend five times more on routine system maintenance. This is what makes userland superior - convenience and ease of usue for the users and sysadmins. And ALL BSDs suck to the great extents in this departament (again, I'm NOT talking about running some GUIs).
Read the article I referenced http://quiston.tpsa.com/antirant.txt to see what I'm talking about.
If one admin can support 2-3 BSD machines, and 20-30 linuxes, the choice os obvious, no matter if you could run your grand-grandfather's Difference Engine card stacks on it.
Actually, what you call minor is what many call essential. And now you see the cultural difference. You think that it minor. Not everyone does. Especially when practically, what's important is that the binary from a year ago or two years ago or three years ago runs.
As for management time: Our department used to maintain primarily BSD (~150 machines) and with several dozen Suns and an equal numberof HP-UX machines. One part-time admin managed this configuration. Since then all the systems switched to Linux. We now have three admins who are always back-logged.
My conclusion from this + what you've said, is that neither of us has seen an stastically signifigant sample.
There is a sad reality in the VLSI industry that CAD tools from 10, 15, 20 years ago are often better for specific tasks than the modern packages from say Cadance.
The article you reference is at best dated. FreeBSD tracks security issues in ports very closely, port maintainers tend to fix them immediately or at the very least the port is marked with what's wrong. I cannot say the other BSDs do this--I don't think they do.
Thus, the allegation of organization separation is overly inflated. There are kernel people and legions of userland people and hundreds of ports maintainers without direct affiliation.
*However*, port security is monitored centerally and advisories are posted for all ports. They are however not posted in the web-page list about the base system.
Your idea though that the OS distributor should patch and maintain every possible piece of software is crazy. When selecting software for a production environment, you either 1) buy it from someone who will release bug-fix only patches
or 2) select Open Source that values the same.
Also, let me take this opportunity to let you know that FreeBSD has incredibly good support for running linux binaries. You can download and install the RedHat libraries and use the redhat binaries, etc, etc.
The packaging issue is not a security issue or a bug-fix issue, it is much more about library version management. Noone yet does this right, but dragonfly has a nice basic proposal. FreeBSD's policies are an approximation closer to handing this issue (within the bounds of the base system libraries).
This whole OSX is FreeBSD rumor is based on aanother rumor regarding Tiger. Apparently, Tiger's new kernel will mash the Mach microkernel with FreeBSD 5.0's kernel.
After all, I am strangely colored.
Count on an AC to know what needs to be done to a long, fat pipe.