Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.os.linux.misc Subject: Re: AI Is Killing Some Legacy Hardware Support Date: Thu, 30 Apr 2026 23:41:42 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10t0pbm$f86$1@reader1.panix.com> References: <10sbn6f$2kkkk$8@dont-email.me> <69f28e2d@news.ausics.net> <69f3dd7c@news.ausics.net> Injection-Date: Thu, 30 Apr 2026 23:41:42 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="15622"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.os.linux.misc:86048 In article <69f3dd7c@news.ausics.net>, Computer Nerd Kev wrote: >Richard Kettlewell wrote: >> In short, yes, if what you want is old hardware then you are going to be >> constantly experiencing decline in support for it in modern software. > >This does not surprise me. In your terms all I was proposing is >that Linux support appears to be declining now faster than BSD, and >I believe that warrants my investigation. I was vaguely hoping for >a response like "yes I see the BSD I'm using fixed a similar issue >in driver x and has a group of people working on supporting >PCMCIA", or even "no way, all the BSDs never had those drivers or >dropped them years ago already" (I've since confirmed they do at >least still have a driver for my Xircom PCMCIA ethernet card that >Linux is dropping). Instead I got all these "duh, your hardware >must be from 30 years ago and useless anyway so who cares" >responses. Ho hum. One might read the situation that way, but I think that's not a great way to look at it. A better way would be that, of the set of people who are doing maintenance on the Linux kernel, none have are supporting that hardware. It may be that they are not because they don't have access to it, or it's not a priority for them, or something else entirely; the details don't really matter all that much. The effect, however, is that they've decided to remove that software because no one is maintaining it and they're otherwise drowning in the review load for AI slop patches for it. The BSDs may continue to have support for those devices; it may work, it may not. You are more than welcome to try it and see for yourself. >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3c26ea81ccc522e77ed0b1707add61fc9206216 >> >> That's a revealing one to quote: >> >> | The i82092 driver has almost certainly not been used in over 20 years. >> | It was broken by a null pointer dereference since the dawn of Git >> | history (2.6.12-rc2 in 2005) until someone fixed it in 2021 in commit >> | e39cdacf2f66 ("pcmcia: i82092: fix a null pointer dereference bug"). >> | From their dmesg log [3], it is clear they were testing in an emulated >> | environment and not on real hardware. >> >> i.e. one of the drivers went a minimum of 15 years with nobody noticing >> that it was broken. Some of this stuff was already unmaintained to the >> point of being broken 20 years ago or more. > >Though The Xircom driver was working for me and they're removing it >now, so I _know_ they consider useful (to me) drivers for removal >too and the significant thing is they are considering all the >PCMCIA drivers "almost completely obsolete", so the problem for me >is likely to get worse. > >Plus I guessed (maybe ignorantly) they'd drop common 1990s PC >hardware drivers while keeping drivers from 2000s for a decade >after doing that. But if "~2009" is "almost completely obsolete" >that means their idea of "obsolete" has overtaken mine and >therefore I might be using the wrong OS. (yes I know the reasons >why they might define obsolete differently, including developer >resources and funding, in the end that doesn't really matter to >me _if_ the BSDs turn out to be different) Well, you could also roll up your sleeve and take on maintaining the driver yourself, and attempt to get them re-added to the kernel. It's not that they're not willing to accept them, it's that no one was willing to support them. But if you step up and do it, there is no structural reason they would not re-take the code. >> (AFAIK the Linux kernel handles null pointer dereferences quite well so >> this was probably just an availability bug rather than any kind of >> vulnerability.) >> >>> Yes I get your point not to complain about what you get for free, but >>> like I say the BSDs have the same price tag, and if Linux starts >>> forcing me to spend time and money on upgrading to new (old) hardware >>> every few years (or more money buying brand new hardware to get driver >>> support for longer) when my old hardware still runs all the >>> application software I use, is it really free for me? >> >> The point is not so much about complaining, nobody can stop you doing >> that, but about the realistic expectations about maintenance and, in the >> longer term, availability of drivers for very old hardware. If what you >> want is ancient hardware then you get to deal with the consequences of >> that, and those consequences are (at least very broadly) predictable. > >I _could_ use all your reasoning to predict that the very moment a >model of PC hardware device goes out of production and all the >associated manufacturers are no longer contractually or legally >obliged to support it, support will be removed from the Linux >kernel, at least once the first new bug is discovered. That clearly >has not been happening as a rule so far, or all these drivers would >have been dropped already decades ago. I would go out and buy new >hardware all the time pointlessly based on that. Much smarter to >look at what's actually happening, and my point is that this >includes looking at BSD too. You could, but that would be a specious conclusion. Support has little to do with what the manufacturers do, or legalities, or what not, and a lot more to do with developer resources and availability of hardware for testing and support. >> The BSDs are maintained by different people with different priorities, >> so the outcomes are likely to differ. But they do face related >> pressures, and they do sometimes remove functionality for various >> reasons. >> >> For example here's a PCMCIA driver being removed from OpenBSD in 2020; >> it was broken and (I infer) nobody was sufficiently interested in it to >> fix it. >> >> https://github.com/openbsd/src/commit/1f9d569892d2e153e862c87145e03403415b4ee0 > >OK thanks, that's an interesting point of data, but unlike with the >Linux removals it's not obviously tied to claims about what PC >hardware the developers consider obsolete, or a broader project to >remove PCMCIA support entirely. Really it's the working drivers >being removed, like the Xircom one, that I care about, and Linux >just happens to have started with broken PCMCIA drivers before >moving on to them. Maybe the BSDs will do that too, it's what I >intend to investagate. So far that "esp" driver still seems to be >in NetBSD, working or not, FWIW. The case with Linux and the OpenBSD removal are really two sides of the same coin. If nothing else, OpenBSD is _more_ aggressive about removing working code than Linux is; they're proactive about pruning their tree when they don't think they can maintain something for whatever reason (lack of hardware; lack of people; etc). Same with Linux. Also, it's not merely about whether the drivers work for your use case, it is also whether or not are kept up to date as the kernel evolves. No new laptops have shipped with PCMCIA slots in ~20 years; it may all still "work" but if the people doing the development and maintenance can't get equipment to test with or build on, or if all the documentation disappears into the void because a company folded, then it is simply more likely that that hardware will eventually lose support. Them's the breaks. The best way to ensure that does not happen for hardware you care about is to do the maintenance yourself. - Dan C