readme: rewrite why, add pros/cons

README.md

@@ -4,25 +4,37 @@ Drop-in replacement for `libudev` intended to work with any device manager
 
 ## Why?
 
-Because `udev` sucks, it is bloated and overengineered. `udev` is just
-like `systemd`, it locks you into using non-portable crap that you can't
-avoid because multiple programs depend on it. Look, even FreeBSD was forced
-to rewrite[0] this crappy library because `libinput` hard-depends on `udev`.
-Without `libinput` you can't use `wayland` and many other cool stuff.
+We all know that systemd is very hostile towards portability. Udev inherited
+the same problem by exposing a very badly designed library interface. This is
+dramatically reduces portability, user choice and basically creates vendor
+lock-in because library interface highly tied to udev daemon.
 
-Michael Forney (author of `cproc`, `samurai`, Oasis Linux, ...) decided to
-fork[1] `libinput` and remove the hard dependency on `udev`. However, this
-fork has a drawback that requires patching applications to use `libinput_netlink`
-instead of the `libinput_udev` API in order to use the automatic detection of
-input devices and hotplugging. Static configuration is also required for anything
-other than input devices (e.g drm devices).
+Another udev problem is non-portable home-grown language called "udev rules".
+Udev authors definitely don't know(or care) why it's better to avoid reinventing
+the wheel. Strictly speaking, I think they did that on purpose to overcomplicate
+udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate
+the future of udev. The recent eudev death only proves that it's really hard to
+support such unmaintainable mess.
 
-Thankfully `udev` has stable API and hopefully no changes will be made to it
-the future. On this basis I decided to create this clean-room implementation
-of `libudev` which can be used with any or without a device manager.
+Udev hwdb is yet another illustration of systemd-like approach. What the hell
+"userspace /dev" has to do with parsing hardware database(pci.ids, usb.ids)
+and setting/remapping buttons? Udev smells like systemd by trying to implement
+all possible functionality in the single daemon/code base. Standalone UNIX-way
+programs much better suited for such purposes.
 
-[0] https://github.com/FreeBSDDesktop/libudev-devd  
-[1] https://github.com/oasislinux/libinput
+Keep in mind that libudev-zero isn't ideal. Here is some pros/cons:
+
+### Pros
+
+* Very portable. Doesn't depend on GNU features.
+* No lock-in. Any device manager can be used, even smdev and CONFIG_UEVENT_HELPER.
+* Source code is much cleaner than udev because of less abstractions and clever code.
+
+### Cons
+
+* Udev rules must be converted to shell script in order to work with any device manager.
+* Udev hwdb interface isn't implemented. pciutils and usbutils will not display any meaningful info.
+* Many functions and interfaces still aren't implemented, which may lead to breakage in some programs.
 
 ## What doesn't work