Why? Separate partitions with / as r/o or squashfs and /home, /var as r/w or tmpfs is the obvious answer here, is it not?

Personally, I wouldn't use a debian-based distro for this. Security bugs in old software go way beyond just the browser, and by the time you find and fix/update all vulnerable packages (and rebuild the revdeps) you may as well have started from something more aligned with the "use modern software, and aggressively optimise for memory use" approach... Like TinyCore, or a custom build (gentoo, LFS, etc.) with uclibc-ng or musl, -Os, and minimal feature-bloat compile-time options.

Then again, I wouldn't bother with a 32bit machine as a general-purpose desktop to begin with. Used 64bit hardware is dirt-cheap now (Sandybridge/Ivybridge boxes can often be had for literally nothing), and modern browser engines kinda blow that 512MB memory target away all by themselves.

FWIW, TinyCore/Coreplus runs just fine on a Pentium 233 with 64Mb RAM. With 128MB, it's even pretty snappy... And it doesn't run decade-old software to achieve it.

I've been arguing that Devuan, as a leading systemd-free distribution, should be taking a (pro)active role in solving the problems that arise from not shipping systemd... Or at least making some decisions on how these things should be handled.

The "3 people" comment was, of course, with regard to the potential userbase of yet another tiny single-developer derivative of a derivative, and the duplicated effort of creating one to solve problems better tackled where they can benefit all Devuan derivatives - i.e. in Devuan itself.
I can solve this particular problem for myself, and I already have, in several different ways. I really don't see the point in building a distro to prove it.

What I would like to know is: Which way does Devuan intend to handle this, and is there anything that needs doing there? What solutions are being considered? I contributed one possibility way upthread, is it worth persevering with or is Devuan going to do something totally different?
Is anything at all happening, or are we just going to do the "wait for debian to make a move, then delay release for 3 months while we put out fires" thing again?

Slackware has an official solution in the repos, which works out of the box. Gentoo has an official solution in the repos, which works out of the box. Artix has an official solution in the repos, which works out of the box. The latter 2 also have wiki pages on the subject, listing several alternative solutions.
Devuan unstable has... *goes looking to confirm the obvious* A pipewire package pulled verbatim from Debian, a non-functional pipewire.service, and no documentation.

Ahh, I see. Pipewire wasn't on the list, nor were was user services in general. Do I take that to mean this is well under control and Devuan's pipewire-launcher and autostart files are being actively maintained?
I mean it sure doesn't look that way to me, is there some secret-squirrel development branch I don't know about?

Shed is definitely a solution (ebuilds for gentoo around here somewhere), as is daemon (ditto drop-in ebuilds replacing gentoo-pipewire-launcher).
TBH my focus ATM is with openrc though, as I'm not at all against this being a job for the system init. There are still things to do, but now that the experimental branch is merged back into main (praise be to navi for kicking that can), the next step is convincing Gentoo's pipewire maintainer to use it...

As for Devuan, it's the glacial pace of innovation and lack of open development that really deters me. Radio-silence from the devs, and the process appears to be "wait for Debian, then do the bare minimum damage control to keep things working".
Cheap talk is step-one in getting any of these solutions implemented, and as far as I can see, nobody in any official capacity is doing even that.

As soon as Devuan picks a direction I'll be happy to pitch in, but having several viable options pretty much ready-to-go and watching Devuan not even consider making a decision isn't particularly motivating.
"Wait and see" has its place, but there's a point it becomes pathological.

Personally my preferred option would be *current* openrc on Devuan, but again, the official approach there seems to be "pull packages from Debian, put it on the list, no further action considered".

Creating yet another respin 3 people might use just for this is a ridiculous misdirection of effort. 20 years ago I was rolling my own "distros" for fun, and unless it's something different enough to gain real traction it's always just that - a bit of fun that ultimately comes to very little.
Diverse options are just swell, but a one-man-band distro for every little thing is the kind of fragmentation we don't need.

The pipewire situation has little to do with "userfriendlyness", and much to do with it being rapidly adopted as a standard media server (audio and video) in major desktop environments. If you run wayland and want to do screen capture you'll need it, because wayland lacks the facilities we used for this on X11, by design.
That pipewire uses systemd for startup is not at all surprising, since there exists no other widely accepted way to handle multiple, order-dependent user daemons in a reliable fashion.

We should have had user daemons a long time ago. Not necessarily the way systemd does it, but there's got to be a better answer than a mess of shell scripts, cron jobs, .xinitrc, .profile, autostart links that some environments use and others don't, and major DEs doing their own thing with "service manager"s like kded.

