All software is broken in some way, so everyone says yes to shipping something that's broken. All things considered, it's not an important feature, especially considering it has a work-around. They have have the ticket for the issue and it's on a backlog. As with all software projects, they have to triage bugs, prioritize their work and allocate resources. The awesome thing about open source is that anyone can create a patch for the fix, and resolve it for everyone.
Compare this to some Apple Radar bugs that are old enough to vote, but only Apple employees can fix.
Key word here is community - it's not just up to the maintainers and regular contributors (who may already be overtaxed with both their day jobs and managing the software project for no pay). Users who have a particularly urgent itch to scratch have to step up - if they're not technical, perhaps put a bounty on the fix so someone else is financially motivated to fix it. Abusing (IMO) maintainers by screaming at them to hurry-up-and-fix-it is not helpful, especially since they are volunteering their free time.
Just to provide one anecdotal example, I have a Asus Zenbook Windows 10 laptop (OEM installed), where the touchpad just randomly breaks after some Windows updates every few years.
Right now my laptop isn't recognizing any multi touch gestures, which makes scrolling a pain in the ass.
I can't exactly remember what I did to fix it the last time, but it involved downloading some drivers from the touchpad manufacturers website (not the laptop vendor), which looked really dodgy. A non-technical user would have zero chance of getting it to work.
For a technical user such as myself, it would be much easier to recompile libinput with some patch I grabbed from their issue tracker.
As a bonus, there's less chance of getting malware from the latter than going to some Asian hardware manufacturer's poorly translated website in search of a compatible driver download.
(I'm referring to "Press the lower right corner of the touchpad to right-click" box. The Dells that the school I teach at has are near unusable with this clicked, but improve significantly with it off and using two-fingers to right click instead).
I've not had any problem before with clicks being misinterpreted this way, though.
I just timed myself doing it on a fresh vagrant VM, and it took me less than two minutes. One full minute was downloading and installing build dependencies, and that would normally be a few seconds as most people already have gcc.
The steps I took were:
sudo apt build-dep libinput
sudo apt install fakeroot
apt source libinput
cd libinput-1.12.6/
grep -r tp_detect
vim src/evdev-mt-touchpad.c
dpkg-buildpackage -b
sudo dpkg -i -O ../libinput*.deb
Free software often is free as in beer, but the real point is that we can, and we should, participate. Throwing money through GitHub Sponsors is one option, but often the best way is to just roll your sleeves up and do the work.
I thought that there were like a billion ways to do this -- pbuilder, debootstrap, fakeroot, sbuild, ./debian/rules, probably a few others I'm forgetting. Every time I've interacted with this over the last decade it's given me a headache.
In 2020, is `dpkg-buildpackage` the official way to do this? It seems very easy!
The other options are good if you need to ensure the package will build elsewhere, or if you need to cross build for a different architecture (which you might need if you're running a multiarch system and you need to patch a library like Mesa that's still needed by some 32 bit apps), or if you don't want to clog your system with build deps or something like that.
Last time I needed to do that, I used cowbuilder, but I'm not really an expert in this area, I'm just a Debian power user, not involved with the project directly.
Without the reference you've provided here I would estimate about three hours for me to do all of that, and that might be pretty optimistic. From figuring out what to search for, to understanding the code that needs to change, to making the change, to building it, to determining what's ~~best practice~~ at least not worst practice for installing it.
And I'm someone who's fairly confident in my abilities, has been using linux for about 15 years, and is comfortable in C and familiar with other packaging systems.
I'm sure I could come up with at least a dozen exercises like this that would take me under a minute but would take the average HN reader hours if not days to complete.
My point is that it's incredibly unfair to take something with which you're obviously quite familiar with and claim it takes less time than buying an app online, just because with experience you can do it that fast.
You're kind of right and kind of not. It is indeed incredibly unfair to claim that anyone can do it in 2 minutes if I could, especially considering that I did it this fast after mentally preparing to do it fast to demonstrate that it can be done fast.
But also remember that I really do believe that we should all participate in the development of the software that we get to use for free. Fixing a bug in some piece of software should, in my opinion, be the most normal thing you do every once in a while. Just like everyone can use a screwdriver at home, every programmer should be able to modify, build and run the software they use. If we did live in such a world, this wouldn't be specialized knowledge, this would really be something most people could do under 10 minutes.
Yeah, I realize that we don't live in a such a world. But please don't take away my hope that if we all try hard enough, one day we just might. :-)