Slashdot Mirror
FreeBSD 4.11-RC2 Available
hugo_pt writes "The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 4.11-RC2. This is the second of three scheduled release candidates. At the moment there are no known severe issues. However the Linux Emulation subsystem (mostly added as a package) has been completely updated based on Red Hat 8.0. We would appreciate people testing the Linux emulation support. In particular testing to see if Linux applications continue to behave correctly if the linux_* packages get installed while using sysinstall(8) during the initial installation of the machine. The package set for disc1 is still being decided on, what is on disc1 for this RC will most likely change before the release."
dont you feed the trollz. 1st post.
Best BSD!
Forgive my ignorance, since I don't usually follow the FreeBSD distro (having moved from NetBSD to RedHat over four years ago). But it seems a bit late to be targeting the Linux emulation towards RedHat 8.0. Not only has RedHat 9 already been obsoleted by Fedora, but 8.0 was extremely short-lived (even by RedHat's usual release timeline) having had numerous problems. In addition, before the days of RedHat Enterprise, RedHat recommended that users requiring stability stick with 7.2 (or something around there).
Will there be support for other Linux distros or what?
They can't even emulate a dead Linux distribution.
Haha - this is just so funny.
It's funny that this comment is rated "Score:1, Informative" (as of this posting) considering that the "Best BSD" it links to is NetBSD rather than the actual topic of this story, FreeBSD.
[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
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 the Amazing 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
In Soviet Russia, the BSD community hits the crippling bombshells.
FreeBSD:
FreeBSD, Stealth-Growth Open Source Project (Jun 2004)
"FreeBSD has dramatically increased its market penetration over the last year."
Nearly 2.5 Million Active Sites running FreeBSD (Jun 2004)
"[FreeBSD] has secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames and half a million active sites since July 2003."
What's New in the FreeBSD Network Stack (Sep 2004)
"FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Linux can't do much more than 100kpps."
NetBSD:
NetBSD sets Internet2 Land Speed World Record (May 2004)
NetBSD again sets Internet2 Land Speed World Record (30 Sep 2004)
OpenBSD:
OpenBSD Widens Its Scope (Nov 2004)
Review: OpenBSD 3.6 shows steady improvement (Nov 2004)
*BSD in general:
..and last but not least, we have the cutest mascot as well - undisputedly. ;)
Deep study: The world's safest computing environment (Nov 2004)
"The world's safest and most secure 24/7 online computing environment - operating system plus applications - is proving to be the Open Source platform of BSD (Berkeley Software Distribution) and the Mac OS X based on Darwin."
--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.
"It's a fact, FreeBSD is dying"
HOLY SHIT! This post BLOWS A FUCKING WHEEL off *BSD's rickety charnel wagon. I'm going to read it again, to see if it has the same impact the second time round...().. FUCKING HELL IT DOES. How can any BSD fork honestly continue after these earth shattering revelations? Stop all the clocks, and STOP THE DOG barking with its juicy bone. *BSD's shiny new Pointiac has just been shown to be a tottering house of cards...cards with dynamite attached, and Mike Smith has just pressed the detonator marked "Double Danger".
...()...YES... I read it again. It's fantasmagorical! Christ I love this post. POST IT MORE. kthnx.
This post is a brilliant swipe at those who think they're in the know, but aren't. It destroys them, dissects them like a master scientist dissecting some kids kidney against their parents wishes, rips apart their ego driven pursuit of superiority. I love the tone - it logically, coherently kicks ass in the most awesomely devastating way possible. How come there are no news stories about this post, it deserves a front page all to itself.
Is there some conspiracy to try and silence this lone voice of terrible reason? I think so, and it is clear what is to be done. Post this again and again, anonymous coward, so we can for a moment be transported back to the beautifully clear and precisely logical world of super-coherence that this post conjures up every time
the issue I had was with some closed-source (sigh) software that was linked against old old libc. it was a $200 mp3 encoder that I bought and ran fine under RH6.x. but never under later versions. even running this binary under modern LINUXs caused problems. this being the best encoder I have ever heard - and having paid $200 of my own money for it - I really wanted this to work. and since I'm now a 100% freebsd user, I needed this to work with bsd.
it does now. I'm sooo happy about it. finally I can get rid of all my linux compute-servers on my mp3 render farm. they are now all 4.11 bsd boxes and couldn't be happier.
I'll probably submit this to the bsd guys, but it would be nice if they included these files as well. I needed them for this last level of linux emulation:
compat/linux/lib/libc.so.5
compat/linux/lib/li
compat/linux/lib/ld-linux.so.1
those get you libc (not glibc) compat, from what I can tell. when I did an LDD on the mp3 encoder binary, it showed this:this is the first time since freebsd 3.4 (I think) that I've gotton this old linux binary to run under freebsd.
again, yay!
great work guys. you made my week.
--
"It is now safe to switch off your computer."
Can someone clarify FreeBSD's terminology? I thought a release candidate was different from a beta (known in FreeBSD-speak as a -STABLE).
Usually with a Linux base update there is a package for it. So far the only ones available are:
linux_base-6.1_6
linux_base-7.1_7
The package spare those of us with limited bandwidth from having to download a billion rpms and the tools needed to manage those rpms.
The difference has to do with the types of changes that can be committed. Basically, it is harder to get a change approved after the RC stage.
Check out the FreeBSD Release Engineering page for more info.
(S(SKK)(SKK))(S(SKK)(SKK))
Once I had a cat who had feline leukemia, and we tried to keep him alive, with numerous trips to the vet. But, in the end, the disease just overwhelmed him. He had such a hard time. If I had another cat with the same diagnosis, then I would just have it put away immediately. Not being dismissive, but just realistic.
You are a very kind to have nursed FreeBSD along and looked after it. At least this pathetic OS is being looked after. It is not out there frantically searching for a "home". No, it's found its final resting place.
If FreeBSD does have to be euthanized, this is not a cruel act - it will pass away immediately without suffering.
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. The funeral bell is tolling for *BSD. Bow your head; the parade's gone by -- *BSD is dead.
Nearly 2 Million Active Sites running FreeBSD (July 2003)
"[FreeBSD] is the only other operating system [the other ones are windows and linux] that is gaining, rather than losing share of the active sites found by the Web Server Survey."
I think it's true that market share has little importance for the BSDs, but before taking for granted what a troll says, it's always good to check it out. ;)
One more thing: I don't think that guy simply "wants to troll" as you put it. Since his/her/its FUD-spreading activity has been going on for *years*, that would probably qualify as something else. :)
(Of course I wouldn't completely rule out the possibility of a mental issue
--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.
Oh, thank you a lot for your comment. I'm just new here and I really misunderstand the situation :)
MS-DOS since 6.0, Windows since 3.1, Novell Netware since 4.5 and FreeBSD since 4.5
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.
Same old FUD, that has been disproved countless times...
This paper presents a suite of benchmarks and results for comparing the performance of these operating systems. The benchmarks target core operating system functionality, server scalability and thread implementation. These benchmarks are useful server-based criteria for demanding applications such as loaded webservers, databases, and voice-over-IP (VoIP) media relays. The results indicate that NetBSD has surpassed FreeBSD in performance on nearly every benchmark and is poised to grab the title of the best operating system for the server environment.''
Full paper: http://www.feyrer.de/NetBSD/gmcgarry/
"The results indicate that NetBSD has surpassed FreeBSD in performance on nearly every benchmark and is poised to grab the title of the best operating system for the server environment."
While an interresting UP benchmark it in no way says anything about performance for SMP machines and 64-bit CPUs. That is what matters for most servers today (at least those that would be suitable for a new OS) and that's where all servers will be tomorrow.
Life is what happened when Good Intentions met Harsh Reality (the brother of the more infamous Chaos).
FreeBSD is already known to have made a lousy AMD64 implementation, a lousy SMP implementation (which, on 2-way and probably 4-way SMP machines, is actually SLOWER than NetBSD 2's giant lock model), and haven't even finished supporting their new kernel facilities on Sparc64 and Alpha.
So if this test was even possible on a 64 bit CPU in SMP mode, it wouldn't save FreeBSD. The source is out there though, so why not run it yourself? Of course it won't help because all of those are UP-centric micro benchmarks, and you'll just have to run, say, an Apache or MySQL bench.
We're waiting for your report eagerly.
Sam ty sig.
Actually, I just re-read your post, and noticed you have no clue at all. Let me explain: an algorithm is an algorithm. It doesn't matter if it's running on a machine with one or two procs, one instance of the algorithm will still only run on one processor at a time. It doesn't matter if it's 64 bit or 32 bit, since NetBSD is 64-bit-clean and hence doesn't have nasty side effects; let's assume FreeBSD is up to scratch on this as well. The algorithms will still scale the same and, if the instruction horse power is equivalent, take the same time.
What you said was "this is a great display of how a person can run, but it doesn't say anything about how he would run with a friend or on a Thursday!"
Sam ty sig.
On the other hand: nice (micro)benchmarks! Thanks :) It appears that FreeBSD developers know of these issues:
You may find the the rest here. It is also a pity that some troll spammed every single FreeBSD mailing list with a "haha, freebsd developers suxorz, especiall PHK and DES" kinda message. Reminds you anyone we know?If you read my post again then you must also have noted that I never mentioned algorithms but the notion parent used that "is poised to grab the title of the best operating system for the server environment."
m ance/2005-January/001019.html
What I did not clarify is that I ment proper server tests with actual workloads where SMP machines are used. The benchmarks are mostly checking the microoptimisations of a UP machine and it is well known that the current state of FreeBSD 5 is not optimized towards that. I also assume that you have missed the bug where hundreds of cycles where wasted when doing Mutex releases. A lot has happened since 6-CURRENT was created and 5.4 is only looking nicer day by day.
You also fail to realise that I in no way have any problems with NetBSD being faster (as I use it on my backup machine).
However, as history with FreeBSD and Linux have shown, why do you think a BGL SMP implementation would scale better than a FGL implementation? Even given the clean lean source of NetBSD? Just curious.
NetBSDs performance is looking very nice but don't make too sweeping assumptions about actual server performance based on this alone and that is also what the paper says in the end. More benchmarks needed.
BTW, regarding the actual benchmarks, rwatson had an interresting comment about it http://lists.freebsd.org/pipermail/freebsd-perfor
Life is what happened when Good Intentions met Harsh Reality (the brother of the more infamous Chaos).
Apologies, I guess I misunderstood your post as saying the benchmarks were run on the wrong kind of system, rather than the benchmarks being used for sweeping assumptions.
So 5-STABLE is actually becoming worth using, you say? I'd like to try that, in fact I will when I can afford to (currently only two machines under my control and both are life-critical, for my life anyway). I've really wanted to get back into FreeBSD, it's highly usable and all, but my negative experience with 5.3 (yes, even tracking -STABLE for a month or so) put me off.
Has anything been said on the topic of the new, stupid disk sync style? Unlike all other systems which sync their dirty buffers quickly and know about it, FreeBSD 5 now can generate MORE dirty buffers during syncing and has to wait for 3 consecutive "no really, it's all clear this time" checks before being satisfied; and each check is spaced about a second. This results in possibly 5-10 seconds spent just waiting for disk syncing, which is digusting compared to near-instant syncs in other systems.
Anyway, does anyone want to run an Apache or other bench on a 64-bit SMP system with NetBSD 2_stable and FreeBSD 5.3-STABLE? Be worth a look I'd say. I wouldn't run a server based on small performance merit myself, it'd all come down to administration, cleanliness, security and stability... but then I don't pay for my hardware myself.
Sam ty sig.