For all its flaws, this is a problem systemd neatly solves. Upstreams have already started using it for clean startup/shutdown of user daemons, more are sure to follow. Pipewire is just a canary for a more general problem.
Either we decide on a general solution, or we get to deal with more of the inevitable upstream code-rot, deprecation, and special-case workarounds we're already seeing with e.g. the vanishing sysv init scripts for system services.

Cool. Now stream your wayland desktop to a smart TV over wifi, and switch audio output to it without interrupting playback. Yes, that's something people do, and it's not unreasonable to expect such capability to work out-of-the-box on a current GNU/Linux distribution.
Hell, just try switching playback to some bluetooth headphones and back smoothly. That's a thing that most users have expected to "just work" for a decade now.

I too use pure ALSA, where it's appropriate. A modern desktop is not that, let alone a portable device with wireless audio peripherals, A/V over USB-C, etc. etc.

Right... So the "bury head in sand" approach then.

There's a world of difference between giving users the freedom to do what they want, and shipping a core desktop component without an even remotely convenient way to start it, or any official guidance wrt setting that up yourself.
End users should be competent enough to follow instructions, but expecting them to grub through a forum thread and select between 10 different user-contributed options (most of which either don't work reliably and/or require out-of-repo software) to get a sound-server started is ridiculous.

Have you tried the pipewire-started-with-shell-hacks approach where multi-seat is involved? More than one concurrent user? Checked that a bunch of orphan processes aren't blocking the audio devices after a user logs out?
The current "IDGAS about this, user runs program how they want" simply does not work reliably. It will continue to not work reliably until we take an official position on the whole user services thing and start working on a robust solution.

The only reason we're getting a pass on this right now is because we're not shipping wayland-as-default right now. When that becomes necessary (and it will, sooner or later), pipewire also becomes necessary - not just for audio, but also for mundane tasks like taking a screenshot.
IOW, if Devuan has any intention of shipping with a KDE, GNOME, or wayland-in-general environment that works out of the box, it also needs a pipewire configuration that works out of the box...
Or we could keep ignoring the rest of the world, drop compatibility with major upstreams every time a challenge arises, and slide further into obscurity.

I was under the impression Devuan was "Debian without systemd", not "Debian like it's 1999, where large swathes of current software won't work properly and users have to spend hours on message boards to get working sound"... Perhaps I was mistaken?

GRUB has nothing to do with anything. You are passing 'vga nomodeset' to the kernel, which will disable KMS and considerable functionality of your graphics drivers (likely forcing some VESA compatibility mode which knows nothing about HDMI or audio).
Whether you do that with GRUB, LILO, or some other bootloader is irrelevant.

'nomodeset' doesn't "fix" anything and has nothing to do with the size of "letters on tty1", besides forcing some miserable (probably 640x480) fallback video mode. It's a "boot with minimal graphics capabilities and don't try to set a video mode" troubleshooting tool.
Perhaps consider reading the documentation for the kernel command-line switches you pass, rather than copy-pasting random things from the internet?

If what you really want is a different console font, change the console font. See 'man console-setup', 'dpkg-reconfigure console-setup', and/or '/etc/default/console-setup'.

Huh, guess the 4 mouse clicks it takes to install any of the ~200 games in my GOG library through lutris, and have it work perfectly first-time doesn't count then?

Proton is (BSD licence) open-source, the only proprietary part is the steam API client library.

That's exactly the market they are in, because the Steam Deck exists.
They've been trying to make the model fly for some time (steam machines etc.), and if the now quite large library of *proprietary* games running on the deck (and by extension, GNU/Linux) is anything to go by, this time it's working.
The only real showstopper right now is "anti-cheat" rootkits, and frankly if you're willing to bear that nonsense for the sake of a "AAA" game, you're probably fine with running Windows SpyOS too.

Much as I dislike Steam, there's nothing "pay per play" about it beyond fairly basic (and easily defeated) purchase-check DRM.
Again, Steam runs on GNU/Linux because the Steam Deck runs GNU/Linux. That's not "testing", it's a shipping game system.
Whether valve is "interested" in desktop GNU/Linux is irrelevant to the end-user, as the deck is effectively PC hardware and anything that runs on it will also run on a desktop. Hell, the thing runs KDE FFS, it might as well *be* a GNU/Linux desktop.

As for the OP... there's so much ridiculous there I'm not sure where to start. "talibans"? BSD doesn't have a terminal? Don't know how CPU power management has worked for the last 20+ years or how to configure it, and think that makes some OS "better" than another... The mind boggles.
Yes, if you want to run BSD you will need to actually learn BSD. Also, the sky is (usually) blue, and not everyone considers steam games the be-all and end-all of "desktop" computing.

There's nothing quicker than 'man' (and 'apropos', to find the right manual), since those manuals are already on your system. '/' for string search in the viewer (it's pretty much just the 'less' pager).
More comprehensive manuals are often available with 'info', though that varies by package.

