6 ms·

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, co

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.

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.