FreeBSD 4.11-RC2 Available

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

Comments

Why RedHat 8?

[Trevin]

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 there).

Re:Why RedHat 8?

[ValiantSoul]

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?

[molnarcs]

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?

[Anonymous Coward]

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?

[endx7]

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?

[TheGratefulNet]

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.

Re:Why RedHat 8?

[molnarcs]

Of course, you are right, thanks.

Re:Requiem for the FUD

[BossMC]

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.

Re:Kreskin said it !

[chinhngt]

May be you miss a thing, FreeBSD is not a commercial project/OS. The market share or some other shits is not a goal of FreeBSD (and maybe it's also right for others *BSD). So, please stop trolling here. I use both Windows and FreeBSD, and I love them, I don't care if they are popular or not. They help me solve my problems, help me understanding more prety things and that's enough.

linux emulation FINALLY WORKS!

[TheGratefulNet]

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

[r7]

Can someone clarify FreeBSD's terminology? I thought a release candidate was different from a beta (known in FreeBSD-speak as a -STABLE).

Re:2nd of 3 "Release Candidates"?

[TheRaven64]

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.

Re:2nd of 3 "Release Candidates"?

[endx7]

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 is where -CURRENT lives. There are no separate -CURRENT branches; when -CURRENT gets branched the branches become -STABLE or -RELEASEs. -CURRENT only gets a version number as the next upcoming "branch". The only way you can find other "CURRENTs" is by going up and down the trunk.

I had a nice "ascii" tree laid out which explained it better, but slashdot shot it down with its lame lameness filter.

Also, this is the way things are laid out today as I can see it. Releases/branches may have been done differently in the past.

Benchmark: NetBSD 2.0 beats FreeBSD 5.3 in server

[hubertf]

``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/