3 ms·

The typical convention these days is: - /usr/ is read-only data. /usr/bin/ contains OS-supplied binaries, /usr/lib/ contains OS-supplied libraries. - /var/ is

The typical convention these days is: - /usr/ is read-only data. /usr/bin/ contains OS-supplied binaries, /usr/lib/ contains OS-supplied libraries. - /var/ is read-write state data and will persist between boots. /var/log/ is for log files. - /run/ is read-write scratch on a tmpfs, and will be cleaned up between boots. So, UNIX sockets and other temporary files go here. - /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. - /opt/ is "vendor space". The OS should never touch /opt/. The names are weird, but that's the intention behind the new scheme. If you want to change configuration, the default config might be shipped read-only in /usr/, but it should be overridable in /etc/. This is why systemd ships read-only unit files in /usr/, which are symlinked into /etc/ to be "enabled".

asveikau 6y ago
/usr/local/etc is a common pattern, though. So maybe I would add that /usr/local is a special case of /usr for locally built* stuff, with sub-nodes imitating the corresponding nodes in /. * Not always locally built, though. *BSDs put binary packages there too.
Blikkentrekker 6y ago
> /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. I find this goal to be rather frustrating. It means that software will hardcode it's default configuration when it cannot find a file in `/etc`, and it makes it very hard to deduce what exactly can be configured. I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. I favor that software simply refuse to start with a clear warning as to why, when it cannot find a configuration option in it's configuration file. Applying a default on a missing key is another case of weak typing; I would hope that lessons were learned by now that guessing what the user wants in case of error is a bad idea. What is even worse is software that simply ignores malformed keys, and applies a default value anyway, giving rise to not only innocent mistakes by typoes, but some malicious exploits that were found by putting zero-width spaces into keys to trick administrators viā social engineering.
- Jasper_ 6y ago
  I partially agree, but I think a good middleground is for default configuration to be in a place like /usr/share/, and allow for admin configuration to happen in /etc/. This way, if you upgrade, you don't need a complicated merge to merge new defaults + old configuration. I've seen a lot of configuration migrations gone wrong in my life.
  - Blikkentrekker 6y ago
    That would mitigate the problem of easily finding out what options there are, but it would still be a form of weak typing where a best guess is substituted for a mistake. If the system administrator truly intend for a value to be default, he should explicitly declare it so in the configuration file. Interpreting the system administrator's act of forgetting something as his intention for it to be a default value, seems like a bad idea to me. As for merge, I find it as annoying if software not support configuration directories. `foo.conf` should exist alongside `foo.conf.d`, and if the latter exist, it's contents should be parsed as well. On an update, the system can simply install a file in `foo.conf.d` which contains the default of any new keys added from the last version.
- collyw 6y ago
  > I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. Isn't sensible default what make certain software a lot easier to use then others? Apple seems to be good at this. Ten years ago Ubunutu brought this to the Linux world to an extent. Personally I like the configurability of Linux, but I am past the days of spending hours tweaking it and I am quite happy if someone supplies me with sensible defaults. Having said that, as a developer I agree with what you said, it's often easier if a library call gives an error than tries to do something smart / just carries on (JavaScript comes to mind), so there is a balance depending on what the user wants to do with the software.
- higerordermap 6y ago
  Yes. But generally many software allow configuration in home directory. That's least of my problems with Linux.
sally1620 6y ago
Except more often than not packages do their own thing and don't follow the convention. this is even worse if you compile from source.

asveikau 6y ago

/usr/local/etc is a common pattern, though. So maybe I would add that /usr/local is a special case of /usr for locally built* stuff, with sub-nodes imitating the corresponding nodes in /. * Not always locally built, though. *BSDs put binary packages there too.

Blikkentrekker 6y ago

> /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system. I find this goal to be rather frustrating. It means that software will hardcode it's default configuration when it cannot find a file in `/etc`, and it makes it very hard to deduce what exactly can be configured. I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. I favor that software simply refuse to start with a clear warning as to why, when it cannot find a configuration option in it's configuration file. Applying a default on a missing key is another case of weak typing; I would hope that lessons were learned by now that guessing what the user wants in case of error is a bad idea. What is even worse is software that simply ignores malformed keys, and applies a default value anyway, giving rise to not only innocent mistakes by typoes, but some malicious exploits that were found by putting zero-width spaces into keys to trick administrators viā social engineering.

Jasper_ 6y ago
I partially agree, but I think a good middleground is for default configuration to be in a place like /usr/share/, and allow for admin configuration to happen in /etc/. This way, if you upgrade, you don't need a complicated merge to merge new defaults + old configuration. I've seen a lot of configuration migrations gone wrong in my life.
- Blikkentrekker 6y ago
  That would mitigate the problem of easily finding out what options there are, but it would still be a form of weak typing where a best guess is substituted for a mistake. If the system administrator truly intend for a value to be default, he should explicitly declare it so in the configuration file. Interpreting the system administrator's act of forgetting something as his intention for it to be a default value, seems like a bad idea to me. As for merge, I find it as annoying if software not support configuration directories. `foo.conf` should exist alongside `foo.conf.d`, and if the latter exist, it's contents should be parsed as well. On an update, the system can simply install a file in `foo.conf.d` which contains the default of any new keys added from the last version.
collyw 6y ago
> I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason. Isn't sensible default what make certain software a lot easier to use then others? Apple seems to be good at this. Ten years ago Ubunutu brought this to the Linux world to an extent. Personally I like the configurability of Linux, but I am past the days of spending hours tweaking it and I am quite happy if someone supplies me with sensible defaults. Having said that, as a developer I agree with what you said, it's often easier if a library call gives an error than tries to do something smart / just carries on (JavaScript comes to mind), so there is a balance depending on what the user wants to do with the software.
higerordermap 6y ago
Yes. But generally many software allow configuration in home directory. That's least of my problems with Linux.

sally1620 6y ago

Except more often than not packages do their own thing and don't follow the convention. this is even worse if you compile from source.