Indeed. Because:

It seemed that's what was being asked.

If you like:
Kwin/KDE
Dolphin
Firefox
Kmail
Kontact
KeepassXC
Filezilla
Jdownloader
Transmission-remote
Pidgin
KRDC
Libreoffice / Okular / FBreader
Gwenview & DigiKam
GIMP
Smplayer
Cantata & MPD
Easytag & Flacon
Kate
GCC, make, etc. scripted from Kate.
QCAD (I need .dwg compatibility that works)
Pre-Autodesk Eagle (I need the component libraries)
VirtualBox
Kcalc
Labplot
Lutris, WINE, DXVK etc. etc.

Konsole, bash, and all the CLI stuff therein.
All the other things I have forgotten but would miss immediately if I were to remove them

I don't have equivalent hardware so I can't check (exact names will differ), but my approach would be either:
a) If hwmon1 and hwmon2 are handled by different drivers, go see how and when they are loaded. They'll be getting an index based on which module loads first, so if you can fix the load order they should always get the same name.
b) See if there's another usable source, such as conky's {acpitemp} object or a node in e.g. /sys/class/thermal.
c) Get the values externally. IIRC conky can call external binaries, so you should be able to use lm-sensors with something like:

${execi 10 sensors | grep "Package id 0" | cut -d'+' -f2 | cut -c1-7}

"Package id 0" is from the intel coretemp driver so your sensor name will probably differ, but it should still be easily grepable.

It shouldn't be difficult to search through the /sys/class/hwmon[x]/name files for the sensor you want in a bash script either, push comes to shove.

The record industry (not to be confused with actual artists) was and still is convinced that consumers should rent access rather than own content.

Apple took things a step further, and sold a device that was essentially useless without subscribing to the content service... A content service where it looks like you've bought something, but actually using it is encumbered with DRM and tied to a subscription tightly controlled by the manufacturer. Then they doubled down and said you're not even supposed to be able to replace the battery.

You don't really own anything on iTunes, and even if you import your own DRM-free audio files it will mangle them to prevent you copying them again.
The open-source community quickly broke these restrictions and allowed us to transfer audio files freely with open-source tools, but the anti-circumvention clauses in the DMCA mean releasing software like GTKpod today would be illegal.

This "you own nothing" attitude is becoming more and more pervasive, throughout multiple industries. Be it streaming services, unrepairable hardware, cars that report to the dealership, or walled-garden app stores, the intent is the same - corporations retaining control over products long after they have left the shelf, and milking customers long after they have left the store.
All under the banner of "Don't think, just buy. Leave everything to us. For just 4.99 (plus recurring payments) you can have all the shiny things you ever wanted... Until we decide to take it away."

Calm, fitter, healthier and more productive
A pig in a cage on antibiotics

The way I see it, we have three options here:

* Keep breaking the DRM and reverse-engineering the hardware, playing cat-and-mouse with manufacturers and risking litigation under the demented monstrosity that is US copyright law.

* Pursue legal means through right-to-repair and such - if the hardware is liberated, liberating (or replacing) the software becomes considerably easier. Freedom to repair also means less waste to landfill, less profit for big corporations and more support for small locally-run businesses. As a bonus, it would also make it easier to hack on your own gear.

*Refuse to buy such products in the first place, and support open initiatives instead. Use jitsi instead of zoom, buy from System76 or Raptor CS instead of Apple. Ditch Spotify and iTunes and get your music from Bandcamp. If some shiny-new-(i)thing doesn't allow you to be in control, don't buy it.

Disclaimer: I am a unashamed software freedom advocate, and an FSF member. I'm not a hippie, and I don't eat my toenails in public... But I sure do like my freedom, and I'll donate to the FSF long before I give a cent to apple or the RIAA.

Back on topic: If you (OP) want to spend your free time circumventing the anti-freedom measures apple has surely put into it's new laptops, nobody here will try to stop you.
Asking others to do so is asking them to spend time and effort indirectly supporting a company that is diametrically opposed to everything free-software stands for, and doing so might even be illegal in some jurisdictions. Personally I feel efforts would be better spent elsewhere.

TBH I expect they're the same people who care more about what colour their car is or how expensive it looks than they do about reliability or performance.
In the good old days we'd call it "more money than sense" and leave it at that.

What I don't get is why anyone with the motivation and good taste to install a relatively obscure GNU/Linux distro (and one aimed at veteran sysadmins to boot) would want to wear the hair-shirt of running it on the latest shiny-new-shit MacBook, Apple and homebrew hacking of any kind parted ways decades ago and they've been intentionally making life difficult for us for almost as long.

Anyone with a lick of sense should already know that nothing computer-related in a movie bears the slightest resemblance to reality, so I'm not sure it'd make much difference.

Personally I take some glee in being the only one with a large GNU-head on my laptop lid in a room full of fruit, almost as much as I do at having superior performance and battery life, as well as the dents to prove my machine doesn't disintegrate when breathed on.
Then again I'm kinda nonconformist by nature, so, vOv.

