Linux in the news
All in one big page
See also: last week's Letters page.
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.
January 25, 2001
Date: Mon, 22 Jan 2001 14:16:20 -0700 From: Andrew Gilmore <email@example.com> To: firstname.lastname@example.org Subject: Dell Linux Laptops Your main page from last week mentions Dell's laptop page. (http://www.dell.com/us/en/bsd/topics/segtopic_linux_001_linux_center.htm). This page is indeed about Dell Linux laptops, but all of the links to anywhere on that page fail. I know that the Inspiron 7500 mentioned on that page is no longer being built, I'm not sure about the Latitude CPx. I'm not sure what to make of the linux laptop thing either. :( Andrew -- Hydraulic Engineer, Upper Colorado Region US Bureau of Reclamation 125 S State St, Room 6107, UC-433 Salt Lake City, UT 84138-1147 PH: 801-524-3879 Fax: 801-524-3858
Date: Fri, 19 Jan 2001 07:42:39 +0800 From: Nick Urbanik <email@example.com> To: firstname.lastname@example.org Subject: Pronunciation of Linux I call Linux so it rhymes with "Linus" in the Peanuts comic strip, and enjoy defending my right to say it that way. Do I need to put on an Seattle accent when I refer to Bill Gates?
Date: Thu, 18 Jan 2001 12:06:33 -0800 From: Gene Mosher <email@example.com> To: firstname.lastname@example.org Subject: VA Linux Hey, VA Linux is prohibited by Intel, which owns ten percent of it, from selling AMD systems. So, while everybody else is doing well, VA Linux just keeps bleeding to death. How can it fulfill its obligation to its shareholders by refusing to sell AMD systems? Obviously it can't. If you look at the Nasdaq, you'll see that Techs are having a VERY good month, but not VA Linux, Red Hat, Caldera or Neoware. The light at the end of this tunnel is a train coming right at them. Even the employees are dumping all their shares while they still have any value at all. $7 a share may be a lot higher than what the share price will be later this year. Just because the share price is two to three cents of what it was a year ago doesn't mean that it can't go a LOT lower. It could well fall to nine cents per share. Look at what happened to NCDI, for instance. Last summer people were bragging about how they were able to scoop up NCD shares for $9. Well, three weeks ago it fell to nine cents. Public companies which are losing money are not long for this world. Public companies which never have made money since their inception as private companies OUGHT to be sued by shareholders. It's the only recourse which stockholders have against a company whose officers took their money, which can't deliver shareholder value and who think that they can ignore their lawful obligations to do their best to do so. VA Linux and Red Hat have followed pied pipers like Eric Raymond right off the edge of the cliff, singlehandedly making it virtually impossible for any Linux organization to get the benefit of public financing, even if, unlike VA Linux and Red Hat, they have a VALID business model. Shame on them. C'mon, give us some good journalism about this, whydoncha? Gene Mosher
Date: Thu, 18 Jan 2001 15:45:47 -0500 From: Derek Glidden <email@example.com> To: firstname.lastname@example.org Subject: Linux, NFS and journaling filesystems [I apologize in advance for the length of this letter, but I think some of my recent, and past, experience might be of significant interest to other Linux users out there.] In your Jan 18th newsletter in the discussion on ReiserFS (huzzah for ReiserFS making it into the 2.4.1 patch!) you say, "bear in mind that NFS still can not serve files from a ReiserFS partition" and there is extensive discussion on ReiserFS/NFS compatibility on the ReiserFS FAQ section of the ReiserFS site at www.namesys.com. However, despite all these reports to the contrary, I've successfully run an NFS server with a 52GB exported volume utilizing ReiserFS on my home network for several months now with no problems. Initially the box was RedHat 6.x based with 2.2.16 kernel and ReiserFS patches, and has variously incarnated through several kernel revisions and a major distro change to its most recent state of Debian 2.2 with kernel 2.4 and ReiserFS patches. The main volume has been a 52GB "md"-driven RAID0 volume comprised of two 26GB IDE drives, formatted ReiserFS, and it has served its files up with knfsd straight off of whatever kernel/distro it happened to be running at the time with only ReiserFS, mingo's RAID and hedrick's IDE patches applied. I've never had any problems with the three or four client machines that may be accessing the box at any given time. (Yeah, I really have a home network with a huge fileserver and three or four client machines that might be using it at any given time. So I'm a big geek. :) ReiserFS has served me well in both testing environments and "real-world" situations; I can't think of any occasions where I've experienced any sort of problems with the ReiserFS volume and never any data loss. Remount times after any sort of failure (even having a UPS on the machine won't prevent someone from accidentally bumping the "reset" switch while it's doing something...) have been great (i.e. virtually nonexistent) compared to the hour-long fsck times I used to have even with smaller ext2 filesystems. With the recent release of the 2.4 kernel, however, I've started playing with alternate configurations. I've just this past week "retired" the old fileserver and, with a couple of new hard drives, have rebuilt the new primary fileserver using two 61GB IDE drives, integrated into a single 120GB volume with LVM (http://www.sistina.com) formatted using SGI's XFS filesystem (http://oss.sgi.com/projects/xfs/) and running the 2.4.0 kernel on Debian 2.2. Instructions for those attempting this at home: check out SGI's CVS version of the 2.4 kernel with the XFS mods already applied. Check out the most recent CVS of LVM from Sistina - the LVM patch that (kind of accidentally) went into 2.4 was not ready for real use and has a couple of real showstopper bugs. Follow the LVM instructions for patching against the 2.4 kernel using the checked out kernel source from SGI. Configure, compile and install. The toolchains for LVM and XFS should both be in your CVS checkout trees ready for compiling and using. If you're running Debian 2.2 and want to run Kernel 2.4, you'll have to get the latest modutils source from the unstable tree and build and install it. XFS is surprisingly well along its road to "release-quality" for a project that the vast majority of the public thinks of as "still under serious development." Mount and check times with XFS are significantly faster than ReiserFS (which is really saying something if you've ever been amazed at the zero-fsck mount times of ReiserFS) and I have definitely noticed an improvement in NFS speed, although I can't directly attribute this to either improvements in NFS code in the 2.4 kernel or moving away from ReiserFS as the base filesystem for the NFS volume. (Although I'd probably point a finger at ReiserFS for the slowdown as I did run the machine with 2.4/ReiserFS for a few days and didn't notice any significant difference in its behaviour during that time.) Over several days of "hardcore" testing, I've concluded that, for me personally, XFS is stable enough to form the base for my newly-built fileserver. It has been very reliable in my completely-and-utterly-scientific "rsync a big chunk of data onto the volume while doing an rm -rf against a copy of the mozilla source tree and running a perl script that writes, copies and deletes a bunch of temp files and then pull the plug" tests, mounting nearly instantly on restart and with the "xfs_check" tool reporting no problems with the filesystem afterwards. But why would I move away from a proven architecture to do something crazy like this? LVM gives me the ability to add new physical volumes to the logical volume on my fileserver without having to rebuild the volume, which is something I've sorely missed as that machine has been upgraded several times from its original 8GB filesystem and each time I've had to build a "backup" server to migrate the data to temporarily while I rebuild the new server. Both XFS and ReiserFS include tools for growing an existing filesystem to account for newly-available volume space and there are tools available for doing this to an ext2 filesystem as well so any of those filesystems will work with LVM without much hassle. I had no problems at all growing any of those three filesystems, with or without data already on them, to account for newly-added space on an LVM volume during my tests. The choice to go with XFS over ReiserFS was partially based on the "geek factor" of using XFS but also partially the fact that a larger set of useful userspace tools comes with XFS than with ReiserFS, not the least useful of which are the "xfsdump" and "xfsrestore" tools. (And let's not overlook the fact that XFS uses full 64-bit file offsets while ReiserFS "only" supports 60-bit file offsets... :) However, ReiserFS has been very very reliable for me and we have been deploying ReiserFS on machines at work for several months now without a single glitch. Other users interested in ReiserFS or XFS are encouraged to visit the respective websites and do as much research as they feel necessary. I feel that at this point in their development, either one would make an ideal base for a system that needs an extremely reliable filesystem with little-to-no downtime. With the important caveat: *** Both ReiserFS and XFS (and any journaling filesystem on Linux at the moment) will have problems dealing with software RAID5 volumes, but at least as of now, behave properly with mirroring, striping and concatenating RAID methods with either md or LVM drivers. This is likely to change in the future, and hardware RAID will not have any impact on either of them as hardware RAID will look like a single device to the Linux VFS layer, which is where the incompatibilities hide. The Namesys website, as you mentioned, has an incredible amount of information about ReiserFS, going well beyond its journaling capabilities. There is also an excellent article on ReiserFS by one of its primary programmers in the most recent Linux Journal magazine that not only points out some of the highlights of ReiserFS but also, very honestly, some of its shortcomings. The future of the 2,4 kernel series is looking bright indeed with projects like ReiserFS, XFS and LVM coming over the horizon. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- With Microsoft products, failure is not Derek Glidden an option - it's a standard component. http://3dlinux.org/ Choose your life. Choose your http://www.tbcpc.org/ future. Choose Linux. http://www.illusionary.com/