Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

 

 

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


reiser at namesys

Jul 26, 2006, 7:26 AM

Post #76 of 223 (10162 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

David Masover wrote:

>
>
>Although I should mention, Hans, that there is a really good reason to
>prefer the 15 minute patches. The patches that take a week are much
>harder to read during that week than any number of 15 minute incremental
>patches, because the incremental patches are already broken down into
>nice, small, readable, ordered chunks. And since development follows
>some sort of logical, orderly pattern, it can be much easier to read it
>that way than to try to consider the whole.
>
>
No, I disagree, if the code is well commented, it is easier to read the
whole thing at the end when it has its greatest coherence and
refinement. A problem with Reiser4 is that its core algorithms are
simply complex. We pushed the envelope in multiple areas all at once.
Benchmarks don't always suggest simple algorithms are the ones that will
be highest performance. Tree algorithms are notorious in the database
industry for being simple on web pages but complex as code.

Some people program in small increments, some program things that
require big increments of change, both kinds of people are needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 7:28 AM

Post #77 of 223 (10173 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 03:43:26PM +0200, Adrian Bunk wrote:
> My distribution example was just one example of what happens when you
> wrongly try to estimate a marked share based on klive data (and it seems

You're again wrong generalizing. With KLive I can attempt to estimate
market share of _kernel_ code (what Hans did), but you can't attempt
to estimate market share of userland (what you did). It won't be a
smile at the end making your statement right.

The estimate market share of kernel code may not be accurate but it
has some minor significance.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 26, 2006, 7:33 AM

Post #78 of 223 (10167 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

David Masover wrote:

>Hans Reiser wrote:
>
>
>
>>to use as his default. Now that we paid the 5 year development price
>>tag to get everything as plugins, we can now upgrade in littler pieces
>>than any other FS. Hmm, I need a buzz phrase, its not extreme
>>programming, maybe "moderate programming".
>>
This phrase was a bit tongue-in-cheek.

>> Does that sound exciting to
>>
>>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 26, 2006, 7:50 AM

Post #79 of 223 (10186 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 04:28:54PM +0200, andrea [at] cpushare wrote:
> On Wed, Jul 26, 2006 at 03:43:26PM +0200, Adrian Bunk wrote:
> > My distribution example was just one example of what happens when you
> > wrongly try to estimate a marked share based on klive data (and it seems
>
> You're again wrong generalizing. With KLive I can attempt to estimate
> market share of _kernel_ code (what Hans did), but you can't attempt
> to estimate market share of userland (what you did). It won't be a
> smile at the end making your statement right.

No, you can't estimate the market share of kernel code based on klive
data.

Someone said in this thread 'is used by (tens of) thousands of computers
in governmental laboratories the US "national security" depends upon.'

klive will never get any feedback from such users.

But the computer freak using Gentoo and always trying the latest things
like reiser4 is relatively likely to also use klive.

> The estimate market share of kernel code may not be accurate but it
> has some minor significance.

You are able to say that based on klive data, reiser4 has at least
35 users in the world.

But you can not tell based on klive data whether the ratio of
reiser4:ext3 users in the world is more like 1:5, 1:500 or 1:50000.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 9:06 AM

Post #80 of 223 (10188 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 04:50:19PM +0200, Adrian Bunk wrote:
> Someone said in this thread 'is used by (tens of) thousands of computers
> in governmental laboratories the US "national security" depends upon.'

There can be people using reiser4 behind the firewall too, what's the
point? IIRC US .gov even sponsored part of reiser4 development, how do
you know they're not testing it too?

You don't believe KLive has any relation to reality, but you have no
way to proof your claim. JFYI: all statistics only take a sample of
the larger space, the whole point of having a statistic is because you
can't measure the total. The smaller the sample compared to the total,
the less the stats are accurate, but they still have some statistical
significance. And one can always hope that KLive will grow larger.

Last but not the least defining gentoo users as freaks isn't very nice
from your part. For all new startups they're the ideal userbase to
have, and they do a great deal of good work by testing all new stuff
and they help speeding up innovation. Infact I think having a sample
of what those brave users run is more important than the rest, the
rest usually follows the ones living on the edge eventually.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 26, 2006, 9:53 AM

Post #81 of 223 (10172 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 06:06:04PM +0200, andrea [at] cpushare wrote:
> On Wed, Jul 26, 2006 at 04:50:19PM +0200, Adrian Bunk wrote:
> > Someone said in this thread 'is used by (tens of) thousands of computers
> > in governmental laboratories the US "national security" depends upon.'
>
> There can be people using reiser4 behind the firewall too, what's the
> point? IIRC US .gov even sponsored part of reiser4 development, how do
> you know they're not testing it too?

I don't know.

The klive data might be inaccurate in any direction.

In this case I'd suspect an inaccuraty in one specific direction.

> You don't believe KLive has any relation to reality, but you have no
> way to proof your claim. JFYI: all statistics only take a sample of
> the larger space, the whole point of having a statistic is because you
> can't measure the total. The smaller the sample compared to the total,
> the less the stats are accurate, but they still have some statistical
> significance. And one can always hope that KLive will grow larger.

Size isn't everything.
The problem is getting an accurate sample of data.


Let me try to make the problem clearer by making an example:

Consider you want to know the ratio between housewifes and women with a
job for women aged between 30 and 40.

Consider you get your data by asking women in shopping malls between
10 and 11 o'clock in the morning on workdays.

Do you understand why the result might be quite different from the
actual ratio?

Do you understand why asking a million women in shopping malls between
10 and 11 o'clock in the morning on workdays wouldn't make the data
better?


And do you know the Linux Counter at [1]?

I remember several years ago Debian had some default setting in
some package to send reports there.

smail was at that times the default Debian MTA, and therefore also the
most popular MTA at the Linux counter...

> Last but not the least defining gentoo users as freaks isn't very nice
> from your part. For all new startups they're the ideal userbase to
> have, and they do a great deal of good work by testing all new stuff

Please read carefully what I said.

I did NOT say:
"All Gentoo users are freaks."

It was more (implicitely) in the direction:
"Many freaks use Gentoo."

The latter is IMHO not that far from reality.

And "freak" wasn't meant negative.

> and they help speeding up innovation. Infact I think having a sample
> of what those brave users run is more important than the rest, the
> rest usually follows the ones living on the edge eventually.

The majority of user will use the filesystem their distribution offers
as default, no matter what people living on the edge today will use...

cu
Adrian

[1] http://counter.li.org/

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bfields at fieldses

Jul 26, 2006, 10:02 AM

Post #82 of 223 (10177 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 06:06:04PM +0200, andrea [at] cpushare wrote:
> JFYI: all statistics only take a sample of the larger space, the whole
> point of having a statistic is because you can't measure the total.
> The smaller the sample compared to the total, the less the stats are
> accurate

Definitely not true in general. If I wanted to know the gender ratio at
the latest OLS I'd take the results from a sample of a dozen chosen
randomly over the results from a sample of hundreds all taken from the
men's room.

For exactly the same quality of sampling, yes, the larger the better,
but the point of diminishing returns comes pretty quickly. So given
limited resources it's probably more important to work on the quality of
the sample rather than on its size....

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 10:20 AM

Post #83 of 223 (10155 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 01:02:36PM -0400, J. Bruce Fields wrote:
> On Wed, Jul 26, 2006 at 06:06:04PM +0200, andrea [at] cpushare wrote:
> > JFYI: all statistics only take a sample of the larger space, the whole
> > point of having a statistic is because you can't measure the total.
> > The smaller the sample compared to the total, the less the stats are
> > accurate
>
> Definitely not true in general. If I wanted to know the gender ratio at
> the latest OLS I'd take the results from a sample of a dozen chosen
> randomly over the results from a sample of hundreds all taken from the
> men's room.

Well, your example is perhaps the worst one since you wouldn't be
decreasing the quality of your stats very much by only doing the
sample in the men's room ;). I guess you meant the woman's room.

> For exactly the same quality of sampling, yes, the larger the better,
> but the point of diminishing returns comes pretty quickly. So given
> limited resources it's probably more important to work on the quality of
> the sample rather than on its size....

No matter how you see it, the larger the better (in the worst case it
won't make a difference). Certainly if I could work on the quality,
that would be more important than adding 1 more user. But I can't work
on the quality.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


cattelan at thebarn

Jul 26, 2006, 11:16 AM

Post #84 of 223 (10173 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, 2006-07-26 at 08:26 -0600, Hans Reiser wrote:
> David Masover wrote:
>
> >
> >
> >Although I should mention, Hans, that there is a really good reason to
> >prefer the 15 minute patches. The patches that take a week are much
> >harder to read during that week than any number of 15 minute incremental
> >patches, because the incremental patches are already broken down into
> >nice, small, readable, ordered chunks. And since development follows
> >some sort of logical, orderly pattern, it can be much easier to read it
> >that way than to try to consider the whole.
> >
> >
> No, I disagree, if the code is well commented, it is easier to read the
> whole thing at the end when it has its greatest coherence and
> refinement. A problem with Reiser4 is that its core algorithms are
> simply complex. We pushed the envelope in multiple areas all at once.
> Benchmarks don't always suggest simple algorithms are the ones that will
> be highest performance. Tree algorithms are notorious in the database
> industry for being simple on web pages but complex as code.
>
> Some people program in small increments, some program things that
> require big increments of change, both kinds of people are needed.
>
FWIW I think both points are valid.

Personally I find it difficult to completely stop what I'm doing
and spend several days studying a large patch/complete new subsystem.

But on the other hand it's important that code that goes in the kernel
gets a proper review, I think we all come to rely on the gatekeepers job
of making sure any given part of the kernel does not destabilize to the
point were it interferes with our individual areas of development.

So exactly what level of granularity is appropriate for changes? Well
that should probably be left of to the gatekeeper for each particular
area. In the case of filesystems generic vfs changes obviously need to
be small and easy to digest, and more importantly easy to bisect
regressions. The core of the file system can be left to the person who
can best manage the code, but hopefully that person applies a reasonable
of granularity to the changes, thus allowing non familiar developers to
at least keep up and possibly make helpful suggestions.

If we look at the current "beliefs" surrounding XFS you can see the
affects of a code base that did not have an incremental development with
regards to linux anyways. Ok so ya XFS was a close sourced IRIX FS for
the first 8 years of it's life, and even once the Linux project started
there was another year or so encumbrance investigation and cleaning
before legal would sign off on its release.
So to this day the major hang up with XFS seems to be "it's to complex
because it has x thousands lines of code". Hell by that argument Linux
has way more lines of code than IRIX could ever hope to have and is
therefore Linux is more complex than IRIX and to hard to understand. :-)
Fortunately many developers (especially ones that have worked on other
OS's) do not use "wc -l" as a tool to measure code
quality/readability/complexity.
XFS unfortunately will probably always suffer from skepticism since
it did not grow up in in Linux.

Guess it's sort of like adopting a 8 year old child vs a new born, hard
to tell what happened in first 8 years.

-Russell Cattelan
cattelan [at] xfs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


buddy.lucas at gmail

Jul 26, 2006, 11:54 AM

Post #85 of 223 (10175 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 7/26/06, Bernd Eckenfels <be-news06 [at] lina> wrote:
>
> Matthias Andree <matthias.andree [at] gmx> wrote:
> > But the assertion that some backup was the cause for inode exhaustion on
> > ext? is not very plausible since hard links do not take up inodes,
> > symlinks are not backups and everything else requires disk blocks. So,
> > since reformatting ext2/ext3 to one inode per block is possible
> > (regardless of disk capacity), I see no way how a reformatted file
> > system might run out of inodes before it runs out of blocks.
>
> Well I had actually the problem on a tmpfs where I had too many zero byte
> files...

Yes, I once ran out of inodes because logrotate kept rotating and
compressing already compressed and empty logfiles. I can't remember
how many seconds it took me to add 'df -i' to our monitoring system.

This, however, was not a feature of the software. I assume.

So, any company that considers the remote possibility of seeking a
$250,000 solution, where the alternative is to buy a 36GB hard drive,
please give me a call.


Cheers,
Buddy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ngc891 at gmail

Jul 26, 2006, 12:01 PM

Post #86 of 223 (10174 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On 7/27/06, andrea [at] cpushare <andrea [at] cpushare> wrote:
> On Wed, Jul 26, 2006 at 01:02:36PM -0400, J. Bruce Fields wrote:
> > On Wed, Jul 26, 2006 at 06:06:04PM +0200, andrea [at] cpushare wrote:
> > > JFYI: all statistics only take a sample of the larger space, the whole
> > > point of having a statistic is because you can't measure the total.
> > > The smaller the sample compared to the total, the less the stats are
> > > accurate
> >
> > Definitely not true in general. If I wanted to know the gender ratio at
> > the latest OLS I'd take the results from a sample of a dozen chosen
> > randomly over the results from a sample of hundreds all taken from the
> > men's room.
>
> Well, your example is perhaps the worst one since you wouldn't be
> decreasing the quality of your stats very much by only doing the
> sample in the men's room ;). I guess you meant the woman's room.
>
> > For exactly the same quality of sampling, yes, the larger the better,
> > but the point of diminishing returns comes pretty quickly. So given
> > limited resources it's probably more important to work on the quality of
> > the sample rather than on its size....
>
> No matter how you see it, the larger the better (in the worst case it
> won't make a difference). Certainly if I could work on the quality,
> that would be more important than adding 1 more user. But I can't work
> on the quality.

Maybe you could try pushing the use of klive by some distros arguing
it's "a way of getting usage statistics in order to improve kernel
quality and hardware support". I mean, not just an extra package but a
service launch at the first boot so anyone can use it.

klive is a nice project, it just needs more _different_ users and
maybe, a support of some distros.

Maybe, you could try add a page in the klive wiki for putting packages
and RPMs of klive for several distros ? What do you think ? It's a
first step to get it merge into distros.

In my case, I got some .tgz that feel lonely...

Maybe be in 2 years, we will know EXACTLY of much people use
EXT4/Reiser5/CoincoinFS/CrashFS...

--
Jerome Pinot
http://ngc891.blogdns.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 1:50 PM

Post #87 of 223 (10147 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Removed some people from CC since we're quickly changing topic and I
doubt they're interested.

On Thu, Jul 27, 2006 at 04:01:02AM +0900, Jerome Pinot wrote:
> Maybe you could try pushing the use of klive by some distros arguing
> it's "a way of getting usage statistics in order to improve kernel
> quality and hardware support". I mean, not just an extra package but a
> service launch at the first boot so anyone can use it.
>
> klive is a nice project, it just needs more _different_ users and
> maybe, a support of some distros.

That would be nice yes. KLive is already supported by Gentoo that
created a proper emerge package, that's why there are so many gentoo
kernels being tracked. Others are of course welcome. I'm open to
suggestions on extending it as well.

At the moment the todo list is like this:

1) create an optional http transport to pass through most firewalls
2) send a packet when system reboots so I can track which sessions
didn't cleanly reboot (it's not reliable if you disconnect
from the internet first and you shutdown later, but it's better
than nothing)
3) send the oops from kernel to klive server, so no oopses will be
lost and I can use the pciids details to track down bad hardware
as well
4) possibly send info on usb buses too and not only about the pci buses

