RE: Fwd: reiser4 non-free?

RE: Fwd: reiser4 non-free?

[Burnes, James]

Is there any way to do an MD5 of either (1) each module in a software
subsystem or (2) each software version and then have a central registry
where interested developers and users can go to see the credits?

That way you could simply do an MD5 of the current binary and use that
fingerprint to see who wrote and contributed to it.  Much like the CDDB
database takes a track/time fingerprint of CD's and then tells you which
songs and artist made the CD.

This could be a kind of historical registry for developers.  If they
want to they can use it to demonstrate to potential employers,
contractors and/or new IPOs to prove their contributions.

It might also be invaluable to eventual science historians that would
like to research the individuals contributing to certain important
systems.

That would seem to be the scalable way to do it.  You could also include
the credits in the source code, but not require them to be duplicated in
in GPL derived works.

I'm sure there are angles I haven't thought of since I'm running on 3
hours sleep.  Maybe a way to look at binary diffs and say, "this is 95%
similar to ReiserFS Version 4.3, would you like to view the credits for
this system?"

Or something like that.

jim burnes
security engineer
great-west, denver
 

> -----Original Message-----
> From: Hans Reiser [mailto:reiser@namesys.com]
> Sent: Monday, May 03, 2004 11:05 AM
> To: Martin List-Petersen
> Cc: Don Armstrong; debian-legal@lists.debian.org; reiserfs-
> list@namesys.com
> Subject: Re: Fwd: reiser4 non-free?
> 
> Martin List-Petersen wrote:
> 
> >On Sun, 2004-05-02 at 22:55, Don Armstrong wrote:
> >
> >
> >>>>Furthermore, the list of credits are still included (to my
knowledge)
> >>>>in /usr/share/doc/resierfsprogs/README.gz.
> >>>>
> >>>>
> >>>oh, well, that is almost as good as putting them on the dark side
of
> >>>the moon....  a credit read by no one has no meaning.
> >>>
> >>>
> >
> >I don't know what you are reading once you've installed a new program
on
> >your system, but the README, README.Debian and the man-pages are for
me
> >usually the FIRST place, since it might hold valuable information and
> >safe me the trouble, which i may have, if i didn't had read it.
> >
> >
> I never read these (except the man pages) unless the install fails in
> some way (I read the NVIDIA ones many times....), and neither do 99%
of
> real users, including 99% of reiserfs users.  As a user, I can handle
> the distro flashing information on my screen as it installs and I can
> read that, or printing credits when I select a particular package for
> the install, and I can handle a tool printing credits when it starts
up
> (ala mkreiser4) for me to read, but going through a list of 3000
> packages after the install completes and reading their readmes and
> credits files just ain't gonna happen.
> 
> As a developer, I can probably be talked out of anything that makes
the
> install slower or more awkward or adds more clicks.  If there is
another
> paradigm in place for displaying info about the packages during the
> install (I encourage you to have one), I would most likely be happy to
> conform to that.
> 
> >So, if you know somebody (including yourself) that doesn't do it I'm
> >really in doubt about the security of your system. There is actually
> >useful information in there.
> >
> >/Martin
> >--
> >The camel has a single hump;
> >The dromedary two;
> >Or else the other way around.
> >I'm never sure.  Are you?
> >                -- Ogden Nash
> >
> >
> >
> >
> >
> >

Re: Fwd: reiser4 non-free?

[Hans Reiser]

Burnes, James wrote:

>Is there any way to do an MD5 of either (1) each module in a software
>subsystem or (2) each software version and then have a central registry
>where interested developers and users can go to see the credits?
>
>  
>
Credits that users must take action to see are not effective credits. No 
one will look at them.

max files

[camis]

Hi All,

Anyone tested to see how fast/sluggish reiser3 (or 4?)
performs when accessing a directory that has between
5 and 25 million flat/text files?

Any past experiences? (dont say use subdirectories ;)

Cami

RE: Fwd: reiser4 non-free?

[Martin List-Petersen]

