On 14/01/07, Jonathon Anderson <[EMAIL PROTECTED]> wrote: > Ubuntu developers: > > Why is the specification mentioned in [ > https://blueprints.launchpad.net/ubuntu/+spec/system-directory-approach > ] and [ > https://blueprints.launchpad.net/ubuntu/+spec/userfriendly-filesystem-structure > ] "oft-rejected"? Granted, these proposals are not very thought-out or > defined, but it seems like the kind of user-centric design decision that is > Ubuntu's foundation. I understand the benefits of the Filesystem Hierarchy > Standard (such as minimal-mount booting and interoperability through > standards-compliance) but these seem more like barriers-to-entry for an > otherwise ideal system: problems to be solved, not reasons to stay > entrenched. > > I think back to my gradual acceptance of OS-X. A staunch Windows user, I was > completely taken aback by the lack of "Add/Remove Programs," let alone > "C:\". > > As I became more familiar with Linux, I began asking myself "what is > '/etc'?" or "if I make a webpage, where do I put the .html files?" or "what > is the difference between '/bin', '/usr/bin', and 'usr/local/bin'?" (It took > me days to figure out what "usr" even meant!) > > I looked up the FHS on Wikipedia (and the subsequent links) and finally > understood the point of it all. Still, when I later used a Mac (as I > sporadically do) I realized that there was something more: "/Applications" > (et. all.) > > There's another side to this issue: atomic packages. I think back to my > Windows days: dll hell... untraceable files installed everywhere... the > registry... an unmanageable melting pot of binaries that could only be > cleaned out by periodically re-installing the operating system from scratch. > > I don't have this same problem on Ubuntu, but it's not because the problem > doesn't exist. In fact, I think the fileystem hierarchy in Ubuntu is way > worse from this angle. A program gets installed in /usr/bin, /usr/lib, /etc, > and who knows where else. It's manageable because there is a system (apt) > that keeps track of it all for you, but that makes package-management a > monolithic, cathedral task that is very isv-unfriendly. > > I believe that the adoption of the ideals presented by "GoboLinux" [ > http://www.gobolinux.org/ ] are a necessary component of the evolution of a > consumer-level desktop os (as opposed to an enterprise-level server os). > > Granted, this seems to be a consistently-rejected idea, and there must be a > reason for it. Still, in my reading, I have found no document explaining, > from the Ubuntu perspective, why this "oft-rejected specification" is, in > fact, oft-rejected. > > Comments are greatly appreciated. >
Two reasons: 1) Prohibitive cost. It would require large changes to the Debian packages and a lot of extra testing to implement. 2) No real benefits. The only plus this would provide is a Non-educated-user-understandable file system. The atomicity of applications is an illusion that will quickly disappear once you delete a dependency. While a non-educated-user understandable file system would be nice, it is a problem that can wait. User-installable packages would be higher on my wish-list. Mind you, there is a way to kill two bird with one stone: having file locations determined by meta-data as opposed to having them hard-wired into a tar-ball. This approach also has it's share of problems, including a high development cost, but at least it has more benefits than changing the FHS. Arwyn. -- Ubuntu-devel-discuss mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
