@sertonix @dalias @leftpaddotpy @dysfun the fact that libudev-zero exists kinda proves my point. yes, if you are reimplementing an API, then you have to reimplement the API. i know, shocking.
Top-level
@sertonix @dalias @leftpaddotpy @dysfun the fact that libudev-zero exists kinda proves my point. yes, if you are reimplementing an API, then you have to reimplement the API. i know, shocking. 10 comments
@ariadne And even if you need an api libseatd has shown how to do it right: allow multiple backends. If libudev would work ok when udev isn't running it could be considered independent. @ariadne @sertonix @dalias @leftpaddotpy @dysfun As someone that is one the server side, the total lack of service manager that seems to have understood the problems we deal with is... fascinating. Systemd is definitely the easiest to work with and the one with the most hooks we need. It does have sooooo many issues, both in UX and in implementation (and code quality) but at least it... works and allows us to do the job @ariadne @sertonix @dalias @leftpaddotpy @dysfun Would I love something better and have ideas for it? Sure. Do any of us have the time and expertise and money to build something better? Nope. Same reason we are stuck with autotools and make.... @Di4na @ariadne meson, cmake, and others exist and make my life as a packager and developer much less bad. well, cmake is about on par for packaging suffering as make. but still, they're way nicer to write and use. on the other hand, bazel exists and has caused hours of pain every time I've touched it. but so is the case for googleware of any kind. @ariadne Actively developing better designed software and push the use of it is. And most importantly explain how to use it! The Alpine Wiki tends to include "use this systemd component and it just works(TM)" instead of "you have a choice. One might not work but you can help to improve it here". |
@ariadne @sertonix @leftpaddotpy @dysfun I was only aware that you could use libudev-zero as a udev replacement on a non-systemd system, not that you could opt not to use the systemd-integrated udev behaviors on a systemd-based system. I'm still not convinced the latter is practical unless someone demonstrates it.