9 ms·

My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. All these dependencies seem to be g

by nextos 7y ago

My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. All these dependencies seem to be getting more or less mandatory. Running a distribution without them is getting harder. Given that they are all getting pushed by the same group of people at Red Hat, it is concerning as they are effectively gaining control of the Linux userland. And given that their architectural decisions are quite contentious and at odds with many Unix design principles, this is not good.

ip26 7y ago
If they are gaining control of the Linux userland because they are the only ones willing & able to put in the development effort, then IMO we can hardly complain. "Decisions are made by those who show up"
- AsyncAwait 7y ago
  Additionally, no alternative project is even providing close to the set of features that i.e. systemd or pulseaudio does, not even via modules. sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1. (watch https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo if you don't know why)
  - _emacsomancer_ 7y ago
    > sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd systems frequently hang on reboot, often needing a REISUB).
    - AsyncAwait 7y ago
      > Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. > my runit systems all behave themselves; my systemd systems frequently hang on reboot Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), and systemd has a default 90s timer to try to wait for everything to dismount, shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that - look for 'DefaultTimeoutStopSec' in /etc/systemd/system.conf).
      - _emacsomancer_ 7y ago
        > Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my understanding is that there is a proper openrc-init being developed. I was actually thinking more of runit and shepherd, which provide their own init and daemon-management. > > my runit systems all behave themselves; my systemd systems frequently hang on reboot > Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like. > shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that) But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd. runit shuts things down properly; with systemd I often have to literally 'yank the cord'.
notatoad 7y ago
>they are effectively gaining control of the Linux userland. but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work. The only reason they're gaining control is becuase the rest of the linux userbase has decided that although they might complain about Red Hat's work on hacker news and deride it as "not good", it's actually good enough that nobody wants to use any alternative projects to the ones red hat works on.
- traverseda 7y ago
  It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders. If they were more willing to compromise and cooperate I don't think they'd catch nearly this much flac.
  - nextos 7y ago
    Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat). I only expect this to happen if Systemd and related efforts become really bothersome. Right now it is a big of a mixed situation. A better init system, and some modern basic userland infrastructure was needed. Systemd has brought some good things, but overall changes are concerning for the reasons outlined in my parent comment.
    - danieldk 7y ago
      Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat). There are exceptions. Drew Devault and the rest of the Sway team did write wlroots, an alternative compositor for Wayland, so Wayland is less of a monoculture. But it is true that it requires a lot of manpower, money, and will to develop an alternative to e.g. Wayland. However, I see the current situation more as the glass being half full. Imagine that we did not have Red Hat, and others pulling the weight of Wayland (and other technologies, such as Flatpak), the Linux desktop ecosystem would in many ways be hopelessly behind macOS, iOS, and Windows. I think this is a better outcome than being stuck with 80ies/90ies graphics technology forever, even if it is not perfect.
