People keep making fun of the year of the linux desktop, but for me that year was distinctly around 2007 when wifi started working mostly painlessly on my thinkpad.
Remembering Larry Finger, who made Linux wireless work
41–50 of 92 posts
Re: Remembering Larry Finger, who made Linux wireless work
#42WiFi in the late 2000s early 2010s was a crazy place, man. Looking at the code it's wild how much he contributed to the process. Damn.
Re: Remembering Larry Finger, who made Linux wireless work
#43https://lwn.net/ml/all/77997185-86a6-41c5-af7a-74e4e9064437@... https://hkfuneralhome.com/larry-finger/
https://lore.kernel.org/linux-wireless/20240625103929.133292...
This has some serious GNU-Pratchett vibes - http://www.gnuterrypratchett.com and nice to see
Re: Remembering Larry Finger, who made Linux wireless work
#44Earlier quoted context omitted.
Your comment is rude and unhelpful.
I thought I wrote it nicely but I guess not I can’t think of a more powerful engineering endorsement than saying he did a Herculean effort to manually keep it all working Basically we’re all screwed now cause he was holding the whole thing up
This is a memorial thread, not a "rant about Linux WiFi thread". You're acting like a complete moron and asshole. This comment is the polite and sanitized version of what I would actually like to say.
Re: Remembering Larry Finger, who made Linux wireless work
#45Earlier 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…
Much of windows OS weirdness can be attributed to the fact they have a relentless dedication to backwards compatibility.
Much of Linux's weirdness can be attributed to that as well -- at least the userland API.
Re: Remembering Larry Finger, who made Linux wireless work
#46Earlier quoted context omitted.
Just accept the fact that software does age with time. If it didn't change a literal bit, the real world in runs for and the software ecosystem it runs on did. Any software older than 10 years should be rewritten from absolute scratch, not be kept on life support at ever increasing expense.
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.
Re: Remembering Larry Finger, who made Linux wireless work
#47Earlier 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…
Just accept the fact that software does age with time. If it didn't change a literal bit, the real world in runs for and the software ecosystem it runs on did. Any software older than 10 years should be rewritten from absolute scratch, not be kept on life support at ever increasing expense.
I would encourage you to read this if you haven’t: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
There are exceptions to every rule, re-writing old software because it’s old needs a rare exception indeed.
Re: Remembering Larry Finger, who made Linux wireless work
#48Wow, 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…
> 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…
The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value.
Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. Linus Torvalds spoke about this recently in the context of new Rust code in the kernel.
Re: Remembering Larry Finger, who made Linux wireless work
#49Earlier 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…
The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value. Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inab…
>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.
Re: Remembering Larry Finger, who made Linux wireless work
#50Earlier quoted context omitted.
The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value. Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inab…
>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.
Yes, precisely. The escalating complexity, maintenance burden and constraints eventually cause the whole system to lose momentum, lose support and become obsolete.