You are right, of course. However, what I'm reacting to is the culture around JS and it's supply chain and general attitudes around different groups of programmers. Yes, some language features *do* make it *easier* to write secure code, but they sure as hell don't do it for you, nor do they eliminate all classes of exploits or flaws. I'm just tired of everyone acting like web-programming is the only thing that matters or the only place folks write code. I detect a real stench around certain groups of coders and don't want everyone lumped into the same boat with "those" guys. JS seems to be a cesspool and the worst practices seem concentrated there and that's why the lame AI bug bounty stunt targets them first.

Or you could just switch to NetBSD and get yourself free from Systemd, Linus/Linux, Pottering, bundled GNOME, and a whole lot of other heinous un-Unixy shit and run your _386_ till the end of time with a better community and a better organized operating system.

You could hang a device with a late-model 2.6 Linux kernel on the internet right this minute, today, and be just fucking fine. There are no RCEs in the 2.6 kernels and there is one DoS attack with the network stack that only impacts somewhat early 2.6 kernels (the TCP SACK issues). People love to hyperventilate when something is 15 minutes old or older. The truth is that most old shit is perfectly safe if you pay attention. You could still compile/update to the most modern version of OpenSSH on your 2.6 box and be just peachy. I have a fucking IRIX 6.5.30 box still online and people constantly lose their minds and tell me how "insecure" it is. Really? Great, someone hack me, then. I've been double-dog daring fuckers to do it for 20 years and just updating OpenSSH every few years and I've been JUST FINE.

Security folks are mostly full of shit and can't compromise/"hack" half the shit they claim to be able to. Most "exploits" are theoretical and never get weaponized or even work as advertised. They just want to scare everyone and act like they have the knowledge everyone else is missing/ignoring. Wrong. Security weenies are rarely even programmers (the first step to being able to actually CRAFT an exploit). Most are shit-talking con-artists and lying wannabe posers. They are often folks with a vandal-mentality or are assholes trying to scare you by pointing out others who have the vandal-mentality and promising to protect you.

Just pay attention to your *services* and you'll be just fine.

Javascript isn't a terrible language, but it's pretty weak in several areas and compares poorly to languages with stronger typing and better security. Seems like AI tools are targeting the weakest systems first (Js + NPMis one of those). Of course TFA isn't talking about supply chain attacks but it is talking about Javascript related bounties. I doubt AI will "take over" development the way folks are anticipating, but if it does, feel free to take over Javascript, PHP, and VB coding any time now, guys. It's disgusting in the first place. Who can stand that shit? C/C++ is still the only way I'm taking you seriously. AI vibe coding has been pretty much an utter failure outside of JS attack code, with the recent "Anthropic C compiler" being the latest demonstration. It's got a broken assembler and cannot optimize at all (and it breaks with simple legal syntax on macros and pragma statements). It took weeks to create and tens of thousands of dollars in AI 'tokens'. Uhh, real intimidating, but hey, I guess if you are a shit-eating Javascript "programmer" you'd better be worried. Pffft.

OK bot. There isn't even a "you".

Due to this news, I suggest we refer to it from here on out as "fauxpilot".

Uranium is not a nuclear weapon. HTH, though I know it won't.

Yes it's already written. Use a kernel with the code still there. It's not like your 486 will have any application that requires the latest kernel, if your system even manages to boot at all.

The problem with written code is that if it remains "supported" it places a burden on all other code changes made to the product. Someone needs to do regression testing to make sure it's not broken. Someone needs to do security auditing and potential bug fixing. And above all, these are not reasonable requirements for hardware that old. Hence "not supported" means "not supported" i.e. the programmer won't or in some cases actually can't support it.

Software is not hardware, you can run old software. It's still there. It's not like the network switch example above.

Could and Did are two distinct words in the English language. Very few 486 machines ever existed with more than 64MB of RAM. They were for insanely niche applications. Now we change the debate from do we support what is today an incredibly rare architecture, to do we support what is today an incredibly rare architecture for the purpose of a niche that almost certainly doesn't exist anymore on that platform?

We can keep going down this rabbit hole of "but it did support", only to find there's a single machine on the planet that actually had that hardware config, and Bob hasn't used that machine in decades.

Actually, many consumer gigabit Ethernet switches lack 10Mbps support these days. They are 100/1000baseT only.

Business and enterprise switches though I've found (including Cisco ones, which you can find dirt cheap used) still are 10/100/1000Mbps. Even newer business and enterprise class switches retain support.

Of course, once you step into 10Gbps Ethernet, you have to be careful because many only are 10Gbps only, while some do support 1/10Gbps. 2.5Gbps support is iffy unless it's specified which is annoying since many things have 2.5Gbps ports.

As for 486, there are still new CPUs using it. The Vortex86 has a CPU that executes 486 instructions though newer ones do support Pentium minus the FPU. These are modern chips, with IDE emulation of SD cards, Ethernet and USB support, as well as running at speeds of 800-1GHz.

And you've seen them used - any fast food restaurant with the ticket screens is powered by a mini PC using these SoCs. They do run Windows and MS-DOS, and early restaurant e-ticket systems used MS-DOS. But later ones nowadays use some form of Linux.

Are you talking about professional well made IoT devices designed for corporate management? Because holy shit are you wrong about general consumer IoT devices doing no listening. There's a reason for the running joke that the S in IoT stands for security.

In fact much of the community driven IoT interfaces for tinkerers rely on the fact that someone has hacked a device almost universally via an active open listening port to force it to work with something other than it's Cloud service.

Your best beat at security: Isolate them on your network and firewall your inbound connections.

From the most current OS/2 release:

"Hardware Requirements
Intel Pentium Pro or higher, or an AMD Athlon or higher. 64 Bit CPUs are supported (however ArcaOS will run in 32-bit mode). Computers with ARM CPUs are not supported. Apple Computers are not supported (regardless of CPU). The Vortex86 CPU is not sufficiently compatible to run ArcaOS and is not supported."

i.e. minimum hardware requirements are a 686 instruction set.

Linux isn't suitable as a real-time OS now either strictly speaking. In fact that one of the top hits from a search on Linux RTOS is a paper from NASA (from a comparatively recent 2019) discussing the performance of Linux with every RTOS relevant kernel feature set into the most ideal position. Their conclusion was... well you probably will hit your event deadline if you throw fast enough hardware at it, but it is still nothing like a true RTOS.

Netanyahu, is that you? Was this lie about nukes they never had promised to you 3,000 years ago?

I admit that it's not intelligent to continue to waste time talking to someone like you, who thinks you can't do things I've done because you have no practical experience.