What difference would it make, you do the same...

Everywhere you go.

Then, if anyone should dare propose an improvement to this supposedly terrible situation, out comes the...

You moan, but you do not do. You rubbish free software, but you do not work on it, even to help yourself. You insult groups and individuals, you belittle their achievements, but you will not even attempt works comparable to theirs.

Your sole contribution to a thread asking how to do a thing is to state that you're not brave enough to try, but someone else might... And even there, you misrepresent my statement.

In any case, I'm done with this thread, and I'm tired of the whinging and politics on this board in general. I'm currently running xlibre on Gentoo, and If anyone wants to try it on Devuan I invite you to read the extensive Debian packaging docs and figure it out.
Otherwise, feel free to hop over to a distro/board/irc channel with less moaning and more doing.

Oh that wasn't meant for you, you're making things. It was for the "I bet it could be done", "not brave enough", "I do hope that SOMEONE will", "above my pay grade", "Perhaps you would like to" bikeshedding crowd.

I built Xlibre on Gentoo, because that's my main these days and the only Devuan installs I have are headless servers I'm not about to screw around with for something they wouldn't even use.
There is now an overlay hosted at github.com/X11Libre/ports-gentoo, so trying it on Gentoo is no more difficult than installing any other live build.

I see no reason the xlibre devs would be against a similar arrangement for Devuan, were somebody with an appropriate build environment to adapt the Xorg spec files and build test packages. That shouldn't be particularly difficult to do (though personally I find the Debian packaging workflow somewhat convoluted and unpleasant), since the project structure is still very close to Xorg.

I mean I could probably do it in a VM or chroot, but not to put too fine a point on it... That's a lot of mucking about and the lack of effort from anyone else around here (who, unlike me, stand to benefit directly) isn't particularly motivating.

Exactly this ^
You claim Xenocara is "the best option", but offer no technical arguments or comparisons to back it up. You claim it "could be done", but don't actually do it, even just for testing, even just for yourself.
You claim Xlibre "could be good", but you haven't tried building or using it... And your "doubts" are vague aspersions on the lead developers politics, rather than a technical assessment.

Why don't you try compiling that, if it's a project you want to promote?

As usual, it's all just talk, all just pontificating on what other people should or shouldn't do, passing judgement on people you have never met, and minor variations of "xyz developers I don't know are assholes/scumbags/[insert insult here]".
Go contribute to the project in question, go work with the people concerned... Then maybe you get to call them names. Raging from afar is pointless and childish, regardless of how easy it is to spit at a faceless organisation you have no real contact with.

I for one do not give a fat rat's behind about the "principles in place" or whether or not the lead developer is a [facist|furry|wears a gimp suit on sundays], I care about ability, technical merit, and whether or not a piece of software is a: solving the problem at hand, and b: copyleft licenced so it can be forked if needed.
If something looks interesting, I'll try it. If there aren't distro packages yet, I'll build it. If it's promising, I might even try to contribute to it. I'm not an accomplished C/C++ coder by any stretch, but you don't always need to be to contribute in a useful way - case in point, even building and testing on different platforms can be productive, assuming you report any bugs you find.

So, how's Xenocera working out for you on $distro_of_choice? Any problems getting the code built? Any bugs to report or technical suggestions to pass upstream?

Ed. Thought that might happen... While I'm still trying to solve a bunch of nonsensical GPU crashes (result: not Xlibre's fault, it's a power management bug in the amdgpu kernel driver), Stefan goes live with an Xlibre-git overlay for any clown to try it out.
This is why I've largely moved over to Gentoo, where the arguments are just a smoke-screen for sneakily getting stuff done.

Well somebody has to actually test the thing, no? If we all just sit around waiting for the magical pixies to do everything, nothing gets done.

To be fair, wayland is *mostly* usable... But my own year-or-so living with it came to an end fairly recently, because upstream apparently has no interest whatsoever in getting from "mostly" to "fully" usable, or considering any use-case beyond "works for normie tasks on my laptop/corpo-drone workstation".
Every single proposition or pull request furthering feature-parity with X11 or backwards compatibility of any kind results in endless stonewalling, recursive arguments, and NIH bullshit. One can smell the "Desktop Linux belongs to us, toe the line or GTFO" excreta dribbling down from Redhat and IBM suits a mile away.

