Slashdot Mirror

... at linux gazette from this month (issue #95) about using an oscilloscope to view signas generated by some programs and how the multitasking operating system (linux in that case) behave when it has to process several things at the same time..

Ahh, good: there's a Linux print-to-PDF solution after all.

Of course, OO's button is certainly easier to use, but I think adding it either to the "save as..." dialog or the "print to..." list (or both) is more intuitive.

dressing up coworkers in their own suit and ties, and providing your own tech EQ will give it a better, less carbon-copy look.

• ultralinux.org - a site for the Sparc kernel port, including FAQs, supported distros etc
• Installing Linux on an Ultra 5 and setting up a dual boot with Solaris
• Configuring Linux audio on Sparc
• JDK for Linux on Sparc

Here is a link that says not only did this go to court but that SCO may be found in contempt of court for not complying.

...and the article Custom Debian CD from Knoppix tells you how.

suicide note

Actually it is really easy to have the ms windows boot loader boot Linux. Well I think it only works for NT/2k/xp. All you do is install grub or lilo on the partition that Linux is on and then copy the first 512 bytes of that partition to a floppy. Boot into winders and copy that file to your C:\ drive and modify C:\boot.ini
Booting Linux from the NT Boot Menu

looks like you're committing suicide!

No, but you can create a printer on any Linux or Windows workstation that prints PS to a remote computer running GS that can convert the file to PDF for you (or any output that GS supports) and place it in thier home directory, email it back to them, place it on a web server for pickup etc... Instant document conversion and archiving of "printed" documents for one person or an entire office. If this printer is marked as the default in Windows, you can highlight a bunch of files, right click and select print. A poor mans batch conversion but it works well.

I use this at home and in an office environment at work. I also added jpeg and tiff "printers" in Samba also (gs -sDEVICE=tiffg4 -r100x100 for tiff, gs -sDEVICE=jpeg -r300x300 for jpeg)

See here and here if your interested, you can expand and add to this to suit your needs. I've found some good uses of this with Google.

Read this.
It's not precisely about software patents, but can easily be applied to them: patenting software is like privatising the road network.

Oh, there is, in OpenOffice calc. Check this article for easter eggs in OSS.

It's really amazing how much more advanced the tools are under Windows, especially when it comes to dvd authoring. I would think with all the great dvd players that more people would be working on authoring.

My personal favourite is the Linux Gazette, but there are others (too lazy to reahch for bookmarks now ;). Don't overlook past issues even if they are pretty old, because some of the tricks discussed haven't changed much over the years (like motd, rdev, tcsh etc.), but of course some of it is to be viewed from a historical point of view =)

Actually, it should be info:/gcc and man:/gcc (for Konqueror) For similar capability under GNOME look here.

Porting UNIX programs to OS X can be a lot of work, much more than to just about any other platform that claims to be UNIX-compatible.

In case you care, the programs I'm talking about are base64 (a simple base64 decoder, required no changes), HUGS (a Haskell interpreter, didn't require any changes either to compile, only to install; note that this was before it was includeded in the fink ports tree) and umoria (rogue clone, required 3 changes).

A UNIX kernel hacker coming to Darwin has to start learning from scratch because its architecture is so different.

Apart from that, do you really think the kernels of Solaris, AIX, Linux, 4.4BSD, ... have that much in common? (even ignoring the fact that some of those follow System V with POSIX interfaces bolted on later, while others are the other way round). There simply is no "standard UNIX kernel implementation", except maybe the original one by AT&T. When one OS is better at low-level things (e.g. multithreading or virtual memory handling), this pretty much invariably means that that particular OS has completely different (or at least heavily hacked) implementation of this facility than other OS'es (otherwise it would be the same). That doesn't make it less UNIX or anything else though.

X11 on OS X is rather inefficient.

Multimedia works differently.

Etc. Etc. OS X just doesn't function like a "true, complete Unix". It's a good approximation, but no more.

On OS X, X11 runs on top of, and in parallel with, the existing Mac window system. Normally, X11 has sole and complete control of the frame buffer, graphics hardware, and accelerator.

