8 ms·

One not-so-unrelated thing I really love about linux is that the "configuration" for just about every application is stored in plain-text files, mostly in the u

One not-so-unrelated thing I really love about linux is that the "configuration" for just about every application is stored in plain-text files, mostly in the user's home directory. Which means we can use git to version control them (like many many people do - the dotfiles trend). You can have a log of configuration changes for your system, you can have various profiles with branches, etc. Want to switch to a different profile? Just `git checkout <branch-name>`, done! Want to revert some change, or see how your PC looked like 2 months ago? `git log` and `git checkout` your way through! I currently have all my configurations[1] in a dotfiles directory representing the home directory (same directory structure etc.) and symlinks to them in the actual home directory. Very easy to manage. [1]: https://github.com/awalGarg/dotfiles https://github.com/awalGarg/dotfiles

digi_owl 10y ago
For every person loving those plain texts, there are one that want to see them purged from existence. Observe how Gnome has basically recreated the registry, complete with hidden magic switches...
- lima 10y ago
  Gnome re-created the registry because they needed features that plain text files don't have. I simply have a hook for my dotfile repo which calls "dconf dump / > .dconf". This dumps the entire tree and it's nicely versioned in the repo.
  - willtim 10y ago
    The issue for me is more that they recreated the windows registry with all its flaws. For example, when uninstalling an app, can every entry associated with that app be easily removed?
    - okramcivokram 10y ago
      If app is removed, are all the relevant dotfiles removed?
      - bwat48 10y ago
        Touche
      - willtim 10y ago
        The registry was supposed to improve upon dotfiles. In practice there is often one dotfile to delete versus hundreds of scattered registry entries. If an Android app is removed, the local settings are also completely removed, because they didn't just copy the design of windows.
        lima 10y ago
        > hundreds of scattered registry entries This is unique on Windows. I actually took a look at dconf on my machine and no application occupied more than one key. GEdit sits in /org/gnome/gedit and virt-manager in /org/virt-manager as you'd expect. I also hate Android's behavior, since there are situations where you want to keep them. If I remove GEdit for whatever reason, I expect it to keep my settings. There are legitimate reasons to criticize Gnome, but this isn't one of them. dconf is totally reasonable and has significant advantages over plain text.
  - CaptSpify 10y ago
    Curious what features a plain-text file doesn't have that a registry would?
    - lima 10y ago
      Most importantly, a stable API which can be concurrently used by multiple processes. Getting/setting single values in a plain text config file is cumbersome and error-prone, and even if there's a library which is able to read that particular format, it often clobbers comments and formatting. For systems administration, you usually solve this by generating the entire config file from a template since nothing on the server should change your config files anyway. However, on the desktop, many different application want to read and write keys. Tray applets, the system config panel, even your media player... They would inevitably conflict and you'd have to implement file-based locking. Another topic: real-time notifications. If you modify the text size in the Gnome Control Panel, what happens is that the panel modifies the value in dconf and dconf sends a notification to all running Gnome applications. You could implement this using inotify, but you'd need code in each of your applications to open the config file, parse it and figure out which setting actually changed. Single dconf lookups are really fast since everything is zero-copy and doesn't involve any syscalls. This is much faster than opening, reading and parsing config files. dconf doesn't aim to replace all plain text config files. Storing the i3 or SSH configuration in dconf would be stupid (or even using dconf on a server to begin with).
      - kosma 10y ago
        > However, on the desktop, many different application want to read and write keys. Tray applets, the system config panel, even your media player... If your applications directly read and store configuration keys belonging to other applications, you have way worse problems in your architecture than configuration file format.
        vetinari 10y ago
        Configuration items like current theme or current default font are things, that all applications are interested in. If they want to have look and feel like the rest of the desktop, that is.
  - deleted 10y ago
    [deleted]
