Slashdot is powered by your submissions, so send in your scoop

 



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 sameerdesai ( 654894 ) on Wednesday December 24, 2003 @11:05AM (#7802557)
    I have always loved open source projects.. this has a unique opportunity of researching on your own and learning what others have done on the research.. like simple scalar tool available on University of Texas austin that allows you to research on microprocessor design I consider this one is a nice research tool in OS. Crossing my fingers for this release.
  • by Noryungi ( 70322 ) on Wednesday December 24, 2003 @11:07AM (#7802567) Homepage Journal
    OK, this one goes out to all of you BSD trolls out there:

    It's dying!
    It's dying!
    It's dying!
    It's dying!

    There... feeling better, little trolls? I know you would! ;-)

    This being out of the way, kudos to all the FreeBSD developers for all the good work -- it's a nice Christmas present!
    • by ibku ( 735269 ) on Wednesday December 24, 2003 @11:43AM (#7802772)

      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 :)

    • by argoff ( 142580 ) on Wednesday December 24, 2003 @11:44AM (#7802773)

      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)

      • Unpopular Freedom (Score:5, Insightful)

        by Alethes ( 533985 ) on Wednesday December 24, 2003 @01:46PM (#7803406)
        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.

        In the words of Theo de Raadt: ...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.

        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.
        • by Progman ( 24348 ) on Wednesday December 24, 2003 @01:53PM (#7803432)
          Whose freedom is being protected by the GPL?

          The author's freedom. The author chooses the license under which he makes his software available, remember?
          • by Alethes ( 533985 ) on Wednesday December 24, 2003 @02:16PM (#7803566)
            The author's freedom is also protected by the Microsoft EULA and by copyright laws. I'm not convinced that the GPL provides any additional protection for the author. As a matter of fact, the GPL proponents would say otherwise -- that the author is giving up some of his freedoms provided by copyright so that somebody else can benefit from the source. The question is who benefits? My thinking is that it's developers who share the collectivist ideology that RMS calls "freedom". Which just makes me think "Freedom to do what?" or "Freedom from what?".
            • by Anonymous Coward on Wednesday December 24, 2003 @04:12PM (#7804156)
              really -- are you intentionally ignoring the obvious?

              they are free to use the code without otherwise arranging a license.

              smells like trolls around here
        • by bmedwar ( 693432 ) on Wednesday December 24, 2003 @02:48PM (#7803725) Homepage
          You are definitely more sane than 99.999% of the population.
        • by Anonymous Coward on Wednesday December 24, 2003 @03:05PM (#7803798)
          ..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.

          I'm glad we got that out of the way, especially since my baby mulching machine is nearing readiness for beta testing. Any beta testers out there? http://babymulch.sourceforge.net [sourceforge.net]
        • by antiMStroll ( 664213 ) on Wednesday December 24, 2003 @03:19PM (#7803889)
          As opposed to the the GPL, which exists as Stallman's attempt to redefine "Free Software" as any software that suits his political ideology.

          A fairer perspective is that the BSD License and the GPL represent competing political ideologies, your assessment is a loaded one. Is the BSD a 'more free' license? Likely. Is it a better one for it? Debatable. 'More free' is not necessarily always better, crying 'fire' in a crowded theatre for example. From this non-developer's perspective, proprietary software will always live in conflict with OSS - SCO as another example - and the BSD license gives companies the means to do BSD harm. They take without giving. The GPL might be less free and, by forcing cooperation, the better for it and the future of the software under its wing.

          • by Alethes ( 533985 ) on Wednesday December 24, 2003 @03:54PM (#7804073)
            The GPL might be less free and, by forcing cooperation, the better for it and the future of the software under its wing.

            And that may very well be the case, but the problem I'm having is that it's being done under the banner of "Freedom", which "forced cooperation" certainly does not mean. Perhaps, instead of "Free Software", it should be renamed, "Cooperative Software", but even that's a misnomer, since GPL software often is unable to really cooperate with anything other than other GPL software consistently and predictably.
          • by Anonymous Coward on Thursday December 25, 2003 @12:55AM (#7806611)
            From this non-developer's perspective, proprietary software will always live in conflict with OSS - SCO as another example -

            As a non-developer perhaps you need to look into the SCO history.

            SCO used to be a GNU/Linux company called Caldera. Caldera took the IPO money made when they offered a GNU/Linux product and bought the UNIX(tm) code via buying SCO. Before SCO had UNIX(tm), Novell had UNIX(tm). And before Novell, USL had UNIX(tm). Back when USL had UNIX(tm), they took code from Berkeley, removed the copyright notices of Berkeley and put on USL copyrights.

            Now, somehow from these known facts you've come up with:

            BSD license gives companies the means to do BSD harm.

            The 'harm' to BSD was the ACTUAL theft of the code.

            forcing cooperation

            From http://www.m-w.com/cgi-bin/dictionary?book=Diction ary&va=cooperation

            "association of persons for common benefit"

            Why should anyone sign up for a FORCED association? Yet, this 'force' isn't all that effective, given the number of posts on slashdot telling of companies/people who are accused of violating the GPL.

          • Re:Unpopular Freedom (Score:3, Interesting)

            by kirkjobsluder ( 520465 ) <kirk&jobsluder,net> on Thursday December 25, 2003 @03:29AM (#7807066) Homepage
            From this non-developer's perspective, proprietary software will always live in conflict with OSS - SCO as another example - and the BSD license gives companies the means to do BSD harm. They take without giving.

            This is one of the big flaws I find with GPL logic. Information should be free because it is an endlessly renewable resource. However we can't just let the information be out there without a license because some evil company might do it harm!
        • Re:Unpopular Freedom (Score:4, Interesting)

          by argoff ( 142580 ) on Wednesday December 24, 2003 @04:05PM (#7804123)

          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.

          I think you're working off the false premise that copyrights are not an inherent restriction of peoples freedom. The GPL solves this problem by "fighting fire with fire" the FreeBSD license doesn't.

          The logic is sorta similar to ..."I think people should be free to own slaves".

          The FreeBSD license disreguards that copyrights "the right to restrict what other people copy that is at their disposal" is inherently biased as anti freedom to begin with.

        • by okmijnuhb ( 575581 ) on Wednesday December 24, 2003 @04:13PM (#7804162)
          I believe that the GPL as written, benefits the *users* of free software, more than any.
          It assures that improved or modified code is cycled back into the community for their benefit, rather than locked away as some proprietary binary.
        • by adiposity ( 684943 ) on Wednesday December 24, 2003 @04:19PM (#7804194)
          I agree with your analysis, in that using the GPL doesn't really give a great measure of "freedom" to any who choose to use the GPLed code. In reality, it imposes extreme limitations on the developers, much as a proprietary license does. For the end user, there really is no difference, IMO.

          The original developer loses nothing, of course, unless he/she foolishly assigns the copyright to the FSF, in which case the code becomes even LESS free, because then it is owned by a third party, and is only available under very strict licensing. Doing so simply helps the FSF grow its suite of free software that is only available under the GPL. I suppose it's a noble goal, but the fact is it is just another company with strict licensing rules, although they include the benefit of being open source.

          On the other hand, the BSD license doesn't guarantee much of anything for the developers, and it's sad in a way that it's so easy to use the code w/o giving anything to the coders. And I suppose that's where the GPL comes in; if you feel that your free contributions should only be available to those who are willing to make more free contributions, you should use it.

          There is no question that the BSD license is more "free" than the GPL. But there is the issue of whether the GPL perpetuates more (a greater amount of) "free" code overall than does BSD. I think the GPL is quite useful in that sense.

          -Dan
          • by xA40D ( 180522 ) on Friday December 26, 2003 @08:08PM (#7815123) Homepage
            it's sad in a way that it's so easy to use the code w/o giving anything to the coders

            Why is it sad? And who say's I don't get anything out of writing BSD licenced code?

            Let me try to explain using the economic term "utility". The concept of utility is a measure of happiness or satisfaction.

            I could go on and on about this. But suffice it to say... I love writing code. I do. It gives me one hell of a buzz. Whether it be a PHP website, a quick Perl script, or mission critical application in C. Once it's written I really don't care. For me it's the journey, not the destination, which is important. If I am able to release my code I simply slap a BSD licence on it and forget about it I really don't care what happens next - I've gained all the utility I care about.

            And there is nothing sad about that.
      • by Anonymous Coward on Thursday December 25, 2003 @12:38AM (#7806550)
        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.

        Now this would be the company that took stock market IPO money from its GNU/Linux offering and bought the USL code. The same USL that had chunks of BSD copywritten code in the USL tree where the USL people removed the BSD license and copyright and put on USL copyrights?

        Your 'statement' ignores the past. But if it helps you feel better about yourself, keep thinking BSD licensed code is somehow evil, ok?

    • by jhines ( 82154 ) <john@jhines.org> on Wednesday December 24, 2003 @12:01PM (#7802863) Homepage
      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.
    • by Anonymous Coward on Wednesday December 24, 2003 @12:03PM (#7802877)
      With *BSD proving to be especially resilient, *BSD trolls are facing the reality that *BSD is, indeed, not dying after all. The particularly outspoken troll known only as "Anonymous Coward" recently said, "*BSD trolls will never die, like *BSD soon will! We will never give up! Face the death of *BSD and switch to a different OS and section!" but the numbers tell a different tale. In fact, in the month of December alone, *BSD trolling is down by 14%, continuing a pattern from earlier months. *BSD may not be dying after all, but it seems to be only a matter of time before the *BSD trolls' days of trolling the BSD section are over.

      Fact: *BSD trolls are dying.
    • by rainman_bc ( 735332 ) on Wednesday December 24, 2003 @03:01PM (#7803783)
      Now if only they could get the ports working in 5.2 so we can actually USE it....
  • by NightSpots ( 682462 ) on Wednesday December 24, 2003 @11: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.
    • by mosel-saar-ruwer ( 732341 ) on Wednesday December 24, 2003 @11:33AM (#7802721)

      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 seen countless motherboard/HBA/HD combinations where e.g. Windows 2000 just can't get the LBA translation right. Or OpenBSD, for that matter.

      Which brings me to the question of Theo. Since I'm interested in NATing/PFing/SSHing, most people would say, "Then you want OpenBSD," to which I say, Yeah, some of Theo's goals are laudable, but, quite frankly, the guy's a kook, and guts of his operating system don't work all that well.

      I'd rather use something designed by grown-ups.

      • by Anonymous Coward on Wednesday December 24, 2003 @11:42AM (#7802766)
        '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 ) <dodell@ s i t e t r o nics.com> on Wednesday December 24, 2003 @11: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.
        • by mosel-saar-ruwer ( 732341 ) on Wednesday December 24, 2003 @12:15PM (#7802958)

          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.

          • by frost22 ( 115958 ) on Saturday December 27, 2003 @09:48AM (#7816901) Homepage
            [...] 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 remaking that is a matter of about 10 minutes (less on a fast machine)

            You dont have to write your kernel file from scratch...

      • pf/nat (Score:2, Interesting)

        by adiposity ( 684943 ) on Wednesday December 24, 2003 @04:32PM (#7804275)
        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 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
      • by bark ( 582535 ) on Wednesday December 24, 2003 @07:12PM (#7805273)

        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 recompile. That's not the case if you just want to use the modules.

    • by Gothmolly ( 148874 ) on Wednesday December 24, 2003 @11:35AM (#7802729)
      "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 Anonymous Coward on Wednesday December 24, 2003 @12:45PM (#7803091)
        No ...

        The issue is that there may be hardware that is unstable with the current release, but without testing, that's unknown. Therefore, it's likely that it will be marked stable when all of the known bug reports are in, and at some later time, someone will show up with untested hardware that has bugs.
    • by dodell ( 83471 ) <dodell@ s i t e t r o nics.com> on Wednesday December 24, 2003 @11: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 Anonymous Coward on Wednesday December 24, 2003 @11:59AM (#7802848)
        STABLE is indeed not the most stable branch. But it _is_ comparable to Linux 2.4. 2.4.23 is a hell of a lot different than 2.4.0. They're "stable" in that they aren't having radical changes (although 2.4 did have some doozies), but they do have semi-active development.

        RELENG, as you're talking about, is nearly immutable. The only fixes are for security/stability. Sticking with, say, RELENG_4_9, is like picking kernel 2.4.23, and staying there, only applying patches that are absolutely necessary. So you have, say, 2.4.23p4 instead of jumping to 2.4.25 (or whatever).
      • by Anonymous Coward on Wednesday December 24, 2003 @03:33PM (#7803965)
        -STABLE is *NOT* the most stable branch

        And less is more, more is less. We have always been at war with Oceana.

      • by Anonymous Coward on Thursday December 25, 2003 @11:37AM (#7808108)

        I re-iterate. -STABLE is *NOT* the most stable branch. It is not comparable to 2.4 in Linux.

        Then what is? I know! 3.3-RELEASE!

    • by PatJensen ( 170806 ) on Wednesday December 24, 2003 @12:06PM (#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 @11: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 @11: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.
    • by nuintari ( 47926 ) on Wednesday December 24, 2003 @03:36PM (#7803985) Homepage
      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.
    • by xwred1 ( 207269 ) on Wednesday December 24, 2003 @06:02PM (#7804882) Homepage
      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.

    • by Anonymous Coward on Thursday December 25, 2003 @01:54AM (#7806785)
      Who said Linux AMD64 port isn't stable yet?

      I know it is stable, because I use one :-)

      Buy a system based on AMD (AMD 8000) or VIA (K8T800) chipset, and I think you will be fine.

      I use Gigabyte GA-K8VNXP (VIA K8T800), Athlon 64 3200+, 512 MB Kingston KVR400X64C25/512 DDR400, Seagate 120 GB 8 MB Cache ATA 100 hard drive, CD Burner, DVD Drive, Radeon 7000 Video card etc.. And I use SUSE 9 for AMD64 distribution.

      I have stress tested this system from both CPU, Memory and IO point-of-view (under both SUSE's 2.4.x kernel and custom 2.6.0-X8664), and I have not seen a single System stability issue. As for XFree86, the open-source radeon kernel DRI driver supports my card. I play TuxRacer with no problem :-).

      Refer some of these URL's and read users' feedback, before make up your mind:
      http://www.x86-64.org/mailinglists
      http:// marc.theaimsgroup.com/?l=suse-amd64&r=1&w=2

      The RedHat RHEL products support AMD64 platform. When Mandrake 9.2 for AMD64 will be released, I expect it be good. (I think a Fedora based distribution is in the make. I hear both Debian and Gentoo AMD64 distributions are in the make too.)

      IOW you need to get the right components then you will be fine. My advise is that do not buy a system where you need to use closed source (binary only) kernel drivers, that will spoil your Linux experience. IOW buy a system where everything works out-of-the-box from kernel.org's and x86-64.org's kernels (2.6.0 for eg..)

      All the best.

      Hari.
  • by rice_burners_suck ( 243660 ) on Wednesday December 24, 2003 @11:20AM (#7802654)
    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 @11: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.
  • by Jenty ( 471786 ) on Wednesday December 24, 2003 @11:43AM (#7802768) Homepage
    that's the best part IMGO: "Scott is asking everyone to test this release over the holidays". What a scary geeks you are !
  • by Anonymous Coward on Wednesday December 24, 2003 @11:49AM (#7802796)
    Scott is asking everyone to test this release over the holidays.

    Is this an example of copying the Microsoft practice of having the customers perform the actual testing?
  • Better jail support (Score:3, Informative)

    by gtrubetskoy ( 734033 ) on Wednesday December 24, 2003 @01: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.

  • by bmedwar ( 693432 ) on Wednesday December 24, 2003 @02:50PM (#7803733) Homepage
    How much longer will 5.x wear the "New Technology Release" label?
  • by Anonymous Coward on Wednesday December 24, 2003 @03:27PM (#7803928)
    I'm looking forward to trying this release out; I've been using FreeBSD 5.1 for a few months and have been very pleased with both the startup time and the relatively little difference between it and Linux. I mean that from a user's standpoint of course, I know the internals are drastically different, but quite a lot of source compiles on FreeBSD pretty easily with little or no patching, and there's always ports to handle that, which, digressing, is an extremely great feature that I know other OSes have. Anyway, it's worth a try if you're looking for something new, and I don't think you'll be entirely disappointed.
  • by the real darkskye ( 723822 ) on Wednesday December 24, 2003 @04:53PM (#7804424) Homepage
    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 broken, I've yet to encounter one that I can't compile under 5.x, including all the things I used to run under 4.x/3.x/2.2.x (yes i've had the same FreeBSD box that long)
    • by Anonymous Coward on Thursday December 25, 2003 @06:10PM (#7809645)
      I think I had a problem similar to yours. I have a Shuttle SN45G with an Athlon XP, and FreeBSD 4.9-R installed just fine, but installing 5.X was problematic. It would hang right at the end of the hardware detection process where it lists disks. It listed md0, and sometimes ad0 and acd0, and then just freeze before running sysinstall (or just before running init, after I finished installing). I fixed it by disabling ACPI. After it was installed, I was able to reenable ACPI after building a custom kernel. I'm guessing all the extra hardware probes in the GENERIC kernel were causing problems.
    • by kace ( 557434 ) on Saturday December 27, 2003 @01:55AM (#7816138) Homepage
      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 on Wednesday December 24, 2003 @07:00PM (#7805195)
    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.
  • by alcmaeon ( 684971 ) on Thursday December 25, 2003 @12:45AM (#7806577)
    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. :-)
    • by bersl2 ( 689221 ) on Thursday December 25, 2003 @02:17AM (#7806890) Journal
      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, Linux is Good, and yay 4 us.
  • by Anonymous Coward on Thursday December 25, 2003 @12:01PM (#7808171)

    In a startling turn of events today, a previously little-known fact came into the public eye: "*BSD Sux0rs". This came as a complete surprise to the BUWLA, or BSD Users With Large Assholes, as they previously thought that *BSD 0wned.
    "You see, even though I have never contributed code to any BSD project, I thought it was my duty to be a big asshole to others which don't use the OS I do, because it just 0wnz.", said one FreeBSD user. "Now that I know it sux0rs, though, I have to go find something else to be an asshole about."

    One notorious OpenBSD fanatic known as WideOpen, told reporters, "I have to kill myself. This isn't how it was supposed to happen. My BSD has always been the best, and shouting that opinion in other people's faces at every chance I got has been my only hobby. It was all I ever did. It was what got me out of bed in the morning. Now I have to die. I will jam my bedpost up my ass until I hit my brain. It is the only way to go: BSD style."

    In the volatile world of operating systems anything can happen. "At least we don't sux0r as much as Windows users", BigAzz, a relatively well-known NetBSD user said. "Screaming things in people's faces is my calling. Now I need to scream that BSD sux0rs. What a sad world. At least I won't kill myself like those uber-asshole OpenBSD guys. They are just way over the top. Or were, at least."

    Nobody knows for sure what the future holds for the state of operating systems, but with Netcraft confirming the sux0r status, *BSD users all over the world will have to stick something else up their asses from now on or risk looking even more gay than they used to.
  • by Jerk City Troll ( 661616 ) on Saturday December 27, 2003 @02: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.

    • by markscarbrough ( 712706 ) on Monday January 05, 2004 @04:42PM (#7884062)
      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 quite lengthy, can involve downtime, and the card sometimes causes a kernel panic when a failure is simulated. Still, even in this case a simple reboot solves the problem and the card operates fine with the degraded array after restart.

      If you are looking for ultra-cheap solution, or have one of these promise cards built into a mobo (as in my case), and you are more concerned with data integrity/redundancy than with 100% uptime, this card is definitely servicable.

      Good luck...
  • by Black Acid ( 219707 ) on Saturday December 27, 2003 @06:27AM (#7816619)
    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 1.1 instead of the much faster USB 2. No one seems to be working on ehci.c at the moment; Firewire portable drives currently seem to be a better option for support under FreeBSD.

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...