.title {text-wrap:balance;} #content > p:first-child {text-wrap:balance;} .gallery { display:flex; justify-content:center; } figure a:link, figure a:visited, figure a:hover, figure a:active {color:inherit; text-decoration: underline;} Netbooks are dead, but the Chuwi Minibook X scratches the same itch. The Minibook X is a 10.5″ x86_64 sub-ultrabook with 16GB RAM, a 512GB NVMe drive, and only one majorly annyoing Linux quirk. I needed a knock-around laptop, so I bought myself a Minibook for my birthday last year. The more I tote it around, the more fun I’m having with this ridiculous little computer. Chuwi Minibook X Quick specs Much like the netbooks of yore, the Minibook is a budget machine. But it’s 2026, so even budget machines pack more oomph than I need from a utility laptop. CPU 4-core/4-thread 3.6GHz Intel N150 Twin Lake 16 GB RAM – LPDDR5-6400 – soldered 😿 512GB NVMe – upgradable 10.51” IPS 2K 16:10 screen 28.88Wh Li-Ion battery Weight: 911g Ports: 2×USB-C (1×PD charging) Cost: $350 Chuwi Minibook Guts One oddity is that the Minibook comes bundled with a 12V/2A USB-C charger. I chucked the charger; I worried I’d fry some 5V SoC someday. The Minibook works fine with a PD charger. Minibook X using a PD Charger at 20V I’d assume the 12V charger was a cost-saving choice, but it also creates some weird possibilities for DC/off-grid setups. Linux and weirdness: sideways panels and kernel parameters Charlie Stross, a favorite SciFi author, talks up the Chuwi Minibook X on Mastodon The fediverse told me that Minibook runs Linux “boringly well,” which was almost true. I tried Debian, then jumped to NixOS for kicks. What works: Camera/Microphone/Speakers Touchscreen Sleep/Suspend Hibernate Keyboard backlight USB-C HDMI Bluetooth (non-free blobs – Intel) Wi-Fi 6 (non-free blobs – Intel) But on first boot, the screen orientation is 270° clockwise: Linux setup screen rotated 270°. The Chuwi’s screen is a panel from a cheap tablet; the screen rotation issue is a hardware problem (the screen is mounted sideways). To fix the screen’s rotation, I had to tweak screen orientation at every software layer. Fixing this problem was a journey: Bootloader – Switched from systemd-boot to grub, carrying some unmerged GRUB rotation patches on top. Initrd – Tell the Intel display driver about the panel orientation via a kernel parameter, and force the Intel driver to load in the initramfs. On NixOS: boot.kernelParams = ["video=DSI-1:panel_orientation=right_side_up"]; and boot.initrd.kernelModules = ["i915"]; (see Kernel docs for modedb default video mode support) Desktop environment – For X11, good ole xrandr --output DSI-1 --rotate right. Wayland picked this up from the DRM connector. This one was easy. Framebuffer – Ensure all TTYs have the proper orientation by adding fbcon=rotate:1 to kernel parameters boot.kernelParams = ["fbcon=rotate:1"]; (see Kernel docs for framebuffer console boot options) Behold, the final result in all its glory: Non-rotated system boot. Zero Cool's bootscreen courtesy of mainframed/Hackers-Plymouth Size, weight, and build This computer is mind-bogglingly small. The build is sturdy and totable; it’ll hold up to a backpack jostling. Chuwi Minibook X with "banana" for scale The laptop’s case is MacBook-esque: aluminum and good-looking. The MacBook Air’s dimensions dwarf the Chuwi’s, but the two laptops are about the same thickness. Chuwi Minibook X alongside the Macbook Air Chuwi Minibook atop the Macbook Air A notebook that weighs more than a kilo is simply not a good thing – Linus Torvalds The Minibook weighs in just shy of a kilo at 912 grams. My Minibook X weighs 912g Perf, thermals, and power tl;dr: you get what you pay for. But battery life and cooling are better than I’d have guessed. The Minibook X was never going to compile the Linux kernel in record time. But the performance matches the specs, it stays cool, and it has enough battery life to run a movie marathon. Numbers: Geekbench6 (a fun side-quest to get running on NixOS), better than I expected. Single-core: 1295 Multi-core: 3332 Wi-Fi 6 speed: 424 Mbps, more than enough to stream a 4K movie. Power Idle: 3.8W During benchmark: ~15W Battery: When I left the 1995 classic film “Hackers” looping in VLC, the battery lasted about 6 hours. Heat: Running stress-ng for 10 minutes, the hottest part of the laptop chassis remained below 90°F (32°C): Thermal camera view of Chuwi Minibook X running stress-ng What I dislike There’s so much to dislike about this laptop: Screen is terrible – 2K? 50Hz refresh rate? Why!? Keyboard is terrible – it only registers keystrokes when you hit the exact center of each key. Touchpad is terrible – It’s a diving board-style, without physical buttons. Sound is meh – I can hear the tinny laptop speaker fine, but it’s underwhelming. I’ve never tried tweaking it in Pipewire, though; it’s possible it could be better. But “terrible” is in comparison to the nicest modern laptops in existence. Everything I listed here works fine. I’m honestly blown away when I tune my expectations to the sub-$400 laptop range. Verdict In The Death and Life of Great American Cities, Jane Jacobs wrote, “new ideas require old buildings”: cheap spaces let people try risky ideas. The Chuwi Minibook X is an old building. I can brick the Minibook and have a normal Monday on my serious work laptop. Nothing has to work, which makes it perfect to try out new Linux desktop stuff: NixOS – I’ve been using Debian for 15 years+, figured I’d try joining the NixOS cult for a while. RiverWM – I’m on a quest to find the Wayland version of XMonad; River is pretty close. KDE Plasma – I’ve used a tiling window manager for over a decade. What’s it like to use a desktop that Just Works™? Steam – Never been much into games, but I decided to give Steam a try since, well, why not? Cheap, weird computers like the Chuwi make it safe to play. And playing with computers is still fun. Playing Melatonin on Steam on the Chuwi

