Re: Another article abour Reiser4 on linux.com
Bernd Schubert wrote: An alternative might be a reiser4 fuse port. Fuse is not performance effective.
Re: article abour Reiser4 on linux.com
Bruce, I read your article on Linus and GPL V3, and I understand that you are frustrated by his not going for V3. I suspect the main thing that sparked your concern in writing the article about reiser4 is that I am somehow doing something different that affects licensing, and not conforming on that issue. Plugins have nothing to do with licensing issues --- that was purely Linus getting confused. Plugins are compiled in. Bruce Byfield wrote: I believe that you make a reference to two people working on XFS, one of whom other people later identify as Steve Lord. They wrongly identify him. Unfortunately, it's not one of which editors approve. It too easily looks as though the writer is being influenced by the source. If I were to do so, I'd risk being banned from publication. Wow. I thought only the judiciary insulated itself from ever learning of its mistakes that well.:-/
Re: article abour Reiser4 on linux.com
On 02:28 Wed 09 Aug , Hans Reiser wrote: Unfortunately, it's not one of which editors approve. It too easily looks as though the writer is being influenced by the source. If I were to do so, I'd risk being banned from publication. Uhm... interesting. It's not that I have so much experience with the press (just three interviews so far), but everytime I got the article for review before publication. It is considered as good manners here to avoid misquoting. Of course the can always opt to disregard any changes, but in reality this procedure is just like a two phase interview with the goal to improve accuracy. If you didn't trust the source in the first place, why should you bother to take information from it at all? If you do trust it, why not ask again? Just my (humble and uninformed) $0.02 8-) -Andreas pgplvjNniRM5C.pgp Description: PGP signature
Re: article abour Reiser4 on linux.com
Andreas Schäfer wrote: On 02:28 Wed 09 Aug , Hans Reiser wrote: Unfortunately, it's not one of which editors approve. It too easily looks as though the writer is being influenced by the source. If I were to do so, I'd risk being banned from publication. Uhm... interesting. It's not that I have so much experience with the press (just three interviews so far), but everytime I got the article for review before publication. If you didn't trust the source in the first place, why should you bother to take information from it at all? If you do trust it, why not ask again? Hmm. Except in this case, they were summarizing a rather large debate, so it's not a question of trusting the source or not, it's a question of whether you want to fact-check with every person on reiserfs-list and lkml, until you've got the whole thing so debated and watered-down that it's meaningless. Then, too, sometimes it's better to check ahead of time than to get it wrong and have to correct later, because people won't always read the corrections.
Re: article abour Reiser4 on linux.com
On Wed, 2006-08-09 at 02:28 -0600, Hans Reiser wrote: Bruce, I read your article on Linus and GPL V3, and I understand that you are frustrated by his not going for V3. To be honest, it was more the fact that he made an obviously false statement, and I happened to be in a position to know it was so. Linus' other comments about GPL3 are at least worth a serious discussion, but his comment about the procedure was off base. I suspect the main thing that sparked your concern in writing the article about reiser4 is that I am somehow doing something different that affects licensing, and not conforming on that issue. Plugins have nothing to do with licensing issues --- that was purely Linus getting confused. Plugins are compiled in. My concern was even simpler than that: The story was one that lots of people want to know about and that I, personally, would like to see resolved as soon as possible. As for the licensing concerns, I mention them not because they are a burning issue for me personally (although I do write about them sometimes, because I have a reasonable amount of experience in dealing with them, despite not being a lawyer), but because they are one of the peripheral issues that seemed worth mentioning. It would be much easier if everyone separated legal and philosophical issues from technical ones, and I'd prefer to to do so myself. Unfortunately, people will keep mixing them. Wow. I thought only the judiciary insulated itself from ever learning of its mistakes that well.:-/ Oh, we have ways of learning. As witness this email exchange :) -- Bruce Byfield 604-421-7177 Burnaby, BC, Canada http://members.axion.net/~bbyfield All the ancient kings came to my door They said, Do you want to be an ancient king too? I said, Oh yes, very much But I think my timing's wrong -Dan Bern, Jerusalem
Re: article abour Reiser4 on linux.com
Bruce Byfield wrote: Wow. I thought only the judiciary insulated itself from ever learning of its mistakes that well.:-/ Oh, we have ways of learning. As witness this email exchange :) You are right, it is only the judiciary.;-)
Re: Another article abour Reiser4 on linux.com
TongKe Xue wrote: A really stupid question ... why not put Reiser4 in one of the BSDs? The cost to port to BSD is about $500k, and I am not possessed of a lot of money at this time. There is also a license issue, I don't want reiser4 to be BSD licensed, people who want proprietary additions to reiser4 should pay me for reiser4.
article abour Reiser4 on linux.com
Bruce, regarding a longstanding convention of avoiding plugins in the kernel, considering that we are the first and only ones ever to have plugins, and considering the existence of binary kernel modules, I don't think your characterization is accurate. Perhaps there was some licensing controversy on lkml I am unaware of? Since plugins are (always) compiled in, unlike kernel modules, I don't see how there is a licensing issue. I think your characterization of plugins as something we impose on the VFS is unfair. Plugins exist entirely internally to reiser4 --- we impose nothing on anyone. I only wish to impose my views on Reiser4, not on VFS, because I really don't care for haggling with others about the code they wrote not having the features I want. I don't think you should characterize me as saying coding style conformity is the issue: that is how my opponents portray it, as some sort of 80 characters vs. 120 characters per line disagreement in which I refuse to go along. I think social connections prevailing over technical merits is the issue, and perhaps also whether VFS should intrude deeply into the independence of filesystem design based on the assumption that the VFS authors are more likely to get it right, or whether it should let each filesystem do what it wants to do based on the hope that if enough people try their own thing in a decentralized system, odds are that one of them will get it more right than the others and users will be able to choose that FS. I never made a reference to Steve Lord or Jim Lord, so suggesting that I got it wrong about him is inaccurate. Your characterization of the issue of whether Linux should double its filesystem performance as a philosophical point seems odd to me --- I think my writing failed to reach you as an audience on that point. Reiser4 was first proposed for inclusion in October 2002, and a casual reader of your article would think it was proposed in 2005. Many journalists will run my words past me to see if it fairly portrays my views --- perhaps you might choose to do that with those you write about in the future. In my experience it is a good journalistic practice. On a positive note, it seems like Andrew Morton will singlehandedly turn the Reiser4 review process into a technical not a political process, and I am much encouraged by that. He has made numerous useful technical remarks in his last email, and we are addressing them. Thanks for your time, Hans Tassilo Horn wrote: Hi, there's another Reiser4 article on linux.com [1], mainly about politics. Neither much of the technical discussion is covered, nor are the comments too positive, but it may be interesting anyway. One thing which bothers me most: Whenever such an article appears it's commented mostly by kiddies speaking after the mouth of several kernel developers, sophisticating most of their comments, ripping them out of context or spreading superficial knowledge. Of course those comments let it get to possible new users. Kind regards and keep up the great work, Tassilo (pleased Reiser4 user since 2.6.0_testX) Footnotes: [1] http://www.linux.com/article.pl?sid=06/07/31/1548201
Re: Another article abour Reiser4 on linux.com
On Sunday 06 August 2006 10:20, Hans Reiser wrote: TongKe Xue wrote: A really stupid question ... why not put Reiser4 in one of the BSDs? The cost to port to BSD is about $500k, and I am not possessed of a lot of money at this time. There is also a license issue, I don't want reiser4 to be BSD licensed, people who want proprietary additions to reiser4 should pay me for reiser4. An alternative might be a reiser4 fuse port. Has some advantages: - Doesn't need to be included into the kernel. - can be GPL - Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/). - Kills one of the major arguments on LKML - if reiser4 is included but Namesys abandons it in the future and reiser4 has to be removed from the kernel that time again, it still could be mounted. Sorry, I have never looked into any of the reiserfs code, but looking at the simple interface of fuse, it might be possible that you could reuse lots of your present code. There even is ongoing work to get a ZFS fuse port (http://www.wizy.org/wiki/ZFS_on_FUSE). Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Re: Another article abour Reiser4 on linux.com
Bernd Schubert wrote: An alternative might be a reiser4 fuse port. Has some advantages: - Doesn't need to be included into the kernel. - can be GPL - Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/). - Kills one of the major arguments on LKML - if reiser4 is included but Namesys abandons it in the future and reiser4 has to be removed from the kernel that time again, it still could be mounted. Please please no. The kernel people will use that as an argument for keeping it out of the kernel. I want reiser4 to be popular enough to make my apps depend on it and not have the users complain about having to use an obscure fs. Besides, the only thing about reiser4 that interests me more than XFS or reiserfs is the speed. In FUSE, you lose all that (as well as millions of context switches, there is a huge amount of copying going on). If reiser4 gets slower, I might as well use XFS or even old reiserfs. - LL
Re: Another article abour Reiser4 on linux.com
On Sunday 06 August 2006 14:41, Lexington Luthor wrote: Bernd Schubert wrote: An alternative might be a reiser4 fuse port. Has some advantages: - Doesn't need to be included into the kernel. - can be GPL - Referring to the fuse site it also works on BSD (http://fuse4bsd.creo.hu/). - Kills one of the major arguments on LKML - if reiser4 is included but Namesys abandons it in the future and reiser4 has to be removed from the kernel that time again, it still could be mounted. Please please no. The kernel people will use that as an argument for keeping it out of the kernel. I want reiser4 to be popular enough to make my apps depend on it and not have the users complain about having to use an obscure fs. Besides, the only thing about reiser4 that interests me more than XFS or reiserfs is the speed. In FUSE, you lose all that (as well as millions of context switches, there is a huge amount of copying going on). If reiser4 gets slower, I might as well use XFS or even old reiserfs. Well, by having a FUSE port just more users would use reiser4, which might increase the force to the linux distributors to include reiser4 into their kernel versions. Regarding the speed, I understand that its slower with FUSE, I was also deeply impressed when I read this (http://sourceforge.net/mailarchive/forum.php?thread_id=23836054forum_id=2697) But being twice as fast as ext3 is enough currently. It's even faster than xfs what I use. Sometimes I'm quite suprised why something is so fast when I realize that it was actually ntfs-3g :-) Cheers, Bernd -- Bernd Schubert PCI / Theoretische Chemie Universität Heidelberg INF 229 69120 Heidelberg
Re: article abour Reiser4 on linux.com
Hi again, I think your characterization of plugins as something we impose on the VFS is unfair. Plugins exist entirely internally to reiser4 --- we to be honest I hope the force from kernel developers will not take away any more abilities and features away from reiserfs! If reiser4 is tied witth VFS whats about ports to e.g. windows or other unix systems - its more or less a lock-in ... an own implementation could solve. XFS also does not integrate well into the linux kernel (its basically a big mess), so I don't think the does not integrate nicely argument counts at all. lg Clemens
Re: Another article abour Reiser4 on linux.com
Bernd Schubert wrote: Well, by having a FUSE port just more users would use reiser4, which might increase the force to the linux distributors to include reiser4 into their kernel versions. I don't think reiser4 would gain many users if it is crippled by being in userspace. All the lazy flushing and aggressive caching become useless if it cannot interact directly with the pagecache and respond to memory pressure. Would you tolerate a 2GB process just to run a filesystem? Thats what reiser4 can do if it is in the kernel, and silently give back memory only when needed. Regarding the speed, I understand that its slower with FUSE, I was also deeply impressed when I read this (http://sourceforge.net/mailarchive/forum.php?thread_id=23836054forum_id=2697) But being twice as fast as ext3 is enough currently. It's even faster than xfs what I use. Sometimes I'm quite suprised why something is so fast when I realize that it was actually ntfs-3g :-) Those micro-benchmarks do not represent anything like normal use. NTFS is probably the most complicated filesystem on the planet, so there is zero chance that a *working* implementation of it can outperform something like XFS... even reiser4 barely beats XFS in many situations (actually slower than XFS for heavy local rsync activity). - LL
Re: Another article abour Reiser4 on linux.com
Lexington Luthor wrote: Bernd Schubert wrote: An alternative might be a reiser4 fuse port. Has some advantages: Please please no. The kernel people will use that as an argument for keeping it out of the kernel. They'll use anything as an argument for keeping it out of the kernel. This one is particularly shallow, especially if we still have the kernel version, because the performance difference will be significant. If it isn't, maybe it is time for things like FUSE to take us in the direction of microkernels... I want reiser4 to be popular enough to make my apps depend on it and not have the users complain about having to use an obscure fs. Well, an obscure program (FUSE) is probably a lot easier to convince users of than an obscure filesystem (reiser4 in-kernel). Besides, the only thing about reiser4 that interests me more than XFS or reiserfs is the speed. That's you. There are other reasons to like it. But I agree with you in that I don't think it's worth the resources to do a FUSE port, especially when there is (again) NO guarantee that anything we do will get us in the kernel, so better to do things that will either get us users anyway (like distro inclusion) or do things the kernel people specifically ask for.
Re: Another article abour Reiser4 on linux.com
I'm a total idiot. Please forgive my stupidity. From a purely technical perspective, what does VFS lack that makes VFS-modules so much harder than Reiser-modules? Thanks, --TongKe On Sun, 6 Aug 2006, David Masover wrote: Lexington Luthor wrote: Bernd Schubert wrote: An alternative might be a reiser4 fuse port. Has some advantages: Please please no. The kernel people will use that as an argument for keeping it out of the kernel. They'll use anything as an argument for keeping it out of the kernel. This one is particularly shallow, especially if we still have the kernel version, because the performance difference will be significant. If it isn't, maybe it is time for things like FUSE to take us in the direction of microkernels... I want reiser4 to be popular enough to make my apps depend on it and not have the users complain about having to use an obscure fs. Well, an obscure program (FUSE) is probably a lot easier to convince users of than an obscure filesystem (reiser4 in-kernel). Besides, the only thing about reiser4 that interests me more than XFS or reiserfs is the speed. That's you. There are other reasons to like it. But I agree with you in that I don't think it's worth the resources to do a FUSE port, especially when there is (again) NO guarantee that anything we do will get us in the kernel, so better to do things that will either get us users anyway (like distro inclusion) or do things the kernel people specifically ask for.
Re: article abour Reiser4 on linux.com
Hans: I suspect that most of your comments are a result of mild misreadings, or inferences that may not be inevitable. My comments are interspersed below. On Sun, 2006-08-06 at 03:19 -0600, Hans Reiser wrote: Bruce, regarding a longstanding convention of avoiding plugins in the kernel, considering that we are the first and only ones ever to have plugins, and considering the existence of binary kernel modules, I don't think your characterization is accurate. Perhaps there was some licensing controversy on lkml I am unaware of? Since plugins are (always) compiled in, unlike kernel modules, I don't see how there is a licensing issue. I believe that the controversy has arisen largely with commercial companies who would like a way to keep their drivers proprietary. Without actually doing a search, I seem to remember that the last time the controversy arose was around October or November 2005. I think your characterization of plugins as something we impose on the VFS is unfair. I report that others make this claim. I don't characterize plugins in any way myself. That said, if I were writing the article now, I would certainly mention your rebuttals on the lkml since then. Researching the article, I realized early that I was attempting to summarize a series of immensely complicated issues for people who might know almost nothing about it, and my aim was not to take sides, but to present the highlights as neutrally as possible. That means reporting opinions that I don't necessarily agree with. I never made a reference to Steve Lord or Jim Lord, so suggesting that I got it wrong about him is inaccurate. I mention something like Reiser and his supporters, which simply means that the reference arises during the thread. I believe that you make a reference to two people working on XFS, one of whom other people later identify as Steve Lord. Your characterization of the issue of whether Linux should double its filesystem performance as a philosophical point seems odd to me --- I think my writing failed to reach you as an audience on that point. I characterized it as a philosophical issue because, although the focus for everyone is superficially technical, it quickly spills over into larger issues, such as whether following the conventions is more important than performance. Reiser4 was first proposed for inclusion in October 2002, and a casual reader of your article would think it was proposed in 2005. That was an unintended implication, and I apologize for it. Many journalists will run my words past me to see if it fairly portrays my views --- perhaps you might choose to do that with those you write about in the future. In my experience it is a good journalistic practice. Unfortunately, it's not one of which editors approve. It too easily looks as though the writer is being influenced by the source. If I were to do so, I'd risk being banned from publication. That said, while I strive for accuracy, I am more than capable of making mistakes. Moreover, on an issue as complicated as this one, mistakes are even more likely than usual. That's why comments are an important part online journalism. On a positive note, it seems like Andrew Morton will singlehandedly turn the Reiser4 review process into a technical not a political process, and I am much encouraged by that. He has made numerous useful technical remarks in his last email, and we are addressing them. That's good news. It seems long past the time that someone like Andrew Morton stepped in to allow people to focus. And when the day comes that Reiser4 is added to the kernel, I hope that you will let I or somebody else from NewsForge interview you on the subject. That will be a milestone that many people, including me, have been waiting a long time for. One thing which bothers me most: Whenever such an article appears it's commented mostly by kiddies speaking after the mouth of several kernel developers, sophisticating most of their comments, ripping them out of context or spreading superficial knowledge. Of course those comments let it get to possible new users. Tassilo: As I said to Hans, please step in and correct any misconceptions, either from the article or its comments. Personally, I take the educational goals of journalism seriously, and they aren't served by allowing mistakes to stand unchallenged. All the best, -- Bruce Byfield 604-421-7177 Burnaby, BC, Canada http://members.axion.net/~bbyfield All the ancient kings came to my door They said, Do you want to be an ancient king too? I said, Oh yes, very much But I think my timing's wrong -Dan Bern, Jerusalem
Another article abour Reiser4 on linux.com
Hi, there's another Reiser4 article on linux.com [1], mainly about politics. Neither much of the technical discussion is covered, nor are the comments too positive, but it may be interesting anyway. One thing which bothers me most: Whenever such an article appears it's commented mostly by kiddies speaking after the mouth of several kernel developers, sophisticating most of their comments, ripping them out of context or spreading superficial knowledge. Of course those comments let it get to possible new users. Kind regards and keep up the great work, Tassilo (pleased Reiser4 user since 2.6.0_testX) Footnotes: [1] http://www.linux.com/article.pl?sid=06/07/31/1548201 -- My opinions may have changed, but not the fact that I am right.
Re: Another article abour Reiser4 on linux.com
Tassilo Horn wrote: [1] http://www.linux.com/article.pl?sid=06/07/31/1548201 From the article: To complicate matters, Reiser4's approach lands the filesystem in the middle of a longstanding convention of avoiding plugins in the kernel, mainly to avoid architectural complications, but also to discourage proprietary drivers that circumvent the kernel's release under the GNU General Public License. We should really find something better to call them than plugins, or we should come up with a standard copy'n'paste statement to refute this.
Re: Another article abour Reiser4 on linux.com
Hello David, Saturday, August 5, 2006, 4:55:16 PM, you wrote: We should really find something better to call them than plugins, or we should come up with a standard copy'n'paste statement to refute this. I agree. As Andrew Morton said: The plugins appear to be wildly misnamed - they're just an internal abstraction layer which permits later feature additions to be added in a clean and safe manner. Certainly not worth all this fuss. So we're talking about extensibility. How about we call it 'extensions' ? -- Best regards, Maciej
Re: Another article abour Reiser4 on linux.com
I like using a term that is already in an accepted part of the kernel. Extensions might smack of plugins a bit much, and we're trying to avoid just doing a s/plugins/extensions/ of the arguments we're seeing now. --Clay On 18:22 Sat 05 Aug , Maciej Sołtysiak wrote: So we're talking about extensibility. How about we call it 'extensions' ? Or just modules... netfilter has modules that allow us to write very cool and weird stuff (like unclean match once was) and nobody complains. Another word could be 'hooks' -- Maciej
Re: Another article abour Reiser4 on linux.com
Clay Barnes wrote: I like using a term that is already in an accepted part of the kernel. Extensions might smack of plugins a bit much, and we're trying to avoid just doing a s/plugins/extensions/ of the arguments we're seeing now. We could do that with almost anything: Or just modules... netfilter has modules that allow us to write very cool and weird stuff (like unclean match once was) and nobody complains. Except that modules could also possibly remind people of proprietary modules, like the nvidia/ATI/vmware stuff. Still, if we allow netfilter, why not Reiser4 modules? Another word could be 'hooks' I don't think this would quite work. A hook describes more the place you connect to, whereas a module/plugin/whatever... Think of it this way -- the hook is what a plugin would plug in to. So it may not matter much what we name them, we're probably still going to need that cut'n'paste argument. Might be easier with modules, though.
Re: Another article abour Reiser4 on linux.com
I think the core thing we have to have to win this argument is a) A word that isn't *instantly* associated with banned things. b) The ability to point to the technology to point to the design and say look, Look, it's *impossible* to use this design to put binary modules into the kernel. Even if it's as hard as ATI or nVidia modules to put it in, that'll be enough to put up a fight against inclusion. The *only* way to win a polical/personal fight is to remove any possible objection until resistance looks purely stupid and wholly unsubtantiated. Yes, things with reservations have made it in in the past, but only when there is no personal conflict. I was just saying to my roomate that I was losing hope for Reiser4 because I didn't see an end to the politics any time soon. I would *love* to see Reiser 4 in the kernel, but you guys are fighting a worse than uphill battle. As long as there's a stalemate the kernel people win, since no change is all they want. It's also quite easy for them to find something new to complain about if you solve their current problems. There's only one possible way I see to get in. You must ask for an absolute list of things that are objectionable. You should then ask *before you start work* about removal of any items that are either a) impossible, or b) illogical. Once you've gotten the official stamp of approval of the (posibly recvised) absolute list of objections, you have to do it, completely and exactly. If they agreed that that is everything they find wrong and promised that they would include Reiser4 if those issues were resolved, then they really *have* to put it in then. The down side of course is that they may ask for a lot. Even if it's more than you find fair, remember that they can effectively kill your project by inaction. Fair? No. The way the world works? Unfortunately, yes. The core of all this is that rather than leaving an open-ended task that can be expanded at will, they are given limits to how long the objections can be spread out. The bonus to you is that if anyone tries to drag out issues after you've done the list, you can point to the it and say These were the limit of the real issues that were raised. Anything beyond is someone else's preference, and therefore their job to get included. --Clay On 17:40 Sat 05 Aug , David Masover wrote: Clay Barnes wrote: I like using a term that is already in an accepted part of the kernel. Extensions might smack of plugins a bit much, and we're trying to avoid just doing a s/plugins/extensions/ of the arguments we're seeing now. We could do that with almost anything: Or just modules... netfilter has modules that allow us to write very cool and weird stuff (like unclean match once was) and nobody complains. Except that modules could also possibly remind people of proprietary modules, like the nvidia/ATI/vmware stuff. Still, if we allow netfilter, why not Reiser4 modules? Another word could be 'hooks' I don't think this would quite work. A hook describes more the place you connect to, whereas a module/plugin/whatever... Think of it this way -- the hook is what a plugin would plug in to. So it may not matter much what we name them, we're probably still going to need that cut'n'paste argument. Might be easier with modules, though.
Re: Another article abour Reiser4 on linux.com
Clay Barnes wrote: I think the core thing we have to have to win this argument is a) A word that isn't *instantly* associated with banned things. That'd be nice. b) The ability to point to the technology to point to the design and say look, Look, it's *impossible* to use this design to put binary modules into the kernel. Even if it's as hard as ATI or nVidia modules to put it in, that'll be enough to put up a fight against inclusion. Why? Why does it have to be impossible to do binary things with the kernel? I mean, if Linus hates GPL3 because it limits what people do with the kernel... Besides, you can't make it impossible, you can only make it about as hard as it is now. The license is the issue here. The *only* way to win a polical/personal fight is to remove any possible objection until resistance looks purely stupid and wholly unsubtantiated. I agree. That's why we not only need a new name, we also need a cut'n'paste argument that just makes this look stupid. And it has to be short enough that cut'n'paste isn't bad, because if we refer people to the FAQ, they won't read it. I was just saying to my roomate that I was losing hope for Reiser4 because I didn't see an end to the politics any time soon. Yes, it can look pretty hopeless. There's only one possible way I see to get in. You must ask for an absolute list of things that are objectionable. You should then ask *before you start work* about removal of any items that are either a) impossible, or b) illogical. Once you've gotten the official stamp of approval of the (posibly recvised) absolute list of objections, you have to do it, completely and exactly. If they agreed that that is everything they find wrong and promised that they would include Reiser4 if those issues were resolved, then they really *have* to put it in then. The problem is, they don't. There have been some fairly definitive lists in the past, that were done, but maybe not quite the way they were expected. The core of all this is that rather than leaving an open-ended task that can be expanded at will, they are given limits to how long the objections can be spread out. Problem is, dictators can do whatever they want, even if they said something else before. And that's all assuming you can get them to agree to such a list, and agree to abide by it. They either wouldn't go for it, or they would come up with a list that effectively kills Reiser4, turning it into ext3.
Re: Another article abour Reiser4 on linux.com
A really stupid question ... why not put Reiser4 in one of the BSDs? And after it's got mainstream use, if it proves its worth, there'll be more pressure for Linux to adopt. On Sat, 5 Aug 2006, David Masover wrote: Clay Barnes wrote: I think the core thing we have to have to win this argument is a) A word that isn't *instantly* associated with banned things. That'd be nice. b) The ability to point to the technology to point to the design and say look, Look, it's *impossible* to use this design to put binary modules into the kernel. Even if it's as hard as ATI or nVidia modules to put it in, that'll be enough to put up a fight against inclusion. Why? Why does it have to be impossible to do binary things with the kernel? I mean, if Linus hates GPL3 because it limits what people do with the kernel... Besides, you can't make it impossible, you can only make it about as hard as it is now. The license is the issue here. The *only* way to win a polical/personal fight is to remove any possible objection until resistance looks purely stupid and wholly unsubtantiated. I agree. That's why we not only need a new name, we also need a cut'n'paste argument that just makes this look stupid. And it has to be short enough that cut'n'paste isn't bad, because if we refer people to the FAQ, they won't read it. I was just saying to my roomate that I was losing hope for Reiser4 because I didn't see an end to the politics any time soon. Yes, it can look pretty hopeless. There's only one possible way I see to get in. You must ask for an absolute list of things that are objectionable. You should then ask *before you start work* about removal of any items that are either a) impossible, or b) illogical. Once you've gotten the official stamp of approval of the (posibly recvised) absolute list of objections, you have to do it, completely and exactly. If they agreed that that is everything they find wrong and promised that they would include Reiser4 if those issues were resolved, then they really *have* to put it in then. The problem is, they don't. There have been some fairly definitive lists in the past, that were done, but maybe not quite the way they were expected. The core of all this is that rather than leaving an open-ended task that can be expanded at will, they are given limits to how long the objections can be spread out. Problem is, dictators can do whatever they want, even if they said something else before. And that's all assuming you can get them to agree to such a list, and agree to abide by it. They either wouldn't go for it, or they would come up with a list that effectively kills Reiser4, turning it into ext3.
Re: Another article abour Reiser4 on linux.com
TongKe Xue wrote: A really stupid question ... why not put Reiser4 in one of the BSDs? And after it's got mainstream use, if it proves its worth, there'll be more pressure for Linux to adopt. It will likely take far more work to port it to BSD than it will to be included in Linux. And you're talking about probably even less chance of inclusion or of picking up a large community than in Linux.
Re: Another article abour Reiser4 on linux.com
(I lost someone's response sorry) Re: hard to get into BSD There's Dragonflybsd; they seem very chill / acceptable to new ideas. On Sat, 5 Aug 2006, TongKe Xue wrote: A really stupid question ... why not put Reiser4 in one of the BSDs? And after it's got mainstream use, if it proves its worth, there'll be more pressure for Linux to adopt. On Sat, 5 Aug 2006, David Masover wrote: Clay Barnes wrote: I think the core thing we have to have to win this argument is a) A word that isn't *instantly* associated with banned things. That'd be nice. b) The ability to point to the technology to point to the design and say look, Look, it's *impossible* to use this design to put binary modules into the kernel. Even if it's as hard as ATI or nVidia modules to put it in, that'll be enough to put up a fight against inclusion. Why? Why does it have to be impossible to do binary things with the kernel? I mean, if Linus hates GPL3 because it limits what people do with the kernel... Besides, you can't make it impossible, you can only make it about as hard as it is now. The license is the issue here. The *only* way to win a polical/personal fight is to remove any possible objection until resistance looks purely stupid and wholly unsubtantiated. I agree. That's why we not only need a new name, we also need a cut'n'paste argument that just makes this look stupid. And it has to be short enough that cut'n'paste isn't bad, because if we refer people to the FAQ, they won't read it. I was just saying to my roomate that I was losing hope for Reiser4 because I didn't see an end to the politics any time soon. Yes, it can look pretty hopeless. There's only one possible way I see to get in. You must ask for an absolute list of things that are objectionable. You should then ask *before you start work* about removal of any items that are either a) impossible, or b) illogical. Once you've gotten the official stamp of approval of the (posibly recvised) absolute list of objections, you have to do it, completely and exactly. If they agreed that that is everything they find wrong and promised that they would include Reiser4 if those issues were resolved, then they really *have* to put it in then. The problem is, they don't. There have been some fairly definitive lists in the past, that were done, but maybe not quite the way they were expected. The core of all this is that rather than leaving an open-ended task that can be expanded at will, they are given limits to how long the objections can be spread out. Problem is, dictators can do whatever they want, even if they said something else before. And that's all assuming you can get them to agree to such a list, and agree to abide by it. They either wouldn't go for it, or they would come up with a list that effectively kills Reiser4, turning it into ext3.
