4 ms·

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_

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.
      - deleted 14y ago
        [deleted]
    - mseepgood 14y ago
      > it still requires building dependencies that are NOT needed by udev No, it doesn't: make systemd-udevd
- deleted 14y ago
  [deleted]
nitrogen 14y ago
Calling a fork "hate-driven development" is unproductive. Further, I found the linked dismissal of Trinity[0] to be as personal, misguided, and "hateful" as it accused the Trinity developers of being. [0] http://blog.martin-graesslin.com/blog/2012/02/having-a-look-at-the-oldnew-desktop-environments/ http://blog.martin-graesslin.com/blog/2012/02/having-a-look-...
- mercurial 14y ago
  The quotes Martin provides on his blog seem to support his criticisms adequately, IMHO. And the decision to stay with qt3 does not bode well for the future of the Trinity project.
  - nitrogen 14y ago
    I appreciate Martin's contributions to KDE, but when I read that blog post it seemed like he was taking the Trinity fork personally, especially due to one of this three imagined reasons for the fork being "Haters of “KDE 4″ technology". There are many other reasons why someone might want to keep KDE3 going apart from the three he gave. Also: "Seeing commits to “twin” really hurts and our current version of KWin is just better in any area." That post was from February, though, so there's little reason for us to continue to dissect it now. I just use it as an example of some of the unfortunate reactions developers have to forks of their code, and a demonstration that those deriding forks should not be taken seriously until after some investigation confirms the validity of their derision.
- qu4z-2 14y ago
  "[...] the reason that users have trouble with KDE Plasma on “lightweight” systems is not because the hardware is “lightweight” but just old." It sounds like he's dismissing older hardware out of hand. I'm not pleased with this.
  - michaelhoffman 14y ago
    My read on it is he's saying that KDE 3.5 isn't great on older hardware either, so what's the point?

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.
    - deleted 14y ago
      [deleted]
  - mseepgood 14y ago
    > it still requires building dependencies that are NOT needed by udev No, it doesn't: make systemd-udevd
deleted 14y ago
[deleted]

nitrogen 14y ago

Calling a fork "hate-driven development" is unproductive. Further, I found the linked dismissal of Trinity[0] to be as personal, misguided, and "hateful" as it accused the Trinity developers of being. [0] http://blog.martin-graesslin.com/blog/2012/02/having-a-look-at-the-oldnew-desktop-environments/ http://blog.martin-graesslin.com/blog/2012/02/having-a-look-...

mercurial 14y ago
The quotes Martin provides on his blog seem to support his criticisms adequately, IMHO. And the decision to stay with qt3 does not bode well for the future of the Trinity project.
- nitrogen 14y ago
  I appreciate Martin's contributions to KDE, but when I read that blog post it seemed like he was taking the Trinity fork personally, especially due to one of this three imagined reasons for the fork being "Haters of “KDE 4″ technology". There are many other reasons why someone might want to keep KDE3 going apart from the three he gave. Also: "Seeing commits to “twin” really hurts and our current version of KWin is just better in any area." That post was from February, though, so there's little reason for us to continue to dissect it now. I just use it as an example of some of the unfortunate reactions developers have to forks of their code, and a demonstration that those deriding forks should not be taken seriously until after some investigation confirms the validity of their derision.
qu4z-2 14y ago
"[...] the reason that users have trouble with KDE Plasma on “lightweight” systems is not because the hardware is “lightweight” but just old." It sounds like he's dismissing older hardware out of hand. I'm not pleased with this.
- michaelhoffman 14y ago
  My read on it is he's saying that KDE 3.5 isn't great on older hardware either, so what's the point?