seba_dos1 7y ago
While I generally understand your sentiment, I can't see how does it apply to Wayland in particular. You can replace Wayland with X11 and basically make the same argument. You can implement Wayland compositor on top of X11 protocol if you wish. You can also implement X11 server on top of Wayland protocol (and that's actually already done and widely used, called XWayland). Given the oddities and architectural baggage of X11, designing a new protocol from scratch is really welcome there. (of course you can argue whether some decisions made while designing Wayland core and its extensions are sensible, but that's a completely different discussion)
- makomk 7y ago
  XWayland isn't a normal Wayland client - it requires special assistance from the compositor. In particular, the compositor acts as the X window manager and there's a special interface between it and XWayland on the Wayland side to make everything work. I don't think it's possible to even implement something like XWayland as an ordinary Wayland client. By design, ordinary Wayland windows are not permitted to know or control their on-screen position, and X relies heavily on apps being able to do both. This is also a major reason why Wine will never support Wayland in the same way that it does X. Basically, if your preferred compositor ever gets fed up of maintaining support for running X applications, the only way you'll be able to run apps that haven't been ported to Wayland is in an emulated desktop confined to its own window. Expect this to happen sooner rather than later given the current attitudes to backwards compatibility. (Think about Ubuntu dropping support for 32-bit applications, for example.) On the positive side, at least Windows 10 doesn't suffer from the same limitation...
  - seba_dos1 7y ago
    I never mentioned implementing XWayland as an ordinary Wayland client. Basically any sensible Wayland compositor you may want to use on your desktop already has XWayland properly integrated. If one of them drops it, you can switch to a more sensible one.
phkahler 7y ago
Wayland is actually more sensible than X. People used to say X had become an OS itself, having memory management, font management, a full drawing API (not used by modern GUI toolkits), and more. One thing transitions like this do is cause the death of unmaintained programs. In some cases that's good, others bad. But ultimately if no one cares enough to modernize it that says something. But we also shouldn't keep developers on an endless train of changes to keep up with. Wayland is like 10 years in the making, so there really is no excuse not to be there already.
- pmontra 7y ago
  > People used to say X had become an OS itself, having memory management, font management, a full drawing API (not used by modern GUI toolkits), and more. That's OK. I used X terminals from HP in the early 90. 1024x1024 monochrome with an Ethernet connection. Their only purpose was to manage the screen, mouse and keyboard. I don't know which OS they were running on (something proprietar?) but probably X11 was the only application they were running.
  - pmontra 7y ago
    I googled for those X Terminals: https://en.wikipedia.org/wiki/HP_X-Terminals https://en.wikipedia.org/wiki/HP_X-Terminals We probably had the 19i because I'm sure it was 1 bit per pixel, so it was 1280x1024.
mort96 7y ago
It sounds weird to me to claim the Wayland ecosystem is less modular than the X ecosystem. With X, you're depending on one huge monolithic display server implementation; with Wayland, you can switch display server at will and they all conform to a common protocol. I get the concern that most of the functionality which used to be in separate programs is now bundled with the Wayland compositor, and I used to share it, but after getting more involved with Wayland stuff, I don't think it's really that big of a deal. The wlroots people have been really good at introducing new common protocols for stuff people actually need. The Wayland ecosystem, at least outside of Gnome, is actually really nice and improving.
- Sir_Cmpwn 7y ago
  Wayland is more modular in other ways, too. We went from IPC-based modularity with separate processes towards modularity via relegating different tasks to different libraries. Like being able to use libinput and libdrm and EGL and libwayland all separately makes for a much more modular stack than putting it all in X.
- bitwize 7y ago
  With X, you can switch your display server as well (and there were proprietary X server offerings available as late as the late 90s/early 2000s). It's just that Xorg, being internally more modular than XFree86, sapped the value add of redoing the entire X server and effectively "won". In fact, with X you can switch out your display server and keep your window manager. Can't do that with Wayland -- by design. Now who's huge and monolithic?
  - PlutoIsAPlanet 7y ago
    Still Xorg.
  - majewsky 7y ago
    > In fact, with X you can switch out your display server and keep your window manager. No, that's not a fact, that's a theory. In practice, there is only one display server that supports modern devices, Xorg. No modularity is lost by replacing a single display server implementation by a single libwayland implementation.
darkpuma 7y ago
I don't understand the ojection to dbus in particular. Are there not multiple implementations of the dbus spec?
- p_l 7y ago
  Haven't seen a case of dbus daemon replacement, only I think one or two client libraries, and one is niche and the other is so niche I think less than 10 people ever used it.
  - darkpuma 7y ago
    AKAIK kdbus re-implemented that half of it, albeit in the kernel not as a daemon. I've not been given the impression that there is anything preventing additional implementations. The strongest technical argument against dbus I've yet heard is that it's too slow for file transfers or something... well fine then, don't use it for that. But for plenty of other stuff it seems to work just fine. People complain about the performance but not once have I ever opened up htop and thought to myself "Gee wiz, dbus sure is breaking my balls today." From my perspective, most of the hate against dbus seems to be fallout from the systemd feud, to which dbus is tangentially related (if systemd sucks, it's not because of dbus.) Maybe with a few cat-v/suckless fanatics thrown in on the sidelines..
    - p_l 7y ago
      kdbus was afaik not-exactly-compatible (at least not wire protocol compatible), and as its main reason for existence had speed. And finally died after Linus went to town on dbus-daemon pointing out a bunch of fixes that made it much faster (though I don't know if anyone turned that example into actual patches for dbus-daemon). As for arguments against d-bus - It's a mess. The protocol is variable-endianess for no reason, back in the very beginning the XML interface spec got significant criticism because introspection required punting and parsing XML. Personally I'd also point to mess of multiple identifiers - last time I tried to figure out details for third-party implementation, I got 3 different addresses per object, whereas sometimes I believe just a reference would suffice. Also, unlike its (probably closest) predecessor DCOP, it's very hard to use d-bus outside of writing a complex program. Systemd is a factor, but it started years before. D-Bus is "desktop bus", and was rather obviously designed to be the interconnect between applications on the desktop. It seems to me to be preciously rare in its original goal of "COM-like" interop on desktop. Then it got started to be used for system daemons. HAL was somewhat reasonable if problematic. PolicyKit and ConsoleKit ... not so much. Those two laid foundations for badly described but "crucial" APIs provided by logind and systemd that were forced down everyone's throat later on. Now that I think of it, NetworkManager taking years to being configurable without gnome panel might have a hand in it too (and cast a shadow on D-Bus due to NM developer arrogance in the past). So, generally, a bit of technology, a containership of politics.
emersion 7y ago
>All these dependencies seem to be getting more or less mandatory. Note that Wayland is not a _new_ dependency. It's a dependency that replaces X11.
rjsw 7y ago
> My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. I don't have any of those things on the system I'm using to type this. It is BSD not Linux though.
snaky 7y ago
> Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)

by nextos 7y ago

ip26 7y ago

If they are gaining control of the Linux userland because they are the only ones willing & able to put in the development effort, then IMO we can hardly complain. "Decisions are made by those who show up"

AsyncAwait 7y ago
Additionally, no alternative project is even providing close to the set of features that i.e. systemd or pulseaudio does, not even via modules. sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1. (watch https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo if you don't know why)
- _emacsomancer_ 7y ago
  > sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd systems frequently hang on reboot, often needing a REISUB).
  - AsyncAwait 7y ago
    > Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. > my runit systems all behave themselves; my systemd systems frequently hang on reboot Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), and systemd has a default 90s timer to try to wait for everything to dismount, shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that - look for 'DefaultTimeoutStopSec' in /etc/systemd/system.conf).
    - _emacsomancer_ 7y ago
      > Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my understanding is that there is a proper openrc-init being developed. I was actually thinking more of runit and shepherd, which provide their own init and daemon-management. > > my runit systems all behave themselves; my systemd systems frequently hang on reboot > Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like. > shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that) But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd. runit shuts things down properly; with systemd I often have to literally 'yank the cord'.

