Hidetoshi Shimokawa recently posted a link to a FreeBSD FireWire driver, pointing out that it allows you remotely run gdb, even when the host you're debugging has crashed:

"As you know, IEEE1394 is a bus and OHCI supports physical access to the host memory. This means that you can access the remote host over firewire without software support at the remote host. In other words, you can investigate remote host's physical memory whether its OS is alive or crashed or hangs up."

Hidetoshi's full email follow's, as well as a security concern raised by Katsushi Kobayashi.

Today Oskar Andreasson has released version 1.1.0 of his iptables-tutorial package, a series of documents explaining netfilter to the layperson. He mentions quite clearly that he would appreciate it if netfilter coders/experts would "if possible, please have a closer look at the tutorial."

The tutorial can be downloaded at
http://www.boingworld.com/workshops/linux/iptables-tutorial

Below is the full e-mail message.

Byron Stanoszek posted a small patch to the lkml, his efforts at adding 32MB of video card RAM to the system RAM pool on his aging 586. A problem with this effort is the significantly slower speed of video RAM. For this reason, it has been suggested that he turn the video RAM into a block device which could then be added as a fast swap device.

An earlier lkml thread (from April 2000) was also referred to in which the same idea was discussed.

A recent thread on the lkml discussed the "OOM killer". The OOM (out of memory) killer has the task of choosing which process(es) to kill when the VM runs out of memory. Rik Van Riel has a full explanation of the OOM killer here.

Andrew Morton, who's been working on dividing the latest -aa VM into smaller pieces for mainline inclusion, submitted a patch about which he says:

"I have incorporated the oom killer into try_to_free_pages(), along with a tunable which defines how hard we work before killing something. It is *extremely* conservative. As it should be. The VM will spin madly for five or ten seconds before giving up and calling the oom killer. And then another five seconds elapses before the oom killer decides to actually kill something. It works."

The thread goes on to compare the mainline VM with the -aa VM. It also looks at ways to further tune the OOM killer.

Alexis Carvalho asked on the lkml, "Does anyone know of any implementation of soft-updates over ext2?" He went on to explain that he was intending to implement this as a project for grad school. The discussion that followed considered some of the pro's and con's of adding soft-updates to ext2.

For further reading, see our earlier interview with Theo de Raadt in which there's a lengthy discussion of soft updates versus journaling. Theo also recommends this USENIX paper.

The thread also discusses the tux2 filesystem, which uses a phase tree algorithm. Find the original (Aug 2000) announcement here.

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

Murray Stokely posted the following to the FreeBSD announce mailing list:

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

FreeBSD Security Advisories have been routinely sent out in the past to advise of security issues in the base FreeBSD system, as well as occasionaly in third-party applications.

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.

To keep up to date on FreeBSD security issues, you can subscribe to the FreeBSD Security Notifications mailing list. All advisories are archived on this web page.

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.

Linus (2.5 tree - earlier story) and Marcelo (2.4 tree - earlier story) are now both using BitKeeper for kernel source control.

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.