Anyone using Pop!_OS with Cosmic? I tried it when it was first released, but I looks like they've done a lot of dev work to it and it's improving all the time. Considering installing it again... Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .
tl;dr: After the long and painful goodbye to my Star Labs StarBook Mk VI AMD , I caved and did what every Linux nerd eventually does, which is buying a ThinkPad . I left Team Red and chose the X1 Carbon Gen 14 Aura Edition with Intel ’s new Panther Lake Core Ultra X7 368H vPro , 32GB of (sadly soldered) RAM and the 2.8K OLED panel. It’s a sub-1kg, repairable carbon-fibre slab that runs Linux beautifully and that I can service (or get serviced) pretty much anywhere on the planet thanks to the widespread availability of parts and service points. Migration consisted of installing the latest Gentoo distribution kernel (to have all necessary modules available), pulling the SSD with my hardened Gentoo installation out of the StarBook , dropping it into the Lenovo , and booting the system. Plus one round of recompiling all packages for the new architecture, but that’s… details. Sadly there’s no Coreboot , the Intel Management Engine is silently plotting in the background, and you’re trusting a closed firmware stack from a vendor with an interesting past . If you’re looking for a fully liberated laptop, this sadly isn’t it. But then again, even in 2026, sadly almost nothing really is . As some of you who suffered through the last two updates already know, the first half of 2026 was, to put it mildly, a hardware massacre . Phones broke, a tablet got preemptively retired, head- and earphones died, and my primary workstation (the Star Labs StarBook Mk VI AMD ) suffered increasing stability issues and finally bricked itself during a firmware update . I wrote at length about why I ultimately decided to part ways with Star Labs , so I won’t rehash all of it here, but the short version is, that with the Star Labs laptop I loved the idea, I loved the design, but I could no longer rely on the hardware, and I needed a device that I could repair no matter where in the world I happen to be. I had been eyeing the ASUS ExpertBook Ultra with the X9 388H for a while, but it remained a paper launch, and after my misadventures trying to source ASUS hardware across the globe, I lost faith in the service and spare-part situation, so I did the boring, sensible, adult thing and bought the laptop that has authorised service centres and spare parts on every continent: A Lenovo ThinkPad X1 Carbon . Wait, weren’t you Team Red? , you might ask. I was, and in spirit I still am. For the better part of a decade I bought almost exclusively AMD. But as I ranted about previously , with AMD laptops it’s always something . The ports, the display, the chassis, the TDP, something always forces a compromise I don’t want to make at this price point. Panther Lake made enough of a splash, performance-per-watt-wise, that I was willing to give Team Blue another shot, despite Intel ’s long history of monopolistic behaviour, security holes and general d!ckhead-ish behaviour. And to be fair, AMD’s behaviour isn’t much better these days anyway . The ThinkPad X1 Carbon Gen 14 Aura Edition is Lenovo ’s 2026 flagship ultrabook. It’s the fourteenth iteration of a line that, at this point, basically is the archetype of the “business ultrabook” . The “Aura Edition” branding is an Intel co-marketing thing, and the single X7 sticker went straight into the bin. Speaking of which, yes, it’s going to get stickerbombed , but that’ll take some time. The interesting part however is not the age-old ThinkPad aesthetic, but what lies underneath, namely a brand-new Panther Lake chip, a redesigned repairable chassis, and crucially proper Linux support straight from the manufacturer. My specific configuration is the one I’ll be reviewing here, but keep in mind that Lenovo sells this chassis in a dozen permutations. These figures reflect my specific machine type ( ) and the official platform specs come from Lenovo’s PSREF spec sheet . Speaking of which, on Linux you can read the model, marketing name and serial straight from the DMI tables (handy for a PSREF lookup), and pull a broader hardware overview with / : The star of the show is Intel ’s Core Ultra X7 368H vPro , part of the Panther Lake generation. After years of Intel embarrassing itself, this is the most interesting mobile chip the company has shipped in a long while, and the first one in ages that made me, a committed AMD user, go back to Team Blue . It’s a 16-core, 16-thread unit, and no, there’s no HyperThreading here. The cores break down into: It carries 12.5MB of L2 and 18MB of L3 ( Smart Cache , shared), and Intel rates it at a 25W base (PL1) with an 80W maximum turbo (PL2). Lenovo configures it for roughly 30W sustained in this chassis, which is a step up from the ~17-20W that last year’s Lunar Lake Gen 13 ran at. What makes Panther Lake architecturally interesting is that it’s a disaggregated, multi-process design. The compute tile is built on Intel ’s own 18A node, while the GPU tile is fabbed by TSMC on N3E . Note: The X1 Carbon Gen 14 is offered “up to” the X7 368H , and only the X7 tier gets the 12-core Arc B390 iGPU. Every cheaper Core Ultra 5 / 7 option makes do with Intel ’s weaker standard integrated graphics. That GPU split is the whole reason I went for the X7, as it is, in my opinion, the only configuration worth buying, if you care about graphics at all. In Geekbench 6 the 368H lands at around 2,870 single-core and somewhere between 16,422 , 16,885 and 17,318 multi-core. These (along with the graphics and AI numbers below) were captured on a *cough* factory *cough* Windows 11 install on its 256GB SSD. For context, XDA measured the mid-tier Core Ultra 7 355 review unit at 2,610 / 11,263 in Geekbench 6 . And for comparison, my Star Labs StarBook Mk VI AMD scores 1,906 / 6,245 in Geekbench 6 , with an OpenCL score of 13,051 and a Vulkan score of 11,932 . Note: Despite having set the power setting on Windows 11 to Performance , the Geekbench report still lists the Power Plan as Balanced . For my purposes, however, the more relevant metric is real-world responsiveness, and the chip is quick . Cold-compiling ungoogled-chromium on Gentoo, juggling a few dozen terminal panes, a couple of browsers and the usual pile of background daemons and it still doesn’t break a sweat. On the StarBook would normally report something between 12 to 48 hours for ungoogled-chromium , depending on how many pre-compiled system libraries the specific release would be able to utilize without errors. On the X1 that number more than halved, with the average runtime being well below six hours. Here are the exact timings for a couple of the usual heavyweights, on the StarBook versus the X1 : The integrated GPU is Intel ’s new Arc B390 with 12 Xe3 cores clocked up to ~2.5 GHz, with hardware ray tracing included. The Xe3 iGPU scores 56,930 in Geekbench 6 ’s OpenCL test , and between 49,213 and 63,874 in Vulkan , which puts it roughly in the territory of a discrete desktop GeForce RTX 3050 . Unlike NVIDIA ’s hardware, however, the B390 is still backed by open-source, in-tree drivers. I’m not much of a gamer, but for the curious, here’s how a handful of titles fare on the B390 : So nothing that’ll trouble a discrete GPU, but for an iGPU in a sub-1kg ultrabook, playable frame rates in actual games at sensible settings is more than I’d ever have asked of integrated graphics a couple of generations ago. What surprised me the most out of all of this was the Cyberpunk 2077 result, since I would never have expected an iGPU sitting inside a lightweight ultrabook to hold somewhere between 40 and 60 fps at Ultra settings and a 1920x1200 resolution in what is still one of the most punishing games you can throw at a machine, and yet it does exactly that, with the frame rate only ever falling off a cliff the very moment I enabled one of the ray-traced lighting presets. The curious part, however, is that this drop isn’t a case of the hardware lacking the feature altogether, because the Arc B390 actually ships with native hardware ray tracing , carrying one dedicated ray-tracing unit per Xe3 core, so twelve RTUs in total. The question is whether the silicon can be fed fast enough to do ray tracing at a frame rate worth having, and the answer seems to be “nope” . Ray tracing, and BVH traversal in particular, generates an enormous amount of scattered, incoherent memory accesses, and unlike a discrete card that gets to service all those random reads out of its own dedicated, high-bandwidth GDDR , an iGPU like the B390 has no VRAM of its own and instead shares the very same LPDDR5x pool as the CPU, which leaves it to contend for a fraction of the bandwidth that a proper GPU would have. And once you throw in the fact that a dozen RTUs is a tiny number next to the many dozens you’d find on a discrete Arc , Radeon or GeForce , as well as the shared ~30W power budget that the GPU has to split with the rest of the SoC , ray tracing ends up being the one workload in which the gap between this little chip and an actual graphics card still shows. None of that really bothers me, though, since ray tracing on an iGPU was always going to be more of a party trick than something I’d lean on day to day, and for the rare occasions on which I actually do need that sort of horsepower , I can always just hang an external GPU off one of the Thunderbolt ports somewhere down the line. This appears to be a route that, judging by the various reports of people running eGPUs over Thunderbolt on previous X1 Carbon generations under Linux, all the way from a relatively tame Akitio Node with an NVIDIA card on a Gen 5 to a frankly unhinged dual- RTX 3090 contraption hanging off a Gen 9 running Fedora , appears to work well enough in practice. And while a fair share of those write-ups inevitably involve someone making their peace with NVIDIA ’s proprietary driver, that’s precisely the part I’d happily skip, because the far more appealing option for me would be to pair the laptop with one of the Radeon cards I already own (such as the RX 6700 XT that currently lives inside my other computer ). Thanks to the open, in-tree driver there’s no out-of-tree blob to wrangle in the first place, native kernel-level Thunderbolt hotplug is simply there , and on Wayland in particular, which is what my Sway setup runs on, the whole thing sidesteps the old X.Org gymnastics entirely. But it remains to be seen how good/reliable a setup like that can work. The Ollama version used here is and it was compiled using . The Vulkan version is and Mesa . Here are the results of the LLM benchmark : According to the results , the Ultra X7 appears to perform similarly to e.g. the AMD Ryzen 9 7900 12-Core Processor , the AMD Ryzen AI 7 350 with Radeon 860M , the 12th Gen Intel Core i9-12900H , and the AMD Ryzen 7 7700X 8-Core for the DeepSeek R1 8b model. Anyway, there’s also an NPU rated at 50 TOPS, which I still need to test. Here’s the first gripe with the Lenovo , which is the RAM. Sadly my model only comes with 32GB of LPDDR5x-8533 memory, and it’s soldered. On the X7 the memory should be able to run at the full 9600 MT/s, but for whatever reason Lenovo decided that, unless you’re willing to add another $1,000 on top, you’ll only be getting the “slower” RAM. And while the SoC theoretically supports up to 96GB, Lenovo will only sell you a maximum of 64GB. Swallowing a non-upgradeable 32GB config stung, especially in the current “AI” -driven hardware climate , in which most people (including myself) are looking at prolonged lifespans for their hardware. I gambled on 32GB being enough for a terminal-centric workflow for the foreseeable future, and so far it is, but I’d be lying if I said I was okay with not being able to change my mind later. Storage-wise the machine shipped with a bare-minimum 256GB M.2 2280 TLC Opal self-encrypting drive, which I promptly removed. The slot itself is PCIe Gen5 with sequential reads near 12,850 MB/s (with a Gen5 drive in it), but it only supports single-sided 2280 drives. Luckily my 2TB SK hynix Gold P31 ( ), which had been living in the StarBook since I upgraded it , is exactly that, so it dropped straight in. Yes, the P31 is only a Gen3 drive in a Gen5 slot, but it goes without saying that SSD pricing these days is absolute nonsense. Also, while the Opal self-encrypting drives are cool and all, I run my own full-disk encryption with rather than relying on the drive’s implementation. The 2TB I already owned is plenty, and I do not care that much about sequential SSD benchmarks that I’m unlikely to ever notice in practice. The 2.8K OLED panel is, frankly, the nicest display I’ve had on a laptop. It’s a 14", 16:10, 2880x1800 OLED running at 120Hz with variable refresh (it’ll drop as low as ~30Hz to save power), rated at 500 nits SDR and covering 100% of DCI-P3 . It also carries an HDR 500 True Black certification worth precisely nothing to me on Linux, but there it is. In proper ThinkPad fashion, the hinge lets the lid lay completely flat, which is something that my initial candidate, the ASUS ExpertBook Ultra , would not have been able to do. Critically for me, Lenovo ships it with an anti-reflective and anti-smudge coating, which means it’s matte enough to actually use in various lighting conditions. Coming from the StarBook ’s perfectly-fine-but-unremarkable 1080p IPS panel, the jump to a high-refresh OLED is the kind of upgrade you don’t think you need until you have it. Blacks are black, like, really black and text is razor-sharp, and at 120Hz animations are buttery smooth. My only real reservation is the usual OLED burn-in over a multi-year ownership period, especially with things like a Waybar that’s always there, not moving and barely changing any of the text it displays. I might need to tweak that part of my setup long-term. If there’s one thing one might complain about it’s the brightness ceiling. The panel tops out at 500 nits, which, for today’s standards is not a lot . However, personally I find the display bright enough and I tend to run it at around 50% brightness throughout the day while indoors, which visually is equal to the StarBook ’s display running at almost 100% brightness. As an added bonus, the OLED PWM dimming runs at a far higher frequency than older panels, so those of us sensitive to flicker can stare at it all day without the headache. The port selection is great, especially compared to the StarBook : Wireless duties are handled by an Intel BE211 Wi-Fi 7 card with Bluetooth 5.4, and my unit also has NFC because yolo . Lenovo additionally offers an optional 5G WWAN modem with a nano-SIM slot, which I skipped, because I’d rather use my dedicated router , and because Linux support doesn’t seem to be quite there yet anyway. The Intel WLAN card, on the other hand, is supported out of the box by the in-tree driver under Linux. The webcam is a 10MP RGB + IR module (with ImmerVision wide-FOV optics), a Time-of-Flight sensor for presence detection, and, most importantly, a physical ThinkShutter a.k.a. a way to physically cover it without the use of dot-stickers, which is a very welcome feature. The IR camera is there for Windows Hello , which is useless to me, but the -on-IR crowd will appreciate it. On my specific model (with the OLED display) the webcam has not been working , as of the time of writing this post. As for the keyboard, the following will probably earn me some a lot of hate, and while I agree that compared to every other laptop keyboard the ThinkPad ’s integrated one is a masterpiece with 1.5mm of travel, slightly concave keycaps, a sane arrow-key layout, spill resistance, and two backlight levels plus an auto mode, … I frankly still prefer typing on my own keyboard Sonshi-style . But yeah, don’t worry, if you’re the type of person that exclusively uses the ThinkPad ’s keyboard then you will be happy to hear that it’s a solid integrated keyboard, still. Also, don’t ever talk to me about keyboards. Note: Two Gen 14 tweaks that are worth mentioning are the key legends, which are now centred and spelled out in full ( “Backspace” rather than a glyph), and the power button, that has migrated into the top-right of the keyboard deck with the fingerprint reader built into it, right next to the longish Delete key. The red TrackPoint nub, however, is still superior to every touchpad I have ever operated (including the integrated one) and I’m happy that Lenovo is still holding on to it. One buying tip that I’m glad I caught beforehand concerns the touchpad configuration. Lenovo offers two different touchpads on the X1 Carbon , the good old regular touchpad with actual buttons on its upper border, and a haptic ForcePad , which technically seems to be the sleeker one. However, choosing it will cost you the discrete physical TrackPoint buttons that only the regular touchpad brings. If, like me, you actually plan to use the nub, the plain mechanical “diving board” pad keeps those buttons, and that’s the one I went for. Lastly, audio finally comes from a stereo system that the Space Frame now fires upward through the keyboard deck rather than down at the desk. It’s startlingly loud for a 14" laptop, though it’s still laptop audio, so better get headphones. That said, these sound like Bowers & Wilkins 603s in comparison to the bad speakers on the StarBook . This is one of the main reasons I picked the X1 Carbon over its alternatives. For Gen 14 , Lenovo completely redesigned the internals around what they call a Space Frame , which is a structural redesign that lets them mount components on both sides of the mainboard, shrink the internal footprint, and fit a 70% larger fan for better sustained performance. Materially it remains the classic X1 Carbon composition however. The device has a carbon-fibre lid over a magnesium (and aluminium) body, rated to MIL-STD-810H and starting at 0.977kg, which is absurdly light for a 14" machine. Lenovo did let it grow in one dimension though, as the Carbon is now a gentle wedge of roughly 7.7mm at the front to 17.6mm at the back. The 14th iteration is hence a notch chunkier toward the rear than the near-uniform Gen 13 , which is a deliberate trade to make room for the bigger fans. The footprint is otherwise unchanged, so existing sleeves will probably still fit. The soft matte finish feels great, but I will stickerbomb it nevertheless, in an effort to camouflage my workstation as a somewhat unhinged comic book that nobody in their right mind would ever try to steal. Going back to the Space Frame design, for someone whose past year has been defined by hardware failures, the Lenovo is ultimately a properly and easily repairable device, thanks to its new build. iFixit gave it a 9/10, all while, for context, the MacBook Pro 14" only scored a 4/10. And frankly on the X1 the score seems well-deserved. To get into the Space Frame you undo four screws, and the bottom comes off. The keyboard deck then lifts away magnetically, without the need for any tools. The battery comes out with a few screws and a connector that releases itself, while the SSD, the fans, the I/O ports and even the display assembly are all individually serviceable. Lenovo even publishes step-by-step repair videos with photos and difficulty ratings for each repair. After the StarBook saga, which ended with me hunting down a CH341A programmer and having to reach out to Star Labs directly to un-brick the thing, this properly documented Lego-brick serviceability, that actually has a replacement-parts market online and offline, is exactly what I wanted. The battery is a 58Wh cell that is barely up from the Gen 13 ’s 57Wh, as Lenovo is seemingly leaning on Panther Lake ’s efficiency rather than on capacity, and this is probably my second-biggest gripe. While it appears that in looping-video tests reviewers got anywhere from 9.5 to 14 hours (depending on configuration and brightness) my realistic mixed working day in browsers and terminals lands around 6 to 7 hours. The moment I’m starting to compile things, however, this figure takes a nosedive to something closer to 2 to 3 hours. 58Wh is definitely on the small side for a 2026 flagship. However, with higher-density battery cells becoming available, an added lightweight power bank could be a viable compromise for days on which the integrated battery won’t last long enough, while still accounting for a total weight below that of your regular T14 . Lenovo bundles a relatively compact 65W USB-C brick that rapid-charges the cell to 80% in about an hour, and because it’s bog-standard USB-C PD, any charger or a dock pushing >60W will run it at full performance. “You wanted repairable and Linux-friendly, why not a Framework?” , I hear you asking. It’s a fair question, and generally I would like the idea behind Framework ’s computers to succeed. I would like to see a future in which you can put together your laptop the same way you do your standard ITX build. I would love to see independent manufacturers producing parts for laptops like the Framework , that would allow you to, I don’t know, replace the default keyboard with an HHKB variant, or that would make it possible to pick which processor, which RAM and which GPU you’d like to have in your device. And while Framework kind of built this “ecosystem” for themselves, six years into their saga the third-party components are still nowhere to be found, with a handful of exceptions which, however, are clearly driven by Framework (think the Cooler Master case or the DeepComputing RISC-V mainboard). I don’t mean to rain on anyone’s parade here, but unless the ecosystem broadens significantly, so that users can find third-party expansion cards, and mainboards, and keyboards, and macropads, and graphics modules, and are not dependent solely on Framework (a company that might at some point enshittify ), I don’t quite see the point of putting up with a device that is significantly bulkier, has had an inferior build quality and comes with its fair share of issues . However, none of this would have been a true deal-breaker for me, if it wasn’t for Framework supporting a seventh-grade computer science project over actual Linux distributions, which cooled my enthusiasm considerably. Because let’s be real, when comparing purely the hardware itself, the new Framework Laptop 13 Pro seems like a legitimately good machine, despite its soulless Apple -esque aesthetic. The X7 Panther Lake option that comes with a modular LPCAMM2 RAM definitely beats Lenovo ’s soldered memory outright, and the brighter 700-nit display might also work better than the X1 in outdoor environments, despite it not being as beautiful to look at as Lenovo ’s OLED. Lastly, the 74Wh battery of the Framework packs significantly more juice into the 13 Pro , which is definitely a plus over the lightweight 58Wh of the X1 Carbon . Apart from that, however, I’d like to think that the build quality and specifically the weight-to-power ratio of the Gen 14 Lenovo remains superior to the Framework Laptop 13 Pro . And yes, this is subjective, but the X1 Carbon is simply the nicer device when compared to the Framework , with its expansion-card slots, visible seams and sort-of makeshift aesthetic. The ThinkPad , with its clean lines and total absence of visual clutter looks and feels like a finished, more premium product. And with around 400g less in weight than the Framework 13 Pro , which also happens to be noticeably thicker, the X1 is more of the type of device that I don’t mind carrying around . Now, as for Linux compatibility, it turns out that Panther Lake is, somewhat surprisingly, in excellent shape on Linux. Phoronix ran the X7 358H through around 300 benchmarks on Ubuntu 26.04 with the Linux 6.19 kernel and found it already “in very good shape for both performance and power efficiency, exceeding expectations […] relative to prior generation Intel laptop processors as well as the AMD Strix Point competition” . For a brand-new architecture, that is about as good a verdict as you can hope for, and it matches my experience with the newer 7.x kernels. A few things that I’ve stumbled upon during my first few weeks with the Lenovo that still need to be sorted out are … For anyone considering this machine for Linux, you’ll want a recent Kernel version. Panther Lake support landed and matured around Linux 6.19 / 7.x, so don’t try to run this on some ancient eNtErPrIsE LTS kernel and expect the Xe3 graphics or power management to behave. Speaking of which, the Xe3 iGPU uses the modern DRM driver and the Intel Mesa stack. On Wayland/Sway it’s been almost flawless and does everything, from hardware acceleration, to external displays. The actual switch from the StarBook to the ThinkPad was almost painless, which is the highest praise I can give it. With the hardened Gentoo that I’m running the “migration” consisted of basically 1. taking the SK hynix P31 out of the StarBook , 2. putting it into the ThinkPad , 3. and booting (and 4. recompiling the whole system *cough* ). The one sensible precaution I took was switching from my hand-rolled, hardware-specific kernel to Gentoo’s pre-built binary kernel on the latest Linux 7.x series for the move. A distribution kernel ships with essentially every important driver, so it doesn’t care that it suddenly woke up on completely different silicon. Once I’d confirmed everything worked, I could go back to trimming the kernel down at my leisure. My Sway/Wayland setup , my dotfiles and my entire terminal-centric workflow are deliberately system-agnostic , so beyond the kernel swap there was almost nothing to reconfigure. Where it did take a little while, though, was the rebuild. My system had been optimised for Zen 3 (the StarBook ’s Ryzen ) which means the entire thing had been compiled with . So I changed the flag to suit the new Panther Lake and rebuilt the whole system from scratch with the usual command, which amounted to somewhere around 1600 packages churning through the compiler before everything was once again native to the hardware it was actually running on. Note: The system ran just fine on the Panther Lake , despite having been compiled with Zen 3 architecture optimizations, with the exception of browsers ( Ungoogled Chromium , LibreWolf ). Those would suffer from crashing tabs all the time, with a corresponding in . However, it is nevertheless a good idea to rebuild the whole system, rather than only the obviously affected packages, to avoid any surprises down the road. On top of that there were some hardware-specific bits to sort out. I had to install additional firmware ( , ), and I had to migrate from to in for packages like and to use the Intel hardware, and I also needed the package. Now for the part that, as a privacy-focused user, is pretty bad. The X1 Carbon Gen 14 runs Lenovo ’s proprietary UEFI firmware, and the Intel Management Engine is present and active. There is no Coreboot port for this machine, and there almost certainly never will be. This was, hands down, the hardest pill to swallow. One of the few things the StarBook promised (even if Star Labs took actual years to ship the first version for AMD) was an eventual Coreboot path. On the Lenovo , however, you are trusting a closed firmware blob and a processor with a co-processor, engineered by a company that is partially owned by the US government , that you cannot audit, sitting below your operating system, with its own network-capable stack, that was built by a Chinese company . Lenovo specifically does not have a spotless record here. This is the company that shipped the Superfish adware with a self-signed root CA that actively broke TLS on consumer machines in 2015, and that same year was caught using the Lenovo Service Engine firmware mechanism (via Windows' WPBT ) to silently reinstall software from the BIOS. To be fair, both of those scandals hit the consumer IdeaPad / Yoga lines rather than the business ThinkPads , and they’re a decade old, but they’re a reminder of what this vendor can do when seemingly nobody’s watching. Of course this is not unique to Lenovo and the exact same IME -and-no- Coreboot reality applies to that Framework I was just comparing it to, to the ASUS I was chasing, and to essentially every modern x86 laptop you can actually buy and use as a daily driver in 2026. There is no liberated, Coreboot -running, ME -less machine with a current CPU, a 2.8K OLED and worldwide service. You either run a decade-old ThinkPad as a matter of principle, or you make peace with the fact that the firmware layer is a compromise and that you simply cannot guarantee to not be compromised . If a fully open firmware stack is a hard requirement for you, then this laptop, like nearly all of its contemporaries, will disappoint you, and it’ll likely not be for you. None of this is cheap, and the ongoing hardware crisis hasn’t helped. Pricing starts at around $2,000 for a Core Ultra 5 with the FHD IPS panel, a configuration like mine lands well above that, with maxed-out units sailing confidently past the $3,000-mark. I was lucky to get a good deal (relatively speaking) on my specific device, but ultimately paying top money for a 32GB, soldered-RAM machine still stings. However, as I explained , after the year I’ve had, reliability and serviceability were worth the premium to me. The ThinkPad X1 Carbon Gen 14 Aura Edition is not the laptop I would buy in a perfect world. In a perfect world I would get something with user-replaceable RAM, a bigger battery and an open firmware stack with no Management Engine lurking beneath it. All of that ideally designed and at least partially manufactured by a European company that could potentially tip the global scales away from the US/China duopoly. But we don’t live in that world, and given the options that actually exist, this is the most sensible machine that would fit my life right now. It’s astonishingly light, the OLED is gorgeous, Panther Lake is fast and efficient on Linux, the Space Frame makes it repairable, and there’s an authorised service centre for it on every continent I’m likely to find myself on. After the year of hardware attrition I’ve had, boring reliability and serviceability anywhere turned out to be the features I valued most. If the StarBook was the dreamy choice, that dream ended in continuous glitches and ultimately a CH341A programmer . This is now the pragmatic choice where the Lenovo is the tool that just works and it (hopefully) continues to do so for the foreseeable future. PS: Make sure to check future updates if you’re interested about the long-term experience with the Lenovo X1 Carbon . 4x Cougar Cove performance cores, up to 5.0 GHz 8x Darkmont efficiency cores, up to 3.8 GHz 4x Darkmont low-power efficiency cores, up to 3.6 GHz 3x Thunderbolt 4 (USB-C), with at least one on each side, so I can charge or dock from whichever side the cable lands on 1x USB-A (5Gbps), always-on so it’ll charge a device with the lid shut, although it’ll probably continue to permanently host my YubiKey 1x HDMI 2.1 1x 3.5mm headphone/microphone combo jack, although I’d wish it would be on the right side rather than the left … as mentioned before, the webcam that doesn’t seem to work yet and that reports as follows in : … some issue with the UCSI power supply code, which is reported in as follows: … some GPU engine resets every once in a while, reported as: … an audio issue where there’s a ton of noise over the 3.5mm jack as soon as any sound plays, but which instantly stops when the audio stops. I cross-tested this under Windows 11 and experienced the exact same effect, so maybe it’s not at all a Linux issue, but more like a hardware or firmware issue. Luckily, I can work around this issue by using my DAC or my audio interface .
I’ve been very happy with my Y1 MP3 player over the past 9 or so months. I take it with me everywhere! It’s a companion on my commute, it’s a focus tool in my open office, it’s a way to have a single-purpose device that doesn’t have the distractions of my glass Everything Rectangle and, as the phone ages, a way to mitigate its now-horrible battery life by using a different device with a different battery. As God confounded the language and scattered the people building the tower of Babel, I have confounded the functionality and scattered the responsibilities of the apps on my iPhone. My wife brought up a point that is completely fair: why am I using this $60 piece of crap when she, through great sacrifice, bought me a top-of-the-line iPod Classic 160GB for the same purpose? Sure, that was in 2012, but it was expensive . It’s still worth $350+ today, right? So what the hell, I dug it out of my Closet of Cables and Mystery. Plugged it in. Battery charged. It booted. My music was still in it, last addition to the library wa 2014. Fantastic! I bought a protective case, some new 30-pin USB cables because the ones I had remaining were all frayed and kind of scary, and I got ready to swap the Y1 with the iPod for a while as an experiment. Then my first hurdle: I wanted to add some songs to it. I know Rhythmbox , my player of choice 1 , has an iPod plugin on its list of installed plugins. I plug the iPod in, it shows up! Hooray! I try to drag music onto it: no dice. Checking I see some very threatening notices that HFS+ with journaling is not supported by Linux at all . So I know on Mac it’s a simple command line call to turn journaling off on a volume so it’s probably a trivial process, but I have no working personal Apple desktop machines. Have no fear: I found a chunk of unvetted C that directly alters the raw filesystem to do it for me on Linux! Boom! We’re in business! Back to Rhythmbox. Drag the music I want over to the iPod. It copies! Bingo! Only: no bingo! I disconnect the iPod and it says ’no music.’ The music is on the device, but the iPod’s music database got clobbered. Well crap. So now I know Gtkpod is purpose built for this. Apparently the iPod Rhythmbox plugin isn’t any good on these models, so let’s try that. No dice. It repeatedly hangs, crashes, and when it does work it still fails to correctly update the database. Still ’no music.' Maybe this is all because it’s still HFS+ and not FAT? It seems like most tools assume you’ve liberated your iPod and you’re using it in Windows mode, not Mac mode. So I attempt to wipe the drive, but can’t for the life of me figure out how to do it correctly with Gtkpod or just plain old partitioning tools. Looks like I need to restore the hardware from iTunes for this route. What about Rockbox ? I use it on my Y1. The annoying thing is that I have to manually update the database on the actual device, whereas the typical iTunes stock experience is one that updates the database iteratively as a matter of course of adding music. But the trade-off is no more struggling with Gtkpod and friends, which is higher friction than the drag-and-drop experience of putting music on my Y1 anyway. And I saw this totally cool skin on Reddit I want to try ! I already have the Rockbox utility on my machine from installing it onto my Y1. It sees my iPod but dies on an SSL handshake talking to rockbox.org while downloading resources. I don’t remember this happening last time I ran this. I downloaded and ran the utility on another Linux machine and got the same result. I gave up about 45 minutes into building the tool myself from source. Now I need a Windows machine to use iTunes in Windows to reformat the iPod. I have a debloated Win11 VM in Gnome Boxes, I fire that up and go in to iTunes, I plug in the iPod, then I go to set up USB forwarding so the VM can do its magic and – “USB Forwarding is Not Supported in the Flatpak version of Boxes.” So I uninstall the Flatpak and migrate my disk images from to somewhere less Flatpak-specific and install the dnf version of Gnome Boxes. I migrate the machine over, set up forwarding, everything seems to be working. Only USB forwarding forgets the device when it disconnects and I have to reconnect multiple times. It also doesn’t see the device when it’s in that raw flash mode, so it can’t forward to install the iPod firmware. This is a dead end. Okay, so I have one Windows machine in my house: my kid’s 2013 Intel Macbook with Boot Camp and a debloated copy of Win10 we solely use to play Minecraft Java together with. Only ever since I set up a local server with GeyserMC and Floodgate we’ve been playing mixed me-on-Java/him-on-iPad-or-Switch-Bedrock so the laptop is mostly neglected. So I install iTunes and wipe the iPod. Takes awhile, because I have to install a cascading series of drivers, but it eventually works. The firmware was the latest for the Classic, released 2009. Then I remember that 18 year old bit of early enshittification of iTunes: the iPod can’t simply be its own library you add/remove items from. I was falling out of love with Apple about that long ago , and I had forgotten how low and slow we’ve been dealing with the world of You Will Own Nothing enshittification that’s been inflicted on us. No wonder we’re so complicit, we’re pushing a quarter century of Everything Rental now. So to do iTunes proper I’d need enough storage on this laptop to hold the music in my library on it, be logged in, and sync a selection of it to the iPod. I remember this now: they made life harder and worse on purpose. And now we have Spotify, where we never had freedom or affordances at all. I remember thinking what an incredible act of charity it was that Spotify let your have an offline playlist on your device. I would have expected offline first as a matter of course in prior hardware/software cycles. Rhythmbox and Gtkpod still don’t sync correctly. Same database issues, so nothing I’d done with wiping the iPod had fixed the fundamental first issue. So I install the Rockbox utility on the Windows machine. I have to install some additional Windows components to get it to load, but it works. I flash the iPod. It doesn’t boot. I flash it again. It boots. Hell yes. And I have my cool theme. So I drag music over. 16000 tracks to start, takes 2 hours to copy. HDDs are slow . Afterward I have to manually update my database from Rockbox, which takes hours . I fall asleep as it runs. I can hear the physical spinning platters. It’s a very strange experience having a device with a real life magnetic disc hard drive again. The future we occupy today is strange in the UX of the iPod and its software feels modern enough but small aspects like an HDD feel anachronistic. The Rockbox experience is a lot nicer on the hardware it was designed for than the crappy Rockbox-in-emulation on an Android device that has absolutely no business whatsoever claiming it can run Android. It is responsive, it doesn’t crash, all the plugins work, etc. Next rabbit hole is investigating battery/storage upgrades. There are cheap and expensive options, I need to go through them. As is my wont, I do not need bluetooth on anything I own, but a modern USB-C connector might be nice? Do I want to go the SD card route or a proper SSD? That is for another time. Anyway, no normal person would inflict this experience on themselves willingly, and would likely give up at some point close to the beginning. It is a reminder that much like if you stay very quiet near a playing iPod you can hear the whir and rattle of the HDD. If you stand very quietly near me you can hear the fluttering and tapping of dozens of moths smashing their bodies against the inside of my skull in the space where a brain should be. I am not aware of any other MP3 player that can handle large music libraries this well and still have a presentable UI. TUIs usually suck, “new” apps are all super slow because of Wirth’s Law. ↩︎ I am not aware of any other MP3 player that can handle large music libraries this well and still have a presentable UI. TUIs usually suck, “new” apps are all super slow because of Wirth’s Law. ↩︎
I've been following WisdPi's development of various 5 Gbps and 10 Gbps Ethernet adapters for the past couple years. They use newer Realtek Ethernet chips, which sometimes have performance quirks—most frequently encountered under Linux. In today's video, I tested the new WisdPi 10G Ethernet Expansion Card for Framework computers. It fits in any available Framework Expansion slot—even on the Framework Desktop. But Expansion Cards use USB-C for their connection to the mainboard—and therein lies the rub...
This is my problem statement and proposal for a TacoSprint 2026 project 🏄. Nix, or store-based systems , are a class of package managers that use a well-defined prefix to store all packages. This can be for Nix or for Guix. This is simple. It makes rewriting paths to binaries or libraries easy. Derivations only need to the strings with the full store-path; becomes for instance. What if you wanted a different path, one not prefixed at the root ? This could be desirable if you don’t have Nix installed already or are missing necessary permissions – “rootless Nix”. Well, Nix already lets you specify a different store-path today but there is a catch! Let’s take a look at a simple example. We can build two different ways. The first command builds and installs at and the second at using and mount namespaces. Notice both have the same hash . This is important. By keeping the hash the same, we can leverage the precomputed derivations from binary substituters like https://cache.nixos.org . Ok, so what’s missing? If you are using tools like Bazel or Buck2 they likely already employ their own sandboxing via namespacing for builds. Integrating Nix into these ecosystems becomes incredibly impractical because we run into nested user namespace and mount restrictions. We can ask to use an alternate store prefix, without chroot and mount namespaces but it has a big gap. The hash is now 😭 It’s even more disastrous. Changing this simple string cascade-invalidates the entire dependency graph. You are now waiting 4 hours for GCC to compile just so you can print “Hello World” from a different folder. 🫠 This means we cannot leverage the public cache. This gap is called out by the Nix documentation today. Does it have to be that way? What if we could install Nix binaries anywhere , without using namespacing or . Can we have our cake and eat it too? 🍰 Nix needs relocatable binaries . The problem is that the store-prefix is part of the derivation itself so it affects the hash calculation. We don’t have to specify the full store-prefix everywhere. What if we used relative paths ? 🤔 Let’s look at one place the full paths are written today in the binary via . When this program runs, the dynamic linker looks at to find its shared dependencies. The loader in Linux however natively supports the variable which translates to “the directory containing the executable.” [ ref ] We could instead write the to be . If we did that then changing the store would cause no hashes to change. No recompilation. 🥳 Okay, so are we done? Well, like most things the devil is in the details. 😈 Before the dynamic linker can read the to find the necessary libraries, the Linux kernel has to load the dynamic linker itself. This path is stored in a different ELF header called (Program Interpreter). Unfortunately, the Linux Kernel does not support in this field as of today . We run into the exact same kernel limitation with the shebang line in scripts as well. When we execute a script, the kernel parses the (shebang) and expects an absolute path. Support for is also lacking as as of today . We cannot use relative paths reliably here unless they are relative to the current working directory, which breaks the moment you run the script from anywhere else. To achieve true relocatable binaries, we need to bypass these kernel limitations. historically would never make sense for in the Linux kernel because “Why would you want your dynamic linker to be found relative to the file!?”. Nix has changed that assessment. There are a few ways we could attack this: I believe augmenting support in the Linux kernel is the right approach. The beauty of Nix is we can even patch the kernel today in any NixOS machine for this support. As a final cherry on top, we can include additional metadata on every derivation whether it’s relocatable . 🍒 We could patch the Linux kernel so that is supported in and the shebang. We wrap every binary with a small static binary that computes its own location and then invokes the dynamic linker. We need to replace file locations to also leverage language-specific features for relative paths. For instance, in Python we can leverage to access files relative to itself similar to .
Nix and Guix look like rival ecosystems, but under the hood they’re the same “Input Output Machine”. Need proof? 🕵 How about we build a Guix derivation with Nix. First let’s create a super basic derivation in Guix: Hello world . We then ask Nix to build it. 🪄 We ask to use as the Nix store and have it write its state, database and log files in alternate directories, so it does not collide or mess with Guix. Note It’s slightly more complicated. Nix happens to check its SQLite database for the derivation, so we need to register it first. The version of Guix (v1.5.0) I’m using leverages a user that runs inside a private mount namespace where is writable, but everyone else (including me) sees it as read-only. The creates a new private mount namespace so I can mount it as read-write and run the Nix command against it. We just built a Guix derivation using Nix. 🔥 How is that possible? Both take a language frontend, Nix or Guile (Scheme), that compiles to a derivation (recipe) and pass that onto a builder (daemon) that executes it to produce an output. What makes them both special is they both promise the same thing: hermetic builds . Everything needed to build the output is declared in the recipe: sources, environment variables, dependencies, etc. “Under Nix, a build process will only find resources that have been declared explicitly as dependencies. There’s no way it can build until everything it needs has been correctly declared. If it builds, you will know you’ve provided a complete declaration.” – Nix OS Website Guix, specifically the daemon, was forked from Nix early on, and as a result the two are very similar; they both share the same derivation format, ATerm , for instance. Guix is based on the Nix package manager – Guix Website That’s why our earlier example of building the Guix derivation with Nix was possible without much translation. What if we could leverage an existing recipe from Guix in Nix in its traditional ? If we could convert from one recipe file to the other, we could use the existing recipes from Guix in Nix and vice versa. Turns out this is far more feasible than you would think, because Guix is Nix or at least a superset of it. I, with the help of Claude, built a tool to do just that: guix-transfer 🤯. guix-transfer is a CLI tool for performing bottom-up translation of GNU Guix derivations into Nix. Confused? Let us see it in action: Note When you unpack a tarball, tar restores each file’s original permissions, including setuid/setgid bits. Nix’s sandbox installs a seccomp filter that blocks any call that sets these bits, returning “Operation not permitted”. Guix’s early bootstrap uses a Scheme-based (gash-utils) that treats this error as fatal, unlike GNU tar which silently skips it. The fix is , which disables the filter. If it’s not clear what we just did: we took a Guix derivation and all of its dependencies (down to the bootstrap seeds), translated it to a Nix derivation, and built it with Nix. 😲 What is this abomination and how was this possible!? It’s important to revisit what a derivation is, and how it’s used in Nix and Guix to better understand how this is possible. Let’s look at the same basic derivation from earlier, Hello World . You might want to check out my other post on Nix derivations by hand if this interests you 🤓. When we evaluate (nix-instantiate) this derivation, we get a path to a file that contains the derivation in the ATerm format: If we look at the contents of the file, we can see the ATerm representation of the derivation: This has all the information we need to build the output by the builder. At this point, it’s really not Nix specific anymore. The same applies for the Guix derivations. The derivations do not “know” whether they came from Scheme or Nix. It’s a recipe. The insight then is if we rewrite the store paths from to , and swap some builtins (i.e. for ), we can get to build it identically . 💡 The only difference in more complex derivations is that they have dependencies, which are also derivations, and the builder references them so it forms a graph of derivations, each built by the builder in topological order. The leaves of this tree for any non-trivial derivation are the bootstrap seeds: , , , etc. Guix is famous for bootstrapping itself from a 357-byte binary as source [ ref ]. Since at no point do the bootstrap seeds depend on being the prefix, the translated chain builds identically under Nix. walks a Guix graph in post-order and for each derivation: Guix’s is replaced with Nix’s . Same idea, different name. Source files are added to the Nix store, with embedded paths rewritten to their equivalents. Every reference: input drvs, builder path, args, env vars are rewritten to the mapped path. Output paths are blanked as Nix recomputes them via . The result is serialised as JSON and registered with . That’s it. No Nix expressions are generated. No . No mapping of Guix packages to nixpkgs equivalents. The Guix derivation graph is translated faithfully , and builds it. Note Interestingly, takes exactly one URL and cannot fall back. Guix derivations carry lists of mirrors, many of which are flaky or dead. Similar to Nix, Guix operates a content-addressed mirror at that serves any source its CI has ever seen. We leverage this for the instead of the original source URL. Now that we have a way to slurp Guix packages into Nix, we can start to do some diabolical combinations by combining native Nix and Guix packages together! We can take our package we built in Nix and leverage it in a Nix derivation. Nix automatically scans your derivations for anything prefixed with and tracks it as an input dependency. This is similar to how store paths are interpolated when you do something like . If writing the paths raw in the Nix expression is a little too raw for you, we can build something more ergonic pretty easily as well. has an mode that instead will emit the Nix expression for the translated . Let’s look at a slightly more complex example that uses Guix’s to build a derivation with dependencies: We can now convert this to a Nix expression with . We realise the derivation with or we can the Nix expression. Please notice that both produce the exact same hash : . We can now use this Guix derivation like any normal Nix expression, such as the ones you might encounter in Nixpkgs. That means we could even build a that is all of Guix packages available for use. My mind is blown. 🤯 Nixpkgs is known as the world’s largest package repository, and now we have made a way for it suddenly to become even larger by borrowing any derivation from Guix! The real power behind Nix are the derivations and that they are hermetic, declaring any dependency needed. We’ve seen that we can transfer these recipes to any store-based system that has similar qualities and preserve the reproducibility. Guix’s is replaced with Nix’s . Same idea, different name. Source files are added to the Nix store, with embedded paths rewritten to their equivalents. Every reference: input drvs, builder path, args, env vars are rewritten to the mapped path. Output paths are blanked as Nix recomputes them via . The result is serialised as JSON and registered with .
Since the PiKVM came out in 2017, there's been an explosion of IP KVMs. I've tested almost every one . But what are they good for? You can use Remote Desktop, Screen Sharing, or VNC to remote control a computer from anywhere on a LAN. And if you don't have a private VPN, you could use RealVNC , Raspberry Pi Connect , or wire up Tailscale or Pangolin for fully remote access. Those solutions are great, and so is SSH if you don't need a full desktop.
As a heavy emacs user, Guix system seems to be the logical place to rest one’s head in the perpetual distro hop . As an all-or-nothing type guy, I’ve been running NixOS for the better part of a year now, but Guix seems to philosophically align with me. That’s right, forget about pragmatism when you can have ideological purity! But, as one will very quickly comes to find in installing Guix, the militant push to have everything be free software means that if you are installing this system to anything other than a hardwired desktop running some sort of open source video card or a librebooted ThinkPad from 2008 , you will be very quickly out of luck when you want to say, use wifi or run any sort of video encode. If you have the ability to plug your machine into an ethernet port, then you can install guix without much issue, but - the moment ethernet is inaccessible, you have to do a workaround. The mitigation? Baking non-guix into an .iso image and installing from that instead. In this article, I will discuss how I got non-guix installed to my x230 ThinkPad, and the process to get there. Non-Guix is a repository of proprietary drivers and the mainline linux kernel so that you can run Guix on a system that doesn’t have 100% free hardware (which is essentially every computer these days). You won’t hear about it in the mainline Guix channels as it is ideologically in conflict with what Guix is attempting to do, so it’s a bit of a Fight Club type scenario (you don’t talk about it). With that being said, nvidia drivers for GPUs, wifi (broadcom and intel), and some other goodies are available within the repo, so all you have to do is add “non-guix” as a channel in your channels.scm: As we previously discussed, you will have a bad time when trying to install a base Guix .iso on your non-freedom respecting hardware. So, we will go ahead and bake a non-guix .iso for you so that you can use wifi to install your new system. You will install guix (the package manager) on your machine for this. Congratulations, guix is available on pretty much every linux distribution and MacOS. Installation instructions can be found here You can then update with . This will take a bit of time, so go get a coffee and let it run. to your file add: and run once again. You will also have to clone the non-guix repo locally: and then you can finally build the guix system .iso with Again, this will take some time. You will be given a location in which this .iso exists after building it in the /gnu/store when it finishes. Copy that path for the next step. You can now plug your USB key into your machine and we will burn in the image to the disk and make it bootable with : run to find the location of your plugged in drive, then: Congratulations, you now have a bootable non-guix .iso for installation! Reboot your machine and select the usb stick as your boot drive. You can then install guix as normal with the guided installer, when prompted for wifi connection, you can scan for networks and should be able to connect to your SSID without issue. You will have to change some of the generated configuration file before installation. Note the + and - lines: After this, save the file and STOP , you will NOT install normally you will hit Ctrl+Alt+F3 and open a new TTY (scary black screen with a prompt). Hit and type the following: and finally: The system will then install and you will get just one more coffee as you wait. Caffeinated enough yet? Upon completion, reboot, pull the USB stick, and you will have your new shiny Guix system with wifi driver support available. As always, God bless, and until next time. If you enjoyed this post, consider Supporting my work , Checking out my book , Working with me , or sending me an Email to tell me what you think. https://github.com/AidanWelch/guix-blog https://gitlab.com/nonguix/nonguix
This post serves as a personal bookmark and a mirror of this fantastic guide by Ok-Pace-1900 on /r/linux_gaming to ensure that this information does not get lost. I learned the hard way that the GPU I have in a DIY Steam Machine PC, the AMD RX 480, is strictly unsupported by Forza Horizon 6. Forza Horizon 6 will not work for AMD users with GPUs based on the Polaris or Vega architectures and older (for example Radeon 400 and 500 series players). These architectures are below our minimum supported specification. I knew that asking for a refund on Steam would be the easy way out. Deciding against it, I did a quick search for the FH201 error code and stumbled on the Reddit post mentioned above. My CPU is good enough for Forza Horizon 6 (Intel i5-10500), so the additional launch options command that worked for me is the following: Simple fix, but the context around this is actually kind of funny. The way a lot of Windows-only games work on SteamOS is via a translation layer referred to as Proton. With this trick, you can pretend that your GPU has some DirectX features that it actually does not have, but it doesn’t matter since it can be successfully emulated via translation to Vulkan, which the GPU supports well! As a result, I can play Forza Horizon 6 on a hacky SteamOS build, with 1080p low or medium settings. Low settings is a 60 FPS experience, with medium settings some areas like Tokyo can struggle a bit and drop below it to ~40 FPS. Now all I need to do is to get rid of the urge to splurge on a great GPU, which would also require a case and PSU upgrade… Slightly off-topic, but can you monitor your gaming PC via Prometheus Node Exporter and visualize it in Grafana? :)
Hot off the press: this episode is a live recording from Rust Week in Utrecht, just two days ago. On stage with me are two people who hardly need an introduction in the Linux world: Greg Kroah-Hartman , Linux Foundation Fellow, stable kernel maintainer and an embassador for the kernel, and Alice Ryhl , core maintainer of Tokio and one of the driving forces behind Rust for Linux at Google. I have to admit a bit of personal history here: I first wrote about Greg more than 20 years ago for the German online newspaper Pro-Linux . Getting to sit down with him, and with Alice, in front of a live audience to talk about how Rust is reshaping the most important piece of infrastructure on the planet, was a genuine career highlight. We get into the big questions: Why does Alice believe that interop, not rewrites, is how Rust wins inside Linux? How do you carefully weave in Rust while maintaining a 35-million-line C codebase? And what does it actually feel like, day to day, to write kernel code in Rust? “Rust is gonna save the Linux kernel.” — Greg Kroah-Hartman CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch. Start for free today and enjoy 40% off any paid plan by using this link . Rust for Linux is the project bringing the Rust programming language into the Linux kernel. After years of patches, proposals, and heated mailing list threads, Rust is now an officially supported language inside the kernel tree, no longer an experiment. The work spans everything from the build system and the crate to drivers, abstractions over core subsystems and brand-new pieces of infrastructure written entirely in Rust. Greg Kroah-Hartman is a Linux Foundation Fellow, the maintainer of the stable Linux kernel branch, and the maintainer of, among many other things, the USB subsystem , the driver core, sysfs, debugfs, kobject, TTY layer and staging tree. He has been a central figure in Linux for over two decades, has written several books about kernel development, and is convinced Rust belongs in the kernel. Alice Ryhl is a software engineer at Google working on Android and Rust for Linux, and a core maintainer of Tokio , the asynchronous runtime that over 50% of all crates on crates.io directly depends on. Inside the kernel she works on Binder, on async abstractions, and on the bindings that allow Rust drivers to talk safely to the rest of the kernel. Rust Week is an annual conference organized by RustNL. The 2026 edition took place in Utrecht, the Netherlands, from May 18 to May 23. It features talks, workshops, the Rust All Hands, and expert sessions on a wide variety of topics revolving around Rust. This episode was recorded live on stage during the conference. Thanks to the Rust Week team who made this recording possible! Learn more about Rust Week on their website . Linux Docs: USB Subsystem Maintainer - Greg’s first contribution led to him maintaining the USB subsystem, and much more The Register: Happy birthday, Linux: From a bedroom project to billions of devices in 30 years - An interview with Greg celebrating the 30 year anniversary of the Linux kernel Tokio - Another big project maintained by Alice RustWeek: Untrusted data in Linux — How Rust is going to save us - Greg’s talk at RustWeek; Rust is gonna save Linux?! Rust in Production: Rust for Linux - With Danilo, one of the co-maintainers with Greg on the Driver Core subsystem and others Phoronix: New Linux Patch Confirms: Rust Experiment Is Done, Rust Is Here To Stay - The official end of experimental Rust Linux Plumbers Conference - A big conference for all levels of kernel developers std::boxed - The most basic kind of pointer in Rust kernel::list::List - Linux’ linked list Rust binding core lib - The most fundamental parts of the Rust libraries alloc lib - All things in the standard library that only require an allocator, not used by the kernel anymore std lib - The thing most people think of as the standard library, containing things like file access which requires running on a kernel QR code generator for kernel crashes - First Rust code added to the kernel Linux Rust Architecture support - Missing some big platforms like S390 (IBM Mainframes) and MIPS (a lot of consumer networking hardware) sched_ext Schedulers written in Rust - sched_lavd shows promise for video game performance, and servers? Aya - Build eBPF programs with nothing more than Rust and the Linux kernel RustWeek: Completion-based IO - Alice’s talk at RustWeek about IO WE DO NOT BREAK USERSPACE - An e-mail from Linus explaining the mantra in typical Linus fashion Linux clippy config - It’s not pedantic! Rust code style - Coding guidelines of the Linux project for Rust code rustfmt config - Almost vanilla with some ideas for the future clang-format config - Added in 2018 and tabs won! Coccinelle - Semantic code transformation and the reason Greg lives in Europe klint - Custom kernel specific lints, basically a repository of clippy lints for kernel code Rust for Linux Greg Kroah-Hartman on Wikipedia Greg Kroah-Hartman’s homepage (momentarily offline) Greg Kroah-Hartman on Mastodon Alice Ryhl’s website Alice Ryhl on GitHub
This post is a quick tip for anyone else running into issues installing the Palm Pilot desktop software, JPilot on Arch Linux. If you just try installing via , the build will fail as the dependency no longer builds on modern systems. The solution is to first install , then .
Giving lightbulbs a MAC address was a mistake that I’m living with. I’m literally unscrewing lightbulbs to renew their DHCP lease @dbushell.com - Bluesky Instead of enjoying the bank holiday Monday I updated my homelab software. I was ‘inspired’ by the Copy Fail Linux bug to run full distro upgrades. This is my self-hosted update for Spring 2026 (rough documentation to give future me a chance). Monday’s fun risked a week of pain. I do have backups but restoring them on a broken LAN is tricky. I have an ISP provided wifi router to dust off in an emergency. Along with an absurdly long 15 metre HDMI cable I do not care to unravel. My winter update added a hardware fallback but that too requires careful rejigging. I have Proxmox hosts, virtual machines, and Raspberry DietPis . They were all on Debian 12 (Bookworm) with a kernel potentially susceptible to the bug. Minimal Debian installs are perfect because I run everything in Docker anyway. Data volumes are easy to backup or network mount. I can change host at will for any service. Debian is just sensible, well documented no-fuss Linux. I used to run “minimal” Ubuntu server. Following 24.04 I found myself debloating most of the Ubuntu part (i.e. snaps). It sounds like the new coreutils are a CVE party . Glad I escaped before that drama! As it happens, this week’s Linux Unplugged episode had Canonical’s VP of Engineering spewing embarrassing AI platitudes. “Ubuntu is not for you” was the only thing said worth remembering. I updated most of my VMs first because they’re easy to restore if anything fails. I followed Lubos Rendek’s guide . Start with a full package update and then change the package sources before running another step-by-step upgrade. The only non-Debian sources I have are Docker and Tailscale. Yes that means I run Docker inside Proxmox VMs — and you can’t stop me! That’s not even my worse crime… After the Trixie upgrade I found VMs were failing to obtain a LAN IP address. The virtual network device had been renamed from to . I edited and just changed the reference. There is surely a better/more predictable fix but this was the quickest. The same name was used across all VMs so I guess 18 is the magic number. Everything has been stable so far. If issues arise I’ll just nuke and pave from a Debian 13 ISO. Docker config and volumes are backed up independently of the VM images. DietPi has a long Trixie upgrade post I didn’t read. I just curled to bash: I gave the script a cursory glance before hitting enter. I have a Pi 4 running failover DNS and a Pi 5 running my public Forgejo instance . DietPi is ideal because of the tiny footprint; I run Docker here too. Raspberry Pi still hasn’t merged upstream Copy Fail fixes. I’m already in trouble if this bug can be exploited but I did the temporary fix out of caution. I wasn’t going to bother with Proxmox 9 but after a GUI update I was informed version 8 “end of life” was August 2026 . That is soon! I followed the official upgrade guide on my Mini-ITX server . Proxmox has a tool to check compatibility. I saw no red lights so I stopped all VMs, updated package sources to Trixie, and ran the upgrade. It is critical to run again before rebooting. I ran into the systemd-boot issue . Apparently if this is not removed the system fails to boot. If my particular box fails to boot I’m in big trouble because I broke video output and have yet to fix it. I have another Proxmox machine running virtualised OPNsense for my home router. I can’t stop the OPNsense VM and upgrade the host to Proxmox 9 because the host would have no network access. I had two options: I specifically set up option 1 for such a purpose. I went with option 2. I figured any software running in memory is still alive until I reboot, right? I didn’t question whether Proxmox would kill any processes itself (it didn’t). The update was suspiciously fast. I ran again and saw a lot of yellow warnings. Yikes. Eventually I noticed I’d failed to update some sources to Trixie and I’d installed a franken-distro. After fixing mistakes all I could do was reboot and pray for an agonising two minutes. OPNsense is the only non-Debian operating system in my homelab. I manage it entirely via the web GUI. The 26.1 update had quite a few significant changes. My DHCP setup was considered “legacy” and my firewall rules required a manual migration. Despite dumbening my smart home my lightbulbs still demand a WiFi connection. I program them myself to avoid Home Assistant and proprietary apps. Turns out I hard-coded IP addresses (discovery protocols are a joke.) Despite having dynamic IPs they remained stable until the OPNsense 26.1 DHCP update. I had no easy way to identify each light. Why would they name themselves anything useful? That’s how I ended up unscrewing the bulbs one by one to see which MAC address fell off the network. I gave them static IPs on a VLAN for future me to appreciate. And with that, my home network is up to date! Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds. Use my failover VM YOLO it live
☕ Welcome to The Coder Cafe! On April 3, 2026, Salvatore Dipietro, an engineer at AWS, posted a patch to the Linux kernel mailing list. The reason: on a 96-vCPU Graviton4 machine running Linux 7.0, PostgreSQL throughput had dropped to roughly half of what it produced on Linux 6.x. In this post, we will trace what changed in Linux 7.0, how PostgreSQL manages memory, and what role memory pages play in making the problem appear (or disappear). Get cozy, grab a coffee, and let’s begin! The Problem Salvatore Dipietro ran pgbench (PostgreSQL’s standard benchmarking tool) on a Graviton4 processor with 96 vCPUs. The workload was a benchmark doing simple updates at scale factor 8,470 (i.e., roughly a 847 million row table), simulating 1,024 clients and 96 threads. A serious, high-parallelism load designed to stress the system. The results were striking. Linux 7.0 delivered roughly half the throughput of Linux 6.x on the same hardware and workload: Linux 6.x : 98,565 transactions per second Linux 7.0 : 50,751 transactions per second To find where the time was going, Dipietro ran , a Linux profiling tool that samples what the CPU is actually doing. The result was unambiguous: 55% of the machine’s CPU time was spent inside a single function: . The culprit was traced back to a change in how Linux 7.0 schedules processes. Let’s start there. When multiple threads run on a machine, the OS needs to share the CPU between them. That’s the scheduler’s job. But the scheduler also decides something subtler: when to interrupt a running thread and hand the CPU to another. That decision is called preemption , and the answer varies depending on how the kernel is configured. Before Linux 7.0, there were three options: : The kernel almost never interrupts a running thread. A thread runs until it voluntarily gives up the CPU: when it makes a syscall, blocks on I/O, or explicitly sleeps. This was the traditional server default with fewer context switches, higher throughput, and predictable behavior under load. : The kernel can interrupt a running thread at almost any safe point, even if it is in the middle of doing useful work. This means a thread never has to wait for the current one to finish its slice before getting CPU time, which reduces response time but increases context-switch overhead. Historically, the desktop default, where responsiveness matters more than raw throughput. : Introduced in Linux 6.12 as a compromise between the two. The scheduler can interrupt threads, but tries to wait for natural boundaries rather than cutting in aggressively. The intent is to approximate ‘s throughput behavior while still allowing preemption when needed. In Linux 7.0, was removed as an option on modern CPU architectures, leaving only and . Indeed, was designed to be a drop-in replacement on throughput workloads, and for the vast majority of server software, it is. But PostgreSQL hit a specific case where the difference is catastrophic, and to understand why, we need to look at how PostgreSQL manages memory. PostgreSQL, like most databases, doesn’t store data as rows in a flat file. Instead, it uses a fixed-size abstraction called a data page (8 KB by default) as its basic unit of storage. Everything on disk (e.g., table rows, B-tree index nodes, metadata) is stored in these pages. A table with millions of rows is ultimately a large sequence of data pages on disk. Reading from disk is slow. So PostgreSQL maintains a shared buffer pool , a large region of shared memory that caches recently read data pages . The more of the working set that fits in the buffer pool, the less disk I/O is needed. When a client connects to PostgreSQL, the server spawns a dedicated process to handle that connection, called a backend . Every backend that needs a data page not already in the buffer pool has to first read it from disk, then find a buffer to store it in: either one that is already free, or one currently holding another page that can be evicted. The job of finding that buffer falls to a single crucial function called . To coordinate access to the buffer pool across hundreds of concurrent backends, uses a spinlock. A spinlock is a locking mechanism built on a simple idea: instead of going to sleep while waiting for a lock to become available, a process just keeps checking in a tight loop (it spins ): Why would we ever want that? For very short critical sections, the overhead of putting a thread to sleep and waking it back up can be more expensive than just “spinning“ , meaning actively waiting. If we know the lock holder will be done in nanoseconds, spinning is faster than sleeping. The key assumption behind spinlocks is the following: the thread holding the lock will release it very soon. Nobody is going to preempt that thread in the middle of a 20-nanosecond critical section. The holder will finish and release the lock before anyone has time to notice. uses a single global spinlock to protect the critical section where it selects a buffer. On a 96-vCPU machine with 1,024 clients all hammering the database, every backend competes for the same lock, and any time it takes longer than expected to release, all of them burn CPU spinning. But why did the Linux 7.0 preemption change make it so much worse? The answer lies in how memory works at the hardware level. Every process in Linux, including PostgreSQL, works with virtual memory addresses. For example, the address in one process is a completely different memory from the same address in another process. The hardware translates virtual addresses to physical addresses using a data structure called the page table , maintained by the kernel in memory. A page table is a multi-level tree, so a single address translation requires several sequential memory reads to walk it. Doing that for every memory access would be impossibly slow. Instead, CPUs have a small hardware cache for recent translations called the Translation Lookaside Buffer (TLB): When a process accesses an address it has accessed recently, the TLB already has the translation, and the memory access proceeds quickly. When a process accesses an address it hasn’t seen before, it gets a TLB miss : the CPU has to walk the page table, find the physical address, and store the translation in the TLB. That takes time. There is one more concept to introduce. When PostgreSQL starts, it allocates the shared buffer pool as a large virtual memory region. But allocating virtual memory and having physical memory ready to use are two different things. Indeed, Linux uses a principle called lazy allocation : the allocation is noted, but the actual physical pages are only mapped on first access. The first time any code touches a previously-unmapped virtual address, a minor page fault occurs: the kernel allocates a physical page and stores the mapping. That takes microseconds, orders of magnitude slower than a regular read or write where the page is already mapped. When a process accesses memory for the first time, the kernel doesn’t map it byte by byte. Instead, it maps memory in fixed-size chunks called memory pages via the page table. NOTE : We already used the word “page” to characterize data pages, meaning how PostgreSQL organizes data on disk into fixed-size 8 KB blocks. This is a different concept than a Linux page, which is the unit the kernel uses to manage physical memory. By default, a Linux memory page is 4 KB. PostgreSQL's shared buffer pool, like all memory on Linux, is backed by Linux memory pages under the hood. In Dipietro’s benchmark, the shared buffer pool was configured to 120 GB via the parameter, which at 4 KB per Linux memory page means roughly 31 million memory pages . Therefore, 31 million potential first-touch page faults. Now let’s consider what happens inside . Each backend acquires the spinlock to find a free slot in the buffer pool. To do so, it reads or writes shared memory. If that region of shared memory hasn’t been touched yet, accessing it triggers a minor page fault , meaning that the kernel has to allocate a physical memory page and store the mapping. During a long benchmark with a 120 GB shared buffer pool, new regions keep entering the working set throughout the run, so these faults happen constantly, not just at startup . And when a fault occurs while a backend is holding the spinlock, the consequences are severe. Indeed, we discussed that the key assumption behind spinlocks is that the lock will be released very soon. In that case, the assumption breaks : the holder is stuck inside the kernel fault handler while it stores a physical memory page mapping, and every other backend on the machine is spinning, burning CPU, waiting for a lock that won't be released until the faulting process resumes. The impact of a fault when the lock was acquired depends on the preemption model . Let’s consider the following example. Backend acquires the lock but triggers a page fault. Meanwhile, backends , , and arrive and try to acquire the lock. Since they can’t, they spin, burning CPU on a tight loop while waiting for backend to release the lock. With (before Linux 7) : Once backend enters the fault handler, the kernel handles the fault. Since avoids voluntary rescheduling points, backend is unlikely to be scheduled away before the fault resolves and the lock is released. The spinners wait a bit longer than expected, but the damage is limited. With (Linux 7 and beyond) : The scheduler may decide to preempt backend A while it’s still inside the fault handler, scheduling another process in its place. Backend won’t resume until the scheduler hands control back to it, which can take some time, even after the fault is fully handled: The spinlock hold time goes from “ duration of the fault ” to “ duration of the fault + time waiting for the scheduler .” And that extra wait, let’s call it , is not just of wasted CPU; instead, it is multiplied by every backend currently spinning . In the previous example, backends B, C, and D each burn extra cycles, making the total waste . On a 96-vCPU machine with hundreds of backends, that multiplier is devastating. That's how the benchmark ended up with 56% of the CPU burning in . That extra time waiting for the scheduler was the root cause of the issue. Fortunately, there is an option to overcome this issue in PostgreSQL. The main variable we discussed was , 120 GB in the benchmark, meaning roughly 31 million memory pages. But there is another variable we can adjust: the size of a memory page . As we said, it defaults to 4 KB, but the kernel supports larger pages called huge pages . On x86_64 and ARM64, the supported sizes are 2 MB and 1 GB: 4 KB pages : ~31,000,000 potential page faults 2 MB huge pages : ~61,440 potential page faults 1 GB huge pages : ~120 potential page faults Increasing the size of a memory page reduces the number of potential page faults but also reduces TLB pressure. Indeed, far fewer entries need to cover the same memory, so the working set fits comfortably in the TLB, meaning far fewer TLB misses and page table walks on the hot path. Overall, stops triggering faults while holding the lock. The lock holder finishes quickly. The other backends wait microseconds instead of milliseconds. The regression disappears . NOTE : Setting huge pages in PostgreSQL is controlled by the configuration parameter, which accepts three values: , , and (the default). With , PostgreSQL uses huge pages if available and silently falls back to 4 KB pages otherwise. Use instead so PostgreSQL fails to start rather than running misconfigured without you noticing. The size of the huge pages themselves is a Linux configuration. However, setting huge pages is not without tradeoffs . Huge pages are pre-allocated and reserved upfront, meaning that memory is no longer available to the rest of the system even if PostgreSQL isn’t using it all. There is also a memory waste concern: a huge page is allocated as a whole, so if only a fraction of it is used, the rest is wasted. For most production PostgreSQL deployments with large , these tradeoffs are probably worth it, but they are good to know about. Peter Zijlstra, the Intel kernel engineer who authored the preemption change, proposed a fix: PostgreSQL should adopt Restartable Sequences ( ), a Linux kernel facility that lets userspace code detect whether it was preempted or migrated during a critical section and restart it if so. PostgreSQL's spinlock paths would use to detect preemption and retry, avoiding the scenario where a preempted lock holder stalls all waiting backends. The PostgreSQL community’s response was not enthusiastic. Using a kernel facility specifically to recover performance that PostgreSQL had for free before Linux 7.0 is a tough sell. It also sits uncomfortably next to the kernel’s long-standing principle of not breaking userspace : if software worked correctly before a kernel upgrade, it should work correctly after. AI is getting better every day. Are you? At The Coder Cafe, we serve fundamental concepts to make you an engineer that AI won’t replace. Written by a Google SWE, trusted by thousands of engineers worldwide. Linux 7.0 removed on modern CPU architectures, leaving only and . On most distributions, the default shifted to . An AWS engineer benchmarked PostgreSQL on a 96-vCPU Graviton4 and found throughput cut in half on Linux 7.0, with 55% of CPU burning inside a single spinlock in . The root cause is minor page faults occurring while a backend holds the spinlock. With 4 KB memory pages backing a 120 GB , there are up to 31 million potential first-touch faults throughout a benchmark run. Under , the faulting process resumed quickly and released the lock. Under , the scheduler may preempt it mid-fault, extending the hold time and causing every waiting backend to keep spinning. Enabling huge pages (2 MB or 1 GB) reduces the number of potential faults by orders of magnitude and eliminates TLB pressure, making the regression disappear. Linux Soft vs. Hard Lockup Instruction Pipelining Explained Simultaneous Multithreading Explained [PATCH 0/1] sched: Restore PREEMPT_NONE as default AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy PREEMPT_NONE Is Dead; Your Postgres Probably Doesn’t Care The long road to lazy preemption Buffer Manager Restartable Sequences The Problem Salvatore Dipietro ran pgbench (PostgreSQL’s standard benchmarking tool) on a Graviton4 processor with 96 vCPUs. The workload was a benchmark doing simple updates at scale factor 8,470 (i.e., roughly a 847 million row table), simulating 1,024 clients and 96 threads. A serious, high-parallelism load designed to stress the system. The results were striking. Linux 7.0 delivered roughly half the throughput of Linux 6.x on the same hardware and workload: Linux 6.x : 98,565 transactions per second Linux 7.0 : 50,751 transactions per second : The kernel almost never interrupts a running thread. A thread runs until it voluntarily gives up the CPU: when it makes a syscall, blocks on I/O, or explicitly sleeps. This was the traditional server default with fewer context switches, higher throughput, and predictable behavior under load. : The kernel can interrupt a running thread at almost any safe point, even if it is in the middle of doing useful work. This means a thread never has to wait for the current one to finish its slice before getting CPU time, which reduces response time but increases context-switch overhead. Historically, the desktop default, where responsiveness matters more than raw throughput. : Introduced in Linux 6.12 as a compromise between the two. The scheduler can interrupt threads, but tries to wait for natural boundaries rather than cutting in aggressively. The intent is to approximate ‘s throughput behavior while still allowing preemption when needed. When a process accesses an address it has accessed recently, the TLB already has the translation, and the memory access proceeds quickly. When a process accesses an address it hasn’t seen before, it gets a TLB miss : the CPU has to walk the page table, find the physical address, and store the translation in the TLB. That takes time. With (before Linux 7) : Once backend enters the fault handler, the kernel handles the fault. Since avoids voluntary rescheduling points, backend is unlikely to be scheduled away before the fault resolves and the lock is released. The spinners wait a bit longer than expected, but the damage is limited. With (Linux 7 and beyond) : The scheduler may decide to preempt backend A while it’s still inside the fault handler, scheduling another process in its place. Backend won’t resume until the scheduler hands control back to it, which can take some time, even after the fault is fully handled: The spinlock hold time goes from “ duration of the fault ” to “ duration of the fault + time waiting for the scheduler .” And that extra wait, let’s call it , is not just of wasted CPU; instead, it is multiplied by every backend currently spinning . In the previous example, backends B, C, and D each burn extra cycles, making the total waste . On a 96-vCPU machine with hundreds of backends, that multiplier is devastating. That's how the benchmark ended up with 56% of the CPU burning in . That extra time waiting for the scheduler was the root cause of the issue. Huge Pages to the Rescue Fortunately, there is an option to overcome this issue in PostgreSQL. The main variable we discussed was , 120 GB in the benchmark, meaning roughly 31 million memory pages. But there is another variable we can adjust: the size of a memory page . As we said, it defaults to 4 KB, but the kernel supports larger pages called huge pages . On x86_64 and ARM64, the supported sizes are 2 MB and 1 GB: 4 KB pages : ~31,000,000 potential page faults 2 MB huge pages : ~61,440 potential page faults 1 GB huge pages : ~120 potential page faults Linux 7.0 removed on modern CPU architectures, leaving only and . On most distributions, the default shifted to . An AWS engineer benchmarked PostgreSQL on a 96-vCPU Graviton4 and found throughput cut in half on Linux 7.0, with 55% of CPU burning inside a single spinlock in . The root cause is minor page faults occurring while a backend holds the spinlock. With 4 KB memory pages backing a 120 GB , there are up to 31 million potential first-touch faults throughout a benchmark run. Under , the faulting process resumed quickly and released the lock. Under , the scheduler may preempt it mid-fault, extending the hold time and causing every waiting backend to keep spinning. Enabling huge pages (2 MB or 1 GB) reduces the number of potential faults by orders of magnitude and eliminates TLB pressure, making the regression disappear. Linux Soft vs. Hard Lockup Instruction Pipelining Explained Simultaneous Multithreading Explained [PATCH 0/1] sched: Restore PREEMPT_NONE as default AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy PREEMPT_NONE Is Dead; Your Postgres Probably Doesn’t Care The long road to lazy preemption Buffer Manager Restartable Sequences
Realized I issued myself a challenge, but failed to define any parameters! My goal is to post at least 1 photo taken with my Sony A7IV per day. Let's see how it goes! Today's photos are from a short e-bike ride my wife and I did along the trail near our home. I want to give some serious kudos to RapidRaw , it's a seriously fast Lightroom alternative that runs on Linux. I've been loving it!
The Papirus icon theme is my favourite - I've used it for years and it continues to work beautifully. So while I've been rebuilding my Framework 13 , it was one of the first things I installed. But there's a problem, dear reader. You see, I'm a proud light mode person, but I regularly switch to dark mode when working in the evening. However, Ubuntu has this silly bug where it switches back to the default Yaru icon theme whenever one switches between light and dark mode. On my previous machine I had a cronjob running every minute that simply checked the theme and switched it to Papirus if it was Yaru. That worked fine, but wasn't the most elegant solution. So, this time I did more research and came up with a slightly more elegant fix workaround. Ok, it's pretty simple. It consists of a small script that runs whenever Ubuntu flips between light/dark mode, then 0.2 seconds later, switches the icon theme back. Far from perfect, but it's better than a script that runs every minute the machine is running. To do this, create a new script at with the following contents: You need to make the script executable, so run this next: Next thing is create a file that tells GNOME to automatically start the script when we log in: Remember to change on the line to whatever your Ubuntu username is. That's it! Log out, and back in again, and the script should be doing it's thing in the background. So the next time you switch between light and dark mode, your fancy-pants icon theme should persist. Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .
In my previous post I talked about my frustration that the used Thinkpad I bought was crashing when unplugged in Linux. My conclusion at the end of the post was that I would return to Mac OS. Well that lasted about 1 day. I'm back to Linux on the Thinkpad, here's what happened (with added rants about Mac OS and Windows): After using Linux on my System76 for a few months, Mac OS felt...old? Everything was laggy: the animation for switching spaces, launching apps, even typing. Sure, my Mac is a 5+ year old computer at this point (14" MacBook M1 Pro), but still, it shouldn't feel that bad. Then there's how Apple treats you like a child. Want to install that app you downloaded? No, it's too dangerous (aka the developer didn't pay us)! We recommend you just throw it away. In parallel to dealing with Mac OS, I went through the terrible process of installing Windows 11 on the Thinkpad with the idea of giving it to my wife. Seriously, I can't properly articulate how awful Windows 11 is these days (but I can try). First off, just getting a bootable ISO is a pain. You can't just flash with any normal program, you're expected to use another Windows computer to setup a USB. Thankfully I found a Mac app ( WinDiskWriter ) that could do it. It took 2 tries though, the first time I choose exFat and it wouldn't boot, so I tried again with fat32. Once you're in the installer, the shit show truly begins. Off the bat, the installer has a completely different design language then Windows 11. The built-in disk practitioner is one of the worst I've used (compared to Linux installers). The install process takes forever and the computer has to reboot 3-4 times. Again, compared to Linux, this is so bizarre. Almost every distro out there has a live environment, an intuitive installer (not you Fedora), takes ~10 minutes and doesn't reboot a single time. Finally you get to the post-install setup wizard. It's filled with laggy animations, how wonderful! Right off the bat it required me to be on the internet, but it didn't recognize my WiFi. There was a "load driver" button though, so I downloaded the WiFi driver from Lenovo onto a USB drive. Nope, not recognized. I had to unplug one of my WiFi APs and use it's ethernet to finish the install. While doing this, screen kept flashing as it tried to figure out the display drivers. Again, Linux just works. WiFi, graphics, etc. Once online I of course had to login to a Microsoft account. I also had to agree to sell my information to advertisers. Then I was presented with 7 pages of upsells. I'm not kidding! "Subscribe to Gamepass", "How about Office 365?", "You need Onedrive, right?". Buying a used car from a sketchy salesman is a better experience than installing Windows. Once everything was finally installed, I had to "check updates" and reboot multiple times. It's funny how installing all the available updates just leads to more updates after reboot. Why not, ya know, install them all at once? But here's where something good finally happened! First, I verified that the Thinkpad worked perfectly in Windows, no crashing at all when unplugged. I also noticed a "Lenovo Updater" app got auto installed. After running the app, it found one "critical" firmware update for my SSD. This update wasn't found by in Linux, and there was no way to get the firmware on the Lenovo site beyond the Windows . The next day, I got fed up with Mac OS and decided I would bite the bullet and order a Framework. I could have gone back to the System76, but once you ride a Cervelo it's hard to get back on a Huffy ya' know? In a last ditch effort, I flashed EndeavourOS to a USB to try one more time with the Thinkpad. My thought was Arch would be bleeding edge and have a higher chance of working. Sure enough, no more crashes! I stress tested quite a bit across a few reboots and it was rock solid! I'm 90% the issue was the SSD firmware, but it might be Arch. I'm honestly pretty happy with EndeavourOS so I didn't try Ubuntu or Fedora, instead I happily wiped Windows with a EndeavourOS + GNOME install. I'm overjoyed that the Thinkpad is rock solid now, it's such a great little machine! I have a feeling my future laptops are going to be Thinkpads, but I expect this will last me quite awhile. TL;DR for those facing the issues I did: To fix AMD data fabric sync flood event in Linux when plugging in or unplugging the charger on a Lenovo Thinkpad P14s Generation 4 that leads to a full system reboot, install the NVMe Solid State Drive Firmware Update from the Lenovo Support website. You will need Windows 11 to install the driver, but can switch back to Linux after install.
On Wednesday I picked up a new (to me) Thinkpad P14s Gen 4. I was excited to finally get off my System76 Pang12, a computer that works, but has a long list of hardware and reliability issues. Thinkpad in hand, I installed Ubuntu 25.10 and immediately put it to work with a night of trimming down my client request backlog. The computer was incredible! Amazing keyboard, vastly better trackpad, perfect 14” form factor and everything worked out of the box on Ubuntu. Heck, it even had a usable webcam! But like a majority of things in my life, something always goes wrong. I knew it was too perfect, and wondered what I was going to find that ruined the joy. How about complete system crashes when you plug/unplug the system? Yep, that’ll do it. I spent all of yesterday and this morning debugging. Multiple distress, a long list of kernel params, different chargers and tweaking bios settings. Nada. About 50% of the time when you unplug, Gnome will slowly start to lock up, then the system restarts. Looking at logs it’s caused by a . At first I thought it might be related to the WiFi chips (based on pre-crash logs). Disabled via bios and still crashes. I’ve tested RAM, SSD and battery, all good. I have a new battery coming Monday just in case, but fully expect it won’t help. I’m out $500 USD, and honestly, I’m done with Linux for now. I love Gnome and Fedora+Ubuntu, but it’ll be a few years before I buy a new laptop after throwing away money on the Thinkpad (and the Pang12 2 years ago). Back to Mac OS Tahoe it is. Liquid ass and all. I’m hopeful that the Thinkpad problems are just on Linux. My wife has been wanting a laptop and she’s not ready to jump off Windows making it the perfect computer for her.
Abstract A full-spectrum dive into anti-forensics across Windows and Linux (with a tad of MacOS, if time permits), centered on real incidents and modern attacker behavior. The course walks through classic log wiping, deeper filesystem tricks, PowerShell, timestomping, sandbox artifacts, memory-only execution, endpoint solution blind spots, and advanced Linux log manipulation. Each technique is paired with detection logic, weaknesses in attacker tradecraft, and practical forensic recovery paths. The material emphasizes hands-on analysis, including MFT/MSRUM/USN artifacts, ETW traces, VHDX extraction, /proc-based investigation, and highlights new research and tooling that shape current offensive and defensive strategies.
It’s good to see you again, old friend. It’s been a while. Twenty-three years, you say? How come we managed to drift apart that far? I know, I know, I betrayed you. But my room was cold at night and Gentoo offered me the ability to keep on compiling. And then I betrayed GNU/Linux for FreeBSD. And then I switched the demon for the apple. I’ve been on an apple diet for so long now, I can barely remember the tux. What is it you say? Oh, it’s openSUSE now. Sure, you’re a chameleon, you can take on any colour you’d like. Great to see it’s still green. I like green. How’s YaST doing these days? ? What’s that, no more ? That’s cool, it looks like you’ve made some progress! Let’s make a screenshot the proper nerdy way and do some in a terminal! Oh, that’s no longer cool? ? So first and then that command? Let’s try that: openSUSE Tumbleweed running on the HP work laptop. My last experience with the Linux desktop was indeed about twenty years ago. Since 2012, I’ve been a macOS user. I’m no longer proud of it: I miss Linux and I think macOS is boring and full of bloat . Yet the rise of the Apple silicon made me buy another one in 2020, which is still the one I’m using right now. The hardware is amazing, the screen is amazing, and the weight and fanless features are amazing. But I still miss customisation features—the ability to truly make the desktop mine—and I stopped updating the OS as a protest to ever increasing bloatware. This laptop is still running Sonoma which is bad enough as it is. I have no intentions to go out and buy another machine any time soon; this one’s still doing fine; but I did start to wonder. What if… I got a ThinkPad and installed Linux back onto it? Would the hardware match the high standards I’m accustomed to now? Would I still be able to make my way around the OS? I ran GNOME 2 and KDE 3 (and then got nerdy with Fvwm). I compiled my own Linux 2.6 kernel patches back when that was brand new. I have no idea what’s happening now. That’s not to say that I don’t touch Linux: I use it daily to host this website, to run the NAS at home, and in virtual containers. But that’s not the Linux Desktop Experience . My main motivation for moving away from Linux was my frustration with endless configuration and compilation. Back in the day, hibernate didn’t just work out of the box, the fan speed had to be configured depending on the type of the laptop, nVidia drivers were a pain (still are), etc. Work and life started getting in the way: I no longer had endless seas of time on my hand to go nuts with Gentoo. With two young kids, that times has dwindled even more, so NixOS or even Arch is out of the question. Being fed up with the crappy Windows 11 installation on my work laptop, I wiped that partition and remembered my old friend The European Chameleon. So here I am, testing the waters yet again. Thanks to Valve, Lutris is amazing . KDE Plasma feels mature (even though some configuration settings seem sluggish). I don’t want to dive into the rabbit hole of AwesomeWM (but I do). I don’t want to try and live without systemd or have to hurt my brain about X11 vs Wayland. I want the thing to “just work”. I want my chameleon to be an apple. A proper one, like a “back in the day” apple one. I haven’t had the time to give openSUSE a proper trail. I’m mainly fighting my muscle memory with versus that strange location which is somewhat diminished by Toshy that then doesn’t work well in combination with my Emacs configuration. What I did notice is that hibernation/suspend is still ugly: if I close the lid for a night without putting the laptop in true hibernate mode (with its dedicated swap partition), the battery drain is ridiculous, especially coming from a MacBook Air that I just jam shut and open up again a hundred times a day. This made me realise I will probably have to give up on the hardware quality part if my next laptop is going to be a non-Apple one. Which I don’t really want to? Seb and I discussed which laptop to get when ours would break down. The Framework is an obvious one as are the System76 ones that specifically support Linux. Alex White’s everyday carry post made me realise the build quality of these is average at best. It’s going to be a painful experience migrating from that. I know Kev is happy with his Framework , but I’m not yet fully convinced. The fact that this HP EliteBook 6 G1a 16 work laptop’s screen and overall build quality is terrible is not helping either. The touchpad palm detection experience is horrible on KDE. Let’s first give the chameleon another chance to see if on an OS level I could live without macOS and my usual mac-exclusive power tools. The ones I’ll miss the most might be Alfred and DEVONthink . My recent migration to do-everything-in-Emacs does make the transition a lot easier. I also moved from iTerm2 to Ghostty last year and am now trying out Kitty with the Fish shell. My RSS feed now lives inside my FreshRSS server making me less dependent on NetNewsWire. Software-wise, I’m getting there. I’m sure I’ll get there. But what about hardware-wise? Related topics: / linux / By Wouter Groeneveld on 22 April 2026. Reply via email .
I find beautiful, well-designed, native applications to be a source of inspiration when using my computer. I've posted on Mastodon about the native Mac applications that were hard to leave when switching to Linux. Now that I've fully made the switch, I figure it's only fitting to do the reverse post on the Linux applications that I've fallen in love with. For this post, I'll be focusing on Gnome/GTK/Adwaita applications. Why? Two reasons. First off, I use Fedora with Gnome 49 so I'm most familiar with this territory. Second, Gnome has a very well defined HIG (Human Interface Guidelines), resulting in a strong visual identity. Applications enhance the operating system in a consistent, fluid way, rather than serving a jarring experience (ie an electron app with radically different UI/UX). This is key to me for finding inspiration and joy when using an application. With all that said, let's dig into the apps I consider essential! Internet radio is awesome and Shortwave is the best application I've found on any platform for listening to it. Search for stations, add to your library and jam! It also has a DVR-like function (okay I get it, I'm getting old) so you can download tracks you've listened to. Finally, there's an amazing skeuomorphic mini-player (I'm a sucker for skeuomorphic design). 📦 Shortwave on Flathub ♥️ Support Shortwave 👤 Meet the Developer "Plays music, and nothing else" is the tagline of this beautiful audio player. For those of us still rocking local media collections, Amberol is the way to go. I mean, just look at it! Point it at a folder, play the music inside, easy! I have my NAS mounted as a bookmark in Nautilus, so I just point Amberol to my network music folder. Who needs streaming?!? 📦 Amberol on Flathub ♥️ Support Amberol 👤 Meet the Developer I've been using Blanket longer than most apps on this list, long before I made the full switch to Linux (and heck, it's probably one of the reasons I eventually made the switch). It's a no-frills ambient noise machine. Comes with a large selection of high-quality samples that can individually be toggled and adjusted. You can save preset configurations (ie coffee shop in a thunder storm), and add your own audio samples. On any other platform this would cost $15 or more, but here it is on Linux, free and open-source. 📦 Blanket on Flathub ♥️ Support Blanket 👤 Meet the Developer Need to quickly edit an image or make a thumbnail? Pinta to the rescue! It's fast and has a familiar UX. Sure, it's not as powerful as GIMP, but I find myself reaching to it more often. 📦 Pinta on Flathub 👤 Meet the Developers This app right here should be a default Gnome app, it's that good! Hands down the most powerful and user friendly screenshot tool I've used (and yeah, I've tried the popular Mac OS ones). Bind Gradia to a shortcut (I use Super + Shift + S) and it'll open after you take a screenshot. Gradia lets you add arrows, drawings, blur text, perform OCR, crop, add backdrops and more. It's honestly an essential application, and performs better than apps I paid $15+ for on Mac. 📦 Gradia on Flathub ♥️ Support Gradia 👤 Meet the Developer There's a lot of single purpose, well-built applications for Gnome, and Switcheroo is a great one I use daily. It takes an image in, and outputs in a different format. You can add on compression, resizing, strip metadata and replace transparency. I use it to optimize images for web. 📦 Switcheroo on Flathub ♥️ Support Switcheroo 👤 Meet the Developer I don't use social media beyond Mastodon, but Tuba makes me glad I'm at least on that platform. Tuba is well designed, fast and filled with thoughtful features (like a custom emoji picker and the ability to schedule posts). I've tried the best on Mac (Ice Cubes), and it doesn't get close to comparing with Tuba. 📦 Tuba on Flathub ♥️ Support Tuba 👤 Meet the Developer Mmmm RSS, my favorite (and probably how you're reading this article)! Newsflash is a great excellent, way to stay on top of your feeds. It's got categories, tags, OPML import/export, themes, and more. My favorite feature is the "Today" tab filtered by unread, great to catch up on what's new. 📦 Newsflash on Flathub 👤 Meet the Developer Here it is, my top pick. You don't even need to read this, just go download Planify, it's incredible. Alain took todos and added a bucketload of thoughtfully designed microinteractions. Labels, scheduling, today view, sections, kanban board, natural text to date parsing, the list goes on. When you hover the "Add" button, it does a little animation. When you complete a task, it gives a little sound. There's so many thoughtfully designed pieces in here! 📦 Planify on Flathub ♥️ Support Planify 👤 Meet the Developer Markdown based note taking, done very well. Notes are organized into notebooks and paired with a pleasant, minimalist markdown editor. 📦 Folio on Flathub 👤 Meet the Developer Distraction free markdown editor for writing long form content. Basically, the Linux alternative to iA Writer on Mac. It's beautiful, fast and has just enough features. I use it to write most of my blog posts! 📦 Apostrophe on Flathub ♥️ Support Apostrophe 👤 Meet the Developer Another excellent, single-purpose application that I use on a daily basis. Sessions is an egg/pomodoro timer that beeps when time's up. You just drag the slider and the timer starts. Great for keeping yourself focused! 📦 Sessions on Flathub ♥️ Support Sessions 👤 Meet the Developer Holy crap this app looks good! John did an incredible job building the best ebook reader on Linux. You can bring your own books, or use the catalogs feature to discover public domain literature. There's support for annotations (with import/export), bookmarks, text to voice and theming. 📦 Foliate on Flathub ♥️ Support Foliate 👤 Meet the Developer Got a sqlite database and want to know what's inside? Bobby to the rescue! Drag and drop your database file in and see the data. Simple, well designed and useful! 📦 Bobby on Flathub ♥️ Support Bobby 👤 Meet the Developer There's so much value packed into this app! Replace random sketchy websites you found on Google by using Dev Toolbox to generate a QR code, check contrast ratios, parse CRON strings and so much more. There's too much in here to cover, but it's become an essential part of my toolkit. 📦 Dev Toolbox on Flathub 👤 Meet the Developer Bazaar is a faster, more reliable and visually more appealing alternative to the default Gnome Software application. It's one of my first installs on a new system and another application that should be a default Gnome app. 📦 Bazaar on Flathub ♥️ Support Bazaar 👤 Meet the Developer The absolute best way to discover, install and update Gnome shell extensions! 📦 Extension Manager on Flathub ♥️ Support Extension Manager 👤 Meet the Developer Copyous is a shell extension, and it's the best clipboard manager out there. Visually browse and search your clipboard history. Supports image previews, syntax highlighting, color previews (ie copy a hex code and it shows the color) and so much more! 📦 Copyous on Gnome Extensions There's so many amazing applications on Linux that I definitely missed some! Feel free to shoot me an email at [email protected] with recommendations. I'll do a separate post in the future for KDE applications! I mentioned a few times in this article that some applications on Linux provide better value than alternatives I paid for on Mac OS. There's not a single paid application on this list, but that does not mean you shouldn't support the developers! These developers work hard to design, build, test and support the software that makes Linux great. If you like their work, show them some love!
Linux
Open Source
Hardware
Java
Music
Performance
Python
DevOps
JSON
Tutorial
Go
Gaming
Shell
Rust
Database
Security
Design