So back to a display server that works it is... And FUD aside, Xorg still does.
Not "works if you use the right compositor on the right day of the week".
Not "works if the app you want to use has been updated in the last 5 minutes".
And certainly not "works if you squint a bit and ignore broken DPI scaling, janky session restore, buggy clipboards, screwed up window placement, missing features, and general dogs breakfast of competing, poorly concieved, partly implemented protocols"...
No, Xorg *just works*. It even works for 20 year old software, with minimal (and often no) changes... Imagine that.

So far, I can't really tell the difference between Xorg and Xlibre from an end-user POV, which is exactly as it should be.
Meanwhile, the "X is insecure" apocalypse is still stubbornly failing to materialise. I'm sure it sucks for somebody somewhere when reality gets all uncooperative like that.

I'll be keeping a dual-stack around in case wayland ever grows up (15 years and counting), but I'm not going to hold my breath.

Zapper is taking the "whine about evil overlords rather than doing anything constructive, in hopes others will validate with more whining" approach still.
FTFY.

GNOME / freedesktop / Redhat / IBM has an agenda, one that involves agressively pushing thier (weak copyleft or "open source") solutions as dominant standards. This is not new. This is not unexpected. This will not change, no matter how much childish name-calling you do.

If you don't like what Redhat is doing, don't use thier solutions (or better, fork them and fix them). If you don't like wayland, run X11 and/or contribute to Xlibre instead.
If you're going to pick fault with all alternatives because you don't like the personalities or supposed politics involved... Congratulations, you're part of the problem.

Aside, on GNOME in general, for many years now: ∨∨∨

The OP asks about running apps without a physical phone, and gives a couple of generic examples with no implementation details.
*you* moved the goalposts by adding custom authentication and token generators.

If you have a working crystal ball, feel free to open-source the schematics. Otherwise you're putting words in somebody else's mouth to further your own agenda.
If what what you really want to do is shoot down every suggestion so you can whine about "big tech" control some more (with much talk and no action of course), you do you... But constant "old man yells at cloud" bitching (a common pastime around here apparently) never achieved anything constructive.

GSF has built-in 2fa authentication for apps to use, with various levels of physical device integrity checks. Whether a specific app uses it or rolls their own is up to the app developer. Even when they do roll their own 2fa auth, they're likely going to be using GSF to verify the integrity of the app, OS, and device before they allow you to start that process.

Unless you are somehow under the impression that there is only one bank in the world, with one app, you're making the assertion that your personal situation with your particular bank is also the only one the OP could possibly be in. This is infantile.

Which is why authentication is (or should be) handled server-side, and any on-device security handled by widely deployed, trusted frameworks. The "app" can then be (and IME often is) little more than a thin interface for the web api, with hooks into GSF for 2fa.
If an app does require integrity checks (e.g. allows fingerprint or facial recognition auth and does it on-device), that's exactly what the android integrity and hardware crypto apis are for. Most apps use those, because security is hard and reinventing wheels is stupid... They're also far more secure than relying on something like cell network registration / IMEI, which is notoriously easy to screw about with (see many real-world examples of sim-swapping / device cloning attacks).

My bank also has an app, it's not mandatory, it only uses 2fa for initial setup, and it works perfectly in a VM. The same goes for a host of "special deal only in our app spyware" situations, virtual boarding passes, concert tickets et al., extracting login tokens or DRM decryption keys for reuse in third-party apps, and countless other things besides.

Android studio can create any number of full-featured emulated devices, with android versions and api levels of your choice, in just a few clicks.
It is of course a google product and not to be trusted, but using the standard development environment does have advantages wrt compatibility.

I'd suggest a version a year or two old, so as to avoid the worst of the Artificial Idiocy that google seems determined to infict on man + dog.

EFI/MBR is a BIOS thing, grab the manual for the board you're considering. If it mentions "legacy" mode/CSM, you can likely still use MBR boot.

Youtube (as with much of the "modern" web) can and will cause your browser to consume fairly insane quantities of memory...

The behaviour of the linux kernel under heavy memory pressure can be somewhat pathological (at least for desktop workloads, where killing memory hogs early is preferable to compromising interactivity), in that memory reclaim may livelock for quite some time (especially when swap is involved), and the OOM killer will only trigger once all other avenues are exhausted (i.e. potentially many minutes of thrashing, swapping pages in and out, and repeatedly evicting the page cache).  Paradoxically, this is often exacerbated by fast (ssd or nvme) swap devices.

There are ways to tune this, but the easiest solution for desktop use is probably a more proactive OOM killer such as earlyoom, nohang, oomd, or (obviously not here) systemd-oomd.
Better explanations of my statements above can be found in the first two linked repos.

Only if one intends to use it for suspend-to-disk.

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?