According to you, would Mac OS X be more of a Unix if the XFree people had to write their own driver, i.e. if Mac OS X didn't supply it's own accelerated drivers? Or does supplying a default window server that is different from X11 make an operating system suddenly less Unix?

The fact simply is that all UNIX flavors differ on several points, but that doesn't make any of them less of a UNIX. Some more general UNIX reading can be found at Bell Labs.

MS could just buy Mandrake and not miss a beat...say hello to the new clippy.

I've had more then enough problems with older unsupported/uninstalled applications and printed web receipts laying around that I finally broke down and configured a PDF printer on my network. Using Samba, Ghostscript, and a PS print driver in Windows (all completely free), I can "print" any document to my Linux machine and have the output go directly to a PDF file. With the PDF, I have a very high quality permanent copy that I can backup and reprint at any time in the future. It is faster, looks better than, and much more efficient then printing to a regular printer and scanning it. There are many references on setting this up, searching for ps2pdf, ghostscript, samba will turn up a lot, a good start is an article in the Linux Gazzette. With some changes, you can also convert any PS file to jpg, tiff and others if PDF is not something you desire for the final output..

This does not justify what Intuit is trying to do to squeeze every last freaking dime out of you and taking away your first sale rights but it is a solution that will work for this and for many other issues with print only documents.

I wrote the Linux Digital Fansubbing Guide. I have a section in there on SVCDs. So I know a thing or two about making SVCDs in Linux.

Here's a couple of Linux programs that can encode mpeg-2:

• mjpegtools
• transcode (see here for its SVCD documentation section)

Avisynth has also been useful for various NLE and filtering tasks...is something similar available for Linux?

Okay, here's the beauty of Linux. You don't need it. If you simply want to frameserve an AVI, a named pipe (man mkfifo) will do just fine. If you want to do fancy stuff like overlay two AVIs, check out the subtitler plugin in the transcode software I mentioned above, which can do overlays, fades, and scrolling of many types of objects including text, pictures, and video.

Here's one.

I have evaluated file systems of late, and wish only to express the need for more attentiveness in one's file system. Being nonchalant about this can lead to "bad situations."

I just finished evaluating JFS 1.0.24 for Linux. My opinion of 1.0.24 and JFS is IBM is doing the port as a courtesy to AIX and OS/2 migrators. It is extremely robust, but slow, 2x slower than XFS or Reiser. I had maximal R/W activity (tar untar create deletes in while loops, Xwin started, downloading via ftp, scp, etc) and power off hot several times, never saw anything but "file system clean."

I am in process or evaluating XFS 1.2pre3. 1.1 XFS for Linux is unreal. It does "everything," it has done it for years, its high performance, has a robust heritage and is all around very good. I have cold killed it, inserted and removed hot swap drives while running, while doing fairly absurd amounts of activity on the test box. Not using this file system is a shame. The release patched kernels, one catering to the Redhat droids and the other is a vanilla with their magic patched in. This isn't a Marcelo kludge either, these are professionals who care greatly in the stability of their product and do a great job in their little cornel of the kernel. The Mandrake and SuSE kernels have this stuff patched in, along with extended attributes and ACLs, and the XFS kernel only has ACL and DMAPI support, and the JFS patches won't apply clean to their kernel, but on thing is true of SGI's version: It actually compiles. The Mandrake 9 and SuSE 8.1 kernels seem not able to compile outside of their proprietary environments. I am upset about this. Typical second tier vendors who fail to bring coherency to fragmented set of projects loosely and informally known as the nebulous "Linux."

EXT3 is a dirty hack (EXT2 with fake journaling). I don't know how EXT3 gets high performance marks - ever - my experience has suggest awful and inconsistent performance with several nasty changes made to e2fsprogs in succession to address potentially severe problems. Its insulting to enterprise customers that RedHat touts this garbage as a journaling filesystem. Reiser is a UFO, and is easily corruptible, and I fail to understand its wide use and early integration in the kernel - my only guess is its simplicity required the least cleaning up of the kludged Linux file system underpinnings. I also get sick to death of Hans blaming everyone and their mother while the guys at XFS and JFS quietly patch away the problems, while Hans whines. Hans did have a good point about the broken RedHat compiler back when it was an issue. I base my opinion of EXTx, and Reiser based on experience. I am appalled, and disappointed at the lack of respect the Linux kernel maintainers have given to XFS. The best of the litter being the last to go in - typical, and Appalling.

