8 ms·

Gentoo developers start udev fork

49 points by mercurial 14y ago

kylek 14y ago
Slightly OT but hilariously spot-on about many gentoo-isms: http://funroll-loops.info http://funroll-loops.info
- nitrogen 14y ago
  Many of the quotes on that page were reasonable questions and statements. Adding a picture of a van with more tailfins than a 1950s roadster doesn't change that.
  - sliverstorm 14y ago
    Agreed. I still don't understand why the comments about USE flags are supposed to be comical. I haven't used Gentoo for a while now because the downsides outweigh the plusses for me, but I think USE flags are definitely one of the plusses. Watching shit scroll by for hours makes me a Linux expert overnight! No, but when this or that package failed to compile and I didn't even have X yet let alone Firefox (for Google)- that was when I first really started learning about Linux.
    - tehwalrus 14y ago
      I don't use Gentoo anymore (mostly because I don't want to break my Macbook Pro's fussy EFI bootsector nonsense) but installing it on machines a couple of times taught me more about Linux (indeed Unix-ness) than any previous activity.
      - PhantomLobe 14y ago
        Me too. I arrived to Gentoo from Debian-land, where a lot of things happened automagically. Now I stick to Arch, kind of a middle ground IME.
  - mercurial 14y ago
    On the other hand, I can see the point in making fun of people removing use flags and playing with -O in order to squeeze performance out of their DE. I've been one of these people, and in my experience, any such gain is too small to be noticeable in practice.
    - nitrogen 14y ago
      Removing use flags and playing with optimization flags can be one of the intermediate steps on the path from "knows nothing about Linux or computer hardware" to "expert low-level developer or admin with detailed knowledge of CPU microarchitecture and practical OS design."
mercurial 14y ago
Don't miss the link to Greg Kroah-Hartman's G+ page [1], it's pretty funny. [1] https://plus.google.com/111049168280159033135/posts/R387kQb1zxc https://plus.google.com/111049168280159033135/posts/R387kQb1...
- ChuckMcM 14y ago
  Those are priceless. There is that old phrase "take your ball and bat and go home" which a child was unhappy with how a game they were playing was going they could just leave. Now when someone gets criticized for their design skills they take their changes and try to build an entirely new ballpark, ticketing system, franchise rules, game rules, and seat numbering scheme. I'd think it was funny if I wasn't dealing with the whole drm/kms/dri/x11/gles battle to see who can build the stupidest way to plug this together for my own, otherwise fun, projects. Makes me pine for Microsoft to port DirectX to Linux, how sad is that!
  - nitrogen 14y ago
    I don't think that the current direction of absorbing everything into either systemd or X11 is the right direction for the Linux ecosystem to take. I find it particularly amusing that, just as Wayland was being created, other developers decided to move input handling out of an independent daemon, hal, and into XInput2. I hope that the Gentoo developers eventually settle on a single, lightweight udev daemon that does one thing and does it well, so that it remains useful outside of the Gnome+Xorg+systemd desktop stack.
    - secure 14y ago
      hal is long deprecated and never provided input handling. XInput2 is an extension which you can use to get support for multiple pointers and better keyboard state. The input handling is still done (and was for a long time) by XKB in the X11 server, XInput2 is just a different API.
      - lmm 14y ago
        In the dim and distant past, I could set the keyboard layout used when X first started (in particular, the layout used for my login screen, KDM) in xorg.conf. Not pretty, but it worked. Then HAL came along, and I couldn't do that, but there was an undocumented XML file that I could use to set my keyboard layout. Even uglier, but fine, after enough googling I found out how to do it. Then HAL was deprecated, and now I don't know how to set that keyboard layout and can't find out (after logging in is fine, but having the correct keyboard layout is if anything more important when typing a password than in general use). I asked Matthew Garrett and he asked why would you ever want to change your keyboard layout? This is why I don't use linux any more.
