
Reinventing Home Directories – systemd-homed [pdf] - kragniz
https://cfp.all-systems-go.io/media/homed-asg2019.pdf
======
LinuxBender
I am not comfortable with the feature creep that systemd is slowing bringing
in. binfmt mount executing files based on a lookup, similar to windows assoc,
intercepting gethostbyname(), this really feels like an attempt to shim old
vulnerable windows concepts into linux. I am concerned that linux will not be
recognizable in the near future and will be subject to bloat and obfuscation.
What would it take to make this stop?

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.

~~~
JohnFen
> 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.

------
danmg
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.

~~~
PyroLagus
> 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.

~~~
danmg
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.

------
hiciu
talk / context:
[https://streaming.media.ccc.de/asg2019/relive/164](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.

------
airencracken
This seems like a massive boondoggle and a potential security issue.

No thanks.

------
philpem
What is with this fetish of putting everything in systemd?

Soon it'll have an X-server and a word processor built in...

------
mongol
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.