- jstimpfle 10y ago
  It's the worst. I've sufferred so much although I never wanted to care about it. I'm a little blurry on the details, but if you want to automize addition of some configuration to the dconf system you have to put your part of the configuration tree in /etc/ and recompile the whole config to a new binary file. I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are obvious. You can't just deploy by copying files. The target system has to be running, and you have to run the right update script in the right sequence. This update sequence is also meant to live-update the configuration of the running system. Of course that wouldn't work reliably. My session dropped its hotkeys (the only thing I actually cared about) on every update.
  - lima 10y ago
    > automize addition of some configuration to the dconf system You mean like "dconf dump" and "dconf load"? I use it for exactly that (importing my hotkeys config). What you describe (compiled files in /etc) are system-global default values. You only need those for multi-user environments. > I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are The performance advantages are massive. The dconf database is just a hashtable which can be directly mmap'ed, so no parsing happens at all. This does matter for settings which are read hundreds of times (your current desktop theme, for example).
    - jstimpfle 10y ago
      > What you describe (compiled files in /etc) are system-global default values. You only need those for multi-user environments. Well, I work as a systems administrator... >> I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are > The performance advantages are massive. The advantages over reading a big unsorted chunk of text, maybe measurable in an isolated benchmark - depending on the size of the text. But it's not a good idea to put everything in one place. With the conventional one-file-per program approach the existing file system (instead of custom binary datastructures) is used to speed up the access. > The dconf database is just a hashtable which can be directly mmap'ed, so no parsing happens at all. As an aside, mmap is not necessarily faster, or may even be slower. It's probably not worth bothering except in extreme cases. What matters is caching. "No parsing happens at all", hardly. A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus? This would mean serialization, deserialization, and lots of context switches. > This does matter for settings which are read hundreds of times (your current desktop theme, for example). Not convinced. If most keys were read many times, something was very wrong. No. Most things are read by exactly one program. The pure act of reading config files is neglibible compared to what other things happen at start-up. A process spawn costs about 1ms. Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file. There simply is no performance gain coming from putting everything on one crap pile. But it has serious practical disadvantages.
- willtim 10y ago
  The Gnome stack is horrible. I long ago started questioning the sanity of the devs when they tried to build an entire office suite in C. Start any Gnome/GTK app and it will continously spew assertion failed log messages at you. Gnome has also forced certain standards, e.g. Network Manager when superior alternatives exist (the excellent Connman).
  - digi_owl 10y ago
    I seem to recall that Connman came to be after Network Manager was established. And frankly i am unsure if it was Gnome or Red Hat that brought it on, but then i find the lines blur between the two (after all, it seems like the most active Gnome devs are on RH payroll).
    - willtim 10y ago
      Connman was developed by Intel, there's absolutely no Gnomeness involved at all. I think you are correct that Network Manager was first, but it took a long time to stabilise and came with far too many dependencies, including X11 and a full Gnome install!
  - tomrod 10y ago
    I'm stuck in GNOME -- any advice on breaking free is appreciated!
    - uabstraction 10y ago
      First, replace the core GNOME apps you use most frequently with lighter alternatives. Take it easy, do it one at a time. Try rxvt-unicode instead of gnome-terminal. Try Thunar or Dolphin or an mc clone instead of Nautilus. There's a lot of non-obvious configuration options in the X11 stack. An .Xresources file can select better fonts, tweak hinting so they look fantastic, and change settings and color themes for many X applications. Out of the box, many X applications look like obsolete garbage, but they can be lightweight, functional, and awesome looking at the same time with a little configuration and love. After getting your core apps sorted, consider an alternate DE/WM. I personally love the gaps fork of i3. XFCE is nice if you still want DE functionality. I personally dual boot Debian Stretch and Gentoo ~amd64 - sharing a home partition. I keep Debian more or less stock on GNOME, while I rice the hell out of Gentoo with i3 and no systemd. Check out https://reddit.com/r/unixporn https://reddit.com/r/unixporn for inspiration and ideas.
