Linux Archive
Linus Torvalds, the creator of the Linux kernel and git, is employed by the Linux Foundation. This Foundation is a non-profit organisation dedicated to, as the name obviously implies, the promotion of Linux. The primary use of the funds it collects is to “help fund the infrastructure and fellows, including Linus Torvalds, who help develop the Linux kernel”. The list of megacorporations donating most of the Foundation’s funds is long. The Linux Foundation has twelve platinum members, which donate $500000 per year, followed by twelve gold members, who donate $100000 per year. Below these two primary tiers lie the silver peasants, who each donate $5000-$25000 per year, based on number of employees. Looking at the list of twelve platinum members, I noticed something interesting. Of the twelve platinum companies, six are “AI” companies or companies with massive investments in “AI”: Google, Huawei, Facebook, Microsoft, Oracle, and IBM/Red Hat. Then there’s Samsung Electronics, which is raking in stupendous amounts of money thanks to the “AI” bubble. Additionally, one of the gold members is Anthropic, another major “AI” company and makers of “Claude”, the sloppiest of slopcoding tools. Many of these companies are unimaginably deep in the red when it comes to “AI”, with very little indication they’re ever going to be able to recover any of it. The situation is particularly bad for Oracle and IBM/Red Hat. Oracle’s debt has been downgraded to one notch above junk status because of its “AI” spending, while IBM’s shares experienced the largest crash in its 115 year history only a few days ago. By the way, in the first half of 2025, “AI-related capital expenditures contributed 1.1% to GDP growth, outpacing the U.S. consumer as an engine of expansion”. Fun fact: since most of The Netherlands is effectively a swamp, most of the country’s buildings are built on massive wooden or concrete poles (piles) hammered deep into the ground until they hit something more stable than mushy clay and wet sand. Otherwise, buildings in the country would simply sink into the ground. Every Dutch person who ever lived near a construction site has heard the rhythmic kathunk, kathunk, kathunk, all day long, as the massive piledriver machines spread their gospel. I guess something reminded me of this just now. Anyway, a large chunk of the funding the Linux Foundation, Linus Torvald’s employer, receives is coming from increasingly desperate companies frantically trying to convince a populace deeply skeptical and often downright hostile towards “AI” to spend money on “AI” before the bubble bursts. For some reason, I thought this was interesting.
Only a few days ago we had Linux on the Mega Drive, and someone took that as a challenge, so now we have Linux on the Atari Jaguar. The Jaguar has a very different architecture than the Mega Drive, but does happen to use a processor from the same 68000-family. Interestingly enough, to this day, Linux has architecture code for the 68000-family of processors. 68040, 68030, 68010… and even the original base 68000 processor. All neatly structured under arch/m68k/. ↫ Joel Bueno And, well, that means Linux can indeed be made to work on the Jaguar, with some hacking and magic, of course.
If you have a Sega Mega Drive, you obviously want to run Linux on it. That’s something you can do now. You do need to have an EverDrive, but don’t worry, the port in question contains a custom fork of Qemu for those of us that don’t. I don’t know what else to say, other than I wonder why nobody did this sooner.
My favorite metonymic technology term is “cron job”: even though cron may not literally be the daemon that executes actions on a schedule, we apply the term to anything that walks like a cron and quacks like a cron. As Patrick McKenzie likes to point out, cron jobs are one of the most eminently useful computing primitives. They offer utility that’s almost immediately obvious for plenty of use cases that almost everybody has: do this every day; do that once a month. And yet. You probably shouldn’t use literal cron (or its more modern cousins) for scheduled tasks! In 2026 there are more modern options available, and my favorite is the humble systemd timer. I love systemd timers. If you don’t love them yet, maybe I can show you the reasons why you should love them, too. ↫ Tyler Langlois These are just timers. They are not consuming your computer or taking over the open source world. They do not phone home to Red Hat. These are just timers.
Minimal hardware hasn’t gone away. Millions of machines still run on 1–2 GB of RAM, single-core or early dual-core CPUs, and spinning disks — hardware that mainstream desktop environments treat as essentially unusable. For these machines, the choice of Linux distribution isn’t just a preference; it’s an engineering decision that determines whether the system is functional at all. The five distros covered here — Lubuntu, Linux Lite, antiX, Puppy Linux, and Tiny Core Linux — each make distinct trade-offs across kernel selection, init systems, package management, and desktop weight. Understanding those trade-offs is what lets you match a distro to a hardware ceiling rather than just guessing. Why RAM constraints still shape distro design Modern desktop Linux assumes several gigabytes of RAM almost by default. GNOME and KDE Plasma idle comfortably at 800 MB to over 1 GB before any applications are open. On a machine with 512 MB or 1 GB total, that’s a non-starter. Lightweight distributions work around this by replacing heavyweight compositors and service stacks with minimal window managers, stripped init setups, and carefully curated default installs. This isn’t a niche concern. According to Linux desktop market share data, global Linux desktop share reached 4.7% in 2025, up from 2.76% in 2022 — roughly 70% growth in three years. A meaningful portion of that growth comes from users reviving hardware that Windows no longer supports efficiently, making lightweight distros increasingly relevant rather than increasingly obsolete. Init systems and package managers that matter The init system is one of the most consequential choices a lightweight distro makes. Lubuntu and Linux Lite ship with systemd, inheriting Ubuntu’s parallel boot, journald logging, and unified service management. The trade-off is memory: systemd carries more overhead than simpler alternatives, though the gap is measured in tens of megabytes rather than hundreds on modern builds. For machines with 1 GB or more, that overhead is usually acceptable given the operational convenience. antiX, Puppy Linux, and Tiny Core Linux take the other path, using sysVinit, runit, or BusyBox-based init scripts. These approaches are simpler by design — no journald, no socket activation, just scripts that run sequentially. On machines with 256–512 MB of RAM, this difference is tangible: fewer background processes, lower memory baseline, faster boot. Package management matters just as much. APT-based distros (Lubuntu, Linux Lite, antiX) pull directly from Debian and Ubuntu repositories, which means current Firefox and Chromium builds with timely security patches. Those browsing crypto-native web platforms will find that GamblingInsider’s list of crypto casinos covers operators that rely heavily on WebAssembly, Web3 wallet integrations, and modern TLS — all of which require an up-to-date browser stack that APT-based distros deliver more reliably than custom package systems. Puppy Linux and Tiny Core use their own extension formats (PET and .tcz respectively), which offer flexibility but can lag behind upstream security releases if not actively maintained. Desktop environments that don’t bloat the kernel LXQt (used by Lubuntu) and XFCE (used by Linux Lite) represent the practical ceiling for lightweight desktop environments that still offer a complete user experience. Both composite cleanly on older GPUs, support modern display configurations, and consume roughly 200–300 MB of RAM at idle — a fraction of what GNOME or Plasma require. According to TechRadar’s lightweight distro guide, these environments strike the right balance between usability and resource economy for most real-world low-spec scenarios. antiX goes further, defaulting to IceWM or Fluxbox — window managers rather than full desktop environments. There’s no compositor by default, no file manager daemon, no notification service running in the background. The result is an environment that can run comfortably in under 150 MB of RAM, though at the cost of a steeper configuration curve. Tiny Core strips things down even further, offering a graphical desktop that fits in a 20 MB ISO and runs entirely in RAM once loaded. Beyond personal hardware revival, lightweight distros have found real traction in kiosk builds, thin clients, and single-purpose terminals. Puppy Linux and Tiny Core are particularly well suited here: they boot from USB, run entirely from RAM, and can be re-imaged in minutes if a device is compromised. XDA-Developers’ coverage of lightweight distros notes that these environments are actively used to repurpose aging hardware for focused browser-based workloads — a category that includes everything from remote desktop clients to web-based productivity tools. Which distro actually fits your hardware ceiling Lubuntu and Linux Lite are the pragmatic choice for machines with 1–2 GB of RAM that need a stable, maintainable desktop. The Ubuntu base means reliable security updates, broad hardware support, and access to the full Debian ecosystem. If systemd overhead is tolerable and the user wants something that behaves like a conventional desktop, either of these works well. antiX is the right call when you’re targeting genuinely old hardware — machines with 32-bit CPUs, 512 MB or less of RAM, or unusual driver requirements. The systemd-free approach and Debian base give you both minimal overhead and a large software repository, a combination that’s hard to beat at that hardware tier. Puppy Linux and Tiny Core are specialists: reach for them when portability, live-USB use, or truly extreme resource constraints are the defining factors. Matching the distro to the actual hardware ceiling, rather than defaulting to the most familiar name, is what separates a functional low-spec system from a frustrating one.
If you visit the Flatpak website today, it lists, as the very first advantage of the project: “Build for every distro: create one app and distribute it to the entire Linux desktop market.” If you then move on to the list of supported distributions, you’ll see the usual suspects, but also distributions like Void Linux, Guix, and Alpine. These last three all have one thing in common: they use an init system other than systemd, because Flatpak doesn’t care what init system you use. It seems that for the next major version of Flatpak, however, that’s going to change: systemd will probably become a dependency for Flatpak. Speaking at the Linux App Summit, Arian Vovk and Sebastian Wick held a great talk about the future of Flatpak. The current version of Flatpak will continue to see a ton of improvements, but at the same time, the limits of what can be done with its decades-old design have become harder and harder to work around. As such, they’re also planning for and working on what they call Flatpak Next, or perhaps Flatpak 2.0, which is effectively a rewrite of Flatpak based on what they’ve learned over the years, making use of modern technologies and ideas that have gained ground since the initial design of Flatpak 1.x. It’s important to note that everything discussed during the talk is planning, and not a single line of code has been written yet. This means that all of these plans are subject to change, and as the work progresses over the coming years, the end result may turn out very different from what’s been detailed in the talk. In addition, and I can’t stress this enough: if anything in this discussion gives you even the smallest of inklings to go and harass, attack, insult, or otherwise bother anyone involved in Flatpak, systemd, or related technologies, please be so kind as to book an appointment for a yoga class or whatever. It seems like you need it. Right at the onset of the talk, Vovk and Wick explain that they want to move the permission management from Flatpak into the service layer, through a new service called systemd-appd. Systemd-appd gives applications an identifier and stores their permissions, and then this data can be queried by the rest of the system. In turn, this enables a slew of other features, not least of which is subsandboxing. At the moment, the plan is to introduce this feature in the current version of Flatpak, thereby introducing a dependency on systemd into Flatpak. From what I understand from Vovk, they were intending to be “super considerate” of distributions and people not using systemd, which I take to mean we’d eventually end up in a situation very similar to systemd-logind, which was extracted from systemd into a separate daemon, elogind, so that distributions using other init systems could still make use of desktop environments depending on systemd-logind. I imagine Flatpak developers wanted to make as many affordances as realistically possible for something similar to happen to systemd-appd, thus ensuring Flatpak would remain available on distributions not using systemd. Obviously, people who are using distributions like Void or Alpine were concerned about the future of Flatpak on their systems. If Flatpak gains a hard dependency on systemd, Flatpak would no longer work on distributions without systemd, so the talk raised questions – sadly, it seems the questions were directed at someone not technically involved with Flatpak development, and his replies were not particularly helpful and often just downright insulting and inflammatory. Even though he’s not involved in Flatpak development, enough people assumed that he was, and a toxic brew stirred. Users with genuine, friendly questions about the future of Flatpak on their systems were met with derision and insults, and it spiraled out of control from there, drawing in the rabid anti-systemd Red Hat conspiracy lunatics (and worse). Things got progressively worse for everyone involved, particularly for Flatpak’s developers. And so we ended up at the situation where everyone’s mad and Flatpak’s developers are “not feeling inclined to spend time on that shit anymore” when it comes to accommodating and making affordances for distributions and people not using systemd. The end result will most likely be that any future Flatpak dependency on systemd will be stricter, and making any independent elogind-like daemon will be much harder than it was going to be. Nobody wins, everybody loses, all because some people thought it necessary and productive to be insulting and inflammatory. As things currently stands, it’s very likely that over the coming years, Flatpak will gain a dependency on systemd, possibly without any affordances for an independent daemon to replicate systemd-appd functionality on distributions that do not use systemd. In other words, Flatpak would no longer be able to boast that it enables “Build for every distro: create one app and distribute it to the entire Linux desktop market.”, as it would no longer be distribution-agnostic. And that’s a shame, because Flatpak fills a real need for users, regardless of whatever init system they use. Which is apparently something some people base their entire identity on, because they’re weirdos.
You may think you know what “long-term support” means when picking a Linux distribution and version, but judging by the multitude of utterly wrong takes and deeply confused users I come across online, I’m starting to get the feeling that in fact, no, you don’t know what it means. KDE’s Nate Graham is seeing the same confusion, and has published a blog post going over what LTS really means in the Linux world. People seem to think that an LTS release means it’s going to be more stable, have fewer bugs, and receive support for a certain set period of time. The reality is that only that last one really applies, sort-of. LTS generally means you’re going to be using a Linux distribution version where you’ll get security fixes and possibly maintenance updates for a set number of years, but you won’t be getting updates with new features or other updates that aren’t security fixes. The purpose of an LTS release is to more or less freeze itself and its packages in time, so that users know exactly what they’re getting. However, part of being frozen in time means any bugs, crashes, and hardware support are also frozen in time. The end result is that LTS releases will often have wildly outdated package versions, and those outdated package versions will most likely contain a ton of bugs and issues that have long been fixed in subsequent releases – subsequent releases you’re not getting, because you’re on an LTS release. LTS releases are fairly stable and reliable as long as you use the most popular software from their included software repositories. So in the circumstances when this stops being the case, I think sometimes people can feel betrayed. They think, “I thought this was supposed to be stable! Why didn’t anyone fix this bug yet? Where’s my long-term support?” But Debian, Ubuntu, and Kubuntu never promised any level of stability, reliability, or absence of bugs. They promised that the version-locked software in their repos would receive security fixes for a certain number of years. Ubuntu and Kubuntu also offered a certain amount of non-guaranteed best-effort hardware compatibility improvements and non-security bug fixes. ↫ Nate Graham This causes major problems for upstream developers. People who use an LTS release will be using versions of packages that are out of date and full of bugs that have already been fixed in later versions, but they don’t know that, so they end up reporting these old bugs that have been fixed ages ago as if they’re new. If you’re an LTS user and you experience a persistent bug and subsequent crash in Kwin, you’re most likely going to complain at the Kwin developers, even if the Kwin developers have already fixed this bug 18 months ago. Every week there’s at least a few developers in my Fedi timeline rolling their eyes at Debian users reporting bugs fixed ages ago and getting mad when told they should complain at Debian developers for not backporting the fix. So many LTS users seem to think that LTS equals increased stability, fewer bugs, and fewer crashes, but that’s just not what LTS is for or what it claims to offer. Sticking to specific (major) versions of packages means not you’re not only missing out on new features and changes – which might be desirable for you – but also on bug fixes. With LTS, as they say, the bugs are also stable.
There is one specific way in which the non-corporate open source projects typically document how their infrastructure work: not at all, and Flathub is no different. The full picture likely lives only in my brain, and while it could be sorted out by anyone (especially in this LLM age, yay or nay), why should it only be me thinking at night about all the single points of failure? Like any system that evolved naturally, it’s all over the place. It’s tempting to tell its history chronologically, but even then, it’s difficult to find a good entry point. Instead, this post focuses on what happens when users call flatpak install; later entries will cover the website and, finally, the build infrastructure. Buckle up! ↫ Bart Piotrowski As time goes by and more and more issues with Flatpak are addressed, I feel my attitude towards the technology change somewhat. I’m still very much a traditional package manager type of person, and will opt for my distribution’s repository if the versions they have are up-to-date, but I’m no longer audibly groaning if an application I want is only really available as a Flatpak. For the increasing number of normal, average users switching to Linux, Flatpak is probably the right way to go, especially since it can easily coexist with your traditional package manager. The only part of the linked article that made me raise my eyebrow was the reliance on Fastly, which seems to form an important linchpin of the whole Flathub stack. Fastly is an American company, and while they support Flathub entirely for free, the state of the world does have me wonder if this couldn’t evolve into a problem in a myriad of ways, perhaps through questionable people acquiring Fastly or through pressures from the clown car US administration. I’m sure it’s all fine, but it’s hard not to think of these things in this day and age.
If you’re sick of Chrome OS on your Chromebook, or can find a Chromebook for cheap somewhere but don’t actually want to use Chrome OS, have you considered postmarketOS? Since I was kind frustrated with ChromeOS, I decided to take a look at something that I knew supported my Lenovo Duet 3 for some time: postmarketOS. For those who don’t know, postmarketOS is an Alpine Linux based-distro focused in replacing the original OS from old phones (generally running Android) with a “true” Linux distro. They also seem to support some Chromebooks because of their unique architecture and, luckily, they support my device under the google-trogdor platform. ↫ kokada PostmarketOS is aimed at smartphones primarily, but supports other formfactors just fine as well. The Duet 3 is one of the tablet-like devices it supports, and it seems most things are working quite well. In fact, judging by the postmarketOS wiki, quite a few Chromebooks have good support, and with Chromebooks being cheap and dime-a-dozen on eBay and similar auction sites, it seems like a great way to get started with what is trying to become a true Linux for smartphones.
You can find beauty in the oddest of places. WSL9x runs a modern Linux kernel (6.19 at time of writing) cooperatively inside the Windows 9x kernel, enabling users to take advantage of the full suite of capabilities of both operating systems at the same time, including paging, memory protection, and pre-emptive scheduling. Run all your favourite applications side by side – no rebooting required! ↫ Hailey Somerville Yes, this is exactly what it sounds like. Hailey Somerville basically recreated the first version of WSL – or coLinux, for the old people among us – but instead of running on Windows NT, it runs on Windows 9x. A VxD driver loads a patched Linux kernel using DOS interrupts, and this Linux kernel calls Windows 9x kernel APIs instead of POSIX APIs. A small DOS client application then allows the Linux kernel to use MS-DOS prompts as TTYs. This is a great oversimplification, but it does get the general gist across. Anyway, the end result is that you can use a modern Linux kernel and Windows 9x at the same time, without virtualising or dual-booting. This might be one of the greatest hacks in recent times, and I find it oddly beautiful in its user-facing simplicity.
Version 7.0 of the Linux kernel has been released, marking the arbitrary end of the 6.x series. Significant changes in this release include the removal of the “experimental” status for Rust code, a new filtering mechanism for io_uring operations, a switch to lazy preemption by default in the CPU scheduler, support for time-slice extension, the nullfs filesystem, self-healing support for the XFS filesystem, a number of improvements to the swap subsystem (described in this article and this one), general support for AccECN congestion notification, and more. See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 7.0 page for more details. ↫ corbet at LWN.net You can compile the kernel yourself, or just wait until it hits your distribution’s repositories.
It may sound unbelievable to some, but not everyone has a datacenter beast with 128GB of VRAM shoved in their desktop PCs. Around the world people tell the tale of a particularly fierce group of Linux gamers: Those who dare attempt to play games with only 8 gigabytes of VRAM, or even less. Truly, it takes exceedingly strong resilience and determination to face the stutters and slowdowns bound to occur when the system starts running low on free VRAM. Carnage erupts inside the kernel driver as every application fights for as much GPU memory as it can hold on to. Any game caught up in this battle for resources will surely not leave unscathed. That is, until now. Because I fixed it. ↫ Natalie Vock The solution is to use cgroups to control the kernel’s memory eviction policies, so that applications that should get priority when it comes to VRAM allocation – like games – don’t get their memory evicted from VRAM to system RAM. Basically, evict everything else from VRAM before touching the protected application. This way, something like a game will have much more consistent access to more VRAM, thereby reducing needless memory evictions that harm performance. It’s a clever solution that makes use of a ton of existing Linux tools, meaning it’s also much easier to upstream, implement, and support. Excellent work.
One day, I suddenly wondered how to detect when a USB device is plugged or unplugged from a computer running Linux. For most users, this would be solved by relying on libusb. However, the use case I was investigating might not actually want to do so, and so this led me down a poorly-documented rabbit hole. ↫ ArcaneNibble (or R) And ArcaneNibble (or R) is taking you down with them.
Bootc and OSTree represent a new way of thinking about Linux system deployment and management. Building on container and versioning concepts, they offer robust and modern solutions to meet the current needs of administrators and developers. ↫ Quentin Joly Slowly, very slowly, I’ve been starting to warm up to the relatively new crop of immutable Linux distributions. As a heavy Fedora user, opting for Fedora’s atomic distributions, which use bootc and OSTree, seems like the logical path to go down if I ever made the switch, and this article provides some approachable insights and examples into how, exactly, it all works, and what benefits it might give you. It definitely goes beyond what I as a mere desktop user might encounter, but if you’re managing a bunch of servers or VMs in a more professional setting, you might be interested, too. I’m still not convinced I need to switch to an immutable distribution, but I’d be lying if I said some of the benefits didn’t appeal to me.
The team behind Tyr started 2025 with little to show in our quest to produce a Rust GPU driver for Arm Mali hardware, and by the end of the year, we were able to play SuperTuxKart (a 3D open-source racing game) at the Linux Plumbers Conference (LPC). Our prototype was a joint effort between Arm, Collabora, and Google; it ran well for the duration of the event, and the performance was more than adequate for players. Thankfully, we picked up steam at precisely the right moment: Dave Airlie just announced in the Maintainers Summit that the DRM subsystem is only “about a year away” from disallowing new drivers written in C and requiring the use of Rust. Now it is time to lay out a possible roadmap for 2026 in order to upstream all of this work. ↫ Daniel Almeida at LWN.net A very detailed look at what the team behind Tyr is trying to achieve with their Rust GPU driver for Arm Mali chips.
We talked about Nemin’s first impressions of the Guix System as someone coming from a Nix environment, but today they’ve got a follow-up article diving into the experience of creating new packages for Guix. I spent about a week packaging WezTerm and learning the ropes of being a Guix contributor along the way. During the packaging process I stumble many times, only to stand back up and figure out a solution. I also explain some of my complaints about the peculiarities of the process, but also provide plenty of praise about of how much the system tries to enable you to do your job. Finally, I also touch on how positive the experience of the code review was. ↫ Nemin’s blog These are the kinds of content a rather niche system like Guix needs. Guix isn’t exactly one of the popular picks out there, so having level-headed, honest, but well-written introductions to its core concepts and user experience, written by a third party is going to do wonders for people interested in trying it out.
But NixOS isn’t the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme, GNU’s sanctioned configuration language. I’ve been following Guix for a bit, but it never felt quite ready to me with stuff like KDE being only barely supported and a lot of hardware not working out of the box. However, now that (after three years) Guix announced its 1.5.0 release with a lot of stuff stabilized and KDE finally a first-party citizen, I figured now is the best time to give it a fresh shot. This post captures my experiences from installation to the first 3-4 days. ↫ Nemin’s blog If you’re interested in Guix, but aren’t quite sure if you want to take the plunge, this article does a great job of showing you the ropes, listing what issues you might run into, some pitfalls to avoid, and so on.
I’ve been terribly sick for a few days so we’ve got some catching up to. Let’s first take a look at how Windows is doing. People often say Linux is “too much work.” And I agree. They’re completely justified to complain. There’s the documentation page diving, the forums, the reddit threads. And, most importantly, you have to basically rewire your brain and stop expecting it to behave like Windows used to. But I looked at the list above and realized: Windows is now also too much work. And the difference with Windows is that you’re going to do all that work while actively fighting your computer only for it to be undone when the next surprise update comes and ruins everything. You might be thinking “just disable updates, man” or “just install LTSC”, or “just run some random debloat script off of GitHub”. Why? Why would I jump through all these hoops? I’d rather put in the effort for an OS that knows what consent is and respects me as a user. ↫ Bogdan-Mihai Mosteanu You know how in most theme parks they have various different rides for all kinds of people? There’s the wild and crazy over-the-top deathcoasters for the ultimate thrill seekers, the more gentle wooden coasters for those who like a thrill, but not over-the-top. There’s the swinging ship-type things for thrill-seeking accountants who seek their thrills predictably. There’s a game of Russian roulette played in the backlot. For the kids, there’s the classic spinning tea cups. And then there’s the public transport service dressed up as an old-timey steam train that just brings you to your destination without any issue, silently doing its thing, the unsung backbone of park logistics. Commercial operating systems like Windows and macOS are the games of Russian roulette, predictably unexpectedly shooting you in the face every sixth time you pull the trigger. That’s not my vibe. I want my operating system to be that steam train, and desktop Linux is the only thing that fits that bill – and it’s very clear more and more people are discovering that too.
Your mission, should you choose to accept it, is to sneak into the earliest parts of the boot process, swap the startup config without breaking anything, and leave without a trace. Are you ready? Let’s begin. ↫ Jynn Nelson Genius.
The solution the Flatpak team is looking into is to use virtualisation for the graphics driver, as the absolute last-resort option to keep things working when nothing else will. It’s a complex and interesting solution to a complex and interesting problem.
