time for (another) change?
time for (another) change?
Posted Sep 22, 2005 9:58 UTC (Thu) by zmi (guest, #4829)Parent article: Reiser4 and kernel inclusion
Reiser4 should be merged. People can choose if they want to use it or not.
If the namesys people will not fix bugs, mark it "experimental" in the
kernel options. But merge it!
Linux should be innovative, and reiser4 could be. It sounds like a good
step in a new field.
I'm still missing the very nice and simple to understand filesystem
features that Novell's Netware provided already back in at least 1996
(Netware 4). With a few clicks, users or groups could be assigned all
types of accesses. ACLs do the trick now, but are not that easy to use as
those on Netware.
Linux should try to become more user friendly (still), and reiser4 could
be a good step.
Posted Sep 27, 2005 2:21 UTC (Tue)
by kirkengaard (guest, #15022)
[Link] (1 responses)
Hans refuses to acknowledge the fact that this whole argument is really him winning kernel support for reiser4, since accomodations *are being made* to do so. Full inclusion will happen when everything is kernel-maintainable and functionally stable. Experimental features belong in -mm until those two criteria are met.
Also, just to say it plainly, namesys will not support 4 past the release of 5, just as they don't support 3 now that 4 is out. Hans Reiser does not want non-namesys-employed hands working in "his" codebase, and so protests efforts to change his work to conform to a) kernel code requirements, and b) user-desired features and bugfixes added in a completely kosher fashion (a la GPL). Until Hans thinks like the rest of the GPL world thinks, namesys products will continue to fail the expectations of F/OSS -- and especially Linux kernel -- programmers. That's at least half of the adoption hurdle, ignoring the equally applicable ad hominem attacks -- and if you think social graces shouldn't matter, tell that to your boss/loan officer/HR manager next time you see him/her/them.
Posted Sep 27, 2005 6:47 UTC (Tue)
by zmi (guest, #4829)
[Link]
... is that merging a filesystem is unlike merging a device driver in non-trivial ways. The filesystem used has a dramatic effect on system functionality, in ways that even a networking driver does not. Moreover, merging a filesystem that agrees with the design principles and specs of the operating system is much easier than merging revolutionary works like reiser4, because the compliant filesystem necessitates orders of magnitude fewer changes to the way everything else expects a filesystem to work. The "Just adopt it already" position ignores the fact that reiser4 expects things that the kernel will natively disagree on in use, and the kernel expects things that reiser4 will screw up. Work is ongoing; we wouldn't be having this debate if reiser4 was being rejected.What you all fail to acknowledge ...
> Experimental features belong in -mm until those two criteria are met. What you all fail to acknowledge ...
If it's "just" this, then a delay is of course necessary. Only when
stability is more or less to be expected (don't dare to say
"guaranteed" ;-), an inclusion is appropriate.
> Hans Reiser does not want non-namesys-employed hands working in "his"
> codebase, and so protests efforts to change his work to conform to a)
> kernel code requirements, and b) user-desired features and bugfixes
> added in a completely kosher fashion (a la GPL).
Why can there be a discussion about this? If they don't support it,
somebody else should. He should fix it or shut up. Progress should be
done, in order have more features. Although I personally am happy with
reiser3, it just works and is stable. But it's becoming slow after some
time working with it, just like NTFS. Hopefully reiser4 with it's builtin
defragmentation can help there.
mfg zmi