> Maybe, you could try add a page in the klive wiki for putting packages
> and RPMs of klive for several distros ? What do you think ? It's a
> first step to get it merge into distros.

If more distros will pickup KLive that will help like demonstrated by
the emerge package from gentoo.

It's already very simple to install klive, I wrote an universal
installer that runs on any flavour of any weird distro out there:

wget klive.cpushare.com/klive.sh
sh klive.sh --install

If you don't want it anymore:

sh klive.sh --uninstall

that's it.

The rpm/deb packages would be just to make life easier for distro to
pick it up but I hoped they had the resources to do the packaging work
themself...

Perhaps once I'll create the CPUShare rpm/deb packages I'll be easy to
share the work to create the KLive ones too. As far as spare time work
goes, CPUShare currently has a much higher prio than KLive, and I'm
not yet at the point of creating rpm/deb packages, now that CPUShare
transaction works and you can already compute remotely, I'm currently
fighting with the paypal sendbox so I can start accepting cash into
the system ASAP. But the hardest part of the ebusiness side of
CPUShare is the handling of the invoicing and receipts generation
which is a non computer related problem. I almost solved it though.

> In my case, I got some .tgz that feel lonely...

The .tgz is only for the ones interested hacking or studying it (both
client and server). You should be using the .sh script above.

