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