bishop_mandible 14y ago
This is fun: http://twitter.com/mjg59/status/270323838468890624 http://twitter.com/mjg59/status/270323838468890624
- nitrogen 14y ago
  What's wrong with wanting to avoid glibc dependencies? The #define approach is not the way to do it, but why not make a udev that works with other C libraries and/or can be compiled with -std=c99?
  - adestefan 14y ago
    Because glib is a decent library of data structures and algorithms that will just need to be reimplemented.
    - steevdave 14y ago
      Maybe so, but we would like to support uclibc and (eventually?) musl
    - steevdave 14y ago
      Also, glib != glibc
      - adestefan 14y ago
        Bah. Poor reading comprehension.
mseepgood 14y ago
Probably the best explanation of the situation (found on reddit) http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_can_get_pissed_on_everything_from_names/c74e7n7 http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...
- zobzu 14y ago
  I don't think it does. udev also now requires systemd, which means, you have no choice, but to use systemd. systemd also brings it's own dependencies. But that's just conveniently omitted from such explanation posts.
  - kelnos 14y ago
    Not quite true. The systemd source tree supports building (and using) udev standalone, without systemd. The disturbing part is that Lennart Poettering has stated that he's not happy with that state of affairs and would be happier if they were more tightly coupled.
    - steevdave 14y ago
      While udev can be built from the systemd sources, it still requires building dependencies that are NOT needed by udev. This was silly and even though a patch was created specifically to address this, it was nak'd by the systemd developers. Disclaimer: I've been a Gentoo developer for about 7 years now. I'm not directly working on the fork but I am testing and throwing in suggestions for using it on ARM devices where it doesn't make sense to have everything systemd provides, but the devices are more powerful and busybox's mdev is underkill.
      - cmccabe 14y ago
        While udev can be built from the systemd sources, it still requires building dependencies that are NOT needed by udev. So patch the Makefile.in. Maintaining one patch requires a fork? I am testing and throwing in suggestions for using it on ARM devices where it doesn't make sense to have everything systemd provides, but the devices are more powerful and busybox's mdev is underkill. Yep, when I use an embedded ARM device, I definitely want a sluggish sysV init boot process. And a crusty old standalone udev with brittle hacks to handle sleep, suspend, and other power-related state transitions. Because, you know, it's not x86.
oofabz 14y ago
>their fork is designed to allow a system to be started even if the /usr/ directory hasn't been mounted yet. What a terrible reason to fork. This feature is useless. Putting /usr/ on a separate filesystem made sense 20 years ago when storage capacities were small, but not anymore. On Fedora, /bin, /sbin, and /lib are symlinks to their counterparts in /usr. I applaud them for this effort to simplify Unix and move away from cargo cult ritual.
- dfc 14y ago
  Is cargo cult the correct term? I have never seen it used to mean "doing things a certain way because they have always been done that way."
  - secure 14y ago
    http://en.wikipedia.org/wiki/Cargo_cult_programming http://en.wikipedia.org/wiki/Cargo_cult_programming says: Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution (compare shotgun debugging, voodoo programming).[1] The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. I think that applies here.
    - yankcrime 14y ago
      So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seperate filesystems have done so because the developers are unskilled novices with no understanding or experience of the problem at hand? Sorry, I think it's entirely the wrong term. [1] http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning
qznc 14y ago
Looking through the email threads I found this: Kay Sievers more or less broke udev for a substantial amount of users by prohibiting kernel modules to load firmware in user-space. Sievers, Hartman, et al consider this reasonable as the drivers, which do this, should be fixed. Torvalds, Cox, et al consider this no good reason to break things. So at least Alan Cox seems to support the forking: > Just fix udev, and if you can't fix it someone please just fork the last working one. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D1368822 http://thread.gmane.org/gmane.linux.drivers.video-input-infr...
zokier 14y ago
So let me get this straight: now we have two branches of udev that are maintained by ... unconservative[1] ... people, and no usable one. Hopefully this will be resolved before it gets out of hand. I think the situation is especially iffy for distros like Debian who are committed to long term support of whatever they choose. [1] I didn't want to write "idiots", partly because I actually respect what the systemd camp is trying to do.