notatoad 7y ago

>they are effectively gaining control of the Linux userland. but they aren't gaining control by some dastardly power grab, they're gaining control because they're the only ones actually putting in the work. They're simply doing what they think is best for their product, while at the same time contributing their work back to the open source world. That is good, that's how it's supposed to work. The only reason they're gaining control is becuase the rest of the linux userbase has decided that although they might complain about Red Hat's work on hacker news and deride it as "not good", it's actually good enough that nobody wants to use any alternative projects to the ones red hat works on.

traverseda 7y ago
It seems like a lot of those projects just aren't interested in accepting pull-requests from outsiders. If they were more willing to compromise and cooperate I don't think they'd catch nearly this much flac.
- nextos 7y ago
  Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat). I only expect this to happen if Systemd and related efforts become really bothersome. Right now it is a big of a mixed situation. A better init system, and some modern basic userland infrastructure was needed. Systemd has brought some good things, but overall changes are concerning for the reasons outlined in my parent comment.
  - danieldk 7y ago
    Exactly. And for much smaller organizations and individuals, it is much harder to organize an alternative effort to this set of projects backed up by a big corporation (Red Hat). There are exceptions. Drew Devault and the rest of the Sway team did write wlroots, an alternative compositor for Wayland, so Wayland is less of a monoculture. But it is true that it requires a lot of manpower, money, and will to develop an alternative to e.g. Wayland. However, I see the current situation more as the glass being half full. Imagine that we did not have Red Hat, and others pulling the weight of Wayland (and other technologies, such as Flatpak), the Linux desktop ecosystem would in many ways be hopelessly behind macOS, iOS, and Windows. I think this is a better outcome than being stuck with 80ies/90ies graphics technology forever, even if it is not perfect.

