damn. this one guy changed the world. if not for him, Linux would not have had those wireless drivers, and the downstream effects of younger teens being able to use Linux and then contribute to that ecosystem and and and.
.
Remembering Larry Finger, who made Linux wireless work
61–70 of 92 posts
Re: Remembering Larry Finger, who made Linux wireless work
#62Earlier quoted context omitted.
Is there some reason that the Linux kernel couldn't offer a stable API for device drivers? At least for common types of devices. Would that really lead to ossification? Stable APIs usually make it easier to change code at lower levels.
> Is there some reason that the Linux kernel couldn't offer a stable API for device drivers? Politics. Offering a stable-ish internal API would instantly lead to hardware vendors shipping closed source drivers for Linux. Currently, you have to be the size of NVIDIA or AMD to be able to afford a closed source driver, it's simply a huge work to keep up with the constant improvements in the Linux kernel.
Not true, there are smaller companies providing closed source kernel modules as well. Check any Android image for a device with SD card slot in the era where open source exfat driver didn't exist, and you'll likely find one of the 2 proprietary exfat driver modules.
Embedded/mobile projects don't tend to use bleeding-edge kernels and stuck on one version regardless of closed source modules anyway.
Re: Remembering Larry Finger, who made Linux wireless work
#63Rest in peace. I'm still rocking Linux on my MacBook Pro from 2012 which has a bcm nic in it. Thank you.
Re: Remembering Larry Finger, who made Linux wireless work
#64> Larry Finger, and fish, from his Quora profile.
The inclusion of the fish in the tagline made me smile. There’s an innocence to the sentence that captures the image really well.
Re: Remembering Larry Finger, who made Linux wireless work
#65Earlier quoted context omitted.
>Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. No, in practice I think it leads to growing complexity, because the system then adds additional APIs (e.g., v1, v2, v3, etc.) to support new features, but has to continue to maintain the old APIs for backwards compatibility, leading to lots of extra code and a huge maintenance burden.
Like winapi with its ...Ex and numbered functions (NdrClientCall4).
Or Linux with it's numbered syscalls (dup, dup2, dup3).
Re: Remembering Larry Finger, who made Linux wireless work
#66Wow, this is sad news indeed for the world at large, but also me personally. I'm suddenly in deep regret for having procrastinated reaching out the thank him. He doesn't know this, but he was somewhat of a mentor for me. In the early 00s I bought a laptop that had an RTL 8188 CE card in it that ran awful under Linux. I forked his driver and made a number of changes to it and eventually got my wifi working really well…
What things did you do that weren't legal to make your WiFi work better?
Re: Remembering Larry Finger, who made Linux wireless work
#67Wow, this is sad news indeed for the world at large, but also me personally. I'm suddenly in deep regret for having procrastinated reaching out the thank him. He doesn't know this, but he was somewhat of a mentor for me. In the early 00s I bought a laptop that had an RTL 8188 CE card in it that ran awful under Linux. I forked his driver and made a number of changes to it and eventually got my wifi working really well…
it's really nice to read comments like this one. thanks for sharing it. don't feel too regretful or guilty, things can happen.
Re: Remembering Larry Finger, who made Linux wireless work
#68Earlier quoted context omitted.
I've struggled philosophically with that very question as well (especially having to update my own WORKING code just to conform to API changes), and I'm very torn on it. I just don't think there's a good point to pick at which to "freeze" the API and say no more changes are allowed. It would greatly hamper innovation and IMHO ultimately lead the Linux kernel having major forks or being displaced by something more ada…
I've always wondered about how versioning could help. i don't think it would work with a monolithic kernel, but a microkernel might allow you to run multiple versions of different things, and they would still work. I've also fantasised about the same thing in application programming languages - e.g. the way racket runs loads of different dialects, you could also have versioning for different things running at the sam…
POV-Ray does exactly this, and warns you if you do not include a #version statement in your source file.
Re: Remembering Larry Finger, who made Linux wireless work
#69Earlier quoted context omitted.
> Even just keeping the driver compilable with each kernel release often took some non-trivial refactoring, I realise that the kernel contributors themselves are mostly volunteers and as such can just do what they want, and writers of non-upstreamed drivers will need to get used to chasing trunk, but to me this sort of thing seems like a waste of human talent. once something works, it should never not work again. it…
I've struggled philosophically with that very question as well (especially having to update my own WORKING code just to conform to API changes), and I'm very torn on it. I just don't think there's a good point to pick at which to "freeze" the API and say no more changes are allowed. It would greatly hamper innovation and IMHO ultimately lead the Linux kernel having major forks or being displaced by something more ada…
It not only makes it difficult to be a part time contributor, I imagine it also makes life more difficult for maintainers: before they accept a patch from a part time contributor, they always have to ask themselves "will this guy still be around to update his code when needed"?
Re: Remembering Larry Finger, who made Linux wireless work
#70Earlier quoted context omitted.
virtual machines exist, and it might be easier to run something in them than to port them every two years.
I'm talking about innovation and progress. In an ideal world retro computing remains a hobby.
Progress is in the eye of the beholder. Case in point: Fiddler. A debugging HTTP proxy, originally a one-man-show; the Classic version is still amongst the most powerful tools out there. Except...well...there's no way to monetize it. So, a New and Innovated version, which is less powerful (yes, it has some new features, but at the expense of dropping the actual power tools), more bloated, and subscription-based. Progress!