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 .
Most Rust developers use the language, compiler, package registry, and tooling every day without thinking too much about the organization that helps keep parts of that ecosystem funded and sustainable. This episode is a re-introduction to the Rust Foundation: what it does, what it does not do, how it relates to the Rust Project, and why that distinction matters for teams using Rust professionally. My guests are Rebecca Rumbul, Executive Director and CEO of the Rust Foundation, Lori Lorusso, Director of Outreach at the Rust Foundation, and David Wood, Principal Software Engineer at Arm, Compiler Team Co-Lead in the Rust Project, and a Rust Foundation board member. Together we talk about the practical side of ecosystem stewardship: infrastructure, security, interop, maintainer support, governance, corporate membership, open-source funding, and the pressure new technologies like AI put on language ecosystems. 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 . The Rust Foundation is an independent non-profit organization supporting the success, sustainability, and positive impact of the Rust programming language. Its work includes funding and supporting ecosystem infrastructure, security and interoperability initiatives, maintainer support, project administration, community programs, events, and collaboration with member companies and donors. The Foundation is separate from the Rust Project. The Rust Project governs the language, compiler, standard library, and technical direction through its own teams and decision-making processes. The Foundation provides organizational, financial, legal, and operational support around that work, without owning Rust’s technical roadmap. Rebecca Rumbul is the Executive Director and CEO of the Rust Foundation. She leads the Foundation’s work on organizational strategy, member engagement, sustainability, and support for the broader Rust ecosystem. Lori Lorusso is Director of Outreach at the Rust Foundation. Her work connects the Foundation with the Rust community, member organizations, trainers, contributors, and companies adopting Rust in production. David Wood is a Principal Software Engineer at Arm, CE-SW Rust Team Lead, Compiler Team Co-Lead in the Rust Programming Language Project, and a board member of the Rust Foundation. In this episode, David adds the perspective of someone involved in Rust’s technical work as well as Foundation governance. Mozilla - The first home of the Rust language Python Steering Council - The governing body of the Python Project How to Write a C++ Language Extension Proposal - Bjarne Stroustrup, the inventor of C++, on why C++ needed a standards committee SCRC - The Safety-Critical Rust Consortium FLS - The Ferrocene Language Specification, a specification of the Rust language that is required for certain steps in the certification of Rust for safety-critical applications Foundation Membership Tiers - The different quantifiable benefits from Diamond to Silver and Associate Memberships Rust Commercial Network - A group of organisations that use Rust in production working together with the Rust Project Rust-C++ Interoperability Initiative - An initiative of the Rust Foundation to improve interoperability between Rust and C++ Rust Embedded Working Group - An official working group of the Rust language to improve usability of the language in hardware-constrained environments An AI Security Engineer in Residence for the Rust Ecosystem - Describing the position of the security engineer made possible by funding from Alpha-Omega Rust Foundation Maintainers Fund - The Foundation’s fund to support Rust maintainers Rust Foundation Trusted Training - The Foundation’s accreditation program for Rust training providers Rust Foundation Website Rust Foundation Media Room Rust Foundation on GitHub Rust Foundation on LinkedIn David Wood’s website
Long-time readers will know I’m convinced local voice interfaces and sub-$1 embedded chips will fundamentally change how we interact with everything in the physical world. That’s why I’m so excited to introduce Moonshine Micro , a version of the Moonshine Voice open source framework that can run a useful voice interface in just 520KB of RAM. It contains separate libraries for voice-activity detection , speech to text , and text to speech , all powered by tiny neural networks with an example bringing them all together on an 80 cent Raspberry Pi RP2350 chip . I’m still working towards the end goal of the moonshot I started at Google Brain in 2017, a full ASR and TTS system on a 50 cent chip that can run on a coin battery for a year, but this is a big milestone on the journey. This release runs a 50-word command recognizer, that’s fully trainable for custom words , and a neural network-based text to speech engine, and can be used to set up a wifi connection. There’s still a lot of work to do to increase the scope of the recognition to full speech, rather than individual words, increase the text to speech quality, and to offer advanced intent recognition on this kind of system, but with the hardware improvements that are likely to come over the next few years, I think we’re getting a lot closer. I’m looking forward to seeing applications I’d never thought of for this technology, so if you build something neat please tag me on Hackster, and for questions or issues let me know on GitHub .
Immich is a self-hosted photo/video app, and one of their side pages is Cursed Knowledge : Cursed knowledge we have learned as a result of building Immich that we wish we never knew. = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/cursed-knowledge-we-have-learned-that-we-wish-we-never-knew/1.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/cursed-knowledge-we-have-learned-that-we-wish-we-never-knew/1.1600w.avif" type="image/avif"> There is something about this format that I really enjoyed as a reflection but also as a way to share with others – simple one sentence/paragraph updates with links, so you can inhale quickly but also go deep if needed. There’s some overlap with bugs here, but it’s not necessarily only buggy stuff – also quirks of formats, observations, etc. I made a cursed knowledge page for Unsung – let me know! (Thanks to Casey Gollan for posting about the original page.)
I have been working on a patch to the Linux kernel to support for the interpreter ( ) via bpf in [ thread ]. Of course I’m leveraging an LLM to help me do this! To pre-seed the context of the LLM, I asked it to read the https://lore.kernel.org/ thread. Uh oh. Looks like they have adopted Anubis , which is an HTTP proxy that requires proof-of-work before allowing access to the resource. Did this really do anything? Unfortunately, no. My AI diligently came up with anubis-fetch , which you can find at https://github.com/fzakaria/anubis-fetch . The tool tries to natively solve the proof of work or, as a last resort, will launch Chromium to visit the URL. This tool also impersonates a real Chrome TLS/JA3 fingerprint natively via req so it clears passive Cloudflare blocking too. ☝️ So who did we stop? The exact adversary Anubis targets defeats it trivially. The whole use of Anubis feels regressive and marginalizes those without access to “good” AI. For a scraper, solving the Anubis challenge is a one-time, amortized-to-zero cost since the cookie can be cached and reused. For a human, it’s seconds of spinner, battery drain on every fresh visit. They can’t amortize anything amongst each other. This “regressive tax” is paid even more so by those with weaker devices or who access the content on their phone. Clients that don’t leverage JavaScript (e.g., text browsers (w3m/lynx), screen readers, RSS readers) are completely left out. Did deploying Anubis stop any of the aforementioned bot-farms or are they mildly inconvenienced when they had to augment their bots to support a new proof of work solution briefly? The irony is that Anubis’s goal is to stop AI but it was incredibly easy for AI to circumvent it and yet the cost to humans and an open web remains. With the presumption Anubis is now a regressive tax, how much does it cost us? Every number here is a rough estimate. This is not a environmental argument at all since the bot-farmers and AI tools themselves are using many orders of magnitude more energy. Nevertheless, it’s interesting to see how much time is spent doing proof-of-work challenges that marginalize people. Difficulty is the number of leading zero hex characters the hash must have, so the expected work per solve is hashes. Difficulty 4 is the common default. Rates assumed: ~50 MH/s native (Go), ~0.5 MH/s in-browser JS; “felt” wall-clock includes page load, the worker, and the reload. Let be the number of Anubis challenge-solves per day, worldwide. Assume a felt time of and device energy per solve (screen + CPU). Collectively we are wasting an impressive amount of time waiting for access to websites; time we didn’t spend before the AI era. As a human, time is precious and finite to me, whereas to a robot it is not. Human-time / year = Energy / year (kWh) =
John Gruber at Daring Fireball penned a short eulogy for Maestral: As of today Maestral continues to work just fine. I don’t know when these certificates are expiring. And I don’t know what I’m going to do when they do. Dropbox enshittified its app – my friend joked once that Dropbox is a rare example of a company that pivoted away from a product-market fit – and it seems Apple’s API changes didn’t really help, either. Maestral stepped in to help restore the minimalistic, functional core of Dropbox – I believe Doctorow terms this “disenshittification” – but it was helmed by one person, Sam Schott, who has every right to move on to other things. #enshittification #software eulogies #third party fixes
The 'Special Value' Pi 4 pictured above is probably the rarest Raspberry Pi I own—even rarer than my blue special edition Pi . A Raspberry Pi reseller briefly listed a special 'value edition' Pi 4 . But the product page 404's now. While it was up, my curiosity got the better of me, and now I have two 'value' Pi 4s. What makes them a 'value'? They're only certified to run at 1.25 GHz (retail Pi 4s run at 1.8 GHz, and can usually be overclocked).
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 .
This is the first in an ongoing ad-hoc series of posts on Apache Kafka performance. I have no general direction, I’ll just share interesting insights based on the performance testing I do on Apache Kafka. Recently I was curious to see if there was any general performance improvement since Kafka 3.X. So I ran a suite of benchmarks with Dimster against 3.7.2 and 4.3.0. I saw two common patterns: Pattern 1: Low load benchmarks showed that end-to-end latency was higher with Kafka 4.3 compared to 3.7.2. The following is a 45 minute no-record-key workload of 5000 record/s, 20 topics (120 partitions), fan-out 2 (240 consumers), full TLS, on 3 brokers each allocated 8 SMT CPUs in k8s (on my Threadripper 9980X). Fig 1. Low load: end-to-end latency over time (p99 over 10 second intervals) Pattern 2: On more stressful loads, 3.7.2 would show much more spiky end-to-end latency compared to 4.3. The following is for the same workload at 100K records/s (200K out). Fig 2. High load: end-to-end latency over time (p99 over 10 second intervals). Kafka 3.7.2 showed large latency spikes. Fig 3. High load: End-to-end latency distribution It seemed that somewhere between 3.7.2 and now, big performance gains had occurred. Then my subconscious kicked in and reminded me that at some point in that period, the default had been changed from 0 to 5 ms. This would correlate with the low-load end-to-end latency result. The producer config controls how long the producer is willing to wait before sending a non-full batch (controlled by ). If a batch reaches first, it can be sent earlier. The point of is simple: give more records a chance to accumulate into the same batch, because larger batches are more efficient than many tiny batches. The important quantity is the rate “per producer, per partition” (rather than the aggregate rate). Kafka producers build batches per partition, so a producer sending 1,000 records/s to one partition has very different batching behavior from a producer sending 1,000 records/s evenly across 100 partitions. A rough way to reason about it is: For example, with a per-producer-per-partition rate of 100, we might expect 6 records per batch. This is only an approximation as it ignores arrival jitter, partition skew, batch.size config (default 16KB), compression, in-flight request limits, and broker backpressure. But it is good enough to build intuition. In the 5K records/s workload, each producer was sending about 41 records/s: That is one record every: This was also a no-record-key workload. With the default partitioning behavior, records from a producer tend to stick to one partition for a while before moving to another sticky partition. So, for batching purposes, the producer was usually sending roughly one record every 24 ms to its current sticky partition. That makes unlikely to help. A 5 ms linger is much shorter than the ~24 ms average gap between records, so most batches still contain a single record. To reliably get more than one record into a batch, the linger would need to be on the order of the inter-arrival time (tens of milliseconds), not 5 ms. So the low-load result made sense: Kafka 4.3’s default added a little extra waiting causing a higher end-to-end latency, but did not create meaningfully larger batches and its load was so low that larger batching wouldn't have helped anyway. The 100K records/s workload was different. There, each producer was sending about 833 records/s: That is one record every: At that rate, can make a real difference. A producer has time to collect several records before sending a batch. In this workload, I saw the average batch size reach about 5 KB, or roughly five 1 KB records per batch. That reduced the number of small produce batches the cluster had to process. It also improved downstream efficiency for the brokers and consumers. The result was a large reduction in tail latency: the 3.7.2 run, with the old default , had periodic p99.9 spikes around 700 ms, while the 4.3.0 run, with the new default , had a much lower and more stable p99.9 around 8 ms. So the benchmark was not necessarily showing a deep Kafka 3.7.2 versus 4.3.0 performance difference. A large part of the effect could be explained by one client-side default changing: linger.ms moved from 0 to 5 ms in Kafka 4.0. I decided to run a similar benchmark again, explicitly setting linger rather than using defaults. This time I used half the producers (better for batching) but with record keys (much worse for batching). I ran Dimster on Kafka 3.7.2 (broker and clients) and 4.3.0 (broker and clients), with six test points across two scenarios: If we look purely at the batching behavior, none of the linger values helped in the 5K records/s tests as the per-producer rate coupled with record keys meant that linger was ineffective at creating larger batches due to the low per-producer-per-partition rate. The chart below shows Kafka 4.3.0 over the three test points with linger of 0, 5 and 20. Only a linger of 20 slightly moved the needle. Fig 4. 5K workload. Batch sizes across lingers 0, 5 and 20 The exact same pattern occurred with 3.7.2. This workload did not need larger batches: the latency distribution for linger.ms=0 was already good. There was no difference in performance between 3.7.2 and 4.3.0. Fig 5. 5K workload, end-to-end latency distribution The place where linger mattered was the 100K records/s keyed test. In that workload, showed a massive improvement over a linger of 0 and 5. Fig 6. 100K workload: end-to-end latency distributions for lingers of 0, 5 and 20 did not help much at all and we can understand why by doing the math: Due to record keys, A simple estimate would predict about two records per batch at and about six at , which lines up with the observed producer batch-size metrics below: Fig 7. 100K workload. Batch sizes across lingers 0, 5 and 20 The batching improvement with was reflected in the end-to-end latencies, with p99.9 of only 23 ms, compared to over 700 ms for a linger of . Noteworthy is that the results for 3.7.2 and 4.3.0 with were essentially identical. 4.3.0 pulled ahead in the lower lingers, but there is often huge variance in the higher latencies, so from one run, this is inconclusive. Don’t over-index on this one set of benchmarks. No benchmark is fully generalizable, and the right value depends heavily on the workload. The main takeaway is simply this: pay attention to producer batch sizes. When producers are sending batches with only one record, Kafka can hit performance limits much sooner than you might expect. The broker has to process more produce requests, more record batches, more replication work, and more fetch-side batch metadata for the same logical throughput. A small amount of batching can make a large difference. The most important number to understand, with regard to likely batch sizes, is the per-producer-per-partition send rate. Total cluster throughput can be misleading. A workload doing 100K records/s may still produce tiny batches if each producer is spreading records across many partitions. Keyed workloads are especially prone to this, because the key determines the destination partition. If each producer writes to many keyed partitions, the effective rate into each producer-partition pair may be low. Under enough load, Kafka producers will often start batching more even with a low , simply because the sender thread cannot drain records immediately. Broker latency, network saturation, throttling, or in-flight request limits can all cause records to accumulate in the producer. But relying on backpressure to create batching is not ideal. In some workloads, setting a higher lets you get the batching benefit before the system is already under stress. The default changed from 0 to 5 in Apache Kafka 4.0. That means some Kafka 4.x client upgrades may show performance improvements simply because the producer is now batching more by default. Conversely, if you are using Kafka 3.x clients, explicitly testing is a low-risk experiment. As for Kafka 3.7.2 versus 4.3.0, anecdotally, I’ve seen improvements in Kafka 4.x, and I may do more benchmarking to isolate those changes. the 3.7.2 run, with the old default , had periodic p99.9 spikes around 700 ms, while the 4.3.0 run, with the new default , had a much lower and more stable p99.9 around 8 ms.
by Amit Gawande Amit talks about what motivated him to build his custom blogging platform, Jot. It's an interesting read that resonated with me as it aligns with why I created Pure Blog. Read post ➡ A month ago, this website moved to a custom engine that I built myself, one I call Jot. Why did I create it? Because I got tired of almost. Almost the right editor. Almost the right publishing flow. Almost the right feature set. -- Amit Gawande This is exactly why I started building Pure Blog , but the difference here is that I decided to publish it for everyone to use. Before doing so, I considered many of the same questions that Amit talks about in his post - I was concerned that the project would morph into a product for everyone , not just me. Ironically, it's been exactly 5 months since I introduced Pure Blog and since then I've done a shit tonne of work to it. But that wasn't driven by the people who use it. It was driven, almost exclusively, by me. Lots of people have contributed to Pure Blog, but there's hasn't been a single feature I've added that I won't get use from. Actually, that's a lie. The only feature I've added that I wouldn't have if I'd kept Pure Blog private is translations . But I think that's fine, as it's the community who contribute those translations. Anyway, I digress. I'm happy to see other bloggers forging their own path - I'd love to get a look at Jot to see what it does differently to Pure Blog, and if there's anything I could copy improve upon. Maybe one day Amit will release the source code for us to look at, but if he doesn't, I don't blame him. As for my use of Pure Blog - it's by far the best thing I ever did from a blogging perspective. Everything is just how I want it, and in a place that makes sense to me. If others get use from it too ( and they do ) then all the better. But I'll keep developing Pure Blog in a way that makes sense to me. Congrats, Amit. Welcome to the club. 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 .
From now on, GoReleaser release announcements will only be published on the GoReleaser blog .
As I've been spending more and more time with agentic development, it's more and more important to me that sessions run somewhere other than my laptop. For the last few months, that has meant running my coding agents in tmux on either a remote Mac or a remote Linux server. The most frustrating thing for me has been that the clipboard or paste buffer on those remote hosts isn't synced to my desktop. So, if I copy something inside of a coding agent, I've had to play games to get it to my local Mac. Similarly, if I wanted to paste a screenshot to a remote tmux session. I was playing games with scp. But also, I don't just want to be able to copy and paste between my Mac and a remote terminal. I want to be able to copy and paste between remote terminals on two different computers. And I want to be able to take a screenshot on my phone and have it end up in the paste buffer on a remote Linux box. I took a run at solving this problem maybe three months ago, and I came at it from the wrong direction. I started to look at what it would take to integrate with Apple's iCloud-based copy-paste buffer magic syncing stuff. And I stepped back right at the point where it was going to involve reverse engineering iCloud crypto. Not because I didn't think my coding agents could do it, but because doing it felt like a great way to become a cautionary tale. But I kept being frustrated. So I took another swing at this sometime last month or so. And the result is called Clipfan. It runs as a menu bar app on your desktop Mac or Macs, and it integrates into tmux on all of your hosts. It uses SSH keys to set up a fully connected pasteboard syncing mesh. On the Mac, it has a pasteboard history because why not. It can auto-install across your fleet of computers and configure tmux on remote machines. It would, of course, be possible to configure it to sync pasteboards with other kinds of computers and other tools on those machines. ClipFan is free. It's available on GitHub today .
F3: The Open-Source Data File Format for the Future Xinyu Zeng, Ruijun Meng, Martin Prammer, Wes McKinney, Jignesh M. Patel, Andrew Pavlo, and Huanchen Zhang SIGMOD'26 F3 is a file format for columnar data (e.g., Parquet ) that is designed to be efficient and extensible. The optimizations make sense, the extensibility mechanism is ingenious , dangerous , fascinating. The key assumption made by this paper is that the hardware and software will continue to improve. It is hard to argue with that. The trouble is that interoperable formats like Parquet take a snapshot of the state-of-the-art and freeze it in a specification. Some innovations that are invented after the format is frozen are incompatible with existing formats because they require a different data layout. Section 1 of the paper refers to many examples related to compression, indexing, and filtering. The goal of F3 is to be general enough to allow seamless incorporation of future innovations without changing the F3 spec nor F3 decoder implementations. Fig. 2 illustrates an F3 file: Source: https://dl.acm.org/doi/10.1145/3749163 A file consists of a metadata and a set of row groups. A specific row group contains data for all columns and a subset of rows. F3 contains incremental improvements over existing columnar formats, for example: F3 metadata supports random access, which is important for operations that only need to access a smaller percentage of all columns. F3 decouples file I/O from a row group storage. The rows associated with a given column in a row group are further subdivided into , which are actually stored. This allows row groups to be sized for efficient row-group level filtering, while the IO unit size is tuned to minimize working set while also amortizing the fixed costs associated with file I/O. F3 allows flexible . Each IO unit can contain a dedicated dictionary, or multiple IO units can share a dictionary. Columns with low cardinality will benefit from smaller dictionary scopes, whereas columns with high cardinality do better with larger dictionary scopes. The stand-out feature for F3 is the yellow block in the block. The idea is that an F3 file can contain within it the WebAssembly code needed to decode the encoded values in an IO unit. If someone invents a brilliant new encoding method that works well with some data sets, they can ship the decoder right along with the data set. Storage of the WASM code shouldn’t be too much of an issue, because the storage cost is amortized across all row groups. The big questions are performance and security. Section 6.2 has some comments on this. In theory, the WASM specification is air-tight, and a bug-free implementation should be able to securely run arbitrary WASM code in-process. WASM also supports performance optimizations like parallel compilation and SIMD instructions. Something I don’t see in the paper is a discussion about how filtering interacts with WASM decoding. I suppose the extensibility could only be used for decoding, and filtering could be hard coded into F3, but that seems against the extensible spirit of F3. Fig. 11 shows the working set reduction from decoupling IOUnit size from row group size: Source: https://dl.acm.org/doi/10.1145/3749163 Table 3 shows how flexible dictionary scopes allow one to trade encoding time for compression ratio (lower relative CR numbers mean smaller files on disk): Source: https://dl.acm.org/doi/10.1145/3749163 Fig. 15 quantifies WASM overhead by comparing decode time for hard coded F3 decoder implementations vs the same algorithms expressed in WASM: Source: https://dl.acm.org/doi/10.1145/3749163 Fig. 16 shows potential savings associated with using WASM extensibility to implement a custom decoder from the literature. Source: https://dl.acm.org/doi/10.1145/3749163 Dangling Pointers I wonder how well WASM decoders can be implemented on other hardware architectures. Is WASM the ideal language for expressing this, or convenient standard that already exists? Thanks for reading Dangling Pointers! Subscribe for free to receive new posts. Source: https://dl.acm.org/doi/10.1145/3749163 A file consists of a metadata and a set of row groups. A specific row group contains data for all columns and a subset of rows. F3 contains incremental improvements over existing columnar formats, for example: F3 metadata supports random access, which is important for operations that only need to access a smaller percentage of all columns. F3 decouples file I/O from a row group storage. The rows associated with a given column in a row group are further subdivided into , which are actually stored. This allows row groups to be sized for efficient row-group level filtering, while the IO unit size is tuned to minimize working set while also amortizing the fixed costs associated with file I/O. F3 allows flexible . Each IO unit can contain a dedicated dictionary, or multiple IO units can share a dictionary. Columns with low cardinality will benefit from smaller dictionary scopes, whereas columns with high cardinality do better with larger dictionary scopes.
Chicago’s weather is pretty lousy most of the year, but when it’s nice, it’s very nice. June blessed the city with dozens of idyllic days. But don’t worry—I still spent most of the time inside on the computer. I launched my first big project at Ghost: automations ! It’s still in beta, but it’s one of the biggest projects I’ve led. If you happen to be a Ghost publisher, please try it out and let me know what you think! For the sixteenth issue of the Taper online magazine, I visualized time by breaking each unit into sixteenths . For example, as I write this, I’m about 6 sixteenths through the hour. Like every Taper submission, my work had to be under 2048 bytes. Generative AI continues to, mostly, be a force for bad in this world: “If AI is going to 10x our productivity across the board, that means that I should be able to produce the same amount of output by midday on Monday that, in the before times, would have taken all week. So can I just take Friday off?” From “Can we have the day off?” . “AI’s PR Problem” has a partial, but scathing, enumeration of many of the problems caused by generative AI. Useful as a reference. New AI resistance strategy: get a religious exemption . I liked this quote from 1976’s Computer Power and Human Reason : “The myth of technological and political and social inevitability is a powerful tranquilizer of the conscience.” The Ladybird browser is no longer accepting patches from the public, due to AI . I think targeted advertising should be illegal, so I loved seeing “Why Don’t We Just Ban Targeted Advertising?” in a major publication ( WIRED ). Homebrew creator Mike McQuaid created a website promoting the practice of doing open source work on company time , a practice I agree with. “Open Source software is not a ‘hobby’ for your spare time. Literally every company you have worked for couldn’t run their business without any OSS. They extract value every hour and then ask maintainers to beg for a Friday afternoon, a donation button or a kind word in an all-hands.” Solidarity with Wiki Workers United. is a proposed environment variable that disables tracking. “Build a web application that works on a playstation portable on a 3G connection—if you do, it will work for all your users, and it will still work 30 years from now.” “At some point you have to actually weave the gossamer. You have to contribute to the infrastructure itself, not just advocate for it.” Hell yeah. After our fascist president shuttered Climate.gov, it was reborn by former members of the team . Good thread about hardware-based attestation . “The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature.” (I actually think there are legitimate uses for hardware attestation , but not like this.) Mikhail Gorbachev, former Soviet Union leader, was in a Pizza Hut commercial !? Symlinking to is good chaos. How to make an HTTP request from the command line, without . The maximum size of a PDF page is about 150 square kilometers. Here’s what that looks like if it were placed over Germany. Hope you had a good June. “If AI is going to 10x our productivity across the board, that means that I should be able to produce the same amount of output by midday on Monday that, in the before times, would have taken all week. So can I just take Friday off?” From “Can we have the day off?” . “AI’s PR Problem” has a partial, but scathing, enumeration of many of the problems caused by generative AI. Useful as a reference. New AI resistance strategy: get a religious exemption . I liked this quote from 1976’s Computer Power and Human Reason : “The myth of technological and political and social inevitability is a powerful tranquilizer of the conscience.” The Ladybird browser is no longer accepting patches from the public, due to AI . I think targeted advertising should be illegal, so I loved seeing “Why Don’t We Just Ban Targeted Advertising?” in a major publication ( WIRED ). Homebrew creator Mike McQuaid created a website promoting the practice of doing open source work on company time , a practice I agree with. “Open Source software is not a ‘hobby’ for your spare time. Literally every company you have worked for couldn’t run their business without any OSS. They extract value every hour and then ask maintainers to beg for a Friday afternoon, a donation button or a kind word in an all-hands.” Solidarity with Wiki Workers United. is a proposed environment variable that disables tracking. “Build a web application that works on a playstation portable on a 3G connection—if you do, it will work for all your users, and it will still work 30 years from now.” “At some point you have to actually weave the gossamer. You have to contribute to the infrastructure itself, not just advocate for it.” Hell yeah. After our fascist president shuttered Climate.gov, it was reborn by former members of the team . Good thread about hardware-based attestation . “The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature.” (I actually think there are legitimate uses for hardware attestation , but not like this.) Mikhail Gorbachev, former Soviet Union leader, was in a Pizza Hut commercial !? Symlinking to is good chaos. How to make an HTTP request from the command line, without . The maximum size of a PDF page is about 150 square kilometers. Here’s what that looks like if it were placed over Germany.
Over the years, we have received, read and handled way over one thousand vulnerability reports filed against curl . We have seen most kinds. It is time for me to try to help future reporters by providing a short guide on how to submit a truly excellent vulnerability report to an Open Source project. We tend to call everyone who reports a security problem a security researcher , because by the act of the submission itself they fulfill the definition. There are however many different kinds of people who submit reports; from the most rookie youngster with limited experience, to the multi-decade experienced senior in the field. Most reports submitted to a project like curl come from reporters who never submitted anything to the project before and are completely previously unknown. Many reporters use hacker handles or pseudonyms, so there is not a lot to learn about the person behind the report either. We don’t know the reporters’ age, experience level, employer, sex or on which continent they live. But also: none of those things matter. When you submit a vulnerability report, consider telling the project how you want to get credited, should they consider your report real. There is a potentially almost unlimited amount of security researchers that can find problems in a project. The project receiving your report only has a limited small number of overloaded maintainers that take care of the reports. Consider this imbalance. Make your report as easy as possible for the team to manage. To us maintainers who receive a steady stream of vulnerability reports, it rarely matters exactly how the problem was detected. Whether you fell over it by accident, you found it by reading every single line of source code or if an AI pointed it out to you, it has little relevance to the security team. The team primarily cares about if the problem is real and if it is, how serious the impact is . If the problem is documented, then it likely isn’t a vulnerability. This is a common theme in curl: people report that they can find something strange or peculiar to happen when they do something, only to have one of us point out that the action is either documented to have that side-effect, or the action was done in spite of clear warnings in the documentation. To make a good vulnerability report, you should make sure you understand what the software is supposed to do – and what the documentation says its limitations and conditions are. A good Open Source project has those things documented. Figure out where and how to submit your report. If you found several problems, it is considered polite to ask the team how they want to receive the rest. As separate individual submissions or maybe as a curated list. Perhaps paced at a slow rate to avoid overflow. Never circumvent the submission method suggested by the project. That is impolite. Consider the initial submitting of the issue to be the first step in a multi-step communication process with the project that will continue for as long as at least one of your reported issues has not been resolved or dismissed. This can be days, weeks or in some cases even months. Expect responses and follow-up questions. Be prepared to clarify, expand and maybe provide more code and reasoning. Remember that you submit vulnerability reports in order to help and improve the project. These days people like to create enormously long and detailed reports that have all the details, often explained three times and with several embedded lists using bullet points describing impact and providing more or less good analysis attempts. Your first paragraph of the report should be a human-written, brief explainer of what the problem is and what badness it leads to. You should be able to explain that in just a few sentences. It is a reality-check, because if you can’t do this, if you don’t understand the flaw enough yourself to write such a paragraph, then you have homework to do. Figure it out, then come back and write the intro paragraph. Having a quality intro saves a lot of time for the security team receiving your report. Be aware that the Open Source project you contact may be overloaded, on vacation or seeing your report as yet another duplicate they already saw reported seven times. Be helpful and respect that you add a load to a small team that probably consists of volunteers working on this in their spare time. Even if you have used a lot of or just a little AI when finding the issue and writing up the report, you must make sure that you communicate as a human . With your human communication skills. Your report should contain a reproducer. Ideally a fully contained and stand-alone script or source code that the security team can build and run to see the vulnerability trigger. A reproducer helps prove to the team that the problem is real or maybe already an accepted risk or behavior. It is also convenient for the developers to first understand and reproduce the issue, and then they can convert the reproducer into a project test case for the pending fix. Without providing a reproducer in your report, you instead push that work to the receiving end. We still need the reproducer. We still need a test case. Provide a patch for the problem. If you can figure out a way to fix the code to make your finding no longer trigger, that is great information for the security team and such a patch usually helps them understand the issue better and get a speedier result. It reduces the load. Sure, such a patch is often perhaps not perfect and it can usually be improved and expanded as the developers have a different view and a more nuanced understanding of the problem and the software architecture involved. It still helps. Getting 80% towards the target is still valuable. Usually you should look for vulnerabilities in the latest version of the software, often even using an up-to-date git repository. Whatever version you used to find it, you need to specify that in your report. If the problem turns out to be real, which your report claims and you should never report anything if you don’t think so, it is then also immediately interesting to know when this problem first appeared . Which is the earliest version of the software that you can trigger this problem with? The project will want to know this to write up a proper advisory for the issue. You can help figuring this out by bisecting etc. Remain available after your initial submission. In the curl project at least, we want to work with the reporter to make sure we get every angle and detail right. First, when trying to understand and assess the initial report and agreeing on a severity for it. Then, we jointly produce and agree to a remedy (patch) for the problem, which ideally means taking the reporter’s version and massaging it into perfection. If the problem is serious enough, there could be reasons to discuss a rushed patch release at an earlier date than the pending release would otherwise happen on. To reduce the time users in the wild remain vulnerable. Finally, we collaborate on the description and explainer for the problem that goes into the security advisory . For every CVE that is registered and assigned to a particular vulnerability, there needs to be a detailed security advisory written. It should ideally describe the issue, how it triggers, what it means, the impact, the affected version ranges and more. Everything related to the vulnerability that we can think might help users. Your job as a security researcher is to make sure the description in the advisory matches your finding, your understanding of the problem and that the description is understandable. For every confirmed security report, the receiving project will try to learn from it and fix code and practices to avoid making the same mistake again. As a reporter, your job is to learn from the submission experience and try to improve your reporting procedure and approach for the next time. Then submit your next report!
My first rather large #3DPrinting project. Can anyone work out what they are? (No they're not abstract Starship Enterprises) 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 .
Solod ( So ) is a system-level language with Go syntax, zero runtime, and a familiar standard library. It's designed for two main audiences: The previous version (v0.1) focused on porting core Go stdlib packages and providing convenient C interop. At the end of that post, I said the next release would focus on networking, concurrency, or both. Now, networking is here — the v0.2 release I'm sharing today includes support for TCP, UDP, and Unix domain sockets. Concurrency is still planned for the future, so for now, servers handle one connection at a time. This release also lets you compile So to more targets, like 32-bit platforms, WebAssembly, and bare metal. And C interop even smoother! Networking • TCP server • TCP client • Deadlines • IP addresses • Targets • Interop • Stdlib • Wrapping up The main feature in v0.2 is the package. It's a simplified version of Go's package which supports the three most commonly used transports: The API mirrors Go closely, so most of it will feel familiar. The big difference is that So has no goroutines, so there's no concurrent server support — you accept and serve connections sequentially. More on that in a moment. Let's build a classic: an echo server that accepts a connection, reads a message, and sends it back. If you've written a TCP server in Go, this should look familiar — , an loop, and / on the connection. The only thing missing is a : without goroutines, each connection is handled to completion before moving on to the next . The client starts the connection using , then uses to send a request and to get the reply: UDP and Unix domain sockets work in a similar way. For UDP, an unconnected socket uses to get data and the sender's address, and to send a reply. For Unix sockets, there are (stream) and (datagram). By default, , , and are blocking. In Go, you'd typically use goroutines and contexts to prevent getting stuck forever. Since that's not available in So (yet), every connection and listener supports deadlines instead: , , and are available on , , , and listener types. When the deadline passes, any pending call fails with . If you don't set a deadline, a blocked call will wait forever. This isn't concurrency, but it's enough to keep a single-threaded server responsive. Along with , v0.2 ports Go's package, which provides small, allocation-free value types for IP addresses. represents an IP address, combines an IP address with a port, and is an IP with a prefix length (a CIDR block): These are simple value types that don't use any heap allocation, which fits well with So's explicit-memory approach. The package also provides and functions to help you work with strings. Solod compiles to plain C, which (in theory) means it can target anything a C compiler can. Because of this, v0.2 adds new targets: Here's the complete toolchain you need to build a freestanding binary using : A large part of the standard library ( , , , , , , , and more) works just fine in freestanding mode. For more details, check out the freestanding guide . A bunch of smaller changes make Solod nicer to write. Three new directives for low-level work, all documented in the interop guide : works with variables, constants, types, and functions. You can use it on multiple lines, and the attributes will stack. For example, will combine with . Type aliases . So now supports Go-style type aliases: Numeric C types . The package now includes named types for C's numeric types — , , , , , , and others. When you declare an extern function, you can use the actual C types in its signature instead of trying to guess the correct fixed-width Go type for your platform. Third-party packages . You can now add external So packages using or by vendoring, and you can organize your own code into multiple modules. So doesn't have a real package ecosystem yet, but it's a good start. Better diagnostics . By default, panic messages report the C file and line. Pass to report the original So source location instead: There's also an optional flag that adds nil-pointer checks when accessing struct fields and calling interface methods. This way, if there's a bad dereference, the program will panic cleanly instead of causing a segmentation fault. Both options are off by default to keep the generated code more readable. Beyond and , v0.2 adds a few more packages: And a small but handy update to memory management: now reclaims the last allocation if you give it the matching pointer. It's a minor optimization, but it means a quick alloc/free pair on an arena no longer wastes space. Stdlib documentation With v0.2, Solod has evolved from just "command-line tools and C glue" into something you can actually use on a network — like a TCP or UDP server, a small protocol client, or a Unix-socket daemon. The new targets (32-bit, WASM, freestanding) mean the same code can now run in more places, even down to bare metal. The big thing that's still missing is concurrency. A server that handles requests one at a time works for some tasks, but a real network service needs to manage many connections at once. That's the obvious goal for v0.3 — adding some kind of concurrency, along with the stdlib packages that support it. If you're interested, take a look at So's readme — it has everything you need to get started. Or try So online without installing anything. Go developers who want low-level control and zero-cost C interop without having to learn Zig or Odin. C developers who like Go's style. TCP (networks , , ) via , , and , with the and types. UDP (networks , , ) via , (a connected socket), and (an unconnected socket with / ). Unix domain sockets ( for streams, for datagrams) via , , , and . 32-bit platforms . The compiler and stdlib now work correctly on 32-bit platforms, where and pointers are narrower. WebAssembly (WASI) . You can compile a So program to and run it under any WASI runtime. Freestanding mode . So programs can run on bare-metal systems without any C standard library. No libc means no malloc, but you can use instead. — hex encoding and decoding, including for hexdump-style output. — generating and parsing UUIDs (v4 and v7), with random components from a cryptographically secure source.
One of my favorite visuals for known vulnerabilities in curl is the mountain . It shows how many currently known vulnerabilities were present in the code through-out curl’s history. In the end of June 2026 it looks like this: Over time we get more vulnerabilities reported. Since every flaw has a version range during which the problem existed and with more issues that have overlapping version ranges, the mountain grows. It changes shape every time we do a release or we publish a new vulnerability. At this moment in time, curl version 7.34.0 is the release that contains the most number of known vulnerabilities: 101 . The worst one ever if you will. Out of a total of 206. The mountain uses different colors for different severity levels of the published vulnerabilities, as the legend in the top-left of the image explains. To illustrate the ever-changing nature of the shape and size, I wrote a script that renders the mountain the way it looked at specific dates in the past up until today. More specifically, the script renders one image for every month since curl started (March 1998). I then turned these 340 individual images into a little movie that shows how it grew into today’s shape. At four months/second. The data for this come from vuln.pm and the curl git repository . The graph rendering is based on the dashboard scripts . All images put into a movie with ffmpeg of course. Several people have asked what happened in 2016 that caused the notable drop. A slope if you will. If we zoom in on that, we can spot that curl 7.51.0 has eleven fewer vulnerabilities than the version before that. This release was the first one after the 2016 Cure53 code audit , but other than that there is no clear distinct process or obvious code changes that explain this trend shift. Lots of other graphs show just the ordinary pace and growth in various project areas. It was still fairly early days CI-wise but had been running at least a few CI jobs per commit for a few years already by then. curl was adopted into the OSS-Fuzz project in July 2017, which since then makes us find some issues better, but the drop looks like it happened before then. We had already been analyzing the code regularly on Coverity since a few years. Better tooling? New compiler options? We simply don’t know. As we keep announcing more vulnerabilities going forward, things will continue to change. Maybe I will come back and make another movie in five years?
For some reason, the Address Book tab/pane on Thunderbird’s menu bar had gone missing, and I struggled to find out how to get it back. So, for future me, what resolved it was:
This is a quick post, mostly for my own reference. I've avoided LUTs and 'Log' video footage for years 1 , mostly because of the extra tiny bit of workflow involved. Like RAW photos, 'Log' footage retains the video sensor's full dynamic range, so you can pull more color and luminance information out of the footage later. But unlike photography, where RAW has been a thing for decades, and many workflows 'just work' without me having to 'grade' every individual photo, in video precious few consumer apps handle Log footage gracefully. You generally end up with a muddy grey mess.
Linux
Open Source
Rust
Business
Python
C++
AI
Hardware
Web Development
Programming
Security
JavaScript
Cloud
Performance
Go
DevOps
Data Analysis
Database
Gaming
C
Data Visualization
Tutorial
Movies