seba_dos1 7y ago

While I generally understand your sentiment, I can't see how does it apply to Wayland in particular. You can replace Wayland with X11 and basically make the same argument. You can implement Wayland compositor on top of X11 protocol if you wish. You can also implement X11 server on top of Wayland protocol (and that's actually already done and widely used, called XWayland). Given the oddities and architectural baggage of X11, designing a new protocol from scratch is really welcome there. (of course you can argue whether some decisions made while designing Wayland core and its extensions are sensible, but that's a completely different discussion)

makomk 7y ago
XWayland isn't a normal Wayland client - it requires special assistance from the compositor. In particular, the compositor acts as the X window manager and there's a special interface between it and XWayland on the Wayland side to make everything work. I don't think it's possible to even implement something like XWayland as an ordinary Wayland client. By design, ordinary Wayland windows are not permitted to know or control their on-screen position, and X relies heavily on apps being able to do both. This is also a major reason why Wine will never support Wayland in the same way that it does X. Basically, if your preferred compositor ever gets fed up of maintaining support for running X applications, the only way you'll be able to run apps that haven't been ported to Wayland is in an emulated desktop confined to its own window. Expect this to happen sooner rather than later given the current attitudes to backwards compatibility. (Think about Ubuntu dropping support for 32-bit applications, for example.) On the positive side, at least Windows 10 doesn't suffer from the same limitation...
- seba_dos1 7y ago
  I never mentioned implementing XWayland as an ordinary Wayland client. Basically any sensible Wayland compositor you may want to use on your desktop already has XWayland properly integrated. If one of them drops it, you can switch to a more sensible one.

phkahler 7y ago

Wayland is actually more sensible than X. People used to say X had become an OS itself, having memory management, font management, a full drawing API (not used by modern GUI toolkits), and more. One thing transitions like this do is cause the death of unmaintained programs. In some cases that's good, others bad. But ultimately if no one cares enough to modernize it that says something. But we also shouldn't keep developers on an endless train of changes to keep up with. Wayland is like 10 years in the making, so there really is no excuse not to be there already.

pmontra 7y ago
> People used to say X had become an OS itself, having memory management, font management, a full drawing API (not used by modern GUI toolkits), and more. That's OK. I used X terminals from HP in the early 90. 1024x1024 monochrome with an Ethernet connection. Their only purpose was to manage the screen, mouse and keyboard. I don't know which OS they were running on (something proprietar?) but probably X11 was the only application they were running.
- pmontra 7y ago
  I googled for those X Terminals: https://en.wikipedia.org/wiki/HP_X-Terminals https://en.wikipedia.org/wiki/HP_X-Terminals We probably had the 19i because I'm sure it was 1 bit per pixel, so it was 1280x1024.

mort96 7y ago

It sounds weird to me to claim the Wayland ecosystem is less modular than the X ecosystem. With X, you're depending on one huge monolithic display server implementation; with Wayland, you can switch display server at will and they all conform to a common protocol. I get the concern that most of the functionality which used to be in separate programs is now bundled with the Wayland compositor, and I used to share it, but after getting more involved with Wayland stuff, I don't think it's really that big of a deal. The wlroots people have been really good at introducing new common protocols for stuff people actually need. The Wayland ecosystem, at least outside of Gnome, is actually really nice and improving.

Sir_Cmpwn 7y ago
Wayland is more modular in other ways, too. We went from IPC-based modularity with separate processes towards modularity via relegating different tasks to different libraries. Like being able to use libinput and libdrm and EGL and libwayland all separately makes for a much more modular stack than putting it all in X.
bitwize 7y ago
With X, you can switch your display server as well (and there were proprietary X server offerings available as late as the late 90s/early 2000s). It's just that Xorg, being internally more modular than XFree86, sapped the value add of redoing the entire X server and effectively "won". In fact, with X you can switch out your display server and keep your window manager. Can't do that with Wayland -- by design. Now who's huge and monolithic?
- PlutoIsAPlanet 7y ago
  Still Xorg.
- majewsky 7y ago
  > In fact, with X you can switch out your display server and keep your window manager. No, that's not a fact, that's a theory. In practice, there is only one display server that supports modern devices, Xorg. No modularity is lost by replacing a single display server implementation by a single libwayland implementation.

darkpuma 7y ago

I don't understand the ojection to dbus in particular. Are there not multiple implementations of the dbus spec?

p_l 7y ago
Haven't seen a case of dbus daemon replacement, only I think one or two client libraries, and one is niche and the other is so niche I think less than 10 people ever used it.
- darkpuma 7y ago
  AKAIK kdbus re-implemented that half of it, albeit in the kernel not as a daemon. I've not been given the impression that there is anything preventing additional implementations. The strongest technical argument against dbus I've yet heard is that it's too slow for file transfers or something... well fine then, don't use it for that. But for plenty of other stuff it seems to work just fine. People complain about the performance but not once have I ever opened up htop and thought to myself "Gee wiz, dbus sure is breaking my balls today." From my perspective, most of the hate against dbus seems to be fallout from the systemd feud, to which dbus is tangentially related (if systemd sucks, it's not because of dbus.) Maybe with a few cat-v/suckless fanatics thrown in on the sidelines..
  - p_l 7y ago
    kdbus was afaik not-exactly-compatible (at least not wire protocol compatible), and as its main reason for existence had speed. And finally died after Linus went to town on dbus-daemon pointing out a bunch of fixes that made it much faster (though I don't know if anyone turned that example into actual patches for dbus-daemon). As for arguments against d-bus - It's a mess. The protocol is variable-endianess for no reason, back in the very beginning the XML interface spec got significant criticism because introspection required punting and parsing XML. Personally I'd also point to mess of multiple identifiers - last time I tried to figure out details for third-party implementation, I got 3 different addresses per object, whereas sometimes I believe just a reference would suffice. Also, unlike its (probably closest) predecessor DCOP, it's very hard to use d-bus outside of writing a complex program. Systemd is a factor, but it started years before. D-Bus is "desktop bus", and was rather obviously designed to be the interconnect between applications on the desktop. It seems to me to be preciously rare in its original goal of "COM-like" interop on desktop. Then it got started to be used for system daemons. HAL was somewhat reasonable if problematic. PolicyKit and ConsoleKit ... not so much. Those two laid foundations for badly described but "crucial" APIs provided by logind and systemd that were forced down everyone's throat later on. Now that I think of it, NetworkManager taking years to being configurable without gnome panel might have a hand in it too (and cast a shadow on D-Bus due to NM developer arrogance in the past). So, generally, a bit of technology, a containership of politics.

emersion 7y ago

>All these dependencies seem to be getting more or less mandatory. Note that Wayland is not a _new_ dependency. It's a dependency that replaces X11.

rjsw 7y ago

> My concern at the moment with Wayland (and Systemd, Pulseaudio, DBus and a few others) is that Linux is loosing modularity. I don't have any of those things on the system I'm using to type this. It is BSD not Linux though.

snaky 7y ago

> Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.) > Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that). http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015 http://www.landley.net/notes-2015.html#05-07-2015)