Electric traction? Sure. We've had that in various forms for ages, and advances in battery technology have now made it viable (if still a mite explodey) for the private automobile.
Electric traction as the solution to anthropomorphic climate change on the other hand... That's just another episode of the same old consumerist "magic pill" bullshit... See quickfur's excellent coverage above.

Now, that's not to say I wouldn't want to own an electric vehicle. They do have some advantages, particularly where relatively clean electricity is cheap and charging infrastructure isn't woefully inadequate.

However... As far as I can see, it's next to impossible to really own any modern vehicle, regardless of powerplant. So if someone would like to point out an EV that isn't a rolling spyware platform full of obnoxious "safety" features designed explicitly to piss me off and prevent my vehicle from doing what I tell it to, I'm listening...
Otherwise I'll stick to my simple, obedient '70s and '80s tech. No cameras, no GPS, no manufacturer phone-home or remote killswitches, no feature subscriptions, no touchscreens, no driver attention monitoring, and most important of all, no goddamn incessant beeping about every trivial thing.

As for fission vs (fossil fuel) combustion, "clean"ness and timescales... Sure. The only missing component there is that we have some viable solutions for processing and containing spent fission fuel on the table. Carbon capture and storage on the other hand is a complete joke if you take even a cursory look at the numbers (and volume) involved.

If it's already in unstable, 99% of the work is done and the best option is probably a simple backport.

That's only because the binary was built against that version, a problem which will go away by itself if you recompile it as above.

Yeah, nah. Why?
First you need a mouse and a GUI, both of which make it a non-starter for serial console or SSH on headless machines. Then you've got the not-uncommon gpu-driver/KMS shenanigans, and on top of that you're dependent on a particular tool on a particular live disc that you will sooner or later not have handy.

That's without even starting on all the fun to be had with "automatic" repair tools if the system has an unusual bootloader, custom boot configuration or chainloading, RAID, root-on-ZFS, netboot, the list of things such tools will probably either not handle properly or completely louse up goes on.

OTOH, pretty much every bootable GNU/Linux media in existence has mount and chroot, and once you're in that way you have all the tools and existing configuration of the installed OS right there.
You also have the opportunity to fix the problem properly the first time and verify that the installed tools (i.e. update-grub, update-initramfs, dpkg configuration etc.) can reliably update the bootloader for next time.

Why reinvent a perfectly good (and not particularly oft-used) wheel just to make your mouse pointer feel useful?

Or you could just chroot in and do 'dpkg-reconfigure grub-[insert platform]', which is pretty much how d-i installs the bootloader anyways and should suffice for most scenarios.
Personally I have no use whatsoever for refractainstaller, but if I were a betting man I'd say that's what it calls for the bootloader step too.

That's not a bug, it's a design decision.
X was not developed for personal computers, it's fundamentally a graphical mainframe technology. In that scenario the trust model is inverted WRT a PC - i.e. the network is secure, applications are served from the mainframe and implicitly trusted, the terminal running the xserver is not.

X is as secure as it has ever been and (at least for now) it's still getting patches for any newly discovered issues, but the core design concepts don't transfer particularly well to the age of software-as-an-enemy... Then again, as long as you don't run untrusted applications that might want to screenscrape or keylog you, you're fine.

It is, and writing custom shell hacks for every user-session "daemon" that doesn't bother to behave like a daemon because systemd user units exist isn't a particularly elegant or sustainable solution.

If Devuan is going to transition to pipewire following upstream Debian, we're going to need a better answer than "user finds random script / autostart / .xinitrc hints on the 'net" for starting and stopping its services.
IMO some kind of process supervisor (be it part of an init system or standalone) is the only realistic (and reliable) option, and I already mentioned one possibility. Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.

This BS is only going to become more common, pipewirwe is just the thin end of this particular freedesktop/redhat/ibm wedge.