49 points by mercurial 14y ago

kylek 14y ago

Slightly OT but hilariously spot-on about many gentoo-isms: http://funroll-loops.info http://funroll-loops.info

nitrogen 14y ago
Many of the quotes on that page were reasonable questions and statements. Adding a picture of a van with more tailfins than a 1950s roadster doesn't change that.
- sliverstorm 14y ago
  Agreed. I still don't understand why the comments about USE flags are supposed to be comical. I haven't used Gentoo for a while now because the downsides outweigh the plusses for me, but I think USE flags are definitely one of the plusses. Watching shit scroll by for hours makes me a Linux expert overnight! No, but when this or that package failed to compile and I didn't even have X yet let alone Firefox (for Google)- that was when I first really started learning about Linux.
  - tehwalrus 14y ago
    I don't use Gentoo anymore (mostly because I don't want to break my Macbook Pro's fussy EFI bootsector nonsense) but installing it on machines a couple of times taught me more about Linux (indeed Unix-ness) than any previous activity.
    - PhantomLobe 14y ago
      Me too. I arrived to Gentoo from Debian-land, where a lot of things happened automagically. Now I stick to Arch, kind of a middle ground IME.
- mercurial 14y ago
  On the other hand, I can see the point in making fun of people removing use flags and playing with -O in order to squeeze performance out of their DE. I've been one of these people, and in my experience, any such gain is too small to be noticeable in practice.
  - nitrogen 14y ago
    Removing use flags and playing with optimization flags can be one of the intermediate steps on the path from "knows nothing about Linux or computer hardware" to "expert low-level developer or admin with detailed knowledge of CPU microarchitecture and practical OS design."

mercurial 14y ago

Don't miss the link to Greg Kroah-Hartman's G+ page [1], it's pretty funny. [1] https://plus.google.com/111049168280159033135/posts/R387kQb1zxc https://plus.google.com/111049168280159033135/posts/R387kQb1...

ChuckMcM 14y ago
Those are priceless. There is that old phrase "take your ball and bat and go home" which a child was unhappy with how a game they were playing was going they could just leave. Now when someone gets criticized for their design skills they take their changes and try to build an entirely new ballpark, ticketing system, franchise rules, game rules, and seat numbering scheme. I'd think it was funny if I wasn't dealing with the whole drm/kms/dri/x11/gles battle to see who can build the stupidest way to plug this together for my own, otherwise fun, projects. Makes me pine for Microsoft to port DirectX to Linux, how sad is that!
- nitrogen 14y ago
  I don't think that the current direction of absorbing everything into either systemd or X11 is the right direction for the Linux ecosystem to take. I find it particularly amusing that, just as Wayland was being created, other developers decided to move input handling out of an independent daemon, hal, and into XInput2. I hope that the Gentoo developers eventually settle on a single, lightweight udev daemon that does one thing and does it well, so that it remains useful outside of the Gnome+Xorg+systemd desktop stack.
  - secure 14y ago
    hal is long deprecated and never provided input handling. XInput2 is an extension which you can use to get support for multiple pointers and better keyboard state. The input handling is still done (and was for a long time) by XKB in the X11 server, XInput2 is just a different API.
    - lmm 14y ago
      In the dim and distant past, I could set the keyboard layout used when X first started (in particular, the layout used for my login screen, KDM) in xorg.conf. Not pretty, but it worked. Then HAL came along, and I couldn't do that, but there was an undocumented XML file that I could use to set my keyboard layout. Even uglier, but fine, after enough googling I found out how to do it. Then HAL was deprecated, and now I don't know how to set that keyboard layout and can't find out (after logging in is fine, but having the correct keyboard layout is if anything more important when typing a password than in general use). I asked Matthew Garrett and he asked why would you ever want to change your keyboard layout? This is why I don't use linux any more.

bishop_mandible 14y ago

This is fun: http://twitter.com/mjg59/status/270323838468890624 http://twitter.com/mjg59/status/270323838468890624