UFS+logging on Solaris and UFS+S on FreeBSD are both superior. I have never seen these go haywire. Ever. Interestingly, UFS+S is apparently the 'softcore' journaling method that EXT3 uses, but its far less damageable by empirical determination, and its clearly faster and runs more smoothly. Anytime Veritas appears, which ironically is included in SCO, and is available for Solaris and NT based OSs, things come along quite nicely.

Recently OS X added journaling to the already pathetic HFS+ filesystem. My experience with Mac OS 10.X, including 10.2 has been horrible. I think its inferior, the Mach kernel was deprecated by its progenitors, CMU, in 1994. I think the FreeBSD userland is outdated. I think HFS+ is a pathetic file system and fail to understand why they don't use UFS, but if you have ever tried using it with OS X you know it's not "finished." [defined as: nothing work if UFS is used - don't try and say otherwise] Adding journaling to HFS+ will only slow down an already horrifically bloated and underpowered platform. I find it laughable Apple hardware does not get submitted to www.spec.org, but I have CPU2000 results for PPC 1.25GHz, and of course it is so horrible they can't submit - everything including the SPARC beats it hands down. I also though having to have OS 9 installed on a separate partition as OS X for classic to work properly laughable. I base my deprecation of the Apple efforts on real life experience and objective comparison. I only have to convince myself, but for those who can't easily see where the truth lies on the speed of a Max vs. a PC, my condolences to any significant other you might be lucky to have.

FreeBSD 5. UFS2 will probably be one of the best filesystems to ever see the light of day, and vinum will be there as well.

[I hate Eugenia Dork Loli and her horrible crap "editing" and "journalism," but there are interviews with Steve Best [JFS],Hans Reiser, and Nathan Scott [XFS], held prisoner on OS"News" (more like OSCrapConjecture), very informative; http://www.osnews.com/story.php?news_id=69 ; with some more Journaling info here, http://www.linuxgazette.com/issue55/florido.html showing how Robust XFS is]

When examining the facts, the superiority of XFS becomes clear, and I advocate its use, it's the responsible thing to do. I have recently beaten heavily on a 2.4.19 stock + XFS pre3 of release 1.2 merged in. I can tell you my experience with the Dell 1650 and constant filesystem abuse that the filesystem is that last thing I would worry about in that kernel. I am eagerly awaiting the release of the 2.4.20 kernel, typically long over due as we seem to have an absentee maintainer that rarely speaks, however, upon its release I believe the XFS 1.2 stable will be merged in or completed and I will have a configuration good to go for use on the order of years.

While I may have harsh words from certain practices and sometimes people, I find XFS and the 2.4.19 kernel to be acceptably stable. I ran that 1650 through the washing machine fairly rigorously, and besides the idiotic spurious " Warning - running *really* short on DMA buffers" errors (which caused a flame war on LKML), it seems to be a useful kernel. The RedHat 2.4.18-17.7x kernel, by the way, is the worst most untested pile I have ever seen. What is wrong with these people? Several net drives with no working promiscuous mode, kernel panics, the list is endless.

I am willing to bet that your problem is bad configuration, in particular hard disk configuration. Check out hdparm, and make sure your disks are using DMA, etc.. (LinuxGazette has a write-up)

If I can't use something under Linux, it won't get purchased, period, and I don't have the money to take risks on technology that might and probably work under Linux, but doesn't now.

It should work, look here .

Your modem is likely a 'win-modem' that will unfortunately never configure to be Linux compatible. These are common in several name-brand computers.

I believe the problem is that M$ specified a modem for their OS. (You can do that as a monopoly).

I'm not sure if the compatibility is a hardware issue or a closed source issue, but either way it keeps you as a loyal fan of M$.

More info

A quick check on Google popped up the following links:

(LILO CRC error...)
http://www.linuxgazette.com/issue50/tag/24.html
http://brenner.chemietechnik.uni-dortmund.de/doc/s db/en/html/kfr_50.html

(Grub cannot fit selected item into memory)
http://www.gnu.org/manual/grub-0.92/html_node/Stag e2-errors.html
http://mm.ilug-bom.org.in/pipermail/linuxers/Week- of-Mon-20020729/005620.html
http://lists.infradead.org/pipermail/linux-mtd/200 0-March/000346.html

Based on those links, I'd be chasing down something taking some of your low memory away from you so that it doesn't boot right. Keep in mind, it may still be an ailing HD as intimated in the LILO links. As for the bootloaders being ready, they are- you've got a special case that's causing you problems and many, many others don't seem to have your issues with them. I can't speak of Red Hat's support since I've not used their distribution in a while- so you may have a beef there.

Meanwhile, a quick Google search leads to:

One
Two
Three

Check your hardware.

Also a list on Linux Links that may be of some help.
Possibly a 3D modeller could be of some help too for visualisation purposes. Especially if used in conjuction with CAD software.

A fairly detailed list of various memory debuggers for Linux was covered in the August Issue of Linux Gazette, available here.
It's interesting to note that the article actually says the following:

Purify
The big daddy of memory tools, does not work on Linux, so you can stop asking that question.

Funny how that changed so quick!

A fairly detailed list of various memory debuggers for Linux was covered in the August Issue of Linux Gazette, available here.
It's interesting to note that the article actually says the following:

Purify
The big daddy of memory tools, does not work on Linux, so you can stop asking that question.

Funny how that changed so quick!

<place tongue in cheek>

There's an interview with Linus in Linux gazette issue 32, 1998 which you can use as a shocker, be warned, you might realize that your understanding of USA might be just a result of long-lasting brainwash ;))

"I agree that Finland is a lot more "neutral" in many ways, and that had its advantages in Linux development" ........ "Moving to the US has meant a lot better weather " ....... "The idiocy of the US cryptography export rules were a problem even before I moved here" ....... " I don't think anybody really dislikes Finland, while a lot of people are nervous about or even actively dislike the US. So in some sense that could have been a downside, but I felt that most people trusted me more as a person than as a Finn, so I didn't feel it to be a major issue. "

To be honest, I would not consider even the weather part as a plus ;))

