Interview with Hans on KernelTrap

Interview with Hans on KernelTrap

[Hubert Chan]

For those who missed it on Slashdot, there's an interview with Hans on
KernelTrap.

http://kerneltrap.org/node/5654?comments_per_page=1

The Slashdot article is here:

http://hardware.slashdot.org/article.pl?sid=05/09/13/1455238

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Interview with Hans on KernelTrap

[Peter Foldiak]

Hans, in the interview you give the example:

  cat /home/reiser/mp3s/..../childcat > /dev/dsp

to illustrate concatenation.

I sorry for repeating myself, but still think it would be a lot cooler 
to be able to simply do:

  cat /home/reiser/mp3s > /dev/dsp

to achieve the same effect.
(We had a discussion of this (as part of the huge "file as directory" 
thread on the lists)
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/0044.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0505.1/0365.html
and you seemed to agree then
http://www.ussg.iu.edu/hypermail/linux/kernel/0505.1/0423.html
)
The convention (I think also approved(suggested?) by Linus at some 
point) could be that where you say

  /home/reiser/mp3s

you get a the file (or concatenation, if the directory has no "file" 
content itself), but when you say

  /home/reiser/mp3s/

(with the trailing "/"), you get the directory.

So
  book/chapter3/paragraph2
is the second paragraph of the third chapter
(or even better, a la XPath:
  book/chapter[3]/paragraph[2]
)

  book/chapter3
is the chapter

  book
is the whole book.

The user (or tools) don't even have to know which is the "real" file, 
which are "parts of real files" and which are "concatenations of real 
files". This is really good for namespace unification across part-whole 
hierarchies. If you are required to use /..../ in the middle, it breaks 
this I think. Could we get rid of requiring "...." in the middle? (Would 
that break too much?)    Peter

Re: Interview with Hans on KernelTrap

[Yiannis Mavroukakis]

Peter Foldiak wrote:

> Hans, in the interview you give the example:
>
>  cat /home/reiser/mp3s/..../childcat > /dev/dsp
>
> to illustrate concatenation.
> [...]
>  
> The convention (I think also approved(suggested?) by Linus at some 
> point) could be that where you say
>
>  /home/reiser/mp3s
>
> you get a the file (or concatenation, if the directory has no "file" 
> content itself), but when you say
>
>  /home/reiser/mp3s/
>
> (with the trailing "/"), you get the directory.
>
If cool is the first perceived benefit, then why do it ? Besides, it's 
quite easy through force of habit or mistype to add a '/'

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Re: Interview with Hans on KernelTrap

[Bruce Israel]

On Wed, Sep 14, 2005 at 03:11:21PM +0100, Yiannis Mavroukakis wrote:
> Peter Foldiak wrote:
> 
> >Hans, in the interview you give the example:
> >
> > cat /home/reiser/mp3s/..../childcat > /dev/dsp
> >
> >to illustrate concatenation.
> >[...]
> > 
> >The convention (I think also approved(suggested?) by Linus at some 
> >point) could be that where you say
> >
> > /home/reiser/mp3s
> >
> >you get a the file (or concatenation, if the directory has no "file" 
> >content itself), but when you say
> >
> > /home/reiser/mp3s/
> >
> >(with the trailing "/"), you get the directory.
> >
> If cool is the first perceived benefit, then why do it ? Besides, it's 
> quite easy through force of habit or mistype to add a '/'

Plus often shell completions (e.g. TAB in bash) often add the
trailing slash automatically.  Though there's an argument to be made
for that being what you want; i.e. how often do you really do a 'cat
<dir>' to look at the inside of the directory?  Though I guess if I
were doing a 'chown -R <user> <directory>', I'd be miffed if it just
changed the files below and not the directory because of a mis-typed
(or mis-completed) slash.

Bruce

Re: Interview with Hans on KernelTrap

[Peter Foldiak]

Peter Foldiak wrote:

> The convention (I think also approved(suggested?) by Linus at some 
> point)... 

P.S. I found the reference, I was referring here to
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/0537.html

By "cool", I mean more than just elegant, though elegant is often the 
sign of really useful. And obviously I don't see all possible (good and 
bad) consequences.    Peter

Re: Interview with Hans on KernelTrap

[Hans Reiser]

Peter Foldiak wrote:

> Hans, in the interview you give the example:
>
>  cat /home/reiser/mp3s/..../childcat > /dev/dsp
>
> to illustrate concatenation.
>
> I sorry for repeating myself, but still think it would be a lot cooler
> to be able to simply do:
>
>  cat /home/reiser/mp3s > /dev/dsp
>
> to achieve the same effect.

