Situation
I’m using Linux Mint, and am syncing my profile between two machines, using unison-gtk. Those machines have some key differences. One of them being that it’s a laptop, that should go to standby after 15 minutes, while the other one is a desktop that should never go to sleep. (Which is worsened right now, as there’s a bug that prevents it from waking up correctly.)
Now this would all be fine, as I can just not sync those settings, and keep them different. But as usual, things that haven’t understood Unix, keep breaking everything.
Problem
Namely, as far as I know, dconf has only one database per user profile (.config/dconf/user
), which is not only not a directory, but not even a text file. It is an opaque binary file. Bad Gnome!
Goal / Question
Most likely solution
I know that Windows, from which this concept was copied, at least delivered the functionality with it, that allowed local registry settings that would not be synced.
So my question: Is there something similar for Gnome (or, in my case, more precisely: Cinnamon)? Like, say, a .local/dconf/user.local
, and a way to tell it to keep a certain setting local?
Because I do want to avoid the route of
dconf dump > user.ini
patch user.ini < laptop.patch
dconf load < user.ini
Ideal world solution
Even better would of course be, if my .config/dconf/user
was some kind of “virtual file” (say some dconfinidirfs
FUSE implementation but for a single file) that would just be a directory tree of small ini files on the backend, in the vein of /etc/someconfig.d/
directories standing in for /etc/someconfig
files, allowing me to just softlink some parts out to another tree of local settings, like normal.
Other solutions
I’m completely open to out of the box solutions without unison or using a local server, a different desktop environment, or even a different distribution, etc. But being able to interactively merge things is essential. “Automagic” merging always ends in data loss, as there are situations that are undecidable without user input or manual merging. Also both profiles may be used at the same time. In the future, even three or four instances (phone, remote host on a server). So a centralised server that always wins does not help. git
’s decentralised approach is a better fit, for example.