Nobody? Let's run down the list shall we?

Firstly we're talking about the core messaging app. I think people would be rightfully pissed if they were given a phone which lacked an app to send and receive SMSes out of the box. That's what we're talking about here. Samsung is replacing a core phone feature with a Google app. No thanks. Samsung messenger is nice and basic and does what it needs to do.

Samsung Browser - I use this. It's Google Chrome except you can install adblockers on it. Because God knows Google Chrome is a piece of shit on Android.
Their App Store - I use this. Only for one or two apps, but Google arbitrarily blocking apps from Huawei is a pain. Samsung still allow Huawei to publish apps in their store. Competition is a GOOD THING. You want vendor lock-in go buy an Apple toy.
Fitness tracker - I know plenty of people who use this. I use a Huawei one, but virtually everyone with a Samsung Gear watch or the Samsung Ring (which sold incredibly well) will need this app for core functionality.
Payment System - I know plenty of people who use this. Not everyone likes to be locked into Google Wallet, and above all not everyone CAN be locked into Google Wallet. I used to use Samsung's payment app back before my bank supported Wallet.

Bixby, and AppCloud - I'll give you that, that's a cancer. You can't actually disable Bixby though.

Precisely none of those need to be removed to make the phone fit for purpose or usable. In fact all of them do precisely nothing unless you click on them.

Poor phrasing. You say it is doing so without consent but then admitting that you actually give it consent and that you blindly click agree to whatever is on the screen? Maybe someone else should setup a phone for you.

It can be disabled. If someone doesn't know how pre-installed apps can be disabled then there's really no helping them. This was a feature introduced in Android 4.0 some 15 years ago.

I think you'll find most people actually know how to use a phone and for apps they will never use they simply long press the app and then hit "Disable" which not only removes the app from the home screen, but also blocks it from updating freeing up space on the user writable partition on the phone.

Forgive me if I sound snarky, it's probably due to the fact that this feature has existed for FIFTEEN YEARS having been introduced back in Android 4.0

  Also I'm not sure anyone on the face of this planet would call the default shipped SMS/RCS messaging app "bloatware". People generally expect the phone to do out of the box functionality of a phone when they open it up. What else do you consider "bloatware"? The contact list? The phone dialler? How about the OS itself?

Samsung has always had a messaging app. Always. In fact in the early days of Android *all* phone vendors had their own messaging app and virtually none shipped with a Google default.

And? Early adopters have bugs. The question is was your ex happy with the phone, not whether it lasted as long as someone other than her expected it to.

You misunderstand the term tested. Testing != using. Unless you used your Gentoo box to read through the commits to the kernel and then run specific tests against the 486 code to ensure there were no regressions.

Why the distinction? The point is that in some cases security would be just fine if the software were kept up to date. The fact that a device has a listening port open doesn't mean security is good or bad, it means it has specific functionality. One of the biggest problems in the consumer IoT world is that 99% of the shit out there is set and forget, open to any bug regardless of whether the vendor has patched it in newer products. Deploying modern software is fundamental to the issue under discussion.

If a third party client existed then it would work just fine. RCS is an open and clearly defined standard, and even iMessages supports it. Samsung users had no problem receiving or sending RCS, Apple users had no problem receiving RCS, and Google has no "control" over RCS as that standard is managed by the GSMA and it's 750 members much like nearly every other aspect of your phone.

Except that comparison (and TFS) has this completely incorrect. Here's the actual GM ad;

"The 2026 Silverado our most capable pickup ever!" - Read in deep dramatic voice
"Remember Chevrolote Spark models are for entertainment purposely" -Read as the image fades to black in higher pitch at 2x speed.

The Copilot being sold to corporations is a different product that acts different and does different things than the consumer one with the ToS. If you have a corporate Copilot licence, every query will have a button above it asking you to which Copilot you want to send the query which produces different results.

Just like a farmer who may finish hauling a bay of hay with his Chevy Silverado when his daughter asks if she can borrow the Chevy Spark to drive into town with the girls.

As fun as the ToS comparison is, the reality it no Microsoft is *not* getting Corporations to pay for the use of Copilot which has that language in the ToS. That Copilot ToS is for individual consumers. It's significantly different not just in terms of Terms of Service, but also in actual function to what corporate Copilot is. In fact if you are a corporation that pays for Copilot licenses, your users will be presented with a button to switch between the different Copilots during every query because they work differently, treat data differently, provide different outputs, and have different use cases.

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.

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.

You almost figured it out. It's almost like when we use a completely different vehicle where everything including all technology inside is different that you want to test things slowly before jumping feet first down on the moon.