Hi there. I'm using gobolinux for a while now, and keep reading about its basic idea and how different people interpret it, and I'm starting to develop the feeling that something is somehow a little skewed in the interpretation of the filesystem layout we all want to change. Now in hoping I won't flame anything/anybody here, here it goes.

With just symlinks, Unix allows us to build a topology above a topology, a way to organize things for a reason, on top of a different way to organize things because of different reason. On those terms alone, gobolinux is an application of this idea, allowing us to organize programs because our package management needs, but at the same time, giving us the "legacy" FHS layout so that basic/core functionality like ld's way of finding libraries and bash's way of finding executables keep working. So a different layout for a different reason. That's why I don't see anything wrong with the FHS layout, on the contrary, I think it serves its purpose best, as gobolinux's own layout serves his. There are yet more layouts to think of that serve their purpose best, like the the need to organize files based on their storage policies (eg. /for-replication, /not-replicating, /for-daily-backup). All those are different concerns targeting _the same files_, that is, _cross-concerns_. And with symlinks we can have all those layouts one on top of the other without experiencing any conflict (ok, in practice this particular way of implementing that abstraction has some limits, but let's ignore that for now).

On the premise that the FHS locks instead of releasing, Gobolinux tries to replace the legacy layout, instead of going the way of stacked layouts, giving us yet another standard layout, as if its underlying reasons were superior than FHS' (gobohide is the proof of that idea). I think they're not. We need both layouts, and not because we just practically have to. FHS's goal is to allow apps to find their files and other apps' files and libraries in a portable way among Unix systems. It's a _functional_ layout aimed at portability and interoperability. Add symlinks to that, and FHS's paths are nothing but standardized _labels_ (equivalent to variables holding paths) that actually _free_ you from doing all the binding of your programs to your layout in config files and/or with compile-time options.

So FHS is there to give the programmer confidence in the meaning of /etc as "the standard location where this host keeps it's settings", not the "physical location". Whatever _concern_ you have over what "physical" should mean (be it package management, versioning, storage policies, etc.) you'll have to solve that at filesystem level with symlinks, bind mounts, etc. Because of this clear separation of concerns, whenever you reference say /etc/httpd.conf in another config file, script etc., what you get is a more portable config file/script than if you did /Programs/HTTPD/Settings/httpd.conf, because that path is not standard (GoboPath can't always be there for you), it tells a different story and serves a different purpose. Guess which path I'd use in a tutorial.

If that seems logical enough, then I'd love to see gobolinux stop confusing the two things, i.e. work in the GoboLinux layout when doing package management, but work in the FHS layout inside and between programs. The two layouts (along with their driving motivation) are so arbitrary to each other that they should be _transparent_ to each other (with the later on top). This also means stop using configure's --prefix option (which btw would clean up a lot of blood out of many recipes out there, make them less intimate with their victims, more reliable and easy to build) and only install programs in chroot jails and symlink them into place. Now you could just copy some programs to your other distro and SymlinkProgram them there and they could work (or am I missing something obvious here?).

So I'll keep doing all the layout-binding of my programs in the FHS layout. Heck, I'll even hardcode FHS paths in my progs and not even care about configure's --prefix option just to prove my point (just kidding). On the same line of thoughts I see little value in replacing root with uid0 except to make a cracker feel funny. I dig the conceptual liberation though :)

FHS's goal is to allow apps to find their files and other apps' files and libraries in a portable way among Unix systems.

k3b: (K3bMkisofsProgram) could not start /opt/schily/bin

I challenge your notion that the FHS will build reliable mechanisms with examples as above. There
are more of such examples and I really think the whole idea behind the FHS sucks. ;-)

One huge problem of the FHS is that it does not easily allow one to have multiple versions of a program installed.
This is what has lead to the whole .so.1.2.3 mess as well. It is a reason why on a typical debian system one finds a NEW symlink called
ruby under /usr/bin which points to a ruby1.8 symlink (or vice versa). If one compiles ruby from source, he does not get any
such arbitrary symlinks.

It is a layer of hacks and more hacks which only grow more and more complex rather than striving for elegance or simplicity.
The ugly UUID entries in "human readable" files like fstab are one example I hate. People say "use labels" but why would I want
to use labels to conceal the ugliness of UUID entries in fstab? Ubuntu was one example which spammed my fstab file with
UUID sections. There were no labels by default.

