Modetc: Move your dotfiles from kernel space

https://maxwell.eurofusion.eu/git/rnhmjoj/modetc

Comments

tengwar2Jan 24, 2026, 11:36 AM
One of the annoyances of Linux is working out where configuration information is, following through multiple layers of indirection and files over-riding other files. This looks like adding another layer, another place to look, and if you're reading the man file for a shell (for example) it probably won't even mention that this could invalidate the information contained in that in the man file.
mariusorJan 24, 2026, 12:49 PM
> working out where configuration information is

Generally, good behaved applications have an entry in their man page that spells out these details for you, so you don't have to work out anything.

user3939382Jan 24, 2026, 1:19 PM
Unfortunately so many packages these days don’t even have a man page at all let alone one with good config info.
mariusorJan 24, 2026, 1:26 PM
Well ... hopefully they're open source and all that.
ktm5jJan 24, 2026, 2:03 PM
You're not wrong. In a worst case scenario I resort to using strace to figure out where a program is reading config from.. from what I understand, if this kernel module is in use then even that approach wouldn't help.

But since the use case is personal dotfiles, I imagine the user isn't going to forget that they set this up.

brianjloganJan 24, 2026, 3:00 PM
To be fair the author shows an example of using NixOS. It's absolutely another layer of indirection (probably several) but it does make that usual Linux "fun" less problematic because of its immutable nature and API design.
rnhmjojJan 24, 2026, 6:27 PM
> this could invalidate the information contained in that in the man file.

No, it doesn't. The point of modetc is precisely keep both myself and the programs happy: the files are actually stored where I like to keep them, but they can be accessed as if they were stored where the developer intended.

