![Filesystem Hierarchy Standard - Reference Poster / Cheatsheet [Dark mode in details]](https://lemmy.world/pictrs/image/d6993f48-858d-40ad-8ab8-9f921d56b7b8.png){kind=link}
Hey, I’ve recently designed a Poster about the FHS since I often forget where I should place or find things. Do you have any feedback how to make it better?
I updated the poster: https://whimsical.com/fhs-L6iL5t8kBtCFzAQywZyP4X use the link to see online.
Dark mode
Old version
Of course you can, but few people care and do it. There is a saying about docker: “Docker images are like smoothies, you immediately know if you like it but you don’t know what’s inside”. The idea being that there is no good quality control and transparency. People just install random blobs, like in the old days where you would install a cracked game from eMule.
If you care about security, docker is not what you want, they are not reproducible nor transparent nor is it possible to easily update broken shared libraries (eg openssl).
But then again people have different requirements. Some just wanna have things running quickly without the hassle. That’s where docker shines. But it leads us to a world where we hide ugly stuff under the carpet instead of fixing things.
Agreed but can’t the same be said about pre-compiled binaries?
At least with a Dockerfile I can download the repo and make them image for myself.
Sure you could’ve downloaded the repo and compiled the binary for yourself but you still had to have all of the libraries setup correctly. It’s more about a codified build process that’s reproducible vs a “supposedly” working documentation on a git repo of make scripts.
There is a lot of work being done on reproducible builds in the guix project and other distros. The idea being that you can be sure that a binary package is bit for bit the same, whoever builds it and on whatever system. This would be the first time you have complete traceability of what goes into your binaries.
On guix, you can for example install substitutes of packages which you could also build manually. Since the build environment and the dependencies are very tightly controlled, you have mathematical proof that the substitute is equivalent to the package built by the maintainer. You can thus be sure that no evil third party injected malware into the substitute binary, unless ot was done at source code level and the package maintainer has put it there (by accident).