| |||||||||||||
On the conviction of Hans ReiserOn the conviction of Hans ReiserPosted Apr 30, 2008 20:33 UTC (Wed) by zooko (subscriber, #2589)Parent article: On the conviction of Hans Reiser
Thank you for this article, Jon. Again you've done a fine job of addressing important issues plainly. One small comment that you made that I question, though, is this: "There are limits to how long reiser4 development can be carried forward as a labor of love." Aren't most successful open source projects labors of love? At least in part? Or at least in their inception? There's a good thesis to be made that an unfunded open source project has a *better*, rather than worse, chance than a funded one, because labors of love are sometimes done more, well, lovingly than paid work. Obviously that is not always true, but neither is the converse. To address the issue of reiser4 specifically, it seems like it might be nearing inclusion in mainline at this time. Edward Shishkin is still working on it, and I believe Andrew Morton mentioned it as a possibility for inclusion in his 2.6.26.
(Log in to post comments)
name space ideas Posted Apr 30, 2008 22:41 UTC (Wed) by ccyoung (guest, #16340) [Link] were imho very indeed kool, and I was always surprised by the community's apparent apathy toward them. it's hard to read his paper (as poorly formatted as it is) and not come away enthusiastic about the ideas and envisioning new tools and paradigms. even trivial things like enumerated types as filesystem objects - free maintenance (no interface needed), free debugging interface, language independence - sort of like SQL for gamers as vs databasers - all directly plugged into the filesystem.
name space ideas Posted May 4, 2008 3:03 UTC (Sun) by jd (guest, #26381) [Link] I personally think the idea of programmatic, polymorphic namespaces to be interesting. How you would actually make use of such a design is another matter. What, really, does a polymorphic namespace mean at the conceptual level? If there is no concept behind the technology, then all you have is a bunch of instructions. (Yes, I dislike modern art, too.) You also have to consider the overheads. Modern hardware is serial and procedural. There's a huge overhead in translating between modern programming methods and what a computer actually does as it is. Adding yet more concepts alien to the underlying architecture is just going to slow things down. It has to, because this type of abstraction is just a fancy way of emulating in software those things the hardware cannot do, and software emulation is always going to be slow. (Regular abstraction hides the specific details of how things are done, but doesn't change the fundamental ideas.) Now, for some things, the speed of the software isn't the most critical factor. Aerospace and medical software, for example, have to have a very high degree of reliability. Speed is a secondary consideration in such cases, and so you actually want any kind of abstraction that reduces the chance of failure, even if it sacrifices performance to do so. You don't use filesystems a whole lot in such mission-critical systems, and it's certainly not clear that Reiser4 is going in a direction that would even be helpful in achieving extreme reliability even if they did, but one could imagine that intelligent filesystems could be valuable in that sector. Someday.
|
|||||||||||||