Results 1 to 3 of 3
Thread: Stepping away from the past
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Jul 2005
Stepping away from the past
I'm not talking about hiding the actual heirarchy like Mac and Gobo, I'm talking about actually rewriting it.
The one thing I have always loved about Linux, is its complete focus on leaving everything open for the end-user to decide what they want, so they can peice it together. Example, you dont like your shell, no problem choose from many others that fit your needs.
What I find most funny is, almost every person that I talk to in the Linux world express their dislike for the hierarchy being based on Unix and yet I have yet to see anyone or organization try to abandon it. The unix hierarchy was not built for todays world, and the number of applications modern desktop mechines envoke into their systems.
Strangely even "Linux From Scratch" the so called "Make it your way" assumes such a file system heirarchy and offers no means or explainations for going away from it.
If anyone knows of any URL that discusses this issue, or better is trying to do something about it please post it here. Please remember I'm not talking about links and hiding, I'm referring to a truely new hierarchy not surpressed by the old unix systems.
Well, first off, Linux IS based on UNIX, and the FHS allows for a common set of directories across Linux and UNIX systems, allowing programs to be easily installed and accessed across systems. Personally, I love it, as it ensures a certain standard that is (I, at least, find it) easy to use.
That said, while I don't know of any attempts to change the FHS, the Rox Desktop project uses a more Mac OS X approach to programs, by giving each program its own directory, wherein all binaries and data files are stored. Take a look:
- Join Date
- Mar 2006
In my opinion, the FHS is basically a good design, in that it generally lets programs find the files they need. The shell can find programs to run, the system daemons can find their configuration files, the dynamic linker can find shared libraries, and the C compiler can find header files. And, hey -- if it ain't broke, don't fix it, right?
In my experience, the biggest problem with the FHS design is that it results in a given package's files being scattered willy-nilly throughout the system, such that it's impossible to tell, in most cases, what package a given file belongs to. When building my own LFS system, I used the account-based package management scheme suggested in this LFS hint:
The basic idea is that each package is given a separate user, and the package's files are owned by that user. This provides a reliable way to identify files as belonging to a given package, thus solving the aforementioned problem.