Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Thread beginning with comment 505624
To view parent comment, click here.
To read all comments associated with this story, please click here.
jabjoe
Member since:
2009-05-06

I don't think the file hierarchy needs to be seen by most users. The UI guides them to stay in home and provides drives not mounts (though of course they are really mounts). They have UIs to configure things. Any users more advanced than that can understand the file hierarchy, it is not hard, very little to read. So who is this for?

The difficulty can not be dismissed. Cutting the wood how you want regardless of grain, just makes crappy furniture.
The difficult is not in the changing of decades and decades of code (which you aren't going to be able to do, so you will need a legacy tree). The difficult is getting everyone to commit to such a large body of work for so little gain. They won't agree to a all new hierarchy, and they won't agree to some indirection standard. Even if the world wasn't what it is and you convinced the majority of developers to change, there will still be enough that you have to do a legacy tree, making your system more complex than what was there before as it requires both and to understand how they interact.

We already have a mess like this with audio. OSS, ALSA and PA. Revolution doesn't work. If the Linux audio guys had evolved OSS instead of made ALSA, they would have come to something like OSSv4 and we wouldn't have this mess.

I can see you are determined and single minded when you have committed to something, like myself, but you are on the wrong track and I hope you don't waste years on this. You have been calm and patient making your point, that bodes well, so maybe you can see what I'm saying and avoid this time/life sink.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

jabjoe,

"I don't think the file hierarchy needs to be seen by most users."

Sometimes it's difficult to avoid, but I am not going to disagree with you on this point in principal.

"Any users more advanced than that can understand the file hierarchy, it is not hard, very little to read. So who is this for?"

It's not about only about "understanding", but about organizational consistency, clarity, and the simplicity of keeping application files together. Frankly dos applications were much easier to manage because they had this property. Of course external dependencies are sometimes a necessary evil, however it would be great if those external dependencies could be managed using simple & explicit resource dependency maps.

Of course what we have now works, and the repositories hide alot of the complexity for most users. But that is just pushing the problem upstream. Install an app like asterisk or ffmpeg from source and tell me dependency hell isn't a problem under linux. I think solutions are within reach, but we need to start with cleaning up our messy inconsistent directory hierarchies.


"The difficulty can not be dismissed."

I don't think the solution needs to be as difficult as you imagine. Mine is just one solution, but there are other possibilities. I think it could be done transparently by adding a process resource map which would get loaded by the distro. This map could be anywhere, but in a GoboLinux hierarchy it would make sense to keep in the application's directory. This would allow the distro to abstract absolute hard coded paths in binaries to distro specific paths. As with GoboLinux today, this would also make managing/running multiple versions a breeze.

"You have been calm and patient making your point, that bodes well, so maybe you can see what I'm saying and avoid this time/life sink."

I'm not getting a clear message on whether you are speaking so discouragingly because you don't want others to make progress on this front, or if you merely think we're too entrenched in compatibility issues to fix it.

Reply Parent Score: 2

jabjoe Member since:
2009-05-06

Of course external dependencies are sometimes a necessary evil, however it would be great if those external dependencies could be managed using simple & explicit resource dependency maps.


Oh please don't start saying shared object files aren't needed any more. For each process running on you system, add up the sizes of all the shared files in use. Then add up all the files sizes, but only add once for each shared file. Compare. It was like 1GB last time I checked! That's before you get into updating being cleaner with shared files. I've got very little time for the "we don't need DLLs any more" camp. It's easy to find what uses what forwards using ldd and backwards (and forwards to if you want) with repository info.

Install an app like asterisk or ffmpeg from source and tell me dependency hell isn't a problem under linux.


Never touched asterisk, but I've built ffmpeg a few times over the years, I don't remember anything about it being hard. Grab the source, do, "apt-get build-dep ffmpeg" and ./configure, make and make install. Easy. You can also keeping doing ./configure and get each dependency if fails against. Some project have either as part of ./configure or separate, a script to pull down the dependencies from a number of repository systems. Setting up a build environment in Linux is far far far far far far far easier than on Windows or RiscOS.

This would allow the distro to abstract absolute hard coded paths in binaries to distro specific paths.


And how are you going to convince them it's a problem they need to solve? Its not for a problem for them.... Not everyone sees what you see as a problem, as a problem. Those people aren't going to lift a finger to help.


I'm not getting a clear message on whether you are speaking so discouragingly because you don't want others to make progress on this front, or if you merely think we're too entrenched in compatibility issues to fix it.


I'm trying to save you time/pain. I don't think for a moment you will get any further than Gobo and it will be a painful experience. I guess that is discouragingly, but the motivation is kindness. I'm sure it is at very least an educational experience, reopening all those sealed can's of worms.

Anyway I think we call this, this is now a crazy thread. We aren't getting any where with each other. Good luck, maybe I'm wrong and something will come out of it. I'm a happy debian user and the only file hierarchy change I want right now is multiarch.

Reply Parent Score: 2