Slashdot Mirror

The most interesting thing I've seen in terms of filesystem technology lately is Reiser 4, which has been discussed here before. It supports extensible metadata and filters but doesn't bog you down like a database can or break backwards compatibility.

No, not like using ln. Making a symbolic link requires that I've already anticpated that someone needs a file in a different path. This, in effect, removes the tree structure and makes every filesystem object just a series of interconnected nodes. Have a read of Hans Reiser's whitepaper on the subject. I was most impressed.

So, for email, I keep folders to a minimum of about 6. But because time is so important, I tier those, so that anything older than a week goes into a mirror folder structure under OLD. Then anything older than a month is moved into ARCHIVE. And the archive stuff is compressed, so I have to really want to look at it.

inbox
root
etc
OLD/inbox
ARCHIVE/inbox.tgz

card ()
{
( ( echo --;
cat -;
echo -- ) | perl -pe 's/\n/\\n/g';
echo "" ) >>~/.tel
}
tel ()
{
cmd=$(perl -e 'print map(" | grep -i $_", @ARGV), "\n"' $*);
cmd="cat ~/.tel $cmd | perl -pe 's/\\\\n/\n/g'";
eval $cmd
}

For shared stuff, I really like having an unofficial document system, and my favorite is The Moin Moin Wiki because it's fairly simple to use and install.

see http://www.namesys.com/whitepaper.html It's the same idea (and more).

A good analyzis can be found in the White Paper by Hans Reiser.

The idea is that folders, whether they be in the context of an email program or a filesystem, are actively updated searches.

This is a Good Thing IMHO. But, I find that abstract views are almost as good. I'd love spend my time contriving useful query-based views of my mail (e.g. select * from ~/mail where address like family and pr0n = false and spam = no) rather than doing some other things [1] but alas. Fortunately there is the 'in the file system' approach that Hans Reiser and crew are working toward. Files as directories of content/properties, indexes built from custom searches on transactional filesystems. And all of it open to tinkering and improvement. The UNIX 'file-os-ophy' of text files and meta-data would make my ideal open and convoluted mail storage system trivial.

Worried about space? Run it through transparent filesystem level compression. Worried about security? Gpg ain't exactly new. Want more meta data? No problem: the filesystem of the future has plenty of flexibility for your X-Hot-Natalie-Portman-With-Grits field.

[1] One of the few things tying me to M$ right now is the preponderance of custom sorted, property-extended email stuck in M$ proprietary formats. If I have to write another shell script to parse MBX, PST or OST formats...I think I'll scream.

Free of charge? You're under-cutting the real people. Shame on you.

http://www.namesys.com/support.html

How about if you're not using a package manager? There are plenty of programs out there that are still only available as binaries or source code, not as packages. RPM isn't the answer to everything. I realise that you can build your own packages, but sometimes you don't want to. I do agree, however, that files that need to be writable probably shouldn't be on /usr, though you then have /usr/local/etc to be concerned about. The /var partition was created for this kind of thing. I'm not sure why this doesn't go in /var/cron myself. An interesting development is the long term plans of ReiserFS. They have a concept of multiple filesystems being mounted at the one point. So, for example, you first mount the system /etc read-write, then you mount a NFS filesystem to /etc read-only for central configs, then you mount another local filesystem to /etc read-write as a user logs in, which contains that user's own configuration files. All programs would then know that configs go in /etc, and no more ~/.everything type directories. In fact, this would allow for separation of configuration from home directories, so that you could have your home directory mounted at whichever workstation you sit down at, but have different configurations depending on what workstation you are on. The filesystem would handle mounting any number of filesystems to /etc, and transparently handle the permissions on the different filesystems mounted at that point. I haven't made it through much of the documentation on the website yet, but it's a very interesting read.

all the psuedo-files like ..user and ..access are hidden, so you're not going to see them in an ls -la, even if you wanted to. To get a list of all the psuedo-files for a particular object (directory or file) you just cat objectX/..psuedo

Have a look at the docs.

Btw, what's up with the soft-porn? The chick clearly has a nipple...

From what I can tell from reading the documenation on their web site, reiserfs is going to keep introducing new features that make the filesystem more and more like a database. Besides the metadata thing, I think the namespace integration will eventually be the "killer app" for reiserfs.