True.

> (We had a discussion of this (as part of the huge "file as directory"
> thread on the lists)
> http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/0044.html
> http://www.ussg.iu.edu/hypermail/linux/kernel/0505.1/0365.html
> and you seemed to agree then
> http://www.ussg.iu.edu/hypermail/linux/kernel/0505.1/0423.html
> )
> The convention (I think also approved(suggested?) by Linus at some
> point) could be that where you say
>
>  /home/reiser/mp3s
>
> you get a the file (or concatenation, if the directory has no "file"
> content itself), but when you say
>
>  /home/reiser/mp3s/
>
> (with the trailing "/"), you get the directory.
>
> So
>  book/chapter3/paragraph2
> is the second paragraph of the third chapter
> (or even better, a la XPath:
>  book/chapter[3]/paragraph[2]
> )
>
>  book/chapter3
> is the chapter
>
>  book
> is the whole book.
>
> The user (or tools) don't even have to know which is the "real" file,
> which are "parts of real files" and which are "concatenations of real
> files". This is really good for namespace unification across
> part-whole hierarchies. If you are required to use /..../ in the
> middle, it breaks this I think. Could we get rid of requiring "...."
> in the middle? (Would that break too much?)    Peter
>
In this specific instance, yes, but other pseudofiles would still need it.

My example was not a good one, I should have found a better one, sorry
for that.

>
>

Re: Interview with Hans on KernelTrap

[Peter Foldiak]

Hans Reiser wrote:

>>The user (or tools) don't even have to know which is the "real" file,
>>which are "parts of real files" and which are "concatenations of real
>>files". This is really good for namespace unification across
>>part-whole hierarchies. If you are required to use /..../ in the
>>middle, it breaks this I think. Could we get rid of requiring "...."
>>in the middle? (Would that break too much?)    Peter
>>    
>>
>In this specific instance, yes, but other pseudofiles would still need it.
>  
>
Sure, you can have only one "default" behaviour. (For instance, you 
would also need some metafiles to specify the details of how exactly the 
concatenation should be done, (e.g. what ordering (or structure) to use, 
whether to put something in between the files, etc.) in addition to all 
the other ones.)    Peter

Re: Interview with Hans on KernelTrap

[Hans Reiser]

Peter Foldiak wrote:

> Hans Reiser wrote:
>
>>> The user (or tools) don't even have to know which is the "real" file,
>>> which are "parts of real files" and which are "concatenations of real
>>> files". This is really good for namespace unification across
>>> part-whole hierarchies. If you are required to use /..../ in the
>>> middle, it breaks this I think. Could we get rid of requiring "...."
>>> in the middle? (Would that break too much?)    Peter
>>>   
>>
>> In this specific instance, yes, but other pseudofiles would still
>> need it.
>>  
>>
> Sure, you can have only one "default" behaviour. (For instance, you
> would also need some metafiles to specify the details of how exactly
> the concatenation should be done, (e.g. what ordering (or structure)
> to use, whether to put something in between the files, etc.) in
> addition to all the other ones.)    Peter
>
>
Yes, true.

Re: Interview with Hans on KernelTrap

[Tomasz Chmielewski]

> For those who missed it on Slashdot, there's an interview with Hans on
> KernelTrap.
> 
> http://kerneltrap.org/node/5654?comments_per_page=1
> 
> The Slashdot article is here:
> 
> http://hardware.slashdot.org/article.pl?sid=05/09/13/1455238

Nice interview.

The compression plugin is mentioned in that article:


Jeremy Andrews: You mention that you want to stabilize the compression 
plugin by 2.6.14. What is important about 2.6.14?

Hans Reiser: Umh, anytime I can double performance and halve space 
usage, it is a priority for me and I want it now! ;-)


So does it mean that Linux will finally have a stable fs with 
journalling and compression, within a month?

Or Reiser4 won't go to 2.6.14 stable kernel, and will be available only 
as a separate patch?


On the other hand, when I looked at the 2.6.14-rc1 changelog on 
www.kernel.org, no plugin/compression is mentioned in reiserfs changes?


-- 
Tomek
http://wpkg.org
Automated software installation and upgrades with Samba

Re: Interview with Hans on KernelTrap

[Tom Vier]

Regarding the compression plugin, it only compresses file data and not fs
structures, right?

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: Interview with Hans on KernelTrap

[Edward Shishkin]

Tom Vier wrote:

>Regarding the compression plugin, it only compresses file data and not fs
>structures, right?
>
>  
>
yes