The way how udev was developed and grown is another ugly example. Fontconfig XML config files are another waste of human-time.
In a way I can understand tuomov with his rants. He has a few good points about it. The worst thing is - who the he** decides all
this stuff? Ok, fontconfig is easy, the authors were the ones who did use such an ugly config file. But what about udev? Is it the
Linux kernel devs who demand such a solution? Is it pushed by distributions?

And why are distributions so incompatible to each other anyway? Why are there so many different package managers?
Why do we really need the or THESE package managers in the first place?

Ruby has a package management system called gem. For Perl I guess it is cpan, for python maybe eggs and for PHP it is pear.

I think this is all silly. For many many reasons. Lets consider a few here. Perl as a language is ugly. But the perl fanatics promote
it as "ah but CPAN has so many solutions, this is really a plus for perl". That may be. The biggest question is - WHY DO ALL THESE
LANGUAGES NEED THEIR OWN SOLUTION FOR IT. Why cant they use a common ground. It would be the best for users.
They could choose among a huge array of solution but instead the scripting languages provide more and more packages
which can only be used in insert-your-scripting-language-here.
With C++ the situation is not so much different, insofar that many programs will require you to use Boost or the STL (or was
it SPL, i already forgot... but boost seems more popular anyway)

Gem (the ruby package manager) does not play along with debian's dpkg easily. So debian folks start to hate it too (though they
create problems as well by splitting up things so drastically. They claim it is better for the users. Well I say I dont care, I am a user
, I DO NOT WANT THIS distinction but I guess my only choice would be to not use debian in this case...).

Then there exists another problem - are gems installed under /usr or /usr/local?
The list with problems can be continued FOR SO LONG, it has so many new problems, it creates
more and more problems instead of simplifying the life of people. What will you do when you upgrade your versions? Will there be
any conflicts? Can you mix dpkg with gem's way? What about Gobolinux, will each of these addons become its own directory
under /Programs?

I partially agree about Recipes but this is because I do not think that having 1000 recipes in shell format is the best upfront solution. I also did not like revisions
much, it seemed way too much focus on cleaning and cleaning and cleaning those recipes... sounds like way too much work for something that should remain
simple. But then again the build systems have their problems as well.

In fact I think what you instead attack here is the build system. I remember a lot of people complaining about build systems... autoconfigure... scons... cmake... libtool.
I am one of those too. I think libtool's .la files are a horrible solution. GNU Autoconfigure is at least somewhat ok from a user's point of view.

I would like to see a more sophisticated build system which does away with all the disadvantages therein. On the other hand I thought
the /System/Index approach will solve some of your complaints but then again I wonder when we will have it. Hopefully before 2040 ;)

Now you could just copy some programs to your other distro and SymlinkProgram them there and they could work (or am I missing something obvious here?).

I guess it depends on the distro. Most of them are so f*cked up that it is not that easy to change them. I am sitting on a debian system right now where I am slowly cleaning it up :)
Its kinda a lot of work and while doing so one realizes how stupid the whole layout actually is. But then again I guess the best way for a user is to never ever care about it and just
do "your work" and leave the rest to the distribution maintainers anyway. Many others are doing exactly this, and I guess it works for them nicely. They probably do not care much about the
FHS as long as their system is usable.

On the same line of thoughts I see little value in replacing root with uid0 except to make a cracker feel funny.

I am not sure what you mean, the choice of name? I think it is fun to be able to easily and transparently change the name for the superuser. Other distributions should pick that up too.
usermod -l NEW_NAME root
would work too.

The FHS is practical for now. Things work because everyone more or less follows it. There is little real room for a change AWAY from it.

We are slaves.

