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!
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.
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.
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?
Too bad not even Microsoft can manage the feat. The DirectX brand has been pretty stable, but the APIs are constantly being re-invented. DirectDraw: dead, replaced by Direct2D. DirectMusic: deprecated. DirectSound3D: broken by Vista. DirectPlay: deprecated and partly broken by Vista. DirectShow: deprecated. DirectInput: deprecated, partly replaced by XInput.
Even if you restrict your focus to Direct3D, which has a narrower scope than KMS/DRI/X11/OpenGL stack being ridiculed, there's still significant churn and a few complete rewrites in it's history, and basically no attempts to support more than one generation of hardware at a time.
Of course, a lot of the DirectX API churn is due to the original goal of DirectX (direct hardware access, albeit through agnostic interfaces) being obsolete. Giving applications direct access is bad, as can be seen by trying to alt-tab out of most games. Even given the above, Microsoft deserves little credit for trying to provide a stable unified API.
For all its limitations and stagnation, it seems like SDL has been the closest to providing that holy grail of a stable unified API.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
>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.
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.
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.
Security: Adding a layer of security on a per-filesystem basis is not sufficient or necessary. It is only conceivably useful as a backup plan when the actual security system has failed, and at that point it is not sufficient to prevent compromise.
Stability: Quotas are a superior solution.
Speed: Not an issue for /usr, which is rarely written to.
Integrity: We have journaled filesystems now. If you lose a filesystem it is almost certainly because the device has gone bad and needs to be replaced. For last-ditch system recovery, an initrd solution like Dracut works better, since it can solve problems involving the root partition.
Size: Modern computers can boot from any size partition.
fsck: Preventing fsck is no longer useful. It doesn't take an hour like it used to. If there was a power interruption I would prefer to fsck all my filesystems anyway.
For the purposes of this discussion I am assuming that the traditional FHS with multi partitions is useless and or detrimental feature. Not something I agree with but for the sake of argument...
How then do you differentiate between legacy cruft and cargo cult?
Sure, but as qznc's comment makes clear there's quite a few things udev have done that together count as sufficient reason for the eudev authors.
> This feature is useless.
Running out of space on /usr tends to be significantly less obnoxious than running out of space on /. So it's not entirely useless; whether it's worth the additional complexity is a separate matter that I don't have a considered opinion on.
1) Udev doesn't do anything about separate /usr, its systemd that does. Both are in the same source tree but unrelated at runtime(i.e. udev can be used without systemd).
2) systemd only prints a warning about separate /usr, it then continues to go on as before, so it does not affect this working or not.
3) The reasons that separate /usr are broken is not because of systemd, but the other parts of the system that rely on things in /usr in early boot. This happens in a variety of cases where services or hw support code rely on binaries in /usr/bin or data in /usr/share.
Nothing you change in udev or systemd can make this work better, its all about fixing the rest of the system, something nobody cared to do for the 10 years before systemd added the warning to tell people of this problem.
I have no opinion on this fork, but note that keeping /usr separate shields valuable hand-edited configuration data (/etc, sometimes /root) from problems with the (much larger, and therefore more likely to suffer from e.g. bad sectors) /usr.
(The usual "/bin, /sbin are statically linked, /usr/bin, /usr/sbin are dynamically linked" also makes it much easier to recover from some problems. Of course, putting stuff in /usr/etc/ or dynamically linking /bin makes these benefits moots - but that would be Doing It Wrong.)
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.
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.
47 comments
[ 3.1 ms ] story [ 104 ms ] thread[1] https://plus.google.com/111049168280159033135/posts/R387kQb1...
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!
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.
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.
Also, why would one ask mjg (who doesn’t do X11 stuff AFAIK) instead of googling? :-)
A single, unified API would actually be pretty awesome.
Even if you restrict your focus to Direct3D, which has a narrower scope than KMS/DRI/X11/OpenGL stack being ridiculed, there's still significant churn and a few complete rewrites in it's history, and basically no attempts to support more than one generation of hardware at a time.
Of course, a lot of the DirectX API churn is due to the original goal of DirectX (direct hardware access, albeit through agnostic interfaces) being obsolete. Giving applications direct access is bad, as can be seen by trying to alt-tab out of most games. Even given the above, Microsoft deserves little credit for trying to provide a stable unified API.
For all its limitations and stagnation, it seems like SDL has been the closest to providing that holy grail of a stable unified API.
http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...
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
[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.
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.
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.
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.
[1] http://www.openbsd.org/faq/faq4.html#Partitioning
Security: Adding a layer of security on a per-filesystem basis is not sufficient or necessary. It is only conceivably useful as a backup plan when the actual security system has failed, and at that point it is not sufficient to prevent compromise.
Stability: Quotas are a superior solution.
Speed: Not an issue for /usr, which is rarely written to.
Integrity: We have journaled filesystems now. If you lose a filesystem it is almost certainly because the device has gone bad and needs to be replaced. For last-ditch system recovery, an initrd solution like Dracut works better, since it can solve problems involving the root partition.
Size: Modern computers can boot from any size partition.
fsck: Preventing fsck is no longer useful. It doesn't take an hour like it used to. If there was a power interruption I would prefer to fsck all my filesystems anyway.
How then do you differentiate between legacy cruft and cargo cult?
Sure, but as qznc's comment makes clear there's quite a few things udev have done that together count as sufficient reason for the eudev authors.
> This feature is useless.
Running out of space on /usr tends to be significantly less obnoxious than running out of space on /. So it's not entirely useless; whether it's worth the additional complexity is a separate matter that I don't have a considered opinion on.
2) systemd only prints a warning about separate /usr, it then continues to go on as before, so it does not affect this working or not.
3) The reasons that separate /usr are broken is not because of systemd, but the other parts of the system that rely on things in /usr in early boot. This happens in a variety of cases where services or hw support code rely on binaries in /usr/bin or data in /usr/share.
Nothing you change in udev or systemd can make this work better, its all about fixing the rest of the system, something nobody cared to do for the 10 years before systemd added the warning to tell people of this problem.
(The usual "/bin, /sbin are statically linked, /usr/bin, /usr/sbin are dynamically linked" also makes it much easier to recover from some problems. Of course, putting stuff in /usr/etc/ or dynamically linking /bin makes these benefits moots - but that would be Doing It Wrong.)
> 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-infr...
[1] I didn't want to write "idiots", partly because I actually respect what the systemd camp is trying to do.