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

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

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.

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.

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.