Randy Hron posted some benchmark results comparing numerous different 2.4 kernel branches. He says, "On an OSDL 4 way x86 box the O(1) scheduler effect becomes obvious as the run queue gets large."
Using tbench with 192 processes, his tests show the latest O(1) incarnation to offer approximately a 340% improvement in throughput! (Both Alan Cox's -ac patch and J.A. Magallon's -jam patch set include the latest O(1) scheduler, and both show the dramatic improvement in throughput) Randy intends to do more testing, the results of which will be posted here.
Marcelo released the 2.4.19-pre8 stable Linux kernel today, explaining that -pre9 would follow and then -rc1. 2.4.18 was released on February 25'th, over two months ago. Marcelo explained the delay:
"One might ask why 2.4.19 is taking so long to be released. The reason are the IDE changes: They need to be widely tested, its _really_ critical code."
You can find the full changelog here.
Keith writes: "It is faster, better documented, easier to write build rules in, has better install facilities, allows separate source and object trees, can do concurrent builds from the same source tree and is significantly more accurate than the existing kernel build system." He goes on to ask if Linus wishes to completely replace the old kbuild with the new, temporarily breaking unsupported architectures, or to have the two build systems coexist for a few releases.
Jordan Hubbard recently announced that he was stepping down from the FreeBSD core team, "After giving it a fair bit of thought over the last few weeks, I have decided to step down from core. I am doing this for a variety of reasons, any one of which would probably be sufficient grounds in and of its own and, taken in combination, certainly constitute ample justification for doing so". His reasons included a lack of time and energy, a feeling that the core group isn't what it once was, and a recent lack of personal enjoyment. He currently works for Apple as an engineering manager for the BSD based Darwin Project. He intends to continue contributing to FreeBSD as well.
In September of 2001, Keith Owens modified modutils to detected "tainted" kernels, or kernels with binary-only modules loaded into them. When binary-only modules are loaded and cause problems, kernel developers don't have access to the source code and are hence unable to debug the problem. Knowing whether a kernel is tainted can save them much wasted effort.
When a binary-only module is added to the running kernel, the following message is displayed: "Warning: Loading %s will taint the kernel..." (%s being replaced with the name of the binary only module) As a result of a recent lkml thread, with the release of modutils 2.4.16 the message also offers this URL to the lkml FAQ with a more complete explanation.
A linux server is capable of functioning as an assortment of different network devices. For example, it can act as a router, a switch, or even a network bridge. In the latter case, two or more ethernet networks are linked, or bridged together logically and transparently to make one larger network. Learn more about bridges in this faq.
Torrey Hoffman recently posted information on a patch he's written to the ethernet bridge driver to allow encryption in an ethernet bridge. His driver patch is intended as a tool for further development, currently applied against the 2.4.17-pre7 kernel. The example usage he describes is running multiple MPEG streams across the bridge, encrypting each with a different key to prevent the video from being copied when transferred across the network. Find more information on the project's home page. The patched ethernet bridge driver uses the AES (aka Rijndael) encryption algorithm. For Torrey's announcement email, read on.
Earlier this month Keith Owens announced v2.0 of kbuild 2.5, offering among other improvments a 30% speed increase over kbuild 2.4. (kbuild 2.4 is the currently used build system in the 2.4 and 2.5 kernel trees.) Several days ago, v2.1 of kbuild 2.5 was released, moving towards kernel inclusion.
When asked what he was waiting for, Keith replied, "For me to be satisfied that the code is stable, the rewrite with go faster stripes is less than four weeks old." [Earlier Story]
v2.1 offers a few minor bug fixes. Keith comments, "You know the code is getting stable when most of the changes are documentation and white space from Lindent :)" Later he mentions another improvement the new system has over its predecessor, "With kbuild 2.5 you do not need to 'make clean' before building, unlike the existing build system, kbuild 2.5 gets it right."
A recent thread on the FreeBSD hackers mailing list began when Jordan Hubbard reported odd behavior with ssh in the 4.5-STABLE tree. The change in behavior was due to a change in the default setting in the interests of security. During the dicussion another change to default behavior was brought up where X11 now has TCP forwarding disabled, prefering instead that the users tunnel X connections through ssh.
Much of the resulting protest was at how this changes FreeBSD's default behavior, creating confusion. Joerg Micheel said, "The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century."
The attempt is to make the default installation more secure. Terry Lambert points out, "I really don't think there's any way to fully protect a security-unconscious user, as if they had spent the time to learn what was necessary, and chosen the right settings for their site. Nothing can replace a system administrator who knows which end is up."
Finally, as the conversation considered whether such changes were security by obscurity, Robert Watson offered, ""Security by obscurity" refers to a behavioral phenomena in system design and delivery, not to a technical design principle. For example, it refers to using a secret algorithm, but does not refer to using a secret key with a published algorithm. So disabling services in a default configuration reduces risk by reducing exposure, but it's not security by obscurity. "
Mark Mitchell has annouced he is planning to make the GCC 3.1 RC1 yesterday and that it should be out soon after. I have been trying to move my distribution to gcc 3.04, and I hope this fix the few remaining issues. Mark's email follows:
The latest IBM middleware for Linux (DB2 Universal Database, WebSphere Application Server, WebSphere Studio Application Developer, and Lotus Domino) is being provided, at no cost, on a 2 CD set, along with Web Services technologies, Linux technical articles, Linux Redbooks, and the very popular Java battle-bots game Robocode. IBM is also providing a worldwide no-cost 2-day Linux workshop, which includes hands-on labs for installing and configuring Linux.
Robert Love recently submitted a group of O(1) scheduler patches for Alan Cox's 2.4-ac branch. The eight patch set brings the ultra-scalable scheduler up to date in the 2.4 stable tree, back porting the many fixes and improvements that were up to now only found in the 2.5 development tree. Robert highlights the addition of the migration thread as the most important change. Though the currently submitted patches are only for 2.4.19-pre7-ac2, Robert noted that he'd be making patches available for 2.4.18 and 2.4.19-pre7 shortly.
A buffer overlow has been discovered in OpenSSH by which in a worse case scenario remote users can gain privileged access to a server. Fortunately the bug is not present in a default install, and therefore it likely does not affect the vast majority of users. According to the OpenSSH security advisory: "All Versions of OpenSSH compiled with AFS/Kerberos support and ticket/token passing enabled contain a buffer overflow. Ticket/Token passing is disabled by default and available only in protocol version 1."
If you have compiled in AFS/Kerberos support and have ticket/token passing enabled:
Updated: Updated advisory follows.
Erich Focht submitted a patch to the lkml, fixing a bug in migration threads (in the 2.5.8 development kernel) that lead to a deadlock, or frozen system. In the process of fixing the bug, he also worked to cleanup the initialization of the migration threads.
In an earlier email to the lkml, Ingo Molnar explained migration threads:
"The concept is the following: there arenew per-CPU system threads (so-called migration threads) that handle a per-runqueue 'migration queue'. set_cpus_allowed() registers tasks in the target CPU's migration queue, kicks the migrating thread and wakes up the migration thread. The migrating thread unschedules on its source CPU, at which point the migration thread picks the task up and puts it into the local runqueue."