Slashdot Mirror
FreeBSD June-December Status Reports
An anonymous reader wrote in to say that "FreeBSD just published status reports covering June to December '04 with many interesting details about the work that went into 5-STABLE and a look ahead on plans and projects for 6-CURRENT."
Oh, never mind!
=)
It's not offtopic, dumbass. It's orthogonal.
That's right, dead. It's about time you lot moved on...
... only old people are confirmed to be dying by Netcraft
I like the 5-stable 6-current... I think we should apply it to Microsoft OS releases too... hmm let's see...
:)
Dos 6.2-stable
Windows XP- no wait...
Windows 98- no wait...
Windows 2000 - current...
there we go...
---
Programming is like sex... Make one mistake and support it the rest of your life.
February 2005: Dead again. BOOYA!
In this article there is a better insight into BSD development.
http://url.fibiger.org/8f
This is mostly irrelevant. FreeBSD5 took a path that will end up with an unmaintainable, unscalable, inefficient kernel threading model. It's doomed to obsolescence. Recent benchmarks with NetBSD demonstrate that NetBSD beats FreeBSD in a lot of critical categories, and the NetBSD team is doing it with fewer developers. How is FreeBSD going to cope when every other OS outperforms them? They'll have to adpot a new model, and the target will likely be DragonFly.
DragonFly is making huge advances. Sweeping changes are being made all the time that make DragonFly easier to maintain and more scalable, but performance is still good on a uniprocessor system, and stability is much the same as FreeBSD4 (which many of you know is terrific). When the giant lock comes off, FreeBSD likely won't be able to hang with them. The upcoming multicore processors will just make things worse. FreeBSD6 is following the same path as FreeBSD5. If things keep going the same way, FreeBSD7 will have to be a DragonFly fork, just to stay relevant.
But will anyone care? FreeBSD is hemorrhaging developers. Right now, if the right three or four developers left, there wouldn't be enough detailed knowledge about the kernel workings to maintain the kernel without a long learning period that the FreeBSD project can't afford. Furthermore, how many of those developers will want to keep working on FreeBSD when it's just a DragonFly fork? DragonFly is positioned to replace FreeBSD, as well as fill niches that no BSD has filled before. Why would anyone want to work on FreeBSD, either as a DragonFly fork or as an obviously non-viable kernel model?
FreeBSD was nice, and is nice; I'm using RELENG_5 now, but shortly DragonFly will have a lot of its features in place, and I'll be moving to it. There are many others like me, ready to swap once DragonFly is ready, and you'd better believe that's trouble for FreeBSD.
Yup, FreeBSD is dead and confirmed by Netcraft. Too bad it can't detect my hardware properly. Or maybe the hardware can't detect FreeBSD.
its dead. it has meet the maker. its departed its no more. it is bereft of life
1) BSD and Linux make a lousy desktop. Seriously, everyone knows they are not ready yet. I would thus want to use something different on my laptop, like WinXP. This increases administration overhead.
2) BSD doesn't do SMP gracefully.
3) BSD and Linux don't have the mindshare of Windows - most interesting applications are developed for Windows and there are only mediocre Linux and BSD alternatives, if there are any at all.
4) Getting to know BSD and Linux would require getting comfortable with a new administration system for startup, shutdown, and package management.
5) Especially now, after SP2 Windows is "good enough"(tm) and getting better fast. Keep the system up to date, (Windows Update is doing a great job there) apply some sane policies to configuration and it's quite secure.
6) BSD and Linux have much more limited hardware compatability, and drivers for "cool stuff" can be hard to find.
All the above said, I might still move to BSD or Linux. Later. When I have time to. When I get a chance to play with it more. When I decide I'm ready to make the switch.
But, for now, it's WinXP for me!
pNosts. Ther3fore
DragonFly is making huge advances. Sweeping changes are being made all the time that make DragonFly easier to maintain and more scalable, but performance is still good on a uniprocessor system, and stability is much the same as FreeBSD4 (which was the last FreeBSD release which actually worked). When the giant lock comes off, FreeBSD likely won't be able to hang with them. The upcoming multicore processors will just make things worse. FreeBSD6 is following the same path as FreeBSD5. If things keep going the same way, FreeBSD7 will have to be a DragonFly fork, just to stay relevant.
But will anyone care? FreeBSD is hemorrhaging developers. Right now, if the right three or four developers left, there wouldn't be enough detailed knowledge about the kernel workings to maintain the kernel without a long learning period that the FreeBSD project can't afford. Furthermore, how many of those developers will want to keep working on FreeBSD when it's just a DragonFly fork? DragonFly is positioned to replace FreeBSD, as well as fill niches that no BSD has filled before. Why would anyone want to work on FreeBSD, either as a DragonFly fork or as an obviously non-viable kernel model?
FreeBSD was nice, and is nice; I'm using RELENG_5 now, but shortly DragonFly will have a lot of its features in place, and I'll be moving to it. There are many others like me, ready to swap once DragonFly is ready, and you'd better believe that's trouble for FreeBSD.
"Gillespie, this bitch is dead. Get the meat wagon . . ."
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.
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 formerly acclaimed TCP/IP stack has lagged behind, according to this study.