The latest of the FreeBSD 5.2-RCx series has been released. FreeBSD 5.2-RC2 fixes a showstopper filesystem bug that could occur when using soft-updates. Get it now from the main ftp server or try one of the mirrors. Promptly report any bugs you find as this is likely to be the last release candidate.
FreeBSD 5.2-RC2 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
29 Comments
2003-12-26 4:38 pm
2003-12-29 7:59 am
the best os for my intel-machine is reaching the next step … great news!
I can’t wait for FreeBSD 5.x to become the new production branch. They’ve made nice progress over the past year. I wonder which will happen first though, that or the first release of DragonFly. Next year’s gonna be fun either way.
Are they going to support broadcom NIC’s anytime soon???
I have FreeBSD 5.1 humming along quite nicely and I’ll look forward in replacing that and installing FreeBSD 5.2 sometime soon I guess.
Some of the things I’ve enjoyed about the 5.x series is the baground fsck. I’ve tripped a breaker a couple times this winter which killed the power to my machine. It’s so nice being able to start up and not have to wait for it to fsck. I also like the new rc-NG system. I just wish that services installed via the ports tree would include scripts like that. Some do, but some don’t.
Anyway, it doesn’t look like 5.2 will be tagged -STABLE but I know it’s improving. Cheers and Thanks to the FreeBSD team!
The bge(4) has been in the tree since 4.5 was released.
That’s 4 releases ago on the 4.x branch, which is about
2 years ago. The bfe(4) driver was included in the tree
in 5.1. You can use cvsweb to see the actual import
dates.
—
steve
Its an early gift from the FreeBSD team. Thank you.
> Its an early gift from the FreeBSD team. Thank you.
Who knows, a final release of 5.2 before the 31st could cause me to spend new years even in front of my computer instead of at a party with mates. Good old FreeBSD, underpromising and overdelivering. Aah
my wish is to adopt FreeBSD to enterprise systems with powerfull SMP support. Long live FreeBSD !!!
I wish that one of these BSD’s would take the needs of desktop users as their special target. It makes no sense having many BSD’s that all basically do the same job.
It’s not a desktop OS. If you want to use it as a desktop then install your favourite bloated window/desktop manager and play tux racer or something.
It is a desktop OS if you set it up so, which is very easy when doing a new installation or later add it through ports (not installing the portssystem should be punishable when using *BSD
). With the recent creation of the port gnome2-lite http://www.freshports.org/x11/gnome2-lite/ is it even sweeter than everto use as a desktop (which I do on my laptop). Still, FreeBSD is first and foremost developed for servers and it should remain so. That fact that FreeBSD rocks as a desktop also just proves that the focus for development is a-ok.
All I can say for the future is: come 5.3, come 5-STABLE and everything is possible. There was much research and planning put into the 5-series before the implemetation and I’m sure it will pay off. Perhaps DragonFly BSD will do fine and provide nice new features. Then porting the best to FreeBSD should not be too hard. This is the thing I really like best about the *BSD:s, the crosspollination. I just recently tested out running OpenBSD:s pf firewall/NAT om FreeBSD and it just rawks. RC-ng which came from (mainly) NetBSD just kicks SysV init and runlevels where it hurts.
Is it just me or is the *BSD-scene growing again? Not bad for someone the gnuzelots (the common name for the species of Gpl advocatis inabsurdum
) have proclaimed dead for many years now.
God Jul and thank you for this early Christmas present FreeBSD developers!
> Is it just me or is the *BSD-scene growing again?
The BSD-scene has never done anything but grow. “BSD is dead” is one slashdot’s most beloved trolls. But we all know the average IQ of the slashdotters.
I was about halfway through downloading RC1 on 56 k. Download broke, apparently RC2 was posted already. So now i’m dowloading that instead.
I guess the final will be out in early jan. Originally slated for xmas i think.
Is DHCP broken? I just downloaded 5.2-RC2 to give it a try but dhclient doesn’t seem to fetch the addresses of my DNS servers. I noticed that resolv.conf isn’t there but I don’t know if that’s normal. It might be a known issue but I’m a total noob with BSDs.
I have 5.1 humming away and my question is: How do I go about upgrading to 5.2 RC2. Thanks!
I have 5.1 humming away and my question is: How do I go about upgrading to 5.2 RC2. Thanks!
1) Update your source with cvsup. Use tag RELENG_5_2. See handbook for details.
2) cd /usr/src && make buildworld && make buildkernel && make installkernel
4) reboot in single user mode
5) run mergemaster -p, update config files if necessary
6) cd /usr/src && make installworld
7) run mergemaster, update config files if necessary
And you’re ready to go! You can also find this information in /usr/src/UPDATING once you have updated your sources.
Linux 2.6.0 has been out over a week, NPTL with its superior 1:1 threading model is over a year mature in stable releases, and everything tested in Linux 2.6 scales O(1). FreeBSD is using inferior M:N threading model with libkse, and isn’t even production ready yet. Plus NPTL didn’t break anything, but libkse probably will break a lot of things. FreeBSD uses O(n) scheduler which is slower, and scales O(n) in many other respects. Why sit around and wait for a technologically inferior OS when a superior one is already out and ready to be used?
“inferior M:N threading model”
I think this is your opinion, and an uninformed one at that. I’ve read more that says that M:N is theoretically superior to 1:1 but we’ll not know for sure until this plays out. Why are you opposed to trying?
“Plus NPTL didn’t break anything, but libkse probably will break a lot of things”
NPTL broke Java among other things, libkse has broken nothing on me yet. I don’t care much for Java, but many big businesses do. (Yeah, I know it’s since been fixed)
“Why sit around and wait for a technologically inferior OS when a superior one is already out and ready to be used?”
Everything has it’s issues, and the ones you refer to are being tackled as we speak. The ULE scheduler will soon be the default, replacing the old 4.4BSD one. That’ll fix the current performance issues. Linux isn’t a complete OS, it won’t even boot without a handful of GNU tools.
I think you need to look a little deeper before you start calling anything inferior to Linux. It is the current champion in the scalability department, but that is something that fluctuates rapidly. NetBSD could already be kicking Linux’s ass. It took only about a week for them to fix the issues they had the first time in the tests you refer to.
1:1 threading is just taking user threads and having them serviced by kernel threads, basically wasting tons of cycles doing a system call every time a thread is switched by the scheduler when it could have stayed at the user level and not involved the kernel. M:N is theoretically better, in particular when context switches incur a large penalties for the CPU. Windows NT has used 1:1 threading forever. You fail to grasp that it is likely 1:1 threading is inferior to M:N threading if it could be implemented properly (not an easy task and one that SUN basically gave up on) – 1:1 is just a dummy implementation – it doesn’t try to give any special scheduler to user threads. Yes, 1:1 is tried and true, but it certainly isn’t “cutting edge”.
Ignore keefer. He’s been told *repeatedly* that FreeBSD implements both 1:1 and M:N threading through libthr and libkse respectively, yet continues to ignore it. He also ignores that FreeBSD 5.x was designed to have an elegant threading model from the start with scheduler entities, as opposed to Linux in which NPTL is essentially cobbled on to the existing design. While definitive benchmarks showing the relative performance of KSE threads versus the NPTL do not exist, FreeBSD clearly sports the more elegant design.
Yeah, it’s the same guy as last time, and I gave a lengthy reply to that post, I’m not doing that again (to recap: FreeBSD implements both 1:1 and M:N, if you want you can choose on a per-application basis which one you want to use to get the best performance, M:N could be faster than 1:1 as specialists from commercial Unices (Tru64) will tell you, and there is a O(1) scheduler called ULE). He is obviously a troll and should be moderated down.
If 1:1 is “theoretically” inferior to M:N then why did Sun abandon M:N threading for 1:1
And who cares about “elegance” all that really matters is how well it works
Sun gave up, pure and simple. They lost whatever direction that they had, and are only now begining to find a new one. No mystery here.
He also ignores that FreeBSD 5.x was designed to have an elegant threading model from the start with scheduler entities
Translation: Required both kernel surgery and substantial userland work (still not completed, no GDB support for instance), and is thus an ‘elegant design’.
as opposed to Linux in which NPTL is essentially cobbled on to the existing design.
Translation: Did not cause undue disruption with neither kernel nor userland, and is thus ‘cobbled on to’.
While definitive benchmarks showing the relative performance of KSE threads versus the NPTL do not exist
Are there any published KSE benchmarks _at all_ out there, let alone any definitive ones?
FreeBSD clearly sports the more elegant design.
Hmm, let’s see. On the one hand we have an implementation that has been _years_ in the making, is still not done (does not support Sparc64 or Alpha for instance) and we still don’t know the word on performance. OTH, we an implementation that was more or less completed (as in functional, not as in debugged) in a matter of weeks by two people and has for some time already been deployed in official Linux distribution releases.
But somehow, the first implementation is just…more elegant. Welcome to bizarro world.
Also, perhaps you don’t remember (or never knew) but Linux had a working M:N implementation long before FreeBSD, namely NGPT. It performed well too. http://www-124.ibm.com/pthreads/
Despite this, going with NPTL instead of NGPT was a very uncontroversial decision in the Linux kernel community (there was a long thread in LKML when NPTL was first announced. Support was pretty much unanimous).
Good old FreeBSD, underpromising and overdelivering. Aah
Not to be an ass here (honestly!), but did you ever look at any of the old roadmaps for FreeBSd 5.x?
Underpromising and overdelivering is an extreme rarity in the world of software
I hope they get the bloody mouse driver working !!!!!!!!!!!!!!!
Translation: Required both kernel surgery and substantial userland work (still not completed, no GDB support for instance), and is thus an ‘elegant design’.
Well, that’s a pessamist’s view. It could also be said that the existing design was rather antequated and not conducive to efficient threading of any kind. Linux had made great strides using its existing _clone() based interface in conjunction with NPTL. But rather than trying to pursue the same path with rfork(), the FreeBSD team instead decided to start from scratch and implement LWPs as truly distinct entities from HWPs in the scheduler’s perspective. In such a way, in the future large portions of thread operations could be moved into userspace, eliminating the need for a context switch, which is quite beneficial on platforms where context switching is slow, namely x86.
Translation: Did not cause undue disruption with neither kernel nor userland, and is thus ‘cobbled on to’.
Or from a slightly different perspective… Linux originally suffered from the same initial design problems as FreeBSD, but rather than scrapping the original design and starting from scratch like FreeBSD did, the existing kernel threads interface was progressively modified to perform better.
Which is more elegant? Well, Linux decided to modify an existing design to do something for which it wasn’t originally intended, whereas FreeBSD scrapped the existing design and reimplemented in order to facilitate new goals.
Hmm, let’s see. On the one hand we have an implementation that has been _years_ in the making, is still not done (does not support Sparc64 or Alpha for instance) and we still don’t know the word on performance. OTH, we an implementation that was more or less completed (as in functional, not as in debugged) in a matter of weeks by two people and has for some time already been deployed in official Linux distribution releases.
But somehow, the first implementation is just…more elegant. Welcome to bizarro world.
FreeBSD decided to do what they thought was the “right way” rather than the easiest way. Scrapping huge portions of the existing codebase and starting from scratch has always lead to similar development problems, most notably the decision to scrap the existing Netscape codebase and start from scratch with Mozilla, which eventually lead Netscape to release the infamous Netscape 6.x. Meanwhile, Microsoft pressed on with its Internet Explorer codebase, and achieved a much better product in a much shorter time. But nowadays, there are few who will argue that Mozilla and the assortment of other Gecko based browsers have greatly surpassed Internet Explorer. (Now granted, Microsoft did largely cease development of Internet Explorer, so this example isn’t entirely applicable to the Linux versus FreeBSD threading approaches, but it does serve to demonstrate my point about continuing development of an existing codebase with design issues as opposed to starting from scratch)
Also, perhaps you don’t remember (or never knew) but Linux had a working M:N implementation long before FreeBSD, namely NGPT. It performed well too.