More ancient Linux device support faces the chop One tactic to deal with LLM-powered vulnerability detection is simple – just speed up the removal of old code. If it's gone, it no longer matters if it's buggy. Bot-powered bug-busting is in the news of late, with scary-sounding reports of automated tools detecting flaws and vulnerabilities far faster than any unaided humans. …
as the old code will be in modules that are only loaded if the device is installed in the system. No device means no old code means little worry about old bugs.
Do not get me wrong: removal of old cruft is a good idea but do not expect vast bug reductions as a result.
A side benefit is that kernel maintainers will not need to waste time on unused code which means more time for what we actually use.
Agreed, but so much for Linux being for hobbyists (at least non-kernel-guru hobbyists). Sometimes the easy route of trash it instead of fix it leads to tears of regret later. As mentioned in the article I still have plenty of 3C5XX cards in the bone pile. (not that I have immediate plans to play with them, but...)
Old kernels are an option now, but old kernels now is synonymous with "unavailable in the future" -- unless you build your own. Very few actually go though the full process of "Linux from Scratch". (and granted, building/installing an older kernel on a running system is a fraction of the full manual effort, but it's non-trivial. Splitting the removed modules out as separate optional modules, regardless of whether they are actively maintained, would at least leave a defined path to make use of them in the future without any one hobbyist having to manually merge the driver.
It's likely the accelerated removal will go largely unnoticed and I hope that is the case, but I have misgivings of hacking branches off the kernel tree. More an unease than any of the mentioned removals I could point with a use-case that would argue against removal. You never need it, until the week after it goes out in the trash. Costly lessons from Murphy's Law abound.
"unavailable in the future"
Assumes facts not in evidence.
There are far too many individual archives for them to go away entirely. I rather think we'll be stuck with all of them in any number of archives long after the heat-death of the Universe.
Yes, I know, a few of the extremely early kernels have evaporated, simply because Linus had a small HDD at the time.
What about dependencies? Old kernels will eventually limit you to old packages as they move past the sell-by date unless you are willing to try to tackle manual upgrades of modules, and that isn't for the fainthearted.
If I remember correctly, an early work laptop I was given had a dual-port Xircom PCMCIA card, supporting (via dangly adaptors) ethernet on one side and 1200-baud modem on the other. And yes, they worked under Linux. After the laptop was declred obsolete, I took it home, rather than tossing it in the official skip.
> a dual-port Xircom PCMCIA card
Xircom did some amazing stuff.
The RealPort cards worked either way up and you could fit a pair at once.
https://www.ebay.co.uk/itm/273777849904
And no dongles -- full size ports on a card a few mm thick.
Its Portstation modular USB dock let you add and remove ports ad lib.
https://docs.rs-online.com/8350/0900766b8002d629.pdf
And it even offered USB drivers for Windows NT 4, which did not support USB at all!
NT first got native USB support with Win2K in the year 2000.
There were drivers for USB that ran on NT4, but they were problematical (to say the least). Who remembers fighting with Dell's 'orrible R62200 attempt? Or perhaps "USB for Windows" from BlueWater Systems? Or maybe y'all have managed to patch the ol' memory to forget select parts of that era. I hear ethanol works for some ...
Win95 had USB support by OSR2.1 in 1997. For rather small values of support.
Win98 had (some) built-in support, in (surprise!) 1998.
> So it didn't arrive until Win98 and Win2000Pro?
Others have clarified this well, but yes, broadly. It didn't arrive *AT RETAIL* 'til Win98 and Win2K.
Windows 95 as shipped did not include FAT32, or USB, or a web browser.
OEM Service Release 1 added Internet Explorer.
OSR 2 added FAT32 and USB and IE2.
OSR 2.1 added IE3.
OSR 2.5 added IE4.
But the point is, you couldn't buy them and there was no documented official way to upgrade: they were clean-install only releases. A big hindrance was that there was no way to convert a FAT16 drive to FAT32. (Except PartitionMagic!)
NT4 never supported FAT32 or USB. At all. There were 3rd party efforts to add them on.
Only with Win98 could you go buy something that would upgrade your PC.
You could of course at first _buy_ the Plus Pack to get IE, and later, download it for free.
I worked at PC Pro magazine and Microsoft let us put the IE installers on our cover CD. We asked Netscape for Navigator or Communicator. It said no. It wanted direct downloads so it could track adoption.
My editor attempted to explain that it was an expensive download. The Californians didn't get it. I (as de facto technical editor) had to spent half an hour on the phone to the West Coast explaining to profoundly ignorant Netscape staffers -- progressively more senior ones as the call progressed -- that in Europe, local calls were metered, and so dial up internet access cost money. They had no idea. They just assumed everywhere worked like the US. They kept insisting I was wrong because calling your ISP was a local call and they were free, and that I did not understand that users were not phoning Netscape internationally to download the browser.
I had to keep explaining, in less and less tech detail, that in the UK and Ireland WE PAID FOR LOCAL CALLS and that meant were were PAYING TO CONNECT TO OUR I.S.P.
When it finally got through to them it blew their minds. There was shouting and scurrying and calls to get board members into this meeting NOW NOW NOW we don't CARE what they are doing WE NEED THEM HERE *NOW*.
By the end of the call, they understood, and were terrified and now realised why MS allowed physical media distribution and why we ran cover disks and why shareware didn't work in Europe and why there were so few downloads.
By the next day we had permission from a deeply shaken and scared Netscape Inc. to put both Netscape Navigator (the browser-only product) and Netscape Communicator (the full fat client with email, address book, calendar, and web page editor) on our cover CD.
Reminds me when at one outfit new CTO took complaint of developers to heart that there appears to be a lot of dead code nobody knows anything about that appears to be not used.
The cohort who developed that "dead" code was long gone.
They decided to put it on chopping board.
Then few months later panicked person from accounting wrote email that the reports they urgently need are not working.
Company was unable to publish accounts on time.
Code was entered back in.
While, in the technical sphere, I've clearly been shifted from "deprecated" to "obsolete", I'm slightly more concerned about the equivalent meatspace process in which medics are chopping drugs off my prescription list because death is now more imminent than eventual harm from chronic conditions...
Ah remember mekkin' me own transistors aht o' warm gravel and a cat's whisker. Weren't a cat wi' a whisker left fer three mile round by t' time ah'd got t' ALU workin', heh!
'ey, lend us a fiver fer a couple o' crack BuzzBalls will ye? Ah'll pay yer back next week...
The issue is how old versions of the proprietary Nvidia Linux driver was not modified to support newer versions of Linux, rather than Linux's fault.
Although I guess the Linux developers are partially to blame for not enforcing their license and requiring that Nvidia make available the source code under the GPLv2 or a compatible license.
Although, you can use the free Nouveau driver instead.
Nouveau in the latest Linux supports Fermi, too bad there is no reclocking support.
Er, you clearly don't know the terms of GPL2, or anything about how Linux deals with driver modules of differing licenses. Anyone is perfectly free to load up a propietary module, it just can't link to symbols from other projects exported with EXPORT_SYMBOL_GPL().
If someone started pre-packaging a Linux distro with Nvidia's drivers burned in and distributed it, then in theory the recipient could insist on also receiving the source code (anytime in the next 3 years) but may be charged a reasonable fee for the media and postage, and the Linux kernel copyright holder can claim breach of copyright against the distributor. Distribution is the key aspect; if it's not distributed, then all's fine and above board, and perfectly within the expressed wishes of the kernel copyright holder.
And to be honest, it's not entirely clear that distribution in itself would actually trigger anything. Ubuntu have taken the plunge and distribute ZFS (which is not GPL2 licensed) with their Linux, and apart from some puritanical squeaking from some there's not been any actual consequences. Linux already includes and distributes a vast store of proprietary firmware, and no one objects to that. It's seems clear that - when it in everyone's mutual interests - pragmatism breaks out and they just get on with it.
Having said that, the Linux kernel project does make life difficult for themselves as well as others, by not having a stable drive binary interface. Other OSes have long sinced learned that the way to accommodate the vast selection of available hardware is to make sure that device drivers are efficient to write and maintain. The problem created by the Linux kernel project is that every time they change that interface, they then have to update all the drivers they've accepted into their tree and everyone else does too. That's not an efficient use of their time, or anyone else's.
The concept of a symbol somehow being non-GPLv2 is ludicrous - but of course the Linux developers just needed to allow proprietary modules.
Many GNU/Linux distro's distribute nvidia's drivers - it being done at a later install step over the internet makes no difference whatsoever.
As per the GPLv2, any distribution of derivative works of GPLv2 software in object code form, that doesn't include either the source code, or a written offer for source code, results in the license being automatically terminated, permanently, even if the source code is indeed available and a written offer wasn't included by mistake.
As for ZFS, as usual the Linux developers have chosen to not enforce their license - as well if they did, they'd have to point out that Ubuntu's license to distribute and/or modify Linux has been permanently terminated, as all current CDDL versions are incompatible with the GPLv2.
It seems the main reason why the Linux developers choose to tend to not enforce their license, is because they violate their own license and permission to distribute and/or modify has been terminated permanently long ago - the plan seems to be keep piling on more proprietary software until ????.
It's clearly not in anyone's interest, or the slightest bit pragmatic to keep letting such proprietary degeneracy fester - it will eventually kill Linux dead - as projects that can't keep their licensing in order, or upgrade license versions, are doomed to die.
The only GPLv2-compliant version of Linux I'm aware of is GNU Linux-libre - as all the proprietary software and references to proprietary software has been deleted prior to distribution - it's actually GPLv2 and a few other compatible licenses.
The whole idea of the non-stable driver ABI is to force in-tree development of modules - which frankly would be a lot more effective to enforce via enforcement of the GPLv2.
I guess that on the assumption that most Linux developers are using Linux as a desktop and likely have an NVidia GPU installed, most Linux developers are tainting their own running kernels.
Also, the copyright for Linux is not held by any one single individual (corporeal or corporate). The EFF does not hold the copyright, and cannot by itself just kick off a case; the actual copyright holder has to be involved. I strongly suspect that most don't care to get that involved in legal issue.
>The whole idea of the non-stable driver ABI is to force in-tree development of modules - which frankly would be a lot more effective to enforce via enforcement of the GPLv2.
If that is the reason, it's somewhat problematic. There's all sorts of rows about code in the tree - style, quality, etc. Look at the fuss there was initially about Paragon's NTFS driver (which was being given to Linux for free, but didn't fit the established coding styles). There's other sorts of politics; look at the fuss over the use of Rust. And at the end of the day, someone from outside cannot force their code into the tree if the insders don't want it there. The pull request will simply get ignored.
So the way the project overall behaves and is set up means 1) it's far from guaranteed that one's efforts will be accepted by the kernel community, and 2) they make it hard for one to be fully independent, working to an ABI (because there isn't a stable one).
Companies like Intel have tried to play nice; contributing USB drivers (there were arguments about those), and drivers for Intel graphics. Now, Intel has withdrawn; no more coding effort from them. Where Linux used to rely on "at least the Intel GPU driver will work on this machine" safety, that's going to go away... If Linuxers find that getting a desktop of any sort running starts to become harder and harder, maybe that's what'd driver a change in the project's outlook. It's similarly hard in Android mobile phones. There, Google has introduced a shim translation layer to isolate actual driver code from the prevailing driver ABI. That way the "drivers" can remain the same even if the kernel (+ the shim) gets updated. The Android spin on Linux is effectively fully proprietary; you can get source for bits of it, but not the whole thing. Then there's the RedHat angle too. Their spin on Linux is now essentially fully proprietary. Sure, you can still ask for and receive the code if you're a paying customer, but if you ever dare distribute that source code then they'll decline to sell you the next version.
Firstly, I would hazard that quite a lot of Linux developers are actually using laptops with Intel graphics. Secondly, you don't need the proprietary Nvidia driver, so anyone who cares and is, well, developing instead of trying to run games on Linux can probably quite happily use Nouveau.
Having said that, the Linux kernel project does make life difficult for themselves as well as others, by not having a stable drive binary interface.
I was just about to post my semi-annual long rant about this, it's nice to see I'm not the only one.
Linux doesn't really have drivers, it has code that deal with controlling hardware, which can optionally be dynamically loaded.
If it had a stable, versioned, documented driver interface then the issue would be somewhat different.
(It would also mean manufacturers could release drivers to that interface; rather than having to recompile things every time the kernel changed).
But it's also an easy way to make things less GPL, so would never happen. :(
I don't personally think it's something that linux lacks, more that it's something that linux probably could never really have, as it would require a lot of effort that would offer the most benefit to those who don't agree with the GPL ethos of the kernel. That's probably more a barrier to a decent driver interface than anything else. Who in their right mind would spend the effort of defining it, pushing it through, and keeping it current with all the attendant criticism and push back that would entail? Plus, you'd need buy in from all the parties involved. Microsoft and Apple control the kernel so can define these interfaces unilaterally.
However, it would help.
I also think it's the reason for things like Fuscia. There is a lot of wasted effort in companies around the world keeping drivers up to date for linux. it's always felt like there's a long term plan to ditch it at the core of Android.
> ATM isn't a competitor of TCP/IP.
It was pushed as the primary mechanism for WAN and MAN comms in the late 1990s, and it not only competed with everything from ISDN to ADSL to SONET, it also competed with network protocols like TCP/IP.
Example:
https://www.theregister.com/1998/11/16/cable_wireless_unveils_1_billion/
> At some point, it was touted as an Ethernet competitor for LAN,
It was but not only that. It aimed to be the entire network, from LAN to metropolitan area.
When IP started to fight back it was headline news:
https://www.theregister.com/1998/11/17/ip_to_displace_atm_says/
Sorry, but you remember it totally wrong. ATM *was* the future of networking. All wired networking.
My memories largely match yours, it was my post which was too concise. I knew ATM was designed for backbones. Heck, back then, our professors drilled into us how the small size of its frames allowed for lower latency, at the cost of higher overhead, because of the need for fragmentation when it was used to carry bigger-packeted protocols and thus a noticeably higher percentage of the bandwidth used for headers. My meaning was that touting it for LAN was straying too far from what it was designed for,
However, I'm still confused by your used of "IP", both here and in the article. Was it a shortcut for "IP over Ethernet"? There were ATM NICs, there are Ethernet NICs, but there aren't IP NICs, that's what I mean by writing ATM wasn't an IP competitor: ATM was used to carry other protocols, including IP. It sure isn't the future of networking now, but in 1998? It totally was. What El Reg didn't foresee in those articles back then: it would come to be what was used for the ADSL revolution around here. Only a few years after those articles, and for a couple of decades thereafter, my IP packets exited my home over ATM. And if I'm still being pedantic about it, it's because how the difference between the ATM and IP bandwidths was an actual thing during those decades (the ISP were selling the former, higher number, while subscribers only saw the latter in real-life use - because of the overhead I knew about since it was drilled into me). So the "IP replaced ATM" shortcut is a little weird when I had to deal with both together for such a long time, until not so long ago. I'm all on fiber now, so I probably won't remember any of this once we roll over in the '30s :)
https://www.freenews.fr/freebox/explication-debits-ip-ou-atm-quelle-difference-13934
There's a kind of affinity between Ethernet and IP. IP assumes a packet switched network exists underneath it, and that's what Ethernet (and much of networking today) provides. TCP is a layer that provides nice, reliable, ordered data transmission over such (potentially chaotic) networks.
ATM sets up a virtual circuit, and in that sense it is already providing a reliable end-to-end data transfer. Looked at this way, adding TCP/IP on top is not necessary for making the connection reliable, it's just wasted overhead.
Here in the UK with BT's System X (which was a masterpiece for its day) was also a thing. That too was circuit switched nationally, and was capapable of providing huge bandwidths across the nation with guaranteed delivery. I don't recall anyone ever hooking a computer up to that directly for the purposes of WANing, but it had the potential to be "the network we use for everything (wired).".
Had the world gone down the route of ditching Ethernet and adopting either ATM or SystemX, things like video streaming could have panned out very differently. Today, it's all http over tcp. But some of the protocols being created nowaday by Google, etc. feel better suited to networks like ATM (or at least, they'd be far simpler and more effective if ATM underpinned data transfers).
> I'm still confused by your used of "IP", both here and in the article. Was it a shortcut for "IP over Ethernet"
No. It's a shorthand for TCP/IP.
I know that TCP/IP is a network protocol and ATM is not -- it's also a hardware spec as well as software -- but that's the nature of the computer world. Sometimes radically different technologies that do different things end up competing.
The OSI 7-layer model was always a work of idealised fiction. Real systems gaily switched or merged or omitted layers.
Before TCP/IP came to the desktop, different OSes used on business and organisational and educational LANs all ran different protocols. OS/2, DOS and 16-bit Windows tended to use NetBEUI. Novell setups used IPX/SPX. Macs used AppleTalk. Acorns used Econet. Banyan VINES used XNS. HP printer servers used DLC. Etc. etc.
Some used RS432, some ArcNet, some their own standards.
But gradually most shifted to 10Mb/s Ethernet as a lowest-common-denominator, cheap enough good enough physical transport for small LANs. IBM shops used Token Ring but while it scaled better it was slower _and_ more expensive.
So ATM was competing against ($WHATEVER protocol over 10Mb/s Ethernet).
However fragile 10base-2 coax Ethernet switched to more resilient, physical star architecture, 10base-T UTP Ethernet. Once all the cables plug into a passive hub it becomes easy to upgrade just that grey box to a switch. Suddenly Ethernet's scaling problems were alleviated. Very soon afterwards, within a few years, 100base-T UTP Ethernet started spreading. With switches it scaled all right, and switches fell in price rapidly.
ATM tried to do the whole stack, from your PC to the wall to the LAN to the WAN to the MAN, hardware and cabling and software.
It was competing against a whole thriving incestuous cannibalistic mob of software standards and cabling standards.
The point being that this kind of environment, with competition and rival pricing, drove evolution faster than rigidly controlled vendor standards.
As plain old cheap switched Ethernet over cheap UTP got good enough and cheaper than anything else, the WWW and Internet standards-based email took off. All those other protocols gradually got TCP/IP added as well, and then the proprietary protocols faded away, and by about a decade after Windows for Workgroups brought both client-server and peer-to-peer networking to the industry standard PC client OS, all the other protocols had largely gone away, replaced by IPv4. On LANs over Fast Ethernet. On WANs over ADSL and SONET backhaul.
ATM was something built by and for voice telephony companies envisioning dedicated data services like videophones and things: making a big switched point-to-point packetised network that scaled down to the desktop.
Its backers didn't realise they weren't competing with any one system or standard, but a hodgepodge of whatever was cheapest and easiest and just did the job... as the list of jobs shrank down to one lowest-common-denominator system that ran whatever else layered over the top in software.
So, yes, IP means just the software protocol, the visible layer of a whole mishmash of stuff that interconnected Fast Ethernet IPv4 LANs over messy bodged links carried over phone lines and NAT.
It's as good a label as any. There isn't really a better.
My memory of those years is a little later, at university, when one of my professors spent a lot of an introductory networking/telecom course hyping inexpensive, switched, gigabit ethernet, and how everything else would very shortly be utterly obsolete, including most of the more arcane things still mentioned in the course content - and so obviously pointless to spend too much time on to learn with any depth during the course. This must have been 1997 or just possibly 1998 timeframe - I wouldn't bet my life on the timing.
Ethernet has - kinda - won.
In the military equipment space (VITA, OpenVPX), it's now all Ethernet interconnect within chassis and outside of chassis. They used to have Serial RapidI/O which - when new - significantly out-performed Ethernet. It had switch chips, and the DMA data transfers one could do between cards were pretty low latency and plenty swift (GByte/sec sustained, no trouble).
The reason why it's now all Ethernet is not so much cost (well, it is cost), but market size. The cost now to develop a competitive switch chip is $billions x lots. The size of the military equipment market (for radar processors, electronic warfare systems, etc) simply isn't big enough for the market to fund the development of their own switch chip for their own network standard. What's also helped is that today's CPUs are true monsters, compute-wise. Whereas in the old days a computation had to be spread out across a chassis full of CPUs (necessitating a low-latency, high speed data transfer network such as Serial RapidIO), a modern CPU can swallow the whole problem in on singular gulp and have CPU cores to spare (removing the need for low latency transfers between boards). So instead, they now put in large Ethernet switch chips and run parallel Ethernet lanes between boards to get vast bandwidths (albeit at Ethernet-like latencies) between boards. It also gets rid of a whole software layer.
Ethernet is not everywhere though. The Japanese super computers K and Fugaku have Tofu - a CPU to CPU data transfer network that is wired in up (I'll try and get this right) in a 6-dimensional hypertoroidal interconnect interwoven with a 4-dimensional hypercube (= every node is connected to a lot of other nodes), and that gets huge bandwidths at low latency and Ethernet cannot match it. There's no switches, which helps (the software has to do its own switching).
After making myself slightly less ignorant about ATM by reading the corresponding wiki page, I'm highly amused to why ATM's frame size was 53 octets.
48 bytes was chosen as a compromise, despite having all the disadvantages of both proposals and the additional inconvenience of not being a power of two in size.
But voice service was run over ATM, for many years as the backbone of the PSTN. ATM sort of aped, in digital form, the "circuit switched" nature of the analogue telephone network. My understanding was that it was designed for that reason; because telephone engineers understood circuit switching.
M.
Out of curiosity, where have you seen ATM running in a live WAN? I only entered the WAN world well after ATM was considered well and truly obsolete, so I've never seen it personally, but then even the longbeards I've worked with remark on how long-dead it is.
Was it in specific, private VPNs for critical systems? Or perhaps, some country where infrastructure investment is tight?
"Out of curiosity, where have you seen ATM running in a live WAN?"
Various research labs here in the Bay Area played with it in the very late 80s and very early 90s. If you had a sneezing fit, you would have likely missed it.
At that point, it was bloody obvious to anyone paying attention that Ethernet and TCP/IP would rule the roost for the foreseeable future.
IBM came up with a hack to work around that ...they essentially used the keyboard controller and an out-of-bandwith chunk of writable memory accessed via the A20 gate to save the state of the system before going into protected mode, and reversed it to come back out. Ugly, ugly, ugly, but very functional hack ... IF you used IBM's proprietary hardware. It also worked on a few clones, but was hit & miss in clone-land.
It is of course fair to argue that somebody with really old hardware won't be able to connect it to newer machines which lack an ISA or even parallel PCI bus. However, IIRC it's been demonstrated that you can use something like a Raspberry Pi Pico to bridge a PC's LPC bus to an ISA socket, although I suspect that doing so would be incompatible with bootloader signing etc.
However if somebody really did have good reason to run an older card and if he'd already fixed the bus issue, in the case of network devices he might be able to use a Packet Driver wrapper: /if/ such a thing were still runnable and preferably in user mode.
The alternative would be for NDISWrapper to be resurrected, which I'm sure the kernel maintainers and system managers around the World would /love/.
As a Linux user since 1993, I had (up to a few years ago) been wondering if they were just going to keep support for hardware in forever. They've FINALLY begun removing driver support for hardware I used back in the 1990s. They seem to be de facto settling on a ~30 year support timeframe here (although, if there's any indication anyone is actually using any of this hardware, I imagine they'll keep those individual drivers.)
If anyone is seriously worried about being able to use, same, a 3c509 on a modern kernel (I used one of these back in the day), it *is* entirely possible to build kernel modules outside the kernel source tree. One could absolutely have an "ancient ethernet card" support package that builds these drivers, if there's truly any demand for it. Back when I ran a 3c509, I was also running a 386 then a 486 though. By the time I went socket 7 (AMD though), I was using RTL8139s -- essentially a 100mbps NE2000 clone. These suckers were VERY cheap, I recall I bought like a 5 pack for $25 LOL. Don't know how they ran in Windows but they were 100% fine in Linux. My recollection was a 3c905 (which I ended up with one of too at some point) had lower CPU utilization, but it wasn't high enough on these to be an issue.
A typical user installation should not need ATM or AX25 support so if these drivers are buggy then they should just be labeled 'caveat emptor' and left alone. ATM is effectively obsolete because it was designed as a way to transfer network traffic over the then synchronous telephone network (specifically fiber long haul links). AX25 is actually alive and very much in use by radio amateurs, they use it for messaging over H/F radio. Its just it shouldn't be part of the Linux kernel -- it turns data streams into audio tones -- FSK -- which is easily handled by user level programs. The interface these days is USB rather than some kind of sound card (which would need drivers and is most definitely obsolete).
