A Vast Majority Of Linux's Input Improvements Are Developed By One Individual

[schmidtbag]

that's how you would run company, not how redhat works. redhat hires experts, not tells people what to do. btw this is why only moron would accuse redhat of developing something. when redhat is left without btrfs devs, redhat switches to xfs

Exactly my point... They hire experts. They're not going to put someone in Hutterer's position who doesn't know a thing about what they're doing. That's why if whoever they do hire doesn't know what they're doing, they have the resources to find someone else. How are you not getting this?

[pal666]

Having those things 'thanos-snapped' out of existance would be an overall improvement for enterprise/server Linux (eg, for headless VMs that never run a UI other than bash)....

some windows or macos idiot's dream

[pal666]

fixed

broken. both ways: gnome is developed by not only redhat and redhat develops not only gnome

[pal666]

Sure they can, because otherwise that person is fired or put elsewhere.

that's how you would run company, not how redhat works. redhat hires experts, not tells people what to do. btw this is why only moron would accuse redhat of developing something. when redhat is left without btrfs devs, redhat switches to xfs

[schmidtbag]

it doesn't work that way. redhat can hire someone who has made himself replacement, that's all. redhat can't tell someone to become replacement

Sure they can, because otherwise that person is fired or put elsewhere. Hutterer's replacement needs to know how to maintain libinput and such, and if he/she can't then someone else will have to. That person being a complete replacement isn't happening overnight, but, he can be replaced if necessary.

[c2p_]

The guy needs some dang help with laptops for testing. He doesn't have nearly enough of them as far as I can tell. libinput being nearly a one-man show is kind of ridiculous.

A lot of open source projects are one-man shows (remember openssl? but that was 2-man if I remember correctly). This is ridiculous that some fundamental things are so underfunded, when others earn millions.

[starshipeleven]

No Redhat no GNOME. People need to remember this.

fixed

[Mike Frett]

Scary stuff. Since it's open source and no one else is apparently interested...let's hope nothing happens to him.

[cacarr]

The guy needs some dang help with laptops for testing. He doesn't have nearly enough of them as far as I can tell. libinput being nearly a one-man show is kind of ridiculous.

[arQon]

With no Red Hat and its employees, half of the current Linux userspace wouldn't exist in its current form (gnome, wayland, systemd, dbus, colord, NetworkManager, polkit, sssd, packagekit, kvm).

And about half of that wouldn't actually be a loss - just like half of the xinput changes wouldn't be.

Hutterer is a perfect example of the Red Hat mentality: this is someone who broke the hell out of mouse acceleration in X, unilaterally. Don't get me wrong: it WAS already broken, no question, and the code was terrible - but the new LOGIC isn't really any better, and there was no discussion of it and no attempt to get a result that was even remotely close to what it had been for over a decade. Just "here's some random behavior that I pulled out of my ass, here you go", with the resultant code being utterly unusable with anything other than garbage-tier mice, because the acceleration on anything with a sample rate faster than about 50ms or with more than 50 CPI is INSANE.

In fairness, he did at least add a way to hack xinput to try and deal with that, but it's clunky as hell. To this day, I have multiple machines where the mouse is literally unusable without "xinput --prop-set etc etc etc" hacked into /etc/.bashrc of all places.

As someone who's had to suffer through writing xinput code, I can certainly agree with zanny that the documentation is borderline useless, and the API is absolutely terrible. The only place half of it is actually "documented" is in his @#$%ing BLOG, fgs.

So yeah, it's not great that he's the only xinput developer, and not just because that's not a good place for a crucial system to ever be in. But that's the Red Hat way of doing things: produce something in isolation, and say "Here, deal with it". They're no different than Canonical in that regard, and often much worse. So while I sympathise with Hutterer's predicament, you don't get to complain about how you're on your own when you (or in this case, I assume "your employer") decide that's how you're going to build the thing in the first place.