FWIW (in case I haven't mentioned it already elsewhere, which I probably have) my current solution is daemon, and these three lines:

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire /usr/bin/pipewire

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-pulse /usr/bin/pipewire-pulse

/usr/bin/daemon --bind --respawn --pidfiles=$XDG_RUNTIME_DIR --name=pipewire-wireplumber /usr/bin/wireplumber

In 3 autostart files (or wherever else you might want them).

Order no longer matters and sleep / while loop hacks are eliminated, because --respawn.
Pipewire not exiting with the user session is fixed (without pkill hacks), because --bind.
Pipewire not doing any of the other things a daemon should do (like writing a pid file or detaching from stdout and forking into the background) is also fixed, and --name and --pidfiles allow for e.g.

$ daemon --list --verbose
cdemu is running (pid 4577) (client pid 4578)
pipewire is running (pid 4573) (client pid 4574)
pipewire-pulse is running (pid 4568) (client pid 4572)
pipewire-wireplumber is running (pid 4547) (client pid 4549)
systembus-notify is running (pid 4583) (client pid 4587)

If you don't want pipewire noise in your xsession log (or want it in it's own logfile), daemon can fix that too with the --output, --stdout, and --stderr switches.

The cost for all this convenience is ~170KB of memory per managed process (on-par with supervise-daemon). Make of it what you will. As much as I like shell, IMO this is a much cleaner solution.

No. I don't reuse passwords, the probability of somebody running a MITM attack on my login to a random forum is miniscule, and even if they did and managed to impersonate me here, who the hell would care?

It is. If you do somehow get redirected to the login form over HTTP (which I haven't seen myself), that's easy to prevent on the browser end with the likes of the HTTPS-everywhere extension.

This ubiquitous bleating about HTTPS with complete disregard for attack surface, user responsibility and basic password hygiene, or even relevance is quite tiring.
Security is a process, not "if [[ ${URL bar} =~ "padlock icon"  ]]; then sleep; else panic; fi".

That script is a simplified version of what Gentoo and Slackware (and likely other non-systemd distros) are using to start pipewire.

PW doesn't daemonise properly, exit with the user's session, or manage it's own instances and ordering, instead relying on systemd user units for all that.
The 1 second sleep is required for reliability, and killing pipewire processes avoids not having sound after a logout -> login (unless you have elogind and KillUserProcesses=yes, which kills everything).

Personally I got rid of all that hacky mess, and am using daemon to manage pipewire (and cdemu, which has the same problems). Binding to the user session requires [e]logind and backporting daemon from unstable, but also neatly solves the "pipewire doesn't exit with session" problem.

TBH the first thing I'd do is see if the system will boot to single user mode (pass "single" or "1" on the kernel command line)... But again, boot issues are difficult to diagnose remotely, so more options more better.
I mention sysrq because when getting a working shell to see what's going on or fix something is the goal, sometimes a large hammer (e.g. "Kernel, kindly kill with fire everything except init") is the most effective tool.

Magic sysrq is a kernel facility, docs here.
SAK (ctrl-alt-sysrq-k) is Secure Attention (or Access) Key and kills everything on the current tty except login.
Unraw (ctrl-alt-sysrq-r) switches the keyboard to xlate mode, which can be useful to wrest keyboard control from a misbehaving or crashed X process.
The term and kill commands might also be useful, in the case some init script or daemon has gone rampant

You might try the usual tricks, like issuing a sysrq unraw or sak at an unresponsive login prompt, booting into runlevel 1 or S from the kernel command line, or at a pinch just passing sulogin (or even just sh) as init to boot direct to a shell and bypass normal startup altogether.

The "recovery shell" you mention is probably either runlevel 1 (or the synonymous "single") as above, or an initrd shell you'll be dropped into if the root fs is unavailable. Pretty sure Devuan has those and always has.

The apparmor stuff is probably harmless, for some unfathomable reason it keeps getting pulled in unless you pin it, then complains because it's not configured properly. In all it's kind of difficult to diagnose something like this from here without seeing the boot process.

Personally I think Devuan should move to openrc as default, and pool init documentation (and service scripts) with Gentoo, Artix, Alpine and Nitrux (and maybe even GhostBSD, which is pretty cool as far as BSD desktops go ).
But that's just me. While it does still do what it should, I have no particular love of sysv, insserv or LSB.

Browsers aside, I prefer "If you not having problems with discourse, then you need to worry.", or simply "If you're using discourse, you have a problem."
That thing is the most obnoxious "forum" software I have ever had the misfortune to encounter.