The article really wasn't well-written, and the features discussed were mostly taken out of context from the original document where they were simply meant to be quick-and-dirty examples.
I'm glad FreeBSD has a reasonably fast filesystem -- it was the one thing that really bothered me during normal usage.
The major "real benefits" of the future are first and foremost security-related. I'm sure ACLs will be one of the first implemented features. Samba fans will likely see a security plugin which implements NT permissions.
Other plugins will be of less concrete benefit, and will likely vary from "nice idea, but what's the point?" to "can't live without it". For example, accessing a Word document's text with cat sample.doc/text. ReiserFS will allow users to use file-based operations on things which aren't generally files. I anticipate many plugins which, while doing nothing which can't be done with a chain of pipes on the command-line, still serve to increase the perceived expressiveness of the system.
Are these filter plugins a "killer feature"? No, but Hans Reiser is betting that plugins will allow developers to evolve a system which "just makes sense".
Another cool thing is filesystem links in which the targets can be "aware" of the links to them. I'm not sure about implementation of this one, but it's a "gee-whiz featurette" that definitely made me jealous as a Win95 user looking at OS/2.;)
The major benefit will be extensibility. The overall system will gain usability as a result of increased expressiveness, and hopefully we'll see more flexible security features as a result as well.
As far as a FreeBSD port, or a port to other operating systems, I can't really say, and it's a matter which has me curious as well.
Do you know whether it will pose a major issue that the code is GPL'd in terms of FreeBSD adoption? I'd tend to doubt that the BSD guys would bless GPL code in terms of mainstream integration into the BSD kernel, and unfortunately I'm getting yelled at by my girlfriend for not being in bed right now, or I'd look more into it;)
This is sort of a sidenote, but the evantual goal is to allow ReiserFS to support security attributes without needed specialized userspace tools or kernel interfaces -- all can be done with ln, cat, and shell redirection, although I'm sure nifty scripts will show up here and there.
The ReiserFS algorithms allow nifty things like atomic actions. For example, an application will be able to check for/tmp/filenameXXX and create and open it as a single transaction, and ReiserFS will guarantee that no race condition exists.
ReiserFS doesn't waste a whole block on tiny files, or on the tails of larger files, so users gain space-efficiency (yes, I know hard drives are cheap, but they're still not free).
Filesystem plugins will allow nifty things like per-file encryption and compression.
Other than speed, space-efficiency, and the fact that V4 will make all filesystem operations (not just metadata-related operations) atomic, I really can't say that ReiserFS can do for you that ext2 (or similar filesystems) can't, at present.
I've posted the link to the V4 page at www.namesys.com, browse over there if you're really interested in better descriptions of features;)
Honestly, last I used FreeBSD was before softupdates and other UFS snazziness, so this is an unfair comparison, but I do recall FreeBSD taking tens of minutes to create an empty cache when I installed Squid from ports (on relatively expensive SCSI hardware), when ReiserFS on my crappy 5400 RPM IDE drive running in a system with 1/3 the clock speed took a matter of seconds to create an equivalent filesystem heirarchy on Linux.
Speed, space efficiency, crash safety. That's why ReiserFS is good today.
Why will ReiserFS be the filesystem of choice five years from now? Go to www.namesys.com and read for yourself.
How long ago was this? I followed the ReiserFS development list quite closely just before adoption into the mainstream kernel, and I'd say at least 85% of the bug reports were actually a result of buggy hardware.
If you could show a ReiserFS bug to the developers, they were VERY interested, and Hans would often assign a developer to figure out what went wrong.
SuSE uses ReiserFS by default, and has funded ReiserFS development.
There's a lot to be said about the simplistic approach of FAT16. The file allocation table is simple, and easier to repair or reconstruct when something bad happens. The FAT scheme has shown the ability to add new features without either breaking backwards compatibility or by implementing horribly complex structures that are prone to subtle breakage.
That aside, in the future, ReiserFS won't implement ACLs. ReiserFS probably won't implement UNIX permissions either. All a filesystem needs to do is store files, and if some of those files happen to represent metadata, and a given plugin decides to use those files which represent metadata to implement UNIX permissions, or ACLs, so be it.
ReiserFS' goal is to be damned fast in ALL cases, and to offer a plugin architecture that allows you do to the rest. It's damned stable, or SuSE wouldn't ship it as default. If you had a problem back when you had to patch the kernel to get support at all, I'm sorry, but my comment was in response to an article which some guy wrote which tried to address why namespaces will be important to the future of operating systems.
Why are people so reluctant to try a new filesystem? You had to try ext[23] in order to try Linux on its own partition, or UFS to run FreeBSD, didn't you?
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.
When you can explain to the ext2 developers (and the UFS guys as well) how to get the benefits of ReiserFS' dancing tree algorithms, don't post to Slashdot, go directly to the developers.
Until you can present a solution which allows UFS to cope QUICKLY with 50,000 files in a single directory, I'm in doubt.
The point is, with ReiserFS in place, to get ACLs you don't have to modify the on-disk representation. You don't just "[expand] the available extended attributes", because that requires modification of the on-disk structures for anything beyond trivial expansion.
ReiserFS doesn't replace the "everything is a file" model, as you've asserted. It extends that very same model to allow a security researcher to implement ACLs, extended attributes, etc., without modifying the on-disk structures one bit, since all you're really doing is editing/creating/deleting files, not mucking with security-model-specific attributes and ACLs.
You mean FreeBSD built ACL support into a slow filesystem in a way that didn't allow for future research and expansion of security models? I'm shocked. A modular filesystem which treats everything as files (and doesn't require modification of userspace tools to use -- I'll bet FreeBSD has some ACL maintenance commands) is a benefit a lot of filesystem developers don't seem to understand.
Well, as I mentioned, plugins can be written in userspace, so it wouldn't be bogging down the kernel, necessarily.
I know that Hans has said in his V4 docs that his proof-of-concept security plugin, which does something like denying read access to any file containing the word "topsecret", is a Perl script.
I would seriously trust the ReiserFS team to Do The Right Thing on this one. They're funded by the US DoD, and their goal is to write a system on which security can be built in a modular fashion. If they can find a way to allow userspace security plugins, I'm sure a few file filters should be no problem at all.
Of course, we'll all just have to wait and see... but the V4 design docs are a really interesting read, and contain mentions of future features. Check out http://www.namesys.com/v4/v4.html for more.
As far as the/dev/eth0 stuff, I vaguely recall something called "kernfs" for the 2.5/2.6 series. Apparently kernel configuration options will be presented in a filesystem-ish interface. How this differs from the stuff in/proc, I don't know, but this may already expose the sort of functionality you're looking for.
Re:Data, even metadata, belongs in files, not fs
on
State Of The Filesystem
·
· Score: 3, Insightful
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,
Tech TV actually showed on TV that once you apply all current security patches for Windows 98/98SE, Me, 2000 and XP, plus installing a decent software firewall program or put your broadband connection behind a hardware firewall, breaking in will be nearly impossible
Well, golllll-y! They showed this on TV, you say? Gosh, I'm convinced!
Er, wait... what exactly did they show? How do you "show" that an OS cannot be exploited?
Man, on TV... I'm reminded of something a former cow-orker said to me once in response to a customer complaint about spam, with a gleam in his eye and a knowing smile on his face:
"Because if you read it on the Internet, it must be true!"
Ditto for proving a product's security on tee-vee. Show me some real evidence, don't quote some schmoe's evaluation on a made-for-the-masses television show.
The flaw with this shiny-looking argument is in the definition of "security flaw".
Keep in mind that lawyers like very specific language. Laws and regulations must be worded in such a way that one can compare an example against the language of the law and determine whether something qualifies as a violation of that law.
Now, many, MANY strains of viruses have been nothing more than (barely!) masked Trojans.
In other words, if you can get the user to run something, it's a security risk, and one for which the OS vendor cannot necessarily be held responsible, short of disallowing programs to run other programs.
In any environment in which data and code are not separated by CPU-level protection mechanisms, a buffer overflow can happen. Even with such protection in place, any time the user is allowed to launch an arbitrary program, there is a risk involved.
Keep in mind that requiring a vendor to label something which is potentially dangerous with "This is a program, which will execute!" or other such flags is insufficient -- the user cannot be trusted to know what such things mean.
What you're saying makes about as much sense, when it comes down to it, as suggesting that mail server vendors be held responsible for flaws in their software which allows spam to be received. In either case, it's a matter of the system not knowing whether the user is doing something legitimate (running a game, or an eCard from Granny) or something with bad results (running a trojan or receiving UCE).
If you can come up with a system which can distinguish between the two cases without burdening the user excessively (read: "at all"), then stop posting your overrated drivel and get ye to the patent office, before someone else does!
I'm reminded of when some in the government wanted to prohibit public-key crypto, and Paul Zimmerman (1) created PGP in order to free the information/ability.
Does anyone know how to go about recreating some of this work for public use?
Let's let the cat out of the bag before the government ties it shut.
Not "the Internet" as a whole, but if a city's telecommunications access is fed through a handful of isolated fiber lines, then yes, it's quite possible, and that's the point.
My former employer owned one of the first ISPs in Pittsburgh (Pittsburgh Online/Webstation, since sold to Stargate), and once told an old friend who worked at the FBI an anecdotal story about how easily he could rob a given bank. It involved jamming the police band frequencies (easily done with equipment you could build yourself), and arranging an "accident" which knock out the telephone lines to the police station.
When the dispatchers' lines were cut, you could walk into the bank and take your time, confident in knowing that even if the bank called 911 (or their security service made the call), the police could not be notified until communications were restored. The person most aware of the coincidence of the two outages (radio and telephone) would be the dispatcher, and they wouldn't be able to coordinate anything until you were long gone.
I don't know what became of the situation, but I do know that my former employer ended up retelling his tale to some very interested higher-ups in the local FBI branch.
That's a good point. I recall construction to the new football stadium in Pittsburgh causing a data line to be cut and denying much of the area telecomm access.
I don't remember details, but in my mind it's a great example of why information like this should be available, on a large and precise scale.
Have you ever dug up your own septic tank? I bet you'd be a bit happier knowing exactly where each and every utility feed in your yard is.
I don't know what information is available here, but I agree wholeheartedly with your statements.
One of the things MS did correctly on Excel was decent graphing
I'm sorry, but I have to strongly disagree with that one. I last really used a spreadsheet for serious graphing purposes about 6 years ago, using Quattro Pro (which came with Corel PerfectOffice) on Windows 95.
It had more flexible (and better-looking) graphing functions that Excel still can't touch, and was a damned sight cheaper too (I paid $90 at the time).
I'd say that Excel graphs like Pico edits text, but that's unfair to Pico.
I'm not sure about Windows stuff -- I always SSH into a 'nix box and check my mail remotely. Mutt does support IMAP and POP as well as local folders. If there's no native Win32 port available, I know that Cygwin offers both Pine and Mutt.
First of all, thank you for your response! My description was pretty vague, and you've been quite helpful.
I was glad to still have the code snippet lying around for later examination, as this was months ago that I wrote it.
When I ran that code, it was from the command-line (gcl -f snippet.lisp >/dev/null) so output didn't flood the terminal, but I do recall it taking over 60 seconds to run (on the modest system on which I tried it). In retrospect, I suppose I should have ran it without printing it out. On the other hand, I'm used to faster output than that, although I'm not sure whether Lisp generally buffers stdout, so I don't know enough to know what I could have known all along.
Compiling the function (without the print, that is) reduced real execution time from an acceptable 5.6 seconds to a downright sprightly 1.9 seconds on a 300 MHz Celeron, but it seems that the real hog was the inline print.
Beautiful! Thank you for the time you've spent in setting one man straight.
As far as printing, I was running from a shell (gcl -f snippet.lisp) and dumping to/dev/null, so I didn't realize that printing would have such a negative effect on runtime. It's rather embarassing that I wrestled with this problem for a good while, restating the expression in different ways, but never could find a good (quick!) way to do it.
I'll have to give Lisp another go (or at least append it to my to-do list). Are there any online references to Common Lisp which you could recommend?
(Regarding Slashdot's indentation -- I've found that the <tt> tag doesn't preserve indentation. I believe <ecode> is what you're looking for.
I tried LISP once. I don't recall what the test proglet I was trying to write did, but I do recall that I was reading words from/usr/share/dict/words into a list, and reading the whole file (2.4 MB, 234937 words) takes FOREVER!
I've tried every LISP interpreter packaged by Debian, and been disappointed by all. A C or Perl interpretation takes at most a few seconds, but this LISP code takes a minute or more:
(with-open-file (infile "/usr/share/dict/words")
(do ((result nil (cons next result))
(next (read infile nil 'eof) (read infile nil 'eof)))
((equal next 'eof) (reverse result)) (print next)))
Oh ye LISP advocate, can you tell me what I've done wrong? I'd love to give LISP another go, but not with such dismal performance...
One is not forced to use the "standard" libc, sure.
However, when one refers to a UNIX-like system, they expect something resembling UNIX.
What I'm saying is that the part of the operating system that makes Linux look like a UNIX system in terms of API and interface is GNU.
The kernel "can" do work without any GNU software, sure, and as soon as you start a distribution that does useful work without any GNU software, I'll apologize for saying that GNU should be given credit.
Until then, every time you waste your time talking about how the Linux kernel would be generally useful without the GNU UNIX-ish stuff on top it just makes those who assume that people on Slashdot have nothing coherent to say happier.
Okay. Let's say a program writes directly to the tty device, instead of using a library such as ncurses.
Such programs generally use functions such as open() to access device files. Something maps the function open() (or fopen()) to a system call, so that the user-level program doesn't have to know how do use system calls directly.
That is what the standard libraries do. Don't blame me, blame GNU.
Slashdot Mirror
The article really wasn't well-written, and the features discussed were mostly taken out of context from the original document where they were simply meant to be quick-and-dirty examples.
;)
;)
I'm glad FreeBSD has a reasonably fast filesystem -- it was the one thing that really bothered me during normal usage.
The major "real benefits" of the future are first and foremost security-related. I'm sure ACLs will be one of the first implemented features. Samba fans will likely see a security plugin which implements NT permissions.
Other plugins will be of less concrete benefit, and will likely vary from "nice idea, but what's the point?" to "can't live without it". For example, accessing a Word document's text with cat sample.doc/text. ReiserFS will allow users to use file-based operations on things which aren't generally files. I anticipate many plugins which, while doing nothing which can't be done with a chain of pipes on the command-line, still serve to increase the perceived expressiveness of the system.
Are these filter plugins a "killer feature"? No, but Hans Reiser is betting that plugins will allow developers to evolve a system which "just makes sense".
Another cool thing is filesystem links in which the targets can be "aware" of the links to them. I'm not sure about implementation of this one, but it's a "gee-whiz featurette" that definitely made me jealous as a Win95 user looking at OS/2.
The major benefit will be extensibility. The overall system will gain usability as a result of increased expressiveness, and hopefully we'll see more flexible security features as a result as well.
As far as a FreeBSD port, or a port to other operating systems, I can't really say, and it's a matter which has me curious as well.
Do you know whether it will pose a major issue that the code is GPL'd in terms of FreeBSD adoption? I'd tend to doubt that the BSD guys would bless GPL code in terms of mainstream integration into the BSD kernel, and unfortunately I'm getting yelled at by my girlfriend for not being in bed right now, or I'd look more into it
Thanks in advance for any responses.
Hmm...
/tmp/filenameXXX and create and open it as a single transaction, and ReiserFS will guarantee that no race condition exists.
;)
This is sort of a sidenote, but the evantual goal is to allow ReiserFS to support security attributes without needed specialized userspace tools or kernel interfaces -- all can be done with ln, cat, and shell redirection, although I'm sure nifty scripts will show up here and there.
The ReiserFS algorithms allow nifty things like atomic actions. For example, an application will be able to check for
ReiserFS doesn't waste a whole block on tiny files, or on the tails of larger files, so users gain space-efficiency (yes, I know hard drives are cheap, but they're still not free).
Filesystem plugins will allow nifty things like per-file encryption and compression.
Other than speed, space-efficiency, and the fact that V4 will make all filesystem operations (not just metadata-related operations) atomic, I really can't say that ReiserFS can do for you that ext2 (or similar filesystems) can't, at present.
I've posted the link to the V4 page at www.namesys.com, browse over there if you're really interested in better descriptions of features
Honestly, last I used FreeBSD was before softupdates and other UFS snazziness, so this is an unfair comparison, but I do recall FreeBSD taking tens of minutes to create an empty cache when I installed Squid from ports (on relatively expensive SCSI hardware), when ReiserFS on my crappy 5400 RPM IDE drive running in a system with 1/3 the clock speed took a matter of seconds to create an equivalent filesystem heirarchy on Linux.
Speed, space efficiency, crash safety. That's why ReiserFS is good today.
Why will ReiserFS be the filesystem of choice five years from now? Go to www.namesys.com and read for yourself.
How long ago was this? I followed the ReiserFS development list quite closely just before adoption into the mainstream kernel, and I'd say at least 85% of the bug reports were actually a result of buggy hardware.
If you could show a ReiserFS bug to the developers, they were VERY interested, and Hans would often assign a developer to figure out what went wrong.
SuSE uses ReiserFS by default, and has funded ReiserFS development.
There's a lot to be said about the simplistic approach of FAT16. The file allocation table is simple, and easier to repair or reconstruct when something bad happens. The FAT scheme has shown the ability to add new features without either breaking backwards compatibility or by implementing horribly complex structures that are prone to subtle breakage.
That aside, in the future, ReiserFS won't implement ACLs. ReiserFS probably won't implement UNIX permissions either. All a filesystem needs to do is store files, and if some of those files happen to represent metadata, and a given plugin decides to use those files which represent metadata to implement UNIX permissions, or ACLs, so be it.
ReiserFS' goal is to be damned fast in ALL cases, and to offer a plugin architecture that allows you do to the rest. It's damned stable, or SuSE wouldn't ship it as default. If you had a problem back when you had to patch the kernel to get support at all, I'm sorry, but my comment was in response to an article which some guy wrote which tried to address why namespaces will be important to the future of operating systems.
Why are people so reluctant to try a new filesystem? You had to try ext[23] in order to try Linux on its own partition, or UFS to run FreeBSD, didn't you?
From the horse's mouth, at the V4 design pages:
When you can explain to the ext2 developers (and the UFS guys as well) how to get the benefits of ReiserFS' dancing tree algorithms, don't post to Slashdot, go directly to the developers.
Until you can present a solution which allows UFS to cope QUICKLY with 50,000 files in a single directory, I'm in doubt.
The point is, with ReiserFS in place, to get ACLs you don't have to modify the on-disk representation. You don't just "[expand] the available extended attributes", because that requires modification of the on-disk structures for anything beyond trivial expansion.
ReiserFS doesn't replace the "everything is a file" model, as you've asserted. It extends that very same model to allow a security researcher to implement ACLs, extended attributes, etc., without modifying the on-disk structures one bit, since all you're really doing is editing/creating/deleting files, not mucking with security-model-specific attributes and ACLs.
You mean FreeBSD built ACL support into a slow filesystem in a way that didn't allow for future research and expansion of security models? I'm shocked. A modular filesystem which treats everything as files (and doesn't require modification of userspace tools to use -- I'll bet FreeBSD has some ACL maintenance commands) is a benefit a lot of filesystem developers don't seem to understand.
Well, as I mentioned, plugins can be written in userspace, so it wouldn't be bogging down the kernel, necessarily.
/dev/eth0 stuff, I vaguely recall something called "kernfs" for the 2.5/2.6 series. Apparently kernel configuration options will be presented in a filesystem-ish interface. How this differs from the stuff in /proc, I don't know, but this may already expose the sort of functionality you're looking for.
I know that Hans has said in his V4 docs that his proof-of-concept security plugin, which does something like denying read access to any file containing the word "topsecret", is a Perl script.
I would seriously trust the ReiserFS team to Do The Right Thing on this one. They're funded by the US DoD, and their goal is to write a system on which security can be built in a modular fashion. If they can find a way to allow userspace security plugins, I'm sure a few file filters should be no problem at all.
Of course, we'll all just have to wait and see... but the V4 design docs are a really interesting read, and contain mentions of future features. Check out http://www.namesys.com/v4/v4.html for more.
As far as the
While there are problems to be solved (backup, for instance), there are many benefits as well.
/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.
/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."
/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.
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
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
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
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,
Er, wait... what exactly did they show? How do you "show" that an OS cannot be exploited?
Man, on TV... I'm reminded of something a former cow-orker said to me once in response to a customer complaint about spam, with a gleam in his eye and a knowing smile on his face:
"Because if you read it on the Internet, it must be true!"
Ditto for proving a product's security on tee-vee. Show me some real evidence, don't quote some schmoe's evaluation on a made-for-the-masses television show.
The flaw with this shiny-looking argument is in the definition of "security flaw".
Keep in mind that lawyers like very specific language. Laws and regulations must be worded in such a way that one can compare an example against the language of the law and determine whether something qualifies as a violation of that law.
Now, many, MANY strains of viruses have been nothing more than (barely!) masked Trojans.
In other words, if you can get the user to run something, it's a security risk, and one for which the OS vendor cannot necessarily be held responsible, short of disallowing programs to run other programs.
In any environment in which data and code are not separated by CPU-level protection mechanisms, a buffer overflow can happen. Even with such protection in place, any time the user is allowed to launch an arbitrary program, there is a risk involved.
Keep in mind that requiring a vendor to label something which is potentially dangerous with "This is a program, which will execute!" or other such flags is insufficient -- the user cannot be trusted to know what such things mean.
What you're saying makes about as much sense, when it comes down to it, as suggesting that mail server vendors be held responsible for flaws in their software which allows spam to be received. In either case, it's a matter of the system not knowing whether the user is doing something legitimate (running a game, or an eCard from Granny) or something with bad results (running a trojan or receiving UCE).
If you can come up with a system which can distinguish between the two cases without burdening the user excessively (read: "at all"), then stop posting your overrated drivel and get ye to the patent office, before someone else does!
I'm reminded of when some in the government wanted to prohibit public-key crypto, and Paul Zimmerman (1) created PGP in order to free the information/ability.
Does anyone know how to go about recreating some of this work for public use?
Let's let the cat out of the bag before the government ties it shut.
(1) See http://www.cypherspace.org/~adam/timeline/ for details.
Going off on a tangent, could you explain what Thatcher did in N. Ireland, and what Blair's approach was?
;)
You've got my curiosity
Not "the Internet" as a whole, but if a city's telecommunications access is fed through a handful of isolated fiber lines, then yes, it's quite possible, and that's the point.
My former employer owned one of the first ISPs in Pittsburgh (Pittsburgh Online/Webstation, since sold to Stargate), and once told an old friend who worked at the FBI an anecdotal story about how easily he could rob a given bank. It involved jamming the police band frequencies (easily done with equipment you could build yourself), and arranging an "accident" which knock out the telephone lines to the police station.
When the dispatchers' lines were cut, you could walk into the bank and take your time, confident in knowing that even if the bank called 911 (or their security service made the call), the police could not be notified until communications were restored. The person most aware of the coincidence of the two outages (radio and telephone) would be the dispatcher, and they wouldn't be able to coordinate anything until you were long gone.
I don't know what became of the situation, but I do know that my former employer ended up retelling his tale to some very interested higher-ups in the local FBI branch.
That's a good point. I recall construction to the new football stadium in Pittsburgh causing a data line to be cut and denying much of the area telecomm access.
I don't remember details, but in my mind it's a great example of why information like this should be available, on a large and precise scale.
Have you ever dug up your own septic tank? I bet you'd be a bit happier knowing exactly where each and every utility feed in your yard is.
I don't know what information is available here, but I agree wholeheartedly with your statements.
Yeah, yeah, hell yeah ;)
.sig, however, you're in more of a position to know that than I am.
Although one minor point --
I am one who gives GNU credit where they deserve it. GNU kicks ass, and has done a lot for Free computing.
However, as I understand it, most of the drivers are for "Linux", the kernel, not "GNU/Linux", the OS.
Judging by your
You kick ass.
It had more flexible (and better-looking) graphing functions that Excel still can't touch, and was a damned sight cheaper too (I paid $90 at the time).
I'd say that Excel graphs like Pico edits text, but that's unfair to Pico.
Reading Slashdot before putting your glasses on can be MUCH more interesting.
I saw:
First Dual-emission OLEO Display in a Phone
How neat would that be? A margarine-based display? Talk about low production costs!
I'm not sure about Windows stuff -- I always SSH into a 'nix box and check my mail remotely.
Mutt does support IMAP and POP as well as local folders. If there's no native Win32 port available, I know that Cygwin offers both Pine and Mutt.
Hopefully this will make Slashdotters realize that the readership isn't comprised of just big, bloated browser (and mail client) users.
First of all, thank you for your response! My description was pretty vague, and you've been quite helpful.
/dev/null) so output didn't flood the terminal, but I do recall it taking over 60 seconds to run (on the modest system on which I tried it). In retrospect, I suppose I should have ran it without printing it out. On the other hand, I'm used to faster output than that, although I'm not sure whether Lisp generally buffers stdout, so I don't know enough to know what I could have known all along.
I was glad to still have the code snippet lying around for later examination, as this was months ago that I wrote it.
When I ran that code, it was from the command-line (gcl -f snippet.lisp >
Compiling the function (without the print, that is) reduced real execution time from an acceptable 5.6 seconds to a downright sprightly 1.9 seconds on a 300 MHz Celeron, but it seems that the real hog was the inline print.
Beautiful! Thank you for the time you've spent in setting one man straight.
/dev/null, so I didn't realize that printing would have such a negative effect on runtime. It's rather embarassing that I wrestled with this problem for a good while, restating the expression in different ways, but never could find a good (quick!) way to do it.
As far as printing, I was running from a shell (gcl -f snippet.lisp) and dumping to
I'll have to give Lisp another go (or at least append it to my to-do list). Are there any online references to Common Lisp which you could recommend?
(Regarding Slashdot's indentation -- I've found that the <tt> tag doesn't preserve indentation. I believe <ecode> is what you're looking for.
I've tried every LISP interpreter packaged by Debian, and been disappointed by all. A C or Perl interpretation takes at most a few seconds, but this LISP code takes a minute or more:Oh ye LISP advocate, can you tell me what I've done wrong? I'd love to give LISP another go, but not with such dismal performance...
Agreed. Such is why RMS pushes for people to call the OS GNU, the kernel Linux, the desktop environment KDE/Gnome/whatever running over XFree86, etc.
People see "Linux" as the entire system. I'd love to see some companies putting money into other aspects of the OS than the kernel.
2.9.13?
Jeez, I need to build another machine. Last kernel I ran was somewhere in the 2.4 series...
One is not forced to use the "standard" libc, sure.
However, when one refers to a UNIX-like system, they expect something resembling UNIX.
What I'm saying is that the part of the operating system that makes Linux look like a UNIX system in terms of API and interface is GNU.
The kernel "can" do work without any GNU software, sure, and as soon as you start a distribution that does useful work without any GNU software, I'll apologize for saying that GNU should be given credit.
Until then, every time you waste your time talking about how the Linux kernel would be generally useful without the GNU UNIX-ish stuff on top it just makes those who assume that people on Slashdot have nothing coherent to say happier.
Okay. Let's say a program writes directly to the tty device, instead of using a library such as ncurses.
Such programs generally use functions such as open() to access device files. Something maps the function open() (or fopen()) to a system call, so that the user-level program doesn't have to know how do use system calls directly.
That is what the standard libraries do. Don't blame me, blame GNU.
I said a "a SysV-style and a BSD-style distro".
Distributions of GNU/Linux do share the Linux kernel, do they not?