- TheCoelacanth 10y ago
  That's XML, right? So still text, just structured text
  - jstimpfle 10y ago
    Pretty much all configuration files are "structured". Only their syntax is tailored specifically towards the needs. And it shows.
robmccoll 10y ago
It's unfortunate that many of the modern components frequently seen in Linux environments do not appreciate/respect/promote the use of plain-text files and scripts. Thinking of systemd and its many utilities, Docker, etc.
- lima 10y ago
  > systemd Isn't systemd's configuration entirely plain text?
  - robmccoll 10y ago
    Some of the configuration is plain text: unit, service, and environment files are plaintext. Which services are enabled and disabled cannot be controlled through file manipulation that I know of. Journal (log files) are binary. I think what bothers me about both is that the presence of text files in a predefined location is not enough to make things happen on its own. Instead of the simplest possible everything-is-a-file and interacting with the filesystem is the interface, you have an additional requirement of calling binaries and their subcommands.
    - juliangoldsmith 10y ago
      IIRC enabling and disabling services in systemd are done via symlinks. You'd have to call a binary to start newly-added services, though. (i.e. systemctl daemon-reload && systemctl start service)
      - lima 10y ago
        > You'd have to call a binary to start newly-added services It reloads its configuration on SIGHUP (same as daemon-reload).
    - edbrown23 10y ago
      Generally systemd manages enabled/disabled services through symlinks in /etc/ (/etc/systemd/system/ on my Fedora 24, for instance), which you can add/delete in the shell if you want to. It's admittedly not plain-text, but manipulation-wise it's about equal.
cgdub 10y ago
You can also go one step further and have the configuration for the entire OS in text files with something like NixOS. https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html Want to see what your PC was really like 2 months ago, including rolling back updates and removing new applications you installed and vice-versa? You can do that. Even if you switched desktop environments.
- mrkgnao 10y ago
  Can you get a Spacemacs setup working on NixOS, with layers and so on? In general, assuming one is willing to write a bit of glue code/NixOS versions of patches/ebuilds/PKGBUILDs, can one get one's configuration from $distro working on NixOS? I use Haskell, so I've been meaning to switch to Nix for a while.
  - cgdub 10y ago
    Spacemacs works fine if you install it normally. Most dotfiles in your home directory will work as usual. I'm not familiar with ebuild or PKGBUILD. You'd probably have to rewrite them as Nix expressions.

digi_owl 10y ago

For every person loving those plain texts, there are one that want to see them purged from existence. Observe how Gnome has basically recreated the registry, complete with hidden magic switches...

lima 10y ago
Gnome re-created the registry because they needed features that plain text files don't have. I simply have a hook for my dotfile repo which calls "dconf dump / > .dconf". This dumps the entire tree and it's nicely versioned in the repo.
- willtim 10y ago
  The issue for me is more that they recreated the windows registry with all its flaws. For example, when uninstalling an app, can every entry associated with that app be easily removed?
  - okramcivokram 10y ago
    If app is removed, are all the relevant dotfiles removed?
    - bwat48 10y ago
      Touche
    - willtim 10y ago
      The registry was supposed to improve upon dotfiles. In practice there is often one dotfile to delete versus hundreds of scattered registry entries. If an Android app is removed, the local settings are also completely removed, because they didn't just copy the design of windows.
      - lima 10y ago
        > hundreds of scattered registry entries This is unique on Windows. I actually took a look at dconf on my machine and no application occupied more than one key. GEdit sits in /org/gnome/gedit and virt-manager in /org/virt-manager as you'd expect. I also hate Android's behavior, since there are situations where you want to keep them. If I remove GEdit for whatever reason, I expect it to keep my settings. There are legitimate reasons to criticize Gnome, but this isn't one of them. dconf is totally reasonable and has significant advantages over plain text.