• plugin-based architecture
• new semantics that allow files to also be directories

Doesnt Reiser FS 4 also have this feature.

In Gnu/Linux we have files, directories, and attributes. In NTFS they also have streams. Since Samba is important to Gnu/Linux, there frequently are requests that we add streams to ReiserFS. There are also requests that we add more and more different kinds of attributes using more and more different APIs. Can we do everything that can be done with {files, directories, attributes, streams} using just {files, directories}? I say yes--if we make files and directories more powerful and flexible.

While there are problems to be solved (backup, for instance), there are many benefits as well.

Many detractors of the UNIX security model point to the lack of ACLs and fine-grained security.

The U.S. DoD has contracted Namesys (the ReiserFS guys, led by Hans Reiser) to develop a filesystem upon which security can be build. Reiser's vision is a filesystem which allows users of the filesystem to define what security means in an extensible manner, with plugins.

The future of ReiserFS includes a plugin architecture which makes it easy to implement NT permissions, for instance, without breaking existing programs or requiring new semantics which wouldn't work across, say, NFS.

I'm not sure why the author chose to throw Plan 9 into the mix. Plan 9 has some interesting features, but I don't feel that either Plan 9 or ReiserFS was given sufficient attention to allow the reader to understand just _why_ such things are interesting.

I tried to sum up some interesting Plan 9isms here, but I'd rather not go into it -- reexporting modified views of the filesystems is a complicated thing, and it's hard to justify such complexity in limited space.

As far as ReiserFS goes, the current and future benefits are many.

First, speed is king, and ReiserFS takes the crown. Anyone who has waited more than 10 seconds for "ls /usr/share/doc" on ext2 can attest to the fact that ext2 craps out on large directories. Reiser V3 does quite well, and V4 is rumored to do even better.

Second, space efficiency is nice, and ReiserFS does it better than anything out there. While storage sizes are increasing dramatically, it "feels" wrong to waste a whole block on a trivial file (only a few bytes long, for instance). With ReiserFS, developers don't need to waste time trying to work around the need for efficient small file access -- it's efficient to have many small files, and it's efficient to have many of them in one directory if needed.

I believe it's been said that in the future, ReiserFS may compress the filenames in some way to try to eliminate even that overhead.

ReiserFS V4 implements wandering journals, and support for transactions. What does that mean to the layperson? It means that in the event of a crash, an application which handles important data (for instance, an online purchasing system) can promise that in the event of a crash, a group of related filesystem operations can be guaranteed either to have all completed, or have all failed.

For instance, a purchasing system makes a note to charge the person's credit card, and to ship the items that were ordered. You can tell ReiserFS programmatically to "create a file in /var/orders/ and place this text in it, as well as a file in /var/ccbilling with the customer's credit info in it, and if the system crashes halfway through, throw it all away, because I don't want to charge for products I'm not shipping and I don't want to ship products for which I'm not billing."

If the system crashes, you don't have to work to make sure that you have a one-to-one mapping of orders to sets of billing information -- ReiserFS can guarantee you that either all of it got recorded, or none of it got recorded.

So now you've got a fast, reliable filesystem. I'll even let you ignore the fact that ReiserFS will let you implement per-file compression and encryption plugins. Still not impressed? Wondering what all of this crap about namespaces is about?

The author of this article basically ripped off Hans Reiser's examples from his V4 draft document, such as the /etc/passwd thing. I'm not sure where he got the idea of subusers and I don't much care, as it's not really relevant to the namespace thing.

What is interesting, but not really mentioned, is that file filters can become part of the filesystem.

The specific implementation details in this example are products of my imagination,

Well, I dont know about 2.6, but you can install it on 2.5 tough :)

Perhaps he was waiting for slashdot to send him $250..

