Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for June 6, 2002Fun with software patents Much of this week's LWN front page has to do with software patents, and how to respond to them. Doubtless some people are tired of the topic, but it remains important. The shape of our free software systems in the future will, unfortunately, be much affected by software patents. It is important that we figure out how to deal with them.
Red Hat and software patents Software companies worry about software patents; an infringement suit can, after all, ruin your whole day. Red Hat has decided that the best way to deal with the problem of software patents is to get into the game. So, the company has applied for (at least) two patents:
Both of these techniques show Ingo Molnar as the inventor. And where might one find the patented technology? The
embodiments of the present invention described are implemented in a
computing platform based on the computer operating system commonly known as
'Linux' that is available as open source directly over the Internet. Linux
is also available through various vendors who provide service and support
for the Linux operating system. Among these vendors are Red Hat, Inc., of
Research Triangle Park, N.C., the assignee of the present
invention.
(This news was originally reported (in Italian) on FreeGo). After letting people worry over the holiday weekend, Red Hat issued a statement of position on software patents. According to that statement, Red Hat's intent is defensive:
Red Hat has consistently taken the position that software patents
generally impede innovation in software development and that
software patents are inconsistent with open source/free
software.... At the same time, we are forced to live in the world
as it is, and that world currently permits software patents. A
relatively small number of very large companies have amassed large
numbers of software patents. We believe such massive software
patent portfolios are ripe for misuse because of the questionable
nature of many software patents generally and because of the high
cost of patent litigation. One defense against such misuse is to
develop a corresponding portfolio of software patents for defensive
purposes. Many software companies, both open source and
proprietary, pursue this strategy.
Red Hat, too, has decided to pursue that strategy; it has joined the software patent arms race by arming itself. What do these patents mean for free software? According to Red Hat's position, not much; the statement includes a promise to not enforce any patent claims against software using an "approved" open source license. So the free software community can relax; Red Hat is simply trying to protect itself from patent suits and will not be exploiting the dark side of software patents. Not so fast. The situation, unfortunately, is not quite that simple. There are a couple of problems with Red Hat's position that should be kept in mind. The first of these problems is that a promise on Red Hat's web site only means so much. It is not an enforceable contract that anybody can count on; Red Hat can change its position at any time. A court may take the published promise into account in a future case, but that promise may not keep such a case from happening in the first place. Red Hat, under its current management, seems unlikely to change its approach to patents - the posted promise is undoubtedly sincere. But corporate management and ownership can change quickly - and, with them, posted patent policies. More disturbing in the short term, however, is Red Hat's list of "approved" licenses. It includes the GPL, the IBM Public License, the Common Public License, the Q Public License, and "any open source license granted by Red Hat." A whole class of licenses, including the LGPL and, crucially, the BSD license, has been excluded from Red Hat's patent promise. In other words, the various versions of BSD Unix are not welcome to use Red Hat's patented technology. In fact, they can be sued for infringement if they do use that technology. The license wars, it seems, are still being waged, and Red Hat has just launched a new offensive. This is a move which will encourage division in the free software community, to say the least. The cynical among us could even see this policy as a strike by Red Hat against a whole class of competing free operating systems. That is almost certainly not the case: Red Hat is just trying to ensure that its patent weapons can actually be used. As the company told us:
We elected to specifically exclude licenses that don't expressly
prohibit open source code from being incorporated into proprietary
code. Absent that stance, the patents would be of little benefit.
It's not worth it. Red Hat ships a great deal of software under licenses which, it seems, are now too free: consider the X window system or OpenSSH, for starters. There has been a great deal of exchange of ideas between Linux and *BSD; the FreeBSD VM subsystem, for example, has long been seen as an inspiration by at least some Linux kernel hackers. We have all benefitted from the OpenBSD security auditing work. Red Hat, in the name of patent defense, is cutting off the flow of ideas in one direction. That is not how free software is supposed to work. Red Hat should find a way to deal with software patents that does not alienate a large and valuable part of the free software community. As a starting point, why not contribute these new patents (and the various gcc patents said to have been originally obtained by Cygnus) to a free software "patent pool"? The patents would be licensed for any use as long as the licensee does not sue any company alleging patent infringement by any free software used or distributed by that company. If it is absolutely necessary to dirty one's hands with software patents, this approach seems more constructive and beneficial to the community.
ADEOS - avoiding real-time Linux patents The current systems for performing hard real-time tasks with Linux (RTLinux and RTAI) take the same approach: use a real-time kernel at the lowest level of the system, and run the general purpose kernel (i.e. Linux) as the lowest-priority task. This technique has been patented by Victor Yodaiken, and the patent has been licensed to the community under terms similar to those used by Red Hat: as long as your work is licensed under the GPL, you can use the patented technology without paying royalties.This patent and its license have been the subject of endless controversy in the free software community. In particular, developers and users of RTAI have always felt a little nervous, especially when the RTAI core was licensed under the LGPL. The recent relicensing of the RTAI core was undertaken to be sure of compliance with the patent license, but not everybody has been satisfied. In particular, people who wish to run or distribute proprietary systems using RTAI have been unsure of their status. An obvious solution, one might think, would be to not use the patented technology; until recently, however, alternatives have been somewhat scarce. That situation may have changed, however, as the result of the announcement of the upcoming first release of ADEOS. ADEOS is, essentially, a small "nanokernel" which takes charge of low-level hardware resources (interrupts in particular). Any number of higher level operating systems can run in parallel on top of ADEOS; they run independently and know little of each other. ADEOS implements an abstraction called an "interrupt pipeline," which is essentially an ordered list of systems which are interested in a particular interrupt. Real-time systems put themselves at the head of the list, and are thus able to respond quickly to interrupts. General purpose systems can handle any interrupts which the real-time systems allow to pass down the pipeline. The idea of running multiple operating systems over a small, low-level kernel is not particularly new; IBM has been doing it for decades. It is interesting, however, in that the ADEOS developers claim that it is suffiently different from the RTLinux approach that it is not covered by the patent. The reality of the situation, however, may not be determined until a fair number of lawyers have been involved. The RTAI project plans to move over to ADEOS and thus, with luck, free itself of patent worries. Whether RTAI will be able to rid itself of the persistent claims that it is a derivative of RTLinux could be another story. RTLinux supporters will point out strong similarities between a number of source files in the two projects. If RTAI really used RTLinux code at the beginning, and released that code under a different license (even if that license was the LGPL), the project has, in theory, lost its rights to use that code. Nobody has seriously pursued a GPL infringement claim against RTAI, but, as long as the allegations persist, such an action is a possibility. Meanwhile, ADEOS embodies a different approach to dealing with software patents: find a way to work around them. From the press release:
Often a piece of Free Software, into which many people have
invested years of work, can be turned into non-free software by a
patent for one simple but essential calculation rule. Our example
shows that the developers need not always give up. Sometimes, by
trying very hard, an alternative calculation rule that does the
work and is not completely useless can be found. Developers should
not shy [from] the effort that this takes, because even if the patent
owner offers a license on friendly terms, usually the project will
be restricted in some way or other and the intentions of the
developers to create real Free Software will be betrayed.
This approach has been taken with other patents: using JPEG and PNG files to get around the GIF patent, and Ogg Vorbis as an alternative to MP3, for example. As software patents proliferate in the U.S., however (and possibly spread to Europe), it will get always harder to dodge them all. And tiresome as well. Software patents remain a threat to free software. (See also: a more detailed, technical description of how ADEOS works.)
UnitedLinux makes its launch After a suitable period of pre-launch hinting, the UnitedLinux initiative sent out a press release announcing its existence. A press release is about all there is, at the moment; the realization of the goals behind United Linux will take a little longer.UnitedLinux is a joint venture between Caldera, Conectiva, SuSE and Turbolinux. Essentially, the four will be combining much of their Linux distribution development operation. The advantages of this combination are fairly clear: much duplicated work can be eliminated, and the companies will have at their disposal a single base distribution which is standards compliant and uniform. The companies' four distributions have all lacked sufficient market share to inspire software vendors to target them. One, larger distribution, it is hoped, will be more successful at attracting the independent software vendors of the world. An alpha release of UnitedLinux, apparently based most heavily on SuSE's distribution, is due in the near future, with the general release happening in the fourth quarter of this year. Each distributor will then add its own special offerings and sell the result under its own brand. Interestingly, the UnitedLinux release plans page mentions KDE 3.0, but says nothing about GNOME. Several "installation languages" will be supported. The biggest controversy over UnitedLinux would appear to be whether it will be available as a free download. The initial statements from the group have been mixed. We will have to wait and see on that one. A more worthwhile question might be: will UnitedLinux expose its development version the way Mandrake, Debian, and Red Hat (sort of) do? Inviting outsiders into the development process is a far more convincing sign of openness than distributing free binaries. The other open question, of course, is: what other companies might join? An invitation has been extended to Red Hat, but nobody really expects that company to want to be a part of UnitedLinux. MandrakeSoft is a more interesting possibility; it is by far the largest other distributor which is not currently a part of the group. Thus far, MandrakeSoft has been awfully quiet about UnitedLinux. If UnitedLinux lives up to its promise, it could become the platform upon which a new generation of distributions can grow. Doing UnitedLinux right, however, will require keeping both the free software community and the commercial world happy. This goal should be achievable; we wish this group luck.
The new LWN.net site Back in August, 1998, LWN made a major site change: we went from the "everything on one big page" format to the multi-page format that is still used for the weekly edition. We got over 100 complaints about that change - people liked things the old way. So we restored the "one big page" as an option, and it is still used by a (declining) number of LWN readers.As you can see, LWN has changed format again; see our introductory posting for a description of what has changed. We'll say here, however, that what has not changed is LWN's content. The presentation is different, and a number of new capabilities have been added, but our writing remains as always. By the standards of 1998, the reaction to this change has been relatively muted. Some people like the new site, others do not, but there has been no avalanche of complaints. Which is fine with us. We are certainly interested in hearing from our readers (at lwn@lwn.net) about ways we could improve the new site; we do request, however, that commenters be specific about what they do or do not like. We try to respond to specific complaints, but there's not much that we can do with a message that just says "I hate the new site." There are certainly some rough edges on the new site. Bear with us, and we'll do our best to straighten them out. Meanwhile, please check out the new features, and, we hope, enjoy the new LWN experience. (Note that people who want to see something that resembles the old site can bookmark lwn.net/current, which always gives the current weekly edition, or lwn.net/current/bigpage, which is the "one big page" format).
Page editor: Jonathan Corbet Security Welcome to the new LWN.net Security Page Our first site code upgrade in nearly four years introduces an integrated security alert and vulnerability database. Our archive of security alerts dating back to July, 2001 now lives in a PostgreSQL relational database. Vulnerabilities and alerts are actually linked to each other. Recent alerts and vulnerabilities use Common Vulnerabilities and Exposures (CVE) numbers to uniquely identify each vulnerability.Today you can browse alerts and vulnerabilities using the links at the top of each page. When viewing an alert, you can view the corresponding vulnerability description with a mouse click. In the future expect, and please continue to suggest, ways for us to better provide you with the security information you seek.
US TurboLinux Security Severely Out of Date (iDEFENSE Labs) iDEFENSE Labs has issued a security advisory for the US TurboLinux distribution.
The collective security weakness of the outstanding issues listed
below is staggering. The following is a list of the most serious
problems for which most other Linux vendors have provided updates on
their US sites. It represents the outstanding security problems
associated with the limited TurboLinux distributions and updates that
have been available on the US sites only.
LWN has pointed out in the past that Turbolinux has not been serious about security updates. With luck this advisory - or, perhaps, the UnitedLinux effort - will help get this distributor back on track.
Security news Unique Preventative IDS for Linux Scott Wimer, Chief Technology Officer of Cylant, dicusses preventive security in this paper.
The recent vulnerabilities with OpenSSH software demonstrate that even intensive auditing cannot necessarily root out all the defects from software. As software systems become larger and more complex, intensive auditing becomes more expensive and more difficult. Software audits
simply cannot be relied upon to find all of the security vulnerabilities in any given system.
Biometric Access Protection Devices and their Programs Put to the Test (c't) C't has published a study of eleven biometric access controls intended to prevent unauthorized access. "In our attempts at outfoxing the protective programs and devices we have concentrated on the first method: direct attempts at deceiving the systems with the aid of obvious procedures (such as the reactivation of latent images) and obvious feature forgeries (photographs, videos, silicon fingerprints)."Also see Bruce Schneier's previously published CRYPTO-GRAM newsletter for May for a look at a technique for fooling fingerprint scanners with fake fingers made of gelatin.
Security reports Download Sites Hacked, Source Code Backdoored (Security Focus) Brian McWilliams reports on the recent contamination of Fragroute with a backdoor. "According to program developer Dug Song, the source code to the Dsniff, Fragroute, and Fragrouter security tools was contaminated on May 17th after an attacker gained unauthorized access to his site, Monkey.org."Note: Copies of Dsniff, Fragroute or Fragrouter downloaded from Monkey.org between May 17th and May 24th are contaminated and require replacement. For more details, see Dug Song's post to bugtraq about the incident.
OpenSSH 3.2.3 released Following on the heels of the last release, OpenSSH version 3.2.3 has been announced. This version fixes a few bugs that showed up in version 3.2.2.
Ethereal 0.9.4 released Ethereal 0.9.4 was released on May 19, 2002 fixing four potential security issues in Ethereal 0.9.3:
No known exploits exist "in the wild" at the present time for any of these issues.
Information Disclosure Vulnerability in IDS 0.8x IDS is a CGI script that generates a multi-gallery photo album for a website on the fly. IDS 0.8x is reported to have a directory disclosure vulnerability.
CGIscript.net - csPassword.cgi has multiple vulnerabilities Steve Gustin has reported multiple vulnerabilities in the csPassword.cgi script from CGIscript.net "Make sure you only allow trusted users to use the csPassword application and make sure your web server in configured to deny requests for .ht* and *.tmp files."
Caldera Security Advisory - Volution Manager Volution Manager stores the unencrypted Directory Administrator's password in the /etc/ldap/slapd.conf file. This vulnerability will be corrected in the next release of Volution Manager.
(Proprietary product) Informix SE-7.25 Local Vulnerability A buffer overflow vulnerability was reported in Informix SE-7.25 if INFORMIXDIR enviroment variable is defined with a size greater than 2023 bytes.
New vulnerabilities Denial of service vulnerability in version 9 of BIND
Ghostscript arbitrary command execution vulnerability
Mailman 2.0.11 fixes two cross-site scripting vulnerabilities
String format bug in pam_ldap logging
Malformed NFS packet buffer overflow vulnerability in tcpdump
Uucp authentication agent, in.uucdp, bad string termination
xchat IC server based dns query vulnerability
Updated vulnerabilities Ethereal packet handling vulnerabilities
Remotely-exploitable buffer overflow vulnerability in fetchmail
UW imapd remotely exploitable buffer overflow
OpenSSH 3.2.2 fixes multiple vulnerabilities
UTF8 interaction bug in the perl-Digest-MD5 module
Heap corruption vulnerability in at
DHCP remotely exploitable format string vulnerability
GNU fileutils race condition
Buffer overflow problem in glibc
Buffer overflow in groff
Problem loading untrusted images in imlib
Cross-site scripting vulnerability in Horde/IMP 2.2.7 and 3.0
Mozilla XMLHttpRequest file disclosure vulnerability
Remotely exploitable vulnerability in pine
Sharutils potential privilege escalation using uudecode
Multiple vulnerabilities in tcpdump
Multiple vendor telnetd vulnerability
Multiple vulnerabilities in SNMP implementations
webalizer: reverse DNS buffer overflow vulnerability
Webmin/Usermin vulnerabilities
Problems with libgtop_daemon
zlib corrupts malloc data structures via double free
Resources CERT Summary CS-2002-02 The CERT Coordination Center (CERT/CC) issued their CERT quaterly summary "to draw attention to the types of attacks reported to our incident response team, as well as other noteworthy incident and vulnerability information."
Announcing Fenris 0.06 Fenris 0.06 has been released by Michal Zalewski. "This release brings you much improved debugging capabilities, from a console-based debugging GUI [...], to core functionality fixes, anti-debugger techniques detection, better performance, or an updated write-up on debugging burneye-protected code."
Linux Security Week and Advisory Watch The June 3 Linux Security Week from LinuxSecurity.com is available, as are the Linux Advisory Watch Newsletters from May 24 and May 31.
Book Review: SSH, The Secure Shell - The Definitive Guide Danny Yee has reviewed SSH, The Secure Shell - The Definitive Guide published by O'Reilly & Associates in 2001.
Events Upcoming Security Events
For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to lwn@lwn.net.
Page editor: Dennis Tenney
Kernel development Kernel release status The current development kernel is 2.5.20, which was released by Linus on June 2. Big changes this time include a large ACPI merge, a bunch more buffer/VM work, a PowerPC64 merge, the usual set of IDE patches, various merges from the -dj series, some device model work, and numerous other fixes and updates. The long format changelog is also available.Other releases from Linus since the last LWN Kernel Page include:
The current prepatch from Dave Jones is 2.5.20-dj3. The most significant feature of this patch, perhaps, is the merging of some small pieces of the kbuild 2.5 code. The latest 2.5 status summary from Guillaume Boissiere came out on June 5. The current stable kernel release is 2.4.18. Marcelo's plan had been to create a 2.4.19 release candidate, but some problems turned up. So he released 2.4.19-pre10 instead. A very long list of fixes got into this release. With luck, the next prepatch from Marcelo will be the first 2.4.19 release candidate. Alan Cox has released 2.4.19-pre10-ac2; arguably the most interesting change in this prepatch is the inclusion of the "speakup" console module for blind users.
A new way of block queue plugging Jens Axboe has posted a patch which, once again, changes some of the main assumptions underlying the block I/O subsystem. It is worth a look at what is going on.A longstanding feature of the block layer has been "queue plugging." If the request queue for a particular block device has been plugged, that device's driver will not be invoked to execute the operations in the queue. The main reason for plugging has been to allow the block layer to build up a backlog of requests, so that adjacent operations can be merged. By sometimes waiting a little longer to start an operation, the block layer can often achieve better performance overall. With the 2.5 block layer, however, there is less need for this sort of plugging. The code works harder at not splitting large requests in the first place, so it is not necessary to merge them again. The new plugging code actually serves a different purpose: it is a mechanism by which a block driver can indicate that it is busy and can not handle any more requests at the moment. As Jens points out in his patch, the block code is starting to look a little (a little!) bit more like the networking subsystem. Like network interfaces, block devices can have multiple requests outstanding. When the device has been given all the simultaneous requests that it can handle, there is no point in further troubling the driver until some of those requests complete. Thus the new plugging code: block devices, too, can ask to be allowed to work in peace for a while. There's a couple of other, incidental changes in this patch. One is that the venerable tq_disk task queue has been removed. Slowly, the set of standard task queues is shrinking. A block driver's request ("strategy") function is also now called out of a tasklet. The block layer that shows up in 2.6 will be vastly different from what has been seen in previous stable kernels.
Splitting the kernel stack The Linux kernel has, for years, run with an 8KB (two page) stack in each process's address space (at least, on i386 systems). That stack holds the "task structure" (the kernel's information about the process) and provides space for automatic variables and call frames when the system is running in kernel mode. The 8KB stack works, of course, but it is not optimal. The biggest problem, perhaps, is the need to find two adjacent pages for a new stack every time a new process is created. On a busy system memory can get badly fragmented, and allocating two pages together can be a challenge.So Ben LaHaise has posted a patch which splits the kernel stack into two 4KB stacks. One of them holds the task structure and is used by normal kernel code (i.e. handling system calls). The other stack is set aside and is used only when the kernel is handling interrupts. A separate interrupt stack is not a particularly new idea - many operating systems have had interrupt stacks for decades. There are numerous advantages to doing things this way. Only one interrupt stack (per CPU) is needed, so one page of memory per process is freed up. The interrupt stack is also more likely to stay in the processor cache, improving performance. Interrupt handlers need not worry about other kernel code having consumed most of the stack when they get invoked. And, of course, it is no longer necessary to perform a two-page allocation to set up the regular kernel stack. The biggest downside, perhaps, is that non-interrupt kernel code must now fit into much less stack space. Some kernel code is not particularly careful about the size of its automatic variables, and risks overflowing the new, smaller stack. As a way of tracking down such code, Ben has also posted a stack checker (followed by a brown paper bag fix) which monitors stack usage and raises the alarm when available space on the stack gets too low. The two patches are probably best used together.
The continuing saga of kbuild 2.5. The discussion over whether to merge kbuild 2.5 has been covered in this space before. It is one of those conversations that persists, however. A few things have happened over the last few weeks.Keith Owens, the author of kbuild 2.5, has posted a new set of timing comparisons meant to show the advantages of the new code. The full build process Keith performed took a bit less than 14 minutes with kbuild 2.5, and a little over 20 minutes with the existing kbuild. He also points out that the result is sometimes incorrect with the existing code. Daniel Phillips also tried it out and obtained similar results. For good measure, Daniel took a look at the code itself: "There is no Python anywhere to be seen in kbuild 2.5, for those who worry about that. It is coded in C, about 10,000 lines it seems. It has a simple built in database which I suppose accounts for some of that. For what it does, it seems quite reasonable." In general, most (but not all) developers who express an opinion on the matter seem to feel that kbuild 2.5 is worthwhile and should be merged. So it has surprised a number of people to see numerous patches to the existing kbuild system, written by Kai Germaschewski, being merged by Linus. These patches do worthwhile things, but they are not kbuild 2.5. Why bother, one might ask, if the whole thing is going to be replaced? The answer seems to be that Linus, for now, wants Kai to be the kbuild maintainer. Kai is willing to do things in small pieces, which has always been Linus's preferred method; Keith has, so far, refused to break his kbuild work up in this way. Also, says Linus:
Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends
to be a bit down on some of it. Which is a plus in my book: it
means that whatever Kai tries to push my way I'll feel just that
much more comfortable with as having had critical review.
Meanwhile, a couple of different developers (Sam Ravnborg and "Lightweight patch manager") have started submitting broken up versions of kbuild 2.5. Kai has stated that he will look them over and integrate those which make sense. Some of these patches also found their way into 2.5.20-dj3. It seems like at least a partial victory for the new kbuild. So one has to wonder why, after all this, Keith felt the need to post his call for an email campaign entitled "If you want kbuild 2.5, tell Linus." It's a full-scale polemic that takes one back to the old devfs wars. It is also, seemingly, counterproductive. One would think that would be better to work with the people who are trying to make kbuild acceptible to Linus than to call for a pressure campaign.
The value of negative dentries A "directory entry" (dentry) is an internal data structure used to hold the results of looking up a file in the filesystem. The Linux "dentry cache" keeps a number of recently used dentries around; they tend to be useful, since files are often accessed more than once over a short period of time. Finding a file in the dentry cache can save a lot of time by avoiding a full filesystem lookup.The kernel also hangs on to "negative dentries," which indicate that the given file does not exist. Andrea Arcangeli recently noted that these negative dentries can take up quite a bit of memory, and wondered what possible use they could be. His message included a patch to force negative dentries out of memory quickly. It turns out, though, that "this file does not exist" can be useful information. A quick strace run on a GNOME application, for example, turns up dozens of lookups on nonexistent files as the application gropes around looking for the unbelievable number of libraries it needs. Similarly, apache is continually looking for .htaccess files, shells look for executables, etc. It is more than worthwhile to be able to determine that a file doesn't exist without an expensive filesystem call - especially for file names that are often looked up. So negative dentries will stay. There is one optimization that can be made, though. In Andrea's case, the negative dentries were created by deleting a large directory full of files. When a file is deleted, it is relatively unlikely that it will be looked up again soon, and keeping a negative dentry around is less useful. In this case, perhaps, it is better to just forget about the file name altogether.
The return of /dev/port A few weeks ago, LWN reported on the removal of support for /dev/port from the 2.5 kernel. Since then, a few users have reported real uses for /dev/port and a desire that it stay in the kernel. Martin Dalecki, who create the patch removing /dev/port, suggested that users who really need it can patch it back in themselves. Linus disagreed, saying:
So when simplifying, it's not just important to say "we could do
without this". You have to also say "and nobody can reasonably
expect to need it".
Which doesn't seem to be the case with /dev/ports. So it stays. That is, of course, the definitive end to the discussion.
Resources A few other worthwhile notes:
Patches and updates Kernel trees
Core kernel code
Development tools
Device drivers
Documentation
Filesystems and block I/O
Janitorial
Kernel building
Networking
Architecture-specific
Security-related
Miscellaneous
Page editor: Jonathan Corbet
Distributions News and Editorials Announcement: the AGNULA project The AGNULA project aims to develop two reference distributions for the GNU/Linux operating system completely based on Free Software (i.e. under a FSF approved Free Software license) and dedicated to audio and multimedia. One distribution will be Debian-based (DeMuDi) and the other will be Red Hat-based (ReHMuDi).
Scyld Beowolf In the May 23rd Distributions page the Scyld Beowulf Cluster Operating System was incorrectly identified as hardware specific. In fact the Scyld distribution supports x86, Alpha, and other platforms.
Distribution News Debian GNU/Linux The Debian Project has sent out a release describing what is claimed to be a new intercontinental Internet performance record: the first Debian Woody CD was transferred from Fairbanks, Alaska to Amsterdam in 13 seconds. The systems on both ends were running Debian, of course.The Debian Weekly News for May 23 is out, with coverage of MPlayer, Nessus, the fair use status of the fortunes file, and more. Here's the Debian Weekly News for May 29. It looks at the new Debian Flyers, the abortive attempt at packaging WineX, apt preferences, and more. In this announcement Josip Rodin discusses woody release status. "To reiterate the main point from the April 30th mail by Anthony Towns, the release of woody is being held back because there is no systematic way to build packages in security advisories on all architectures included in woody."
Mandrake Linux Issue #43 of the Mandrake Linux Community Newsletter is out. "This Week's Summary: StarOffice 6.0 Officially Released; Spotlight on MandrakeExpert; MandrakeClub Activities; Website of the Week (plf.zarb.org); Online Survey; Ximian GNOME for Mandrake 8.2; Mandrake in the News; Website Updates; Software Updates; Headlines from MandrakeForum."The Mandrake Linux Community Newsletter for June 1 (issue #44) is out. It covers the MandrakeSoft.com redesign, the Business Case of the week, recent security alerts, and more.
Red Hat Linux Red Hat has two bug fixes out for this week. There are new SANE packages for RH 7.3 which fix a problem observed when upgrading SANE. There are also new XFree86 packages are available which fix various bugs reported since the last erratum update. These are available for RH 7.1 - alpha, i386, ia64 and RH 7.2 - i386, ia64.
Slackware Linux On May 25, 2002 Slackware 8.1-rc1 was announced. That was followed by Slackware 8.1-rc2, announced on June 1, 2002. Since then much progress has been made on cleaning up the remaining bugs. As always the Slackware-current change log contains the details.
Yellow Dog Linux Terra Soft Solutions, Inc., publishers of Yellow Dog Linux, announced the Japanese edition of Yellow Dog Linux 2.2, which will be showcased by Amulet at LinuxWorld Tokyo.Yellow Dog L | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||