- CaptSpify 10y ago
  Curious what features a plain-text file doesn't have that a registry would?
  - lima 10y ago
    Most importantly, a stable API which can be concurrently used by multiple processes. Getting/setting single values in a plain text config file is cumbersome and error-prone, and even if there's a library which is able to read that particular format, it often clobbers comments and formatting. For systems administration, you usually solve this by generating the entire config file from a template since nothing on the server should change your config files anyway. However, on the desktop, many different application want to read and write keys. Tray applets, the system config panel, even your media player... They would inevitably conflict and you'd have to implement file-based locking. Another topic: real-time notifications. If you modify the text size in the Gnome Control Panel, what happens is that the panel modifies the value in dconf and dconf sends a notification to all running Gnome applications. You could implement this using inotify, but you'd need code in each of your applications to open the config file, parse it and figure out which setting actually changed. Single dconf lookups are really fast since everything is zero-copy and doesn't involve any syscalls. This is much faster than opening, reading and parsing config files. dconf doesn't aim to replace all plain text config files. Storing the i3 or SSH configuration in dconf would be stupid (or even using dconf on a server to begin with).
    - kosma 10y ago
      > However, on the desktop, many different application want to read and write keys. Tray applets, the system config panel, even your media player... If your applications directly read and store configuration keys belonging to other applications, you have way worse problems in your architecture than configuration file format.
      - vetinari 10y ago
        Configuration items like current theme or current default font are things, that all applications are interested in. If they want to have look and feel like the rest of the desktop, that is.
- deleted 10y ago
  [deleted]
jstimpfle 10y ago
It's the worst. I've sufferred so much although I never wanted to care about it. I'm a little blurry on the details, but if you want to automize addition of some configuration to the dconf system you have to put your part of the configuration tree in /etc/ and recompile the whole config to a new binary file. I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are obvious. You can't just deploy by copying files. The target system has to be running, and you have to run the right update script in the right sequence. This update sequence is also meant to live-update the configuration of the running system. Of course that wouldn't work reliably. My session dropped its hotkeys (the only thing I actually cared about) on every update.
- lima 10y ago
  > automize addition of some configuration to the dconf system You mean like "dconf dump" and "dconf load"? I use it for exactly that (importing my hotkeys config). What you describe (compiled files in /etc) are system-global default values. You only need those for multi-user environments. > I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are The performance advantages are massive. The dconf database is just a hashtable which can be directly mmap'ed, so no parsing happens at all. This does matter for settings which are read hundreds of times (your current desktop theme, for example).
  - jstimpfle 10y ago
    > What you describe (compiled files in /etc) are system-global default values. You only need those for multi-user environments. Well, I work as a systems administrator... >> I doubt anybody can measure the parsing advantage of a binary format, but the drawbacks are > The performance advantages are massive. The advantages over reading a big unsorted chunk of text, maybe measurable in an isolated benchmark - depending on the size of the text. But it's not a good idea to put everything in one place. With the conventional one-file-per program approach the existing file system (instead of custom binary datastructures) is used to speed up the access. > The dconf database is just a hashtable which can be directly mmap'ed, so no parsing happens at all. As an aside, mmap is not necessarily faster, or may even be slower. It's probably not worth bothering except in extreme cases. What matters is caching. "No parsing happens at all", hardly. A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus? This would mean serialization, deserialization, and lots of context switches. > This does matter for settings which are read hundreds of times (your current desktop theme, for example). Not convinced. If most keys were read many times, something was very wrong. No. Most things are read by exactly one program. The pure act of reading config files is neglibible compared to what other things happen at start-up. A process spawn costs about 1ms. Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file. There simply is no performance gain coming from putting everything on one crap pile. But it has serious practical disadvantages.