Here is a pic.

...having just seen this picture of the recent KDE 3 hackfest.

A portrait of the Mandrake user from a collection of Linux User Caricatures:
This chap (baby) is the new distro on the market(compared to the others anyway). He is always seen as a new lunix user hence the baby look, and the distro is regarded as one best for beginners to learn who might be migrating from windows to linux.

A portrait of the Mandrake user from a collection of Linux User Caricatures:
This chap (baby) is the new distro on the market(compared to the others anyway). He is always seen as a new lunix user hence the baby look, and the distro is regarded as one best for beginners to learn who might be migrating from windows to linux.

I guess that's why no one would (or could?) tell me how to get back into my late RedHat setup after it arbitrarily decided it no longer knew my login password?

Boot to single user mode (at lilo append "single" to the kernel name. If that doesn't work there are alternatives

Then use passwd

The Linux Gazette has a monthly part about The Foolish Things We Do With Our Computers. Recently they've been getting far less mail to this area.

The Linuxgazette is writing a serie of docs about this. They're explaining how to use POD, LaTeX with latex2html and next month DocBook will have it's turn.

The Linuxgazette is writing a serie of docs about this. They're explaining how to use POD, LaTeX with latex2html and next month DocBook will have it's turn.

I generally take a trip to Borders once a month and return with both of these.

Sysadmin isn't specifically a Linux magazine, but it frequently has some damn good articles involving Linux and will show the novice the kind of things Linux and other Unices are really good at.

Linux Journal is the other magazine I read regularly, it has a good mixed bag of articles and opinions.

Someone else mentioned Linux Gazette, it's web-based only and is a 'sister' of Linux Journal. It has some very good technical articles and it's free (sponsored by various companies).

You won't learn everything from magazines though, see them as a catalyst for further research through books, web sites, man pages, and most of all, your own experimentation.

The NT loader is perfectly capable of booting Linux, or any other OS for that matter.

I'm sure everyone knows this, but you can use NT (and Win2k)'s built in boot loader to launch Linux.

Here's the link:

http://www.linuxgazette.com/issue36/larriera.html

There's an interesting review of different file systems here

How about a little wrap up:

Part I - Using ssh

Part II - ssh suite: Sftp, scp and ssh-agent

Part III - Using ssh-agent for SSH1 and OpenSSH

Abbreviated Version

The authoritative source

Mmmnnkay? Mnnnkay.

How about a little wrap up:

Part I - Using ssh

Part II - ssh suite: Sftp, scp and ssh-agent

Part III - Using ssh-agent for SSH1 and OpenSSH

Abbreviated Version

The authoritative source

Mmmnnkay? Mnnnkay.

How about a little wrap up:

Part I - Using ssh

Part II - ssh suite: Sftp, scp and ssh-agent

Part III - Using ssh-agent for SSH1 and OpenSSH

Abbreviated Version

The authoritative source

Mmmnnkay? Mnnnkay.

Have phun.

Wow, must have been hard to write the article when you have stuff like this, In Issue 27 of the Linux Gazette even.

Other sources:
Diskless HOWTO
XDMCP HOWTO
XDM-Xterm Mini-HOWTO
Linux Terminal Server Project

I'm suprised it made it past the Linux Gazette Editors actually, considering it was in Issue 27! You've got one year of HS left, but I suggest you try harder in college or someone will call you on plagiarism. I admit however that I didn't actually read the artice, as I'm not likely to find any new information.

Whether you agree with it or not, RedHat and VALinux alike have spurned adopting ReiserFS despite its inclusion in the stock Linux kernel as of 2.4.1. Both vendors have courted the more "evolutionary" Ext3 kernel for 2.2 releases, but Ext3 is not the future of JFS' on Linux. As such, I offer this article in a plea for RedHat and/or VA Linux to begin consideration and formal testing of XFS as a viable JFS for their future, kernel 2.4-based product releases.

1. Your typical dual-NFS/SMB file server administrator

   I have been integrating and maintaining production NFS/SMB UNIX servers and networks for years. As such, I ask that some of the "ReiserFS absolutists" (i.e. believe only ReiserFS should exist as every other JFS for Linux is "not as good" in their opinions) out there, who don't use Linux's kNFSd services in a heavy production environment (especially with non-Linux NFS clients) like myself, please not blindly comment on this post. Remember, every OSS project "itches a scratch," and there is a reason why Tweedie's Ext3 and SGI's XFS exist in addition to Namesys' ReiserFS (disclaimer: I know little about IBM's JFS).

