Or they are just simply not on the happy path. For example, my laptop has been running KDE just fine for years, but my attempts to switch to Linux on my desktop today have turned into a project, as plasma, steam[1], discord, and sometimes kde_powerdevil[2] are crashing every time my monitors turn off.
Linux as an OS is so fragmented that the number of paths are basically innumerable. Many of them are "happy" but they can be hard to find and also change from year to year.
I have a machine that has run Debian 11 and 12 with no issues but 13 hung before launching the UI. Fixable from the terminal but still, super un-happy path!
KDE on SUSE vs on Debian vs on Kinoite and with various sound demons, file systems, file browsers etc will surely differ in ways that are beyond the direct control of the kDE devs too.
Steam Frame is running SteamOS on ARM, and is capable of playing games standalone, which implies ARM support in Steam. Through granted, it could be in a limited form.
They'll need that either way if they want to get back onto macOS, even if it's separate binaries and not a translation layer. At this point I think Steam basically doesn't work on Mac? Since the x64 Macs are legacy and the new ones are aarch64
It technically works since ARM macs can still run x86 binaries. But it's so slow and buggy, and the selection of playable games so slim that there is almost no point.
So, in the specs for the mini-pc, it claims the video out can do 4K @ 120Hz (even faster if displayport). I assume the 4K @ 60Hz you saw is from the "4K gaming at 60 FPS with FSR" line.
I reckon it can probably stream at 4K@120 if it can game at half that.
> I wish Linux would offer a solution to that. No idea what it would look like though.
It probably would have to be an isolated environment to run in. Something like the Secure VM efforts adopted for desktops, perhaps with a small trusted hypervisor instead of CPU vendor extensions. Anything else I can think of starts to restrain what software you can run on your machine, or becomes highly invasive in ways similar to Anti-Cheats on Windows, both of which would be rejected by the general Linux community. (Through, it's not like anyone was asking Microsoft either before implementing anti-cheat and trampling on system integrity, at least until Microsoft started requiring signed drivers)
However, given that a generic blackbox implementation enables DRM and binary encryption there will probably still be opposition. It gets particularly nasty if it's given access to something like a full TPM to unlock application data in the same way a TPM can unlock an encrypted drive for your OS. That would make it the penultimate closed source application, which is really anti-ethical to a number of communities. (open source, modding, game/app preservation...)
When it’s running in reverse then it’s acting as an air conditioner blowing cold air into the house. So usually the heat strips are used then to reheat the air and prevent it from blowing cold air in the middle of winter. Not strictly necessary but most people demand it.
The article is a bit a of jumble of thoughts, but I believe that advice is aimed at girls who aren't liking and therefore not matching. Some lines that mention this particular grouping:
> Only 50% of girls sent 10 likes in their account lifespan.
> 10% of girls that finish the onboarding never send any pass or like, ...
> We have plenty of girls that can scroll through 300 profiles and not like anyone and deleting their account saying "I dont like anyone" well
I would say if your laptop starts doing sudden thermal shutdowns then liquid metal should be your first suspect. However, I do have a slightly older all-amd variant (G513QY) which may behave differently. Comparing my case with the article, they noticed CPU throttling and had dark/black marks on the CPU, whereas I was encountering GPU thermal shutdowns with marks on both GPU and CPU.
Rough timeline for my laptop was:
14 months in, manually under-clocked discrete GPU to prevent thermal shutdowns
20 months in, complete cooling failure on GPU, replaced liquid metal with PTM7950
Most of my systems avoid a boot partition, boot process is BIOS/UEFI -> grub (from EFI partition or MBR block) -> linux (from /boot in root).
However I do got one where UEFI boots the linux kernel directly, /boot is the EFI parition. And there it feels like a bit of a waste to have to expand /boot or insert a bootloader into the boot process because initramfs is getting bloated with files that aren't critical to mounting root.
I agree that abandoning virtual memory entirely brings back old problems, but there is a middle ground of a single virtual address space. This limits flushes to page table changes and makes it easier to move the MMU out of the CPU cores/caches. Page table size issues can be mitigated by larger or mixed size pages (and already is in x86_64/ARM)
[1] Might be https://gitlab.gnome.org/GNOME/gtk/-/issues/5984
[2] https://github.com/rockowitz/ddcutil/issues/556