Adam Borowski <kilob...@angband.pl> writes: > -shim is moribund (and never worked right even when it was maintained), > thus installing it on systems with modular inits is damage. I believe > this is the problem that should be solved first -- because all > non-trivial cases mentioned above use logind or an equivalent, and to > implement a profile you need to know what alternate dependency to use.
> The name I hear the most is elogind, but other options also get > mentioned. It'd be good if someone more knowledgeable could say more; I > think multiple Debian derivatives are experimenting here. > Once such a solution is chosen, implemented and tested, only then it'll > be time to fix dependencies -- inside Debian rather than some > derivative. I think this would be great. It's both meaningful and useful in creating more ecosystem diversity. I'd be happy to take patches for this sort of thing as a maintainer, and I think it's a much better use of people's energy and good will. I think the key to a good path forward is to recognize that systemd solved some specific problems, and to build a roadmap of which problems do indeed need to be solved and the alternate solutions to them, and which aren't important enough to folks who don't like systemd to solve and therefore will stay systemd-exclusive features until that changes. Then there can be a sustained ecosystem, with a clear mission, alongside systemd, and Debian can endeavor to support both. And the resulting tools, assuming they're built in the small pluggable tool model (seems like a likely bet) would be broadly useful even for those of us who like systemd. For example, I'd love something that can do the jailing and seccomp rule configuration that systemd can do, with the same or very similar syntax and, particularly, the syscall groupings, but that is implemented as a standalone wrapper program that I can use in situations where I don't want to spawn a service. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