If you are interested in what Reiser4 offers (and no, it's not a database), take a look at here.

Warning, quite long and full of details, but a fascinating thought that it may be in a semi stable state this year.

It might just be entirely possible that microsoft bought a licence from namesys for reiserfs. Reiserfs doesn't have to be GPL you know.

see: Business Model and Licensing for more info.

Have you had any issues with the fact that Namesys is a Russian company? I think we all remember the recent story about DARPA pulling their funding of OpenBSD. Do you worry about this happening to Namesys?

First of all anyone who hasn't read the Future Vision for Reiser4 should. From the comments so far it seems like most people are unaware of the main goal of the project, which is too bad because it is probably the most ambitious free software project in existence.

This doesn't really do it justice, but what the project is trying to accomplish is to push a great deal of the functionality of databases into the filesystem. In a better world than ours you wouldn't need a table with keys and values, you could just have a folder (table) with filenames (keys) and file contents (values). The problem is that storage is allocated in large blocks, and so the kind of small files that one would use as values end up wasting enourmous amounts of space. This is the virtue of ReiserFS: it has efficient small file performance. With future version the namesys crew seems to intend to add all the wonderful searching abilities that we would want directly into the system calls.

Ask yourself this, which is less hassle to use, /proc or /etc? Wouldn't it be nice to be able to change your resolution in X with
echo "800x600" > /etc/X11/Resolution?

The general idea is that settings could be stored hierarchically, so that /etc/password, for example would look like this
/etc/passwd/
/etc/passwd/root/
/etc/passwd/root/password => sldk7w9xh3
/etc/passwd/root/uid => 0
/etc/passwd/root/gid => 0
/etc/passwd/root/name => Sir Walter Raliegh
/etc/passwd/root/home => /root
/etc/passwd/root/shell => /bin/bash
/etc/passwd/root/luser/
...
where => is some sort of operator that displays the contents of a file.

Essentially this adds all the benefits of a registry (e.g. you change your password with echo "opensesame" > /etc/luser/password), without adding the complication of a half-assed database (e.g. our friend the Windows registry).

Think for one second about how easy this would make adding a GUI configuration to your favorite program ("You mean I don't have to write a seperate parser for every program"), without, of course, requiring a GUI. It has simplicity, it has elegance, it has closure.

My question for Hans is this: it seems that you have put in place a system to let the filesystem take on all the functionality that I was going on about above, how do you intend to get people to use it? Making reiser a filesystem does add a high level of commitment: users have to reformat their drives, and people writing applications can't really assume that their users will have it, and so will be reluctant to rely on it. Obviosuly it is immediatly useful for in-house projects that can have very specific requirements, but how can we get the rest of the world to switch over?

First we'll ask the question, then we'll be made to pay $25...

I'm preparing by reading everything I can find: I'm working on Tanenbaum & Woodhull's "OS Design & Implementation"; I've read "Design and Implementation of the Second Extended Filesystem"; Steve Pate's "UNIX Filesystems" is waiting on my shelf; and of course, there's the FAQ and ReiserFS v.3 Whitepaper at www.namesys.com.

Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front? And are there any special tricks (above and beyond mastering your subject) to getting hired in this field once a degree is in hand?

Thanks!

In your future visions paper early on you talk about Reiser's Rule of Thumb #2. However, I can't find Reiser's Rule of Thumb #1 -- what is it? Is it a secret? Does it contain the sum of all human knowledge?

TELL ME!

Scroll down are you should see the following:

However, in practice it [the maximum number of files] depends upon the context.
- for an r5 hash, when the number of files > 1 million the hash collision rate is so high that it is impossible to reliably create more files.
- for a tea hash, although file creation is roughly an order of magnitude slower than for r5, the collision rate can be dismissed.

Yes, ReiserFS makes no attempt at preventing hash collisions. This fact, along with the "no bad block testing" policy, has kept me using EXT3.

(And for whoever looks in my back posts and points out I use Windows, I do have a Linux server which uses EXT3 partly because of the hash collision problem but mostly because of the fact that ReiserFS has no provisions for working around bad blocks. Stupid Maxtor.)

On the ReiserFS 4 page you say that the new filesystem uses algorithms allowing the FS to do transactions only databases could do previously. Do you envision ReiserFS 4 being something comparable to MS' "SQL-FS" plans in Longhorn? How would ReiserFS 4 affect regular (oracle, postresql, mysql) database projects/companies?

Three reasons why ReiserFS is great for you:
ReiserFS has fast journaling, which means that you don't spend your life waiting for fsck every time your laptop battery dies, or the UPS for your mission critical server gets its batteries disconnected accidentally by the UPS company's service crew, or your kernel was not as ready for prime time as you hoped, or the silly thing decides you mounted it too many times today.

ReiserFS is based on fast balanced trees. Balanced trees are more robust in their performance, and are a more sophisticated algorithmic foundation for a filesystem. When we started our project, there was a consensus in the industry that balanced trees were too slow for filesystem usage patterns. We proved that if you just do them right they are better. We have fewer worst case performance scenarios than other filesystems and generally better overall performance. If you put 100,000 files in one directory, we think its fine; many other filesystems try to tell you that you are wrong to want to do it.

ReiserFS is more space efficient. If you write 100 byte files, we pack many of them into one block. Other filesystems put each of them into their own block. We don't have fixed space allocation for inodes. That saves 6% of your disk.

Ok, it's time to fess up. The interesting stuff is still in the future. Because they are nifty, we are going to add database and hypertext like features into the filesystem. Only by using balanced trees, with their effective handling of small files (database small fields, hypertext keywords), as our technical foundation can we hope to do this. That was our real motivation. As for performance, we may already be slightly better than the traditional filesystems (and substantially better than the journaling ones). But they have been tweaking for decades, while we have just got started. This means that over the next few years we are going to improve faster than they are.

Speaking more technically:
ReiserFS is a filesystem using a plug-in based object oriented variant on classical balanced tree algorithms. The results when compared to the ext2fs conventional block allocation based filesystem, running under the same operating system and employing the same buffering code, suggest that these algorithms are overall more efficient and every passing month are becoming yet more so. Loosely speaking, every month we find another performance cranny that needs work; we fix it. And every month we find some way of improving our overall general usage performance.

The improvement in small file space and time performance suggests that we may now revisit a common OS design assumption that one should aggregate small objects using layers above the filesystem layer. Being more effective at small files does not make us less effective for other files. This is truly a general purpose FS. Our overall traditional FS usage performance is high enough to establish that. ReiserFS has a commitment to opening up the FS design to contributions; we are now adding plug-ins so that you can create your own types of directories and files.

When will it be stable enough for early-adoption users?.
What kind of early adaptor are U any way ? asking questions about stability ?

"Reiser4 is due June 30, 2003!"

In your Future Vision white paper, last modified in January 2001, you outline several very interesting ideas about metadata.

Several developements have taken place since : the extensible attributes of BeFS has been burried with BeOS, the database-like metadata of Longhorn (aka Yukon) may actually be a separate layer from the filesystem altogether, and Apple is also moving all metadata out of the filesystem to XML files shared between applications (see iLife package).

My question : What is your current take on the metadata debate ? Do you still think the filesystem is the right place to handle metadata ? Any predictions ?

Now you just need to hire someone to desire a modern, more "commercially pleasing" website. =)

