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