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.
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.
Probably, vote with your time and focus. Use better distributions and port software to those distributions.
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 /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 :)
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.
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.
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.
No thanks.
Soon it'll have an X-server and a word processor built in...
