http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...
http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...
[0] http://blog.martin-graesslin.com/blog/2012/02/having-a-look-...
It sounds like he's dismissing older hardware out of hand. I'm not pleased with this.
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.
systemd also brings it's own dependencies.
But that's just conveniently omitted from such explanation posts.
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.
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.
No, it doesn't: make systemd-udevd