Slashdot Mirror
DragonFly BSD Announces 1.0RC1
CoolVibe writes "Matt Dillon announced the availability of DragonFly BSD's 1.0 Release Candidate #1. Get it at Dragonfly BSD's site (please use a mirror or post mirrors as comments). Changes and features include: variant symbolic links, UDF support, lightweight kernel threads, message passing, GCC 3.4 in the tree, binutils 2.14, Kernighan's awk 2004-02-07, BIND 9.2.4 rc4, CVS 1.12.8, libpcap 0.8.3, tcpdump 3.8.3, less 381, MMX/XMM kernel optimizations are now on by default, greatly improving bcopy/bzero/copyin/copyout performance for large (>4K) buffers, XIO, acpica5, new AC'97 codec support, network stack revamping, long standing bug fixes for wide variety of support and stability issues, and way, way, way more. A new installer is also in the works that uses DragonFly's new CAPS IPC mechanism. The installer beta is available from LiveBSD. (Not updated to RC1 just yet, but it gives a nice idea of the progess made)"
MD5sum: MD5 (dfly-1.0RC1.iso.gz) = 663bc0ce4c077c4eeb38792e846210ea
Additionally, a torrent and list of mirrors are also available.
www.sitetronics.com/wordpress
Hahaha, BSD IS DEAD. Cato er deilig, alle vil ligge med cato!
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
May I ask what a "variant symbolic link" is?
www.eFax.com are spammers
Support for variant symbolic links is exciting. That makes it really easy to support 64/32-bit modes on Opteron systems. Similarly, it makes it easy to support variant ABIs for (e.g.) C++ runtime environments without encoding ABI versions into library names, but do look out for combinatorial explosion...
http://www.pentarou.org/files/bsd.jpg
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
I think this project is a good model for how large projects should be handled.
They published their design and a roadmap for implementing their design. This
makes it easier for a lurker who is watching the project to actually jump in
and contribute to it.
At least, it seems that way in theory. Anyone have any idea how responsive the
community has been to this project?
*sigh* back to work...
Uh, anyone want to give an idiot like me a concise and clear reason why DragonFly BSD is superior to the other BSD variants? What specific applications is it more suited towards?
No, I'm not trolling, but thanks for asking.
Karma: Chevy Kavalierma.
I've been using it since february, and let me tell you, it's great! It's fast, and generally stable (between major changes, it is a prerelease OS don't forget!), and it runs legacy Linux and FreeBSD binaries at native speeds.
;^)
And it is being redesigned at it's core to be a clustering capable operating system (although this is not in just yet). Soon it will be able to run user mode drivers, greatly enhancing the stability of the system to levels that no other current OSS project can boast (and still be telling the truth
This truely is what a modern UNIX-like OS should be!
Way to go Matt and the rest of the DragonFly team!
Who would have thought that such a poor actor could help out the *nix community so well.
What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0
Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.
Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.
These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.
As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.
The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.
message passing == micro-kernel ?
Your CPU is not doing anything else, at least do something.
You're pushing buttons. The initial question was answered fairly
For the record, I've found the DragonFly user and developer community to be the most helpful I've ever encountered online, but if you're not even going to quickly go over the information on the web site, they are under no obligation to repeat what is freely, and publically available information, that has been there right out in the open from day one.
I've asked my fair share of dumb questions, but I've also read the web site. This should come as common sense, but I guess that I am greatly overestimating the mental capacities of the general Slashdot population (yourself included).
Dipshit.
ProPolice enabled by default, replacing of unsafe string functions from many ports, systrace, etc.
Joder... Quien será el zampabollos que siempre está liado con la misma chorrada??????... Como decía Ford Fairlane; "tanto gilipoyas y tan pocas balas..."
Ok ok ok... I know... This is an english site, but more important is this is a international site!! XDD
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.
Stop your blathering fuckwit.
Who does the code audits? To what standard are they held?
Oops, you just fell for Theo's propaganda.
W^X, ProPolice, randomized shared library loading. All of these happen to ANY program compiled from source, with or without code auditing, and make overflows pretty damn hard to exploit, probably impossible.
And yet Linux does all this and more, and yet it is supposedly insecure crap thrown together by school boys.
Why? we ask? Oh, because Linux focuses on umm features and err stuff and isn't umm secure and err code feature secure audit df dflj asdfl;ja sdfl;jasdf.
Linux doesn't do any of those, since it's just a kernel. Some distros might hack in something like PAX, but its nowhere near as pervasive and as well tested as on OpenBSD - it takes toolchain support for randomised shared libraries, and OpenBSD also fixed a lot of bugs in Propolice while integrating it, showing noone else has seriously tried it to use it before across multiple architectures.
Oh I didn't even mention stuff like StackGhost on sparc...
Duh, Linux does "W^X", aka non executable mappings in non-leet speak. It does randomized shared library loading, and this doesn't require toolchain support in Linux, probably because its design is cleaner than OpenBSD's.
Linux can quite easily be built with propolice, and it has a very fine security infrastructure with SELinux. More advanced than what OpenBSD has.
Lastly, Linux gets its code audited, by Linux distro companies, and by the likes of IBM, SGI, NEC, Intel, AMD, Sony, Toshiba, HP, Transmeta, CISCO, TI, Dell, Motorola, Nokia, Bosch, MIPS, Google, to name a few larger ones. Really audited, I mean. Not just "OpenBSD style audited", which amounts to no more than grepping for a few string functions. I mean properly audited.
Oh, what's that you say? What is your incredible retort? Theo is a cock smoker? Yes, I already knew that, that doesn't change anything.
Linux does "W^X", aka non executable mappings in non-leet speak
/usr/libexec/ld.so /usr/lib/libtermcap.so.9.0 /usr/lib/libc.so.30.3 /usr/local/bin/bash /usr/libexec/ld.so /var/run/ld.so.hints
... except via PAX, although I'll be glad to be corrected. Of course, not many major distros actually use PAX or Propolice, where OpenBSD delivers tested binary packages for 10 (or whatever the current number is) different architectures. I'm not interested in security where I have to patch and recompile my entire OS.
No it doesn't. W^X ensures that there are no pages in a process's address space which are writable and executable and separates them. Not just a non-exec stack. For example on i386:
0250B000 24K read/exec
0280A000 4K read/exec [ uvm_aobj ]
06B04000 188K read/exec
0861F000 508K read/exec
1C000000 348K read/exec
2250B000 4K read
2250C000 4K read/write [ anon ]
(trim)
7EB90000 4K read/write [ anon ]
865FF000 12K read
CDBFE000 28672K [ stack ]
CF7FE000 4040K read/write [ stack ]
Notice how the exec mapping stop, and the write mapping begin. This means on i386 the segment registers can be used to enforce read/write/execute - you dont need a new processor with per-page NX (although that works as well of course).
It does randomized shared library loading, and this doesn't require toolchain support in Linux, probably because its design is cleaner than OpenBSD's
Vanilla Linux doesn't
Linux can quite easily be built with propolice, and it has a very fine security infrastructure with SELinux. More advanced than what OpenBSD has.
Very funny. The average sysadmin understands the UNIX security model. Not many understand the insanely complex SE Linux thing.
Linux does a lot of things better than OpenBSD, but really, security just isn't one of them. I always regret posting to Slashdot to try to correct some of the cluelessness here, so this will be my last post here for a while again.
I ditched FreeBSD when Jordan quit. That was it. That was the day when FreeBSD died. I don't give a stinking fuck about some dragonflybsd!
I want to put my pee pee in your poo poo hole.
Oh, the cluelessness? Like this perhaps?
... except via PAX, although I'll be glad to be corrected. Of course, not many major distros actually use PAX or Propolice, where OpenBSD delivers tested binary packages for 10 (or whatever the current number is) different architectures. I'm not interested in security where I have to patch and recompile my entire OS.
Linux doesn't do any of those, since it's just a kernel.
Duh, it wouldn't be the KERNEL's job to enforce non executable mappings, it wouldn't be up to the KERNEL to randomise shared library loading. Idiot.
No it doesn't. W^X ensures that there are no pages in a process's address space which are writable and executable and separates them. Not just a non-exec stack. For example on i386:
Vanilla Linux doesn't
Actually, PAX can do both those things. I use a distro which supports PaX, and more architectures than OpenBSD.
Very funny. The average sysadmin understands the UNIX security model. Not many understand the insanely complex SE Linux thing.
Well you would say that because in your eyes, OpenBSD is the best. Actually SELinux is very useful.
I saw "continuation of FreeBSD 4" and got excited, but then I saw "GCC 3.4" and got disappointed.
Give me a compiler that doesn't require a Quad Xeon to compile KDE in under a month, please!
it seems the moderators are too busy modding down people they disagree with to be bothered with posts like the grandparent. oh well. maybe they can at lest mod this down since it points out how much the mods suck today.
i like to browse at 0 so i can read Anonymous comments because usually they are about as insightful as comments by people with karma. (i guess i should see if there's some way to disable the karma bonus modifier in my viewing preferences). anyway, usually browsing at 0 works because posts such as the grandparent, as well as GNAA and BSD is Dying trolls get modded down almost immediately to -1. in conclusion, i'd just like to mention once again how much the moderators suck today.
moderators, you all suck today.
Or you could just click on the link I posted above
s/above/below
MORTAR COMBAT!
Hahah! Beat you twice.
Yet another sickening blow has struck what's left of the *BSD community, as a soon-to-be-released report by the independent Commision for Technology Management (CTM) after a year-long study has concluded: *BSD is already dead. Here are some of the commission's findings:
.005% of internet servers. A recent attempt at a face-to-face summit in Boulder, Colorado culminated in an out-and-out fistfight between core developers, reportedly over code commenting formats (tabs vs. spaces). Hotel security guards broke up the melee and banned the participants from the hotel. Two of the developers were hospitalized, and one continues to have his jaw wired shut.
Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.
Fact: the *BSDs have balkanized yet again. There are now no less than twelve separate, competing *BSD projects, each of which has introduced fundamental incompatibilities with the other *BSDs, and frequently with Unix standards. Average number of developers in each project: fewer than five. Average number of users per project: there are no definitive numbers, but reports show that all projects are on the decline.
Fact: X.org will not include support *BSD. The newly formed group believes that the *BSDs have strayed too far from Unix standards and have become too difficult to support along with Linux and Solaris x86. "It's too much trouble," said one anonymous developer. "If they want to make their own standards, let them doing the porting for us."
Fact: There are almost no FreeBSD developers left, and its use, according to Netcraft, is down to a sadly crippled
Fact: NetBSD, which claims to focus on portability (whatever that is supposed to mean), is slow, and cannot take advantage of multiple CPUs. "That about drove the last nail in the coffin for BSD use here," said Michael Curry, CTO of Amazon.com. "We took our NetBSD boxes out to the backyard and shot them in the head. We're much happier running Linux."
Fact: *BSD has no support from the media. Number of Linux magazines available at bookstores: 5 (Linux Journal, Linux World, Linux Developer, Linux Format, Linux User). Number of available *BSD magazines: 0. Current count of Linux-oriented technical books: 1071. Current count of *BSD books: 6.
Fact: Many user-level applications will no longer work under *BSD, and no one is working to change this. The GIMP, a Photoshop-like application, has not worked at all under *BSD since version 1.1 (sorry, too much trouble for such a small base, developers have said). OpenOffice, a Microsoft Office clone, has never worked under *BSD and never will. ("Why would we bother?" said developer Steven Andrews, an OpenOffice team lead.)
Fact: servers running OpenBSD, which claims to focus on security, are frequently compromised. According to Jim Markham, editor of the online security forum SecurityWatch, the few OpenBSD servers that exist on the internet have become a joke among the hacker community. "They make a game out of it," he says. "(OpenBSD leader) Theo [de Raadt] will scramble to make a new patch to fix one problem, and they've already compromised a bunch of boxes with a different exploit."
With these incontroverible facts staring (what's left of) the *BSD community in the face, they can only draw one conclusion: *BSD is already dead.
Hahah! I pounded your mom three times.
Well I actually didn't. I just said that to provoke a response and obviously have absolutely no proof because I am lying through my teeth.
But I'm sure you would never do something like that.
Heheh!
Very true, and very misunderstood, judging by the people commenting on how bleeding edge it is.
It's seemed to me that once the messaging system is fully in place, DragonFly will have an incredibly simple, extensible, and stable API on which to build, and that a number of features that both Linux and FreeBSD now have will be much simpler to implement on DragonFly in the not too distant future, and will end up being far less hackish than the current solutions.
It's unfortunate that supposedly technically competant people get so enthralled by buzzwords and hype that they will cling to technologically inferior solutions or ideas, despite the fact that it is both relatively painless for them to adopt or otherwise incorporate the newer technology that's free to boot.
In the end though, while Linux will require corporate hand-holding (funding, marketing) and hand-me-downs (code ripped from proprietary UNIXes and welded into Linux) in order to keep growing, DragonFly will be able to stand well enough on it's own, with the developers being able to add new functionality easilly enough on their own time and on their own terms.
Perhaps a decade or so from now, Linux will be in a similar position to the one Windows is in now, and DragonFly will be there to provide a much needed alternative.
Yet another sickening blow has struck what's left of the *BSD community, as a soon-to-be-released report by the independent Commision for Technology Management (CTM) after a year-long study has concluded: *BSD is already dead. Here are some of the commission's findings:
.005% of internet servers. A recent attempt at a face-to-face summit in Boulder, Colorado culminated in an out-and-out fistfight between core developers, reportedly over code commenting formats (tabs vs. spaces). Hotel security guards broke up the melee and banned the participants from the hotel. Two of the developers were hospitalized, and one continues to have his jaw wired shut.
Fact: DragonflyBSD, yet another offshoot of the beleaguered FreeBSD "project", is already collapsing under the weight of internal power struggles and in-fighting. "They haven't done a single decent release," notes Mark Baron, an industry watcher and columnist. "Their mailing lists read like an online version of a Jerry Springer episode, complete with food fights, swearing, name-calling, and chair-throwing." Netcraft reports that DragonflyBSD is run on exactly 0% of internet servers.
Fact: the *BSDs have balkanized yet again. There are now no less than twelve separate, competing *BSD projects, each of which has introduced fundamental incompatibilities with the other *BSDs, and frequently with Unix standards. Average number of developers in each project: fewer than five. Average number of users per project: there are no definitive numbers, but reports show that all projects are on the decline.
Fact: X.org will not include support *BSD. The newly formed group believes that the *BSDs have strayed too far from Unix standards and have become too difficult to support along with Linux and Solaris x86. "It's too much trouble," said one anonymous developer. "If they want to make their own standards, let them doing the porting for us."
Fact: There are almost no FreeBSD developers left, and its use, according to Netcraft, is down to a sadly crippled
Fact: NetBSD, which claims to focus on portability (whatever that is supposed to mean), is slow, and cannot take advantage of multiple CPUs. "That about drove the last nail in the coffin for BSD use here," said Michael Curry, CTO of Amazon.com. "We took our NetBSD boxes out to the backyard and shot them in the head. We're much happier running Linux."
Fact: *BSD has no support from the media. Number of Linux magazines available at bookstores: 5 (Linux Journal, Linux World, Linux Developer, Linux Format, Linux User). Number of available *BSD magazines: 0. Current count of Linux-oriented technical books: 1071. Current count of *BSD books: 6.
Fact: Many user-level applications will no longer work under *BSD, and no one is working to change this. The GIMP, a Photoshop-like application, has not worked at all under *BSD since version 1.1 (sorry, too much trouble for such a small base, developers have said). OpenOffice, a Microsoft Office clone, has never worked under *BSD and never will. ("Why would we bother?" said developer Steven Andrews, an OpenOffice team lead.)
Fact: servers running OpenBSD, which claims to focus on security, are frequently compromised. According to Jim Markham, editor of the online security forum SecurityWatch, the few OpenBSD servers that exist on the internet have become a joke among the hacker community. "They make a game out of it," he says. "(OpenBSD leader) Theo [de Raadt] will scramble to make a new patch to fix one problem, and they've already compromised a bunch of boxes with a different exploit."
With these incontroverible facts staring (what's left of) the *BSD community in the face, they can only draw one conclusion: *BSD is already dead.
The problem with a 'startup' is that if you decide to rely on it and they disappear down the road, you are screwed..
At least with the "big 3" you can be reasonably assured they will be around in another 10 years..
Not to slight what the dragonfly people are doing, its really great... But its still in its infancy..
---- Booth was a patriot ----
What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0
Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.
Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.
These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.
As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.
The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains more and more market share and as BSD sinks ever deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.
I want to put my pee pee in your poo poo hole. Also, Mary-Kate Olsen makes one hot corpse.
Most ammusing post ever. Man, you should write for Slashdot. The Linux crowd will love you as they love this sort of garbage! Way to go!
Matt Dillon put RC2 on the download page.
It's also available via BitTorrent.
...the BSD is the only pray to stand ground to server predator, the Slashdot!
Soar grapes!