Linux in the news
All in one big page
See also: last week's Back page page.
When not to be good!. Need one final chuckle for the Christmas season? Check out this joke from Verlag Heinz Heise GmbH. Here is a translation in advance that you will need:
Have you all been good?Thanks to Fred Mobach for sending this in.
Section Editor: Forrest Cook
January 4, 2001
Two years ago (January 7, 1999 LWN): The 2.2 Linux kernel pre-release series began; the stable release was pushing towards version 2.0.37. The Linux Kernel Archive mirror system was started with two mirror sites. There are now hundreds of Linux kernel archive mirror sites all around the world.
Numerous people predicted that Open Source software would be big in 1999; these predictions turned out to be accurate.
Info World speculated that "Linux will become just another Unix. The Internet lost its charm when big business discovered it. The same will happen with Linux. Linux will wipe out SCO and Unixware and gain ground against NT, but will lose its soul in the process". Well, they got the SCO part right, but Linux continues to have almost as much soul as James Brown.
Red Hat was getting lots of attention with its corporate expansion and potential of being a threat to the Microsoft empire.
The first issue of the Debian Weekly News came on-line; that project is still going strong.
Aladdin Ghostscript was released under a GPL license.
One year ago (January 6, 2000 LWN): Linux survived the Y2K bug with a few minor bugs here and there; so did the rest of the world. Several Linux distribution vendors came out with some additional Y2K bug fixes.
The cracking of the DVD encryption format was big news; Eric Raymond wrote a letter to LWN entitled DVDCA and the Big Lie.
The stable kernel was version 2.2.14, which was a bit long in coming. The development kernel was version 2.3.35. With Y2K concerns out of the way, the Unix Year 2038 bugs were beginning to get a look.
The first of many SEUL/edu Linux in Education reports came out; this group continues to produce good information concerning Linux in the schools.
Numerous commercial entities announced the open-sourcing of projects; among them were InterBase from Inprise, the CompactPCI networking package from MontaVista, and several device drivers.
VA Linux introduced its now-highly-successful SourceForge site which provided a home to many open-source projects. Apple announced the roll-out of its Mac OS X, a Free BSD based platform.
Letters to the editor should be sent to firstname.lastname@example.org. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
Date: Thu, 28 Dec 2000 23:06:22 -0700 From: Eric B <email@example.com> To: firstname.lastname@example.org Subject: MSNBC Thinks Microsoft is the underdog! In the article: http://www.msnbc.com/news/508942.asp on MSNBC's website the author states the following in regards to his top tech predictions for 2001: "Microsoft comeback: The Redmond giant could become the thought leader on the Web as it was for PCs. Microsoft will finally have most of its .Net architecture in place next spring. Based on what I've seen, it will have all the parts in place for a viable platform for the next-generation Web. It may take 12 to 18 months, but don't be surprised to see Microsoft take the leadership role away from Sun, Oracle and the Linux crowd. Click for more." Apparently we already won and nobody told us. I guess now we are fighting to stay on top! Eric Bueschel -- Windows: A 32 bit shell for a 16 bit operating system, originally written for an 8 bit processor on a 4 bit bus by a 2 bit company that can't stand 1 bit of competition!
From: Anton Ertl <email@example.com> Subject: Yet more on Elevator algorithms and write ordering To: firstname.lastname@example.org Date: Fri, 29 Dec 2000 12:54:25 +0100 (MET) Matt Dillon writes: >I'm afraid there is considerable confusion over write ordering in a >filesystem. The confusion stems from an assumption that dependant >operations are queued to the disk device all together. No, there is no such assumption involved. >This assumption >is not true of FFS with softupdates. FFS with softupdates turned on will >queue all *NON* dependant buffers to disk all at once and doesn't care >in the least whether the kernel, the disk device, or the physical disk >itself reorders the writes. Dependant buffers are not queued until >non-dependant buffers have completed their I/O's. I would say "buffers they depend on" instead of "non-dependent buffers", but otherwise, yes, that's how file systems currently try to enforce write ordering constraints. The problem is: how do they know that the I/O for a buffer is completed? A disk with write-caching enabled happily reports that it has completed the I/O for a block when it has the block in its RAM cache. The disk driver and buffer cache then report I/O completion to the file system, which submits the next batch of blocks. These blocks may arrive at the disk while much of the earlier batch is still in the cache, and then the reordering optimization of the disk may write the blocks in an order that results in a file system inconsitency. You can see this effect with http://www.complang.tuwien.ac.at/anton/hdtest/. With write caching disabled on the disk, the blocks are written in-order (i.e., the Linux buffer cache does not reorder these accesses). With write caching enabled on the disk, the two disks I tested delayed writing one block for as long as I tested (several seconds). I wrote this test in order to check some assumptions necessary for a log-structured file system I was involved with. I was not pleased with the result. - anton
Date: Fri, 29 Dec 2000 10:02:45 -0800 (PST) From: Matt Dillon <email@example.com> To: Anton Ertl <firstname.lastname@example.org> Subject: Re: Yet more on Elevator algorithms and write ordering :I would say "buffers they depend on" instead of "non-dependent :buffers", but otherwise, yes, that's how file systems currently try to :enforce write ordering constraints. : :The problem is: how do they know that the I/O for a buffer is :completed? A disk with write-caching enabled happily reports that it :has completed the I/O for a block when it has the block in its RAM :cache. The disk driver and buffer cache then report I/O completion to :the file system, which submits the next batch of blocks. : :These blocks may arrive at the disk while much of the earlier batch is :still in the cache, and then the reordering optimization of the disk :may write the blocks in an order that results in a file system :inconsitency. : :You can see this effect with :http://www.complang.tuwien.ac.at/anton/hdtest/. With write caching :disabled on the disk, the blocks are written in-order (i.e., the Linux :buffer cache does not reorder these accesses). With write caching :enabled on the disk, the two disks I tested delayed writing one block :for as long as I tested (several seconds). I wrote this test in order :to check some assumptions necessary for a log-structured file system I :was involved with. I was not pleased with the result. : :- anton This will depend heavily on whether you are running SCSI disks or IDE disks. SCSI disks have an explicit bit that can be set to enable write acknowledgement prior to completion of the write. I don't know about Linux, but FreeBSD turns that bit off. The bit is usually off by default. SCSI disks also have an explicit ordering tag. However, the ordering tag has been depreciated in the latest SCSI working standard. Many SCSI disks ignore this tag anyway (which is probably why it is being depreciated). IDE disks have historically shipped with this bit turned on... because IDE ops are serialized (tagged IDE ops are possible, but not really reliable). In other words, IDE disks tend to lie about write completion. We found this out years ago when Kirk McKusick ran a bunch of filesystem tests with IDE and was tring to figure out why IDE drives seemed to beat out SCSI drives for certain tests. The manufacturers are more interested in getting good benchmark results from the rotten IDE protocol then in filesystem recovery. I'm not sure whether it is possible to turn the bit off for an IDE drive but since IDE is essentially a munged SCSI protocol over a substandard physical layer, it should be possible. This is one reason why nobody in their right mind uses IDE drives on critical production systems, not unless the drives are in a RAID cabinet with backup power and non-volatile ram. -Matt