Also note, the export of the whole database isn't available on the
site, but I've no problem to publish it after filtering out all the ip
addresses (which are collected only for purely paranoid security
purposes, and tor doesn't route udp traffic).

> Maybe be in 2 years, we will know EXACTLY of much people use
> EXT4/Reiser5/CoincoinFS/CrashFS...

BTW, CPUShare records a lot more than the fs already. 2 years or more,
but I'm not in a hurry. The server will also soon require some caching
trick to avoid recomputing the queries every time you click on
it. Current KLive is the best I could do in a very little time I spent
on it, it works well, but it still has an huge room for
improvement. Also note, so far KLive logged 76989 cumulative days of
uptime. When I see a number like that my mind thinks at the energy
that can be recycled if all that time recorded on KLive would be
routed inside CPUShare. That's why for me it's more urgent to give a
chance to those brave 500 users to cash in with CPUShare than to push
KLive beyond its current status ;). In due time KLive will get more
attention too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 26, 2006, 1:50 PM

Post #88 of 223 (10157 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 07:20:29PM +0200, andrea [at] cpushare wrote:
> On Wed, Jul 26, 2006 at 01:02:36PM -0400, J. Bruce Fields wrote:
>...
> > For exactly the same quality of sampling, yes, the larger the better,
> > but the point of diminishing returns comes pretty quickly. So given
> > limited resources it's probably more important to work on the quality of
> > the sample rather than on its size....
>
> No matter how you see it, the larger the better (in the worst case it
> won't make a difference). Certainly if I could work on the quality,
> that would be more important than adding 1 more user. But I can't work
> on the quality.

But depending on the nature of the error, the worst case might be the
common case (as I've already explained in another email).

If you can't ensure the quality of your data, please don't use this data
to wrongly draw any conclusions from them [1].

cu
Adrian

[1] the conclusion itself might or might not be true
e.g. there _could_ be an 1:5 ratio between reiser4 and ext3 users
but your data is not in any way able to support or reject this
statement

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 2:17 PM

Post #89 of 223 (10150 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 10:50:22PM +0200, Adrian Bunk wrote:
> But depending on the nature of the error, the worst case might be the
> common case (as I've already explained in another email).
>
> If you can't ensure the quality of your data, please don't use this data
> to wrongly draw any conclusions from them [1].

Please read the footer of the KLive pages:

"The use of the information and of the software in this website is at
your own risk. KLive probably doesn't represent a reliable sample of
the real usage of the Linux Kernel."

Said that pretending that KLive data has absolutely no significance at
all and that you can't draw any conclusion at all from it, to me seems
as wrong as pretending it to perfect.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bfields at fieldses

Jul 26, 2006, 2:37 PM

Post #90 of 223 (10163 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 11:17:41PM +0200, andrea [at] cpushare wrote:
> Said that pretending that KLive data has absolutely no significance at
> all and that you can't draw any conclusion at all from it, to me seems
> as wrong as pretending it to perfect.

This is where we disagree. It may be wrong, but it's certainly not
nearly *as* wrong....

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andrea at cpushare

Jul 26, 2006, 3:17 PM

Post #91 of 223 (10169 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 05:37:57PM -0400, J. Bruce Fields wrote:
> This is where we disagree. It may be wrong, but it's certainly not
> nearly *as* wrong....

;)

My point of view in saying you can't dismiss the current KLive stats
completely, is simply that I didn't expect reiser4 numbers to be so
high even in the small sample of the brave KLive project that is full
of people willing to test new stuff (also note that I compared it to
isofs, I didn't attempt a comparison with ext3 myself). That makes it
a positive in my view.

If you think KLive numbers aren't a positive point for reiser4, then
it can only mean you expected them to be even higher than they were...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ninja at slaphack

Jul 26, 2006, 6:19 PM

Post #92 of 223 (10173 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Russell Cattelan wrote:

> Guess it's sort of like adopting a 8 year old child vs a new born, hard
> to tell what happened in first 8 years.

And, by that token, the newborn is sometimes preferable. It hasn't had
time to develop severe emotional problems, it's physically harmless, and
you get to help it form its ideas and beliefs.

On the other hand, the 8 year old is potty trained, you won't have to
change a single diaper, it's intelligent and makes you question things,
it understands what you want it to do...

So, it depends what kind of developer you are, what kind of gatekeeper,
and what kind of project it is. I still believe in releasing early and
often, but I can see many reasons not to. Some are financial -- Namesys
is trying to operate a business, so any features they open up too early
could be that much harder to sell as a commercial product. The
repacker, for instance.

I'm not arguing for closed source, I'm just saying that once you open,
there's no going back. Many times it's a good thing, but sometimes you
want to wait and see.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ninja at slaphack

Jul 26, 2006, 6:29 PM

Post #93 of 223 (10183 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Matthias Andree wrote:
> On Tue, 25 Jul 2006, David Masover wrote:
>
>> Matthias Andree wrote:
>>> On Tue, 25 Jul 2006, Denis Vlasenko wrote:
>>>
>>>> I, on the contrary, want software to impose as few limits on me
>>>> as possible.
>>> As long as it's choosing some limit, I'll pick the one with fewer
>>> surprises.
>> Running out of inodes would be pretty surprising for me.
>
> No offense: Then it was a surprise for you because you closed your eyes
> and didn't look at df -i or didn't have monitors in place.

Or because my (hypothetical) business exploded before I had the chance.

After all, you could make the same argument about bandwidth, until you
get Slashdotted. Surprise!

> There is no way to ask how many files with particular hash values you
> can still stuff into a reiserfs 3.X. There, you're running into a brick
> wall that only your forehead will "see" when you touch it.

That's true, so you may be correct about "less" surprises. So, it
depends which is more valuable -- fewer surprises, or fewer limits?

That's not a hypothetical statement, and I don't really know. I can see
both sides of this one. But I do hope that once Reiser4 is stable
enough for you, it will be predictable enough.

> But the assertion that some backup was the cause for inode exhaustion on
> ext? is not very plausible since hard links do not take up inodes,
> symlinks are not backups and everything else requires disk blocks. So,

Ok, where's the assertion that symlinks are not backups? Or not used in
backup software? What about directories full of hardlinks -- the dirs
themselves must use something, right?

Anyway, it wasn't my project that hit this limit.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


reiser at namesys

Jul 26, 2006, 9:35 PM

Post #94 of 223 (10175 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Adrian Bunk wrote:

>[1] the conclusion itself might or might not be true
> e.g. there _could_ be an 1:5 ratio between reiser4 and ext3 users
> but your data is not in any way able to support or reject this
> statement
>
>
It does however suggest that my surprise at how people at the last
Linux Conference I went to all seemed to know that there exists a
Reiser4 may be due to it being more widely used than I would have
guessed. Maybe there is some coolness factor to having the faster FS
that you can't get from any Distro that is enough to overcome the hassle
of compiling reiser4progs and a kernel before inserting the DVD. I
would not have guessed we had 1/5th of ext3's usage even among lkml
readers..... I guess the market contains more people who like
technology than I was guessing. Maybe there is a positive word of mouth
effect going on too.

It would be nice if SuSE and others at least made it an unsupported
option at install time. I shall have to find the time to go asking them
all.....

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 26, 2006, 11:56 PM

Post #95 of 223 (10185 views)
Permalink
Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Wed, Jul 26, 2006 at 11:17:41PM +0200, andrea [at] cpushare wrote:
> On Wed, Jul 26, 2006 at 10:50:22PM +0200, Adrian Bunk wrote:
> > But depending on the nature of the error, the worst case might be the
> > common case (as I've already explained in another email).
> >
> > If you can't ensure the quality of your data, please don't use this data
> > to wrongly draw any conclusions from them [1].
>
> Please read the footer of the KLive pages:
>
> "The use of the information and of the software in this website is at
> your own risk. KLive probably doesn't represent a reliable sample of
> the real usage of the Linux Kernel."

It was you who wrongly said:
"With KLive I can attempt to estimate market share of _kernel_ code"

Hadn't you read your own disclaimer?

> Said that pretending that KLive data has absolutely no significance at
> all and that you can't draw any conclusion at all from it, to me seems
> as wrong as pretending it to perfect.

Possibly wrong conclusions about the general market share based on data
not having the quality for being the basis of such statements are worse
than having no data.

Every time someone will repeat the "1:5 ratio for reiser4:ext3 users",
this will be an additional proof it's really worse than no data.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


genoni at sns

Jul 27, 2006, 1:33 AM

Post #96 of 223 (10157 views)
Permalink
Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Thu, July 27, 2006 08:56, Adrian Bunk wrote:
>
>> Said that pretending that KLive data has absolutely no significance at
>> all and that you can't draw any conclusion at all from it, to me seems as
>> wrong as pretending it to perfect.
>
> Possibly wrong conclusions about the general market share based on data
> not having the quality for being the basis of such statements are worse than
> having no data.

Am I missing something, or it is not marketing what we are talking about?
please I do not understand your point.

For what I understand... I was not supposing reiser4 users to be so mutch,
but this is very usefull because this means that there are more
possibilities to test the code well and to fix bugs...

This also means that there are people who feels the need of this filesystem
for their work because they are not satisfied with the other filesystems, or
because anyway with reiser4 they see that they get better results about the
work they need to be done.
And this is probably the most important point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 27, 2006, 3:04 AM

Post #97 of 223 (10179 views)
Permalink
Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Thu, Jul 27, 2006 at 10:33:12AM +0200, Luigi Genoni wrote:
>
>
>
> On Thu, July 27, 2006 08:56, Adrian Bunk wrote:
> >
> >> Said that pretending that KLive data has absolutely no significance at
> >> all and that you can't draw any conclusion at all from it, to me seems as
> >> wrong as pretending it to perfect.
> >
> > Possibly wrong conclusions about the general market share based on data
> > not having the quality for being the basis of such statements are worse than
> > having no data.
>
> Am I missing something, or it is not marketing what we are talking about?
> please I do not understand your point.
>
> For what I understand... I was not supposing reiser4 users to be so mutch,
> but this is very usefull because this means that there are more
> possibilities to test the code well and to fix bugs...
>...

I'm sorry for saying it that directly, and this is not meant against you
personally:

Your statement is a good example why this data is worse than having no
data.

As I already said in this thread:

<-- snip -->

You are able to say that based on klive data, reiser4 has at least
35 users in the world.

But you can not tell based on klive data whether the ratio of
reiser4:ext3 users in the world is more like 1:5, 1:500 or 1:50000.

<-- snip -->

I can't prove that the 1:5 ratio is wrong, but the point is that
claiming a 1:5 ratio was true based on the klive data is not better than
claiming it based on no data. But claiming it based on the klive data is
worse since people like you are getting the wrong impression it was
based on data that would have the quality for supporting such a
statement.

The data simply has not the quality for such a statement.
Please read my two examples in [1] if you want to get an impression why
such problems can occur.

cu
Adrian

[1] http://lkml.org/lkml/2006/7/26/203

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


genoni at sns

Jul 27, 2006, 4:07 AM

Post #98 of 223 (10177 views)
Permalink
Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

Still I am missing something.

I am not interested in discussing about 1:5 ora 5:1 or so on.
I am not even interested if reiser4 users are 35 or 35000.
But if some people felt they need reiser4 to get their work done, that means
something. The numbers and the datum per se are meaningless.

Anyway you have a datum.
Some people need reiser4, period.

Why they need reiser4?
all of them are just playing with him to have a new game for their spare time?
I don't think so.
Some of them are using reiser4 because it is the best solution for their work?
this is a concrete possibility.

again... why that?
Because the other FSs are not suitable for certain work?
Because the other FSs are suitable, but reiser4 offers better results?
Because even reiser4 is not complitelly suitable for some kind of work, but
the other FSs are a worser solution?

I don't think most reiser4 users decided to give it a try just to enjoy
their time making tests just because they are curious.

that does not mean reiser4 should be merged into linux kernel because of
this. On the other side you can agree reiser4 has its place, because there
are users who need it. What we would need to understand, sine ira nec
studio, is where this place is.

On Thu, July 27, 2006 12:04, Adrian Bunk wrote:
> On Thu, Jul 27, 2006 at 10:33:12AM +0200, Luigi Genoni wrote:
>
>>
>>
>>
>> On Thu, July 27, 2006 08:56, Adrian Bunk wrote:
>>
>>>
>>>> Said that pretending that KLive data has absolutely no significance
>>>> at all and that you can't draw any conclusion at all from it, to me
>>>> seems as wrong as pretending it to perfect.
>>>
>>> Possibly wrong conclusions about the general market share based on data
>>> not having the quality for being the basis of such statements are
>>> worse than having no data.
>>
>> Am I missing something, or it is not marketing what we are talking about?
>> please I do not understand your point.
>>
>> For what I understand... I was not supposing reiser4 users to be so
>> mutch, but this is very usefull because this means that there are more
>> possibilities to test the code well and to fix bugs... ...
>>
>
> I'm sorry for saying it that directly, and this is not meant against you
> personally:
>
>
> Your statement is a good example why this data is worse than having no
> data.
>
> As I already said in this thread:
>
>
> <-- snip -->
>
>
> You are able to say that based on klive data, reiser4 has at least
> 35 users in the world.
>
>
> But you can not tell based on klive data whether the ratio of
> reiser4:ext3 users in the world is more like 1:5, 1:500 or 1:50000.
>
>
> <-- snip -->
>
>
> I can't prove that the 1:5 ratio is wrong, but the point is that
> claiming a 1:5 ratio was true based on the klive data is not better than
> claiming it based on no data. But claiming it based on the klive data is
> worse since people like you are getting the wrong impression it was based on
> data that would have the quality for supporting such a statement.
>
> The data simply has not the quality for such a statement.
> Please read my two examples in [1] if you want to get an impression why
> such problems can occur.
>
> cu Adrian
>
>
> [1] http://lkml.org/lkml/2006/7/26/203
>
>
> --
>
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days. "Only a promise,"
> Lao Er said.
> Pearl S. Buck - Dragon Seed
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo [at] vger More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


bunk at stusta

Jul 27, 2006, 4:35 AM

Post #99 of 223 (10167 views)
Permalink
Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

On Thu, Jul 27, 2006 at 01:07:27PM +0200, Luigi Genoni wrote:

> Still I am missing something.
>
> I am not interested in discussing about 1:5 ora 5:1 or so on.
> I am not even interested if reiser4 users are 35 or 35000.
> But if some people felt they need reiser4 to get their work done, that means
> something. The numbers and the datum per se are meaningless.
>...

You answered to an email where I talked about the wrong assumption the
klive data could support the 1:5 market share claim.

This is completely independent from discussions about why users might
need reiser4, or which technical or social problems prevent its merging
(unless of course someone wants to justify its merging wrongly with the
1:5 claim), and therefore your answer does not apply to this part of
the thread.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


genoni at sns

Jul 27, 2006, 4:43 AM

Post #100 of 223 (10190 views)
Permalink
Re: the ' 'official' point of view' expressed by kernelnewbies.org regarding reiser4 inclusion [In reply to]

I answered a mail about how klive data should not be took in account, and
could even be dangerous...


On Thu, July 27, 2006 13:35, Adrian Bunk wrote:
> On Thu, Jul 27, 2006 at 01:07:27PM +0200, Luigi Genoni wrote:
>
>
>> Still I am missing something.
>>
>>
>> I am not interested in discussing about 1:5 ora 5:1 or so on.
>> I am not even interested if reiser4 users are 35 or 35000.
>> But if some people felt they need reiser4 to get their work done, that
>> means something. The numbers and the datum per se are meaningless. ...
>>
>
> You answered to an email where I talked about the wrong assumption the
> klive data could support the 1:5 market share claim.
>
> This is completely independent from discussions about why users might
> need reiser4, or which technical or social problems prevent its merging
> (unless of course someone wants to justify its merging wrongly with the
> 1:5 claim), and therefore your answer does not apply to this part of
> the thread.
>
> cu Adrian
>
>
> --
>
>
> "Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days. "Only a promise,"
> Lao Er said.
> Pearl S. Buck - Dragon Seed
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 3 4 5 6 7 8 9 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.