So imagine a Linux distribution with the future ReiserFS as the filesystem, and something like Haystack (rewritten in C) as the desktop, with a nice API...

Gnome and KDE have done a great job at catching up to the Microsoft desktop, maybe even improving it incrementally...but something like this would make Windows and OSX look as primitive as Win 3.0.

Newer FSes like reiserfs don't have this option anymore (last I checked anyway), so maybe they are more efficient about it. I've never seen any Linux docs make a similar claim, but I'd imagine that however it's implemented having a small amount of free space is also going to force higher block fragmentation.

ReiserFS performance will suffer when disk usage is greater than 85%.

From what I understand, ReiserFS 4 is supposed to have a SQL-like implementation of its filesystem. Would it bring Longhorn/BeOS functionality to Linux?

I'm not aware of any kind of unification of RDBMS and file system; do you have a reference or a link or a product name or anything?

I'm sorry, I looked into that and it turns out the guy who told me about that was talking about reiserfs, and I just misunderstood him. It might have some DB like features, but it doesn't look like the same thing at all. Still, a step towards that maybe.

Local Google on MyComputer will be the future. I'm convinced of it.

Given how much people's data has grown, I think Longhorn's SQL based filesystem is really an important development, one that will turn out to be incredibly useful.

I'd like to see something that could offer equivalent utility under Linux.

So I wonder how combinations such as ReiserFS and glimpse would or could fill this niche?

Afterall, they got vile things like the Internet rolling, and give gobs of money to horribly destructive and Big Brotherish projects like reiserfs v4.

It's too bad most Linux developers aren't interested in doing something really forward-thinking. If there was a DB integrated into the OS...

