Reiser On ReiserFS's Future And More

Steven Haryanto writes: "This one's from Indonesia. InfoLinux did an email interview with Hans Reiser, in which he explained about the ReiserFS project plan and the new Namesys business model. Mr. Reiser told me that Namesys recently received $600K funding from DARPA to include encryption in ReiserFS v4.0." Dig this quote: "We are going to add plugins in our next major version, and we hope that plugins will do for filesystems what they did for Photoshop." Mmmm -- encrypted, compressed, journaling, extensible filesystems. Reiser also touches on issues of international software development and how programmers can achieve fame.

Comments

Re:Plugins do the same as for photoshop?

[Anonymous Coward]

I dunno, wouldn't you want glowing, beveled, drop shadowed files?

Re:encrypted, compressed, journaling....

[Anonymous Coward]

Maybe you should ask some NT-admin that (but NT-admins are all stupid... haha). Journaling, compression and encryption have been standard features of NTFS for a long time.

Hint: not everything needs to be compressed / encrypted.

Re:ReiserFS for Mac OS X?

[Anonymous Coward]

Hans always has one response to any suggestion: Show me the money !. Hans will port to any platform if you can negotiate a contract. That's why ReiserFS is so successful. It is a business, a profession. It is not a hobby.

I thought "crypto with a hole" was illegal?

[Anonymous Coward]

I thought "crypto with a hole" was illegal? That US law treats software with easy add crypto hooks to be equivalent to full cryptographic software and subject to all the same export restrictions? Has this changed? Or will we no longer be seeing ReiserFS in the pre-packaged Linux distros or ISO images?

Re:I thought "crypto with a hole" was illegal?

[Forge]

RiserFS should fall under export restrictions since technically it's imported from Russia and other places. That's where most of Riser's staff works.
--
Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.

Re:I thought "crypto with a hole" was illegal?

[scrytch]

> The export restrictions on cryptography have been lifted.

They've been "eased", "suspended", or whatever. Just another capricious fascist executive order away from going back in. Mark my words, they'll put it back someday and make an example out of whomever is politically inconvenient at the time.

--

Re:I thought "crypto with a hole" was illegal?

[Tungz10]

The export restrictions on cryptography have been lifted.

Re:I thought "crypto with a hole" was illegal?

[El Prebso]

Who really cares what the US laws says???

Correct URL

[Anonymous Coward]

White paper URL from the article seems wrong.

http://www.namesys.com/whitepaper.html is much better.

Cheers,

--fred

Re:ROTFL!

[Ranger Rick]

Don't even get me started. After looking at how their RPMs are built, it's a wonder SuSE runs at all. Half of the ones I looked at *can't* be built as anyone but root. So if they miss a file, there's no way of knowing during QA, because "it works for me". Making spec files without a BuildRoot is like going whoring without a condom. You may get out ok, but most likely you just got screwed.

We supported SuSE in our previous release of our software where I work, but I've given up after spending almost a day trying to coax their system into compliance, when I can build 20 meg of code on RedHat 6.x and 7.x, mandrake 7.2 and 8.0 in 2 hours from a single spec file.

Solaris Journaled UFS?

[emil]

The most famous example of a file system that grew into journaling was Solaris UFS. I have heard some rather harsh criticism (from SGI) on the design. I don't know enough about filesystem design to discuss the merits, but I do know that Sun was the number one US server vendor last year, so they must be doing something right.

Here is the man-page entry:

logging | nologging

If logging is specified, then logging is enabled for the duration of the mounted file system. Logging is the process of storing transactions (changes that make up a complete UFS operation) in a log before the transactions are applied to the file system. Once a transaction is stored, the transaction can be applied to the file system later. This prevents file systems from becoming inconsistent, therefore eliminating the need to run fsck. And, because fsck can be bypassed, logging reduces the time required to reboot a system if it crashes, or after an unclean halt. The default behavior is nologging.

The log is allocated from free blocks on the file system, and is sized approxima tely 1 Mbyte per 1 Gbyte of file system, up to a maximum of 64 Mbytes. Logging can be enabled on any UFS, including root (/). The log created by UFS logging is continu- ally flushed as it fills up. The log is totally flushed when the file system is unmounted or as a result of the lockfs -f command.

Re:Solaris Journaled UFS?

[Salamander]

The most famous example of a file system that grew into journaling was Solaris UFS

Perhaps I wasn't clear enough. I wasn't saying that you couldn't add journaling to an existing filesystem. What I was saying was that you couldn't add it *as a plugin*, i.e. by leaving the original code untouched and adding a separate journaling facility. You have to change the original code, at least to the point of making it "journal-friendly".

UFS is a good example of this. They implemented a mostly-separate logging component called ufs_log, but the original code is still littered with flag checks and callouts to use it. It could probably be more modular than it is, which might be the source of SGI's criticism, but it could never be so modular as to be a plugin.

Re:Like Frank Xia ...

[Forge]

Or his uncle, Chow Yun Fat. Author of the original FAT file syustem.
--
Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.

Mmmm... CPU cycles

[Lally Singh]

Mmmm -- encrypted, compressed, journaling, extensible filesystems.

May ask for a moment of silence for the CPU? First IDE, now CPU heavy filesystems? Also, one of my first questions is, how do you compress a filesystem without having problems with either:

• Making seeks tough to calculate, or worse, requiring many disk accesses to get the right address
• Performance problems with things like writes in the middle of the file, causing the dictionary for that part of the file to overfill and the whole portion of the file to need recompression

Perhaps I'm just not up on the latest compression techniques (most likely), but those questions just popped in my head.

Either way, this is just further down the road of increasing CPU requirements just to drive the friggin disk. Ick. I miss SCSI.

--

Re:Mmmm... CPU cycles

[otis wildflower]

May ask for a moment of silence for the CPU? First IDE, now CPU heavy filesystems?

I have recently built a firewall server with 2 ATA33 drives mirroring each other via md raid1 (all reiser except /boot) at boot. Getting it to work (chicken + eggery abounding :p) was a challenge, but be that as it may, I'm so far pretty happy with it. I have used linuxrouter in the past and I gotta admit, I like having all my utils on the fw box. It only runs opensshv2, syslog client and kernel stuff, so hopefully it will be relatively hard to r00t.

This firewall box has 256MB PC133 RAM and a Duron 750. This is probably about 4x more RAM and 6x more CPU than necessary.

For server situations, CPU is so cheap that I believe you should pile on as many options as possible, as long as they're optional. modular plugin filesystem functionality is really really cool, and if I can plugin a steganographic encryption system (or choose to build it in statically as long as its presence is 'masked' somehow ;) that would IMHO be very very rock.

Your Working Boy,
- Otis (GAIM: OtisWild)