2. Why some of us went Ext3 over ReiserFS

   Because I have UNIX NFS clients, ReiserFS was quickly identified as a "non-viable solution" for my needs (not that it is not applicable in many other areas, no sir, so don't flame me!) when I first looked at JFS' in early 2000. Although ReiserFS is very innovative in design, which includes a recent DARPA grant to extend these capabilities, its lack of a traditionally keeping meta-data in the inode itself results in a host of traditional UNIX service and VFS incompatibilites. So I ended up testing the early, full data journaling (aka Ext3 "v1 mode") Ext3 releases (e.g., 0.0.2f) for 3 months on non-critical systems with great success. I eventually adopted it on my main fileservers in summer of 2000 and it has worked flawlessly since. I even had a physical disk error, which my RAID controller did not catch for 24 seconds (long story, the firmware and driver versiuons was out of sync, my fault) and I was able to drop down to the full Ext2 fsck to fix things.

3. Ext3, the conservative solution

   For people like me, Ext3 is a nice, "evolutionary" approach to journaling that significantly reduces the variables involved -- important to some of us that don't embrace "change" so quickly (for obvious reasons ;-). Ext3 is also a quick upgrade for existing Ext2 filesystems (get Ext3 kernel, e2fsprogs aware version, create the journal file, and mount as Ext3) plus complete reversable back to Ext2 (just delete the journal file and reset some superblock variables), which meant I could "switch back at a moments notice." I find the VA Linux kernels with Ext3 added (along with NFS v3, unified IDE and other 2.4 backports to 2.2) most excellent, and longtime Linux kernel NFS guru H.J. Lu (now formerly of VA) takes the time to make the appropriate RedHat RPM kernels for us RedHat users (shortly after HJL's departure from VA, I began hosting his kernels). VA Linux uses Ext3 in their enterprise NAS device products (actually based on not a RedHat kernel, but SuSE!), although RedHat's adoption of Ext3 has been limited to a public beta, and installer/BOOT kernels that are simply "Ext3 aware."

