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."

2 of 301 comments (clear)

  1. Status of FreeBSD 5... by NightSpots · · Score: 5, Informative
    For those who don't follow FreeBSD, here's the executive summary:

    • FreeBSD's most stable branch (-stable) is still 4. It's currently at 4.9. This is like the 2.4.x branch in Linux.
    • FreeBSD's development branch (-current) is at 5.2. All major changes go into this branch, although some (like hyperthreading) will be MFCed (merged from current) back into the 4 branch if they're important. This is like the 2.5.x branch in Linux.
    • Although it was planned for 5.2, it appears that the 5.3 branch will mark the transition to 5-stable. That is, the stable branch will be the 5 series, and the development branch will start working towards 6. This is the equivalent of the 2.6.x branch in Linux.


    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 ... well, there's a reason people use FreeBSD, and it's not because it has a pretty installer.
  2. Re:Opteron 64-bit support? by sremick · · Score: 5, Informative

    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.