Slashdot Mirror
FreeBSD 5.2.1 Released
Kalev writes "The FreeBSD Release Engineering Team has announced FreeBSD 5.2.1-RELEASE. This is intended to address several bugs and vulnerabilities discovered in the FreeBSD 5.2 release. See the Release Notes. The release is now available for downloading. If you are currently running FreeBSD 5.x, you can easily cvsup to it or use binary upgrade feature of sysinstall."
No, it wasn't a rush, but people didn't test it enough.
That is usually the problem, 5.1 ran so well that people didn't want to test the RC's, thus some bugs didn't get ironed out for _their_ hardware.
The thing is, if these people had downloaded the livecd of RC2 and sendpr'ed this release wouldn't be needed.
You should blame people for their lack of will to test but strong will to always complain.
Is it just me or are point point releases of FBSD pretty rare?
:) ).
You're right. The only other one was 4.6.2-RELEASE. (I'm not counting the 2.2.x releases -- 2.2 was a major version number
Almost seems like 5.2 was a bit of a rush job.
5.2 was right on the boundary between "experimental" and "stable". As such, lots of people started using it once it was released, but few people actually participated in testing it. I believe that 5.2 had one of the longest ever periods between code freeze and release.
Tarsnap: Online backups for the truly paranoid
[I posted the message below to -current and -security, providing an easier upgrade path from 5.2-RELEASE to 5.2.1-RELEASE]
/usr/ports/security/freebsd-update && make install clean /usr/local/etc/freebsd-update.conf.sample /usr/local/etc/freebsd-update.conf /usr/local/sbin/freebsd-update fetch /usr/local/sbin/freebsd-update install
/usr/local/sbin/freebsd-update --branch crypto fetch /usr/local/sbin/freebsd-update --branch nocrypto fetch
/usr/ports
/usr/share/doc
/usr/share/man/cat*
/usr/src
/usr/share/man/cat* are rebuilt from (updated) man pages
In order to provide an easy update path for i386 systems from
FreeBSD 5.2 to FreeBSD 5.2.1, FreeBSD Update will now update
systems running FreeBSD 5.2-RELEASE to 5.2.1-RELEASE. To take
advantage of these updates, install and run FreeBSD Update, and
reboot into the new kernel:
# cd
# cp
#
#
# shutdown -r now
If you have recompiled any files locally, FreeBSD Update may
not be able to update them automatically (it will complain).
With the latest version of FreeBSD Update (version 1.5), you
can use one of the following commands:
#
or
#
depending upon whether you installed the "crypto" distribution,
to force files to be updated. (If you're not sure if you
installed the "crypto" distribution, you almost certainly did).
FreeBSD Update will update a 5.2-RELEASE system to the exact
binaries distributed with 5.2.1-RELEASE, with the following
exceptions:
1. Files under the following directories will not be updated:
The ports and src trees can be updated using cvsup; the files
in
automatically.
2. FreeBSD binaries include, in their headers, the value of
__FreeBSD_version on the machine where they were compiled.
This value was bumped from 502000 to 502010 as part of the
release engineering process; binaries for which this is the
ONLY change will not be updated.
As always, this is something I'm providing personally; it is
in no way endorsed by the Security Officer, Release Engineering
team, or the project as a whole.
Colin Percival
Tarsnap: Online backups for the truly paranoid
Almost seems like 5.2 was a bit of a rush job.
As Colin pointed out in a peer post here, 5.2 had quite a long release cycle. If you look at the 5.2 release schedule you'll note that we spent almost 2 months on it. Add in that 5.1 was released in June of 2003, and you have quite a long dev cycle. We did the best that we could to manage risks in the 5.2 cycle, but shortly afterward it became apparent that there were some significant bugs in certain modules that didn't gain much attention until after the release was made.
Cat, the other, tastier white meat.
4.6.1 never existed. It was going to exist, but some security issues appeared, so it was aborted. But you're right, I forgot about 3.5.1-RELEASE, mostly because it was never tagged in the CVS repository.
FreeBSD 4.1.1 existed also, and was tagged. However, it was a branch off of RELENG_4 instead of RELENG_4_1 and turned into a disaster. But yes, ever since 3.0, we've had few point releases.
Cat, the other, tastier white meat.
actually if you had looked at http:www.freebsd.org/releases/index.html
You would have noticed that 4.1.1 was the first point point release in almost two years after the decision that they were unneccesary extra work.
For 4.1.1 it was decided it was worth it because of the expiring of the RSA patents, it allowed the security pieces to be more easily merged in for US users.
For the record, FreeBSD's scheduler was already O(1), it just didn't handle SMP extremely well. The new ULE scheduler handles the SMP case much better, along with other nice improvements. See Jeff's paper at http://www.chesapeake.net/~jroberson/ULE.pdf
h andbook/current-stable.html, and read the early adopters guide.
The release engineering team certainly does have high standards. Trying to live up to the stability reputation. But keep in mind that 5.x still is considered in testing and major changes can still be afoot that can cause instabilities. So please still keep in mind what -current means, http://www.freebsd.org/doc/en_US.ISO8859-1/books/
5.x will get better and better as it approaches 5.3R, so while some of the problems running a -current release are lessened, one should still be aware of all this and the higher standard for fixing one's own problems when running 5.x. RTFM is not an insult when running 5.x, its simply a price of entry to a great OS.
The AMD64 platform is currently a Tier 1 FreeBSD platform.
Current Tier 1 platforms are i386, Sparc64, AMD64, PC98, and Alpha.
Current Tier 2 platforms are PowerPC and ia64.
Current Tier 3 platforms are S/390(R).
All systems not otherwise classified into a support tier are Tier 4 systems.
All information lifted verbatim from the FreeBSD website most of it from Section 10 of the Committer's Guide, Support for Multiple Architectures
So expect as much support for AMD64 as you would for the standard PC version, the only thing keeping AMD64 back is it's not a widely distributed and therefore not as well tested.