| |||||||||||||
systemd 183 releasedsystemd 183 releasedPosted Jun 12, 2012 12:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)In reply to: systemd 183 released by nlucas Parent article: systemd 183 released
Udev is arguably special in that regard. It's in constant flux because of new hardware or new ways to configure it.
Udev's primary API is /dev filesystem structure - which is stable, btw.
(Log in to post comments)
systemd 183 released Posted Jun 12, 2012 13:06 UTC (Tue) by nlucas (subscriber, #33793) [Link]
The kernel is in the same state of flux and that doesn't mean the user-space API is broken.
/dev is only one of the udev API's. libudev is another, as are the DBUS bindings.
None of them should be considered second order APIs. If they exist they will be used by someone somewhere. If they break, someone will be annoyed. If they are constantly breaking more "someones" will be annoyed.
One thing that seems not everyone grasps is that Linux has probably more usage in customized systems than on desktops. udev was published as the rescue for this low-level plumbing, even on customized systems, because USB happened (needed to load modules on demand, creating/removing devices, etc). This systems could use other things (like mdev), but udev is the only one generic enough for most usages (mdev doesn't cover all modular cases).
Android decided to not use udev, but it will need to reinvent it (if it doesn't start using it) for the generic tablet cases (when tablets, maybe docked, replace laptops).
systemd 183 released Posted Jun 12, 2012 13:09 UTC (Tue) by nlucas (subscriber, #33793) [Link]
By the way, I don't mind a little API break once in a while. It's good to cleanup accumulated cruft.
The problem is the constant breakage, not one or other "flag day".
systemd 183 released Posted Jun 13, 2012 16:24 UTC (Wed) by nix (subscriber, #2304) [Link]
Quite. They even moved the daemon around between releases and didn't even have the courtesy to maintain a compatibility symlink (total cost: one line of code in Makefile.am's install rules). I can see no advantage to moving the daemon out of the directory where all other system daemons are located -- it was just done for the hell of it, as far as I can see, but of course it meant everyone had to adjust their boot scripts, and either load them up with compatibility crap in case of downgrades or lose the possibility of downgrading without breaking boot.
(However, they *are* very good at telling you what the compatibility breaks will be, so you *can* adapt to them. But every upgrade feels like skydiving with a possibly-broken parachute, and it shouldn't.)
|
|||||||||||||