PS: Why was my above comment too long for this forum software!!! :(

One huge problem of the FHS is that it does not easily allow one to have multiple versions of a program installed. This is what has lead to the whole .so.1.2.3 mess as well.

To solve this I can only think of running each program in a sandbox similar to the one in which they were compiled in. Kernel support (i.e. per-process mounts) is there, now we need to make this sandbox stuff. Otherwise I don't see how a certain layout, no matter how smart/different, can solve this, so no layout can be blamed for such failure. Sure, if you don't want two versions of a program _running_ at the same time, each in a different environment (eg. one using glibc 2.4, the other using glibc 2.5 both linking to libc.so), then it's already solved by SymlinkProgram.

About UUIDs, well, I'd wish fstab and mtab would disappear entirely. About the plethora of package managers, well yeah, after a few years, you just go for lightweight, even if you know you always get extra hours of sweat under this slogan. Combine that with an aversion of blackboxes which pkg managers usually are, and yeah, you're pretty much left with gobolinux.

But I diverge. The idea is that however ugly FHS is, as long as the programs find each other in this mess, I'd be happy to provide it for them as long as have control over it from underneath. All the linux programs that exist can never agree over a standard layout to find each other anyway (be it Gobolinux or FHS or whatever), but _interested pairs_ almost always do. I don't care that X11R6 is in /usr as long as that path is meaningful to interested programs. Why would I want to correct such established contract? As long as I can stack it on top of my own layout and my own concerns of course.

So FHS is there to give the programmer confidence in the meaning of /etc as "the standard location where this host keeps it's settings"

There is no real confidence.

I meant confidence for the programmer that he/she can design his/her program to look for its own config files in /etc and the host shouldn't complain about such requirement. Of course there's no real confidence _for the host_ that all programs respect this guideline and really install their config files in /etc.

In a way both locations totally suck. There simply is no "clear separation of concerns". The FHS does not care much about "clear separations of concerns", else it would not have mandated the wishy-washy /usr/X11R6 long ago. I guess it was grown in this regard "because some big distributions used it". I think it is wrong to continue claiming it to be any great clear separation of concern.

I was refering to separation between the "package management" concern and the "shared layout for apps to find other apps' files" concern. FHS only deals with the later concern, so yes, it doesn't and shuldn't care about such separation in itself. Two layouts one on top of each other actually achieve the separation.

Lets think with objects and messages instead for a thought experiment. I tell my object:
"look dude, give me all the config.php" and when i want to edit it i could do "config.php.edit" or whatever. Or send instructions in the form of a message.

install-gaim-1.2
remove-ruby

All these things in essence should mean that for a USER the thing becomes totally user.
You can layover fancy GUIs to achieve this without ever having to worry much about it or the physical locations.

I hope Linux never goes "the way of the library" (API) and sticks to "the way of the files" (layout) for such administrative tasks. But yes, an independent package management library for programs to install themselves through it, and later find their config data etc. through it would definitely tighten things up more than a layout could ever do. It will let you have one big config file for the whole system (but more likely a database, accessed through the same API), and it would free people of inventing and parsing their own syntaxes over and over again. But that's how MS people thought when they invented the Windows Registry :) I'd personally stick to "everything is a file" and plain text config files as they are in the Unix culture.

Posted By: cosminapTo solve this I can only think of running each program in a sandbox similar to the one in which they were compiled in. Kernel support (i.e. per-process mounts) is there, now we need to make this sandbox stuff.

There is a draft for such mechanism called ViewFS (see this thread for some more information).

Posted By: cosminapI meant confidence for the programmer that he/she can design his/her program to look for its own config files in /etc and the host shouldn't complain about such requirement.

Better if the programmer design the program to look for config files in "--sysconfdir" or similar.

Posted By: cosminap"root" is not perceived as the default user name that has superuser privileges in most distros, instead it is perceived as a common noun

(my emphasis)
Assumption is the mother of all mistakes. Assuming that "root" is the superuser is bound to break. Developers should use UID 0 to reference the superuser, though most applications doesn't need to use superuser privileges. The developers that unnecessary implement that are just lazy.
The difference between a variable ROOT and the variable PATH is that UID 0 is standard (in Linux at least - I haven't read posix), while the system path for finding executables is not.

Posted By: cosminapI'd unify $HOME/ over / and chroot to that on login.

So would I, but currently it's not possible to chroot as regular user under Linux at the moment.

Posted By: cosminap
If that seems logical enough, then I'd love to see gobolinux stop confusing the two things, i.e. work in the GoboLinux layout when doing package management, but work in the FHS layout inside and between programs. The two layouts (along with their driving motivation) are so arbitrary to each other that they should be _transparent_ to each other (with the later on top). This also means stop using configure's --prefix option (which btw would clean up a lot of blood out of many recipes out there, make them less intimate with their victims, more reliable and easy to build) and only install programs in chroot jails and symlink them into place. Now you could just copy some programs to your other distro and SymlinkProgram them there and they could work (or am I missing something obvious here?).

A new version (3.0) of Gnuppix is ready! (if anyone cares :-)
I now use the default --prefix for all programs and symlink to FHS.
I have tried to keep the layouts completely transparent to each other. A key to the transparency is to only symlink regular files. The directories are simply created (in FHS) and populated with symlinks to regular files.
http://linuxconfig.dyndns.org:1184/lazy/LazyLinuxWiki/Gnuppix/Introduction