Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software BSD

FreeBSD 4.11-RC2 Available 55

Posted by timothy from the keeping-stable dept.
hugo_pt writes "The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 4.11-RC2. This is the second of three scheduled release candidates. At the moment there are no known severe issues. However the Linux Emulation subsystem (mostly added as a package) has been completely updated based on Red Hat 8.0. We would appreciate people testing the Linux emulation support. In particular testing to see if Linux applications continue to behave correctly if the linux_* packages get installed while using sysinstall(8) during the initial installation of the machine. The package set for disc1 is still being decided on, what is on disc1 for this RC will most likely change before the release."
This discussion has been archived. No new comments can be posted.

FreeBSD 4.11-RC2 Available More

FreeBSD 4.11-RC2 Available

Comments Filter:

  • Why RedHat 8? (Score:2, Interesting)

    by Trevin ( 570491 )
    Forgive my ignorance, since I don't usually follow the FreeBSD distro (having moved from NetBSD to RedHat over four years ago). But it seems a bit late to be targeting the Linux emulation towards RedHat 8.0. Not only has RedHat 9 already been obsoleted by Fedora, but 8.0 was extremely short-lived (even by RedHat's usual release timeline) having had numerous problems. In addition, before the days of RedHat Enterprise, RedHat recommended that users requiring stability stick with 7.2 (or something around th

    • Re:Why RedHat 8? (Score:3, Informative)

      by ValiantSoul ( 801152 )
      The RedHat 8 emulation has been around for a long time in FreeBSD, it has just been updated. I'm not positive why its only version 8, but I'm guessing its because most applications that will work on today's distibutions probably work on RedHat 8 (with minor updates such as glibc).

    • Re:Why RedHat 8? (Score:5, Informative)

      by molnarcs ( 675885 ) <csabamolnar@gm a i l . com> on Tuesday January 04, 2005 @08:55AM (#11252678) Homepage Journal
      As ValiantSoul said, rh8 has been there for a long time, but the default was rh7.x - which has changed to 8 now. The reason is that a few linux-apps didn't work with rh7 (a few!). All current linux-apps in FreeBSD ports works well with rh8, (most of them work well with rh7 as well), so I guess for at least a year 8 will be sufficient. Since FreeBSD is all about stability (even cutting edge ports), it makes sense that they switched to a well tested default. I, for instance, changed the default linux base to linux_base8 right when I began using FreeBSD (in 2003 september) with 5.1 release, and no ports gave me trouble. For your interest: rh-9 is already in ports btw, along with a few others:

      linux_base/ # stands for rh7
      linux_base-6/
      linux_base-8/
      linux_base-debi an/
      linux_base-gentoo-stage1/
      linux_base-rh-9/
      linux_base-suse-9.1/

      • Re:Why RedHat 8? (Score:4, Informative)

        by endx7 ( 706884 ) on Tuesday January 04, 2005 @10:34AM (#11253186) Homepage Journal
        The biggest reason why they changed from rh7 as default in ports to rh8 was that rh7 had an unpatched vulnerability. Redhat seems to have no interest in maintaining and updating these outdated versions, so the default had to change.

        It probably wouldn't be terribly hard to get FC3 working as a base since it, like the other redhat-related releases that we have already, use rpms, which we already know how to handle. Although, I haven't tried it, so I can't tell you for definite.

    • Re:Why RedHat 8? (Score:5, Informative)

      by Anonymous Coward on Tuesday January 04, 2005 @09:53AM (#11252953)
      It works and has no security issue (like 7) and is well enough tested (unlike 9).

      Luckily it was already in the port system (just as 7,9, debian ,gentoo and suse 9.1) so it was "easy" to make that the standard port (linux_base). Perhaps when Fedora gets in the ports that will become the standard for the linux emulation.

      BTW FreeBSD (like any other BSD) is not a distro, it is an OS.
      The difference in words is subtile but for everything else it is a real different way of thinking.

      --
      Martin P. Hellwig

    • Re:Why RedHat 8? (Score:4, Interesting)

      by TheGratefulNet ( 143330 ) on Tuesday January 04, 2005 @11:32AM (#11253639)
      rh7 was a hack. its emulation was very broken for me (see my mp3 encoder post).

      rh8 libs and such finally make things work.

      in short, they did The Right Thing.
    • I can't say "why RH8" but I can give one issue that is sufficient to say "Why not 7.3" (which is one of your options) - g++296. The g++ issue has proven to be a major PITA for RH 7.3. The system compiler is a redhat fork of gcc, is incompatible with everything both before and after it, and 7.3 is already end of lifed, so no support from redhat. You's stuck with a system compiler with absolutely zero support, outside of some guys from Fedora that keep a compat RPM around, that you'd have to backport all t
  • ... facts are facts. ;)

    FreeBSD:
    FreeBSD, Stealth-Growth Open Source Project (Jun 2004) [internetnews.com]
    "FreeBSD has dramatically increased its market penetration over the last year."
    Nearly 2.5 Million Active Sites running FreeBSD (Jun 2004) [netcraft.com]
    "[FreeBSD] has secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames and half a million active sites since July 2003."
    What's New in the FreeBSD Network Stack (Sep 2004) [slashdot.org]
    "FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Lin

    • Re:Requiem for the FUD (Score:5, Interesting)

      by BossMC ( 696762 ) on Tuesday January 04, 2005 @04:41AM (#11252088) Homepage
      Dear AgainstTheFUD (840249), Being a FreeBSD user, I find myself reading the Slashdot BSD section once in a while. In light of the fact that your posts are somehow modded above 0, I end up reading your same stupid post over and over again. This is becoming a nuisance, as it is irrelevant to the story. At least the *BSD is dying trolls are modded down, thus shielding my eyes from "The FUD." I am politely asking you to shut the hell up. You are not providing a service; you are feeding the trolls in a routine fashion, and I hate it. Stop. Thanks in advance.

  • linux emulation FINALLY WORKS! (Score:4, Interesting)

    by TheGratefulNet ( 143330 ) on Tuesday January 04, 2005 @11:30AM (#11253605)
    yay!

    the issue I had was with some closed-source (sigh) software that was linked against old old libc. it was a $200 mp3 encoder that I bought and ran fine under RH6.x. but never under later versions. even running this binary under modern LINUXs caused problems. this being the best encoder I have ever heard - and having paid $200 of my own money for it - I really wanted this to work. and since I'm now a 100% freebsd user, I needed this to work with bsd.

    it does now. I'm sooo happy about it. finally I can get rid of all my linux compute-servers on my mp3 render farm. they are now all 4.11 bsd boxes and couldn't be happier.

    I'll probably submit this to the bsd guys, but it would be nice if they included these files as well. I needed them for this last level of linux emulation:

    compat/linux/lib/libc.so.5
    compat/linux/lib/lib m.so.5
    compat/linux/lib/ld-linux.so.1

    those get you libc (not glibc) compat, from what I can tell. when I did an LDD on the mp3 encoder binary, it showed this:
    /usr/local/bin/mp3enc31:
    /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x280ad000)
    libm.so.5 => /lib/libm.so.5 (0x280b3000)
    libc.so.5 => /lib/libc.so.5 (0x280bb000)
    libc.so.6 => /lib/libc.so.6 (0x28184000)
    /lib/ld-linux.so.1 => /lib/ld-linux.so.1 (0x2809a000)
    this is the first time since freebsd 3.4 (I think) that I've gotton this old linux binary to run under freebsd.

    again, yay!

    great work guys. you made my week.

  • 2nd of 3 "Release Candidates"? (Score:3, Insightful)

    by r7 ( 409657 ) on Tuesday January 04, 2005 @11:34AM (#11253670)
    Can someone clarify FreeBSD's terminology? I thought a release candidate was different from a beta (known in FreeBSD-speak as a -STABLE).
    • I think a beta means "enough of the stuff is there for us to want the public to test it". RC means "if the problems are cleared up we can release this unchanged".

    • The difference has to do with the types of changes that can be committed. Basically, it is harder to get a change approved after the RC stage.

      Check out the FreeBSD Release Engineering [freebsd.org] page for more info.

    • Re:2nd of 3 "Release Candidates"? (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Tuesday January 04, 2005 @02:14PM (#11255514) Journal
      Can someone clarify FreeBSD's terminology? I thought a release candidate was different from a beta (known in FreeBSD-speak as a -STABLE).

      Wrong. -STABLE and -RELEASE are two different things. FreeBSD is divided into 3 categories of branch.

      -CURRENT
      This is the bleeding edge. Code here will probably work. More or less. It may break, or it may only be partially functional. This branch should not be used on production machines, since there is no guarantee that changes to the -CURRENT branch will not break things. There is usually one -CURRENT branch for each major release in active development (e.g. 4-CURRENT and 5-CURRENT)
      -STABLE
      Changes to -CURRENT that have undergone sufficient testing to be deemed stable are moved into the corresponding -STABLE branch. There is no restriction on the kind of changes that can be made to -STABLE except that they are not allowed to break things.
      -RELEASE
      These branches start life as snapshots of -STABLE. Once a -RELEASE branch has become a release (e.g. 4.10-RELEASE) the only changes allowed to it are security and bug fixes. No feature enhancements are allowed. If you have a production system, it is usually better to track a -RELEASE than to track -STABLE because, although -STABLE is not supposed to break anything, it is not possible to test it with every possible combination of hardware and software.
      Beta and release candidate builds are stages between a -STABLE branch becoming a -RELEASE branch. Once build is named a beta, new features are not (usually) allowed to be added. When it is named a release candidate, it is even harder to add changes. Ideally, a release candidate will, after a period of testing, be renamed a -RELEASE.
      • Well, not only that, but -RELEASE can refer to -CURRENT snapshots as well (such as the early 5.x releases when 5.x was still -CURRENT). Also, after a certain amount of time, -STABLE branches become errata branches. 4.x has become this. You basically come out with: "Production Release" (STABLE), "Technology Preview" (CURRENT), and "Production (Legacy) Release" (errata, a type of STABLE).

        Also, there is only "one" -CURRENT, at least in terms of CVS at least. This is HEAD and the main cvs trunk, and that i
      • Wrong. -STABLE and -RELEASE are two different things

        I think you missed my point. Obviously -STABLE is not a release. But going by FreeBSD's terminology it's not a release candidate either. The category before RC is BETA. By that common definition -STABLE is no different from BETA whereas -CURRENT is ALPHA.

        My main question was how do you have 3 RCs without the first 2 not being RCs at all?

        Really looks like a bad case of NIH to me.

        R7

  • Benchmark: NetBSD 2.0 beats FreeBSD 5.3 in server (Score:3, Interesting)

    by hubertf ( 124995 ) on Wednesday January 05, 2005 @10:19PM (#11271651) Homepage Journal
    ``With the recent releases of NetBSD 2.0 and FreeBSD 5.3 operating system, many new and exciting features have been implemented. Both criticism and commendation on performance, reliability and scalability have been directed towards these releases.

    This paper presents a suite of benchmarks and results for comparing the performance of these operating systems. The benchmarks target core operating system functionality, server scalability and thread implementation. These benchmarks are useful server-based criteria for demanding applications such as loaded webservers, databases, and voice-over-IP (VoIP) media relays. The results indicate that NetBSD has surpassed FreeBSD in performance on nearly every benchmark and is poised to grab the title of the best operating system for the server environment.''

    Full paper: http://www.feyrer.de/NetBSD/gmcgarry/ [feyrer.de]

    • "The results indicate that NetBSD has surpassed FreeBSD in performance on nearly every benchmark and is poised to grab the title of the best operating system for the server environment."

      While an interresting UP benchmark it in no way says anything about performance for SMP machines and 64-bit CPUs. That is what matters for most servers today (at least those that would be suitable for a new OS) and that's where all servers will be tomorrow.
      • FreeBSD is already known to have made a lousy AMD64 implementation, a lousy SMP implementation (which, on 2-way and probably 4-way SMP machines, is actually SLOWER than NetBSD 2's giant lock model), and haven't even finished supporting their new kernel facilities on Sparc64 and Alpha.

        So if this test was even possible on a 64 bit CPU in SMP mode, it wouldn't save FreeBSD. The source is out there though, so why not run it yourself? Of course it won't help because all of those are UP-centric micro benchmarks
        • Actually, I just re-read your post, and noticed you have no clue at all. Let me explain: an algorithm is an algorithm. It doesn't matter if it's running on a machine with one or two procs, one instance of the algorithm will still only run on one processor at a time. It doesn't matter if it's 64 bit or 32 bit, since NetBSD is 64-bit-clean and hence doesn't have nasty side effects; let's assume FreeBSD is up to scratch on this as well. The algorithms will still scale the same and, if the instruction horse pow
          • If you read my post again then you must also have noted that I never mentioned algorithms but the notion parent used that "is poised to grab the title of the best operating system for the server environment."

            What I did not clarify is that I ment proper server tests with actual workloads where SMP machines are used. The benchmarks are mostly checking the microoptimisations of a UP machine and it is well known that the current state of FreeBSD 5 is not optimized towards that. I also assume that you have mi
            • Apologies, I guess I misunderstood your post as saying the benchmarks were run on the wrong kind of system, rather than the benchmarks being used for sweeping assumptions.

              So 5-STABLE is actually becoming worth using, you say? I'd like to try that, in fact I will when I can afford to (currently only two machines under my control and both are life-critical, for my life anyway). I've really wanted to get back into FreeBSD, it's highly usable and all, but my negative experience with 5.3 (yes, even tracking -S
    • It's a pity that your first reference to the massive barrage of criticism FreeBSD received is to this guy's [slashdot.org] crappy journalism.

      On the other hand: nice (micro)benchmarks! Thanks :) It appears that FreeBSD developers know of these issues:

      Since the performance optimization on FreeBSD for the last few years, with features like SMPng, libpthread, and UMA, has been focussed on macro performance not micro performance, it's not surprising the micro performance requires tuning. However, there is lots of on-going wo

Slashdot Top Deals

BLISS is ignorance.

Close