better motivation in README based on technical merits #75
Description
udev inherited the same problem by exposing a very badly designed library interface.
1 This does not explain what parts are badly designed. Design quality can only be evaluated based on goals and accepted trade-offs and these are not elaborated. https://en.wikipedia.org/wiki/Udev elaborates on the design, but does not provide goals or trade-offs.
This dramatically reduces portability, user choice and basically creates vendor lock-in because the library interface highly tied to the udev daemon.
This is missing context and how a better design would work based on 1.
Another udev problem is the non-portable home-grown language called "udev rules".
Languages are typically non-portable unless one has more or less bad extensions, see the history of C++ as "C with extensions", so I do not understand this argument.
The udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel.
Missing elaboration. See missing point 1 from your side.
Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible.
Missing examples how the desired functionality can be simplified in a configuration language or how the system admins and less technical users should configure their work flows.
trying to implement all possible functionality in the single daemon/code base
No argument how the alternative should work based on design in 1.
Convince mainstream apps(libinput, wlroots, ...) to use a new library instead of libudev.
As of now, the README does not read convincing to me. Options for personal contact would be also nice.
So far I am unaware how much maintenance churn this would mean to get "stuff just working" or to debug and patch things with your suggested solution for different type of users. For a more successful example how to replace systemd, check out dinit.
Personally I think the fundamental approach sounds fine for "doing stuff automatically based on rules for hardware".