I can understand the appeal of getting away from x86 (TBF I don't mind it at all, I still work with the venerable 8086 regularly), but Apple isn't the only game in town, and more arm-based projects are appearing all the time.
I can't help thinking effort would be better spent supporting (and buying) systems that are designed with GNU/Linux and software-freedom in mind.

Presumably just some variation on rm -rf /* or an obfuscation of such then. IMO if you execute commands from some random post as root without understanding what they do, you deserve what you get.
If I instructed you to set your PC on fire, you'd rightly ignore that as well, would you not?

Themes are pretty much always installable without root privileges (and so cannot wipe the whole drive and can be tested with a throwaway account), rarely have any call at all to be packaged as a .deb, and are usually either human-readable to begin with or come with source code you can inspect.
Most theme engines have an explicitly non-executable format anyway, so if something is packaged as a .deb or an installer script, you'd be wise to ask yourself why that is...

In general, the only "safe" source for any precompiled binary software is the distro maintained repository, and that's exactly as safe as the maintainers are vigilant. Any "user contributed" stuff is usually completely unchecked, because when it comes to FOSS in general it's anticipated that the user can and will inspect the source code.

That is indeed the better option, not only do you get a chance to see the source, you also ensure the resulting binary is linked against the correct libs.
Personally I'd consider a VM overkill (though useful for building packages for other distros), fakeroot and the debian packaging tools do a pretty good job of ensuring you only need root for the final installation, so you can do all building etc. as a dedicated unprivileged user.

All those people who hose their systems messing with sources.list or installing .debs from random places could have avoided that pain by spending the 10 minutes to learn how to rebuild a package from source, it's not difficult.

Okay, there's so much horsehockey in this thread I just can't resist...

Long-form command-line switches have two hyphens, short form have one. This has been the defacto-standard for *nix applications since the dawn of time. Why? Because that's how it's always been, and because it makes parsing command-line switches in shell a lot easier.
This really is command-line GNU/Linux 101, and if you intend to use anything beyond easy-mode Ubuntu derivatives and clicky GUIs you're going to have to get used to it.

Yes, that's the standard comment character for shell, and therefore for *nix configuration files. Again, always has been and likely always will be.

On puseaudio issues in general, the reason Devuan sometimes needs the user to configure pulseaudio is because unlike certain other distros Devuan doesn't force you to use pulseaudio.
Yes, I'm sure it could be made to work out of the box for your setup... At the expense of not working out of the box for someone else, or of making it more difficult to run without pulseaudio altogether - which is also an entirely valid configuration.

And I suppose you were disappointed the installer didn't try to converse with you in really easy words as well?

Debian, and by extension Devuan, is not and never has been designed to "work effortlessly", that's not the goal.
The goal to be able to fulfil almost every conceivable role, on almost any available hardware. Hence the slogan: "The universal operating system".
This means that you will have to *gasp* configure it to your needs, because a default that "works effortlessly" on your desktop is almost certainly inappropriate for a supercomputing cluster or an embedded network appliance.

Wasting time by not reading the available documentation is very much an error, unless of course you like wasting time.
If the release notes were not intended to be read, why do you suppose someone put in the effort to write them?

I'd be inclined to make the obvious comment regarding looking gift-horses in the mouth WRT free software and volunteer developers (not to mention unwillingness to put in effort yourself), but given your attitude so far that's likely a waste of perfectly good oxygen.

MX is the mid-range line, and I haven't heard of any problems with them either.

This was no spike, this was pegging at 60-70c continuously, and it only took about 50GB of sustained sequential write to get there.
I probably got ~5x drive capacity of write endurance total before the first one croaked.

HP make pretty decent server-grade stuff, but their consumer products are total garbage, always have been.
That said, those SSDs were almost certainly OEM jobs, and good luck figuring out who really made them.

I have several (including a pair being thrashed as cache drives), and I have absolutely no problems to report.
Even the DRAM-less budget models seem to be okay, if understandably slow-as molasses. And yes, even the very cheapest have metal cases and thermal pads.
Just be aware that they're one of the (several) brands known to lie about performance, if stated speeds seem too good for the price, that's exactly what they are.

I could, but all this is going on in the initrd before init starts or /etc/init.d is available...

I'll do the same to the initrd script that starts udevd and see what happens, but it'll have to wait a little as I can't really take this box offline right now.
It occurs to me that there were also some hardware changes which might have fallen in the "I just noticed it" window, and those could probably be reverted temporarily.

When I get a window long enough to risk borking the boot process and reverting backups without undue screaming, I'll have another poke about.

Gentoo on the desktop, Devuan on the server. I did run Arch once, long ago, it's a pain in the ass and so are many of it's users.

Installers are not the last word in possible configurations... Gentoo doesn't even have one.
I don't run ZFS root anywhere* though, because it not being shipped on any install/recovery media I am aware of is a headache I don't need. There's nothing preventing you from adding it in once the base system is installed though, and it's very nice.

Of course it's possible, and TBH it looked pretty obvious to me... But then I've been doing manual partitioning since Sarge. I don't think I've ever even tried the "guided" mode.
I have deep-seated trust issues when it comes to installers, and the moment I'm presented with words like "partition" or "format"  I tend to make a beeline for the advanced option.

*Except on BSD, but I don't really use BSD enough to include it here.

While it may well cause boot delays, It doesn't explain the failure to remount the root partition r/w or the thick cloud of smoke being emitted by /bin/mount in the screenshot above.
There's little point in trying to troubleshoot ifup when you can't write to the filesystem...

Indeed.
Once you get in (or if you image the disk before reinstalling), it would be interesting to see the apt policy and debsums for those packages... Libraries don't change themselves (this is stable, not ceres, right?), barring some proper odd variety of disk corruption.

I'm not sure exactly what you mean by "remote dpkg install" here, but all you should need for a look around is a working mount command, the minimal live image would do nicely.

Incidentally, if that's some kind of thin terminal and you have a bunch of identical installs, you might like clonezilla's bare-metal PXEboot image restore features. It sure beats lugging HDDs around IME.

Well, the netinstall image doesn't include any mouse support, which I guess is a shame (but hey, it's tiny)... So some extra keystrokes and/or gratuitous use of cat might be needed.

Both the graphical and minimal live images can install the system with refractainstaller though, and they both have mouse-driven copy-paste, so there's a viable option if you run full disk encryption or something (what else?) that needs input of long strings to the installer.