4. Ext3, not ideal for the near future

   Today, Ext3 is still a kernel 2.2-only solution. And it still "inherits" all the "limitations" of Ext2 -- so it is not ideal where features are more important that minimizing variables. Now it's not that I've adopted kernel 2.4 on my most critical services, as it is still maturing IMHO (not bashing 2.4 at all, but as more systems run it, more "issues" are identified that were not before), but it would still be nice to have on some of my more "bleeding edge" workstations. I would be satified if Tweedie would only port the full data journaling (v1 mode) capability to 2.4, although I heard he purposes held off on the kernel 2.4 port and Ext3 1.0's release until 2.4 itself "stabilized" in his view (of which, I've heard many good reasons for doing so). If anyone has any insight to all this, I'm all ears (as I can only "assume" things here from what I've heard).

5. Re-evaluation of ReiserFS in kernel 2.4.1+

   As such, that left me with re-evaluating ReiserFS for 2.4 systems, now in the stock 2.4.1 kernel, or possibly SGI's XFS or IBM's JFS. I looked at ReiserFS only to discover that the stock kernel does not include the kNFSd workaround patches. Furthermore, many ReiserFS users were still plauged with NFS and even quote issues, even after patching. This tends to make me believe that it will still be awhile before specific Linux subsystems "better accomodate" ReiserFS completely for certain users (like myself), although it is a viable solution for most standalone workstations or Windows-centric file servers. Even I am using ReiserFS on a kernel 2.4 Netfilter firewall and Squid Proxy cache/filter, where it excels (but does no direct network file serving duties).

6. First impressions of XFS in mid-February

   This led me to SGI's XFS. Mid February saw the release of kernel 2.4.2 and, by the weekend of the 24th, SGI had already adopted 2.4.2 as the base of their XFS development CVS repository. I was impressed with this attention to keeping XFS' development as close to the stock kernel as possible. I decided to check out the kernel, compile and test it on a few older and newer systems, and ended up writing an RPM spec file and releasing some RPMs for RedHat 7.0 at the time (since it has been a couple months, using 2.4.0pre kernels, since SGI had done so). Thus I began my standard "three month evaluation" of XFS in early 2001, like I did with ReiserFS and Ext3 in early 2000.