nitrogen 14y ago
What's wrong with wanting to avoid glibc dependencies? The #define approach is not the way to do it, but why not make a udev that works with other C libraries and/or can be compiled with -std=c99?
- adestefan 14y ago
  Because glib is a decent library of data structures and algorithms that will just need to be reimplemented.
  - steevdave 14y ago
    Maybe so, but we would like to support uclibc and (eventually?) musl
  - steevdave 14y ago
    Also, glib != glibc
    - adestefan 14y ago
      Bah. Poor reading comprehension.

mseepgood 14y ago

Probably the best explanation of the situation (found on reddit) http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_can_get_pissed_on_everything_from_names/c74e7n7 http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...

zobzu 14y ago
I don't think it does. udev also now requires systemd, which means, you have no choice, but to use systemd. systemd also brings it's own dependencies. But that's just conveniently omitted from such explanation posts.
- kelnos 14y ago
  Not quite true. The systemd source tree supports building (and using) udev standalone, without systemd. The disturbing part is that Lennart Poettering has stated that he's not happy with that state of affairs and would be happier if they were more tightly coupled.
  - steevdave 14y ago
    While udev can be built from the systemd sources, it still requires building dependencies that are NOT needed by udev. This was silly and even though a patch was created specifically to address this, it was nak'd by the systemd developers. Disclaimer: I've been a Gentoo developer for about 7 years now. I'm not directly working on the fork but I am testing and throwing in suggestions for using it on ARM devices where it doesn't make sense to have everything systemd provides, but the devices are more powerful and busybox's mdev is underkill.
    - cmccabe 14y ago
      While udev can be built from the systemd sources, it still requires building dependencies that are NOT needed by udev. So patch the Makefile.in. Maintaining one patch requires a fork? I am testing and throwing in suggestions for using it on ARM devices where it doesn't make sense to have everything systemd provides, but the devices are more powerful and busybox's mdev is underkill. Yep, when I use an embedded ARM device, I definitely want a sluggish sysV init boot process. And a crusty old standalone udev with brittle hacks to handle sleep, suspend, and other power-related state transitions. Because, you know, it's not x86.

oofabz 14y ago

>their fork is designed to allow a system to be started even if the /usr/ directory hasn't been mounted yet. What a terrible reason to fork. This feature is useless. Putting /usr/ on a separate filesystem made sense 20 years ago when storage capacities were small, but not anymore. On Fedora, /bin, /sbin, and /lib are symlinks to their counterparts in /usr. I applaud them for this effort to simplify Unix and move away from cargo cult ritual.

dfc 14y ago
Is cargo cult the correct term? I have never seen it used to mean "doing things a certain way because they have always been done that way."
- secure 14y ago
  http://en.wikipedia.org/wiki/Cargo_cult_programming http://en.wikipedia.org/wiki/Cargo_cult_programming says: Cargo cult programming is a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution (compare shotgun debugging, voodoo programming).[1] The term cargo cult programmer may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. I think that applies here.
  - yankcrime 14y ago
    So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seperate filesystems have done so because the developers are unskilled novices with no understanding or experience of the problem at hand? Sorry, I think it's entirely the wrong term. [1] http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning

qznc 14y ago

Looking through the email threads I found this: Kay Sievers more or less broke udev for a substantial amount of users by prohibiting kernel modules to load firmware in user-space. Sievers, Hartman, et al consider this reasonable as the drivers, which do this, should be fixed. Torvalds, Cox, et al consider this no good reason to break things. So at least Alan Cox seems to support the forking: > Just fix udev, and if you can't fix it someone please just fork the last working one. http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D1368822 http://thread.gmane.org/gmane.linux.drivers.video-input-infr...

zokier 14y ago

So let me get this straight: now we have two branches of udev that are maintained by ... unconservative[1] ... people, and no usable one. Hopefully this will be resolved before it gets out of hand. I think the situation is especially iffy for distros like Debian who are committed to long term support of whatever they choose. [1] I didn't want to write "idiots", partly because I actually respect what the systemd camp is trying to do.