willtim 10y ago
The Gnome stack is horrible. I long ago started questioning the sanity of the devs when they tried to build an entire office suite in C. Start any Gnome/GTK app and it will continously spew assertion failed log messages at you. Gnome has also forced certain standards, e.g. Network Manager when superior alternatives exist (the excellent Connman).
- digi_owl 10y ago
  I seem to recall that Connman came to be after Network Manager was established. And frankly i am unsure if it was Gnome or Red Hat that brought it on, but then i find the lines blur between the two (after all, it seems like the most active Gnome devs are on RH payroll).
  - willtim 10y ago
    Connman was developed by Intel, there's absolutely no Gnomeness involved at all. I think you are correct that Network Manager was first, but it took a long time to stabilise and came with far too many dependencies, including X11 and a full Gnome install!
- tomrod 10y ago
  I'm stuck in GNOME -- any advice on breaking free is appreciated!
  - uabstraction 10y ago
    First, replace the core GNOME apps you use most frequently with lighter alternatives. Take it easy, do it one at a time. Try rxvt-unicode instead of gnome-terminal. Try Thunar or Dolphin or an mc clone instead of Nautilus. There's a lot of non-obvious configuration options in the X11 stack. An .Xresources file can select better fonts, tweak hinting so they look fantastic, and change settings and color themes for many X applications. Out of the box, many X applications look like obsolete garbage, but they can be lightweight, functional, and awesome looking at the same time with a little configuration and love. After getting your core apps sorted, consider an alternate DE/WM. I personally love the gaps fork of i3. XFCE is nice if you still want DE functionality. I personally dual boot Debian Stretch and Gentoo ~amd64 - sharing a home partition. I keep Debian more or less stock on GNOME, while I rice the hell out of Gentoo with i3 and no systemd. Check out https://reddit.com/r/unixporn https://reddit.com/r/unixporn for inspiration and ideas.
TheCoelacanth 10y ago
That's XML, right? So still text, just structured text
- jstimpfle 10y ago
  Pretty much all configuration files are "structured". Only their syntax is tailored specifically towards the needs. And it shows.

robmccoll 10y ago

It's unfortunate that many of the modern components frequently seen in Linux environments do not appreciate/respect/promote the use of plain-text files and scripts. Thinking of systemd and its many utilities, Docker, etc.

lima 10y ago
> systemd Isn't systemd's configuration entirely plain text?
- robmccoll 10y ago
  Some of the configuration is plain text: unit, service, and environment files are plaintext. Which services are enabled and disabled cannot be controlled through file manipulation that I know of. Journal (log files) are binary. I think what bothers me about both is that the presence of text files in a predefined location is not enough to make things happen on its own. Instead of the simplest possible everything-is-a-file and interacting with the filesystem is the interface, you have an additional requirement of calling binaries and their subcommands.
  - juliangoldsmith 10y ago
    IIRC enabling and disabling services in systemd are done via symlinks. You'd have to call a binary to start newly-added services, though. (i.e. systemctl daemon-reload && systemctl start service)
    - lima 10y ago
      > You'd have to call a binary to start newly-added services It reloads its configuration on SIGHUP (same as daemon-reload).
  - edbrown23 10y ago
    Generally systemd manages enabled/disabled services through symlinks in /etc/ (/etc/systemd/system/ on my Fedora 24, for instance), which you can add/delete in the shell if you want to. It's admittedly not plain-text, but manipulation-wise it's about equal.

cgdub 10y ago

You can also go one step further and have the configuration for the entire OS in text files with something like NixOS. https://nixos.org/nixos/about.html https://nixos.org/nixos/about.html Want to see what your PC was really like 2 months ago, including rolling back updates and removing new applications you installed and vice-versa? You can do that. Even if you switched desktop environments.

mrkgnao 10y ago
Can you get a Spacemacs setup working on NixOS, with layers and so on? In general, assuming one is willing to write a bit of glue code/NixOS versions of patches/ebuilds/PKGBUILDs, can one get one's configuration from $distro working on NixOS? I use Haskell, so I've been meaning to switch to Nix for a while.
- cgdub 10y ago
  Spacemacs works fine if you install it normally. Most dotfiles in your home directory will work as usual. I'm not familiar with ebuild or PKGBUILD. You'd probably have to rewrite them as Nix expressions.