the filesystem hierarchy of modern operating systems

[Arwyn Hainsworth]

On 14/01/07, Jonathon Anderson <anderbubble at gmail.com> 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.