Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Operating Systems Software Unix BSD

FreeBSD 5.2 RC2 Now Available 301

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."
This discussion has been archived. No new comments can be posted.

FreeBSD 5.2 RC2 Now Available

Comments Filter:
  • by NightSpots ( 682462 ) on Wednesday December 24, 2003 @10:07AM (#7802573) Homepage
    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.

    • What's the status of pf on FreeBSD? And what's the preferred packet filtering/firewall setup these days?

      The last I checked, circa 4.8, you had to recompile the kernel just to get a NAT "router."

      Has NAT-ing and filtering drawn any attention in the 5.x series?

      I ask because FreeBSD has about the best host adapter/hard drive support in the business [possibly better even than NetWare] - if you've got an old hba and an old hd, FreeBSD will load the drivers and do the LBA translations to perfection. I've se

      • by Anonymous Coward
        'pf' is available in the ports.
        'ipf/ipnat' are available with kernel options.
        'ipfw/natd' are available by loadable modules without recompiling the kernel.
      • by dodell ( 83471 ) <<moc.scinortetis> <ta> <lledod>> on Wednesday December 24, 2003 @10:49AM (#7802801) Homepage
        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.

        • 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 b

          • [...] 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.]

            Huh ?

            Your default install kernel has been compiled from GENERIC, too. Copying GENERIC to MYVERYOWNKERNEL, inserting option "IPDIVERT" somewhere and

      • pf/nat (Score:2, Interesting)

        by adiposity ( 684943 )
        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 [love2party.net] is coming along nicely. I am currently using it with a kernel loadable module and a startup s
      • i'm using 4.9 and i never had to recompile to get my nat box working. I'm using the ipf / ipnat combination, and they were already installed. I just had to configure them, and put it in the starup scripts. The recompiling part is for purists who would rather have them in kernel vs. loading them as modules. For noncritical work, modules are fine. I looked into ipfw / natd, but the configuration is too nasty. ipf/ipnat is in comparison so much simpler.

        The freebsd handbook *always* wants you to recomp

    • "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.
    • by dodell ( 83471 ) <<moc.scinortetis> <ta> <lledod>> on Wednesday December 24, 2003 @10:43AM (#7802770) Homepage
      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 ;))
    • by PatJensen ( 170806 ) on Wednesday December 24, 2003 @11:06AM (#7802902) Homepage
      Thanks for the good update and rundown. I was hoping to see some more work done on Newcard (the new Cardbus/PCMCIA engine in FBSD 5) I've had a huge amount of difficulties deploying FreeBSD 4.9 and 5.1 on recent and older laptops alike.

      I recently deployed 5.1 on a Toshiba Satellite Pro 4208XDVD and an older IBM Thinkpad 600X. Neither of them correctly probed my Cardbus controllers without specifying the size of allocated memory to the controller. I also had difficulty once the controllers came up, in that none of my wireless cards would work. (Orinoco Gold, MS Wireless Broadband Adapter)

      Has anyone else had Newcard difficulties with the FBSD 5 release train? I've read of quite a few workarounds to get Cardbus working correctly. I have yet to recompile a new kernel removing Newcard - is it worth it altogether?

      Merry Christmas Slashdot!

      -Pat

  • by Anonymous Coward on Wednesday December 24, 2003 @10:19AM (#7802643)
    Does it have proper Opteron 64-bit support?

    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?

    • by sremick ( 91371 ) on Wednesday December 24, 2003 @10:32AM (#7802716)
      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.
    • Considering part of FreeBSD's project goals is to be the best UNIX system available for Intel(like) hardware, I would wager a big sum that it either works now, or is the developement cycle, being worked on furiously. Since 64 bit computing is where the intel/amd market is going, its likely where FreeBSD will go as well.
    • Gentoo runs pretty will on amd64. I'm running it right now.. the compiler works fine, XFree is up with drivers that Nvidia specifically released for amd64 (but they won't accelerate 32bit GL or do xv), mplayer and most everything I've tried to build and use has worked just fine.

  • I want everybody in the community to know that 5.2 RC2 is the best version of FreeBSD yet, and is even the best OS out there. I have been using 5.2 RC2 for over three years over here, currently reflected in its uptime, because it has not crashed at all over the entire three years.

    Anybody who hasn't tried 5.2 RC2 yet is really in for a treat...

  • by Chemisor ( 97276 ) on Wednesday December 24, 2003 @10:32AM (#7802709)
    > 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.
    • 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.
      Mastery of mspaint does not qualify you as an experienced user.
      • > Mastery of mspaint does not qualify you as an experienced user.

        Perhaps not, but remembering that mspaint still exists might be a qualification in itself. That program seems as ancient as dosshell these days.
        • mspaint is shipped as part of Windows XP. For bitmaps, it is the default action for "Edit" in explorer (not sure if it is still for Open - I've had too many things want to take that over). Not so ancient as dosshell.exe.

          XP still comes with Program Manager (\WINDOWS\system32\progman.exe)
  • that's the best part IMGO: "Scott is asking everyone to test this release over the holidays". What a scary geeks you are !
  • Better jail support (Score:3, Informative)

    by gtrubetskoy ( 734033 ) on Wednesday December 24, 2003 @12:21PM (#7803277)
    5.x has much better jail(8) [freebsd.org] support than the 4.x. IMHO jail is a killer app of FreeBSD.

    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 [freebsd.pl] out there, but they seem outdated.

  • I had a problem with 5.2-RC1 where by on boot the kernel would detect the HDD and say [MPSAFE] and then pause for a while, this struck me as odd, mostly because i interperated MP to be Multi-Processor, and i was on a Uniprocessor machine (and thats an AMD, not an Intel P4 w/ HyperThreading, which i know is set up as a virtual CPU in the kernel for scheduling)
    If anyone knows if this has been resolved, I'll probably update my box from 5.1 to 5.2-RC2 tonight.

    As a side note, I'm curious as to what ports are
    • this struck me as odd, mostly because i interperated MP to be Multi-Processor, and i was on a Uniprocessor machine

      I can't find a good link now, but I read somewhere that the GENERIC kernel was going to be made SMP by default. Therefore, you may want to save some overhead and recompile your kernel without the SMP.
  • FreeBSD 5.x (Score:1, Interesting)

    by Anonymous Coward
    There are so many things in these new technology releases that I am so lookiing forward to implementing on my own machines once this branch becomes stable. GEOM Based Disk Encryption and LOMAC are among them.

    The background fsck saved me a couple of times before I got UPSs for them, and the new GENERIC SMP kernel will be great once I get my new dual Opteron.

    All in all FreeBSD is doing great, and I'll never go back to Linux; there's no incentive, nor need.
  • 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
    • 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.

      Did you try Slackware? It runs on the lowest end of the hardware spectrum; has everything you need for a base system and then some, pre-packaged in tgz format; is easy to customize; and stable as hell.

      But really: what happened to love and peace? Y'know, BSD and Linux (or GPL, depending on point of disagreement considered) can coexist: BSD is Good,
  • by Jerk City Troll ( 661616 ) on Saturday December 27, 2003 @01:53AM (#7816270) Homepage

    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 [highpoint-tech.com] 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 [3ware.com], 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.

    • I've heard nothing but great things about the 3ware cards, also, though I have no personal experience. I am running a FBSD 4.9 SOHO server using a promise fastrak ata raid controller with a raid 0+1 array and I've had absolutely no problems. The driver is included in the standard FBSD ata driver and the raid array can be probed using the 'atacontrol' command. I beleive that this card is a "software raid" card as you mentioned but it _smokes_ during normal operations. Unfortunately, RAID rebuilds can be quit
  • I couldn't use my Acer USB portable ATA hard drive enclosure in 5.1, but it works great in 5.2-CURRENT. Just an update for anyone that was having trouble with their hardware under FreeBSD. 5.2-RC1 panic'd when detecting my RAID, but 5.2-RC2 (as well as 5.1) with ATAng works great.

    However, USB 2.0 (EHCI) is still not supported (to try it, add "device ehci" to your kernel configuration). This makes using portable hard drive enclosures under FreeBSD less than optimal, as transfers go at the slow 1Mbps of USB

FORTUNE'S FUN FACTS TO KNOW AND TELL: A cucumber is not a vegetable but a fruit.

Working...