Systemd-Homed: Systemd Now Working to Improve Home Directory Handling

Systemd has its own cron type implementation called timers and I'm sure it logically would work user jobs in at times the user is logged in, in the same way cron works around the fact that the user is sometimes suspended or off for indeterminate time frames.

In most cases it wont even have to. Most users machines have a lifecycle like this

POST 15 seconds Optional FDE passphrase entry 10 seconds Starting up 30 seconds to 2 minutes User login 10 seconds Operation some duration for hours to weeks Shutdown

The encrypted and or logged out state are transitory states on the way to the machines single owner entering credentials to access the device and the machine is only in those states 0.001% of its lifecycle.

For people worried about substantial secrets as opposed to a thief stealing their personal data it may be wise to segregate THAT data on a separate encrypted volume that is only unlocked during use so that opening up your machine to watch cat videos on Youtube doesn't expose thousands of patient records or company secrets.

Cron is only incompatible with homedir encryption if your scheme relies on time sensitive things which effect things OFF your computer happening ON your machine which is powered on frequently enough but not logged in as you sufficiently to complete the tasks it must also require data on your home dir to complete.

I say it has to be factors that effect off computer items because otherwise the task can simply be done as soon as you log in.

I say it must require data on your home dir to complete else your system can be told to do it for you.

For the small number of cases where one might imagine a shared computer might be turned on enough but logged in as other users one can imagine ignoring homedir encyption and simply using FDE with multiple passphrases for individual users. This will necessarily be less secure as all users would be constrained by permissions by able to break into other users local data. At this point we have identified the use case that is actually incompatible.

Shared computers with privileged local data with mutually untrustworthy users on which users need to regularly run tasks which require access to user data regardless of who is logged in.

The logical solution to which is a server, segregation to be provided by different virtual machines if needed.

I mean, no one likes the current situation but it was deemed an acceptable trade off considering there is a work around.

(In particular, will the error be logged if the program fails to start due to bad config file? And how do I describe “only start once “volume X” is mounted?j)

I think people either should try to maintain their own distro, be a maintainer for their distro of choice or stop complaining about the decisions maintainers from their distro take for them.

I mean, at least in Arch systemd seemed to be the obvious choice: it reduced the complexity for the maintainers. Arch used to be a combination of multiple shells scripts maintained by Arch package maintainers. Since systemd they can use the .service file that multiple programs already have upstream, or they can write themselves one that is much easier and less error prone than the shell script approach used before.

I am sure that the maintainers from Debian, Ubuntu, Fedora, OpenSUSE, Madriva, etc. all analyzed the advantages/disadvantages of migrating to systemd vs. maintaining their in-house solution (that they all had before, one way or another). If you still discord from them, why are you using one specific distro? You can pick any other one that is not using systemd, like Devuan, Void Linux, Alpine, etc.

Sounds like your beef is with a specific distro, not systemd in general.

I see this opinion quite often and I think it's based far too much on "ancient wisdom" and not actually grounded in reality.

Because in practice, the fragmentation has meant that people creating/selling cross-platform desktop apps take one look at linux and think: "Yeah, this isn't worth it".

It means a poorer user experience for Linux novices (and even advanced users), because documentation doesn't always match what's on their desktop. They're missing binaries. Arguments are different. Things are implemented differently not even for the sake of being different, but simply because there was no opportunity to reuse the work, so none was reused (and now backwards-compatibility is in the way of changing that).

It also means that there's a ridiculous amount of duplicated work between all the distributions. That duplicated work takes a toll on all distributions, which run on limited, usually-volunteer manpower.

Those distributions with less manpower, the ones that will actually try new things rather than do something slightly-different, are the ones that are more likely to die. The fragmentation between things that are essentially-the-same creates a higher effort barrier to creating actual new things.

systemd is slowly fixing all of this, and thank fuck.

I definitely think it is ridiculous though, that I couldn't use something seemingly fundamental like an init script across distros.

I get that that's the problem of the automation, not the daemon, but I'm curious about who exactly is representing users when the people running a project state things like that so unequivocally, and if those users are just excluded from any benefits from a system like this because fuck 'em.