.title {text-wrap:balance;} #content > p:first-child {text-wrap:balance;} Hackers are pwning packages at an exhausting clip. But the hacks are hackneyed. What’s new is the doom cycle: Code that steals keys to publish code to steal more keys. A zombie army of infected code. And AI is making it worse. GitHub Actions are a trap Trivy is an open-source security scanner. But if you used Trivy in late March, you had a bad time. On March 19th, hackers pushed a version of Trivy that tried to smuggle secrets from anywhere it ran. Trivy cited a “misconfiguration” in their continuous integration (CI) system, GitHub Actions. But the exploit was less a misconfiguration and more a GitHub Actions trap. Admiral Ackbar warning about the trap in GitHub Actions Here’s a simplified version of how Trivy got pwnd1: # INSECURE. DO NOT USE. on: pull_request_target jobs: check: steps: - uses: action/checkout@deadbeefdeadbeefdeadbeefdeadbeefdeadbeef with: ref: refs/pull/${{ github.event.pull_request.number }}/merge - uses: ./.github/actions/setup-go - uses: some/go-static-analysis@c0ffeec0ffeec0ffeec0ffeec0ffeec0ffeec0ff At first glance, this code looks fine: No secrets referenced. Third-party actions pinned to an immutable hash. Check out a pull request. Perform some static analysis. But this code is a verbatim antipattern from a 2021 GitHub blog post titled “preventing pwn requests”: if the pull_request_target workflow only […] runs untrusted code but doesn’t reference any secrets, is it still vulnerable? Yes it is – GitHub Security Lab The problem is pull_request_target: pull_request_target – plunks a nice, juicy GITHUB_TOKEN into the environment. actions/checkout – takes an optional parameter persist-credentials, which removes secrets if set to false. But the default for the parameter is true. Setting the persist-credentials parameter to false has been an open issue in GitHub Actions since 2021. Your $HOME is a crime scene Once hackers had Trivy’s keys, they published a new version of Trivy to steal more keys. LiteLLM used Trivy in their CI. The same CI they used to publish code to PyPI, the Python software registry. When LiteLLM’s CI ran the compromised Trivy, hackers nabbed their publishing key. And on March 24th, when Callum McMahon fired up his IDE, his MacBook froze. And that’s how he discovered the LiteLLM hijack. McMahon’s MacBook was flailing at bad code that hackers snuck into LiteLLM. And the bad code trying to steal credentials: ~/.netrc ~/.aws/credentials ~/.config/gcloud ~/.config/gh ~/.azure ~/.docker/config.json ~/.npmrc ~/.git-credentials ~/.kube/ Files that are typically strewn around $HOME directories, full of tokens and keys, often unencrypted. AI and the supply chain doom spiral We’ve dealt with problems like unencrypted credentials, unpinned dependencies, and CI footguns forever. But AI has accelerated everything, including repeating security mistakes. On the day of the Trivy compromise, I asked Claude, “how do I scan docker registry images for security vulnerabilities?” The reply, in part: CI/CD Integration Example (GitHub Actions with Trivy) - name: Scan image for vulnerabilities uses: aquasecurity/trivy-action@master Broken in two ways: Unpinned references – master is a reference that changes all the time. If hackers zombify the repo, I’d be the first victim. Active vulnerability – No mention whatsoever of the CVE posted that day. I never asked, so Claude never checked. Meanwhile, Vercel’s CEO has attributed his company’s recent data breach to a hacker that was “accelerated by AI.” And Anthropic’s latest hype tour includes briefing the US Federal Reserve Chair about vulnerabilities unearthed by their frontier model. Bad guys with LLMs get superpowers. Good guys with LLMs fall prey to mid-2010’s CI problems. And the same tool that can root out 27-year-old security problems in OpenBSD, will still tell you to pin your GitHub actions to @master. My GitHub Actions example is a simpler verison of the action removed in aquasecurity/trivy #10259.↩︎

Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else. – Eagleson’s Law After scouring git history, I found the correct config file, but someone removed it. Their full commit message read: Remove config. Don't bring it back. Very. helpful. But I get it; it’s hard to care about commit messages when you’re making a quick change. Git commit templates can help. Commit templates provide a scaffold for your commit messages, reminding you to answer questions like: What problem are you solving? Why is this the solution? What alternatives did you consider? Where can I read more? What is a git commit template? When you type git commit, git pops open your text editor1. Git can pre-fill your editor with a commit template—a form that reminds you of everything it’s easy to forget when writing a commit. Creating a commit template is simple. Create a plaintext file – mine lives at ~/.config/git/message.txt Tell git to use it: git config --global \ commit.template '~/.config/git/message.txt' My template packs everything I know about writing a commit. Project-specific templates Large projects, such as Linux kernel, git, and MediaWiki, have their own commit guidelines. Git templates can remind you about these per-project requirements if you add a commit template to a project’s .git/config file. Another way to do this is git’s includeIf configuration setting. includeIf lets you override git config settings when you’re working under directories you define. For example, all my Wikimedia work lives in ~/Projects/Wikimedia and at the bottom of my ~/.config/git/config I have: [includeIf "gitdir:~/Projects/Wikimedia/**"] path = ~/.config/git/config.wikimedia In config.wikimedia, I point to my Wikimedia-specific commit template (along with other necessary git settings: my user.email, core.hooksPath, and a pushInsteadOf url to push to ssh even when I clone via https). Forge-specific templates Personal git commit templates lead to better commits, which make for a better history. The forge-specific pull-request templates are a band-aid, the cheap kind that falls off in the shower. There’s no incentive for GitHub to make git history better: the worse your commit history, the more you rely on GitHub. Still, all the major pull-request-style forges let you foist a pull-request template on your contributors. As a contributor, I dislike filling those out—they add unnecessary friction. Commit message contents Your commit template allows you do the hard thinking upfront. Then, when you make a commit, you simply follow the template. My template asks questions I answer with my commit message: 72ch. wide -------------------------------------------------------- BODY # | # - Why should this change be made? | # - What problem are you solving? | # - Why this solution? | # - What's wrong with the current code? | # - Are there other ways to do it? | # - How can the reviewer confirm it works? | # | # ---------------------------------------------------------------- /BODY But other clever folks cooked up conventions you could incorporate: Conventional commits – how do your commits relate to semantic versioning? This makes it easier for SRE and downstream users. Problem/Solution format – first pioneered by ZeroMQ2, this format anticipates the questions of future developers and reviewers. Gitmoji – developed for the GitHub crowd, this format defines an emoji shorthand that makes it easy to spot changes of a particular type. Commit message formatting How you format text affects how people read it. My template also deals with text formatting rules3: Subject – 50 characters or less, capitalized, no end punctuation. Body – Wrap at 72 characters with a blank line separating it from the subject. Trailers – Standard formats with a blank line separating them from the body. People will read your commit in different contexts: git log, git shortlog, and git rebase. But git’s pager has no line wrapping by default. I hard wrap at 72 characters because that makes text easier to read in wide terminals.4 Finally, my template addresses trailers, reminding me about standard trailers supported in the projects I’m working on. Git can interpret trailers, which can be useful later. For example, if I wanted a tab-separated list of commits and their related tasks I could find that with git log: $ TAB=%x09 $ BUG_TRAILER='%(trailers:key=Bug,valueonly=true,separator=%x2C )' $ SHORT_HASH=%h $ SUBJ=%s $ FORMAT="${SHORT_HASH}${TAB}${BUG_TRAILER}${TAB}${GIT_SUBJ}" $ git log --topo-order --no-merges \ --format="$FORMAT" d2b09deb12f T359762 Rewrite Kurdish (ku) Latin to Arabic converter 28123a6a262 T332865 tests: Remove non-static fallback in HookRunnerTestBase 4e919a307a4 T328919 tests: Remove unused argument from data provider in PageUpdaterTest bedd0f685f9 objectcache: Improve `RESTBagOStuff::handleError()` 2182a0c4490 T393219 tests: Remove two data provider in RestStructureTest Git commit templates free your brain from remembering what you should write, allowing you to focus on the story you should tell. Your future self will thank you for the effort. Starting with core.editor in your git config, $VISUAL or $EDITOR in your shell, finally falling back to vi.↩︎ I think…↩︎ All cribbed from Tim Pope↩︎ Another story I’ve heard: a standard terminal allows 80 characters per line. git log indents commit messages with 4 spaces. A 72-character-per-line commit centers text on an 80-character-per-line terminal. To me, readability in modern terminals is a better reason to wrap than kowtowing to antiquated terminals.↩︎

