Linked by Amjith Ramanujam on Fri 25th Jul 2008 16:08 UTC, submitted by diegocg
Daniel Phillips has announced the prototype design of a new linux filesystem (implementation has only begun). The most interesting thing seems to be a different way of implementing versioning: "Unlike the currently fashionable recursive copy on write designs with one tree root per version, Tux3 stores all its versioning information in the leaves of btrees using the versioned pointer algorithm. This method promises a significant shrinkage of metadata for heavily versioned filesystems as compared to ZFS and Btrfs".
Thread beginning with comment 324699
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Porting HAMMER fs from DragonFlyBSD to Linux
by hamster on Sat 26th Jul 2008 19:37
in reply to "RE[7]: Porting HAMMER fs from DragonFlyBSD to Linux"
Member since:2006-10-06
But it is kinda weird that they are all for sharing code but yet they have a problem with giving back to diffenrent bsd licensed projects don't you think? Now who's the hypocrite?
problem is, the BSD license ( and BSD licensed projects) actually is about, unidirectional spreading of the code, as wide as possibile - with no contributing back required (of course it's welcome, but it's not mandated)
giving away the code for others to use it and integrate it ( or parts of it) in their own projects (relicensing is also possible) in order to it to be considered the reference implementation of what it represents (be it a specification, an algorithm, or a combination thereof, such as a "unix" variant) is an intended result
and it has to be that way, given the environment the BSD license was born (academic research, whose results were to be openly available)
otoh, the gpl requires code contributions in return - not only that, it requires the code to stay open, thus remaining "free" being protected from those menacing its "freedom"
bu that was meant to satisfy the first requirement of "free software" as a distributed development method ( apart from any social and ethical implication, that is ): to ensure that sw development is done cooperatively among peers, the SW is required to stay "free"
but then that SW is not intended as, and will hardly become, an industry standard reference implementation
closed source developers will have to develop their own (based on the BSD one, maybe), but that is often the goal in this case...
bottom line, given their respective goals and backgrounds, expecting the same from the GPL and the BSD ( or projects using oneof them) is not fair towards either ...
problem is, the BSD license ( and BSD licensed projects) actually is about, unidirectional spreading of the code, as wide as possibile - with no contributing back required (of course it's welcome, but it's not mandated)
giving away the code for others to use it and integrate it ( or parts of it) in their own projects (relicensing is also possible) in order to it to be considered the reference implementation of what it represents (be it a specification, an algorithm, or a combination thereof, such as a "unix" variant) is an intended result
and it has to be that way, given the environment the BSD license was born (academic research, whose results were to be openly available)
otoh, the gpl requires code contributions in return - not only that, it requires the code to stay open, thus remaining "free" being protected from those menacing its "freedom"
bu that was meant to satisfy the first requirement of "free software" as a distributed development method ( apart from any social and ethical implication, that is ): to ensure that sw development is done cooperatively among peers, the SW is required to stay "free"
but then that SW is not intended as, and will hardly become, an industry standard reference implementation
closed source developers will have to develop their own (based on the BSD one, maybe), but that is often the goal in this case...
bottom line, given their respective goals and backgrounds, expecting the same from the GPL and the BSD ( or projects using oneof them) is not fair towards either ...
Nice post no imflamatory outburst i'll try to keep the same standard. But you failed to answer my question isnt it kinda backwards so to say that you are for sharing code and yet not doing it with the project you use code from?
I don't expect anything from either licens. I just asked who was the hypocrite when one side says take what you want and the other side says we are all for sharing code but only if we have to..?
RE[9]: Porting HAMMER fs from DragonFlyBSD to Linux
by AlexandreAM on Sat 26th Jul 2008 20:56
in reply to "RE[8]: Porting HAMMER fs from DragonFlyBSD to Linux"
Member since:2006-02-06
I understand your personal problems with this behaviour of GPL. And, in fact, I think it is a problem with the license too.
Unfortunately, I believe it is a needed problem. It's not like the GPL camp is against the BSD camp (well, perhaps RMS is, I can't tell for sure, only attending to one lecture of the guy). It's more like "We can't be compatible with BSD with the risk of having the software we develop being ripped without ensuring the basic rules by which the spirit of this license was born, so we just aren't compatible"
Is that a reasonable explanation for you ? Mind you that I'm not saying it IS the real explanation, it's just how I feel about the situation.
Regards.
Member since:
2006-03-01
But it is kinda weird that they are all for sharing code but yet they have a problem with giving back to diffenrent bsd licensed projects don't you think? Now who's the hypocrite?
problem is, the BSD license ( and BSD licensed projects) actually is about, unidirectional spreading of the code, as wide as possibile - with no contributing back required (of course it's welcome, but it's not mandated)
giving away the code for others to use it and integrate it ( or parts of it) in their own projects (relicensing is also possible) in order to it to be considered the reference implementation of what it represents (be it a specification, an algorithm, or a combination thereof, such as a "unix" variant) is an intended result
and it has to be that way, given the environment the BSD license was born (academic research, whose results were to be openly available)
otoh, the gpl requires code contributions in return - not only that, it requires the code to stay open, thus remaining "free" being protected from those menacing its "freedom"
bu that was meant to satisfy the first requirement of "free software" as a distributed development method ( apart from any social and ethical implication, that is ): to ensure that sw development is done cooperatively among peers, the SW is required to stay "free"
but then that SW is not intended as, and will hardly become, an industry standard reference implementation
closed source developers will have to develop their own (based on the BSD one, maybe), but that is often the goal in this case...
bottom line, given their respective goals and backgrounds, expecting the same from the GPL and the BSD ( or projects using oneof them) is not fair towards either ...