skobesJan 24, 2026, 12:26 PM
Tomorrow: modify man pages from kernel space!
deafpolygonJan 24, 2026, 12:23 PM
Always check the man pages..
tengwar2Jan 24, 2026, 6:39 PM
And I said that the man pages would be a part of what you have to examine. 95 pages in the case of bash (that's after running it through troff). man pages were fine when they were three pages long, but their lack of any internal index has become a problem.

Ok, now you might have a dozen files which could contain the information, where the location of each file can be modified by environment variables. It's tolerable if you are working on something you change weekly, but a practical problem if you do it yearly or it's entirely new.

BenjiWiebeJan 24, 2026, 8:35 PM
'man bash'. Type G. Press PgUp until you see the FILES heading (took one press for my terminal size). There's your list of files. Alternatively, instead of G and PgUp, type /FILES<Enter>.

Of course, this doesn't help at all when software either doesn't have manpages, or doesn't include the list of files in the manpage. Just nitpicking your bash example.

tengwar2Jan 24, 2026, 9:17 PM
This is HN, not Reddit. You can safely assume that every single person here knows how to use man, particularly if they mention using troff to format it properly. There remains a problem.
BenjiWiebeJan 25, 2026, 4:51 PM
I truly wasn't sure if they were aware of man's search and go to options, as they brought up 95 pages as being why it was hard to find configuration file locations for bash.

When I'm searching for configuration file location, I do use '/FILES' or PgUp from the bottom of the manpage, so the length of the manpages is irrelevant.

pimlottcJan 24, 2026, 2:19 PM
I didn’t understand what this was from the title. Perhaps a better description would be “mod_rewrite for your homedir”
roryirvineJan 25, 2026, 10:29 AM
That sparked a memory of rewritefs, which I used when rationalising a few hundred thousand legacy mod_rewrite rules at a web hosting company in the early 2010s: https://github.com/sloonz/rewritefs

Looks like it was based on a mid-2000s system called libetc, which did a similar job but had to be LD_PRELOADed: https://ordiluc.net/fs/libetc/

yokoprimeJan 24, 2026, 10:57 AM
I struggle to see a valid usecase for this that isn’t handled by symlinks.
rnhmjojJan 24, 2026, 3:27 PM
Hi, author here: whether it's a valid use case depends on your level of OCD, but the difference compared to symlinks or bind mounts is that you will have a clean home: e.g. `ls -la` won't show any "hidden" files.

Also, completely unrelated to my motivation, someone pointed out that modetc could be used to quickly hotfix packages built with Nix. Say that you need to fix a CVE in openssl, normally that would require to rebuild all dependent packages, which takes a long time. Instead with something like modetc you could build just openssl and rewrite /nix/store/<hash>-openssl-3.6.0/ -> /nix/store/<hash>-openssl-3.6.0-hotfix/.

Another application might be replacing some configuration file with placeholders for secrets, with one file with the secrets substituted in, without having to modify it in place, possibly only for a specific UID. This is something you might find useful on NixOS.

regularfryJan 24, 2026, 11:10 AM
If I symlink ~/.ssh -> ~/.config/ssh, I still have .ssh in my ~. Whereas if I rewrite it, I don't.
hvenevJan 24, 2026, 11:16 AM
Will you not have `~/.ssh`? If you have `.ssh .config/ssh` as a rewrite rule, `stat ~/.ssh` will still find it.
txtsdJan 24, 2026, 11:21 AM
The point is to have a clean home directory.
jl6Jan 24, 2026, 12:03 PM
Abandon hope.

I just treat ~ as a system-owned configuration area, and put my actual files (documents, photos, etc.) in a completely different hierarchy under /.

SAI_PeregrinusJan 24, 2026, 6:57 PM
"/home/${USER}" for whatever junk programs are going to stick there, "/home/${USER}/home" for my "real" home directory.
oftenwrongJan 24, 2026, 3:19 PM
I have been doing this for decades. My files are in a sub-directory of $HOME. It also makes it very obvious when a piece of software does not treat your $HOME with respect.
trollbridgeJan 24, 2026, 1:49 PM
You could write a kernel module, then, that just hides certain symlinks from you (which is effectively what this module is).
ComputerGuruJan 24, 2026, 4:46 PM
On Windows this was always easier because, for some reason, most everyone respected %appdata% compared to XDG_CONFIG_HOME, but also because hidden files wasn’t just a naming convention but an actual separate metadata flag.
SardtokJan 24, 2026, 6:16 PM
Always... Except for the decades before this became common. Never a bloated C: root directory. Microsoft even had games store stuff in My Documents\Games at one point. My Documents was a user dir that saw a lot of abuse over the years.
SAI_PeregrinusJan 24, 2026, 7:05 PM
They still have that, it's just `My Documents\My Games` now. And Visual Studio makes a folder in My Documents for every annual release. And…
ComputerGuruJan 25, 2026, 3:33 AM
Yes, as in there’s no reason Linux can’t clean up its game the same way.
Joker_vDJan 24, 2026, 5:32 PM
That ship has sailed 30 years ago.
user3939382Jan 24, 2026, 1:21 PM
The use case is that you can actually use your home directory without either (a) hiding files or (b) wading through 40 config files and dirs that XDG ignorant devs put there.
amusingimpala75Jan 24, 2026, 4:55 PM
From the example:

  # XDG "compliant" programs
  .config/ etc/
  .local/state/ var/lib/
  .cache/ var/cache/
This is the first I’ve heard of using ~/etc instead of ~/.config as $XDG_CONFIG_DIR. Is there any precedent for that?
rnhmjojJan 24, 2026, 5:14 PM
Well, it's just the natural extension of the FHS convention to the home directory.

I didn't come up with this idea, though, I think I saw this in a reddit thread and started doing it myself: I like that the directories are visible and follow the usual structure.

godelskiJan 24, 2026, 5:54 PM
Why not push it under a hidden directory? Like ~/.local/etc? If we're reconstructing some of the hierarchy I think it makes sense to group and hide. Isn't the problem that the home folder is getting cluttered?
rnhmjojJan 24, 2026, 6:20 PM
Why would I hide them? They're not really special and since I'm organising them with modetc they're not cluttered. For reference, my home looks something like this

    ~
    ├── bin         binaries and scripts
    ├── etc         configuration files
    ├── var
    │   ├── lib     program data
    │   └── cache   program caches
    ├── src         git repositories
    ├── img         pictures
    ├── mail        email in maildir format
    ├── note        text notes, todo
    ├── doc         documents
    └── down        downloads
godelskiJan 25, 2026, 5:55 AM
I mean we hide in the first place because configs and we don't want to clutter

But more I was thinking that having ~/bin ~/etc ~/src and so on is just clutter. I use ~/.local/{bin,build,lib} so it's compact and reduces clutter in my home

dividedbyzeroJan 24, 2026, 6:03 PM
But why would I want those directories visible in my home dir?
rustyminnowJan 24, 2026, 6:54 PM
Why would I want them hidden? I access files in ~/.config almost daily, I think this is a really good idea
ycombinatrixJan 24, 2026, 10:49 PM
NixOS solves the same problem without having to mess with the kernel
simonkagedalJan 24, 2026, 5:03 PM
The limit of 16 rules is interesting. Where does that come from?
Joker_vDJan 24, 2026, 5:34 PM
Every time I see yet another dotfile-management solution I just can't help but wonder: maybe it's the dotfiles that are the problem?
erlkonigJan 25, 2026, 2:54 AM
XDG doesn't handle complex environments, especially not heterogeneous computing environments. Something long the core strength of Unix is acknowledged by XDG and then left utterly unaddressed. Without this, the "standard" is as much an impediment as an aid.

It's amusing that modetc goes through all this effort to twist dotfiles into the XDG half-solution, and here I am using symlinks through /dev/shm/xdg/* to warp XDG into sort-of working in an actual heterogeneous environment.

Because XDG by itself is a failure beyond trivial cases.

user3939382Jan 24, 2026, 1:18 PM
I absolutely love this and have wanted to take the time to build this for years precisely because of dotfiles. Thank you!