
Gentoo developers start udev fork - mercurial
http://www.h-online.com/open/news/item/Gentoo-developers-start-udev-fork-1752421.html
======
qznc
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-
infr...](http://thread.gmane.org/gmane.linux.drivers.video-input-
infrastructure/49758/focus%3D1368822)

------
mercurial
Don't miss the link to Greg Kroah-Hartman's G+ page [1], it's pretty funny.

[1]
[https://plus.google.com/111049168280159033135/posts/R387kQb1...](https://plus.google.com/111049168280159033135/posts/R387kQb1zxc)

~~~
ChuckMcM
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
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
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
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.

~~~
secure
See
[https://wiki.archlinux.org/index.php/Configuring_keyboard_la...](https://wiki.archlinux.org/index.php/Configuring_keyboard_layouts_in_X)

Also, why would one ask mjg (who doesn’t do X11 stuff AFAIK) instead of
googling? :-)

------
mseepgood
Probably the best explanation of the situation (found on reddit)

[http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_...](http://www.reddit.com/r/fossdrama/comments/13il1o/gentoodev_can_get_pissed_on_everything_from_names/c74e7n7)

~~~
nitrogen
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-...](http://blog.martin-graesslin.com/blog/2012/02/having-a-look-at-the-
oldnew-desktop-environments/)

~~~
qu4z-2
"[...] 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
My read on it is he's saying that KDE 3.5 isn't great on older hardware
either, so what's the point?

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

~~~
nitrogen
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
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
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.

------
oofabz
>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
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
<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
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>

~~~
oofabz
Yes, that is what I'm saying.

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.

------
bishop_mandible
This is fun: <http://twitter.com/mjg59/status/270323838468890624>

~~~
nitrogen
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
Because glib is a decent library of data structures and algorithms that will
just need to be reimplemented.

~~~
steevdave
Also, glib != glibc

~~~
adestefan
Bah. Poor reading comprehension.

------
zokier
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.

