The reactions to systemd-homed have predictably been, "soon there's going to be a word processor in ", without these people realizing that:

1.) systemd is NOT a single binary, it's a project, an ecosystem of utilities. That's like saying to GNU; Why is there wget? I want GNU to compile stuff with GCC, why is GNU nano a thing?

Of course the goal of the GNU Project is to produce everything needed to have a libre OS - the goal of systemd is to produce everything needed to manage this OS.

systemd is not an init system, it's a system manager designed to be useful way beyond simply bringing the system up.

2.) Linux home directory handling is currently a mess. Any random app can ignore XDG conventions, making it hard to be sure that a simple rsync of home is sufficient i.e. it would be working as expected if you were forced to nuke your system. From my experience, it doesn't work particularly well for backing up the configs of many programs as they write to places like /etc

Show thread

@MatejLach not sure how systemd-homed could fix that though… Yet another new standard isn't going to unify anything unless apps can somehow be forced to use it.

Follow

@isagalaev Am not entirely sure myself, but I'd hope for a mechanism similar to systemd --user where perhaps the distro packager of a particular app can write a .homed file for it that could force it to redirect assets to XDG compliant places & the app would effectively assume it's still writing to the original place, that is it's totally transparent to the app. That way any random Electron app could also be made to use it, even if the dev doesn't care.

@MatejLach yeah, I also started thinking first about sandboxing apps in the similar way Docker does (and it uses kernel services for that anyway).

Sign in to participate in the conversation
Matej Lach's mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!