When upgrading to the latest kernel, it's generally preferable to apply one of the two major VM patches. One of the patches is maintained by Andrea Arcangeli, the author of the current standard 2.4 kernel VM. In a recent email, Andrea referrs to his vm-33 patch, recommending that you "never use a 2.4 kernel without first applying this vm patch". Andrew Morton also recently broke this patch into smaller pieces to allow for easier inclusion into the mainline kernel.
The other available patch is Rik van Riel's rmap VM. [Earlier story] Regarding this effort, Rik says, "This is an attempt at making a more robust and flexible VM subsystem, while cleaning up a lot of code at the same time." Today he released rmap-12i, now based on Marcelo's main 2.4 kernel tree. The -rmap VM is currently included in Alan Cox's -ac patches.
Emails from both Andrea and Rik follow.
Hans Reiser recently submitted a group of 13 small patches for ReiserFS to Linus Torvalds - one of which was labled as critical, fixing a filesystem corruption issue. Specifically, that patch "Fixes a problem that was created during inode structure cleanup/ private parts separation. This fix was made by Chris Mason. This is very critical bugfix. Without it, filesystem corruption happens on savelinks processing and possibly in some other cases." Please note, this corruption only affects ReiserFS in the 2.5 development kernel.
In the same brief email, Hans stated, "We will set up a secure bitkeeper clone later this week, for now we send you old fashioned patches".
"A Developer Preview release of FreeBSD 5.0-CURRENT is now available for widespread testing. This preview is a significant milestone towards the eventual release of FreeBSD 5.0 in late 2002."
5.0-DP1 is available for the i386, alpha, and sparc64 architectures. Murray's full announcement email follows, with complete details as to what's included in this release and where to get it. Also check out the release notes and errata.
The advisories tend to be a thorough look at the problem, and certainly take time to prepare. In an attempt to be more timely with security issues, Advisories are being split into two parts: Notices and Adivisories. The former are new and are to be used to notify of third party software security issues. Advisories, then, are left for FreeBSD specific issues and will retain their comprehensive format.
OpenBSD is on a six month development cycle. The last official version, OpenBSD 3.0, was released on December 1st, 2001. The next version, 3.1, is due to be released on June 1st, 2002. (At some point, more information on this upcoming release will appear here.)
Last November we spoke with OpenBSD creator Theo de Raadt, who offered much insight into the world of OpenBSD development. From his description of their development cycle, we know that OpenBSD developers are working this month on a final image of 3.1 (while in development referred to as -current). Some time around May 1, -current will become the official 3.1 release and production will begin on the CD's. The -current tree, currently locked to all but those making important bug fixes, will be reopened, entering what Theo calls "the insane month", explaining that this is "because many developers have completed projects over the last two months which were not permitted in because of the lock."
Theo describes OpenBSD development as evolutionary instead of revolutionary. Understanding this concept helps one to properly anticipate 3.1. As reflected in the following email, the OpenBSD packet filter, PF, has undergone significant improvements with this release. (PF was introduced in 3.0, after the previous packet filter, IPFilter, was removed due in part to issues with its license.) 3.1 also offers support for wavelan bridging, and the Sparc64 port underwent a memory model change. The full list of improvements can be found on this page.
Larry McVoy, the author of BitKeeper (BK), recently sent an email to the lkml briefly summarizing the past two months of BitKeeper usage for the Linux kernel. He acknowledged that "BitKeeper overhead for maintaining this information, the changeset stuff, is about 7MB uncompressed. It started at about 1.5MB for the initial baseline, so we're growing at about 3MB/month, which is a problem."
He posted a four point list of improvements planned for BK in the near future. The changes include a fix for the problem mentioned above, as well as better performance of updates, LODs for temporary patch inclusion testing, and nested repositories.
" The first goal of this project is to create virtual servers sharing the same machine. A virtual server operate like a normal Linux server. It runs normal services such as telnet, mail servers, web servers, SQL servers. In most cases, the services run using standard configuration: The services are running unaware of the virtual server concept.Normal system administration is performed with ordinary admin tool. Virtual servers have users account and a root account."
One big improvement in this version is the introduction of a simple install script for RedHat 7.2 systems. Author Jacques Gelinas adds, "I would be interested in other script like this to install SuSE, Mandrake and Debian from scratch."
kbuild 2.5 v2.0 was released today by Keith Owens. One major improvement in this new version is a 30% speed increase over kbuild 2.4 by replacing a text-file read at each compile step with a memory mapped database (mdbm from BitKeeper). Regarding the speed gain, Keith says, "Now the nay-sayers will have to find something else to complain about!". He also warns, "... You know what they say about .0 releases ... User beware."
Currently this version is only available for i386 architectures. However, Keith adds, "Patches for other architectures and kernels will be out in the next few days, it takes time to generate and test patches for multiple architectures against different kernel trees."
Another interesting debate recently ensued on the lkml, this time with kernel guru Alan Cox in the middle. The topic was related to the GPL (hence the emotions involved), though specifically referring to the changing of an EXPORT_SYMBOL_GPL flag to EXPORT_SYMBOL. Among the questions raised is whether this infringes upon a developer's rights...
Much of the debate follows, involving many kernel notables, including Andrea Arcangeli, Alan Cox, Rik van Riel, Ingo Molnar, and Linus Torvalds. Many good points are raised on both sides of the issue, making for an interesting read...
On the FreeBSD-Hackers mailing list, John Regehr discussed a paper he's working on about a tool that measures scheduling behavior on different operating systems. While writing this paper, he noticed an anomaly between the context switches in FreeBSD versus Linux.
Terry Lambert replied to John's query with a lengthy and informative response. In it, he predicts,
"I expect that under real load, the relative performance of FreeBSD vs. Linux will depend on the number of threads in a thread group (threaded process). I expect that under real load, you will see that FreeBSD performs well at 6 for 2 CPUs (that's the expected break-even point of random replacement vs. ordered replacement with starvation), and at more than that, FreeBSD performance will degrade slower than Linux for more threads (processes with shared VM), but degrade faster than Linux for more CPUs.
"I also expect that FreeBSD 5.x, when released, will blow the doors off of most commercial offerings, even though I would have done a lot of things differently (e.g. interrupt threads). I look at these issues as "room for future improvement" that other OS's don't have."
Mike Silbersack recently announced a plan to change the FreeBSD default ephemeral port range from 1024-5000 to 49152-65535. A debate on the usefulness of this change followed. During that debate, Mike explained:
"The ephemeral port range determines the maximum number of simultaneous outbound connections that you can have. As pointed out in a PR (I don't recall the # offhand), our low limit was probably the reason that FreeBSD ran out of steam before the other OSes in the sysadmin benchmark last year."
This greatly increases the outgoing pool, from 3,976 ports to 16,383 ports. You can find information on changing the ephemeral port range in FreeBSD here (allowing you to locally revert the upcoming change if it causes you problems). The same document provides instructions for Linux, OpenBSD, Solaris, Windows and many other operating systems, too.