Re:Mmmm... CPU cycles

[otis wildflower]

Nevertheless, with the cheapness of hdd's these days (they practically give away 40gb drives) filesystem compression is rather useless.

Still, I'd like to see compressed ISO mounting via loopback...

# mount -o ro,loop,compressed ./cdrom.iso.gz /path/to/cdrom/mount

Your Working Boy,
- Otis (GAIM: OtisWild)

Re:Mmmm... CPU cycles

[hansreiser]

I like your post. I'll just add that a slightly better way than compressing on file close is to compress on commiting the journal transaction containing the data.

Re:Mmmm... CPU cycles

[DiSKiLLeR]

Well, no, see thats different.

Thats a "compressed volume", or "partition", or "drive".

On NTFS, (and as ReiserFS intends on doing it i believe), you compress on a file by file basis.

On NT, you right click on a file -> properties -> and you have your usual attributes, "system", "hidden", "read only", "archive", and a new one, "compressed".

Check compressed, hit okay, and that file is now stored compressed.

The volume, ie. partition/disk is NOT compressed, the NTFS filesystem is still normal as always, but if the compressed attribute is enabled on a file, it is stored compressed; other files are not.

Of course, you can enabled "compressed" on a dir, and it will ask you if you want to recursively compress all other files. (yes or no). Any new files put into that dir will be compressed on default.

Basically, this is alot different to the old doublespace/drive space technique.

It also lets you see wierd things; right click on a 10kb file, and it will say "file size: 10kb", "size on disk: 12kb". Okay, that makes sense. That 10kb file has been allocated 3x 4kb "clusters" or "allocation units". 2kb of the last cluster is wasted.

Compress it, and it will say, "file size: 10kb", "size on disk: 8kb".

Nifty.

Personally, i prefer this method of compression. You can compress your text/documents directory, but not your mp3s/jpegs/etc which won't compress at all.

Its quite nice, and i'd love to see ReiserFS (and others, ext3fs? UFS) support it.

I suppose you'd use the 'chflags' command (FreeBSD has that, i believe linux has something equievalant for ext2fs flags) to set the 'compressed' flag on a file/dir.

D.

Re:Mmmm... CPU cycles

[DiSKiLLeR]

Hrm...

Dunno. NTFS Is a journalling filesystem and has had compression and encryption for years. Compression has been in NTFS for at least 6 years, perhaps quite a lot longer. (dunno if NT 3.51 had NTFS compression).

I've found it works *great* and has no real performace impacts. (apart from serious fragmentation if you go and compress your whole drive at once. When that happens, just do a big defrag.)

Nevertheless, with the cheapness of hdd's these days (they practically give away 40gb drives) filesystem compression is rather useless.

I also see your points, how do seek()'s and things work? I dunno.

D.

Re:Mmmm... CPU cycles

[ChadN]

You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.

And since compression is deterministic, compressing wil do absolutely NOTHING to protect against a ciphertext-only attack, except reduce (slightly) the effectiveness of a "birthday attack". A 128-bit block cipher (such as AES) should be perfectly immune to such attacks. Ie. compression does NOT enhance security of the ciphertext, in any appreciable way, using a modern (ie. non-DES) cipher.

Re:Mmmm... CPU cycles

[chill]

Well, you could always use a translation layer like BIOS does with big hard drives to convert CHS, LBA and all that.

Disk compression has been around since the good old days of DOS 3.21 with the likes of Stacker, DoubleSpace and a few others. (Possibly much sooner, but those are what I can remember off the top of my head.) The algorithms are probably all worked out and on file somewhere.

Disk/file/drive compression was real big until Microsoft included the function in an OS upgrade.

--
Charles E. Hill

Re:Mmmm... CPU cycles

[drsmithy]

Stacker was out *long* before DOS 5.0. Earliest I can remember using it was with DOS 3.3 (and an ISA compression coprocessor card !).

Re:Mmmm... CPU cycles

[rgmoore]

IMO, the real solution to this "problem" is to use intelligence in choosing how you use your file systems. If you are in an environment where performance is hyper-critical and you need to have rapid, accurate seeks, you just don't use a compressed file system. You only use it for file systems where that's not likely to be a problem. The whole advantage of a pluggable architecture is supposed to be that the various attributes like compression, encryption, etc. are optional, after all.

Of course there's also some question about the practical utility of compressed file systems these days. In practice, we're already using compressed file systems by using compressed file formats of various types. The big files that are going to use up all of the hard drive space for desktop-class users are things like pictures, music, video clips, etc. But those files are already compressed using JPEG, MP3, MPEG, etc., so a compressed file system isn't really going to buy you a whole lot anyway. Doing things that way also has the huge advantage that you can use highly optimized compression algorithms for each different class of data, rather than a generic one that won't work as well. People working on larger, more powerful systems are less likely to be willing to pay the performance hit for compression.

Re:Mmmm... CPU cycles

[peccary]

A few more thoughts:

CPUs cycles are getting cheaper than I/O and memory bandwidth, but this kind of thing makes it hard to do DMA.

Random access to files is not particularly helped by using the "latest compression techniques", it's more a matter of how you design the filesystem.

You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.

Most files are not accessed randomly, and of those that are, most of the file is eventually accessed even if it is done non-sequentially.

Most random accesses occur on pagesize boundaries. Even if you are accessing one single byte in the middle of the page, modern VM-integrated buffer caches will fetch the whole page to do it. So what you need is not the ability to seek to any random point in the middle of the file, but just to any page boundary. Much simpler. You can store tables of these things.

If you write to the middle of the file and blow the compressibility of the data, then you punch out the page and relocate it on the disk. Sequential contiguity suffers, but heck, you weren't accessing this file sequentially anyway, so why are you complaining?

Re:Mmmm... CPU cycles

[rabtech]

Microsoft solved these problems by splitting all compressed files into 64k chunks -- the compression is done, one 64k chunk at a time. When a file is read, it is decompressed. If only part of a file is written back to disk, a chunk is compressed. If it is too large to fit in the space previously occupied, it just finds a space on the volume large enough (estimated) to hold the rest of the file, and stores that chunk there. If one chunk must be relocated, it starts relocating all the rest of the chunks (two file fragments are better than 10.)

Novell takes the scheduled approach -- files are always written uncompressed. Later, at a specified time, the system looks for "compressable" files and compresses them. In this way, only decompression is performed on the fly.
-------
-- russ

"You want people to think logically? ACK! Turn in your UID, you traitor!"

Re:Mmmm... CPU cycles