And DARPA is also funding Reiserfs v4 development.

-- kryps

I dunno like if an OS was built around perl and discuss how easy it would be to setup yer various unix jobs.

Or if every form of data on your computer was saved to XML instead of all the propietary file formats nowadays.

Just use Reiser4 in Linux and develop plugin (yes! filesystem plugin) with that functionality.

Or it can be done with Hurd's extensible FS translators.

Then make really small C library to interoperate with new open()/write() semantics. Or even make it into glibc.

Anyone can use new features then. No need to be tied to KDE libs or part of Gnome (if/when it's ported).

I was reading about Reiser4 last weekend and HR mentioned similar functionality IIRC. I would hope everyone can sees the point behind metadata...it's kinda the reason XML is considered a GOOD THING. The question is...can we shift our paradigms to use this newer model? Change is hard to effect...this would have to be adopted be a mainstream OS for this to really catch on and be widely used. (Asbestos uunderwear on!) Isn't Longhorn's new DB filesystem also supposed to offer some or aLL of this? (RTFA if you want to reply please!) MS might not be as behind the curve as we'd like to think....time will tell if this will actually be widely accepted. My .02.

I was reading about Reiser4 last weekend and HR mentioned similar functionality IIRC. I would hope everyone can sees the point behind metadata...it's kinda the reason XML is considered a GOOD THING. The question is...can we shift our paradigms to use this newer model? Change is hard to effect...this would have to be adopted be a mainstream OS for this to really catch on and be widely used. (Asbestos uunderwear on!) Isn't Longhorn's new DB filesystem also supposed to offer some or aLL of this? (RTFA if you want to reply please!) MS might not be as behind the curve as we'd like to think....time will tell if this will actually be widely accepted. My .02.

Object models are primarly good for boosting programmer productivity by reducing wheel reinvention, and by allowing you to use languages that are most appropriate for the task at hand. If you're writing a media player, C is not the best language to use. If you're writing a high performance codec, maybe it is. Object models that let you share code a la COM/.NET mean you don't have to choose langauges based on what code is already available to you in that language.

It makes me wonder.... Is this the same guy who thought all files should be arranged by association, instead of in a tree structure? That would just make things SLOPPY. I sure hope this Humane interface doesn't promote sloppiness!

Reiser's paper is very interesting, and IMO fits quite nicely with The Humane Environment's "no applications" paradigm. The focus then becomes the data (the stuff inside of documents), instead of the data access mechanism (applications manipulating documents.)

Yes, yes. I believe Hans Reiser has the much better idea though.

On a side note, I think that ultimately the ability to "search through PowerPoint documents" is a bit of a joke. Unix grep searches through all my documents just fine, because I've stayed with text all this time. Then came complicated formats such as PowerPoint, and we need new search tools. But in the future we will have encrypted and DRM-ed documents and we'll need new search tools again.

The computer he seem to describe would be able to pull up the information based on what you wanted based on a request, not on some method of searching for a file.

Or perhaps this can be rephrased. What are files, and how do you interact with them? This is what makes the Reiserfs filesystem so interesting. They are thinking about these kinds of issues in unconventional ways. Reiserfs is not just another journaling filesystem. Moreover, Hans Reiser is subjecting his ideas to the test of reality by producing tangeable testable results.

I mean, really, what was the last 'innovation' that occured in the *nix /world?

Jeez... are you serious? Come on, Unix is one of the more important platforms for research, if not the most important. It is flexible, it is reliable, most of the scientific community is familiar with it. And these days it is also free!

Just talking about Linux I could point you to Berlin, some guys with rather interesting ideas for building user interfaces. Or the Beowulf Project, for massive distributed computing. Or RTLinux (and KURT), for full featured real-time operating systems. How about ReiserFS, that takes database-like balanced trees to the filesystem level. Or SELinux, a research prototype of a high-security operating system.

And the list goes on and on (forgive me for not looking up links, go Google for these ones): SPIN (a dynamically extensible operating system written in Modula-3, runs on Linux), all the research stuff at Mosix (including distributed shared memory, grid management, network RAM and more), the Hello Project (an operating system in Standard ML atop Linux), all the emulation stuff which hardly needs to be introduced, and all the kernel work for supporting different processor architectures.

Also note BDS's Kame Project, an advanced implementation of IPV6 and IPSec; the evolutionary scheduler for Linux; the networking kernel stuff, including the QoS work; OpenBIOS; the User-mode Linux kernel. Look up also the "C10K problem" for an interesting paper on server performance, (and while you're on that, khttpd and TUX kernel webservers).

