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.
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
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.
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.
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...
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).
Hah, I tried using Connman for a while instead of NM, and I cannot vouch for its superiority.
It's been over a year since I've switched away (to gasp systemd-networkd with vanilla wpa_supplicant), so I can't recall the exact reasons, but I think it was because of lack of doc, terrible debugability, and bad behavior when dealing with multiple known wifi networks.
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).
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!
What's wrong with Network Manager? Show me any other network manager which handles split DNS, WWAN modems and automatically connecting VPNs out of the box with zero configuration.
It's slow to connect, uses a lot of resources and cannot be installed without bringing in hundreds of megabytes of dependencies (e.g. X11, Gnome libs).
It connects to my home wifi in <1s. How long for you?
> uses a lot of resources
10 MiB and 9 minutes of CPU time after an uptime of 4 days with many reconnects, which is totally reasonable.
> cannot be installed without bringing in hundreds of megabytes of dependencies
Not true. Even on Ubuntu, it only pulls in 17.4 MB of dependencies:
apt-get install --no-install-recommends network-manager
The following additional packages will be installed:
dconf-gsettings-backend dconf-service glib-networking glib-networking-common glib-networking-services gsettings-desktop-schemas libbluetooth3 libdconf1
libgudev-1.0-0 libmm-glib0 libndp0 libnl-3-200 libnl-genl-3-200 libnm0 libproxy1v5 libsoup2.4-1 wpasupplicant
[...]
After this operation, 17.4 MB of additional disk space will be used.
Do you want to continue? [Y/n]
On RPM based distros, it's even less. They made it the default network manager on RHEL 7, even for the minimal cloud images.
Try installing it on Ubuntu headless server, then it will bring in hundreds of megabytes. You obviously already had most of the dependencies installed.
Intel developed Connman because NetworkManagers shortcomings make it unsuitable for embedded devices.
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.
All you need to do is install XFCE. It has a great terminal, a solid file manager, a compositing WM, and easy configuration. I don't bother setting things up piecemeal or fiddling with .Xresources any more.
Also, it would be great if we could stop using "rice" as an adjective. Even if you don't find it offensive, some people do.
Contrary to some other advice here, I switched to a new window manager first (xmonad, FWIW), but kept running a bunch of GNOME stuff too. Gradually, I have phased out most of GNOME and my computing life is simpler and more stable as a result.
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.
> 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).
> 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.
So do I. You only need that feature if you want to, say, set a default wallpaper for new users or prevent them from changing, and I don't see any issues with they way it's implemented. It's a plain text config which can be deployed using your favorite config management system. You'd just put in a change hook like you'd restart a service after changing its config file.
> 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 way it works is that dconf client mmap the database file, so it's the same. dbus does no caching by itself, it uses the same mechanism.
> A hash table just leads to the information. You still have to interpret it. And I assume dconf can only be queried over dbus?
No, dbus is only used for writing. Reading is directly from the filesystem without anything in-between. The serialization format used by dconf matches the in-memory structure, so the application can literally take the value from (mmap) memory and use it as-is. So, no parsing.
I agree with you that it would be less efficient if dbus were used in the read path, this is probably why it's implemented that way.
> Not convinced. If most keys were read many times, something was very wrong.
> No. Most things are read by exactly one program.
> Loading the program code itself is a hell of a lot more expensive than loading a tiny text configuration file
The primary use case for dconf are desktop settings and yes, those are read hundreds of time. Not only at startup, but also at runtime. The current GTK theme or scaling factor is read all the time during rendering.
I'm not advocating that all application config should end up in dconf - as I noted, I like my i3, GPG or SSH config the way they are.
For me, it has lots of practical advantages. For example, I have a script which sets all desktop settings the way I like them (font, scaling factor, focus follows mouse,...) and I can just set them using "gsettings set org.gnome.desktop.interface.scaling-factor 2" instead of figuring out which configs are in which files, how to parse them and merge existing and new configs.
> You'd just put in a change hook like you'd restart a service after changing its config file.
It's not the same. While servers restart on reboot, the config file is not automatically compiled. Also if you don't reboot, most servers are restarted through a uniform interface. Dconf makes an exception without need. You need the dconf infrastructure at deploy time (it might be an installation), and you need to know how to use it.
I've wasted hours figuring out how the configuration is to be used. In the end I still had terrible bugs. I'm glad other programs just do the parsing for me. It works, there never was a problem to begin with.
> The current GTK theme or scaling factor is read all the time during rendering.
I think you are missing the possibility of parsing a configuration once at startup and storing the result in memory in suitable datastructures. It's not like conventional programs would parse the configuration over and over. Fixed binary layouts are very bad for interoperation.
Btw, there is no memory usage problem compared to an mmap solution if every program just parses the _relevant_ information. And it also doesn't preclude a live-update mechanism -- this just has to be done with care. Not every information is trivially live-updatable, as illustrated by the breakage I mentioned.
> I can just set them using "gsettings set org.gnome.desktop.interface.scaling-factor 2"
This can be also done with text configuration files. Some programs do it. Most do it not (including dconf, which doesn't update your original input file) because the tradeoffs are bad. It has nothing to do with the question whether or not the serialization format is text.
Text vs binary is just this question: Do I need absolute performance or absolute discoverability? In the case of configuration files, the answer is clear.
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).
> Getting/setting single values in a plain text config file is cumbersome and error-prone
What? The INI format is very simple and there are numerous libraries that handle it cleanly in any language.
> and even if there's a library which is able to read that particular format, it often clobbers comments and formatting.
What? These are primarily machine-readable configuration files. Why is formatting relevant? And how are comments relevant to dconf, since it uses a binary format anyway?
If a plain-text file isn't good enough, at least have the decency to use SQLite.
> 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.
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.
That opens another can of worms: What is system control panel: is that gnome control center? Or command line dconf tools? Or is that dconf-editor? Or one of the myriad tweak utilities?
Cut off one of these and brace for the whining, that gnome is dumbing everything down and locking up your settings.
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?
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.
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.
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.
Can you please explain what you mean with respect to Docker? I've been using it (and the other software in its ecosystem) for three years and have never run into files and scripts that were not plaintext. Even image layers are just tarballs of files and metadata.
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.
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.
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)
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