Your best bet right now IMO would be flashing PostmarketOS onto a used OnePlus 6, which is cheap, has good specs and none of the battery issues plaguing the Pinephone Pro. That said, it’s not 100% ready to be a phone yet- for now its best use case is as a mini-tablet / PDA kind of thing. Really feels like carrying a pocket laptop around, which is pretty fun as a starting point.

Pinephone has a great active community, and the device itself is dirt cheap (also pretty low-specced). There’s a pro version with a much better specs in theory, but development state is much rougher. Not that the basic model is anywhere near daily driver material yet, but the progress is very appreciable every time i check in.

Yes, since you can run Android apps on them. They will be slower and have some quirks though I’m sure.

It goes through XWayland, whereas Wine on Wayland would do away with that later

Plasma’s scalable applications paradigm has been around for coming up on 15 years. Gnome’s isn’t far behind.

Just want to add that I don’t think it’s a technological plateau. I think it’s capitalism producing shiny and “upgraded” versions of things that are easy to sell. Things that enable accessible and rapid consumption. High refresh rate, vertical high-resolution screens for endless scrolling in apps optimised for ads-scrolled-past-per-second. E-ink devices only good enough that you can clearly see the ads on them as you read your books. Things are just not made for humans. They’re made for corporations to extract value out of humans.

Having used Ubuntu touch for a bit I’m way more excited about gnome mobile. I just think it’s overall a better paradigm. Ubuntu had some neat ideas but overall it just didn’t do it for me.

Having both that and Waydroid on a phone would be pretty great. You might want to check out Darling for running Mac apps on Linux in the meantime, since its goals are similar to Wine’s (but it’s still early in development in comparison)

Ahh yes the Steam Machines. Definitely contemporaneous with windows 8.

I think it’s likely Valve have intensified efforts recently for a number of reasons but not least of which is the ongoing encroachment of Microsoft turning the Windows PC experience into more of a walled garden across more segments. It can’t have gone unnoticed that Microsoft are 1) selling games on the Microsoft Store and 2) are normalising the concept of hardware root of trust etc with the windows 11 TPM requirement.

EFI secure boot was one thing. Setting conditions up so every PC in the world has hardware support for verifying that user space programs are signed by Microsoft is another. I’m not saying overnight they’ll flick a switch and every windows installation in the world is on S mode. But it’s clearly trending that way. That would be good night for Steam if they so chose. And clearly Microsoft believe they can fob off regulators well enough

https://www.fierceelectronics.com/embedded/what-risc-v

I don’t know if KDE got it working yet, but Gamescope’s works pretty well out-of-the-box. Nobara and maybe Chimara OS already have this ready with a session for Steam Big Picture mode.

Kinda funny that Windows games seem to always get compatibility with these things first. I guess just adding support in Wine means more games get the functionality at once than developers adding it on a per-game basis.

New motherboards. Unless AMD collaborates with board makers to push updates to their BIOS/UEFI to include OpenSIL compatibility, which is likely not going to be the case in my opinion

Nah, people always want to put their own spin on things and I welcome the diversity.

Arch can bring in all the necessary packages yourself, but Garuda exists and people enjoy using it. Horses for courses.

My issue is not with the ARC, it’s a few things:

• kernel integration is iffy; I don’t want to attach a module to my system every time I compile the kernel and prey that the difference in pace between the release schedules of openZFS and Linux hasn’t caused issues, and because of the licencing issues my options of having a distro with zfs built in are very limited.

• it’s performance isn’t excellent from a NVME standpoint. It’s not terrible, but it could be better.

• it has a massive code base, making introducing things like performance improvements and new features quite a challenge (Though the openZFS team are doing a bang-up job despite this).

Ultimately if I was still holding on to 40+TB of important data, I’d be using ZFS and be happy about it. I want snapshots on my workstation, without all the strange issues I’ve had with btrfs. I’m sure bcachefs will have its own issues but it’s better to have options.

It’s a technology that lets you run code through the kernel’s JIT compiler. It’s an extremely flexible way to run code in kernel space; the typical example is using it to build XDP programs for networking, which can deeply analyse network packets without having to incur the performance penalty for changing context to userspace.

I was on Fedora workstation before switching to Silverblue and they’re both quite solid, to be fair. The big feature that differentiates Silverblue is immutability–you can’t easily make changes to the base system.

Now, to some people I think that’s going to sound awful, but it has its pros and cons. The biggest benefit being that your base system is solid (and not just solid as in unlikely to break, but literally unchanging over time). Updating your system is effectively replacing it with a different system entirely (delta compressed, so it’s not too inefficient, if I understand correctly), and you can rollback/revert/swap between systems on the fly, in the unlikely event that an update makes something worse, though I haven’t needed to. You can even rebase your Silverblue (Gnome) system into a Kinoite (KDE Plasma) system, pin both “commits” and swap between them. I haven’t tried that though, since I’m pretty happy with the Gnome workflow. Long story short, immutable distros like Silverblue are basically as solid as solid can be.

There are two drawbacks that I can think of, and then a couple of minor nitpicks. The biggest being that you need to restart your system after making changes or installing packages. You don’t need to restart between each package install or anything, but any system-level changes that you make won’t take effect until you restart. The second drawback is that layering packages is not always ideal and working inside docker/podman containers (often via toolbx/distrobox) is the best way to do some tasks. For example, if you’re a programmer and need to install a lot of dependencies to build some program, I find it’s best to create a “pet container” to work in. That doesn’t both me much though, in fact I kind of like that workflow.

So basically, it’s probably not for everyone, especially people who really love to tinker and customizes everything. But if you want a basically unbreakable Linux machine, it’s worth looking into.