Slashdot Mirror
FreeBSD 5.2 RC2 Now Available
Dan writes "FreeBSD Release Engineering Team's Scott Long announces the availability of FreeBSD 5.2 RC2 which fixes a number of bugs, specifically the one in which users experienced system panics during install and dynamic library problems in the 'fixit' environment. Scott is asking everyone to test this release over the holidays. You can download it from one of your preferred mirror sites." Update: 12/24 23:01 GMT by T : Dan writes with more info: "Scott Long has also laid out a roadmap for future FreeBSD 5.3 releases now that FreeBSD 5.2-RC2 is getting close to release quality."
That means that the next two releases on the 5 branch are going to be last times new features are added to the branch before -current forks, so it's going to require a lot of testing to ensure stability.
Why do you care?
Well, if you don't ever plan on using FreeBSD, you don't. If you do use FreeBSD, tossing this release on your hardware and making sure things like ACPI function with your motherboard are really important as NOW is the time to fix them so that they can be tuned and maintained prior to the 5.3 Release when the code is marked stable.
The major changes in FreeBSD 5 are significant. There's new locking throughout the tree, which should improve SMP performance everywhere. There's also finer grained locking in the Network stacks (thanks Sam), better ACPI (thanks John), support for AMD64 (coming slowly, thanks Peter), and the GEOM disk abstraction layer (nice work PHK), which has already been shown to be useful for things like GEOM-gate (a la nbd in Linux), is getting more mature with every release.
Performance and stability
--
Use Vobbo for Video Blogs
An HP ProLiant DL140 server, apparently.
Oh wait, you've probably got a different ad...
Perhaps this "bais" is due to the fact that Linux kernel panics are not news. However, kernel panics in BSD are so rare that when they occur they are indeed news.
And yes, before the Linux hordes flames me to death, yes I know that Linux kernel does have Opteron support and has been more or less 64-bit compatible since the DEC Alpha days.
I'm talking about the distribution. I am considering buying a dual Opteron in January but all the Linux distros seem to be betas. A quick search on Google reveals that the distros have serious problems. In particular, X doesn't work and compilers fail completely.
FreeBSD reports Opteron as tier-1 hardware, so how is it?
Anybody who hasn't tried 5.2 RC2 yet is really in for a treat...
> bugs, specifically the one in which users
> experienced system panics during install
I wonder how they expect anyone to actually use an operating system whose installation procedure makes experienced users panic... Oh, yeah; I forgot. It's open source.
/. just cannot resist the chance to take a shot at FreeBSD over a kernel panic in the story, can it? One stability issue in FreeBSD in what, 5 years?
Calm down. We are talking about the release candidate of a development branch. FreeBSD 5.x isn't stable yet. The first stable FreeBSD 5.x release will be 5.3. Nobody says that there are major problems with the stable branch of FreeBSD.
Yet, the myriad of kernel panic issues in Linux go conveniently ignored.
This is hardly on topic in a FreeBSD release announcement.
"NOW is the time to fix them so that they can be tuned and maintained prior to the 5.3 Release when the code is marked stable..
Shouldn't this read something like:
NOW is the time to fix them so that they can be tuned and maintained so that the 5.3 Release can be marrked stable.
In other words, the code should be marked stable when it IS, rather than at some arbitrary release level.
I want to delete my account but Slashdot doesn't allow it.
that's the best part IMGO: "Scott is asking everyone to test this release over the holidays". What a scary geeks you are !
I re-iterate. -STABLE is *NOT* the most stable branch. It is not comparable to 2.4 in Linux. For more information, please see http://www.freebsd.org/handbook/current-stable.htm l (which explains the -CURRENT and -STABLE branches as well as a bit about releng.)
;))
But yes, thanks to the developers who have been working on this. And thank heavens that it's the holiday season; now I'll finally have time to work on locks in the IPv6 stack (thanks Sam and Robert
www.sitetronics.com/wordpress
Indeed, the developers have done alot of hard work making FreeBSD an excellent OS. I've been using 5.x since it came out and have few complaints. Even for a developer release I've found 5.x to be rock solid, with high quality in mind, and quick time to fix any problems that do come up (mostly port maintainers keeping up with 4.x->5.x changes :)
It's dying!
OK, It's so much that it's dying .... it's that all these companies like SCO are able to keep living by forking off endless proprietaty code for themselves because the FreeBSD license allows it. Do a "strings" command on any SCO binary and you'd be amazed how much similar stuff they have to the FreeBSD equivalents. (what's even more amazing is that for all that copying you'd think they'd be able to make SCO stable)
Yes, you still have to add options DIVERT into the kernel to get IPFW to work with natd, if that's what you mean.
One of the goals for 5.3 (and indeed something that Sam has been doing some wonderful and hard work on) is cleaning up the IP stack. Getting IPFW pfil(9) ready (if I understood correctly) is also one of these goals and will mean that using any software firewall solution such as pf, IPFW or ipfilter would be a question of loading the module. At which point you wouldn't have to recompile the kernel for this functionality.
But this is a 5.3 goal and will not be present in 5.2.
Hope this was of help.
www.sitetronics.com/wordpress
BSD itself died, back at v4.4 when UCB stopped doing development itself. The body parts have been transplanted into computer systems all over, almost every system has some BSD code.
The current BSD's are like the children of the original, taking on the family business.
BSD is like the late, great, patriarch, whose portrait hangs on the wall, in the living room of the family mansion.
One of the goals for 5.3 (and indeed something that Sam has been doing some wonderful and hard work on) is cleaning up the IP stack. Getting IPFW pfil(9) ready (if I understood correctly) is also one of these goals and will mean that using any software firewall solution such as pf, IPFW or ipfilter would be a question of loading the module. At which point you wouldn't have to recompile the kernel for this functionality.
Hope this was of help.
I can't tell you how welcome this sort of functionality will be. I know I'll get flamed for this, but some of us out here in the real world just don't have the time to spend a couple of weeks trying to recompile a kernel. [And no, it's obviously not the actual compile time - it's the fiddling: What happens if I set this flag? What happens if I don't set that flag? Oops, that didn't work - maybe if I were to change that to this... Getting the configuration just right can take nigh unto forever.] Loadable modules for filtering, NATing, and SSHing will be MOST appreciated.
Thanks, and keep up the good work.
PS: If I can be a little greedy, the other thing that really benefits a firewall-ish device is rock solid support [i.e. drivers] for hardware-accelerated encryption [SSL, SSH, and the like]. Of course, rock solid drivers are one of FreeBSD's fortes, but if you're redesigning the stack, I'd just say: Redesign it with hardware acceleration very much in mind.
For those of you that have been neglected by the gods or ad rotation, look here. (Do you think the red ad was designed to match the /.-BSD theme?)
Whoever she is, I can tell she's into BSD.
What I really wish for is private Sys V IPC and multiple IP's for jails to be available as standard features. Currently, there are some patches out there, but they seem outdated.
Allowing freedom includes allowing people to do things you don't necessarily agree with. I used to defend the GPL consistently, but I'm starting to feel like "Free as in Speech" should also include unpopular speech, and that's what the BSD license protects that the GPL does not.
...software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.
In the words of Theo de Raadt:
As opposed to the the GPL, which exists as Stallman's attempt to redefine "Free Software" as any software that suits his political ideology.
The GPL as a strategy is fine, but to call it "freedom" is less than honest. Whose freedom is being protected by the GPL? The developers? Not really. The developers are only allowed to use the source as long as they conform to the RMS ideology that the work they do should benefit the collective and not necessarily just the individual who wrote the software. As for the users, what freedom do they gain by using GPL software over BSD licensed software? The freedom to use software that does not co-exist peacefully with others? The freedom to view the source code they don't understand or care to understand? Besides, the original BSD software always remains free as in speech and beer, even if the Hated Proprietary Software Vendor of the Week exercises their right to protect their own interests.
I'm certain that I'll be moderated as a troll, but this something that I've been pondering quite a bit lately, and I'm certainly willing to be proven wrong.
I personally feel that ipfw/natd are a terrible combination, and are confusing and frustrating to use, to boot. I have been able to do everything I need to ipfw/natd, however. My major complaints were:
1. Cannot dynamically reload rules of ipfw (your connection can be broken after a flush, and before new rules).
2. Poor (really no) integration of natd/ipfw.
3. Weaker rules/macros than pf.
The FreeBSD pf port is coming along nicely. I am currently using it with a kernel loadable module and a startup script, both of which are installed by the port. You do still have to recompile the kernel:
You need these options:
"device bpf" and "options PFIL_HOOKS"
The port will tell you to do this when you install it. My transition was very easy, and immediately I was happier with pf. I had never used it before, and I prefer it immensely. I use it to do firewalling and NAT, and they are integrated, of course.
So, I'd say the status is...good! I'd prefer not to have to rebuild the kernel, but I'm used to that by now.
-Dan
Well, I have to say, having just installed a FreeBSD (5.1) server in my house, I am blown away at the stability and easy configurability of this thing. I built the computer it is running on for $160.00 with (obviously) cheap parts and it is perfrominig like I had really spent some money on it. This was much easier to install software for and configure than any of the Linux distros I have used in the past, including the vaunted RedHat. Stable and fast. That's what I like, and this isn't even the current fork. :-)
On a more serious note - I'd recommend any Linux fan to give FreeBSD a shot. It took me a while to get my head around the whole philosphy behind the way things are done (just as I had to get used to Linux - its just "different" to most linux distros), but once you get used to it, its far more logical and consistant. Faster, in my experience, as well.
Even if you decide to go back to Linux, knowing BSD will put you in a better position to understand the way other Unices work, as Linux is far less similar to them than BSD.
My 2c.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I've recently switched from Debian Linux to FreeBSD 5.2. I was running a pair of RAID-1 arrays off a Highpoint HPT372 RocketRAID 133 controller using Highpoint's rather lackluster, "open source" driver. Of course, contacting them about FreeBSD support greater than 5.0 has yielded nothing useful, so now I am on the hunt for other solutions.
I've come across offerings from 3ware, notably the 7006-2. What caught my eye about this card (well, all of them from 3ware) was that it's actually a hardware-based ATA RAID adapter (where as RAID functionality is implemented in software for most ATA controllers out there). Does this mean that I can use this card without any driver hell? Will a RAID-whatever array simply appear as another /dev/a[dr]* device or is it not that simple? (By the way, I care little about CLI tools for rebuilding the array. I am content to use the card's BIOS to do management.)
Of course, if I can solve the problem with my Highpoint, that'd be useful too. Currently, if I create a RAID-1 array, the two real disks appear as /dev/ad4 and /dev/ad5 but I also get a /dev/ar0 device. However, if I simulate a disk failure, none of the devices appear. It appears to me like FreeBSD indeed supports the RAID functionality of this card out of the box, but a bit of minor tweaking is required.
The bottom line however is I wouldn't mind buying a a RAID adapter with functionality implemented in hardware. That'd be better overall. I just want to make sure it'll work with flying colors in whatever OS I choose to use.
Join Tor today!