More generally, software is really, really expensive to produce and maintain. The economics only work at scale, in particular for B2C. (Maybe AI will change that, if it becomes more reliable.)
Imagine FAANG assigning $500 per engineer per year to allocate to feature / bug bounties.
You generally only need multiple people for timely action, and it usually even slows you down (from the perspective of total hours spent)
Like 2k bug bounty? I guarantee you some people would be willing to spend a lot of time for that. But yeah, people which are gainfully employed and have a decent salary - likely not.
The above back of envelope maths ignores the overheads of interacting with the people who posted the bounties to get them to agree to pay up, and of the cost overruns on the class of bugs that look like two day fixes but take two weeks.
Makes StarBucks barista pay look good…
Of course, if they can churn this out closer to 2 days, maybe there is something there.
Such a talented person would probably prefer a more certain and higher income.
I think the real blockers are the legal implications of reverse engineering.
Well, this would imply broken software. You already payed for the software, now you are required to pay to get bugs fixed? Bad optics, although not beyond contemporary sentiments... Inherently shady incentives: https://en.wikipedia.org/wiki/Perverse_incentive
This kinda only works best for FOSS, incentivizing external devs IMO.
After about a hundred back-and-forths getting the guy with the actual hardware to try different commands, I was thinking to myself man, maybe he should just give him remote access to work on the target PC, this is torture for both of them. And then I see him comment:
> Honestly I'm thinking of this and maybe something insane like organizing ssh access or something to quit torturing Nadim with building and rebooting all the time
And Nadim replies:
> Haha, sorry, but there's no way I'm giving you SSH access!
> I’m fine with continuing with tests!
Which is fair enough! But was funny to see right when I was thinking the same thing. Great perseverance from both of them.
Was slightly disappointing they they moved off GitHub to Discord eventually so after all that, we miss the moment of them actually getting it working!
Also, Lenovo Legion Pro 7* are not cheap (not that this would have been justified for cheap laptops).
Shame on Lenovo/<big company> who should have fixed this years ago.
It seems like there's a lot of personal information being asked for / thrown around... including a debit/credit card number?
Is there no better way to handle the bounty payment?
> Approximately 95% of the engineering work was done by Lyapsus. Lyapsus improved an incomplete kernel driver, wrote new kernel codecs and side-codecs, and contributed much more. I want to emphasize his incredible kindness and dedication to solving this issue. He is the primary force behind this fix, and without him, it would never have been possible.
> I (Nadim Kobeissi) conducted the initial investigation that identified the missing components needed for audio to work on the 16IAX10H on Linux. Building on what I learned from Lyapsus's work, I helped debug and clean up his kernel code, tested it, and made minor improvements. I also contributed the solution to the volume control issue documented in Step 8, and wrote this guide.
I'm not willing to pay $1000 for a fix (it's easier for me to buy a new laptop that will work with Linux), but $100 is probably okay. :)
It's funny, but for as long as I can remember Linux (20+ years), there have always been some problems with sound.
I have a couple old-ish Samsung Galaxy Book x86 tablets that have a similar issue, that I have never quite goaded myself into trying to reverse engineer. I'd love some better material on trying to reverse engineer windows drivers: presumably maybe running windows in qemu with some kind of intercepting pass through?
Outsourcing this work to outside developers on the regular probably would make the media claim something like "Lenovo is too lazy to pay their people to make their speakers work so they make strangers on the internet do it instead" which isn't half false.
It'd probably be better and cheaper if they'd just hire someone to make their speakers work on Linux.
Good suggestion, but I discovered that React was not able to fix my Linux kernel, either, for some reason.
Hal3000: "Great request—here is your React version 20XX* TODO list"
*20XX is a year+ old version of React
Lenovo may not be as friendly as IBM to its opensource.
Still, I didn't expect this amount of custom configuration for my new laptop. Most importantly Bluetooth sound and getting Nvidia driver support. For Bluetooth I ended up writing my own tiny daemon. While driver support exists there seems to be a race condition somewhere between Pipewire, systemd and the bluetooth drivers. And for Nvidia drivers I ended up using the CUDA driver repository which is curiously only available for Debian 12.
Are they stupid or is just all a big lie?
I remember going for the highest paying bounty in the Ethereum VM several years ago (I think it was ~$400 DAI/SAI). I did it because I wanted to force myself to learn the internals and to see for myself if the bounty system works. I think I spent a few weeks debugging and ended up splitting the bounty.
As long as the user-facing issues are disconnected from the technical issues, it's going to be hard to get the true value.
I don’t have this laptop but have built kernel modules in the past to give context. It’s a tiny step to publish this as a kernel module so end users can trivially install this (this reduces the instructions to downloading one file, running one command, with no reboot or rebuild needed) so it’s quite reasonable to call this out and ask someone to do it.
It’s a bit like publishing a windows driver as raw source code. Great work but there’s no reason not to ship the prebuilt driver right?
I don't think you have to be the original developer to create packages one can distribute. Go for it!
From TFA:
> This guide is currently for Linux kernel version 6.17.8. It will be updated for future kernel versions as they are released, until the fix is fully integrated into the kernel.
So it sounds like the plan is to get it into the mainline kernel, at which point it will get to all the distributions. So I sent see the problem here.
