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