7. What is instantly preferrable about XFS

   It did not take me long before I was impressed with SGI's XFS implementation. Most specifically:

   • Forgetting features, Linux-oriented integration was at the forefront of XFS' port. The fsck program was called "fsck.xfs" (which really did only some basic things, relying on "xfs_repair" for any rare "dirty work"), and "xfsdump" preserved advanced XFS attributes in backups.
   • The structure of XFS has remained relatively unchanged since the original whitepapers and release in the 1993-1994 timeframe. One thing that scares me about ReiserFS is the changing internal structure, not just via the extensible features of putting meta-data directly in the root tree -- which is a very interesting, advanced and novel idea -- don't get me wrong -- but I believe even Linus had to put his foot down on some of these "variables" before ReiserFS was included in 2.4.1 (as I have heard). Again, XFS' structure on Linux is that of the Irix implementation.
   • Regarding features, according to the Linux Gazette #55 review of JFS' for Linux (mid-2000), XFS sported the most features -- from B+Tree directory and free block management to small data file and directories being stored in the inode itself. But it still preserved the traditional, UNIX FS inode structure that made NFS, quota and other support natural and minimal in effort.
   • The ability to move storage devices from MIPS/Irix systems to Linux systems is a big plus. Most intererstingly, this also included almost direct porting of XFS's Access Control List (ACL) capability from the Irix platform to Linux. I had personally never used ACLs on Irix before, just Solaris, and was impressed by XFS' storing of ACLs in the filesystem meta-data, instead of in separate files like Solaris (although the XFS "acl" front-end has a syntax that leaves much to be desired ;-).
   • Lastly, it looks like SGI is "thinking ahead" to enterprise NAS/SAN devices by implementing a Data Management API (DMAPI) for hierarchical storage management (HSM) subsystems. XFS excels at large file performance, hence why MIPS/Irix is a favorite platform for A/V content servers.

8. How SGI releases XFS

   Shortly after my RPM releases for RedHat 7.0, SGI began a series of test releases for the RedHat 7.1 beta (first Fisher, 7.0.90, and then Wolverine, 7.0.91) in March and April, and eventually RedHat 7.1 itself. Like the 2.4.0pre kernel releases before them, RedHat releases XFS in a three fold scheme:

   • Tarballs from CVS, and patches from CVS again the stock kernel, which include the ability to build RPMs and Debian packages (by including the appropriate SPEC/config files).
   • [Source] RPMs for popular RPM distributions (e.g., RedHat), as SGI has a long stance of not being in the business of distributing their own full-up distro (just support "add-ons" for their hardware).
   • A modified RPM set and Anaconda installer, including a bootable, pre-mastered ISO CD, that allows XFS to be installed alongside a stock RedHat distribution. This is especially sweet IMHO.

