Linux Archive
Amos B. Batto has published an incredibly detailed look at the state of Linux on smartphones. It’s an excellent read you really shouldn’t skip. Five years ago, Linux phones looked like they were poised to become a viable alternative to the Android/iOS duopoly that has an iron grip on the mobile phone industry. Sadly, after a brief flash of activity and community engagement with the release of the Purism Librem 5 and the PINE64 PinePhone in 2020, the Linux phone market has generally stagnated. This stagnation occurred partly because of the problems at Purism and PINE64, but also because the available Linux SoC’s weren’t up to the task of running a modern smartphone, and the hardware industry wasn’t providing any good alternatives with good free/open source drivers. In addition, Plasma Mobile and Phosh were still inchoate mobile interfaces at the time, and there wasn’t a good distro option to run these interfaces on Android kernels with a normal integrated mobile SoC. The poor performance of the PinePhone and Librem 5 and the problems with the PinePhone Pro and the Librem 5 refunds sapped people’s enthusiasm and willingness to take a chance on the next Linux phone. Fortunately, all of these conditions are changing, and I believe that there is now the possibility that Linux could finally become a viable alternative to Google’s Android and Apple’s iOS in the mobile space, just like desktop Linux has become a viable alternative to Windows and Mac OSX on the PC over the last three decades. This isn’t to say that mobile Linux will fundamentally challenge the business of Google or Apple, but the conditions are ripe for a small market to arise for Linux phones, similar to the way that people can currently buy Linux PCs from a number of small companies, such as TUXEDO, System76, Purism, Slimbook, ThinkPenguin, Ubuntushop.biz, Entroware, Star Labs, Juno, Laptop with Linux, Linux Certified, ArkPC, etc. ↫ Amos B. Batto I’m not quite as optimistic as Batto, and that’s almost exclusively down to how running Android applications through compatibility layers will remain an absolute necessity for anyone trying to use one of these Linux smartphones today. As long as crucial applications and services required to function in a modern society, like banking, messaging, government services, and so on, require the use of an Android application when using a Linux smartphone, I just don’t think any significant number of people will be switching over. What’s needed is something that will force these crucial services to become available on platforms other than Android and iOS, since I don’t think any of them will do so of their own volition. The only way I can see this happening is if the European Union, spurred on by our desire to reduce our dependence on adversarial US companies, mandates that several services marked as crucial must make themselves available on platforms other than Android and iOS. I doubt that will happen, but I honestly don’t see Linux smartphones becoming anything more than a mere curiosity you fiddle with at home, while carrying an Android phone or iPhone as your actual phone.
Chimera Linux is a relatively new Linux distribution, and quite a unique on at that, as it combines the core tools from FreeBSD, the LLVM toolchain, and the Musl C library instead of the usual suspects. Despite being relatively new, it still has some serious pedigree as the project was started by Nina “q66”, who was part of the Void Linux team. At Void, she maintained the various PowerPC/POWER ports of the distribution until Chimera became her sole focus. Nina published a detailed blog post today about how the Chimera team builds the tooling for their distribution, as well as the goals it’s trying to achieve. It covers everything from a bit of personal history, the rationale behind the project, who it’s catering to, how its tooling works and why, and the infrastructure they’ve built that underpins it all. There’s a lot to process here, with one of the most interesting little details – at least to me, as someone who has two POWER9 machines – the fact that Chimera started with the ppc64le target only. The article is an incredibly interesting look at not just the how of Chimera, but also the why, which makes for some really fascinating reading.
Qualcomm, yesterday, promising Linux support for the new Snapdragon X2 processors: Linux on Snapdragon X2 Series is moving from early bring-up toward a more complete upstream developer experience. Core support is landing, Hexagon NPU and Adreno GPU work is progressing, and real laptops with Snapdragon X2 Series processors are already beginning to boot Linux. ↫ Qualcomm’s promises from 2026 Interesting, but I feel like I’ve heard these exact words before. Qualcomm, two years ago, promising Linux support for the then-new Snapdragon X processors: It’s been our priority not only to support Linux on our premium-tier SoCs, but to support it pronto. In fact, within one or two days of publicly announcing each generation of Snapdragon 8, we’ve posted the initial patchset for Linux kernel support. Snapdragon X Elite was no exception: we announced on October 23 of last year and posted the patchset the next day. That was the result of a lot of pre-announcement work to get everything up and running on Linux and Debian. ↫ Qualcomm’s empty promises from 2024 These promises were not at all kept. Two years later, Linux support for Snapdragon X laptops is still spotty, broken, and limited, confined to just a few bespoke Ubuntu builds, which don’t even offer full support either. It’s a complete mess, effectively unusable, and highlights once again that big technology companies are compulsive liars. I have little faith in these new promises, but who knows – maybe this time it’ll be different. Probably not, though.
Want to run something a little more exotic on your server? How about GNU Guix? It has been a month since migrating my home server to GNU Guix. Managing OS state declaratively through Git has eliminated configuration drift, and Guile Scheme provides a cohesive environment that complements Emacs. While adapting to a smaller package ecosystem and managing substitute timing requires occasional adjustments, the stability, reproducibility, and container isolation make it a dependable foundation. ↫ Wai Hon I’m definitely noticing an increase in interest in Guix lately.
If you ask most people which operating system a racehorse uses, most of them would say none. And that’s quite explainable. Horse racing appears as an age-old sport, and on the surface at least, it appears as if it has nothing to do with technology. But in reality, horse racing has become one of the most tech-forward sports out there, with piles of data and information that are processed on every single race. Lightweight GPS units transmit a horse’s position while it’s running, databases process race information, and broadcast systems turn telemetry into graphics. Then we have wagering platforms that handle huge volumes of transactions on big events in the blink of an eye. So horse racing needs a powerful operating system that supports custom integrations and data processing. The truth is that beneath many systems like this sit technologies familiar to almost every modern software engineer, such as Linux. With that said, it is important to mention that racecourses and racing tech suppliers rarely publish a neat diagram highlighting the exact operating system that runs every server. So, let’s find out how Linux, Real-Time OS, and open-source software are helping the horse racing industry do its thing. The Horse Is Now a Moving Internet of Things Device First, let’s talk about how data is gathered and why horse racing companies actually need a good operating system. For instance, the Gmax Race system used by Total Performance data and Equibase places lightweight GPS trackers on horses and streams a bunch of information, including position, speed, stride length, running order, timing, and more. On top of that, this system is designed to operate without relying on ordinary cellular service or racecourse Wi-Fi, and its data can feed television graphics, display boards, and online visualizations. StrideSAFE goes a step further, but from a different, often more important perspective. It is designed to make horse racing safer for horses. Its three-ounce GPS and accelerometer unit collects around 2,400 movement data points per second while a horse races, which allows algorithms to examine even tiny changes in gait that would be extremely difficult to observe with the naked human eye. This technology is already used on big events like the Kentucky Derby and the Breeders’ Cup. But all of this data can also be used for Breeders’ Cup predictions. Expert handicappers often dig deep beneath the surface and want to see how a horse moves and performs before making a bet. Why Is the Software Important? A normal laptop can occasionally pause for an operating-system update without bringing Western civilization to an end. An embedded tracking device has less freedom. It has to wake sensors, timestamp measurements, process signals, manage wireless communication and keep doing those jobs predictably while the horse underneath it is travelling at racing speed. That is the world of real-time computing. A real-time operating system, or RTOS, is designed around predictable timing. Rather than concentrating primarily on giving a user a pleasant desktop experience, it makes sure important tasks happen within defined time constraints. Public documentation does not identify the specific embedded operating system inside Gmax or StrideSAFE units, so naming one would be speculation. But Total Performance Data itself has described embedded real-time systems as directly relevant to its technology. When former Google engineering executive Jeremy Doig joined TPD’s board, he specifically referred to applying his background in “embedded realtime systems” to the company’s live sports telemetry. Then the data leaves the horse and meets Linux. Once information reaches servers, the engineering environment starts looking much more recognisable. Linux has become a standard operating system for servers precisely because it is stable, configurable, and extremely well supported across networking, databases, and cloud infrastructure. Horse-racing companies do not universally reveal their server operating systems, but one unusually transparent example comes from specialist sports technology company Mustard Systems. A current engineering role for its horse-racing team lists a stack including Linux servers, Python, C, Go, PostgreSQL, RabbitMQ, and Kafka. Which makes sense. Racing software often has similar requirements: process large data feeds, store history, move messages rapidly between services, and keep systems available when demand spikes. Why Linux and Open Source Fit Racing So Well Final Thoughts The digital transformation of horse racing is quite easy to miss because the sport is wrapped around that traditional blanket that’s covering all the tech. But technology is already in horse racing, and the operating system is very important in order to process all of that information and make it understandable for humans.
Earlier this year, Natalie Vock made a splash with a set of patches to the Linux kernel that greatly increased performance on AMD GPUs with lower amounts of VRAM. With that work now accepted by upstream, Vock decided to turn their attention to another interesting problem: what if you run out of VRAM, and how can we improve performance when we do? Regardless, what I hope this blogpost can demonstrate is that even if you end up with some memory evicted to system RAM, the slowdown can be manageable. There’s measures that drivers (particularly, the kernel driver) can take to make overcommit work as fast as possible, and even applications can do their part in coordinating with the driver stack to mitigate the effects of their memory being evicted. With everything in place, VRAM overcommit isn’t really as big of a deal as one may think it is at first sight. ↫ Natalie Vock The work Vock has done has already been in SteamOS for a while, and they’re currently in the process of upstreaming it to the vanilla kernel as well. Since this is a complex set of patches and changes, this may take a while, and as such, they’ve prepared custom kernel and Mesa branches for adventurous users. Do note that these branches won’t be maintained much, and are entirely experimental, not as well-tested as the SteamOS kernel, and probably won’t yield the same performance improvements. Still, this is the kind of work that has a material impact for users. Not everyone has a 16GB monster GPU, especially not today with supply chains ravaged and ruined by slopmakers, so it’s great to see the Linux world working to improve performance for everyone, not just the wealthy few.
Version 7.2 of the Linux kernel has been released. Significant features in this release include common attributes support in the bpf()vsystem call, cache-aware load balancing for the CPU scheduler, large-folio support in the Btrfs filesystem, further swap subsystem improvements, improvements to the Landlock security module, support for block devices with inline encryption hardware via the dm-inlinecrypt device-mapper target, and much more. ↫ corbet at LWN.net If you run Linux, you’ll get it sooner or later.
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.
