3 ms·

> Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are

> Updating a value in a text file means re-writing the whole file again. It is a technically-inferior approach that has survived in time because text files are still text files. It always seems like registries are trying to solve three different problems: configuration, status and process shared state. Registries seem to work poorly compared to text files for configuration, and work somewhat well for some level of shared state. I think to compare functionality with Linux, you would have to compare /etc, .configs and the /proc filesystem. As for tecnically inferior, the *ix approach seems to have made the right tradeoffs, via the hand of Darwin, rather than some brilliant engineering insight. The article did a good job of explaining what's wrong with Windows' implementation of the registry. What is right with the *ix approach is that configuration files are usually read on startup, and only written to when configuration is changed (which should be infrequent). This works really well for server software, command line utilities, and an awful lot of GUI software. For some GUI software, particularly where you have really complex feature sets, we need to save state of widgets (i.e. saving the default zoom level) and text files may be problematic for this (i.e two instances of the app running), and this is where the registry really shines.

mikepurvis 4y ago
The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.
- ElectricalUnion 4y ago
  Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}
  - dklodh 4y ago
    Most don't even know of XDG. The reason is, there's no central documentation or route for the userland. By Linux, we understand, the kernel and to the kernel developers, that is true. So let alone the anarchy of the userland be handled by distributions and users.
    - account42 4y ago
      https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... freedesktop.org is that central documentation. Sure, there are applications that don't implemente that spec but it is not for there not being any documentation but either because the maintainers of those applications don't care or because the applications are older than the spec and moving configuration is not always trivial.
  - tomcam 4y ago
    I don't mind dot files or dot folders, but I'm very open to better ideas. My app works on Mac, Linux, and Windows though. Any thoughts?
    - ElectricalUnion 4y ago
      There are several libraries that handle directory for you in the appropriate OS-specific manner. One Rust example being https://github.com/dirs-dev/dirs-rs https://github.com/dirs-dev/dirs-rs > The library provides the location of these directories by leveraging the mechanisms defined by > the XDG base directory and the XDG user directory specifications on Linux and Redox > the Known Folder API on Windows > the Standard Directories guidelines on macOS
- cycomanic 4y ago
  > The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var. What do you mean? You are mixing multiple things, most of var and lib are also only root writable (unless tied to a specific user). For GUI application you generally end up with a system where etc holds the system defaults and user configuration is in $XDG_USER_CONFIG which defaults to $HOME/.config. This is the case for the vast majority (>90%) of GUI applications. If we're are talking state, that typically ends up $HOME/.cache (if it should be temporary) or $HOME/.local/var (if it should be persistent). There are also XDG variables for these but I forgot them at the moment. So can you elaborate what you mean with your perceived problem?
- 5e92cb50239222b 4y ago
  It's a great thing about etc. If your application `foobar` wants to write something to /etc and doesn't have root privileges (which it probably shouldn't), create a subdirectory /etc/foobar with owner `foobar:foober`, and write there all you want. Many applications do that and it works fine.
  - throw0101a 4y ago
    Strictly speaking /etc should be relatively static, and dynamic data should go into /var, so you (or the package installation) would create /var/lib/foobar with proper ownership.
    - ElectricalUnion 4y ago
      > Strictly speaking /etc should be relatively static I really wish that was true but nasty stuff like wpa_supplicant/, resolv.conf (now usually a systemd-resolved managed symlink), NetworkManager/ and X11/ lives there, very mutable and often constantly changing under the hood.
  - vimsee 4y ago
    I have not seen any applications creating a user with the applications name. How can one avoid a naming conflict? Kate (a text editor) might be installed on a system by Kate (a person). What I have noticed however is that there are daemons running as root and is used as a "middle man" whenever an application running as a normal user needs some extra privilege.
    - pmontra 4y ago
      Desktop applications no, because they must run as the user (let's leave containers and sandboxes alone.) Servers yes, for example PostgreSQL creates the postgres user and runs as such.

mikepurvis 4y ago

The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var.

ElectricalUnion 4y ago
Most Linux GUI apps either litter your home folder with dotfiles, dotfolders (both disgusting) or they follow XDG Base Directory specifications and place configurations in ${XDG_CONFIG_HOME:-${HOME}/.config}
- dklodh 4y ago
  Most don't even know of XDG. The reason is, there's no central documentation or route for the userland. By Linux, we understand, the kernel and to the kernel developers, that is true. So let alone the anarchy of the userland be handled by distributions and users.
  - account42 4y ago
    https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... freedesktop.org is that central documentation. Sure, there are applications that don't implemente that spec but it is not for there not being any documentation but either because the maintainers of those applications don't care or because the applications are older than the spec and moving configuration is not always trivial.
- tomcam 4y ago
  I don't mind dot files or dot folders, but I'm very open to better ideas. My app works on Mac, Linux, and Windows though. Any thoughts?
  - ElectricalUnion 4y ago
    There are several libraries that handle directory for you in the appropriate OS-specific manner. One Rust example being https://github.com/dirs-dev/dirs-rs https://github.com/dirs-dev/dirs-rs > The library provides the location of these directories by leveraging the mechanisms defined by > the XDG base directory and the XDG user directory specifications on Linux and Redox > the Known Folder API on Windows > the Standard Directories guidelines on macOS
cycomanic 4y ago
> The biggest issue with etc is that it's owned by root and therefore read only from the application's point of view. So, a great fit for sysadmin-managed configuration, not so great for applications that are GUI-configurable. You end up with a tiered approach of defaults in lib, and cascaded overrides in etc and var. What do you mean? You are mixing multiple things, most of var and lib are also only root writable (unless tied to a specific user). For GUI application you generally end up with a system where etc holds the system defaults and user configuration is in $XDG_USER_CONFIG which defaults to $HOME/.config. This is the case for the vast majority (>90%) of GUI applications. If we're are talking state, that typically ends up $HOME/.cache (if it should be temporary) or $HOME/.local/var (if it should be persistent). There are also XDG variables for these but I forgot them at the moment. So can you elaborate what you mean with your perceived problem?
5e92cb50239222b 4y ago
It's a great thing about etc. If your application `foobar` wants to write something to /etc and doesn't have root privileges (which it probably shouldn't), create a subdirectory /etc/foobar with owner `foobar:foober`, and write there all you want. Many applications do that and it works fine.
- throw0101a 4y ago
  Strictly speaking /etc should be relatively static, and dynamic data should go into /var, so you (or the package installation) would create /var/lib/foobar with proper ownership.
  - ElectricalUnion 4y ago
    > Strictly speaking /etc should be relatively static I really wish that was true but nasty stuff like wpa_supplicant/, resolv.conf (now usually a systemd-resolved managed symlink), NetworkManager/ and X11/ lives there, very mutable and often constantly changing under the hood.
- vimsee 4y ago
  I have not seen any applications creating a user with the applications name. How can one avoid a naming conflict? Kate (a text editor) might be installed on a system by Kate (a person). What I have noticed however is that there are daemons running as root and is used as a "middle man" whenever an application running as a normal user needs some extra privilege.
  - pmontra 4y ago
    Desktop applications no, because they must run as the user (let's leave containers and sandboxes alone.) Servers yes, for example PostgreSQL creates the postgres user and runs as such.