9. XFS Release 1.0 is a solid JFS for 2.4 file servers

   As of May 1st, XFS Release 1.0 was released. In following their three fold release venue, it includes a ~300MB additional ISO CD for installing with RedHat 7.1. But instead of patching XFS against just the stock Linux kernel, SGI took the time to take the RedHat 7.1 2.4.2-2 RPM kernel release and patch it against that (they actually did this with 1.0-Test3 as well) -- inheriting and benefiting all the patches and other kernel decisions that RedHat makes. This is very important to system administrators like myself which only trust RedHat releases and kernels for heavy file server duties (please, no flames on this -- I'll list reasons off-list, and I *DO* recommend Mandrake and, increasingly, Debian for many other purposes).

10. Additional advantages of XFS that RedHat/VALinux should consider

    As such, I am surprised that RedHat and, especially, VA Linux have not taken a closer look at evaluating and, gulp, even supporting XFS's development on kernel 2.4. XFS is the natural upgrade for these two firms, being that both have spurned supporting ReiserFS for its non-traditional and troublesome design with traditional UNIX services and capabilities like XFS. In addition to design attitude, features and other considerations SGI has made in porting XFS to Linux as I made above, I would like also point out the following, additional considerations:

    • Again, I want to hammer home that SGI has been committed with each and every OSS project and release to base them on the "common" project releases. Not only does SGI keep their CVS repository in-sync with the latest kernel and support project releases, but they can integrated XFS with even RedHat's heavily patched kernel releases. I would personally like to hear what Alan Cox thinks of adding XFS to either his "ac" release, or pushing it on RedHat internally.
    • XFS's ACL capabilities are superb and add quite an "enterprise punch" to Linux. Not only are the XFS ACL's supported fully in Samba 2.2 on both Irix and Linux, but Steve Lord of SGI was part of the kernel 2.5 developers conference presenting the idea of adopting XFS' ACL approach in the core VFS (virtual filesystem) layer of Linux 2.5 itself (so all filesystems could benefit). This should tell everyone about the capabilities XFS brings to the Linux table for all Linux filesystems to benefit from.
    • In addition to ACLs, quota support is production quality. Not only does XFS have full, VFS-compatible quote support, but XFS is now a supported fs in the official Linux Quota project's CVS repository (and future releases). This should further drive home the fact that XFS can be and is being easily integrated into standard, stock Linux.
    • XFS is fully LILO compatible, meaning a system, with or without a separate /boot filesystem, can be completely XFS. In addition to being XFS root bootable via in-kernel compilation, the three core XFS components can be compiled as modules, and loaded via an initrd (initial root disk) instead. No "performance hidering" options are necessary for this compatiblity (unlike ReiserFS and its "notail" option).

11. Disclosing the few disadvantages and issues with XFS

    As much of a XFS advocate as I am, I am also quick to honestly and complete disclose each and every "disadvantage" or "issue" with XFS. Note that they are few and usually non-issues in most situations, although XFS is no more of an "universal JFS for applications" than ReiserFS is (and I would and should be considered a "XFS Absolutist" if I didn't). Specifically, I find the following disadvantages to and issues with XFS:

    • Although XFS sports some excellent performance number in certain operations (especially large files and random writes), XFS' inherit design makes it horrendous at deleting lots of small files, even versus Ext2 (and specifically against ReiserFS where ReiserFS excells). This makes XFS a less than ideal JFS solution for caching/temporary/log filesystems (e.g., /tmp and /var) and applications/services (like Squid proxy cache/filtering servers) -- although I have found that a XFS /tmp and /var "feel just as fast" as Ext2 on workstations (haven't done extensive testing on servers yet). Since this is a design flaw in XFS' structure itself (although that same design allows faster operations and performance in other areas ;-), in the future, I hope both XFS and ReiserFS will be part of the same, stock kernel releases so I can use XFS on data and application partitions (like /home, /usr, /usr/local, /opt, etc...) that are XFS exported, and ReiserFS on local, non-exported support partitions (like /tmp and /var -- although I will probably leave /var/spool XFS since most operations, like print jobs, are large files).
    • The size of XFS' code base is very large, resulting in a ~1MB support module set -- too big to fit the initrd on a floppy with the kernel, or just barely small enough to fit compiled-in kernel that sports little else on a floppy. Although I'm fairly sure this may be just a short-term fact of a "first port" -- I being a true believer in "get the sucker running, then optimize code size" and XFS is currently one of those codebases where many routines are redundant throughout the code. But the size of the code base and binary does not affect overall run-time performance as various XFS benchmarks prove -- which supports my theory that the current Linux port is simply an un-sized-optimized release that will improve in the future.
    • Although XFS is fully LILO compatible, it is only LILO compatible when LILO is used in the MBR (master boot record). Those of us who like to use 3rd party boot managers and put LILO at the beginning of the root (or /boot) partition will find that this is not an option with XFS if the root (or /boot) partition is XFS. To use a 3rd party boot manager, the root (or /boot) must be Ext2 on XFS systems (although I believe ReiserFS is in the "same boat" here as well?).

12. The final analysis

    SGI's XFS is a powerful, stable and feature-packed JFS that is mission-critically proven on Irix and now available for Linux. It brings a wealth of features and traditional UNIX fs compatibility to Linux, while only sporting a few, less than optimal attributes in some limited areas. Being that SGI has gone to great lengths to synchronize its codebase with the common codebase of the projects it integrates with, and some of these projects (notably Quota and Samba) have adopted native support for it, many XFS users are starting to question why XFS has not become an option in our favorite distributions.

    As such, I urge RedHat and VALinux, two companies who currently favor Ext3 and spurn ReiserFS for specific issues that XFS does not have, to consider beta testing and offering XFS as an option for their distributions and systems. As the 2.4 kernel matures and gains widespread acceptance, those of use who cannot adopt ReiserFS will need a solid replacement for Ext3 coming from kernel 2.2. And the additional enterprise-driven features of XFS make its consideration that more inviting.

    I thank you for your open consideration of this article.

-- Bryan "TheBS" Smith

Here is a good article that may help explain differences. http://www.linuxgazette.com/issue55/florido.html