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 505673
To view parent comment, click here.
To read all comments associated with this story, please click here.
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

Alfman Member since:
2011-01-28

jabjoe,

"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"

I didn't really say that, but I consider it a separate topic. I don't consider shared libraries bad per say, but some kind of organization is needed to help keep sanity. It's not a good thing to dump all libraries in global directories even though that's where they go today.


"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."

I would always expect that the distro repository sources to have already been customized for the distros, however they are very frequently out of date. If you install a version directly from the developers, the onus goes to you to fix it up to work with your distro. Ideally extra work wouldn't be necessary.

"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."

Not everyone needs to be convinced, just enough to make a sustainable project.


"I'm trying to save you time/pain."

Constructive criticism is good, but to be perfectly candid some of these remarks read as though you are trying to speak down to us rather than to be helpful.

Reply Parent Score: 2