[Hater's Leaving, The]

Stacker came out at the same time as DOS 5.0. It was in DR-DOS 6, IIRC. MS after trying to steal the idea and having their wrists slapped, put the inferior TroubleSpace into DOS 6.02 IIRC.

The idea itself is ancient.
Helsinki University were looking into these things in the 70s (so an old Finnish mate tells me), and the common algorithms now used, LS{77,78,SS,W,several others} were developed with this precisely application in mind. (and slow comms links too)), also date from the 70s (77, and 78 are a dead give-away).

THL.

--

Re:Mmmm... CPU cycles

[Hater's Leaving, The]

Blimney, the cobwebs were building up.
I remeber the first version of Stacker that anyone said was stable was at the time of DOS 5.0, and it was _Stacker 2_, I think. Remembering that MS-DOS 4 was almost a non-event, that does probably put the _original_ stacker at DOS 3.3 times.
I stand corrected.

Sorry,
THL.
--

Re:Mmmm... CPU cycles

[Hater's Leaving, The]

Thank you. I was puting the journalling spects aside, as the two techniques are independent.
In a Journalling FS such as yours, the word 'close' as I used it can be wishy-washy, because there are two different data streams involved, the 'control' (journaling info), and the 'data' (file contents), which take different routes to the hard disk. One could define 'closure' to be the termination of the transaction sequence between the OS and the disk rather than the terminiation of the transaction sequence between the app and the OS.

THL.

--

Re:Mmmm... CPU cycles

[Hater's Leaving, The]

Very good post. You ask all the right questions.

Compressed FSs have always had this problem. The best solution that people have comeup with is one that we have already implemented - caches.

In particular, the hairy writing to disk stage (where the compressions and on-the-fly construction of dictionary etc. takes place) only needs to be done on file closure.

For some files, such as those that are frequently opened for writing, it's perfectly possible to have backgrounded compression. Basically you don't compress the file until a later point in time, you store it uncompressed on the hard disk and mark it as such. It's a seperate house-keeping job to actually compress the files (when they are 'stable' for some heuristically defined stability function (e.g. closed >10 seconds ago, or yesterday, or whatever))

Another helpful technique is to chunk the files, so that you only ever have to seek from the nearest chunk boundary. This simply shrinks the amount of data that suffers from the seek problem, and often (though _not_ always) reduces the compression ratio. (e.g. a large executable could possibly be made smaller, as the code and initialised data could end up in different chunks, and the compression model could only need to adapt to one type of data.)

Note, however, that we are not talking about _a_ compression plug-in. We are talking about compression _plug-ins_ (i.e. plural). You can chose your plug-in depending on the requirements.
e.g. A FS for infrequent writes and frequent whole-file reads, such as a document management server, and could use a 'slow' compression, fast decompression, no-seek algorithm.

From purely personal opinion, I believe with current HD transfer rates giving the CPU the decompression task is a better than reading bigger files. However, I'd not swear to that until I've played around with it and tested it thoroughly, with all my favourite file types. (I tend to have 500MB highly-compressible log files from what I do, so this really pushed my buttons!)

I do go on sometimes...
THL.
--

Re:Standards, limits of extension interfaces

[stripes]

So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster ... however much faster is unknown, since this is totally untested.

I don't see how it is x86 specific. It is specific to CPUs that use caches, which is pretty much all non-embedded CPUs, and many of the embedded ones. I would imagine this would not be faster on something like the Terra, which is a non-cached CPU, but since it relies on proper management of 1000s of hardware level threads, I don't think Linux is ready to run there at all. Even on those systems it should be faster then indirecting through a pointer, faster by exactly one memory access (the pointer).

I do agree that it is untested (in terms of benchmarking). I don't think it has entirely wrecked extensibility. One needs to modify that file to add a filesystem, so you can't do it through a run-time loaded module...unless you use the generic void*.

I'll go for "that is really really ugly", and maybe even "does that make a noticeable difference when you are probably going to schedule a disk I/O?", and even "I'm glad FreeBSD doesn't do that". There is no way I'll buy "it's x86 specific" though.

Re:Standards, limits of extension interfaces

[LunaticLeo]

I think I gave up on the idea that Linux would ever know what it was doing with filesystems when I saw this abomination . That's right, Linux not only has no concept of vnodes, it actually uses a union of every single filesystem type for its inode data structure. Search lxr for "vnode" if you don't believe me. So much for generic, to say nothing of modular.

This has been discussed on the LKML. Using a Union for all the various FS specific inode info is a performance hack. You could have a pointer there to a FS specific inode, but you are going to lose memory locality benefits, and cause cache line thrashing. Inodes are touch OFTEN, that makes thes memory issues important.

Further this is a performance hack that takes advantage of the fact that the Linux Kernel is open source, and easily compiled. You can't get this advantage in closed source without arbitrary FS specific inode info size limits.

But, you are right there is an ugliness to it, but don't make the mistake that Linux Kernel developers are idiots or poor coders. This has been considered.

Remember the truism: The Perfect is the enemy of the Good.

ROTFL!

[m2]

What can I say, except buy SuSE. It is better in more than just the filesystem in a whole lot of ways, and you get far more software that has been far better tested before release. I mean, just think "gcc". I don't understand why people don't go with a distro that has a QA before shipping based process. Unfortunately herd instinct rules.

ROTFLMAOL! Good one, Hans, good one. You just lightened my day with that joke. I mean, it's a joke... isn't it? QA for SuSE means "the booklet has pretty colors and one or two really stupid and annoying jokes". Before I moved I hoped to find people who actually could tell a technically solid product appart from a big budget marketing department. *sigh* Then I thought "ok, I'll give this a try, it can't be that bad". I withstanded a little over 14 months of it. Then I broke. SuSE is invasive. "What? You are the sysadmin here? Yeah, right!" Their entire approach to the distribution is painfully invasive. It's their way or the highway (sorry, couldn't resist -- but it still applies). Most of the time that thing called SuSEconfig will respect the changes you have made to config files, but the problem is, most of the time just doesn't cut it. I could just quit using it, but it's not an option if other people "help along" with the adminning, because they like not having to use that horrible program called vi (or any other editor that doesn't have buttons for that matter). In fact, the day I broke was because SuSE decided Magic-SysRq is an spawn of the devil... that spiced up with the horrible (non-existant) upgrade paths they have, which I'm sure their QA department have tested and have made sure it works...

Re:ROTFL!

[jovlinger]

the pedant notes that when going whoring, getting screwed and getting out ok are not mutually exclusive.

Modular Plugins != plugin modules.

[TBone]

Just because something is modular in the kernel doesn't mean it can only be a module. The only case that this exists, AFAIK, is the protocol-specific masquerading modules.

Maybe against the current recommendations, anything that I don't have to load as a module (my AWE32 and Masq mods) gets compiled into the kernel. Why? Because it's not like I won't need the features - that's why I selected them for compile in the first place.

If you encrypt all of your main filesystems, then you'll just have a /boot partition with vmlinuz on it, and the encrypted filesystem mods already loaded. Load the kernel, find the encrypted root, and *Bam* there's your newly-readable filesystem. This isnt' rocket science.

Ooops...

[Psiren]

What if you did something silly like placing your filesystem encryption module on your encrypted filesystem... Get outta that one Houdini ;)

Re:Ooops...

[Archie Binnie]

I just pray we don't get a Gaussian Blur plug-in, I like my data as it is.

Re:Ooops...

[being john]

yeah, that's a bit of a problem
---

Re:Ooops...

[dasunt]

Off topic, but you reminded me of a bug I once saw on a page of "most interesting bugs" in an older version of multics. It seems that the entire OS was swappable, and in one version, the swapper-out module could swap out the swapper-in module...

Re:SQL crippling?

[hansreiser]

You are right that I should say, the failure to redesign SQL from scratch every 5 years has been crippling the database industry, not SQL has been crippling the database industry. SQL was great in its time. It has lasted too long.

What I would replace it with is described at www.namesys.com

Re:encrypted, compressed, journaling....

[jimhill]

(Wavy flashback lines)

I remember when the Linux kernel introduced modules and in the race to out-module one another, a lot of newbies rebuilt their kernels with every single filesystem as a module. Ahh, those were the days...

Re:Standards, limits of extension interfaces

[scrytch]

> Stackable vnodes, which are supposed to address this same need, are ancient history

I think I gave up on the idea that Linux would ever know what it was doing with filesystems when I saw this abomination. That's right, Linux not only has no concept of vnodes, it actually uses a union of every single filesystem type for its inode data structure. Search lxr for "vnode" if you don't believe me. So much for generic, to say nothing of modular.
--

Re:Standards, limits of extension interfaces

[scrytch]

> This has been discussed on the LKML. Using a Union for all the various FS specific inode info is a performance hack

So, they basically wrecked the extensibility of the architecture so a completely theoretical untested performance hack for the x86 architecture *might* go faster ... however much faster is unknown, since this is totally untested.

As for that truism, here's another: penny wise, pound foolish.
--

Re:First things first...

[Delphis]

Other stories I'm sure I heard a while ago was that Hans Reiser was a complete asshole to work with, or so the Linux kernel mailing list had it. Anyone remember anything about that?

I'd hate to have ResierFS installed all over the place and then this prick demands royalties or something 'a la Unisys'.

--
Delphis

Re:great news, xfs

[Outland Traveller]

Not to start a filesystem war, but my experience with XFS on linux has been very positive. The install .iso is *polished*. The fs tools are plentiful and high quality. Performance is excellent. If XFS on MIPS is any guide, reliability is top notch too.

I'm glad to see ReiserFS aggressively pushing the technology envelope, but I have nothing but good things to say about XFS, and would recommend it to anyone using a recent kernel who wants a robust journaling filesystem.

As others have said I think there is room for both filesystems going forward.

"Reiser On ReiserFS's"

[Orlando]

Ah, so THAT's what Mutley's been saying all this time.

Re:They actually make money....

[ethereal]

I hate to tell you, but I'm pretty sure Hans Reiser is male. The hint was when the interviewer called him "Mr. Reiser".

Caution: contents may be quarrelsome and meticulous!

Re:I'm pretty sure Hans Reiser is male.

[ethereal]

True, I've never met the guy. He could be one of those androgynous anime-looking men. (today on "It's Pat" - Pat talks about Free Software with Hans Reiser.) But judging from his flame potential on the lkml, I still would have guessed male :).

Caution: contents may be quarrelsome and meticulous!

Re:Photoshop plugins?

[sammy baby]

"Lens flare" - does nothing useful, but hey, you can't be a l33T web designer without it.

Re:stability??

[Ilmari]

Viruses planted in plug-ins would be too easy to implement and distribute.

Bullshit. The plugin version would (presumably, that's the general rule for kernel modules) have to match your kernel version, and you have to be root to load the modules, and I assume you'd have to explicitly enable the functionality of the plugin for individual filesystems.

So, if you run any untrusted code as root, let alone an untrusted kernel module, you deserve any shit that's going to hit the fan.

--

Re:SQL crippling?

[leandrod]

Don't throw away the baby with the water. The limitations of SQL are due to it not supporting the full relational model, and to its arbitrary limitations.

We need a properly implemented relational database language -- probably based on Chris J Date's and Hugh Darwen's The Third Manifesto.

Going for any hierarchical model, be it an OODBMS or a filesystem based one, is forfeiting all the relational model advantages because you find SQL, which isn't really relational, lacking... and you get nothing that any proper D wouldn't offer.

--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin

Re:SQL crippling?

[leandrod]

SQL is crippling because it doesn't implements the full relational model, as you can read in DBDebunk.
--
Leandro Guimarães Faria Corsetti Dutra
DBA, SysAdmin

Re:Plugins do the same as for photoshop?

[Levine]

How many plugins have you seen that fail (crash or fail to complete the operation) when you try them on a large image?

Erm. None, really. Based on the architecture of the file system, I think plugins would be an interesting and, most importantly, plausible concept.

No one wants to take a risk of widespread data corruption or data loss.

You've obviously never seen the Linux zealots running the -dev releases of Debian. Sheesh! Talk about trashing a system sometimes... ;)

Cheers,

levine

Plugins?

[Webmonger]

I suppose you could make "zipmagic for linux" (letting you treat .tar.gz files as directories). What else could you do?

Re:Plugins?

[sketerpot]

I suppose you could make "zipmagic for linux" (letting you treat .tar.gz files as directories). What else could you do?

You could add support for other compressed file formats, you could have gzipped files in a tarball so you wouldn't have to decompress the whole directory, you could add RCS and CVS support, changelogs, all sorts of things. If the plugins were open source, until they were stable, the only people who would use them would be the adventurous ones and people who can fix the bugs, so I don't think they would have a stability problem. Apache doesn't. Sendmail doesn't. Ext2fs doesn't.

Re:Plugins do the same as for photoshop?

[asland]

I imagine the fact that doublespace was bugfree (I don't agree with that, but lets just assume it is/was) proves that all filesystem affecting plugins will be.

It's even easier than that...

[GauteL]

.. to make the same kind of mistake.

I once in my very newbie-days made /etc a partition of its own.
Too bad I needed /etc/fstab to mount /etc.

Re:It's even easier than that...

[jfunk]

How about the time I accidentally did 'rpm -e rpm'?

I find it very strange that nothing appears to depend on RPM in RedHat...

Re:It's even easier than that...

[jovlinger]

I tried to manually upgrade libc (or whatever). So I rm-ed the symlink, and then tried to ln -s to the upgraded .x library. Unfortunately, ln (and a whole slew of other commands) are dynamically linked...

That one took some juggling to solve. I now have a staticically linked ldconf.

http://www.reiserfs.com/whitepaper.html

[VP]

Wow!

Don't miss reading Reiser's vision of the future - if they can pull all this off, it will truly change the way computers are used.

Standards, limits of extension interfaces

[Salamander]

I really hope that when Hans and Co. think about how to extend filesystems they'll put their weight behind some generic facility and not just pull some new ReiserFS-specific interface out of their collective ass. Stackable vnodes, which are supposed to address this same need, are ancient history. NT has had filter drivers - not just for filesystems but for just about anything - since day one, and they have proven invaluable as a way to implement new functionality without writing a whole new filesystem. Erez Zadok has done some really cool work on a system called FIST for this sort of thing. All of these should serve as sources of inspiration at the very least, and of code in some cases.

On a different note, journaling is not really something that can be added as a plugin, extension, or filter. Even if you have a generic journaling interface or layer separate from the "core" filesystem code, you have to make sure that that core code is "journaling-friendly". This involves thinking about ordering and atomicity, plus callouts and hooks between the main FS and the journaling code. It's pretty pervasive, and not something that can be done "stealthily" by adding a plugin or filter to a filesystem that was never designed (or, as in ext3, redesigned) with journaling in mind. Encryption, compression, virtual namespaces, all sorts of other things can be added as plugins or filters, but not journaling.

Re:Like Frank Xia ...

[SpinyNorman]

Don't forget the inventor of the modern toilet - Thomas Crapper (I kid you not!).

Re:Like Frank Xia ...

[SpinyNorman]

Interesting... it also says that the word "crap" predates Mr. Crapper anyway.

Disregarding the facts, I imagine the toilet was in fact invented by the famous Japanese sanitation engineer Dr. Takhira Shita.

Other fine, albeit fabricated, news stories are available here:

http://www.denounce.com/

Re:First things first...

[SpinyNorman]

I've had my /usr and /home partitions on ReiserFS for a long time, and had zero trouble with them (Mandrake 7.1 came with ReiserFS integrated into the 2.2 kernel).

Re:stability??

[chill]

re: Viruses in plug-ins -- No more or less so than kernel modules.

re: Third-party bad code -- Then don't use it until it is tested stable by a third party. Back up your data. Don't run beta code on production systems. Etc.


--
Charles E. Hill

File system plugins

[bored]

The idea of 'plug-ins' for file systems isn't new. Its new to Linux, because Linux has a very messy driver model, due to Linus's early insistence on monolithic kernels. Lots of other OS's support this idea, most are designed from the start to support this. The evil NT/2k from M$ has the ability to add 'filter' drivers to all the devices in the system. The result is that in NT/2k you can write your encryption/compression filter and it will just work on top of any file system running on the OS.

nitpick time

[Digital_Fiend]

"We are going to add plugins in our next major version, and we hope that plugins will do for filesystems what they did for Photoshop." Err, photoshop plugins lead people to rely on clicking buttons instead of actually making stuff. Photoshop plugins were one of the worst things to happen to the Internet in the last 5 years. :) Hundreds of thousands of "gee, isn't render difference clouds cool" pages. Other than that though, seems neat.

Re:nitpick time

[Zone5]

Ah yes, the tried-and-true "don't make it easy - then nobody will do things the true artiste way that I do, and everything go to crap" argument. For anyone who hasn't been paying attention, it's not making things easier for the average person which has made the internet turn to crap... it's letting the average person use the internet at all. Once you give someone a voice, you have to accept that you may occasionally get to listen to whatever crap or drivel they choose to spew out, with or without difference clouds plastered all over it.

Re:nitpick time

[UberLame]

So, how do you add interesting texture to you compositions? I admit that I use difference clouds a fair amount (and just plain noises sometimes to), but I don't really know of a better way at this time. Perhaps if there was a way to apply a function to the image, and one of the presets was just plain noise, and another was render difference clouds, I could learn to do my own thing. But, till then...

Re:nitpick time

[MwtrV]

He is simply stating that it will make ReiserFS *expandable* like plugins did for photoshop. He is not really concerned with the specifics of the program he is citing as an example. There is nothing to nitpick over because yes, anyone can write bad plugins for whatever program allows them.

Re:nitpick time

[mod you later]

two points:

1. photoshop plugins are abused more than used - how sick do you feel when you see that lens flare in a logo, product case, cd cover?
2. it doesn't apply here - having partitions that are in a similar format or work exactly the same as each other is a positive point as far as compatibility goes

i was angry:1 with:2 my:4 friend - i told:3 4 wrath:5, 4 5 did end.

Different model

[wiredog]

The model of Red Hat, Caldera, et. al. isn't selling software. It's selling support. Many years ago (15-20) Jerry Pournelle, writing in Byte, said that in the future (today) money wouldn't be made from selling software, it would be made by selling support and documentation. Certainly there are many companies that already make money from all or part of this model. They also provide support for open source developement.

DARPA

[wiredog]

$600K funding from DARPA to include encryption

Nice to see that DARPA (the Defense Advanced Research Projects Agency) is still funding useful things like this. Remember that they funded the internet when it first started. They're usually up to something interesting.

Re:DARPA

[Laplace]

Welcome to DARPA, where Research is our middle name.

Re:DARPA

[lastninja]

One of my tutors once told me that if you want funding for some exotic, crazy or strange research and no one was willing to provide it for you, you could always contact DARPA because they don't want anyone to do research on strange new things that they can't check up on. (understandable really considering that the US is targetted by terrorist from all sorts of crazy countries).

SQL crippling?

[davidsheckler]

Hans said:
"SQL has been crippling the database industry for decades"

I'll admit it's not the best syntax to manipulate
a database but before SQL there was no uniformity
in database access. At least you don't have to
learn a new "language" for each database you
maintain/access. I don't see how it's crippling.

I am curious about any solution he would propose.

Re:SQL crippling?

[SuiteSisterMary]

The good thing about SQL, as you point out, is that it's a common language that can be applied to any database. The bad thing about SQL is that, as you point out, it's a common languate that can be applied to any database, and therefore, as soon as your database wants to do anything that SQL doesn't already cover, you need to start creating extentions, and suddenly it's no longer cross-product.

Re:SQL crippling?

[Lozzer]

try Database Debunkings for some views of the limitations of SQL.

Re:encrypted, compressed, journaling....

[ghoti]

Yes haha very funny ;-)

But seriously, I can't see why a filesystem plugin couldn't be statically compiled into the kernel. It's still a plugin from the point of view of the file system, but during its initialization, it registers with the fs and then can be used like any other part of the kernel. I don't know if this is the way they are going to do it, but it would be possible.

Re:RTWP

[StrawberryFrog]

> he proposes a hierarchical model that fits to data rather than fitting the data to the model

Ah yes, hierarchical databases ... the ones that relational databases obsoleted.

LinuxTag

[mindriot]

Hans Reiser is also going to speak at LinuxTag 2001 in Stuttgart, Germany. From the LinuxTag website:

What new features are planned for V4? Dancing trees to replace balanced trees, plugins, item handlers, ACLs, extents, a repacker, and more. Hans Reiser will discuss these plans with the audience, and get user feedback on them.

Is it even legal for DARPA to fund GPLed code?

[Brett Glass]

As I recall, Federal law states that work created by or for the US government is not covered by copyright. Therefore, the code would not be able to be GPLed, because the GPL requires a copyright!

GPLing the code is also bad policy because people should be able to use technology that's developed with their tax dollars for any purpose. The GPL prevents enterprising programmers from using the code in their own products and making money from those products. It therefore seems to me that DARPA should either NOT fund such a project or insist that the code that is generated be placed in the public domain -- or at least licensed under the BSD License or the MIT license. After all, it's our tax dollars.... None of us should be denied the use of the code.

--Brett Glass

Re:undo plugin would be handy

[eu4ik]

Yes, but what about the unlink system call? rm is just the most common way to invoke it, not the only way. I see this problem all the time in Windows; Explorer is about the only app that places files in the Recycle bin, so files deleted by other apps are unrecoverable. Not good. At least under Windows there's a system call to move a file to the Recycle bin, so a properly coded app can do what a naive user would expect. I'm not about to recode all my POSIX apps to use "system(rm...)" instead of unlink().

Re:Plugins do the same as for photoshop?

[stilwebm]

You've obviously never seen the Linux zealots running the -dev releases of Debian. Sheesh! Talk about trashing a system sometimes... ;)

I thought about mentioning the bleeding edge types. But they are so used to bugs, they don't mind them. =)

Re:Plugins do the same as for photoshop?

[stilwebm]

Yes, the crashing of the plugins is because of bad programming. Exactly my point.

Plugins do the same as for photoshop?

[stilwebm]

While the plugins for Photoshop are great and very powerful, there is one problem. How many plugins have you seen that fail (crash or fail to complete the operation) when you try them on a large image? I think it will be very hard for enough high quality, stable, trustworthy plugins to be available. I'm sure compression, encryption, and a few other basics will be great. But will they do the same as for Photoshop? I doubt it. No one wants to take a risk of widespread data corruption or data loss.

Re:Plugins do the same as for photoshop?

[TheAJofOZ]

I'm not sure why this is big news. As I look through the Darwin source code, I notice a directory called "vfs". Basically, it's a layered file system that allows you to add any number of "feature layers" that encrypt data, translate file names, compress data or whatever. Basically, it's a plug in architecture.

VFS seems to be more flexible than the plug in architecture planned for ReiserFS since it gives you the ability to override any call to the file system.

It's worth noting too that I don't know where VFS came from, it may not have been an Apple invention in Darwin but I don't see it in the NetBSD source code, so maybe it is.

Re:Plugins do the same as for photoshop?

[n0-0p]

Actually, you may never have had problems but the version of Doublespace released with DOS 6.2 used faulty compression code. Hence the release of DOS 6.22 with Drivespace at no upgrade cost (MS wasn't even going to try to charge for that one).

Re:Plugins do the same as for photoshop?

[YeeHaW_Jelte]

Remember doublespace for DOS? Never really had data loss with that, and it was an pretty effective tool. Photoshop plugins aren't exactly critical in use, and the crashing of them is probably due to bad programming on account of that.

---
Living is a way of life ...

So ReiserFS becomes a VFS?

[Otis_INF]

Perhaps I don't understand it, as far as I see it, ReiserFS will become a kind of Virtual FileSystem, hosting the actual filesystem units? Or are the 'plugins' add-ons that are not affecting the actual layout of the filesystem on disk?
--

Re:stability??

[El Prebso]

So what the difference betwen ReiserFS an the Linux kernels module feature???

You donøt see these kind of problems with the kernel, so why whould you in a filesystem

Re:Get ready for the RDF?

[El Prebso]

Damn that's funny :-)

Choose the Filesystem that fits you

[El Prebso]

I think alot of people are to focused on XFS, Ext3 and ReiserFS competing with each other. Why can't Linux have three filesystems???

I like ReiserFS and I found that it's completly stable, it has never crashed. Others like XFS and that is fine by me, just don't tell me that my choise is wrong, I'll decide that for myself.

The great thing about Linux is that it let us choose what we want and don't give us what some dude i Redmond thinks we want. Let us have have 3,4 or 8 filesystems, then the user can choose what filesystem he or she want to use.

Get ready for the RDF?

[lowe0]

Quote: "we hope that plugins will do for filesystems what they did for Photoshop."

What, make them run 55% faster on a Mac than on an equivalent PIII?

Re:First things first...

[Lozzer]

From the interview

So, ReiserFS finally did make it to the 2.4 series. Now what? You mentioned on the list that current development work is now focused on version 4. Would you provide a general overview of what can we expect from this version?

We are now all focused on jumping on every bug report that comes in, determining if it is not a hardware bug, and if it is a real bug fixing it immediately. We will stay that way for several more weeks until it is very clear to the community that the experimental label should come off (this is hard when new VFS/MM layer bugs keep showing up), and then v4 will start.

Not every day a big name in software grants your wishes...

Has the world gone totally mad?

[peccary]

For almost ten years I worked on networked filesystems, and the US government prevented us from adding any kind of "hooks" on the basis that they might be used by furriners to add prohibited crypto.

Now the US Defense Department is paying a bunch of Russians (oh, the irony, the irony) to do exactly this!

And the Bush administrations is paying Osama bin Laden 40 mil for his valiant efforts on behalf of the War on (some) Drugs?

What's next? An invitation for Fidel Castro to spend the night at the White House and drop E with President Junior? Saturday Night Live quits doing White House satires because "we just can't keep up"?

You got the url wrong

[iplayfast]

It's www.reiserfs.com

Re:great news, xfs

[InsaneGeek]

They way I see it is that Reiser is looking to make a mark with having the latest & greatest feature list, XFS is looking to have the the most stable & reliable filesystem, and ext3 is a way to have people keep their existing ext2 data and add journaling support.

Reiser is planning on selling their modules in the future, make a new feature to be sold and change the previously sold module to be free. Their entire business model depends on them having newer and newer features, which is great for people who are wanting/needing feature over stability.

XFS is leaning more towards the datacenter type of situation, it may not have the latest and greatest, but it will work reliably, constantly, and with great performance. XFS is looking towards Linux as their OS platform, they have to give the same quality of filesystem they had on Irix to their customers who demand that quality. (when buying a multi-million dollar 512proc numa system they tend to require lots of stability).

On the competeing filesystems, Steve Lord from the XFS mailing list said it probably best:

"...I have never regarded the different filesystem on Linux as being in direct competition with each other, there will always be benefits to using each different filesystem for their strong points. Plus having several filesystems under active development means that there will be a tendency for the developers to make theirs the best, the implementations improve, and everyone wins."

Reiser will be used for the things it's good at (squid, mail spool, new features) and XFS will be used for the things it's good at (larger files, NFS server, stability). They compete only that they are filesystems, but what they are designed to be good at are two different things.

NFS plugin?

[oingoboingo]

Hopefully Hans will also provide an NFS plugin too...relatively recent versions of ReiserFS cause large-scale crapping out of your NFS server when you try and export ReiserFS volumes.

I won't be rushing again to stick ReiserFS on an NFS system any time soon....

RTWP

[Modular]

Actually he feels that it's relational databases that are crippling. In his whitepaper advocating a unified namespace, he proposes a hierarchical model that fits to data rather than fitting the data to the model.

Photoshop plugins?

[egjertse]

Looking forward to these filesystem plugins:

• "Random noise" - randomly copy from /dev/urandom instead of writing the actual file
• "Motion blur" - bit rot on very fast disks
• "JPEG compression" - lossy compression for your data!
• "Mosaic" - increase fragmentation
• "Colorize" - rot13 all .so files
• "Watermark" - digitally sign all files (also system files)

How about just making a toolkit for porting Gimp plugins?

Re:Photoshop plugins?

[Hater's Leaving, The]

Hot-diggetty man, I need mod points _now_!

You forgot
* Invert - learn to read documents backwards...
* Fade - You didn't need _all_ of the data did you?
* Rotate - Put data on the next sector to the one the FS headers say it's on.
* Merge - Great if you're short of space.

THL.
--

Fame

[3G]

Reiser also touches on issues of international software development and how programmers can achieve fame.

That should be pretty easy - create a kick-ass piece of software that everybody uses & name it after yourself (like he did :).

encrypted, compressed, journaling....

[Arethan]

okay....
And you expect to boot off of your encrypted/compressed drive how again?

Forgive me if I'm wrong, but you need to read the module files off the hard drive in order to load them and use them, but you need the modules loaded to read the drive... Kind of a chicken before the egg problem?

Lol. (Yea, I know. Boot partition is a standard FS the kernel and bootstrap prog can read and keep your FS module files on a non encrypted/compressed drive. But still, it's funny. I'm sure that more than a few newbies are going to forget about this little problem, move their module files to the encrypted drive, and then when they next reboot it won't work. *grin*)

Re:encrypted, compressed, journaling....

[deaddrunk]

ReiserFS was included with SuSE 6.4, but the kernel patch was available for plenty of time before that.

Hint: just over a year is not a long time.

Plugins

[SCHecklerX]

So how is this different from installable file systems (IFS), like those used in OS/2?

Re:Plugins

[Hater's Leaving, The]

Remember, Linux good, IBM bad.
Hmm, no that's not right.
OS/2, ah, ah, there's a MS link - OS/2 was what NT was going to be before they fell out and MS had to write their own NT, (using guys from Digital instead)

I'll start again.
Remember, Linux good, MS Windows-related bad.

THL.
(Who thinks that IBM's CSet++ on OS/2 was the best development system and UI class library he's ever encountered)

(aiming squarely at the funny/informative/off-topic/shut-up-cynical-bastar d split)
--

I agree

[ishrat]

I am all for this viewpoint that developers should at least get fame if not money, which in any case they may not be too interested in.

"I now tell people that I firmly advocate making the names of the programmers as prominent on the code as possible, especially when it is free software, and the sponsors should also be prominent on the code. People who do something should get either fame or money as their reward for it, and for free software to succeed we have to maximize the amount of fame that goes around. I think it is a complete rip-off that Stallman's name is not on every Linux distro (or at least the name GNU). It hurts his ability to command attention from people outside the industry who don't know much about us, and it is simply unfair. Failure to cite properly is considered an offense in academia, and it should be considered an offense in the free software community."

Re:Not a bad web site http://www.reiserfs.org/

[jwilhelm]

Yea... and your web site doesn't even load.

Re:Not a bad web site http://www.reiserfs.org/

[jwilhelm]

...and I forgot to mention that the real website is http://www.reiserfs.com

stability??

[codefreez]

How stable can a FS with plugins be? Some third party's bad code can make your files go bye-bye. I'm sure the security implications would be heavy too. Viruses planted in plug-ins would be too easy to implement and distribute.

Re:stability??

[Hater's Leaving, The]

Given that it's only as stable as the weaker of
- ReiserFS itself
- The provider of the plug-in.
and that ReiserFS itself is stable, you do have to be careful with your choice of plug-in.

If you care about your files be as careful about your plug-ins as you are about the manufacturer of your brake-disks, or your gas oven, say.

No-one will _force_ you to use any particular plug-in, you simply have to look for advocacy stories, and make sure you're not on the bleeding edge.

THL.
--

Open Sales

[roozbeh]

You haven't seen his brilliant idea? He will start evangelizing Open Sales:

In open sales, you [as the software licencee - ed.] join a pool [of licensed software] and pay a percentage of your hardware costs to use the software in the pool (if you can buy the hardware you should be able to afford a percentage of it for the software). The licensing software picks 5 random [software] vendors for you to divide your money between in proportion to the value you perceive in it, and your money gets divided between them. All software in the pool should have publicly available source code so that others can add improvements to it. This would fix the problems inherent in both copyright and patent law to a state better than they are now. Users would vote on what the percentage of hardware cost license fee would be, votes weighted according to how much they paid last year.

I wonder what will RMS say if he sees that idea...

First things first...

[Matthias Saou]

Before going into implementing new features, I'd prefer if they made ReiserFS rock solid first.

At the moment, and after hearing recent scary stories about problems with ReiserFS (but I personnally haven't ever had any big trouble), I switched to XFS and enjoy it just as much.

I also find SGI much more quick at getting things stable and finished, which is fairly important IMHO.

Matthias

Re:Like Frank Xia ...

[Pogue Mahone]

... or James V.Fat, author of the VFAT file system. Or Sid Mips, who has a whole architecture
port named after him. Or Georg Keyboard, Enzo Tpqic02, ... the list is endless.

Bzzz wrong. compress-y jounaling-y crypto-no

[glrotate]

Encryption debuted in Win2k

Attitude of ReiserFS's developers/backing company

[MwtrV]

RE: ReiserFS, revolutionary...

From what I have read thus far on ReiserFS and how they are planning on charging for plugins in the future along with ports, XFS seems like a slightly better choice for those concerned with the aesthetics of a project. I don't mean to be a "FREE!" bigot, but I wouldn't want to run something on my system next to the very core of Linux that didn't match the philosophy of it's neighboring code. I hope XFS finds a place in the kernel -- it deserves it a lot more -- and politics casts ReiserFS out. I know the argument: "People have to eat!" Well, that's fine and dandy, Certainly ReiserFS should be available. I just don't think XFS should be left out of the tree if it is embracing more platforms and has no commercial "options" (thus, making it more free.)

From the ReiserFS FAQ: "15.Can I use ReiserFS on other architectures than i386? Yes, on DEC Alpha. You may be able to easily bribe us to do the port though...."

From the XFS FAQ: "Q: Does it run on platforms other than i386? The current XFS tree seems to work just fine on ppc now (aside from some trivial compile fixes). It also runs well and is getting sporadically tested on the alpha, sparc64 and ia64. But on all of those platforms it is
not as well tested as on i386, but so far there are no major problems on those platforms known. All in all it looks like XFS will be running across a lot of platforms fine soon (with all the platforms above we have 32/64bit and little/big-endian architectures supported. If you run it on a platform not mentioned here please
let me know so that i can add it. Also an important note is that XFS is inherently platform independent in the on disk layout - so it should be possible to move a XFS disk from one linux platform to another out of the box."

Why in kernel space?

[janpod66]

I think putting ReiserFS into may not be a good engineering tradeoff. What are the tradeoffs? We gain the following:

• ReiserFS allows very fine-grained access control, on a "per field" (per file) basis. But is that really needed for the kinds of databases it is intended for? The main applications listed for it, databases, file servers, and desktop applications, either have a front-end application that performs its own security checks, or they run on behalf of a single user. Furthermore, even if fine-grained access control is needed, the set of user ids known to the kernel often does not correspond anymore to the set of users authorized to access the data.
• Being in the kernel, all applications use it automatically. But if we put a database into libc and hooked it into the file system calls, we'd get almost the same benefits.

What are the disadvantages of putting it into kernel space?

• Performance. Currently, it takes several system calls to access a data item in ReiserFS. That's a lot of overhead.
• Slow evolution. ReiserFS could benefit greatly from additional API calls, but adding those is a big hassle because they need to become ioctls or new system calls.

Maybe ReiserFS is the best we are going to get and the only way in which people are going to migrate to something less impoverished than the current UNIX file system data model. But I still think it's not a good engineering tradeoff overall.

Reiser's message is clear: Mundie is right.

[ccagle]

Don't get me wrong, I'm no great lover of Microsoft - I run Linux exclusively on my machine - but Reiser's comments (you did read the article, right?) echo exactly what MS VP Mundie has said about Open Source. It is certainly bad for business, or at least the software business.

Businesses that use software can benefit greatly from Open-Source programs; however, a software-only company - the ones who actually write, debug, and support the code - cannot expect to make money by giving away their product. Reiser's idea for open sales is rather new (at least, I've not heard of anything similar), and as such, has some faults. Overall, however, I think the concept of open sales is a potentially workable idea that needs to be expounded upon before being put into practice.

The way I understand it, open sales works like this: several open-source vendors contribute software to a pool, which anyone can access, modify, and use. Allegedly, companies and individuals will subscribe to these pools, and pay money so that their name shows up in a list of sponsors. It is unclear to me that this will be profitable or that it represents a departure from the economically bankrupt business models which characterize Free Software. The most obvious problem with Reiser's theory is that sponsors lists are most likely to either be 1) ignored, or 2) obtrusive (and possibly both) . I can only imagine where this could lead; am I going to be reading the source for a Perl script and see AOL ads commented in? I can see where being mentioned in the code would be useful to a support company; if you provide support for a particular program, such as Apache, then the most obvious place to market would be in the install process of that program. On the other hand, one thing the Linux community is reknowned for is its excellent community-support base. Will companies and individuals be willing to pay for support when they can find the answer themselves at no cost by searching Google?

Another problem I have with the system as described is the donation redistribution scheme. Reiser suggests that the software fees are to be redistributed among the contributors at random. I can see where he is coming from in a way; random distribution keeps the licensing monies from being taken by just a few. However, some companies and individuals are going to contribute more in the way of code than others. This should be taken into account in the redistribution scheme. Those who bear a heavier load should reap greater rewards.

There is also the problem of who is going to maintain and control these software pools. Are the companies who contribute code to these pools also going to be responsible for distributing the gains? Will the sponsors be allowed to have a say in who they will pay, and how much? Will there be standards to determine who deserves how much of the profits according to how much code they contributed?

There are many considerations to be made in regards to open sales, and it is not clear that this method will be able to produce a profit. Perhaps if software development companies can find new methods of providing value to their customers they can give away their products and still make money, but for now the rule seems to be that you cannot turn a profit by giving away valuable products for free.

==================

Sales Pool

[LaminatorX]

I like that idea alot. Sort of a software wholesale co-op. It's sort of like Napster's propsed subscription service, only tied to one's hardware cost instaid of a flat fee. That'd be really nice, as it would effectively make software pricing progressive with respect to income; i.e. those with ample money would have bought more expensive kit, those with a hand me down PII 266 likely don't have as much to spend.

Re:How about checking the links before posting?

[xzap]

the link should have pointed to
www.ResierFS.com
i.e. ReiserFS.

Re:undo plugin would be handy

[sketerpot]

You can accomplish this by replacing rm with a shell script that places deleted files in a special folder and tell cron to delete the contents of this folder every day.

An amazing number of things can be implemented without help from the filesystem. If you want undo functionality, that should be seperate from the filesystem. You can accomplish that with other tools, and it is very stable.

We should be thinking more about how to modularize than how to homogenize.

They actually make money....

[the_radix]

We are one of the very few companies making it on selling purely software, all the others sell CDs or hardware or something. This means the open source business model is a very bad one at the moment.

She has a darn good point on this. If all that Linsux companies can do is produce pieces of plastic to buy, then I am definitely going to take my money elsewhere. The reason I buy software that is not open source is because I can't get the sources.

Is open source bad? No, just the business model. It's a decent community, it just doesn't work in the corporate world. I know very few people who, faced with a free choice and a paying choice, both of which are perfectly legal, will take the payment route.

What's so important about this?

[Tini Kanooo]

Other than Helen Hunt's home address, WHAT does Paul Reiser need to protect by developing file system encryption? Maybe that dog Murray has some kitty-porn on that computer!