Re: reiser4 vs politics: linux misses out again
Horst von Brand ([EMAIL PROTECTED]): > Erik Hensema <[EMAIL PROTECTED]> wrote: >> Horst von Brand ([EMAIL PROTECTED]): >> [on reiserfs4] >> >> >> and _can_ do things >> >> >> no other FS can > >> > Mostly useless things... > >> Depends on your point of view. If you define things to be useful >> only when POSIX requires them, then yes, reiser4 contains a lot >> of useless stuff. > > That isn't my definition. Ok. It seems to be the definition of some people over here tough. >> However, it's the 'beyond POSIX'-stuff what makes reiser4 >> interesting. > > I haven't seen a shred of evidence of that up to here. Just redoing > in-kernel (for completely inscrutable reasons) stuff that has been > confortably done in userland for many years isn't "Interesting", quite the > contrary. Some things simply need to be done inside the kernel for atomicity, especially when mixing 'normal' posix applications with apps using extended semantics. >> Multistream files have been useful on other OSses for years. > > I only have seen other OSes moving away from such stuff... That would be OSX I guesss. >> They >> might be useful on Linux too (Samba will surely like them). > > OK, if you think Windows is a good idea all around... Windows is a fact of life, like it or not. Every Linux+Samba server replacing a Win2k3 server is a win, IMHO. >> The plugin architecture is very interesting. > > Again: It isn't "plugins", it's "kernel configuration options redefining > the filesystem layout". And that is extremely toxic: If the claims are to > be believed, somebody using ReiserFS 4 could end up using filesystems as > widely different as ext3 and ufs today. Both called the same. Or everybody > will end up using the exact same set of "plugins", so they make no sense as > configuration options. Sure, it is nice to have different versions of the > same filesystem (in a way, ext3 is a version of ext2; in ext3 there are > some options that where introduced later, and some of which aren't > backwards-compatible), but this is not something I would want each > individual user screw around with willy-nilly. So the whole "plugin" idea > is very questionable to me. Not every plugin changes the filesystem layout. Plugins can also change higher level APIs. Changing the filesystem layout is quite dangerous indeed. Hans, is a list of required plugins stored in the superblock? >> need files to be in the POSIX namespace. > > The POSIX namespace /is/ the namespace for files. It doesn't need to be the namespace for _all_ files. >> Why would you want to >> store a mysql database in files? > > Because it is the abstraction of permanent storage that the OS gives me. Or > I could write them directly on a raw block device for performance (by > cutting out a middleman). Reiser4 could offer you a differend kind of abstraction. I don't know if it would be useful in the mysql case, I don't write database software. Mysql is just a random example of software needing to store data somewhere. The data is only accessable through the mysql api. Backing up the files is useles when the server is running. > >> Why not skip the overhead of the >> VFS and POSIX rules and just store them in a more efficient way? > > Exactly. Cut out the filesystem. > >> Maybe you can create a swapfile plugin. > > The kernel manages swapping on files and devices just fine, thank you. Just a random example. >> No need for a swapfile to >> be in the POSIX namespace either. > > And how do you handle it if it has no filename?! mkswap --kind=reiser4fsswap --operation=create whatever. >> It's just a fun thing to experiment with. > > Noone here is stopping you from experimenting. > >> It's not always >> nescesary to let the demand create the means. Give programmers >> some powerful tools and wait and see what wonderful things start >> to evolve. > > The sad truth is that if you give a random collection of people powerful > tools they misuse them more often than not, creating a huge mess in the > process. That is why it is so hard to design good tools. Agreed. That's why you need to experiment. >> And yes, maybe in ten years time POSIX is just a subsystem in >> Linux. Maybe commerciale Unix vendors will start following Linux >> as 'the' standard instead of the other way around. Seems fun to >> me :-) > > To me too. But forcing Linux today to be as non-POSIX as possible, just so > it will be prepared for 10 years in the future makes no sense, because you > break it /now/. Linux will still be posix. video4linux isn't posix either. I don't see why access to data stores should be posix all the time. >> I think this debate will mostly boil down to 'do we want to >> experiment with beyond-POSIX filesystems in linux?'. > > You
Re: reiser4 vs politics: linux misses out again
Jim Crilly wrote: > >I thought r3 was journaled from the beginning; the Namesys site credits >Chris with the addition of a relocated and large journal. And yes, a good >bit of the patches were from him. > Chris and I disagree about QA methodology, but I am deeply in debt to him for his contributions. R3 did not have a journal at first, that was his contribution, and a major part of what made reiserfs useful to real users. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
Horst von Brand wrote: > > > > >> It's not always >>nescesary to let the demand create the means. Give programmers >>some powerful tools and wait and see what wonderful things start >>to evolve. >> >> > >The sad truth is that if you give a random collection of people powerful >tools they misuse them more often than not, creating a huge mess in the >process. That is why it is so hard to design good tools. > > We are rope makers. Our job is to make good rope. If someone might use it to hang dissidents, that does not mean we should now make the rope too inflexible to form a noose. It is important that we know our place. Our place is to help users express themselves the way they want to. It is not our job to keep them from hanging dissidents. If they hang dissidents, we should not change the way we make rope, we should shoot them. Most of our users don't hang dissidents, to the contrary, they do work of value to society, and need their time saved so that they can do more of it. The users of reiser4 know a lot more than I do, and are much wiser than I am. Because I focus on a narrow little area, I am able to do something useful to help them express their greater wisdom more flexibly. I take pride in that. The belief expressed above that powerful tools will be misused more than well used, and the dislike of power for the users it contains, is why we will never do more than talk past each other. Perhaps we should just agree to disagree. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
Erik Hensema <[EMAIL PROTECTED]> wrote: > Horst von Brand ([EMAIL PROTECTED]): > [on reiserfs4] > >> >> and _can_ do things > >> >> no other FS can > > Mostly useless things... > Depends on your point of view. If you define things to be useful > only when POSIX requires them, then yes, reiser4 contains a lot > of useless stuff. That isn't my definition. > However, it's the 'beyond POSIX'-stuff what makes reiser4 > interesting. I haven't seen a shred of evidence of that up to here. Just redoing in-kernel (for completely inscrutable reasons) stuff that has been confortably done in userland for many years isn't "Interesting", quite the contrary. > Multistream files have been useful on other OSses for years. I only have seen other OSes moving away from such stuff... > They > might be useful on Linux too (Samba will surely like them). OK, if you think Windows is a good idea all around... > The plugin architecture is very interesting. Again: It isn't "plugins", it's "kernel configuration options redefining the filesystem layout". And that is extremely toxic: If the claims are to be believed, somebody using ReiserFS 4 could end up using filesystems as widely different as ext3 and ufs today. Both called the same. Or everybody will end up using the exact same set of "plugins", so they make no sense as configuration options. Sure, it is nice to have different versions of the same filesystem (in a way, ext3 is a version of ext2; in ext3 there are some options that where introduced later, and some of which aren't backwards-compatible), but this is not something I would want each individual user screw around with willy-nilly. So the whole "plugin" idea is very questionable to me. > Sometimes you don't > need files to be in the POSIX namespace. The POSIX namespace /is/ the namespace for files. > Why would you want to > store a mysql database in files? Because it is the abstraction of permanent storage that the OS gives me. Or I could write them directly on a raw block device for performance (by cutting out a middleman). > Why not skip the overhead of the > VFS and POSIX rules and just store them in a more efficient way? Exactly. Cut out the filesystem. > Maybe you can create a swapfile plugin. The kernel manages swapping on files and devices just fine, thank you. > No need for a swapfile to > be in the POSIX namespace either. And how do you handle it if it has no filename?! > It's just a fun thing to experiment with. Noone here is stopping you from experimenting. > It's not always > nescesary to let the demand create the means. Give programmers > some powerful tools and wait and see what wonderful things start > to evolve. The sad truth is that if you give a random collection of people powerful tools they misuse them more often than not, creating a huge mess in the process. That is why it is so hard to design good tools. > And yes, maybe in ten years time POSIX is just a subsystem in > Linux. Maybe commerciale Unix vendors will start following Linux > as 'the' standard instead of the other way around. Seems fun to > me :-) To me too. But forcing Linux today to be as non-POSIX as possible, just so it will be prepared for 10 years in the future makes no sense, because you break it /now/. > I think this debate will mostly boil down to 'do we want to > experiment with beyond-POSIX filesystems in linux?'. You (and some others) clearly want to. More power to the bunch that comes up with clean semantics that can be implemented efficiently and are useful in real life (as opposed to "it would be oh-so-nice to also have $FEATURE for my pet $NICHE_CASE, feature for which I just can't be bothered considering ramifications at all"). Before going off look up "featuritis" (and consider how it all but killed off a lot of OSes, even many Unix variants, and uncountable other things too). > Clearly we don't _need_ it now. There simply are no users. But > will users come when reiser4 is merged? Nobody knows. Probably a tiny minority. Something like the following ReiserFS 3 has today. > IMHO reiser4 should be merged and be marked as experimental. IMHO ReiserFS 4 should not be merged into Linus' kernel. So what? It is not my call (nor yours). > It > should probably _always_ be marked as experimental, because we > _know_ we're going to need some other -- more generic -- API when > we decide we like the features of reiser4. The reiser4 APIs > should probably be implemented as generic VFS APIs. But since we > don't know yet what features we're going to use, let reiser4 be > self contained. Maybe reiser5 or reiser6 will follow standard > VFS-bey
Re: reiser4 vs politics: linux misses out again
On 07/11/05 07:09:46AM -0400, Ed Tomlinson wrote: > On Sunday 10 July 2005 20:01, Ed Cogburn wrote: > > Jim Crilly wrote: > > > > > But in most of the changesets on the bkbits site you can go back over 2 > > > years and not see anything from namesys people. Nearly all of the fixes > > > commited in the past 2-3 years are from SuSe. > > With Chris Mason's name attached? Chris wrote the journaling support for R3 > and worked for SUSE for a while (he may still?). I also remember seeing > quite > a few patches run though the reiser mailing list for comment... > I thought r3 was journaled from the beginning; the Namesys site credits Chris with the addition of a relocated and large journal. And yes, a good bit of the patches were from him. Jim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Sunday 10 July 2005 20:01, Ed Cogburn wrote: > Jim Crilly wrote: > > > But in most of the changesets on the bkbits site you can go back over 2 > > years and not see anything from namesys people. Nearly all of the fixes > > commited in the past 2-3 years are from SuSe. With Chris Mason's name attached? Chris wrote the journaling support for R3 and worked for SUSE for a while (he may still?). I also remember seeing quite a few patches run though the reiser mailing list for comment... > So, for the sake of argument, if IBM were to drop official support for JFS, > we'd yank JFS out of the kernel even if there was someone else willing to > support it? Why does it now *matter* who supports it, as long as its being > maintained? And will we now block IBM's hypothetical JFS2 from the kernel > if IBM, from the programmers up to the CEO, doesn't swear on their momma's > grave that they'll continue to support JFS1, even if JFS1 is being > supported by others? Jeez, this is why it doesn't take a kernel dev to see > the problems here, common sense seems to be an increasingly rare ingredient > in these arguments against R4. If I didn't know better, I'd think you were > making this stuff up as you went along - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
Horst von Brand ([EMAIL PROTECTED]): [on reiserfs4] >> >> and _can_ do things >> >> no other FS can > > Mostly useless things... Depends on your point of view. If you define things to be useful only when POSIX requires them, then yes, reiser4 contains a lot of useless stuff. However, it's the 'beyond POSIX'-stuff what makes reiser4 interesting. Multistream files have been useful on other OSses for years. They might be useful on Linux too (Samba will surely like them). The plugin architecture is very interesting. Sometimes you don't need files to be in the POSIX namespace. Why would you want to store a mysql database in files? Why not skip the overhead of the VFS and POSIX rules and just store them in a more efficient way? Maybe you can create a swapfile plugin. No need for a swapfile to be in the POSIX namespace either. It's just a fun thing to experiment with. It's not always nescesary to let the demand create the means. Give programmers some powerful tools and wait and see what wonderful things start to evolve. And yes, maybe in ten years time POSIX is just a subsystem in Linux. Maybe commerciale Unix vendors will start following Linux as 'the' standard instead of the other way around. Seems fun to me :-) I think this debate will mostly boil down to 'do we want to experiment with beyond-POSIX filesystems in linux?'. Clearly we don't _need_ it now. There simply are no users. But will users come when reiser4 is merged? Nobody knows. IMHO reiser4 should be merged and be marked as experimental. It should probably _always_ be marked as experimental, because we _know_ we're going to need some other -- more generic -- API when we decide we like the features of reiser4. The reiser4 APIs should probably be implemented as generic VFS APIs. But since we don't know yet what features we're going to use, let reiser4 be self contained. Maybe reiser5 or reiser6 will follow standard VFS-beyond-POSIX rules, with ext4 and JFS2 also implementing them. It's just too damn hard to predict the future. IMHO better just merge reiser4 and let it be clear to everybody that reiser4 is an experiment. As long as it doesn't affect the rest of the kernel and it's clear to the users that reiser4 is *not* going to be the standard, it's fine with me. -- Erik Hensema <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On 07/10/05 10:43:03PM -0400, Ed Cogburn wrote: > Jim Crilly wrote: > > > but SGI doesn't release a new filesystem every 3 years with the > > desire to remove and replace the old one. > > Read Han's reply to Ed T. nearby. This is why I should have followed my own > original intent and not gotten back into this flamefest, as this response > is the same kind of bullshit that's been repeated over and over again. My > mistake, won't happen again. I did read Hans' reply, but why should I believe him? When I was skimming the csets on the bk site most of the changes looked like small fixes or code migration stuff that touched all filesystems. And I don't even know what 'features' he's saying were added that he didn't sanction. I obviously didn't read all of the log entries so it's definately possible the big stuff he's talking about was completely missed by me, but I would bet that his > 2/3 number is prett far off because every time I give reiser3 a try something eventually goes wrong and I end up back on XFS or ext3 because they're more reliable. Jim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
Ed Tomlinson wrote: >On Sunday 10 July 2005 01:10, Horst von Brand wrote: > > >>Ed Cogburn <[EMAIL PROTECTED]> wrote: >> >> >>>David Lang wrote: >>> >>> On Fri, 8 Jul 2005, Ed Tomlinson wrote: >No Flame from me. One thing to remember is that Hans and friends >_have_ supported R3 for years. > > >>They let it fall into disrepair when they started work on 4. >> >> > >This is FUD. Hans do you have figures on how many fixes for R3 have >been added in the last year or so? > > No, but I can tell you that > 2/3 were related to features I thought should have been put in V4 instead, and were added in violation of my declared code freeze and without my consent. Naturally, those bugs were routed to the authors of those features. There were maybe 2 bugs in the last 18 months in code not related to code freeze violations, I don't remember exactly. There is a simple reason why Namesys no longer spends much time on bug fixes for V3. The frozen code is too stable to generate bug reports to work on, and the unfrozen code is not ours. If the unfrozen code stopped being maintained, I'd have to do something. It seems to me that you should all hope that V4 gets to where Namesys does not spend much time maintaining it. It means we have no bug reports. Stable branches, and development branches, and only bug fixes get added to the stable branch, it is an old paradigm, and broadly speaking it is still the right paradigm. Guys, Horst is trolling.He has never used our code, and yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On 07/10/05 08:01:26PM -0400, Ed Cogburn wrote: > Jim Crilly wrote: > > > But in most of the changesets on the bkbits site you can go back over 2 > > years and not see anything from namesys people. Nearly all of the fixes > > commited in the past 2-3 years are from SuSe. > > > So, for the sake of argument, if IBM were to drop official support for JFS, > we'd yank JFS out of the kernel even if there was someone else willing to > support it? Why does it now *matter* who supports it, as long as its being > maintained? And will we now block IBM's hypothetical JFS2 from the kernel > if IBM, from the programmers up to the CEO, doesn't swear on their momma's > grave that they'll continue to support JFS1, even if JFS1 is being > supported by others? Jeez, this is why it doesn't take a kernel dev to see > the problems here, common sense seems to be an increasingly rare ingredient > in these arguments against R4. If I didn't know better, I'd think you were > making this stuff up as you went along Someone other than Namesys maintaing the filesystem isn't the problem. XFS for instance has had a lot of work done by non-SGI employees after it's merge, but SGI doesn't release a new filesystem every 3 years with the desire to remove and replace the old one. The main problems with reiser4 have been beat to death, if you don't get it by now chances are that you won't. Having Hans and team run off to work on reiser5 6 months after inclusion is an issue, since it seems to have happened before, but it's a minor one as long as reiser4 is merged in a state where it can be manged by other people without too much trouble. Jim. > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Sun, 10 Jul 2005, Ed Cogburn wrote: But in most of the changesets on the bkbits site you can go back over 2 years and not see anything from namesys people. Nearly all of the fixes commited in the past 2-3 years are from SuSe. So, for the sake of argument, if IBM were to drop official support for JFS, we'd yank JFS out of the kernel even if there was someone else willing to support it? Why does it now *matter* who supports it, as long as its being maintained? And will we now block IBM's hypothetical JFS2 from the kernel if IBM, from the programmers up to the CEO, doesn't swear on their momma's grave that they'll continue to support JFS1, even if JFS1 is being supported by others? Jeez, this is why it doesn't take a kernel dev to see the problems here, common sense seems to be an increasingly rare ingredient in these arguments against R4. If I didn't know better, I'd think you were making this stuff up as you went along you are completely missing the point. the fact that the kernel group is going to have to maintain the code over the long run means that it must be acceptable to them before it gets added. so saying that it's supported (for now) by namesys doesn't matter. if it's not something that is in a state that can be maintained over the long term by the kernel group then it can't be accepted, exactly BECOUSE nobody expects an outside orginization to maintain the code forever. Namesys is allowed to maintain the code themselves outside the kernel for as long as they want to (and even fork the kernel if they need to make changes to it that aren't acceptable to the mainline). Namesys is asking the core kernel team to accept their code into the mainline so that it will be maintained by the core kernel team for the indefinate future. This is why it's up to Namesys to satisfy the concerns of the core team, not the other way around. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On 07/10/05 08:06:26PM +0400, Alexey Dobriyan wrote: > On Sunday 10 July 2005 16:48, Ed Tomlinson wrote: > > On Sunday 10 July 2005 01:10, Horst von Brand wrote: > > > Ed Cogburn <[EMAIL PROTECTED]> wrote: > > > > David Lang wrote: > > > > > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > > > > > > > >> No Flame from me. One thing to remember is that Hans and friends > > > > >> _have_ supported R3 for years. > > > > > > They let it fall into disrepair when they started work on 4. > > > > > > > >>This is an undisputed fact. > > > > > > Exactly. > > > > This is FUD. Hans do you have figures on how many fixes for R3 have > > been added in the last year or so? > > You don't need Hans to find out how many. linux.bkbits.net is still online. > > http://linux.bkbits.net:8080/linux-2.6/src/fs/reiserfs?nav=index.html|src/|src/fs Which seems to support the notion that namesys stopped support for reiser3 when reiser4 was started. The tracking of who submittend and who committed patches wasn't there just over a year ago so sometimes it's hard to tell who actually posted that patch if someone like Andrew or Linus committed it. But in most of the changesets on the bkbits site you can go back over 2 years and not see anything from namesys people. Nearly all of the fixes commited in the past 2-3 years are from SuSe. Jim. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Sunday 10 July 2005 16:48, Ed Tomlinson wrote: > On Sunday 10 July 2005 01:10, Horst von Brand wrote: > > Ed Cogburn <[EMAIL PROTECTED]> wrote: > > > David Lang wrote: > > > > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > > > > > >> No Flame from me. One thing to remember is that Hans and friends > > > >> _have_ supported R3 for years. > > > > They let it fall into disrepair when they started work on 4. > > > > > >>This is an undisputed fact. > > > > Exactly. > > This is FUD. Hans do you have figures on how many fixes for R3 have > been added in the last year or so? You don't need Hans to find out how many. linux.bkbits.net is still online. http://linux.bkbits.net:8080/linux-2.6/src/fs/reiserfs?nav=index.html|src/|src/fs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Sunday 10 July 2005 01:10, Horst von Brand wrote: > Ed Cogburn <[EMAIL PROTECTED]> wrote: > > David Lang wrote: > > > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > > > >> No Flame from me. One thing to remember is that Hans and friends > > >> _have_ supported R3 for years. > > They let it fall into disrepair when they started work on 4. > > > >>This is an undisputed fact. > > Exactly. This is FUD. Hans do you have figures on how many fixes for R3 have been added in the last year or so? > > >>Second > > >> third parties have be able to add much function (like journaling) > > >> to R3 so the code must be sort of readable... > > Why don't you check it? Wouldn't you much prefer if the original authors > (or somebody similarly initmate with the code) did mayor surgery on it? > Specially if it is something you depend on? > > > >> With R4 they have created a new FS that is _fast_ > > Remains to be seen. > > > >> and _can_ do things > > >> no other FS can > > Mostly useless things... Just because you do not see how to use a new feature does not mean its useless... > > >> - I also expect they have written cleaner code... > > Better check first. > > > >> Why are we fighting about adding this sort of function to the kernel? > > Because the filessytem experts in the kernel development crowd (and others) > have /serious/ problems with the ideas and the code? > > > >> Yes it may not be the absolute best way to do things. How many times > > >> has tcpip be rewritten for linux? The answer is more than once. > > So? > > > >> Lets put R4 in, see how it works, generalize the ideas and if we have > > >> to rewrite and rethink part of it lets do so. > > Why not: Let's keep it out, fix the problems that it has and evaluate it > for inclusion once the problems have been ironed out? That has been the > policy for everything else as far as I can remember (and that is from > nearly the beginning...) When you are exploring new stuff its almost impossible to see the best way to do things. Once R4 (and other FSes) use these new features (or not) it will become more obvious how they should be coded. As it is not its a bit like trying to decide your new baby will be a doctor when he/she grows up - its not something you can predict. > > > remember that Hans is on record (over a year ago) arguing that R3 should > > > not be fixed becouse R4 was replacing it. > > > > This type of thing is one of the reasons that you see arguments that > > > aren't 'purely code-related' becouse the kernel folks realize that _they_ > > > will have to maintain the code over time, Hans and company will go on and > > > develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining > > > it. > > > Maybe its because Hans and Co., having only a finite amount of dev time, > > would much prefer to spend that time on R4 rather than R3? > > ext2 is still being maintained alongside ext3. And so is R3 - just no new features are being added... > >Maybe if we > > were to let R4 into the kernel, it wouldn't be long after that R3 could be > > retired because everyone has moved to R4? > > ext3 is several years old, and there are /still/ ext2 users around... > See above - this should presend NO problems. > > Devs should be free to work on whatever they want, because most of them are > > doing this on their own time anyway, otherwise they might just decide to > > hack on some other OS, or a fork of Linux instead. > > Nobody forces anybody to work on Linux, or even on the standard Linus > kernel. It is the ReiserFS crowd who are demanding something from the Linux > crowd, not the other way around. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
Ed Cogburn <[EMAIL PROTECTED]> wrote: > David Lang wrote: > > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > >> No Flame from me. One thing to remember is that Hans and friends > >> _have_ supported R3 for years. They let it fall into disrepair when they started work on 4. > >>This is an undisputed fact. Exactly. > >>Second > >> third parties have be able to add much function (like journaling) > >> to R3 so the code must be sort of readable... Why don't you check it? Wouldn't you much prefer if the original authors (or somebody similarly initmate with the code) did mayor surgery on it? Specially if it is something you depend on? > >> With R4 they have created a new FS that is _fast_ Remains to be seen. > >> and _can_ do things > >> no other FS can Mostly useless things... > >> - I also expect they have written cleaner code... Better check first. > >> Why are we fighting about adding this sort of function to the kernel? Because the filessytem experts in the kernel development crowd (and others) have /serious/ problems with the ideas and the code? > >> Yes it may not be the absolute best way to do things. How many times > >> has tcpip be rewritten for linux? The answer is more than once. So? > >> Lets put R4 in, see how it works, generalize the ideas and if we have > >> to rewrite and rethink part of it lets do so. Why not: Let's keep it out, fix the problems that it has and evaluate it for inclusion once the problems have been ironed out? That has been the policy for everything else as far as I can remember (and that is from nearly the beginning...) > > remember that Hans is on record (over a year ago) arguing that R3 should > > not be fixed becouse R4 was replacing it. > > This type of thing is one of the reasons that you see arguments that > > aren't 'purely code-related' becouse the kernel folks realize that _they_ > > will have to maintain the code over time, Hans and company will go on and > > develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining > > it. > Maybe its because Hans and Co., having only a finite amount of dev time, > would much prefer to spend that time on R4 rather than R3? ext2 is still being maintained alongside ext3. >Maybe if we > were to let R4 into the kernel, it wouldn't be long after that R3 could be > retired because everyone has moved to R4? ext3 is several years old, and there are /still/ ext2 users around... [...] > Devs should be free to work on whatever they want, because most of them are > doing this on their own time anyway, otherwise they might just decide to > hack on some other OS, or a fork of Linux instead. Nobody forces anybody to work on Linux, or even on the standard Linus kernel. It is the ReiserFS crowd who are demanding something from the Linux crowd, not the other way around. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Fri, 8 Jul 2005, Ed Cogburn wrote: Maybe its because Hans and Co., having only a finite amount of dev time, would much prefer to spend that time on R4 rather than R3? Maybe if we were to let R4 into the kernel, it wouldn't be long after that R3 could be retired because everyone has moved to R4? Maybe if R4 had been allowed into the mainstream kernel a year ago, this ENTIRE ARGUMENT would be moot? Since when has there been a requirement for all new code to have a signed support contract before it enters the kernel? Don't tell me this is normal, because I damn well know its not. Early on and for the most part even today, good stuff gets into the kernel without any explicit or at least meaningful promises of long term support. That stuff stays in the kernel as long as there is someone willing to maintain it, and it disappears from the kernel when there is no one left willing to keep it up-to-date. That has always been the basic rule, without it Linux would never have gone beyond the stage of being Linus's toy, because if Linus had demanded such a support commitment up front, people would have lost interest in hacking on his toy. Devs should be free to work on whatever they want, because most of them are doing this on their own time anyway, otherwise they might just decide to hack on some other OS, or a fork of Linux instead. Demanding long term support commitment from volunteers is just bizarre, since pretty soon, you won't have many volunteers left, with the ones still remaining consistently lying to you as everyone will know that the promises they are making can't be enforced. As for code from companies, has Linus gotten a signed support contract from IBM for JFS? If he asked, do you really think they would agree to one? So this business of demanding a perpetual support contract from Hans for R3 before you even let R4 into the kernel is patently absurd. Such a contract won't be needed once R4 gets into widespread use and stabilizes, allowing R3 users to switch over to it, never mind that this has not been required to my knowledge of anyone else. Either you're putting the cart before the horse on this one without realizing it, or you're just another member of the 'say-no-to-change' group (or worse, the say-no-to-Hans group) using any excuse that pops into your head for why you keep saying 'no'. it's not that they are being asked to commit to a perpetual support contract, it's the fact that they AREN'T being asked to commit to a perpetual support contract that makes it more important that the code that they are asking to be merged must fit in well with the code and the philosphy of the rest of the kernel so that it can be supported well by others if the kernel folks don't agree with the underlying design they may end up accepting it for a while, but will rip it out as soon as they get an excuse (see devfs for a perfect example) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
David Lang wrote: > > remember that Hans is on record (over a year ago) arguing that R3 > should not be fixed becouse R4 was replacing it. No, I said and say that V3 should not have features added to it, because features should not be added to a stable branch. Bug fixes are good. There are a few V3 bug fixes where the fix is so deep that it belongs in V4, all of the ones that I can think of at the moment are ones requiring disk format changes. Note that in V4, disk format changes are no longer deep fixes because of plugins. > > This type of thing is one of the reasons that you see arguments that > aren't 'purely code-related' becouse the kernel folks realize that > _they_ will have to maintain the code over time, Hans and company will > go on and develop R5 (R10, whatever) and consider R4 obsolete and stop > maintaining it. No, we will stop adding features to it at some point, only add bug fixes, and let it become stable enough for mission critical use. Of course, with plugins this becomes more complicated of a policy because smaller releases with more orthogonal features are easier and more tempting, and it becomes tempting to version and release plugins rather than the FS, so I am not sure exactly how this will play out yet. I think we will have an option to select experimental plugins individually. > > David Lang > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
David Lang wrote: > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > >> >> No Flame from me. One thing to remember is that Hans and friends _have_ >> supported >> R3 for years. This is an undisputed fact. Second third parties have be >> able to add much >> function (like journaling) to R3 so the code must be sort of readable... >> With R4 they have created a new FS that is _fast_ and _can_ do things no >> other FS can - I also expect they have >> written cleaner code... Why are we fighting about adding this sort of >> function to the kernel? >> Yes it may not be the absolute best way to do things. How many times has >> tcpip be rewritten >> for linux? The answer is more than once. Lets put R4 in, see how it >> works, generalize the ideas and if we have to rewrite and rethink part of >> it lets do so. > > remember that Hans is on record (over a year ago) arguing that R3 should > not be fixed becouse R4 was replacing it. > > This type of thing is one of the reasons that you see arguments that > aren't 'purely code-related' becouse the kernel folks realize that _they_ > will have to maintain the code over time, Hans and company will go on and > develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining > it. Maybe its because Hans and Co., having only a finite amount of dev time, would much prefer to spend that time on R4 rather than R3? Maybe if we were to let R4 into the kernel, it wouldn't be long after that R3 could be retired because everyone has moved to R4? Maybe if R4 had been allowed into the mainstream kernel a year ago, this ENTIRE ARGUMENT would be moot? Since when has there been a requirement for all new code to have a signed support contract before it enters the kernel? Don't tell me this is normal, because I damn well know its not. Early on and for the most part even today, good stuff gets into the kernel without any explicit or at least meaningful promises of long term support. That stuff stays in the kernel as long as there is someone willing to maintain it, and it disappears from the kernel when there is no one left willing to keep it up-to-date. That has always been the basic rule, without it Linux would never have gone beyond the stage of being Linus's toy, because if Linus had demanded such a support commitment up front, people would have lost interest in hacking on his toy. Devs should be free to work on whatever they want, because most of them are doing this on their own time anyway, otherwise they might just decide to hack on some other OS, or a fork of Linux instead. Demanding long term support commitment from volunteers is just bizarre, since pretty soon, you won't have many volunteers left, with the ones still remaining consistently lying to you as everyone will know that the promises they are making can't be enforced. As for code from companies, has Linus gotten a signed support contract from IBM for JFS? If he asked, do you really think they would agree to one? So this business of demanding a perpetual support contract from Hans for R3 before you even let R4 into the kernel is patently absurd. Such a contract won't be needed once R4 gets into widespread use and stabilizes, allowing R3 users to switch over to it, never mind that this has not been required to my knowledge of anyone else. Either you're putting the cart before the horse on this one without realizing it, or you're just another member of the 'say-no-to-change' group (or worse, the say-no-to-Hans group) using any excuse that pops into your head for why you keep saying 'no'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Fri, 8 Jul 2005, Ed Tomlinson wrote: No Flame from me. One thing to remember is that Hans and friends _have_ supported R3 for years. This is an undisputed fact. Second third parties have be able to add much function (like journaling) to R3 so the code must be sort of readable... With R4 they have created a new FS that is _fast_ and _can_ do things no other FS can - I also expect they have written cleaner code... Why are we fighting about adding this sort of function to the kernel? Yes it may not be the absolute best way to do things. How many times has tcpip be rewritten for linux? The answer is more than once. Lets put R4 in, see how it works, generalize the ideas and if we have to rewrite and rethink part of it lets do so. remember that Hans is on record (over a year ago) arguing that R3 should not be fixed becouse R4 was replacing it. This type of thing is one of the reasons that you see arguments that aren't 'purely code-related' becouse the kernel folks realize that _they_ will have to maintain the code over time, Hans and company will go on and develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining it. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
On Friday 08 July 2005 18:59, Ed Cogburn wrote: > [EMAIL PROTECTED] wrote: > > > > In reality is it doesn't count. Users don't care what level of pain is > > involved in producing the products they use. > > > > Development efforts and results for OS's are always just taken for > > granted. > > > > BTDT - if you're very lucky, a (very) few non-programming users might > > notice something nice and mention that they noticed a difference. The > > majority are still struggling to find the power switch ;-> > > > You no longer have to be a kernel dev to see that there is more to the > resistance to R4 than objective technical issues, anyone with an > understanding of English whose been reading the R4 > debates-that-quickly-turn-into-flame-wars the last couple of years here can > see that. For you guys to continue to suggest otherwise only makes you out > to be the fools, not the "lusers" (which you obviously define as anyone who > isn't a kernel dev). > > So be my guest, ignore the message and attack the messenger, I didn't > respond to start yet another flamewar, nor did I really expect much > objectivity anyway, as that's been thrown out the window even in > discussions between developers, e.g. the R4 plugins thread. > > If its a fork of the kernel that you really want, so be it. When it > happens, and given the increasing divergence going on between the > commercial distros and the vanilla kernel, maybe it's already begun, I'll > use the one that isn't afraid of giving new ideas a chance. > > Flame away, I'm done. No Flame from me. One thing to remember is that Hans and friends _have_ supported R3 for years. This is an undisputed fact. Second third parties have be able to add much function (like journaling) to R3 so the code must be sort of readable... With R4 they have created a new FS that is _fast_ and _can_ do things no other FS can - I also expect they have written cleaner code... Why are we fighting about adding this sort of function to the kernel? Yes it may not be the absolute best way to do things. How many times has tcpip be rewritten for linux? The answer is more than once. Lets put R4 in, see how it works, generalize the ideas and if we have to rewrite and rethink part of it lets do so. Please do add R4 to the kernel! Thanks, Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
[EMAIL PROTECTED] wrote: > > In reality is it doesn't count. Users don't care what level of pain is > involved in producing the products they use. > > Development efforts and results for OS's are always just taken for > granted. > > BTDT - if you're very lucky, a (very) few non-programming users might > notice something nice and mention that they noticed a difference. The > majority are still struggling to find the power switch ;-> You no longer have to be a kernel dev to see that there is more to the resistance to R4 than objective technical issues, anyone with an understanding of English whose been reading the R4 debates-that-quickly-turn-into-flame-wars the last couple of years here can see that. For you guys to continue to suggest otherwise only makes you out to be the fools, not the "lusers" (which you obviously define as anyone who isn't a kernel dev). So be my guest, ignore the message and attack the messenger, I didn't respond to start yet another flamewar, nor did I really expect much objectivity anyway, as that's been thrown out the window even in discussions between developers, e.g. the R4 plugins thread. If its a fork of the kernel that you really want, so be it. When it happens, and given the increasing divergence going on between the commercial distros and the vanilla kernel, maybe it's already begun, I'll use the one that isn't afraid of giving new ideas a chance. Flame away, I'm done. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiser4 vs politics: linux misses out again
- Original Message - From: "Horst von Brand" <[EMAIL PROTECTED]> To: "Ed Cogburn" <[EMAIL PROTECTED]> Cc: Sent: Sunday, July 03, 2005 22:11 Subject: Re: reiser4 vs politics: linux misses out again > > The work involved in getting it into the kernel, workin with it while it is > there, and then ripping it out when it becomes clear that it won't be > maintained anymore doesn't count. In reality is it doesn't count. Users don't care what level of pain is involved in producing the products they use. Development efforts and results for OS's are always just taken for granted. BTDT - if you're very lucky, a (very) few non-programming users might notice something nice and mention that they noticed a difference. The majority are still struggling to find the power switch ;-> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
