Reinventing Home Directories – systemd-homed [pdf](cfp.all-systems-go.io)
cfp.all-systems-go.io
Reinventing Home Directories – systemd-homed [pdf]
https://cfp.all-systems-go.io/media/homed-asg2019.pdf
13 comments
Gentoo. We avoid these issues, you pick what ever init system you want. If it's not in the tree, add it to your overlay.
> What would it take to make this stop?
Probably, vote with your time and focus. Use better distributions and port software to those distributions.
Probably, vote with your time and focus. Use better distributions and port software to those distributions.
> What would it take to make this stop?
That's a great question, and I have no answers.
I'm personally still trying to decide between moving all of my machines to Slackware or moving away from Linux entirely and to BSD. I'm currently leaning toward the latter.
That's a great question, and I have no answers.
I'm personally still trying to decide between moving all of my machines to Slackware or moving away from Linux entirely and to BSD. I'm currently leaning toward the latter.
Some of Lennart's inventions that he presents at conferences seem to lose momentum soon after. A while ago he talked about casync and mkosi. Both of these seemed more interesting to me than this but progress seem slow or stalled. We will see what becomes of this, but I don't think it is a slam dunk and what everyone has always needed but never realized. I think by ruling out remote /server use cases he will limit the interest in it.
What is with this fetish of putting everything in systemd?
Soon it'll have an X-server and a word processor built in...
Soon it'll have an X-server and a word processor built in...
talk / context: https://streaming.media.ccc.de/asg2019/relive/164
edit: I think the most important part of the talk was an answer to question about why .ssh/authorized_keys won't be possible with this scheme (42:00):
> this is about protecting your data from the system as much as possible, so that when you are not logged in it's really cut off
This looks like, among other things, an ecryptfs replacement.
edit: I think the most important part of the talk was an answer to question about why .ssh/authorized_keys won't be possible with this scheme (42:00):
> this is about protecting your data from the system as much as possible, so that when you are not logged in it's really cut off
This looks like, among other things, an ecryptfs replacement.
I'm going to pass on this one. How is /etc not 'extensible'? You just add a new file to the directory. Reinventing the windows registry, but this time in JSON, is a lateral move that is only going to complicate maintaining systems.
For user level configuration, you already have too many competing mechanisms for doing this already, and this one requires systemd level integration making it much more coupled to the operating system and system in general.
For user level configuration, you already have too many competing mechanisms for doing this already, and this one requires systemd level integration making it much more coupled to the operating system and system in general.
> I'm going to pass on this one. How is /etc not 'extensible'?
Without commenting on systemd-homed, since I haven't watched the talk yet; regular users can't modify /etc. Granted, most applications have user local configuration or a command line option to specify a config file, but not all. That said, I suppose you could always user namespace overlay mount a custom directory over /etc to add custom files to it.
Without commenting on systemd-homed, since I haven't watched the talk yet; regular users can't modify /etc. Granted, most applications have user local configuration or a command line option to specify a config file, but not all. That said, I suppose you could always user namespace overlay mount a custom directory over /etc to add custom files to it.
The common pattern is to have some system wide file in /etc or /usr/share that is used by default, and allowing the user to override this with a dot-file in their home directory or passing in a config file as a optional argument.
What is being proposed obliterates most of the workflows that people are use to: editing configuration files in the editor of the user's choice and then having the option of using normal backup or using source code repository tools to maintain and version them. Instead, we have the same windows registry mechanism, with some modern flourishes, that most people have ridiculed Microsoft for decades over.
As a user, I can 'strace -e open' and see what locations my program is trying to open. This is very helpful for what configuration data is being read. Everything is a file, and every file operation is a syscall. As a developer, JSON isn't appropriate for every kind of application.
What is being proposed obliterates most of the workflows that people are use to: editing configuration files in the editor of the user's choice and then having the option of using normal backup or using source code repository tools to maintain and version them. Instead, we have the same windows registry mechanism, with some modern flourishes, that most people have ridiculed Microsoft for decades over.
As a user, I can 'strace -e open' and see what locations my program is trying to open. This is very helpful for what configuration data is being read. Everything is a file, and every file operation is a syscall. As a developer, JSON isn't appropriate for every kind of application.
Actually I'd really like a good user config system. dconf already works pretty well for GUI-environment related things. The problem with the win registry is it isn't all tied up and schema'd. So deleting an app doesn't delete its registry entries (at least for traditional win32 apps).
For /etc I'm not so sure, I've really come round to .ini style files.
I just hope the LDAP integration of this works well. I have a feeling that Poettering won't give a shit if it doesn't work with Active Directory...
And more PKCS#11 support would be great, I love my smartcards :)
For /etc I'm not so sure, I've really come round to .ini style files.
I just hope the LDAP integration of this works well. I have a feeling that Poettering won't give a shit if it doesn't work with Active Directory...
And more PKCS#11 support would be great, I love my smartcards :)
This seems like a massive boondoggle and a potential security issue.
No thanks.
No thanks.
There are some things brought in that I like, but I don't believe systemd is required for them. Cgroups, LXC, to name a couple. Those make functional and operational sense to me.