[The] Linux kernel uses GPLv2, and if you distribute GPLv2 code, you have to provide a copy of the source (and modifications) once someone asks for it. And now I’m asking nicely for you to do so 🙂 – Joga, bbs.onyx-international.com Boox in split screen, typewriter mode In January, I bought a Boox Go 10.3—a 10.3-inch, 300-ppi, e-ink Android tablet. After two months, I use the Boox daily—it’s replaced my planner, notebook, countless PDF print-offs, and the good parts of my phone. But Boox’s parent company, Onyx, is sketchy. I’m conflicted. The Boox Go is a beautiful, capable tablet that I use every day, but I recommend avoiding as long as Onyx continues to disregard the rights of its users. How I’m using my Boox My e-ink floor desk Each morning, I plop down in front of my MagicHold laptop stand and journal on my Boox with Obsidian. I use Syncthing to back up my planner and sync my Zotero library between my Boox and laptop. In the evening, I review my PDF planner and plot for tomorrow. I use these apps: Obsidian – a markdown editor that syncs between all my devices with no fuss for $8/mo. Syncthing – I love Syncthing—it’s an encrypted, continuous file sync-er without a centralized server. Meditation apps1 – Guided meditation away from the blue light glow of my phone or computer is better. Before buying the Boox, I considered a reMarkable. The reMarkable Paper Pro has a beautiful color screen with a frontlight, a nice pen, and a “type folio,” plus it’s certified by the Calm Tech Institute. But the reMarkable is a distraction-free e-ink tablet. Meanwhile, I need distraction-lite. What I like Calm(ish) technology – The Boox is an intentional device. Browsing the internet, reading emails, and watching videos is hard, but that’s good. Apps – Google Play works out of the box. I can install F-Droid and change my launcher without difficulty. Split screen – The built-in launcher has a split screen feature. I use it to open a PDF side-by-side with a notes doc. Reading – The screen is a 300ppi Carta 1200, making text crisp and clear. What I dislike I filmed myself typing at 240fps, each frame is 4.17ms. Boox’s typing latency is between 150ms and 275ms at the fastest refresh rate inside Obsidian. Typing – Typing latency is noticeable. At Boox’s highest refresh rate, after hitting a key, text takes between 150ms to 275ms to appear. I can still type, though it’s distracting at times. The horror of the default pen Accessories Pen – The default pen looks like a child’s whiteboard marker and feels cheap. I replaced it with the Kindle Scribe Premium pen, and the writing experience is vastly improved. Cover – It’s impossible to find a nice cover. I’m using a $15 cover that I’m encasing in stickers. Tool switching – Swapping between apps is slow and clunky. I blame Android and the current limitations of e-ink more than Boox. No frontlight – The Boox’s lack of frontlight prevents me from reading more with it. I knew this when I bought my Boox, but devices with frontlights seem to make other compromises. Onyx The Chinese company behind Boox, Onyx International, Inc., runs the servers where Boox shuttles tracking information. I block this traffic with Pi-Hole2. pihole-ing whatever telemetry Boox collects I inspected this traffic via Mitm proxy—most traffic was benign, though I never opted into sending any telemetry (nor am I logged in to a Boox account). But it’s also an Android device, so it’s feeding telemetry into Google’s gaping maw, too. Worse, Onyx is flouting the terms of the GNU Public License, declining to release Linux kernel modifications to users. This is anathema to me—GPL violations are tantamount to theft. Onyx’s disregard for user rights makes me regret buying the Boox. Verdict I’ll continue to use the Boox and feel bad about it. I hope my digging in this post will help the next person. Unfortunately, the e-ink tablet market is too niche to support the kind of solarpunk future I’d always imagined. But there’s an opportunity for an open, Linux-based tablet to dominate e-ink. Linux is playing catch-up on phones with PostmarketOS. Meanwhile, the best e-ink tablets have to offer are old, unupdateable versions of Android, like the OS on the Boox. In the future, I’d love to pay a license- and privacy-respecting company for beautiful, calm technology and recommend their product to everyone. But today is not the future. I go back and forth between “Waking Up” and “Calm”↩︎ Using github.com/JordanEJ/Onyx-Boox-Blocklist↩︎