3 ms·

I agree that this isn't an ideal user experience. On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your

I agree that this isn't an ideal user experience. On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your wallet and paying for another closed source macOS app. 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 Oh and I'm tempted to argue that this is, in fact, a user experience we deserve. ThinkPads are used by many developers worldwide. Most of my friends at Red Hat have it. Last time I could check (2011), Google gave developers ThinkPads with Linux as one of the options. Any single one of us could have fixed this bug in one day, and then spend maybe another full day communicating with Peter to get the fix in shape and merged. Yet it still isn't fixed. 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.

deleted 6y ago
[deleted]
EE84M3i 6y ago
Wow, I've never seen it so clearly described how to download/modify/rebuild/install a debian package before. 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!
- Liskni_si 6y ago
  There are a million ways to do it, but dpkg-buildpackage has been here for ages and if all you need is rebuilding a package for your personal use and for your current system and architecture and don't mind installing builddeps into your system, it's definitely the easiest. 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.
reificator 6y ago
> On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your wallet and paying for another closed source macOS app. 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.
- Liskni_si 6y ago
  > My point is that it's incredibly unfair to take something with which you're obviously quite familiar with and claim it takes longer 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. :-)
  - emj 6y ago
    Buying an closed source app has taken us in my family something like 1 month on avarage. It's all about how often you do it and how much goes wrong.

deleted 6y ago

[deleted]

EE84M3i 6y ago

Wow, I've never seen it so clearly described how to download/modify/rebuild/install a debian package before. 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!

Liskni_si 6y ago
There are a million ways to do it, but dpkg-buildpackage has been here for ages and if all you need is rebuilding a package for your personal use and for your current system and architecture and don't mind installing builddeps into your system, it's definitely the easiest. 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.

reificator 6y ago

> On the other hand, recompiling libinput in 2020 takes about as much time as taking out a credit card from your wallet and paying for another closed source macOS app. 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.

Liskni_si 6y ago
> My point is that it's incredibly unfair to take something with which you're obviously quite familiar with and claim it takes longer 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. :-)
- emj 6y ago
  Buying an closed source app has taken us in my family something like 1 month on avarage. It's all about how often you do it and how much goes wrong.