7 ms·
>Over-elaborated hierarchies where configuration files may reside, and their precedence schemes. >Read the manpage for all the hilarity. If you find it hilari
by Arnavion 3y ago
>Over-elaborated hierarchies where configuration files may reside, and their precedence schemes.
>Read the manpage for all the hilarity.
If you find it hilarious it's because you don't understand the reason. /usr belongs to the distribution and /etc belongs to the user. The distribution doesn't touch /etc and the user doesn't touch /usr.
Upstream ships a unit with its own opinion of the defaults. That unit goes in /usr.
Distribution would like to override a default. It can patch the file but that is somewhat harder to discover (it would require reading the package source). Alternatively it can add a drop-in. That drop-in goes into /usr too since it's a distribution file.
User would like to override a default. They should not edit /usr because that belongs to the distribution. They drop their override in /etc.
Some units are created at runtime on demand and thus ephemeral, like mount units generated by generators. These go in /run. These are functionally "system-provided units" because users must be able to override them, so they're below /etc in the hierarchy.
The "defaults" and "overrides" we're talking about are both at the level of the individual setting as well as at the level of the whole file. If a user wants one of the settings to be different, they can add a new 99-foo.conf file that unsets / changes it. If they want a whole file to be different, they can add a new file with the same name that is empty / has different values for its settings.
BTW `systemctl cat whatever.unit` will print all the files that systemd considered in the order that it considered them.
>And this is just an excerpt which doesn't cover the details.
The only detail your excerpt doesn't include is the consideration of `service.d/`, `socket.d/` etc directories which provide overrides for all units of that type. It's just one point, not commonly used, and not that big of a deal either.
- stinos 3y agoand the user doesn't touch /usr. So it's not hilarious statements like this make it hard to understand the reason? I almost cannot tell whether your whole post is sarcasm, or just showcasing irony.
- bayindirh 3y agoYes, "The user (syadmin) doesn't touch /usr, except /usr/local", where compiled in applications reside with full path so /usr/local/{bin,sbin,share,...}. If you're deploying an especially big application, you may also prefer /opt/$APPNAME/{bin,etc,usr,...} (A full filesystem tree, basically). We manage a fleet of systems at work, and I don't remember editing or touching a file under /usr, unless the period I was developing .deb or .rpm packages to deploy on said fleet. There are many written and unwritten rules in Linux world, and sometimes people disregard or ignore these rules so blatantly, so I can't understand whether the post I'm replying to is a sarcasm or irony.
- hedora 3y agoThe rules are very much written down. For instance, here are the rules for /opt: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/reference_guide/s1-filesystem-fhs#s3-filesystem-opt https://access.redhat.com/documentation/en-us/red_hat_enterp... There's also a section for /usr.
- teddyh 3y agoI’d start here: • Filesystem Hierarchy Standard <https://www.pathname.com/fhs/ https://www.pathname.com/fhs/> • For Debian (and derivatives): <https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy https://www.debian.org/doc/debian-policy/ch-opersys.html#fil...>
- teddyh 3y agoAnd, of course, hier(7): <https://manpages.debian.org/stable/manpages/hier.7.en.html https://manpages.debian.org/stable/manpages/hier.7.en.html>
- deleted 3y ago[deleted]
- marcosdumay 3y agoYou mean that the top-level Linux directory are hilariously badly named? If so, I don't think anybody will disagree. But if you meant that's a large problem, then well, no it isn't. There are 7 of those badly named ones. It's a matter of reading half a page of text to see what they do, and after 2 or 3 times you read it as reference, you have them memorized. If would be nice to solve the issue, but it isn't anybody's priority.
- eviks 3y agoOr you'll never memorize them because those 2 or 3 times are many months apart since you're just a user that rarely tweaks those configs But yeah, ease of use is nobody's priority
- nickdothutton 3y agoI think there is a gap here between those who routinely (exclusively?) used UNIX machines along with 50, 100, 1000 other people all logged in at once (generally pre-Linux era) and those who only ever got to see and enjoy a time when everyone could have a UNIX workstation on their desktop (Linux, Mac, or other x86 flavour, take your pick).
- hedora 3y agoBack in the shared era, the machines were better-suited to individual customization, and were more easily understood by system administrators. Now, they're optimized too... waste more computational resources when idle?
- wpietri 3y agoYeah, I really feel like we're in a "horseless carriage" or "radio with pictures" era for computing. We have incredibly powerful machines available. But the dominant paradigm for managing that power is to slice it up into things that simulate much less powerful processors in software environments designed for a shared 1970s university department minicomputer. In many ways I love it, of course. It's what I grew up on, and I'm sure I'll have a small Linux cluster in the retirement home, because that's how computers are "supposed to be". But I think the old paradigm has only lasted so long because we have so much computing power to burn.
- jaystraw 3y agoI'm not sure I understand. When the "old paradigm" was new, computing power was much more limited. They couldn't afford to "burn" any computing power. But it's only stuck around, because now we have more computing power? That doesn't make sense
- wpietri 3y agoYou might read some Kuhn. Paradigms change when the old one becomes unsupportable. But the vast increase in computing power per dollar means we can waste a lot of it without it being economically uncomfortable. Well, most of us. A good check on this is a podcast where Dr Kevin Bowers is interviewed: https://www.youtube.com/watch?v=GlzWM5GKQT8 https://www.youtube.com/watch?v=GlzWM5GKQT8 He works for a financial trading firm, where the competitive nature of it means that every processor cycle counts. For him, older paradigms are perplexing and irritating, because they are major barriers to getting the most out of the hardware.
- Eldt 3y agoIt's both hilarious and unintuitive, but for some people their personal familiarity trumps most other things
- pierat 3y agoIt's makes a lot more sense when you realize that /usr doesn't stand for "user", but "user software resources".
- gjvc 3y agounix system resources
- kps 3y ago/usr stands for ‘user’. In particular, in our own version of the system, there is a directory "/usr" which contains all user's directories, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk. — https://www.bell-labs.com/usr/dmr/www/notes.html https://www.bell-labs.com/usr/dmr/www/notes.html
- dreamcompiler 3y agoX11 clients and servers are now whispering "Hold my beer."
- ElectricalUnion 3y agoIf you want to use /usr for yourself, be prepared to throw the FHS and compability with almost everything away and rebuild your whole userland with something like NixOS/Guix.
- squeaky-clean 3y agoI can't see how this doesn't make it more hilarious. It gives me "There's no fighting in the war room" vibes.
- hedora 3y ago> Distribution would like to override a default. It can patch the file but that is somewhat harder to discover (it would require reading the package source). Alternatively it can add a drop-in. That drop-in goes into /usr too since it's a distribution file. > User would like to override a default. They should not edit /usr because that belongs to the distribution. They drop their override in /etc. Larry Wall elegantly solved these problems 38 years ago with the "patch" utility. Debian is a good example of how its use has been standardized to solve these problems. The patch approach to managing distribution-provided configuration files is superior to the systemd unit approach for at least three reasons: - Non-experts can read the configuration files from top to bottom in linear order, so the documentation can be inlined by the distribution provider, which means they can add maintainers notes as necessary. - It also works better than the systemd unit style of configuration for sophisticated users. In particular, if you add a now-incompatible option to the file in the suggested place (next to the documentation and commented out default version of the setting), then the package management system can detect that you've made a potentially breaking change before installing the new software, and ask you what to do. This works in the absence of sophisticated data modeling, schema mapping tools, etc. - The implementation of all this is factored out and standardized across 1000's of packages, so it only needs to be implemented once and understood once.
- faangsticle 3y agoYou don't have to be an expert to read multiple files. If you do need expert assistance with something like that please contact me and we can work something out.
- eviks 3y agoThe "expertise" is in finding those files and understanding their hierarchy
- manuel_w 3y agoRebasing patches is pretty hard I'd say. Much harder than just explaining someone the logic behind /lib, /etc and /run. I mean, this directories are seperate for a reason. Knowing the idea behind the directory split (a.k.a. Linux Filesystem Hierarchy Standard) is more essential than knowing how to use the patch command line tool. There are more and more people who don't want to use the command line. And that's completely fine. > - It also works better than the systemd unit style of configuration for sophisticated users. In particular, if you add a now-incompatible option to the file in the suggested place (next to the documentation and commented out default version of the setting), then the package management system can detect that you've made a potentially breaking change before installing the new software, and ask you what to do. This works in the absence of sophisticated data modeling, schema mapping tools, etc. Anecdata, but still: Every single time the package manager asked me what to do, it was not because of a breaking change, but simply because the base file changed in a way that the patch didn't apply cleanly anymore. That is, I, the user, had to work around limitations of the patch format. If the distro configuration and the user configuration had been separate files, things would have just worked fine.
- wpietri 3y ago> If you find it hilarious it's because you don't understand the reason. I think it's hilarious that you think users are supposed to understand "the reason" at this level of detail. When we make a thing, we make choices about who it's for. Sometimes those choices are explicit. But this is a good example of an implicit choice. Clearly it grew into this shape for reasons, but those reasons are about the people doing the making, not the people using it. Even if we grant that all of this hierarchy is necessary, it still imposes a large burden on the person trying to figure out "why is X doing Y?" And that might be fine if the makers said, "Well this is going to be hard, so what can we do to make it easy?" But denying that users will reasonably find this hilarious (or frustrating or impossible) is just digging the hole deeper. Telling people that their understandable reactions are wrong doesn't change their reactions, it just gets them to stop mentioning the problems around you.
- faangsticle 3y ago[flagged]
- wpietri 3y agoWell that's hilarious too, in that I just pointed you to a bigger context.
- monkeywork 3y agonot sure how you thought your comment here would be useful. If snark is the only option sometimes it's better to just close the browser.
- thayne 3y ago> it still imposes a large burden on the person trying to figure out "why is X doing Y?" Systemd has tools for that, such as systemctl cat which shows all applicable configuration and what files they come from. Personally I have found the systemd hierarchy to be very useful. It allows me to create overrides for certain properties in a Unit without having to worry about keeping the rest in sync with upstream, or my package manager overwriting my configuration. And it allows me to have different independent packages (or chef recipes or ansible playbooks) that create different override files for the same unit without stepping on each others toes. Yes it is a little complicated, but for most end users, you don't really need to worry about most of the complexity, you just need to know where you put your overrides. And for distributors and power users, that complexity serves a useful purpose.
- olliecornelia 3y agoAt least acknowledge how retarded this all sounds.
- gpm 3y agoThis is why /usr/local/bin is located in /etc right?
- Aerbil313 3y agoIt’s still hilarious. The fact that there’s a need for this hilarity doesn’t negate that. What a mess humanity have created… (Let’s write a suckless OS!)