Okay, I think I understand you now, Giddie. Rather than just having a means for the user to organize what they have access to on their systems by whatever means they want, you want a system in which the organization corresponds one-to-one with the actual system.

Interesting idea. Here's the thing, though... I'm not sure if it is a good idea.

The reason is one of information hiding. I firmly believe that purposely hiding information from the user is a bad thing. That is to say, a user should be able to get as much information about their system as they want, whenever they want. It shouldn't be hidden behind "user friendly" interfaces which will break in unrecoverable ways. Witness the horror that is the Windows registry. Sure, it's "easy" from a user standpoint, but when it inevitably breaks (or just becomes so clogged with junk) there is NO WAY to reliably fix it without just reinstalling the system. It's entirely opaque. You're not doing anyone any favors by hiding these things away. Better would be telling people straight up that the /Menu is just a representation of what's around and isn't what's actually there. Most people are capable of understanding this distinction.

There's no real way to do what you want without going back to installation databases ala RPM or APT. These are terrible solutions. They work, usually (just like the Windows registry works, usually), but when they fail they're very hard to recover from. They're also incredibly inflexible. Put something on your system which isn't in .deb form? It'll break things, most likely.

With a system like I proposed above, a failure is annoying, but not catastrophic. You accidentally delete all of your /Menu? Well, that sucks, but you can still use everything you have, and can easily rebuild the directory. Is it a leaky abstraction? Yes it is, but to some degree all abstractions are leaky and providing even -greater- abstractions does not seem like the right way to solve the problem. It seems like a hell of a lot extra complexity (and therefore points of catastrophic failure) for very little gain.

I also don't understand the requirement you have for having the CLI mirror the GUI insofar as your scheme is concerned. Surely if someone is going to use the big, scary CLI, they're capable of realizing the difference between a symlink and an entry, yes? If someone is willing to delve into the frightening world of text commands, then we can surely presume they already know the difference or, if they don't, are willing to learn.

All that said, you do make a good point about things being confusing to a new user. We are dealing with humans and as such they're unlikely to look through the documentation until a need really arises. So I can tentatively agree that the GUI might benefit with some hidden magic. But even this could surely be done without major surgery to applications. A FUSE filesystem might work, or even just a small plugin that watches for DBUS change file messages on /Menu and takes care of moving/compiling packages.

Anyway, I wish you luck on your endeavor!

Whoops!

Yes, I did misunderstand you. I had thought you wanted to install some kind of database system and, instead of filesystem commands actually going to the filesystem, they'd be pre-empted and just muck about with the database. So the database would allow one to present a view to the user of a system however they might like, but underneath nothing changed. Sort of like Apt on steroids, with file magic going on behind the scenes.

You can see why I said I wasn't particularly enthused with the hiding behind abstractions in this case.

Now that I've been set straight, though, I think I really do now know what you're saying. The thing is, I'm not sure what you're suggesting can be done cleanly or elegantly. Wouldn't it necessarily mean that every program would have their own copies of all the libraries they need? I suppose that wouldn't be too bad, but extremely wasteful. It'd also mean that even having dynamic linked libraries would be pointless; they can't share any code -anyway-, so you might as well statically compile everything. Fixing system bugs would also be horrendous; rather than just replacing one library, you'd have to replace every single app that used it... and you'd still not get them all, most likely.

Alternatively, you could have all the libraries needed in one place, but then you'd pretty much need in-kernel reference counting of them to make sure nothing breaks; if you do it in a demon and said demon dies, then the system becomes inconsistent and possibly unusable.

Something might be possible, though, by building on the /Menu idea. If a demon existed whose entire purpose was to monitor that directory using the inotify interface (and all of its subdirectories) and, if someone placed a .tar file somewhere, ran some install script... or, if someone deleted a symlink in /Menu and it correspondingly removed the entry in the /Programs directory... then you might be able to get what you want without having to do major surgery on the system as a whole. In this case, if the demon dies, it doesn't leave the system in an inconsistent state (though, admittedly, it could become so should the user do something that required the demon... but even then, the problem would be easy to fix and the system would still WORK just fine, just have some extra stuff or not install something new...)

And it would work as you wanted in the CLI as well, since the demon is monitoring the directory and doesn't care what causes the change.

STD, I think there are ways around the problems you've suggested.

Firstly, I'm thinking of using a FUSE filesystem. This means that it's not only possible to dynamically create symlinks of legacy trees if we so desire, but it's actually possible to detect when a program is looking for a file in the wrong place, and inform the user. It also makes it possible to provide different access privileges for different processes, making it possible to sandbox programs.

Secondly, an application's dependencies will be stored in its directory, a bit like how GoboLinux does it now. So when you tell the system to run the application, the system will know that MyApplication needs libblabla.so, but it may not know where it is. There are a few logical places to look for bundles containing libblabla.so --- the home directory, /Applications, etc... but it would take quite a while to search, so the baseline case is that the system asks the user to point it to the location of the dependency. To supplement this, the system can keep a database concerning the programs and libraries each known bundle provides. Next time, it will remember that libblabla.so is provided by /Libraries/MyLibrary, and it won't need to ask. If MyLibrary is moved or deleted, the FUSE fs will know about it, and can update the database. The important thing here is that the database helps the system work with the user; it doesn't restrict the user.

Another interesting aspect of the above idea is that you can have several bundles providing the same library. Maybe one's a development version, and the other is stable. When you first run an application that depends on it, the system will ask you which one to use, and that one will become the default. There's no reason why you couldn't change your mind later...