Gentoo developers start udev fork
h-online.com
h-online.com
> 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] 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.
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.)
[1] I didn't want to write "idiots", partly because I actually respect what the systemd camp is trying to do.