I still have no idea why everyone goes straight for random blog posts and online copies of manuals... 'man' is faster, available almost everywhere, and doesn't require a web browser.

It presents as a very niche attack vector, requiring a specific set of conditions and permissions. For most people it's irrelevant.

I'd suggest you do whatever you like. There's no real reason not to set 'nodev' on a non-root "media and documents" filesystem, so you might as well.

It instructs the kernel whether or not to honour the suid and cap_sys_admin bits on executables, what else is there to "expand on"?

Exploiting suid executables also requires specific conditions and root permissions at some point, but again, since disabling suid does no harm on a data filesystem, you might as well.

I highly doubt it. It was likely the lack of the 'user' flag, since that is exactly what it's for. 'rw' is a default mount option anyway.
It could also be some weirdness of your file manager of course, but since you didn't specify what you're using, in which desktop environment, or what kind of "Authentication dialogue" you saw, who would know.

One additional trap to be aware of: If you use the 'user' flag, only the user who mounted the filesystem will be allowed to unmount it. That means the combination of 'user' and 'auto' will likely result in root mounting the filesystem at boot, and authentication being required for an unprivileged user to unmount it later. See the 'users' and 'group' flags for alternatives.

For reference, entry for the 4TB spinning-rust RAID1 in my desktop is:

LABEL=rust                      /mnt/rust       ext4    noatime,user,noauto        0 2

Which results in:

/dev/md2 on /mnt/rust type ext4 (rw,nosuid,nodev,noexec,noatime,user)

And it mounts and unmounts just fine from a GUI file manager (dolphin), without elevated permissions.
Note:

So we don't need explicit noexec, nosuid, or nodev, and:

So most of the time you don't need to add explicit (filesystem specific) 'defaults' for ext4 either.

An OS installation doesn't "own" a filesystem in any way (unless it's ZFS, but I digress), *nix is a network OS at heart and permissions are all about users and groups.

Who can do what and where simply comes down to whether the users effective UID/GID (i.e. numeric user and/or group identifier) matches the file/directory owner UID/GID.
If you set up your user account to have the same UID on both installs, that user will have the same permissions for the same files regardless of which OS you boot... And I suggest you do set up identical usernames with the same UID, because anything else is a kind of a confusing PITA (e.g. "bob" (UID 1000) on machine 1 can write to the disk, but "bob" (UID 1001) on machine 2 can't, so Bob is annoyed).

Aside:

No, no it should not. Mountpoint directory permissions should be root:root, they will be replaced with those of the root of the mounted filesystem (i.e. mount the filesystem, then chown, not the other way around).
Granting write on a mountpoint directory to an unprivileged user is just a super effective way to let that user fill up root when the filesystem is not mounted.

steve_v:
*opens a bunch of root-owned files in kate tabs, as unprivileged user*
*screws around for as long as needed, as unprivileged user*
*hits "save"*
*gets polkit authentication prompt*
*profits*

Much better than just having a GUI editor running as root for long periods of time I recon.

Aside, everything any of us might do in a GUI editor can also be done in emacs at a TTY.

The only thing more confusing here than the use of libreoffice for editing a simple text file... Is the use of libreoffice as root.
Just.. Why? Use a real text editor, from an elevated terminal. Nano, vi(m), emacs, mcedit, all work just fine without any weird encoding issues or the hazard of runing enormous GUI bloat as root. Nano has been the default $EDITOR for years, and with good reason.

Indeed, because that option simply specifies the number of parallel jobs to run. The only "error" possible is that the build fails because things are compiled out-of-order (which means upstream needs to fix their makefile / build process), and the only "risk" is wasting time and trying again with those options omitted.
To put it another way: The function of '-j' and friends is not complicated, and I have no idea why anyone would need handholding over such an option. Try it and find out, like everyone else.

The choice is whether to use DKMS or module-assistant... That choice is up to you.

Same as you would on Debian.
OTOH, compiling a kernel is much the same on any distro and hasn't changed significantly in decades, the only real difference here is using the debian specific make targets (included in linux-source-[version]) to build .deb packages rather than manually installing the image/modules.

And if you also fail to elaborate, nobody will know why.