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
/. 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.
The following is from the October status report. A new one is due out soon as they are bi-monthly.
AMD64 Porting
Contact: Peter Wemm
The last known bug that prevented AMD64 machines completing a full
release has been fixed - one single character error that caused
ghostscript to crash during rendering diagrams. SMP work is nearing
completion and should be committed within the next few days. The SMP
code uses the ACPI MADT table based on John Baldwin's work-in-progress
there for i386. We need to spend some time on low level optimization
because there are several suboptimal places that have been ignored for
simplicity, context switching in particular. MTRR support has been
committed and XFree86 can use it. cvsup now works but the ezm3 port
has not been updated yet. The default data segment size limit is 8GB
instead of 512M, and the (primitive) i386 binary emulation support
knows how to lower the rlimits for executing 32 bit binaries.
Notable things missing still: Hardware debug register support needs to
be written; gdb is still being done as an external set of patches
relative to the not-yet-released FSF gdb tree; DDB does not
disassemble properly; DDB cannot do stack traces without
-fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64
linux binary emulation is needed, and the i386 FreeBSD binary
emulation still needs work - removing the stackgap code in particular.
The platform in general is very reliable although a couple of problems
have been reported over the last week. One appears to be a stuck
interrupt, but all that code has been redone for SMP support.
'pf' is available in the ports.
'ipf/ipnat' are available with kernel options.
'ipfw/natd' are available by loadable modules without recompiling the kernel.
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
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.