Unix gave you the Internet, for root's sake. How much more "innovative" does it needs to get?

Cooler, if I read the tea leaves right. I believe some time ago now there was a thread on lkml about whether it'd be possible to have files as also directories (and vice-versa). The reasoning behind this was simple: we want flexible filing system attributes, but not at the expense of API bloat. You want ACLs? That'll be another API then. Extended Attributes? Another API. What, you want heirarchical extended attributes too? Well you've just created another version of the filing system API haven't you.

The theory goes (and Hans Reiser, top guy, explains it much better than I can) that by altering one of the rules of the filing system, we can get lots more power and expressiveness without having to invent lots of new APIs. Let's say you want to find out the owner of file foo. You can just read /home/user/foo/owner. You can edit ACLs by doing similar operations. Now you can have something more powerful than extended attributes, but you can also manipulate that data using the standard command line tools too! Coupled with a more powerful version of locate, you can have very interesting searching and indexing facilities.

This has implications beyond just string attributes. Now throw in plugins, so for instance the FS layer interprets JPEGs and adds extra attributes. Now you can read the colour depth of an image by doing "cat photo.jpg/colour_depth" or whatever. You can get the raw, uncompressed version of the file by doing "cp photo.jpg/raw > photo.raw". Noticed something yet? You no longer need a new API for reading JPEG data, because you are reusing the filing system API.

But the FS is not a powerful enough concept, I hear you cry! Have no fear, for with new storage mechanisms comes new syntax too, to allow for BeFS style live queries. If you want more info, you should really read up on this stuff at Reisers site.

That's why ReiserFS is so good at small files as well as large files. Have you ever wondered why that is? It's not just a quirk of its design, it was very deliberate. One day, Hans wants to see us store as much information as possible in a souped up version of the filing system, so reducing interfaces and increasing interconnectedness. Or something. It sounds cool anyway :) That's one thing that RFS has that the other *FSs don't - the ReiserFS team has vision.

To me, the most critical thing in the Linux market right now is the lack of good software courses, books and software itself. Without good software and an owner who understands programming, a hobby computer is wasted. Will quality software be written for the Linux market?

Almost a year ago, Alan Cox and myself, expecting the linux market to expand, hired Marcelo Tosatti to maintain Linux 2.4. The the initial work took only two months, the three of us have spent most of our lives documenting, improving and adding features to Linux. Now we have reiserfs, ext3, a robust VM, UML, and the 2.5 development tree. The value of the computer time we have used exceeds $40,000,000.

The feedback we have gotten from the thousands of people who say they are using Linux has all been positive. Two surprising things are apparent, however, 1) Most of these "users" never bought Linux (less than 10% of all computer owners have bought Linux), and 2) The amount of royalties we have received from sales to hobbyists makes the time spent on GNU/Linux worth less than $2 an hour.

Why is this? As the majority of users must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?

Is this fair? One thing you don't do by stealing software is get back at Berkeley for some problem you may have had. Berkeley doesn't make money selling software. The royalty paid to us, the manual, the CD's and the overhead make it a break-even operation. One thing you do do is prevent good software from being written. Who can afford to do professional work for nothing? What hobbyist can put 10-man years into programming, finding all bugs, documenting his product and distribute for free? The fact is, no one besides us has invested a lot of money in Linux software. We have written 3 stable kernels, and are writing Linux-2.5, but there is very little incentive to make this software available to Linux users. Most directly, the thing you do is theft.

What about the guys who re-sell Linux, such as linuxmall.com, aren't they making money on hobby software? Yes, but those who have been reported to us may lose in the end. They are the ones who give
Linux users a bad name, and should be kicked out of any club meeting they show up at.

I would appreciate letters from any one who wants to pay up, or has a suggestion or comment. Just write to me at:

3940 Freedom Circle
Santa Clara, CA 95054 USA

Nothing would please me more than being able to hire ten programmers and deluge the Linux market with good software.

Linus Torvalds
Transmeta Corporation