On Mon, 2004-05-03 at 18:41, Burnes, James wrote:
> Is there any way to do an MD5 of either (1) each module in a software
> subsystem or (2) each software version and then have a central registry
> where interested developers and users can go to see the credits?
>
> That way you could simply do an MD5 of the current binary and use that
> fingerprint to see who wrote and contributed to it.  Much like the CDDB
> database takes a track/time fingerprint of CD's and then tells you which
> songs and artist made the CD.

Not an option, since the software is distributed in source and the look
of the binary varies based on operating system, library version, the
compiler used etc.

Also that would prevent you from modifying the source.

Freedom gone and not redistributable within Debian.

Debian actually does do checksums on the packages, but that is for security and prove of
origin reasons.

Kind regards,
Martin List-Petersen
--
"Now we'll have to kill you."
        -- Linus Torvalds

Re: max files

[Stewart Smith]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Tue, 2004-05-04 at 03:47, camis wrote:
> Anyone tested to see how fast/sluggish reiser3 (or 4?)
> performs when accessing a directory that has between
> 5 and 25 million flat/text files?

AFAIK no current file system performs "well" under this scenario. There
is work going on to get better performance for >1million directories on
xfs - but it is a tricky problem.

just as an indicator - for a dir with ~101000 files on reiser3, reading
from disk ('cause this box doesn't have that much memory):

stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
 
real    0m9.403s
user    0m2.190s
sys     0m0.230s

and for repeated runs (i.e. when things are cached):
stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
 
real    0m2.284s
user    0m2.160s
sys     0m0.130s

so it is quite possible that you'll get acceptable performance... at
least for some applications :)

The algorithms will scale, there just may be implementation details
around the place that could make things faster.

I'd say, test it :)
-- 
Stewart Smith (stewart@flamingspork.com)
http://www.flamingspork.com/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: max files

[Vladimir Saveliev]

Hello

On Mon, 2004-05-03 at 21:47, camis wrote:
> Hi All,
> 
> Anyone tested to see how fast/sluggish reiser3 (or 4?)
> performs when accessing a directory that has between
> 5 and 25 million flat/text files?
> 

reiser3 performance at this kind of load depends very much on how do you
create files.
Given you use defaut hash to sort names in directory
for i in `seq 1 25000000000`
do
	touch $i
done
should give you "ls -l"-able fileset

reiser4 is not that sensitive to file names and order of creations.
Although, one can speedup of creation substantially if he creates files
in lexicographic order

> Any past experiences? (dont say use subdirectories ;)
> 
> Cami
> 

Re: max files

[Pierre Etchemaite]

Le Tue, 04 May 2004 08:56:49 +1000, Stewart Smith <stewart@flamingspork.com>
a écrit :

> stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
>  
> real    0m9.403s
> user    0m2.190s
> sys     0m0.230s
> 
> and for repeated runs (i.e. when things are cached):
> stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
>  
> real    0m2.284s
> user    0m2.160s
> sys     0m0.130s

Very bad filesystem test, because ls will sort results by default. Try 
ls -U (unsorted).

Re: max files

[Hans Reiser]

Stewart Smith wrote:

>On Tue, 2004-05-04 at 03:47, camis wrote:
>  
>
>>Anyone tested to see how fast/sluggish reiser3 (or 4?)
>>performs when accessing a directory that has between
>>5 and 25 million flat/text files?
>>    
>>
>
>AFAIK no current file system performs "well" under this scenario. There
>is work going on to get better performance for >1million directories on
>xfs - but it is a tricky problem.
>
>just as an indicator - for a dir with ~101000 files on reiser3, reading
>from disk ('cause this box doesn't have that much memory):
>
>stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
> 
>real    0m9.403s
>user    0m2.190s
>sys     0m0.230s
>
>and for repeated runs (i.e. when things are cached):
>stewart@saturn:~$ time ls Maildir/.Lists.linux-kernel/cur/ > /dev/null
> 
>real    0m2.284s
>user    0m2.160s
>sys     0m0.130s
>
>so it is quite possible that you'll get acceptable performance... at
>least for some applications :)
>
>The algorithms will scale, there just may be implementation details
>around the place that could make things faster.
>
>I'd say, test it :)
>  
>
I would guess that reiser4 would do better at this, as our readdir 
returns files in very close to sorted order.

Of course, that depends on the sorting algorithm ls uses.... some 
sorting algorithms do worse at close to sorted order....