マリウス 2 days ago

Hyperuplink: Discuss like it's 1998

Between the screeching handshake of a 2400-baud modem, the steady hum of a computer in Turbo mode, and the pale flicker of a CRT glowing at three in the morning, the internet seemed to have had something that, over the past two decades or so, it has completely lost: A soul . Communities made up of actual humans gathered around bulletin boards that loaded in a single request, where regular hardware could bring an entire world to your screen without borrowing half your CPU just to show you a list of topics. If you happened to have lived through that brief and peculiar moment in history, you probably still carry a fondness for those days, and you remember the strange little corners of the internet that you discovered, the hours you spent exploring them, and perhaps the friends you made along the way. Hyperuplink is my attempt at bottling those memories and the feelings attached to them, and pouring them into something that makes sense in 2026. It is a modern internet bulletin board that doesn’t require Telnet and works inside your browser, that renders proper, modern HTML5 and CSS on the server-side, that runs 100% JavaScript-free, and that ships as a single statically linked binary with no external runtime, no interpreter, no FastCGI , no , no , and not a single loose file spilled across your disk. It can talk to a PostgreSQL server or an entire cluster, it makes use of any Redis -compatible cache, and it comes with a whole set of nostalgic as well as modern themes. More importantly, Hyperuplink is fun, it doesn’t take itself too seriously, and it is the forum software for everyone who’s done wrangling with phpBB ’s runtime environment or Discourse ’s broken JavaScript UI. And yes, Hyperuplink , too, really whips the llama’s ass. The short version, for anyone who has been idling in the community channel or who already read the back-story in an earlier status update , is that back at the time I wanted a community discussion forum for the people who use any of the tools, programs and services I’m building , and I could not find a single piece of software that I actually wanted to put up with. I was looking for an internet forum that would resemble the good old BBS systems from back in the day, but that would allow people to use it from the comfort of their modern-day browsers. I also wanted something that … phpBB was the obvious first stop, because it has been around for decades and, unlike Discourse and Lemmy , it does not force JavaScript down the visitor’s throat. But phpBB is a monster that carries far too many features, takes time to install and configure, and, once you account for its extensions and runtime dependencies, demands a recurring maintenance ritual that I frankly do not have time for. Discourse and Lemmy , on the other hand, I won’t even consider to begin with, because they simply don’t work without JavaScript enabled. Everything else I looked at either missed something I needed, would have brought similar runtime headaches, or would have required me to fork it and maintain that fork forever, just to get a few of the features that I needed. So I did the reasonable, well-adjusted thing and started writing my own bulletin board software at the end of last year . Before writing a single line I sat down and weighed the usual suspects, PHP with Laravel , Python with Django , Elixir with Phoenix , Go with Fiber , and Zig with Jetzig . I did not consider server-side TypeScript for even a second, because the Node.js and NPM ecosystem is a dumpster fire of outright malware that I refuse to pick for even something as deliberately absurd as Hyperuplink . The scripting stacks make web development pleasant, and they abstract away the tedious HTTP, session and form handling so you can focus on the thing you are building, but every one of them drags a runtime and a maintenance burden behind it. My one goal for Hyperuplink was for a hobbyist admin to be able to run a board without babysitting a whole stack. From an administrative perspective I wanted to be able to update one or two binaries every once in a while and be good, without having to subscribe to e.g. the PHP security announcements, and its mailing lists, and its security advisories on GitHub, and the NVD only to make sure I’m not missing a critical CVE of one of the gazillion of dependencies. Go sits in the sweet spot between the low-level compiled languages like C , C++ and Zig that hand you performance at the cost of development speed, and the interpreted languages like PHP and Python , that make data structures a joy to work with but that are expensive to run. The deciding factor was that Go compiles down to one statically linked binary that you copy to any VPS and simply launch. The one downside is that Go is not exactly a “web native” language and has nothing like Django or Laravel to accelerate the boring parts, so I built my own small web application framework on top of the Fiber v3 framework and went from there. Hyperuplink is a single static binary, compiled with CGO disabled, cross-compiled to Linux, macOS, FreeBSD, NetBSD, OpenBSD and a long tail of architectures, so that deployment is nothing more than copying that binary into place. It is PostgreSQL-native and cluster-friendly and it uses materialised views to optimize read performance. Schema migrations are embedded and run automatically on startup, which means there are no external migration files and upgrades should be as easy as simply firing up the new version. In addition, a Redis -compatible service is used for caching, and sessions, and the async job queue. Profile pictures, attachments, and custom assets can either be uploaded to the local disk or into any S3-compatible object store (such as MinIO ), which is useful when scaling the service horizontally. Hyperuplink runs zero client-side JavaScript, meaning that every page is server-rendered HTML5 and CSS, and there is nothing that logs how your cursor drifts back towards that thread about whether pineapple belongs on pizza, just to collect data on your account. Speaking of which, accounts can sign-up/-in via local password, with optional TOTP two-factor authentication, but Hyperuplink also supports login through OAuth providers for the friends you are trying to lure over from other platforms. And for anyone who finds email too boomer , sign-ups and notifications work over XMPP , too. As for authorization, accounts can be assigned to groups with per-category permissions so the good stuff stays available only to the good people . Hyperuplink features a range of pre-built themes, some of which feature beautiful retro aesthetics that it owes to the classic-stylesheets project. There are also slightly more modern looks available, and with every theme the colour schemes are interchangeable, so a Gruvbox -tinted macOS 9 board is very much a thing. The bulletin board supports Markdown in posts, it offers uploading profile pictures and attachments, it comes with reporting and moderation features for the admins, and the UI supports i18n. Hyperuplink also ships with a REST API that I believe is friendlier to work with than what Lemmy or Discourse expose, and it even has its own TUI client with the official Hyperuplink integration into Neon Modem Overdrive . Hyperuplink is developed on tty.fail and mirrored to GitHub , the mirror being where the pre-built binaries and container images are built and hosted ( thanks for the free CPU cycles! ). Regardless of how you decide to run your bulletin board, you will need a PostgreSQL and a Redis -compatible server reachable, plus, optionally, an S3-compatible store if you would rather keep uploads off the local disk. The official repositories contain all the required documentation and configurations to get you started as quickly as possible, but the basic idea is that you can simply grab the binary for your platform from the releases page , drop it wherever you please, and run it: There’s a whole Docker and Podman (rootless!) setup available, if you would rather bring the entire stack up at once. The repository ships a / with PostgreSQL and Valkey and an optional MinIO profile: The Podman setup does everything the Docker setup does but rootless, and alongside the there is even a set of Quadlet units if you prefer using systemd . Kubernetes works, too, and a minimal with a couple of replicas and the config handed in through a is pretty much all you need. Since the uploads can use S3 the pods stay stateless. Ebuilds are available in the repository so you can compile it on your own Gentoo… server… I guess. I tried including all that’s necessary for Nix but to be fair, I’m not actively using it anywhere so consider this more of a proof-of-concept rather than an actively maintained thing. If you feel like actively maintaining the Nix part of things I’d be happy for you to reach out. The repository also contain the required init scripts for FreeBSD, OpenBSD, OpenRC and even a Service definitions for systemd . If you want to build Hyperuplink yourself, for which you need Go , it’s equally easy to do: The self-contained binary lands in , ready to be moved wherever you please. Note: Alright, alright, I lied, and you got me. No runtime dependencies was not 100% accurate and you’re probably staring at a forum that refuses to allow its users to upload profile pictures. The reason for that is that Hyperuplink has one runtime dependency, which is ImageMagick ’s command. The service must be able to find that binary in its in order for profile pictures to work. As for why, it’s a long story, but the tl;dr is that image processing is hard and there aren’t many people, me included, who feel like reinventing the wheel for, let’s say, the WebP compression algorithm, by building a native Go implementation. Because I explicitly didn’t want to use for the sake of preserving Go ’s easy cross-compiling, I decided that calling the binary was the most reasonable approach. After all, you’re likely to have ImageMagick on your system if you’ve ever hosted anything web related on there. However you end up running the process, put it behind a reverse proxy that terminates TLS, because in the session cookie is HTTPS-only and you most definitely wouldn’t want to run the forum in mode. Also, if you want the service supervised there are the aforementioned service files for systemd , OpenRC on Gentoo and Alpine, and rc.d on FreeBSD and OpenBSD waiting in the repository. Hyperuplink is open source under the SEGV License , the code is available on tty.fail with the mirror and the pre-built binaries over on GitHub , and everything else you could want to read about it is either available at hyperup.link , or within its own embedded manual that you can find under Help -> Manual . If all of this sounds like your kind of thing, come and say hello in the chatroom , show off your board once you have it set up, and if you would like to lend a hand with development or testing then reach out , because the best communities were always the ones with real people, putting in real work. can either use an existing database table to authenticate users, and/or… supports simple signups, ideally with XMPP JIDs instead of email addresses supports notifications and replies via email and ideally via XMPP is lightweight and does not drag along a mountain of runtime dependencies does not require users to have JavaScript enabled does not bury me under administrative features I will likely never touch is reasonably easy to theme and, more importantly, to maintain long term

Web Development Open Source C++ CSS Elixir

マリウス 6 days ago

The Cables that Connect the World

At the northeastern edge of La Línea de la Concepción , on a scrubby Mediterranean beach called El Burgo–Torrenueva , there is an old battlement-tower, La Torre Nueva , and not much else. It was part of the system of coastal watchtowers during the 16th century that would defend the area against the incursion of the Barbary corsairs . The coordinates are . Walk the tideline and you would never know that buried two metres beneath the sand, a fibre-optic cable comes out of the sea here and turns into the internet. It’s the start of a line that runs across the Strait of Gibraltar to Ceuta , on the African coast, and on toward two continents. Nearly everything you do online that crosses an ocean passes through a cable like this, ending, in most cases, underneath a similarly unremarkable patch of coast. Note: Ceuta is an interesting place by itself, that has recently gained some attention and that would also make for an interesting write-up of its own. However, the tl;dr is that it is an autonomous Spanish city of some 85,000 people sitting on the North African coast, bordering Morocco , which means the European Union has one of its very few land borders with the African continent running straight through a peninsula most people could probably not even point to on a map. It has been held by the Spanish crown since 1668, it had been Portuguese before that, and Morocco seemingly never stopped claiming it. For our purposes, though, what matters is that the small enclave, until very recently, hung off the mainland’s network by a single ageing link. When we talk about the internet we do so as if it were air. Ambient, ownerless, and everywhere. In reality, however, it is the exact opposite, because international data doesn’t (normally) travel by, let’s say, satellite, despite what most people might assume. It travels through roughly 1.5 million kilometres of very real (and very owned) fibre-optic cable lying on the seabed, surfacing at a small number of carefully chosen landing points. For these landing points you normally need a gently sloping seabed, mild currents, and little marine traffic, so that anchors and trawlers don’t sever the line. Suitable spots are scarce enough that the same beach usually becomes the shared landfall for several cable systems at once. Unlike what you might be thinking of at first, submarine cables aren’t your run-of-the-mill Ethernet or fibre cable. The hardware that does the heavy lifting out in the deep ocean is about as thick as a garden hose with roughly 25mm across and weighing in at around 1.4 tonnes for every kilometre. The part that carries your data is a small bundle of glass fibres, each one around the same thickness as human hair, sitting in the very middle. Everything else wrapped around those fibres is there to keep them alive in a deeply hostile environment. Working outward from the core, the fibres sit in a water-blocking gel inside a thin copper or aluminium tube, which is sheathed in polycarbonate, then an aluminium water barrier, then a layer of stranded steel wires that give the cable its tensile strength, then a wrap of mylar tape, and finally an outer skin of polyethylene. The copper is for power, because the cable doubles as a very long extension lead, which we will get to in a moment. Closer to shore, where trawlers and anchors roam, the whole thing gets one or two further jackets of galvanised steel armour wire, swelling it to 50mm or more in diameter and several times the weight. Hence, the cable that surfaces on our Spanish beach is buried a couple of metres down and not simply left lying on the sand. The reason a copper conductor runs the entire length is that light, no matter how pure the glass, slowly fades as it travels, and so every 50 to 80 kilometres the cable is interrupted by a repeater , which is an optical amplifier that boosts the signal back up before passing it along. Each repeater needs electricity, and because the fish sadly still didn’t manage to install power sockets on the ocean floor, the shore stations at either end have to feed a direct current of anywhere between 3,000 and 15,000 volts down that copper core, to literally power the cable from both ends at once. On top of the amplification, modern systems lean on a stack of clever tricks to keep the signal intelligible across thousands of kilometres of glass, including wavelength-division multiplexing to cram many separate colours of light down a single fibre, coherent detection to read them back out, and forward error correction to repair whatever gets garbled along the way. Length, then, is mostly a question of power and amplification rather than of the glass itself. Shorter hops can dispense with repeaters entirely, hence an unrepeatered span will happily run to around 250 kilometres on amplifiers at each end alone, which is roughly the length of the line we started this post with. At the other extreme, a single system can stretch across an ocean, and the longest of them, like the 2Africa cable encircling the continent it is named after, run to tens of thousands of kilometres. The actual manufacturing and laying of these cables is, perhaps a little surprising for something the entire global economy rests on, the business of only a small handful of companies. The bulk of the world’s submarine cable is built and installed by just four suppliers, namely the American SubCom , the French Alcatel Submarine Networks , the Japanese NEC , and the Chinese HMN Technologies . They own and operate the specialised fleet of cable-laying ships, which aren’t exactly the kind of boat you would recognise from a harbour, but more like a purpose-built vessel carrying thousands of kilometres of cable coiled in enormous tanks below deck, rolling it out over the stern at a steady walking pace as they crawl across the ocean. Deploying a new system is a multi-year effort that begins long before any ship leaves port. First somebody, these days increasingly a content giant rather than a phone company, decides a route is worth having and assembles the money for it, either alone or as a consortium of several owners sharing the bill. Then comes a marine survey, in which a ship maps the intended path along the seabed to find the gentlest, safest route around wrecks, trenches, and other people’s cables, followed by the permitting, which is the paperwork of securing landing rights and concessions from every jurisdiction the cable so much as touches. As we are about to see on the Spanish beach, this can generate a remarkable quantity of bureaucracy . Only once all that is settled does the cable get manufactured to length, loaded onto the ship, and laid, with the vessel simply lowering it onto the seabed in deep water and a sea plough burying it a metre or two beneath the sediment closer to shore, where the danger from fishing and anchors is greatest. A working ship covers somewhere in the region of 100 to 200 kilometres a day, so an ocean crossing takes several weeks at sea. A transatlantic system running some 7,000 kilometres typically costs in the order of 250 million USD, while a longer trans-Pacific route can easily climb towards 400 million, and the cable itself runs anywhere from roughly 6,000 to 20,000 dollars per kilometre, depending on how many fibre pairs it carries and how heavily it is armoured. Keep in mind that the spending does not stop once the cable is lit, because a submarine cable has a design life of only around 20 to 25 years and on top of that there are somewhere between 150 and 200 faults occurring across the world’s cables in a typical year. The overwhelming majority of them are not caused by sabotage or sharks, but by the combination of fishing gear and dragged ship anchors. Each break has to be mended by sending out one of a small number of dedicated repair ships, that are on permanent standby under regional maintenance agreements, to grapple the cable up off the seabed, haul both severed ends to the surface, splice them back together, and lower the repaired thing back down. This is slow and weather-dependent work that is quite expensive. With the data provided by TeleGeography ’s Submarine Cable Map I have put together a list of the (co-)owners of undersea cables and sorted it by the number of cables each individual company has a stake in. The full dataset runs to some 473 distinct owners, the overwhelming majority of which are obscure national and regional carriers you will never have heard of, so rather than just dumping the entire list here, I limited it to the hundred most prolific (co-)owners: Note: These figures are derived from the public Submarine Cable Map data, counting both, systems already in service, and those still planned or under construction (603 of the former, 91 of the latter, at the time of writing). The field is free-form text, so a few owners turn up under more than one spelling, and I had to do a little manual untangling of company names. What jumps out, at least to me, is the name sitting right at the top. For most of the history of this infrastructure the owners were telephone companies, the BTs and AT&Ts and NTTs of the world, laying cables to carry one another’s calls and, later, traffic. Google now has a stake in more submarine cables than any traditional carrier on the planet, with Meta not far behind, and Microsoft and Amazon both slowly accumulating their own share. The companies that fill those cables with traffic have, over the past decade or so, decided that they would rather own the pipes than rent them. The other thing the numbers tell you is just how long the tail is. Of those 473 owners, some 260 appear on exactly one cable, and more than 340 of them, north of seventy percent, on no more than two. These are the world’s national telecoms, each one buying a slice of the handful of consortium cables that happen to land on its particular stretch of coast, which is also why so many of the big international systems list a dozen or more co-owners apiece. The internet, seen from this angle, is less of a single network and more of a mix of local operators, all chipping in for a share of the same few very expensive ropes across the ocean. To see what it looks like where the cable actually meets the land, let’s head back to that beach in La Línea . The cable that surfaces there is called Dos Continentes , it belongs to GTD , a Chilean telecoms group , and it’s a relatively small regional system consisting of two armoured fibre cables looping across the Strait of Gibraltar to Ceuta , the Spanish enclave on the African coast that depended on a single ageing link before this one was built. I went looking for exactly where it comes ashore, and the paper trail gives an idea about how invisible this infrastructure actually is. The cable lands in Spain, but the public Spanish government map of coastal concessions doesn’t seem to show it, because it looks like coastal permits in Andalusia are devolved to the regional government. The landfall instead shows in a regional registry , in a signed resolution buried under an expediente number. That document pinpoints where the cable enters the public maritime domain, at grid reference , just seaward of the beach manhole. The cable then runs inland, buried as the permit insists ( “no exterior element above ground level” ) to what is presumably a network node, where traffic is fed into GTD ’s pre-existing terrestrial dark-fibre network, from where it’ll eventually travel to one of the actual GTD data centres in Madrid , Barcelona , Bilbao/Sopelana , and Sevilla . On its way out to sea it crosses three older cables already lying on the seabed, namely Europe India Gateway , ATLAS , and FLAG . As can be seen (or, well, actually not) even an empty-looking patch of water off a Spanish beach is layered with other people’s infrastructure. Note: When GTD applied, it seems that the town council of La Línea formally objected and asked them to drop the project. The cable, the council said, cut straight through the main local fishing ground, “splitting it literally in two” , threatening the small shellfish and trasmallo boats that work those waters, and a protected limpet that lives on the rocks, in a town whose fleet was already squeezed by run-ins with Gibraltar over fishing rights. However, they were overruled and the concession was granted anyway, with mitigation conditions attached, for an initial fifteen years. The Dos Continentes cable ( Segment I , La Línea - Ceuta Sur ramal ), owned by GTD Cableado de Redes Inteligentes, S.L.U. , the Spanish arm of the Chilean GTD group , has a total length of ~105 km and is in service since 2020 under the signed concession resolution from the Junta de Andalucía ( Dirección General de Calidad Ambiental y Cambio Climático ), expediente , dated 14 January 2020. The two key points, as given in the resolution’s coordinate table are: Note: The resolution’s prose text gives a slightly different value that disagrees with its own table by approximately 140m. To convert the UTM coordinates I used the official Instituto Geográfico Nacional ( IGN ) Calculadora Geodésica with the following settings: and differ by only centimetres in practice, so the resulting coordinates (WGS84-equivalent) can be dropped straight into any consumer map or GPS app: Both points sit on Playa de El Burgo–Torrenueva , beside the Punta de Torrenueva tower, at the northeastern ( Levante / Mediterranean-facing) edge of La Línea de la Concepción , against the municipal boundary. The resolution describes the route as passing “muy cerca de la torre-faro existente en la Punta de Torre Nueva” . As you can see, however, you see nothing. :-) The permit requires the whole installation to be subterranean ( “no exterior element above ground level: No manholes, splices, connections or terminals.” ), hence you can stand exactly on the landfall, but it’s a point in the sand by a tower, and not a structure. On the afternoon I was there, a couple of dozen people were spread out on that stretch of sand under parasols, probably not even knowing that somewhere underneath them the link that carries an entire enclave’s traffic to another continent came out of the sea. It is interesting to see that what has changed most over the past decade isn’t the technology itself, but who pays for it. For a century these systems were built by carriers selling capacity to one another, which made the network something close to a shared utility with many owners. Today, however, the largest (co-)owner of submarine cable on the planet is an advertising company. It probably makes sense in their position, however it is a change in how the network is governed, and, more importantly, it seems to have happened almost entirely out of public view, which is worrying. If you live anywhere near a coast, there is a decent chance one of these things lands within driving distance of you, and the TeleGeography map will get you to roughly the right bay. Getting from there to the actual patch of sand takes some amount of digging through concession resolutions, planning registers, environmental reports, and sometimes the local newspaper archive. It took me an evening of reading to narrow it down, but I can recommend to do this exercise if you’re curious about the world that you’re living in and, more importantly, the hidden infrastructure surrounding you. PS: Maybe we picked the wrong word and should have called it the trench rather than the cloud ? Transformation type: Transformación de Datum Reference system: ETRS89 Input coordinates: UTM Huso (zone): 30

TypeScript Data Hardware Programming

マリウス 1 weeks ago

Flipper BUSY Bar

Yes, it is in fact real, I’m holding it in my hands, and after what feels like years of Flipper teasing everyone with this ominous device in various online posts, I can finally confirm that it is real. The BUSY Bar is a 250 gram desk device by Flipper Devices , the company behind the Flipper Zero and the still very much in-development Flipper One . It’s basically a little display that shows various things on a 72x16 RGB LED matrix, and as of writing this it’s main selling point is that can run a Pomodoro-style focus timer , and that it has a ful-blown HTTP API that’s available over USB, over the local network and over the internet, that let’s you control this thing. The BUSY Bar has a five-position selector on the top, that switches between the two focus modes ( BUSY and CUSTOM , which are functionally identical and only differ in their defaults), a OFF position that in reality is more of a sleep mode which turns both screens off, an apps position that currently only holds a clock, and a settings position for, well, the settings. A large mechanical button in the middle starts and pauses a session, a scroll wheel adjusts the timer and doubles as an OK button, and last but not least there’s a back button for when you have to navigate back. Speaking of back, the backside of the device has a 1.54 inch monochrome OLED that shows the timer, the battery percentage and the Wi-Fi, Bluetooth and USB indicators. This way the device remains usable to its own user as well, even when clipped to the top edge of a monitor using its built-in mount, pointing its primary matrix display away from its user. The device measures 168.6 x 55.2 x 40.8mm and weighs 250g/8.82oz. The body is made out of PC/ABS with a PC front and back panel, and the monitor mount padding is TPE. The bar fits monitors up to 21mm thick and I can confirm that it works on curved displays as well. However, if you have a particularly thin monitor (say, one of these portable displays) it won’t be able to sit on top of it. The full specifications, as published in Flipper’s own documentation , are as follows: The 72x16 matrix is driven by the ICND2153 , a 16-channel constant-current PWM sink driver with a 16-bit grayscale shift register, LED open detection and a pre-charge circuit for ghosting reduction, and the ICN2012 8-channel power switch. One thing that is a bit sad in 2026 is the 2.4 GHz limitation for Wi-Fi. In an office environment full of devices and microwaves the bar is on the most congested spectrum available. The USB side is also kept, let’s say lightweight , with its 12 Mbit/s maximum speed, which, however, is certainly enough for a virtual ethernet interface serving a web UI and an HTTP API. On the charging side the documentation asks for an 18 W or higher PD charger for the 2.5 hour figure, while the device itself only appears to use 5V⎓3A (15 W) and 9V⎓1.5A (13.5 W) as its PD modes. There is one discrepancy with regard to the display brightness, where the tech specs page lists no brightness figure at all, the product page currently says 400 nits, and the launch coverage from CNX Software and XDA both quote 800 nits. I don’t have the equipment to measure it, so I can’t really tell which it is, but I can assure you that even in a brightly lit space it’s plenty bright. Flipper published an official disassembly guide on iFixit , which is awesome. Its 21 steps describe a device that’s designed with repairability in mind. The back cover is held by 8 clips and comes off with a plastic card. Below it are 5 Phillips PH1 screws, one on the bottom and four on the back. The battery has a press-latch connector and needs to be disconnected before anything else. The display flex cables use spudger-release latches, the main PCB is held by 3 screws, the control PCB by 5 latches, the front display back cover by 6 latches and the button stabilizer by 3 screws. The monitor mount legs are friction fits. Nothing is glued and the battery is a standard 18650 cell on a 4-pin connector, which means a replacement is easily and cheaply available from most electronics shops. For a 2026 consumer device this is probably something that my fellow Right to Repair advocates will love. The firmware sources are on GitHub as . Most first-party code is GPL, the library is MIT, graphical assets are CC-BY 4.0 and fonts are OFL 1.1, all of which are declared in a REUSE manifest. The build system is FBT , the same SCons-based Flipper Build Tool used for the Flipper Zero , and the dependency list is a usual embedded stack with FreeRTOS underneath Flipper’s own abstraction, lwIP for TCP/IP, TinyUSB for the USB device side, Mongoose as the embedded HTTP and WebSocket server, mbedTLS for TLS and LVGL for the UI. The bar also includes JerryScript in , wired up through and a service. That is the same JavaScript engine the Flipper Zero uses for its scripting apps. With the engine already in the firmware the only thing that still seems missing is the documented way to load your own scripts onto the device. The BUSY Bar runs an HTTP server and speaks the same API over three transports, documented as OpenAPI 3.1 . Plugging the device into a computer over USB brings up a virtual ethernet interface with the device at a fixed , printed on the back of the unit. is the local web interface, is the API reference generated by the firmware currently on the device, and is the base URL for said API. No authentication is used over USB, but it can be used via Wi-Fi and it must be used when going through Flipper’s cloud. This request responds with the current power status. The battery current is in mA, and both battery and USB voltage are in mV, which means that you can graph the device’s own power consumption without any extra hardware. Note: Access over Wi-Fi is disabled by default and has to be turned on from the local web interface over USB first. Once enabled, you can pick a token for authentication, which would go into an header, if you decide to set one: Access over the internet goes through Flipper’s cloud with a bearer token generated at , scoped either to a single device or to the account: Flipper maintains for Python with both a synchronous and an client. It maps method names onto API paths directly, so becomes and becomes . That makes the OpenAPI document usable as the library’s reference documentation: The library also has a module that scales and re-encodes images and audio for the device, an mDNS discovery helper for , and a firmware compatibility check. On top of that there is an official TypeScript library for all the soydevs, and a community-maintained .NET client . And there is also a Zig library, but… more on that in just a moment . :-) The BUSY Bar presents itself to Matter as a single on/off endpoint, an emulated switch with a configurable startup state of , , or . Turning it on starts the BUSY timer and turning it off ends it, making the integration is a trigger. Reporting the state back to Matter requires switching on Settings ➔ Smart home , at which point focus sessions can power automations like dimming lights or locking a door when a timer is turned on. Pairing is done using a QR code on the back screen or in the web interface, and the device can be commissioned into multiple fabrics at once. The Home Assistant integration is done through the HTTP API using the generic REST facilities, which works in both directions, meaning the device as an automation trigger, and the device as an output for anything else in the house. The BUSY Bar comes with mobile apps for your smartphones. I have tested its iOS app and, well, it was okay, I guess. I’m not a huge smartphone app user to begin with, but I’ll give my two cents here. The app basically mirrors the current state of the bar and offers rudimentary control over it. When you start a timer and you have the app set up (via Flipper’s cloud) you’ll see the app pushing a permanent notification that displays the timer on your smartphone’s lock screen. It’s also possible to configure a Do not Disturb mode that prevents other apps from interrupting your focus session whenever a timer is currently running. To me these are gimmicks, but to others these features might be worth something. Having that said, the apps aren’t rated particularly highly and while I didn’t encounter any issues during the few days that I’ve tested the iOS version, the app did leave a somewhat cheap impression by the way it looks and functions. It felt like one of these apps that corporate boomers at large hardware manufacturers would come up with, falsely believing that they are in-line with what today’s generations might want. There are a few things that bother me, however none of them are actual dealbreakers. The Wi-Fi authentication is a single shared numeric key, constrained by the API schema to , sent in a plain header over unencrypted HTTP on the local network. At the four digit minimum that is a 10,000 value keyspace, and I have found no documentation of rate limiting. The access mode enum also includes an value alongside , which means that the API can be opened on the LAN with no key at all. Hence, it’s probably a good idea to use a ten digit key and keep the device off networks you don’t control. Then there’s all the coming soon . Installing user apps, the JS SDK, the Windows application, and the expanded app library, those are all future promises. I don’t doubt the Flipper team that they will eventually arrive, but I could imagine that for a non-technical user it is probably very frustrating to have bought a device that can barely do anything at all at the moment, especially on a Windows machine. The device that arrives today is a focus timer, a clock, and a status display. Lastly, the price. It launched at USD 179 for waiting list members, then USD 199 for the first 3,000 units, with USD 249 quoted as the eventual retail price. At 249 it is a very hard sell, especially in the current software state. If you’re buying this because you’re a technical user and you really want to fiddle with it, it might be worth the Pesos, but as I’ve demonstrated in the past you can build a similar device significantly cheaper yourself, especially if you’re already deep into the tinkering rabbit hole. Flipper built the device I would have expected them to build, which I mean as a sincere compliment. The hardware is over-engineered for a status light in the same way that Flipper hardware always seems to be, with a real mechanical switch, a real encoder, a replaceable 18650, an official teardown guide and no glue anywhere in it. Whether it is worth the money depends entirely on what you intend to do with it. As a device that tells your coworkers to go away, it is way too expensive and not at all effective, because people who interrupt you are not deterred by a sign that tells them not to. Let me put it this way: For roughly $50 below the BUSY Bar ’s retail price you could place one of several Smith and Wesson models on your desk and it would likely be a more effective way to deter co-workers from talking to you. However, as a small, well-built, fully scriptable RGB matrix with an 8 GB filesystem, a WebSocket, and an elaborate priority system, so that several programs can share one screen without overwriting each other, it is the most open and probably best thing in its class, and I expect the community will find uses for it that Flipper hasn’t thought of yet. PS: Turning off the BUSY bar is like quitting Vim, in the sense that it doesn’t offer an obvious way to do so. Yes, the switch on top has an “OFF” position. However, that simply turns off the displays, but it keeps the busy bar running and connected to WiFi. If you want to fully shut down the device so that it won’t consume any battery, you will have to put the switch into the “Settings” position, navigate to System , Power , and Shutdown , and confirm the poweroff with Yes . Only then the device actually turns off. As mentioned before, I have a little bonus that I’d like to share with this review, which is a Zig library that implements the BUSY Bar ’s current OpenAPI specification as closely as possible, and that brings a command line tool that lets you control the device over its HTTP API. The library supports all of Zig’s platform targets as it only uses Zig’s library, and it is fairly lightweight and easy to use. I’m using it with my BUSY Bar and it has been working great for me. The command line tool contains a few quality-of-life features like simple commands for starting and stopping the busy mode, which would otherwise require manually writing JSON payloads. Long story short, if you’re one of the people that have ordered the BUSY Bar and are maybe looking to integrate it into Zig tools, or even just into your desktop environment using your own scripts, I invite you to check out the repository . If you’d only want the CLI tool to play around with your BUSY Bar you can find builds for every supported platform over on the release page on GitHub .

JSON JavaScript Hardware Electronics Programming

マリウス 2 weeks ago

Recovering BIOS Firmware on the Star Labs StarBook

As I described in my latest quarterly update , a perfectly routine firmware update managed to turn my Star Labs StarBook Mk VI (AMD) into an expensive paperweight. I had simply copy-pasted the one-liner from Star Labs ' official documentation , the script did its thing for about half a minute, shut the device down, and from that point on the StarBook refused to boot. Black screen, keyboard backlight on, the power LED lit, and the speakers occasionally producing a clacking sound. Sadly no amount of the usual turn-it-off-and-on-again rituals or battery disconnects brought it back. The only way out of this situation is to re-flash the BIOS chip externally using an SPI programmer. Star Labs do document this , however their guide assumes you’re using their programming kit together with a dedicated debug board and an FPC cable. That kit is significantly more expensive than a generic programmer, doesn’t list any make or model information, and, at the time of writing, has been permanently out of stock on their web shop. Not exactly helpful when you’re stranded somewhere with a dead laptop that happens to be the only computer you have with you. The good news is that you don’t need any of that, at least for this specific model of the StarBook . As Star Labs ’ own Sean pointed out in the GitHub issue I opened while debugging this mess, this specific StarBook uses a SOIC-8 flash chip, which means you can recover it with a cheap, generic CH341A programmer and an ordinary SPI clip, as long as you respect its voltage. Warning: Flashing a BIOS chip externally can permanently destroy your device if you do it wrong. The flash chip on the AMD StarBook runs at 1.8V and you must use a 1.8V adapter. Driving it at the CH341A ’s default 3.3V risks damaging the chip, and won’t read it correctly anyway. Everything below is what worked for me, documented to the best of my knowledge, but you’re doing this entirely at your own risk. The flash chip on my StarBook Mk VI (AMD) , which I could read off the silicon once I had the backplate off, is a Winbond 25R128JWSQ , a SPI NOR flash in a SOIC-8 package. The suffix on Winbond parts apparently denotes the 1.8V variants. The ubiquitous, three-dollar CH341A “black” programmers that you’ll find on AliExpress , Amazon , and pretty much everywhere else operate their SPI lines at 3.3V (and the parallel header at 5V). Clamp one of those directly onto a 1.8V chip and, best case, reads garbage. Worst case, however, you cook the flash or something downstream of it. The fix is a small 1.8V adapter board (essentially a level shifter with a voltage regulator) that sits between the CH341A and your SOIC-8 clip. These are sold as kits, e.g. the KOOBOOK CH341A Programmer + 1.8V Adapter combo that Sean linked in the issue. Make sure whatever you buy explicitly mentions 1.8V. You will need a CH341A programmer with a 1.8V SOIC-8 adapter, a SOIC-8 test clip (the spring-loaded “Pomona-style” clips, or the cheaper ribbon-cable variety, both work), a second computer running Linux (can be via a live medium, e.g. a USB stick) to drive the programmer from, e.g. a department store laptop and a Fedora live USB will do, if you’re eloquent enough to explain to the staff that you’re definitely not building what almost certainly looks to them like a bomb. You will also need the correct firmware image for your model (more on that below), a small Phillips screwdriver and, ideally, a plastic spudger. Power everything off and unplug the charger before you start. Flip the laptop over and remove the backplate by undoing the two long Phillips screws in the top corners first, and then the eight shorter screws around the edges. Lift the plate off carefully. Then, remove the five screws holding the battery in place (one of the screw positions is intentionally left empty) and gently unplug the battery connector. Last but not least, locate the SOIC-8 flash chip on the mainboard. It’s the little eight-legged Winbond chip described above. Note: While I had the StarBook open, I noticed that my (barely two year old) battery had started to visibly bulge, so do take a moment to inspect yours. A swollen lithium battery is a fire hazard and should be replaced. SOIC-8 flash chips have a defined pin 1, and the clip’s pin 1 (usually the wire on the red edge of the ribbon) has to line up with it. Get the orientation wrong and the chip simply won’t show up. For reference, the pinout of the Winbond SOIC-8 flash is: You don’t have to wire any of this up by hand, though, as the clip and the 1.8V adapter carry all eight lines for you. The only thing you need to get right is aligning pin 1 of the clip with pin 1 of the chip. Note: On my chip there is a gray dot painted onto the package, on the corner opposite to pin 1. Pin 1 is instead marked by the small indented (etched) dot, on the exact opposite side from the painted one. I have no idea why the gray dot is there, but if you align to it you’ll have the clip on backwards. Look for the indentation, not for the gray spot if yours has one too. With the clip attached, plug the CH341A into your second machine. A quick look at should confirm it enumerated: Install if you haven’t already: Before writing anything, make sure can actually talk to the flash over your clip: If everything is seated correctly, will identify the Winbond chip (detected as something like ). If instead you get: …then don’t panic. In my experience this is almost always poor clip contact rather than a real problem. I had to wiggle and reseat the clamp a few times before the chip showed up reliably, because those cheap clips are fiddly. Only proceed once the chip is detected consistently across a couple of runs. Even if the firmware is bricked, it’s good practice to take a backup before you overwrite anything. Read the chip twice and compare the dumps to be sure your contact is solid: If the two reads differ, your clip contact is flaky and you should reseat it and try again. As for the firmware image, Star Labs publish their firmware in a public GitHub repository . For external programming you want a full SPI image, not the EFI/ updater files. For my StarBook Mk VI (AMD) (product SKU ) that’s the image. The full-image files also live under the model’s directory . Pick the one that matches your model and rename it to something convenient, e.g. . Note: Star Labs ’ firmware versioning is, to put it mildly, a mess. As of writing, the last AMI (the original “BIOS”) release for the AMD StarBook is , while onwards is Coreboot . Whichever you decide to flash, just make sure it’s a full image for your exact model. Last but not least, write the downloaded image using the command: By default will erase, write, and then verify the chip. Star Labs ' official command appends (i.e. and ) to skip those verification passes, but I’d recommend leaving them off so confirms the write actually stuck. Either way, do not disconnect or disturb the programmer while it’s working. Once it finishes successfully, remove the clip, reconnect the battery, screw the backplate back on, and try to boot. When I powered mine back on, the StarBook came to life again, only to stop at a screen complaining about a missing boot entry, since flashing a fresh image also wipes the EFI boot variables. That’s nothing dramatic and you just need to point the firmware back at your bootloader. You can either use the boot menu and pick your SSD, which usually re-adds the boot entry, or boot a recovery/live system and run (this is what I did), or drop into the EFI shell and launch your bootloader manually: Note: On newer Coreboot releases Star Labs are enabling Rom Armor and anti-rollback. On the AMD board external flashing and downgrading still worked for me on , but this is expected to be locked down from onwards. What frustrates me most about this whole ordeal isn’t that a firmware update can go wrong, because that’s always a risk when you flash something. It’s that Star Labs ’ documented recovery path depends on a proprietary kit that nobody can actually buy, when a generic CH341A with a 1.8V adapter seemingly does the job just fine. However, this info is nowhere to be found in Star Labs ’ official documentation, which is why I decided to publish this write-up to begin with. Hopefully it spares the next person the day (and the stress) it cost me.

Hardware Tutorial Electronics Java Shell

マリウス 2 weeks ago

Teaching an Old Dog New Tricks: Forgejo + XMPP

I recently decided to leave Codeberg and run my own Forgejo instance instead. After finishing the initial setup, I realized that a forge I host myself is a forge that I get to shape, and that I no longer have to settle for whatever feature set someone else considered reasonable. I can now make it truly mine, and switch on the things I have always wanted a Git host to do. The first of those things concerns the registration. Right now Forgejo , like pretty much every other forge, wants an email address and sends a verification link to it, because apparently a clicked link is still considered a proof that a human is on the other end. I, however, would much rather let people sign up with an XMPP JID instead. Partly, because an email address you can receive a link at has long stopped being a real obstacle for automated spam, so the whole email verification is less beneficial than people assume, and partly because XMPP is the superior protocol, and I would prefer my users to arrive over it rather than over email to begin with. Unfortunately, Forgejo has no native XMPP support. Additionally, it also makes no use of Go ’s shared objects , which would let extensions be built largely independently of the core, and which for a monolith of this size would make a great deal of sense. There is no clean place to add a protocol to it without going into the core itself. I was not, however, looking to implement real JID registration and authentication into Forgejo . That would have been a fight against windmills, and I say that from experience. My past attempts at far lighter changes were killed off by bureaucratic requirements like design discussions and collecting of use cases , and probably a laissez-passer A38 somewhere along the way. So I did what any reasonable but slightly unhinged person would do, and decided to bridge Forgejo ’s existing email integration into XMPP instead. Switchyard is a small daemon that speaks SMTP on one side and XMPP on the other. Email and XMPP happen to share the same address form, , so the recipient maps across directly, and a message addressed to goes out as a chat to the JID . It accepts the mail a service submits over SMTP , turns each one into a job on a queue, and a worker delivers it over a standing XMPP connection that reconnects on its own when the server drops it. Because it listens for SMTP the way any mail server does, Forgejo needs no patch to hand its mail over. It gets configured as the endpoint with the same block you would point at a real mail server: On the other end, a short gives it the credentials it checks Forgejo against, a certificate for the submission port, and the single XMPP account it sends everything from: With that in place, every message Forgejo would otherwise send by email, like the sign-up confirmation, the password reset, or the note about a new issue, instead goes out over XMPP to whatever JID the user typed into the email field. Switchyard also handles IDNs, because, you know, that’s kind of my thing. :-) SMTP always carries the domain in its punycode form, while XMPP uses the native IDN , so it decodes the recipient domain on the way through, and a user who registers as in Forgejo is reached at on XMPP . This lightweight service is not specific to Forgejo . Switchyard works with anything that can be pointed at an SMTP server, and turns that software into something that speaks XMPP without the software itself knowing that anything changed. The one adjustment that should be made on the other side is relabeling the “Email address” field in the HTML templates to “JID” , so people know what to put there. In Forgejo ’s case that is a small template patch, which you can easily maintain yourself. It’s a very different commitment from maintaining a full XMPP implementation that upstream will most likely never accept. The downside is that this costs you email (for now!). Once Forgejo is talking to Switchyard , everything it sends goes to XMPP , and a user who did enter an email address gets nothing. I’m already working on fixing that, by having Switchyard first check whether the destination host is an actual XMPP server at all, and fall back to forwarding the message to an ordinary mail server that you configure when it is not. That way one protocol ( SMTP ) comes in, and is distributed to either the preferred one ( XMPP ) when available, or forwarded to the fallback ( SMTP ) when it isn’t. Easy-peasy lemon-squeezy. Is any of this clean and elegant engineering? Definitely not. It is an SMTP server wired to an XMPP client (with a job queue in between), it works, and it does the job. With Switchyard I get a feature that belongs upstream but almost certainly will never get there, and for me this counts more than a clean implementation that would maybe win the beauty contest, but would remain a patch for probably the rest of its life. A patch that I would have to continuously merge and maintain across Forgejo releases. Note: I’m still in the midst of thoroughly testing this implementation on tty.fail , which is my own Git platform, and I haven’t yet opened up registrations for others to sign up. In case you would like to contribute to any of the projects and therefor would like to get early access, join the community channel and let me know!

Open Source DevOps HTML Git

マリウス 3 weeks ago

GL.iNet Mudi 7

tl;dr: After almost seven years my Netgear Nighthawk M2 has started rebooting on its own, reporting nonsensical battery percentages and ignoring most of my presses on its touch buttons, so I spent the past three months replacing it with the GL.iNet Mudi 7 ( GL-E5800 ), a 5G NR Sub-6 travel router with two nano-SIM slots plus an onboard eSIM, Wi-Fi 7, a 2.5 GbE port, two USB-C ports and a removable 5380 mAh battery. It is the most capable mobile router I have owned, its 13.5-hour battery rating is close to what I measure, and the LTE reception alone is a clear upgrade over the M2 . Sadly the Tri-band on the box means two bands at a time, there is no MLO at all, both SIM trays are underneath the battery, the touchscreen still can’t get you through a captive portal, and firmware 4.8.5 has a cellular defect that leaves the device on Connecting… after a carrier deactivates an idle data session. If you came to the Mudi line for blue-merle and IMEI randomization, you might be disappointed to learn that this sadly seems to have ended with the GL-E750 . Earlier this year I reviewed the GL.iNet Slate 7 ( GL-BE3600 ), the Wi-Fi 7 travel router that replaced my long-running Linksys WRT3200 ACM as the router in my travel setup . I mentioned in that post that I was also in the process of replacing my even older Netgear Nighthawk M2 , the LTE-A Cat. 20 hotspot that has handled my mobile data for almost seven years now. The M2 has been a reliable piece of equipment, however, it has started misbehaving so badly that I no longer trust on the road. Random reboots, increasingly nonsensical battery percentages, and touch buttons that no longer register most presses make it a tedious device to use, and with it well past any expectation of longevity, I figured it was time to give its successor a proper, multi-month trial before the M2 gives up entirely in the middle of some airport lounge. The device I settled on is the GL.iNet Mudi 7 ( GL-E5800 ), a 5G NR Sub-6 Tri-band Wi-Fi 7 travel router that GL.iNet unveiled at CES 2026 and started shipping back in April. On paper the device is an upgrade over both the Netgear M2 and the Mudi V2 aka GL-E750V2 , which was still a 4G/LTE Cat. 6 device with a 0.96" OLED. The Mudi 7 packs Qualcomm ’s Dragonwing MBB Gen 3 platform, a Wi-Fi 7 PHY with a 6 GHz radio, two nano-SIM slots plus an onboard eSIM, two USB-C ports, a 2.5 GbE Ethernet port, a 2.8" color touchscreen, and a removable 5380 mAh battery, all in a 157x75x22.8mm, 300g enclosure that runs OpenWrt with GL.iNet ’s firmware layer on top. At $419.99, or roughly €425, it is also the most expensive device GL.iNet sells. Just like the Slate 7 , the Mudi 7 is above most consumer travel routers. It comes with a 5G NR Sub-6 Rel-17 NSA/SA modem with LTE Cat. 20 (DL) / Cat. 18 (UL) fallback, and the exact specifications of the hardware are as follows: Apart from having a modem, the second difference from the Slate 7 is the 6 GHz radio, which the Slate 7 lacks entirely. However, the Tri-band on the box is a bit misleading. The Mudi 7 has radios for all three bands, but the chipset cannot drive 5 GHz and 6 GHz simultaneously, so you configure the device as either 2.4 + 5 GHz or 2.4 + 6 GHz. This also means the Mudi 7 has no Multi-Link Operation at all. On the Slate 7 I complained that GL.iNet ’s MLO documentation advertises a 6 GHz band that the hardware doesn’t have. On the Mudi 7 the 6 GHz band is present and MLO is gone, which is an odd trade for a device that costs nearly three times as much. There are two regional variants, GL-E5800NA for North America and GL-E5800EU for Europe, with different 5G NR and LTE band coverage, which is important to travelers like myself. Both variants cover n5, n7, n26, n38, n41, n77 and n78. Beyond that they diverge, as the EU model adds n1, n3, n8, n20, n28, n40 and n75, while the NA model adds n2, n12, n14, n25, n30, n48, n66 and n71, plus n13, n29 and n70 in SA mode only. LTE splits the same way, with the EU model on FDD B1, B3, B5, B7, B8, B20, B28 and B32 and TDD B38, B40, B41, B42 and B43, and the NA model on FDD B2, B4, B5, B7, B12, B13, B14, B17, B25, B26, B29, B30, B66 and B71 and TDD B38, B41, B42, B43 and B48. For my use case (almost exclusively APAC/LATAM) the EU variant turned out to be the more sensible choice, but anyone moving frequently between North America and the rest of the world should read both band lists carefully before ordering. To be fair, though, the Nighthawk M2 splits even harder. Netgear ships that device as at least five separate SKUs, and the band list for each one is quite short. The box itself contains the Mudi 7 , the battery pack, a relatively big travel pouch, a USB-C cable, and the paper manual. No external antennas and no power adapter, which I appreciate, given the chargers I already lug around. The headline feature is the modem, which uses the Dragonwing platform, Qualcomm ’s rebranded enterprise and mobile-broadband lineup. In practice the 4.67 Gbps peak figure is, as with virtually all hyped peak numbers, marketing material. Real-world throughput depends primarily on the carrier’s network, the SIM plan, the spectrum allocation, the band combination, and the signal conditions at your specific location. In my own testing I have seen sustained downlink figures in the 600–900 Mbps range on a properly-provisioned 5G network, and significantly less (in the 100–250 Mbps range) on a more typical mixed NSA deployment. What’s more important, though, is the LTE fallback. The modem falls back to LTE Cat. 20 (DL) / Cat. 18 (UL) and is significantly more sensitive than the M2 ’s aging Qualcomm baseband. In the same hotel rooms where my M2 used to show a single LTE bar at best, the Mudi 7 can consistently show two or three, often pulling more usable bandwidth on the same SIM and the same carrier. Lastly, the Mudi 7 has two TS-9 external antenna ports for those of us who care to bolt on a pair of paddle or directional antennas in RV/cabin/dead-zone scenarios. I haven’t bothered to test these, as my use case doesn’t involve any of that. However, these days most people might have almost exclusively converted to Starlink anyway, so the external antennas might not be as much of a selling point as they were ten years ago. The Mudi 7 has two Nano-SIM slots and one onboard eSIM. Both Nano-SIMs and the eSIM are managed via the touchscreen and the web UI. However, it’s important to note that the Dual SIM Dual Standby in this context means dual standby with an asterisk. The onboard eSIM and SIM slot 2 are mutually exclusive and cannot be active at the same time. The eSIM is disabled by default, and the moment you enable it, SIM 2 stops functioning. SIM 1 remains operational either way, and the modem can auto-switch (i.e. fail over) between SIM 1 and whichever of SIM 2 / eSIM is currently active, but you do not get to keep three simultaneously hot profiles. For anyone hoping to keep a local SIM, a regional roaming eSIM, and a home-country SIM in standby together, this is a bit of a disappointment. Failover itself has also been more rigid than I expected. The web UI exposes the auto-switch feature, including data-usage thresholds and signal-loss triggers, but the failover decision-making has been slow in practice. A complete loss of signal usually does cause a switchover within a reasonable amount of time, but more nuanced situations (such as one SIM throttling without any indication, or losing data while still showing connected ) often require a manual nudge. GL.iNet ’s documentation describes far more sophisticated multi-WAN coordination than the SIM-side auto-switch logic delivers. Then again, to be fair, Mwan3 on the Linksys has had similar issues and I guess down detection is just a complicated thing to get right. One caveat is that both Nano-SIM trays are underneath the battery , so putting a card in or taking one out means having the device powered down, prying off the back cover, and pulling the battery out. On a product aimed at people who buy a local SIM on arrival, that is a weird design. Then again, in many cases the device is probably already powered off because you arrived by airplane anyway. Switching between profiles that are already provisioned (either physical-to-physical or physical-to-eSIM) is one of the things the touchscreen handles well, and it doesn’t normally require any detours into the admin UI. Speaking of which, just like the Slate 7 , the Mudi 7 comes with a built-in touch display, though here it is a 2.8" color LCD rather than the much smaller panel on the Slate 7 . The screen shows the usual variety of things, like signal strength and current network type, connected client count, real-time data usage, battery percentage, Wi-Fi details with a QR code for quick joining, and the ability to toggle the VPN, the Wi-Fi, and a couple of other features without opening the admin UI. Firmware upgrades also display a progress bar on the screen, which (as I had complained about with the Linksys ) is a small but welcome quality-of-life feature. The notable thing missing from the touchscreen is captive portal handling. The moment the upstream WAN is a hotel or airport Wi-Fi network with a captive portal in the middle, the touchscreen is useless and you have to reach for a phone, tablet, or laptop, attach to the Mudi 7 , open a browser, and go through the portal manually before the router (and everything behind it) can reach the internet. But to be fair, a 2.8" panel is probably a poor place to render an HTML login form and a keyboard to begin with. The lockscreen with a 4-digit PIN that was introduced on the Slate 7 is also present on the Mudi 7 , which I once again appreciate, given the kind of sensitive information (carrier and SIM details, VPN state, hostnames) that this screen displays. One annoying quirk is the battery percentage reporting. Both the LCD and the web UI will, after a full charge, stay at 100% for the first 1–3 hours of unplugged operation before catching up to reality and dropping rapidly to whatever the actual state of charge is. The underlying kernel fuel-gauge driver does report accurate values (you can confirm this via SSH and ), but from what I can see the MCU layer that drives the LCD and the admin UI applies some smoothing to avoid the device displaying 98–99% immediately after charging. I would much rather see the truth on the screen than a smoothed consumer-friendly approximation, especially on a device whose entire purpose is to be unplugged for long stretches. The Mudi 7 shipped with OpenWrt 23.05.4 ( , Kernel ), with GL.iNet ’s firmware layer on top. The device runs Qualcomm ’s proprietary SDK and binary blobs. The same software-openness caveats that apply to the Slate 7 apply here as well. You get full root SSH access, the configuration tree, and the ability to side-load the LuCI UI if you want, but you’re stuck with GL.iNet ’s firmware for anything that touches the cellular or Wi-Fi 7 silicon. The original Mudi ( GL-E750 ) is the device that blue-merle was written for, the SRLabs package that changes the IMEI via AT commands on the device’s modem, wipes the stored client MAC addresses, and randomizes the BSSID and the WAN MAC address across reboots, and it is a large part of why the Mudi line got its reputation as the privacy-focused travel router in the first place. However, blue-merle supports the GL-E750 and nothing else, and with the 5G modem, the firmware base, and the entire platform having changed underneath it, there is no indication that this is going to change. If IMEI randomization is the reason you were looking at a Mudi specifically, the Mudi 7 does not give you that, at least today. To be fair, the firmware layer is also what makes the device usable out of the box. The Multi-WAN , WireGuard , OpenVPN , Tailscale , AdGuard Home , DNScrypt-proxy2 , Tor , and the modem management features are all preinstalled and reachable via a friendly web UI, which (as I had mentioned in the Slate 7 review) is a substantial step up over the bare vanilla OpenWrt experience on an older router like my WRT3200 ACM . The Mudi 7 supports WireGuard with up to 600 Mbps. I have been running my own WireGuard tunnel on the device, routing the entire LAN through it, and it has kept up with whatever the upstream 5G or LTE connection could deliver. As with the Slate 7 , Tailscale is available, with the same caveats. Basic connectivity works, but anything beyond the default configuration (exit nodes with advanced flags, subnet routing, tagged ACLs, etc.) is going to require manual intervention via SSH. The Mudi 7 can, like the Slate 7 , run a Tor node and route LAN traffic over it. The moment Tor is enabled, VPNs , DNS , AdGuard Home and IPv6 will not work properly anymore, because the firmware doesn’t (yet) compose these services the way a hand-rolled OpenWrt setup can. Note: As I had explained in the Slate 7 review , these limitations are 100% a GL.iNet issue and not caused by OpenWrt . The same combinations work fine if you wire them up by hand on top of a vanilla OpenWrt installation, including DNS lookups via Tor through DNScrypt-proxy2 . The UI just isn’t there yet on the GL.iNet side. AdGuard Home is, as on the Slate 7 , part of the default installation and just as plug-’n-play. I still don’t use it personally, but the web UI is identical to the one on the Slate 7 and works fine in the configurations I have tested. The Mudi 7 differentiates itself from most travel routers in the number of uplinks it can hold at once, as the device supports up to five concurrent WAN inputs: The cellular modem, the 2.5 GbE Ethernet port (when configured as WAN), Wi-Fi-as-WAN (i.e. repeater mode), USB-C tethering from a phone or a secondary modem, and USB-C-attached USB Ethernet adapters. The firmware uses Multi-WAN underneath, with a friendly UI on top. Router, access point and extender modes are all supported, WDS is not. The device features dual USB-C, with one of the USB-C ports being power-only. The other USB-C port is a fully-featured 10 Gbps port with USB tethering, and USB OTG support. It’s possible to charge the Mudi 7 on one port while simultaneously tethering on the other. USB tethering itself, just like on the Slate 7 , is a matter of a few clicks in the UI. Plug a phone in, enable tethering on the phone, and the Mudi 7 picks it up as a USB Ethernet WAN. The same applies to a USB-to-Ethernet adapter, should you ever need to add a second wired WAN or to bridge into a hotel’s wired LAN where Wi-Fi is unreliable. I have had the Mudi 7 for roughly three months now, and the tl;dr is that the device is pretty solid overall, with a handful of caveats around firmware quirks and the chunkier footprint. Battery life is a bit of a mixed bag here, because it depends a lot on what features/services are running on the Mudi 7 , on the amount of WiFi clients and how cellular coverage is. Let me therefore put it this way: For the amount of features you get with the Mudi , especially compared to my older M2 , the battery life is decent. Having that said, however, I do believe that the Nighthawk , at least in its earlier days, was able to survive longer on a single charge than the Mudi is able to right now. Obviously I don’t have scientific benchmarks to prove it, but I remember vividly being out and about with the M2 for a full day and going to bed with the device only around halfway drained. This is something that I don’t think is possible with the GL.iNet . While the device easily gets through a regular workday, I probably wouldn’t trust it to survive a full day road trip with four friends through a mountainous region. Ultimately, its battery life can be extended using an external powerbank, but that’s clearly not ideal with a device that already weighs 300g on its own. If we’re being honest here, 300g equals about two Google Pixel 5 or two Motorola Edge 30 phones, which can both provide you with a 5G hotspot and which will probably (combined) outlast the Mudi by at least a few hours. So if the pure 5G hotspotting capability is all you care about, the GL.iNet is definitely not a good option with regard to battery life. If, however, you’re looking at it as the centerpiece of your mobile LAN, that will allow you to leave your Slate 7 at home because it supports pretty much every important feature and offers integrated 5G connectivity on top of that, then its battery life isn’t too bad after all. The chassis warms up noticeably under sustained 5G load (especially with a VPN), but never to the point where I’d be concerned about throttling or comfort. The back gets warm to the touch, but no warmer than a mid-range phone under similar load, and certainly not as warm as my old M2 would get at times. Unlike with the Netgear , I haven’t experienced any heat warnings with the Mudi so far. The build quality is solid. The chassis has a reassuring density to it, the touchscreen is responsive, and the front button doesn’t feel flimsy. The back panel is a bit of a weak point, because it is a plastic snap-fit cover protecting the battery and it creaks under pressure. Given that this cover has to be pried off to swap the battery or a SIM, I’m half-expecting it to wear out relatively quickly. Weight and footprint, as I had anticipated in the travel desk write-up , are clearly worse than the M2 ’s. The Mudi 7 is heavier (300g vs the M2 ’s 240g) and noticeably chunkier in both length and width. In absolute terms this is still a small device, but on a packed desk and in a packed bag, the difference is noticeable. The included travel pouch is also larger than the router needs, because most of the extra volume is set aside for accessories. Most people probably won’t use the travel pouch for travel, but rather for storage at home. Charging behavior has been predictable. The 24W PD fast-charging input gets the 5380 mAh battery from 0% to ~80% in roughly an hour, and to full in about an hour and 45 minutes. The device accepts whatever USB-C PD source there is around, including my UGREEN 100W and the Sharge Pouch Mini P2 power bank. If you’re considering this device as a permanent member (or even a centerpiece) of your LAN, I have some good news for you: The Mudi 7 can be operated via USB-C, without its battery plugged in. I don’t know whether this is officially supported by GL.iNet , because when you connect a charger the display will show a battery icon with an exclamation mark inside of it, but long-pressing the front button will turn the device on nevertheless. I haven’t experienced any peaks in power-consumption that would lead to arbitrary restarts without the battery plugged-in, but your mileage may vary. Reliability has been pretty good, and I haven’t experienced any crashes, random reboots, or other issues. The only firmware-level oddities I have encountered are the battery reporting discussed above and the cellular issue in firmware 4.8.5 mentioned in the tl;dr : After a carrier deactivates an idle data session, the router can remain on Connecting… until I intervene. The Mudi 7 is probably one of the most capable travel-friendly mobile routers I have ever owned, and it has a permanent place in my travel setup . The 5G modem, the dual-SIM-plus-eSIM configuration, the dual USB-C ports, the 2.5 GbE port, the removable 5380 mAh battery, and the Wi-Fi 7 PHY can replace the M2 + Slate 7 combo for me, while also covering scenarios (5G, multi-SIM, multi-WAN, USB-C-tethered secondary modems) that the combo never could. While the 300g weight and the bulkier footprint are a step back compared to the M2 , if I account for the added size and weight of the Slate 7 that I had to lug around alongside the M2 to make the LAN work for me, then it doesn’t look as bad anymore. Then again, with the M2 + Slate 7 combo I had the flexibility to only bring what’s really needed, which, for e.g. a day trip, would end up being only the M2 . Apart from that, there is the Tri-band situation, with the chipset only driving two bands at once and offering no MLO at all, the SIM-failover logic, which doesn’t work as smoothly as one would expect, the SIM 2 vs eSIM mutual-exclusion, that is mildly annoying, and the battery percentage smoothing, that makes me distrust everything else the device reports. However, none of these are deal-breakers but more like minor inconveniences. The proprietary Qualcomm blob situation is the more concerning part for me, and as with the Slate 7 , the Mudi 7 is OpenWrt only in spirit , and its long-term wireless and cellular stack support depends entirely on GL.iNet and Qualcomm continuing to cooperate. If your priority is true software freedom, this device, like virtually every other 5G-capable router on the market today, is not for you. Neither is it for you if you bought into the Mudi name for blue-merle and IMEI randomization. If your priority is a modern, travel-ready, multi-WAN, multi-SIM 5G router with a solid (if proprietary) firmware on top, the Mudi 7 is, at the time of writing, the best option I’m aware of. I will be sticking with the Mudi 7 as my mobile-data device for the foreseeable future, and the Nighthawk M2 has been retired to the bottom of a drawer after seven years of service. PS: Make sure to check future updates if you’re interested in the long-term experience with the Mudi 7 .

Electronics Hardware HTML TypeScript

マリウス 4 weeks ago

The TEMU-fication of Software, Digital Goods & Services

Disclaimer: This is an opinion piece and most of it is speculation about a future that has not arrived (yet?), based on a few data points that have. As usual, summary at the end. A few years ago I would have laughed at anyone telling me that there is a serious market for ten-dollar drills, two-dollar dresses, and one-dollar pairs of shoes shipped from a warehouse on the other side of the planet. Today, however, that market exists and it has a name, and it is even publicly traded (sort of, through holdings). TEMU , Shein and a few others have built frankly mind-boggling businesses around the idea that if you make production cheap enough, fast enough, and just barely good enough to look right on a phone screen, an enormous part of the population will buy it, even when the product breaks within a week, when the materials it is made of contain worrying levels of toxic substances , and when the carbon footprint of one delivery exceeds that of an equivalent local purchase by orders of magnitude. The key to this sort of business model is not innovation, but instead the externalization and compression of cost. Somewhere upstream, people work seventy-five hours a week , in conditions most readers of this website would refuse to even visit, so that the rest of us can have a cheap plastic spatula at our doorstep within five business days. While the visible price collapses, the invisible costs get distributed onto landfills, lungs, and ultimately people that we will never meet. What follows is a hypothesis I cannot prove but have been turning over in my head for a while, as we are watching the same thing happen to software, books, music, (film-)scripts, and most of the digital goods and services we consume. The cheap labor in this case is not human, it is a Large Language Model ( LLM ), or what many people these days call “AI” , and the externalized cost is, among other things, quality , which requires craftsmanship to produce, and attention to perceive. And just like with physical goods, we will probably end up with a two-tier market, in which we have a large and massively profitable lower tier of generated slop , and a smaller, more expensive upper tier of work that is still recognizably human. I’d like to call this the TEMU-fication of software, digital goods and services , and describe what it might look like. For decades, the global fashion industry has relied on a workforce that has almost no leverage and no voice, and for which the economics work because someone, somewhere far away, will sew a t-shirt for less than the price of a coffee. Without that skewed arrangement, the entire fast fashion business model collapses. The garment in your hand is only cheap to you because it has been expensive to someone else , in ways that the price tag does not show. Modern Large Language Models occupy a similar position in the economy, with one important difference, which is that there is no human being in the sweatshop, only a stack of GPUs trained on a corpus of work that other human beings produced over the course of decades. The labor that has been compressed is historical and the model is a kind of compressed copy of the work of millions of programmers, writers, illustrators, and musicians, served back at near-zero marginal cost. Well, at least in theory, and only if the hyperscalers find a way to lower the cost per token, but that’s a different topic. However, the result is the same. A class of goods can suddenly be produced for an order of magnitude less than before. And, just like with TEMU , those goods turn out to be just barely good enough . The most direct manifestation of this so far is what is being called vibe coding . The term refers to the practice of describing what you want in natural language to an LLM , accepting whatever it produces, iterating over it with more refined descriptions of the basic idea and eventually shipping the result into production. Whether the developer actually understands what was generated is increasingly considered an implementation detail . And while the output is technically software, the question is what kind of software it is. A 2025 Veracode report found that approximately 45% of AI-generated code samples failed security tests and contained critical vulnerabilities from the OWASP Top 10 , and a multi-language, multi-model academic study that evaluated outputs from Claude , Gemini , Codestral , GPT-4o and Llama-3 across Python, Java, C++ and C, found that a substantial fraction of generated snippets were either non-compliant with basic secure coding standards or actively triggered classified weaknesses (buffer overflows, hard-coded credentials, SQL injection, cryptographic misuse, path traversal, you name it). Even more concerning is a peer-reviewed 2025 paper from IEEE-ISTAS that documents a 37.6% increase in critical vulnerabilities after just five iterative prompts, suggesting that the more you let the model refine its own code, the worse the security posture gets. When these issues compound over time, the result is a higher total cost than traditional development. However, this doesn’t matter when you don’t think long term , but fast fashion instead. Also, none of this is to say that an experienced engineer cannot use these tools well, because they certainly can. The issue is what happens when the same tools are used by someone who does not know what good looks like in the first place, and there is nobody downstream of them who does either. The output passes the basic test of it runs and looks plausible , ships into production, and accumulates the kind of architectural and security debt that surfaces only when something goes very wrong . Note: There are credible voices in the industry, particularly from the AI tooling vendors themselves, who argue that AI-assisted development raises a floor more than it lowers a ceiling. In this view, the median piece of software has always been mediocre, written under deadline pressure by tired humans, copied from Stack Overflow without much thought, and held together by duct tape. If an LLM produces output of roughly comparable quality in a fraction of the time, the argument goes, nothing got worse. We are simply removing a bottleneck. I find this argument partially persuasive, and partially convenient for the people making it. It is true that a lot of software was already not great, but it is equally true that there is a difference between bad code written by a human who at least understood what they were doing , and bad code written by a system that does not understand anything . The first kind can be questioned and corrected, but the second kind tends to compound, because the person shipping it cannot answer why it does what it does. At least for now. Software is not the only place where this is playing out. The book industry is arguably further along, with estimates suggesting that somewhere between ten thousand and forty thousand AI-generated books are uploaded to Amazon ’s Kindle Direct Publishing platform every month, many without any disclosure that a model was involved. In June 2023, the Kindle Top 100 bestseller list was found to contain only 19 books written by humans . Amazon has since introduced limits and disclosure requirements , but enforcement is patchy and authors continue to push back against what looks like a slow flood. Categories that have been hit particularly hard include travel guides (generated guides to cities the author has never visited, with restaurant recommendations that don’t exist), nutrition and health (generated diet advice with citations to studies that don’t exist), and public-domain rewrites (generated adaptations of older books, relying on the recognizability of titles that the actual authors never agreed to). Travel guides in particular have produced a small genre of stories where readers arrive at addresses that turn out to be empty lots, or follow walking directions through neighborhoods that no human would ever recommend. Note: The defense, again, is that the bottom of the book market was always full of filler, that print-on-demand has been around for a long time, and ghost-written business books and assembly-line genre fiction predate generative AI by decades. However, the new thing is the scale at which low-effort content can now be produced, and the speed at which it can drown out the rest of the catalogue. Authors are competing for shelf space against entities that can ship a hundred new titles in a weekend. A 2025 analysis of 65,000 English-language articles published since January 2020 found that a little over half of all new articles on the internet are now AI-generated , and it’s not only the written word that’s being churned out by machines . YouTube has its own version of the problem, where, according to a Guardian analysis, nearly 10% of the world’s fastest-growing channels feature nothing but AI-generated content , and on Shorts specifically more than one in five videos served to a new user is low-quality AI-generated material . Not even the highly creative and (up until recently) human process of making music is immune to this TEMU-fication . Spotify has been removing ghost artist tracks for years, but the practice scaled up dramatically when generative tools made it trivial to produce convincing lo-fi background music in arbitrary volume. The platform has reportedly removed 75 million spammy tracks in a single year , and high-profile acts like the AI-generated band The Velvet Sundown amassed over a million streams before being unmasked. There has been at least one criminal case, involving over $8 million in fraudulent royalties , built entirely on AI-generated music and bot streams. However, that is no reason to applaud Spotify , as the company appears to fight the AI spam only when it’s someone else trying to make money off of it. However, there is a sliver of hope, as engagement with AI-generated articles reportedly dropped by around 40% in 2024, and human-generated content seemingly still gets roughly 5.4× more traffic than AI-generated material in some studies. About 38% of consumers openly express skepticism about AI-created content, and people do still seem to be voting with their attention. Whether that vote is powerful enough to shift incentives at the platform level is a different question, and personally I’m not particularly optimistic, especially given that the platforms profit either way. Let’s take Netflix as an example. From my understanding, the WGA ’s 2023 deal explicitly prevents studios from treating AI-generated material as source material, or from using AI to write or rewrite scripts, and Netflix was seemingly bound by that agreement until at least May 2026. Netflix ’s own Generative AI Production Guidelines also seem to reflect this, stating that AI is permitted in ideation , but that its use should not replace or materially impact work that would otherwise be done by union-represented writers, actors, or crew members, without proper approvals . While that sounds reassuring on the surface, it is, in my view, a delay and not a limit. The same company has publicly committed to going all-in on AI in its production pipeline , has signed deals with VFX automation providers that explicitly put a chunk of the global VFX workforce at risk, and has already used generative AI in at least one of its programs ( El Eternauta ). The trajectory seems to be “use AI everywhere it is contractually allowed right now, expand into the rest the second the contracts permit it, and spin the result as dEmOcRaTiZaTiOn Of CrEaTiViTy” . So here is my specific (and quite possibly wrong) prediction: Within the next five to ten years, Netflix will offer a basic subscription tier whose catalogue consists predominantly of AI-generated or AI-assisted content. We are talking generated procedural shows where each episode is remixed from a small set of templates, generated kids’ content that is vaguely educational and impossible to remember an hour after watching, and generated dramas that recycle plots from existing IP and vibe the rest. For this, the viewer pays the lowest monthly price, while the platform pays nearly nothing in production cost and keeps an enormous margin. The only “upside” for consumers will be the lack of ad breaks, as targeted advertising will quite possibly be injected in real-time into the show you’re watching, seamlessly blending into the storyline without you noticing it, but ultimately still triggering your ape brain to crave a refreshing soda or a sweet treat . Their premium tier, meanwhile, will become the human-made tier. Series with credited human writers, films with credited human directors, and performances by humans whose likeness has not been digitally replicated. The marketing will not call it human-made , because that would be admitting that the cheap tier isn’t , but the price difference will make it obvious. You will pay extra for the same thing Netflix has been selling you all along, except now it is positioned as a luxury. Clearly, I cannot prove that this is what will happen. Netflix ’s own guidelines, as written, prohibit it, and the WGA deal forced a delay. But once the contractual block has lifted, the financial logic is hard to argue with. A streaming service that can produce good enough content for fractional cost will eventually try to. And, mind you, Netflix is just one example. The same logic applies to every other content-distribution business with a subscription model and a margin. If you want to know what the human side of this two-tier world looks like, I think the best existing model is the handicrafts and handmade goods market . By 2025, that market was estimated at roughly USD 987 billion globally, with projections reaching over USD 1 trillion by 2035 . There is data suggesting that U.S. consumers already spend almost a fifth of their money on handmade goods rather than on mass-produced equivalents, and over half of handicraft buyers globally indicate a preference for products that are eco-certified or made from natural materials, going in the exact opposite direction of what TEMU has been doing. What this market shows is that industrialization does not erase the artisans, but pushes them into a different segment. People did not stop buying handmade chairs when factories started making chairs cheaply. While the masses opted for the cheaper, mass-produced items, a small but sustained minority of buyers continued to seek out the human-made version, and over time were willing to pay a premium for it. If the hypothesis holds, software engineering, writing, acting, illustration, composition and the other content-producing professions will undergo something similar. The bulk of the market will migrate to the cheap, mass-produced, generated tier, while a smaller market will continue to value, and to pay for, work that is verifiably the product of a thinking, breathing, opinionated human being. We are already seeing the first signs of this in agencies that explicitly advertise human-only content (at a premium), and in licensing companies flagging tracks as human-composed to distinguish them from AI library music. I think that the interesting question is not whether this segmentation will happen, but what proportion of the market ends up in each tier, and how robust the upper tier turns out to be. There is a darker version of this analogy. Roughly 57-60% of the daily caloric intake of the average adult in the United States and the United Kingdom now comes from ultra-processed foods . Across 22 European countries the share ranges from 14% to 44% , depending mostly on how protected the local food culture has remained. These foods are cheap, abundant, available everywhere, and nutritionally inferior to the alternatives in ways that have been studied at length . People know this, but they eat them anyway, often because the alternatives are slower, more expensive, harder to find, or require skills that have not been taught. I suspect that AI-generated content is on the same path. The cheap tier will not be a marginal phenomenon serving a marginal audience, but it will be the default , the cornerstone of how most people consume software, entertainment, news, and information, because it is what the platforms will serve them and what their monthly subscription covers. Some will care enough to seek out the alternative, but most will not, just as most people, knowing what they know about ultra-processed food, do not change their grocery habits. Probably the strongest counter-argument to all of this is that LLMs are still early, that the quality issues are transient, and that within a few model generations the gap between AI-generated and human-generated work will narrow to the point where the distinction stops mattering or might not even be possible anymore. If that is true, the two-tier picture collapses, because there is no longer a quality difference to justify the upper tier, only a marketing difference. The handmade analogy breaks because, unlike a hand-built chair, a generated novel is functionally identical to a written novel once you can no longer tell them apart. However, I am doubtful that this is going to be the case. There are tasks where I have watched the gap narrow faster than I expected, but there are also tasks where the gap has stayed stubbornly fixed and the failures have just gotten more sophisticated. My instinct is that for narrow, well-bounded technical work, the gap will close further. For long-form work that depends on a coherent worldview, lived experience, and, most importantly, emotions, I doubt it will, because the model has none of those. The second counter-argument is that the consumer backlash will be stronger than I am giving it credit for. The 40% drop in engagement with AI-generated articles is not nothing, and platform incentives may shift if users start to penalize AI-flooded feeds. Apple and others have started experimenting with content provenance and disclosure schemes that, if widely adopted, could stop the worst of the flooding. So it is possible that I am underestimating the immune response . The third counter-argument is, that the cheap tier might not be sustainable at all, because AI-generated content trained on AI-generated content degrades model quality , and the broader ecosystem ends up poisoning its own training data. If that turns out to be the dominant dynamic, the cheap tier could collapse before it becomes entrenched. I think all three of these arguments are valid and have a certain weight to them, but none of them are strong enough, in my view, to make me confident that the TEMU-fication will not happen. They might modulate how it happens, but they probably do not stop it. Initially, I went looking for an optimistic ending for this write-up, to say that software engineering is not going away , and writers are not going away , and actors are not going away . And while all of that is, I think, true, none of it should be confused with things will look the same . What I expect, and what I am to some degree already seeing, is that the people producing software, books, music, scripts, and other human-made work will not disappear , but they will get pushed into a narrower, more specialized, more “luxury” -coded part of the market, pretty much the same way hand-bound notebooks, independent record stores, and small bakeries that mill their own flour did. There will still be a livelihood in it, at times a very good one, but it will look vastly different, and there will probably be fewer people making a living in these fields. My assumption is that they will be more visible inside their niche, but less visible outside it, and they will make their case in part on the basis of provenance , where something was made by a human who knew what they were doing, and you can tell. Meanwhile, the bulk of what most people interact with will, I suspect, be generated. Some of it will be fine, and some of it will be ultra-processed , in the same sense that a frozen lasagna is ultra-processed. It will be functional, calorically adequate food , but it will not be what your Italian grandmother was making. People will nevertheless eat it because it is there, it is cheap, it is convenient, and because the alternatives have been priced out of their daily life. There is no “inevitability” to it, because none of this is really decided yet. There are still choices, made by platforms, by regulators, by consumers, and by the people doing the actual work, that will shape which tier ends up being how big and how durable. The handmade market exists because enough people kept buying handmade goods to make it viable. The human-made tier of software and digital goods will exist because enough people keep buying it, or it won’t exist at all. If you are someone who writes code, or stories, or music, or scripts, by hand, with intent, and with a point of view, I do not think the LLM is going to kill your job . I do think, however, that it is going to change the shape of the market you operate in, push you toward the upper tier (whether you wanted to be there or not) and ask you to make a more deliberate case for why your work is worth the difference in price. For the rest of us, the more interesting question is which tier we are choosing to consume from, and whether we are choosing it on purpose, or just because it was what the algorithm served us by default. I have my suspicions about the answer, but I would love to be wrong.

Java Programming AI Python C++

マリウス 1 months ago

A GTK4 ssh-askpass in Zig

I run hardened Gentoo on my laptop, and most of the time I never touch because I’m using keys for most of the systems. There is one class of situation where I do need it, though, which is when a program wants an SSH key passphrase for a regular ED25519 key, but has no terminal to read it from. The usual case is , or the toolchain in general, fetching a private module over SSH during a build that runs without a TTY. OpenSSH can’t prompt on a pipe, so it runs whatever points at and puts the passphrase prompt in a window instead. For years I had nothing installed for that and had to work around these scenarios. The main reason for that is what Gentoo ’s Portage offers: Each of these has at least one inconvenience I didn’t feel like putting up with. My system runs with the global USE flag, so anything that needs X11 is out before I look any further. Of the five, is the only one with no X11 dependency whatsoever, which should have made it the obvious pick, but the trouble is everything else that comes with it. As a Sway user , I did not want a full KDE stack on the machine just to type the occasional passphrase, and that is what a install pulls in: is next, and it needs outright. On top of that it pulls in a few KDE framework packages and a Qt built with support, which collides with the already on my system that was compiled , so Portage stops on a slot conflict: needs as well, this time by way of GTK2 and a Cairo built with support: is X11 by name, so no surprise there, and it also needs the old imake build system, namely and , to compile at all: That left . At first glance it looked like the one option that needed no at all, but that turned out to be wrong. It does need X11 , and the ebuild appears to be broken about it. The build calls and the source includes , an -only GDK header, so on a system compiled without it fails to build: This is where I gave up on the packaged options. Even setting the X11 question aside, every one of these uses GTK2 or GTK3 at most. However, it just so happened that I had wanted to build something with GTK4 for a long time, so instead of patching one of the existing implementations, which are mostly C anyway, I wrote my own with Zig 0.16 and GTK4 , and called it ssh-askpass-zigtk . The reason the GTK helpers break on my system is the headers. The standard way of calling GTK includes the GTK4 headers, which pull in GDK , and GDK still ships on most installs, so an X11 header comes in whether you want it or not. Zig ’s , the obvious way to call a C library, would do the same, because it pulls in exactly those headers. So doesn’t anything. declares the thirty-odd GTK and GLib functions the program calls by hand, as plain prototypes: Nothing in that file names a symbol from or , so the compiler never sees an header, and the binary builds and runs against a GTK4 that was compiled without X11 . The one -adjacent value it needs, the Escape keysym, is hardcoded as rather than pulled from . GTK is built on GObject , which does single inheritance by putting the parent struct as the first member of the child, so a window, a box, a label, a password entry and a button are all layout-compatible with a at the ABI boundary. On the Zig side one type stands in for all of them, and every widget function takes and returns the same , without a hierarchy of wrapper types to model something the C ABI already flattens. The parts that don’t touch GTK , the mapping of to a dialog type and the parsing of the variables, are in with unit tests, so they run under with no display and no GTK at all. Recoloring goes through a small CSS provider, since GTK4 removed and . Because the bindings are hand-written externs and no GTK headers enter the build, Zig can cross-compile the binary for any Linux architecture without a GTK4 toolchain for that target. The only thing missing at link time is the GTK4 shared library itself, and covers that, as it builds a tiny stub whose exported symbols are all no-ops, links the executable against that, and lets the target’s real GTK4 resolve at runtime instead. The release workflow uses this to produce binaries for , , , , , , and from one machine, none of which has GTK4 installed for the other seven. Note: doesn’t grab the keyboard as other askpass implementations normally would. The GTK3 helper calls so another client can’t read the passphrase as you type it, but from what I see, GTK4 dropped that interface and I believe that Wayland doesn’t let a client grab the keyboard at all, so there is no portable way to do it without X11 . Hence the and variables also have no effect. The code is on tty.fail and mirrored to GitHub , where each tagged release ships prebuilt Linux binaries per architecture. To use it, put the binary somewhere on your and point at it. For a terminal that means two lines in or your shell’s startup file (e.g. for my fellow Zsh users ): , from OpenSSH 8.4 onward, tells OpenSSH to use the dialog even when a terminal is available, as long as a graphical session is present. On a systemd user session, the same two variables go in as plain lines with an absolute path, since that file neither expands nor runs a shell. Log out and back in, and the next , pull or that needs a passphrase without a terminal gets the dialog.

Shell AI Mobile C CSS

マリウス 1 months ago

I Regret Migrating to Codeberg

My primary reason for leaving GitHub was not about a single feature or a single outage, but about the “enshittification” of the platform under Microsoft ’s ownership. The web interface got rewritten into a sluggish pile of JavaScript that either broke things which used to just work, or made them so horribly slow that using them became a PITA . Beyond the technical decay GitHub had turned into de facto “public infrastructure” in much the same way that WhatsApp has , hosting the source code of a very large share of the world’s software and, through that, giving Microsoft a degree of leverage and surveillance over everyone’s projects, and by extension everyone’s digital lives, that no single company should hold. On top of that, stories about legitimate developers losing their accounts due to arbitrary bans by Microsoft only reinforced the feeling that it would be a good idea to at least have a backup somewhere else . Codeberg looked like a viable alternative. It offered free and open-source projects a reputable home and, more importantly, an equally free one, run by a non-profit association rather than a subsidiary of the largest software vendor on the planet. Unfortunately, the latest update to its terms of service seems to mark a first step in changing one part I moved there for, namely the “freedom” part. Every project I’ve published so far was built with 100% human stupidity rather than “artificial intelligence” , or, more accurately, LLMs . I don’t hold particularly strong feelings about Codeberg banning projects that are predominantly LLM -driven, at least not feelings as strong as the ones I hold about the simultaneous ban of legitimate cryptocurrency projects, which reads as though it got lumped in for no reason other than that most people still remember the villain-du-jour that crypto was in the years before LLMs took that title. The two clauses landed within days of each other, the LLM prohibition on the 29th of June and the cryptocurrency prohibition on the 2nd of July, both as Assembly 2026 proposals, and the terms now file the latter under, of all things, “content that harms the reputation of Codeberg” , which sounds like legalese for “we don’t have a solid reason or an actual number of bad precedents to categorically ban it” . The announcement blog post , however, reads very poorly, and the section titled “The development team of none” is the worst of it. It states: Using LLMs to work with your code gives you a kick of adrenaline. You can develop at a rapid pace, build things as if you had a large team. Only that you have none. In fact, you are (often) alone, working with a statistical machine that turns energy into code. And, a little further down, it says: It seems like many ‘vibe coders’ don’t realize that they don’t actually have a community around them. This is out of touch with how most free software gets made. The majority of FOSS developers are one-man-shows, and the only cOmMuNiTy they have around them are the users requesting features or reporting bugs while most of the time not contributing in any form whatsoever. I’ve been publishing silly little tools for decades, predating this website and even GitHub itself (remember when SourceForge was the hot sh.t ?), and not one of them has ever had an actual “community” around it, at least not in the romanticized sense that Codeberg paints in that post. I’m a lone wolf who codes everything by hand and spends an absurd amount of time doing exactly that, and the notion that an LLM is the thing separating a real project with a real community from a fake one does not hold up once you look at how the average useful little tool on any forge comes to exist in the first place. It’s frankly a bit snotty of Codeberg to make this argument at all, considering that the platform effectively lives inside the Forgejo bubble, and Forgejo mutinied inherited its community of active contributors from Gitea , who had spent the better part of six years building that community before Forgejo even existed. A project that acquired its own community by hard-forking someone else’s, then turned around to lecture solo developers about not having one, is a difficult position to argue from with a straight face. In addition, Codeberg conflates “having a community” with “being legitimate software worth hosting” , when the bar for a personal project has always been a working build, ideally a license, and maybe a README, and not a channel full of contributors. A good deal of what makes the small, single-author tool ecosystem worth having is precisely that it doesn’t need a community to justify its existence, and a forge whose entire selling point is hosting the code of individuals is an odd place to argue the opposite. The part that bothers me isn’t the specific ban on LLM projects, or the specific ban on cryptocurrency projects. It’s that a hub built around “free software” is now telling its users which kinds of software are deemed good and which are not, and that is closer to censorship than it might seem. Once a platform writes into its terms that an entire category “harms its reputation” and can be removed on that basis, the deciding factor stops being whether the code is legal, or functional, or useful, and becomes whether it aligns with a position the platform has taken. I would argue that a significant share of the projects caught by a blanket ban of that kind are legitimate software rather than vibe-coded slop or sh.tcoin implementations. Every platform I can think of that took this approach became divisive the moment it started enforcing an ideology on its users, whatever that ideology happened to be, and however justified it looked at the time. The mechanism is always the same, where a real problem shows up, an unpopular category becomes the obvious culprit, the platform bans the category instead of addressing the problem, and that ban then becomes the precedent for the next category, and the one after that. The category that is uncontroversial to ban today is the reason the mechanism exists tomorrow, and the users who applauded the first ban rarely get asked about the second one. I do acknowledge that both categories aren’t free of problems. LLM -driven repositories do strain infrastructure, do generate unmanageable volumes of low-quality issues and pull requests, and do carry real questions about copyright and code provenance, all of which Codeberg names in its post. The cryptocurrency space, in turn, might have produced more outright scams than almost any other corner of software. However, a categoric ban on the villain-du-jour is not a solution to any of that. We now even have people like Linus Torvalds making the fairly reasonable argument that an LLM is just a tool , and “clearly a useful one” , with a legitimate place in Linux kernel development when it’s used carefully and its output is held to the same standard as everything else. If the maintainer of the largest and most consequential open-source project on the planet can treat LLMs as a tool to be judged on its results rather than a category to be banned on sight, a backyard code forge can manage the same. I, too, am worried about the impact of LLMs on tech, and on society in general, going forward, and I’d guess I’m about as worried as whoever wrote Codeberg ’s policy. I just don’t believe that banning content, which is very much what this amounts to, is the way forward. What I wish Codeberg had reached for is a solution that treats the actual problem, which by their own account in that same post is resource consumption and the infrastructure cost that comes with it, as an actual resource problem. A change to the terms of service could have required authors to tick a checkbox declaring that a repository contains LLM -generated code, or is cryptocurrency-related, and those repositories could then be segmented onto a separate tier of infrastructure that doesn’t get the same resources as everyone else. A tier that carries specific quotas, and that might require the author to pay for what they consume. Declaring the truth honestly would (at least at first) cost nothing, and failing to declare it, then getting caught, could be met with exactly the permanent, immediate ban that Codeberg is now applying to entire categories from the outset. Similarly, projects that carry the LLM or Crypto label could carry automatically displayed disclaimers that explicitly state that Codeberg is in no way responsible for the quality or correctness of this specific repository. Heck, they might even go as far as to blatantly state that Codeberg does not approve of the use of LLMs or Cryptocurrencies in those warnings, to make extra-extra-extra sure that people get it and that there is no “reputational risk” for Codeberg . An approach like this puts the cost of resource-hungry projects onto the people creating them, and it keeps the shared resources for the projects that were the reason the platform exists. All of that without Codeberg having to decide which categories of software are ideologically acceptable in the first place. The “we ban everything upfront that we don’t agree with” approach is the wrong signal to send, and it is a very slippery slope. Despite not owning a single project that falls into either banned category, I’m now going to look into setting up my own public Git host, and I’ll move off Codeberg only a few months after moving there , because of this. Not because of the bans themselves, but because I don’t want to depend on a platform that rewrites its terms of service on a whim, without properly announcing that the change was even under consideration, and without giving its users a way to weigh in. The decisions did go through Codeberg ’s own Assembly 2026 , which is more process than most platforms bother with, and yet as an ordinary user I found out about it the way probably most people else did, through a dark blue banner at the top of the site on the day it was already settled. While I appreciate the info about the ToS change, I wish I’d gotten a banner back when the platform was still deciding whether to go down this road, and I wish it had linked to a discussion thread, or at the very least a poll, so that I could have voiced the concern I have, which is about the freedom of the platform as a whole, rather than about any single category that ended up banned.

Open Source Business AI JavaScript

マリウス 1 months ago

More ...

Codeberg GitHub

Open Source Github

マリウス 1 months ago

Hyperuplink

Updates Website Codeberg GitHub

Web Development Open Source Github

マリウス 1 months ago

Bangkok, Thailand

Culture Travel Journalism

マリウス 1 months ago

Apple iPhone Air

tl;dr: I bought an Apple iPhone Air , not because I believe in Apple ’s self-congratulatory “privacy is a fundamental human right” marketing, but because after years of replacing Google Pixel hardware roughly every 18 months I have, again, reached the point where I need exactly one mobile device that will reliably run the closed-source financial, corporate and government apps that modern societies insist on. The Air is a fascinating piece of engineering, despite the new Liquid Glass in iOS being the UI equivalent of a bad car accident , and the device’s raw performance for things like mobile RAW photo development is, sadly, significantly ahead of anything Android offers in 2026. I still do not recommend using an iPhone as a primary device, because Apple remains a surveillance company. Long-time readers of this blog will know that I have spent the better part of the last decade trying to engineer my way out of the surveillance economy. I switched away from iOS and stock Android to GrapheneOS a long time ago, I run my own infrastructure , my own cloud , my own mail , my own Lastpass ( update ), my own Dropbox , my own search , my own Spotify , my own messenger , heck, even my own Zapier (sort of), and have generally tried to minimize the surface area that any single vendor has on me. The fact that I just spent a frankly absurd amount of money on a brand-new Apple phone should therefore probably come with an explanation, which is what this post is. It’s also a review of the iPhone Air itself, and a brief tour of how badly iOS has aged on a device that costs roughly the same as a decent used car in many parts of the world. Disclosure: I paid for the device with my own money. I have no relationship with Apple , and would honestly prefer not to give them my money in the first place. The opinions in this post are entirely my own. To understand why a GrapheneOS apologist would willingly buy a brand-new iPhone , it helps to know the road that led me here. The tl;dr is that for the past four years I have run a compartmentalized multi-phone setup , with one primary device on GrapheneOS that is as clean of corporate spyware as it gets, and one dedicated spyware phone that runs all the banking, travel, government identity, and other apps that I have to use to participate in modern society , but that I refuse to have anywhere near my actual life. The iPhone Air is the latest incarnation of that second device. Before the Air I kept an iPhone 11 Pro Max around for almost seven years. Of every smartphone I have ever owned across the past two decades, the only two devices that survived such long periods of time without a single hardware-level fault were the Motorola Razr V3i (yeah, I’m that old) and the iPhone 11 Pro Max . And with most of the banking, government, and corporate know-your-customer software that I am forced to interact with on a regular basis simply refusing to run on a de-Googled device, and, more importantly, being a gigantic PITA to recover onto any new phone if the current one should ever give up, it made sense to keep one rock solid device around that I could rely on. And because iOS is the best-supported target for specifically these apps, the iPhone is the only realistic alternative for someone who refuses to deal with Google Play Services . Running this kind of software on a separate physical device, that is kept in a Faraday bag when not in active use, is the cleanest way I have found to limit the blast radius of surveillance capitalism. In other words, the iPhone 11 Pro Max was not my phone , but more like my spyware appliance . The decision to specifically go with the iPhone (17) Air , as opposed to a more mainstream iPhone 17 or even a used predecessor, came down to two things: form factor, and longevity. I wanted a device that wouldn’t add a ton of weight to my travel setup , yet was still capable enough to survive (ideally) the next decade. I intentionally didn’t buy a used iPhone , because I’m planning for this device to hold up for a very long time, so I wanted Apple ’s initial one-year warranty, plus the reassurance that no previous owner had beaten up the battery, burned in the screen or let the device melt or freeze in their car for hours. For a spyware phone that occasionally rides along in a pocket as a backup, or that travels along in my carry-on, I do not want a brick. The iPhone 11 Pro Max that I am retiring weighed a frankly miserable 226 grams and the current iPhone 17 Pro Max is even heavier at 233g. The non- Max variant is only slightly lighter at 206g, and even the regular iPhone 17 , despite having a .2" smaller screen, is still 12g heavier than the Air . The iPhone Air , by contrast, is 5.64mm thin (excluding the camera plateau) and weighs only 165 grams, all while carrying a 6.5" OLED display. For comparison, the Google Pixel 6a , which for some time had been my spyware device and that the Air is also replacing, is a 6.1" device made predominantly of cheap plastic and glass, and weighs 178g. That’s 13g more than the larger and sturdier iPhone . The Air is, by far, the lightest 6.5" flagship I have ever held. While its footprint is significantly larger than I had expected from photos, and it is definitely not a one-handed device for people with small- to medium-sized hands, if you, like myself, are coming from a Pro Max , you will probably feel like you are holding a piece of cardboard, and I mean that in a positive sense. With most of the mobile phone industry having converged on the same slab-of-glass-with-a-camera-bump template, and the differentiators usually being marketing language rather than actual engineering, the iPhone Air is somewhat of an exception. The frame is Ti-6Al-4V , which is supposedly made with 80% recycled titanium . And while Apple has used titanium on Pro -line iPhones since, I believe, the 15 Pro , the Air clearly pushes the thickness budget to a different level. The closest competitor in the realm of well-established premium smartphones, which I believe is the Samsung Galaxy S25 Edge , is slightly thicker and is shown in many reviews to have build-quality compromises. Because the Air is too thin to fit a conventional stamped USB-C connector, Apple ’s engineers 3D-printed the metal connector frame out of titanium powder, fused with a laser, and machined to spec. As reported by Engadget , Apple ’s justification is that at this thickness, there is no other way to fit a standard-compliant USB-C connector. I am skeptical of the claim that this was the only option (a redesigned stamped part would presumably also work), but the fact that they shipped a 3D-printed titanium structural component in a consumer phone is an interesting engineering choice. Another interesting engineering choice is the camera plateau . Rather than the widespread camera trypophobia bumps , the Air has a raised horizontal rail at the top of the back, under which sit the A19 Pro SoC , the new C1X modem, the networking silicon, and the single 48MP Fusion camera. This concentration of components in a thicker strip is what makes the rest of the chassis flat. From a thermal perspective it makes total sense, as it concentrates the device’s heat generation in a region that is the easiest to keep away from the user’s hand. This is one thing that always bugged me about the 11 Pro Max , which is that the moment the device is under load (which is pretty much all the time when running a recent iOS version) the backside area, where your fingers naturally rest when holding the phone, will get uncomfortably hot. On the Air you need to actively move your fingers underneath the plateau to feel the heat. However, because the Air does not have the vapor chamber that the Pro line introduced this generation, it throttles more aggressively under sustained load than the 17 Pro . For my use case (banking apps, occasional photo editing, very occasional video) this is irrelevant, but for someone trying to play a demanding game for two hours straight, it probably isn’t. Speaking of heat, the Air packs quite a lot of it with its 6-core CPU with 5-core GPU and the Neural Accelerators , which in benchmarks scores 9,497 points in Geekbench 6 multi-core. For comparison, the Pixel 10 Pro ’s Tensor G5 , in the same benchmark, sits at roughly two thirds of that number . The C1X modem, which is Apple ’s second-generation in-house cellular modem, is also an interesting piece of engineering. It has replaced the Qualcomm silicon that has been in every iPhone since the 12 and in real-world testing the C1X appears to be noticeably more power-efficient than both the Qualcomm modem in the 16 Pro and the Samsung Exynos 5300 modem that has been making the Pixel family miserable for the past several generations. For a device whose battery is a comparatively modest 3,149 mAh , that efficiency gain is what makes the Air ’s battery life usable at all. One big difference from literally every phone that I have ever owned is the fact that the Air has no physical SIM tray. If I were planning to use this phone as my primary phone, this would be a huge PITA for travel . Pre-paid SIMs in many countries are usually not available as eSIM, or when they are, they’re significantly more expensive and privacy-invasive due to KYC measures. I have written before about why I strongly prefer physical SIMs for both privacy and practical-travel reasons, and Apple ’s decision here is a real downside for any full-time traveller . The reason for the lack of a physical SIM tray appears to be that Apple needed the volume for the already small enough battery, which makes sense. It is nevertheless a regression. Another engineering decision that somewhat made me question the whole thing is the USB port. In 2026 the world’s most valuable company decided that, on a flagship-priced device, you still only get USB 2.0 transfer speeds out of the USB-C port. For whatever reason, Apple reserves USB 3 speeds for the Pro line. This means that transferring 50MB RAW files off an SD card via a USB-C card reader is not exactly slow , but it is also not fast , and it is straightforwardly insulting on a device as expensive as the iPhone Air . Plus, the whole USB design choice also leads to absurd incompatibility issues with plenty of built-in USB controllers within SSDs, making a good number of external drives simply unusable with the Air . One big letdown at this price point for many people seems to be the single 48MP rear camera. Coming from an iPhone 11 Pro Max , or even the cheaper Pixel 6a , both of which had multi-camera arrays, I understand that the average user might perceive this as a step down for photography. However, personally, I don’t care too much as I take essentially all of my photos on dedicated cameras anyway. GSMArena ’s review calls the single rear camera the device’s “big pain point” , and I think that is fair at this price. Taken together, the Air is probably the most opinionated phone Apple has shipped in a long time. The company was willing to sacrifice camera count, port performance, and thermal headroom to deliver a piece of hardware that is as thin and light as it is, and that is built around in-house silicon. Whether this approach turns out to be a good idea, history will tell. As a piece of standalone consumer electronics, however, it is pretty impressive, and I say that as someone who, in almost every other domain , finds modern consumer hardware profoundly depressing . And then there is the software. iOS 26 ships with Liquid Glass , Apple ’s new design language, which applies a translucent, light-refracting, glass-like aesthetic to basically every system surface, from the lock screen to the notifications, Control Center, app icons, menus, and even system alerts. Apple ’s clearly high af marketing department describes it as “a new material that combines the optical qualities of glass with a fluid, responsive feel that brings depth and dynamism to every interaction” … whatever that is supposed to mean. What it actually feels like, in daily use, is sadly less flowery , and the user backlash and performance issues have been covered extensively . The kindest thing I can say about Liquid Glass is that, despite it being the Ferrari Luce of UIs , the engineering underneath it is impressive. The amount of real-time blur, refraction, and material simulation Apple is pulling off on the A19 Pro at 120Hz is a graphics feat that the Android system can only dream about. Having said that, however, I don’t think that any of that engineering would be truly necessary if somebody at Apple had asked the question “does this design language actually make the device easier to use?” before shipping it on a billion devices. The primary purpose of the Air for me, as with its predecessors, is to host all of the closed-source corporate spyware that I refuse to put on my primary GrapheneOS device . This includes: On the Air , all of this just works . Apps launch instantly, attestation succeeds, and the device does not get anywhere near as hot as the average Pixel phone doing any of it. After four years of fighting with Google ’s hardware and Android ’s gradual decay, I am, embarrassingly, enjoying the boring reliability of iOS . The thing I did not expect, and the thing that has surprised me about the Air , is how good it is at mobile RAW photo development. For a long time I had been doing all of my photography workflow on a Pixel Tablet running GrapheneOS , using Lightroom Mobile . The arrangement worked, but it didn’t work well. Lightroom Mobile on the Tensor G2 -powered Pixel Tablet has increasingly become a sluggish, crash-prone mess , with editing operations that take noticeable seconds to render preview updates, occasional import failures, and a battery life under heavy editing that is less than three hours. On the iPhone Air , the same workflow (using a USB-C SD card reader, plus the free Snapseed app) is vastly faster. Importing a card full of 50MB RAW files from my Fuji is bottlenecked by the USB 2.0 port rather than the phone. Edit operations on RAW files are essentially instantaneous, even with multiple layered adjustments. Exporting to JPEG happens in well under two seconds per image. Obviously the Air ’s A19 Pro SoC was released several years after the Tensor G2 , and it is orders of magnitude faster on graphics workloads, but the Pixel Tablet is nevertheless a 2023 product that Google is still selling new in 2026. The fact that an in-pocket, 5.6mm-thin iPhone runs circles around it on the same workload is, frankly, embarrassing for Google . The mobile content-creation software ecosystem on iOS is also significantly better than what is available on Android , and not just because the hardware is faster. Lightroom Mobile on iOS is more polished than the Android version, and even Snapseed , an app by Google , runs noticeably more smoothly on iOS than it does on Android . Even free, ad-supported photo apps tend to be visibly better on iOS than anything on Android . Some of this is because developers prioritize iOS for revenue reasons, because literally every little sh.t app on iOS these days can seemingly charge a price or, worse, a subscription fee. However, some of it is also because Metal and Core Image are better-integrated graphics and imaging stacks than what Android exposes to third-party developers. Whatever the reason, in the specific category of mobile RAW photo development, iOS is not just ahead, but it is literally pulling Android ’s pants down and slapping its Baklava . Even setting RAW editing aside, the device feels noticeably snappier than any Android phone I have used, including the Pixel 8 . App launches are faster, animations are smoother, and background apps stay in memory longer. Apple ’s memory management on iOS , even with comparatively modest RAM (the Air has 12GB), is more aggressive about keeping apps warm than Android ’s. Tom’s Guide ’s real-world performance testing shows iPhones consistently lapping Android flagships on workloads like video transcoding, where the iPhone 17 Pro models complete a standard test in 22 seconds, while every Samsung Galaxy S25 variant takes over twice as long. On purely synthetic Geekbench 6 multi-core, the Snapdragon 8 Elite Gen 5 does outperform the A19 Pro , but the Snapdragon ’s lead in synthetic CPU benchmarks does not translate consistently into real-world responsiveness, because Android as an operating system still carries a significant amount of overhead that even the fastest silicon cannot entirely paper over. On the iOS side, the A19 Pro ’s single-core performance (around 3,871 points in Geekbench 6 ) is still the highest of any shipping mobile SoC. A heuristic that I have used for years, and that has consistently held up, is that an iPhone from year N tends to feel as snappy in everyday use as an Android flagship from year N+1 or N+2 , and I’m certain that the iPhone Air is no exception to that rule. This is a generic OS observation rather than a comment on the Air specifically, but it is a real observation, and it is one of the reasons why iOS devices keep getting recommended even by people who would much rather be using something else. Besides the superior hardware of Apple ’s phones over specifically the Google Pixel devices, the ecosystem of accessories that are intentionally designed to fit the iPhone lineup is another thing that Google , as well as most other Android manufacturers (with the exception of Samsung and Xiaomi ), has failed to establish. In recent years, Apple managed to further increase their ecosystem’s lead with their MagSafe quick-attach feature, for which you can find literally everything, from snap-on card holders through powerbanks all the way to actual stands. Because I was curious to give the MagSafe system a try, I decided to pick up a powerbank that unintentionally fits the “Space Black” iPhone Air better than Apple ’s own, plain white iPhone Air MagSafe Battery . I chose the Xiaomi UltraThin Magnetic Power Bank 5000 not only because its design was clearly targeted at iPhone Air users, but also because it is the thinnest (6mm) and lightest (98g) 5000 mAh power bank on the market, thanks to its relatively new high-energy-density silicon-carbon battery. When attached to the back of the Air it brings up the device’s weight to 263g in total, which is noticeably heavier than most other smartphones, but it also almost doubles the phone’s battery life. While the Xiaomi power bank can deliver 22.5W, it only does so via USB-C, and because it is not MagSafe -certified, it drops to 7.5W when charging the phone wirelessly (by snapping it on using MagSafe ), rather than the 15W that Qi2 phones get out of it. With the Air locked and inactive it takes about two to three hours to charge it to around 92%. It never reaches 100%, despite the power bank carrying considerably more capacity than the phone’s integrated battery, due to the inefficiency of wireless charging . Note: I’m aware that Google introduced MagSafe compatibility into its Pixel line with the Google Pixel 10 , however, there is no dedicated ecosystem targeting specifically the Pixel and its hardware design . For the narrow use case that I have personally been struggling to solve, which is “I need a single, lightweight, and highly reliable device to host all the closed-source corporate spyware I am forced to interact with, and I already have a primary GrapheneOS device for my actual life” , the iPhone Air seems like a very good option, at least ignoring the absurd price tag. It is light enough to carry in a Faraday bag inside my cabin luggage with me and it’s flat enough to occasionally bring it alongside a Pixel without making my pockets look like I pack big data. It appears to be reliable enough that I do not expect to repeat this exercise for at least another five to seven years, and it runs every attestation-dependent banking, travel, and near-future dystopian government app I might need it to run. On top of that, the mobile content-creation software story on iOS is, sadly, lightyears ahead of Android , as well as Windows and Linux . For anybody whose use case is “I want this device to be the primary, always-with-me phone that handles my nudes photography, my manifestos notes, my 4chaning web-browsing, and my doomscrolling actual life” , I cannot in good conscience recommend the Air , or any other iPhone , for exactly the same reasons I have been writing about for the past years . Apple is, with all due respect to its marketing department, a surveillance company . The fact that it chooses to surveil its users somewhat more politely than Google does is not, by itself, a reason to grant it custody of your private life. You cannot audit the OS, you cannot disable any hidden surveillance subsystem, and you most certainly cannot install a hardened replacement. The iPhone Air is a fascinating piece of engineering and a perfectly competent spyware appliance . It is however not, and will never be, my primary phone. Banking apps for several jurisdictions, most of which now require Google Play Integrity or equivalent attestation on Android and basically refuse to function on GrapheneOS without disabling the very protections that make GrapheneOS worth running in the first place. Apple Wallet for boarding passes and, in some jurisdictions, virtual VISA and MasterCards. Luckily I’m neither a citizen nor a resident of a country that imposes the absurdity of digital state-issued identifiers . Corporate apps that some clients might use and require, as well as privacy-invasive bs like WhatsApp , using throwaway phone numbers, in jurisdictions in which large parts of public life run on it . Travel apps (airlines, hotels, rental cars), most of which are technically available on GrapheneOS but which are also ill-behaved, ad-laden, and absolutely should not be on the same device as my personal data.

Mobile Security iOS

マリウス 1 months ago

The Day WhatsApp Goes Dark

Note: As usual, tl;dr at the end. Tomorrow morning, WhatsApp goes dark, and it’s not just a short downtime, but it is a termination of the service. The servers turn off, the domains don’t resolve anymore and no mobile client is able to connect. Have you ever asked yourself what would happen in that case? What if WhatsApp actually went dark? Obviously, nobody really knows what would happen in such a case, because we haven’t experienced that situation (yet), but even though the closest analogues like the six-hour Meta outage in October 2021, and Brazil’s 12-hour court-ordered shutdown in December 2015 were measured in hours, not days, those already produced effects that journalists described as “apocalyptic” . We can try to extrapolate what happened throughout events like those to see what “global catastrophe scenario” could theoretically look like. Because whether you believe it or not, WhatsApp is more than just a messenger , and one example that makes this pretty obvious came from the Forbes editor José Caparroso , who wrote during the 2021 blackout that … Latin America lives on WhatsApp . I am surprised by so many people underestimating how catastrophic this downfall has been. But before we dive into this thought experiment, however, it’s worth establishing what we’re actually talking about, as readers in most of Europe and North America underestimate WhatsApp by an order of magnitude, primarily because in those markets it functions as one platforms among many. That is, however, not how the rest of the planet works. Note: This thought experiment is not only based on some abstract numbers and studies, but upon my own experience of how WhatsApp is being used in e.g. the global south on a day to day basis. During my travels I think I’ve pretty much “seen it all” , with for example broadband technicians taking photos of the stickers on the backside of WiFi routers/modems, that show the hardware address and login credentials (on their phones), and sending them via WhatsApp to themselves, only so they can open them on WhatsApp Web (on their work laptops), in order to upload them into the ISP’s technical service portal. It is frankly mind-boggling what sort of tasks WhatsApp has become a Swiss army knife for in those countries, whether it’s as a file transfer platform for sensitive documents, or as a full-blown hotline for critical services and infrastructure. Let’s start by understanding the sheer scale of WhatsApp . The Meta owned and operated messenger has roughly 3.3 billion monthly active users as of early 2026, which is about 40% of every human alive, and somewhere north of 60% of every human with a smartphone. The platform processes more than 100 billion messages per day , out of which around 7 billion are voice messages. On top of that, users place around 5.5 billion voice calls and 2.4 billion video calls per month , which boils down to more than 2 billion minutes of voice and video traffic every 24 hours. To put this in perspective, the global SMS network, at its peak in 2012, handled about 23 billion messages per day across every carrier on Earth. WhatsApp does four to five times that volume on its own, every day, on a service that is (at least at the consumer layer) “free” . However, if we look deeper into the country-level breakdown, it becomes clear that WhatsApp usage isn’t evenly distributed across the globe. India has between 535 million and 596 million monthly active users , and regardless of whether we pick the higher number or we stick with the more conservative estimate, it is the largest single national user base on any messaging platform anywhere. Brazil has about 148 million users, and the app is installed on roughly 99% of the country’s smartphones. And 93% of those users open the app daily . Indonesia has about 112 million users, with WhatsApp being the leading messaging platform in the country, and in Zimbabwe WhatsApp alone accounts for roughly 44–50% of all mobile internet traffic . In Lebanon more than four in five adults use it , making it the dominant communications channel during multiple national crises. In a great many countries, WhatsApp is not simply a service on the internet, it actually is the internet for most practical purposes. WhatsApp Business now has more than 200 million businesses on the platform globally , with around 50 million small and medium-sized enterprises using it as their primary customer channel. In India and Brazil, roughly 80% of small businesses use WhatsApp to communicate with customers. In Brazil specifically, 96% of businesses rate WhatsApp as their primary communication tool, and a joint study by Fundação Getulio Vargas and Sebrae , Brazil’s main small-business support organisation, found that 70% of Brazilian small companies rely on the Meta -owned trinity ( WhatsApp , Instagram , Messenger ) as their marketplace. Globally, around $45 billion in commerce is expected to flow through WhatsApp in 2026 . Click-to-WhatsApp advertisements alone generate roughly $10 billion per year for Meta . About 175 million customers send messages to WhatsApp Business accounts every single day. And then there’s payments. In India, WhatsApp Pay is a small player in the UPI with about 67 million transactions per month against UPI’s 18 billion monthly volume, but in absolute terms, that’s still an enormous number of transactions. In Brazil, WhatsApp Pay is integrated with local card and bank rails and is used by transit operators ( Vai de Bus , for instance, sells passes via WhatsApp ), banks, and merchants. Across Africa, fintech overlays on WhatsApp , like Finnova in Nigeria, or Azza in Nigeria, Kenya, and South Africa, are processing crypto and conventional payments at significant volumes. Besides being a chat platform, a marketplace and a payment processor, WhatsApp is also being used as critical clinical infrastructure across the global south. A three-year programme at UCLA’s David Geffen School of Medicine paired subspecialists in Los Angeles with clinicians at Partners in Hope Medical Center in Lilongwe, Malawi, via WhatsApp groups. 89% of submitting clinicians and 71% of expert respondents reported that the case discussions improved medical education and patient outcomes. In the Eastern Cape of South Africa , WhatsApp groups serve as the primary continuing-medical-education channel for HIV and TB management in rural clinics where specialists are days away. In Haiti, WhatsApp groups coordinate emergency department operations at Hôpital Universitaire de Mirebalais , including mass-casualty alerts, security updates, and clinical decisions. In Zambia, IntraHealth International runs nurse and midwife mentoring networks over WhatsApp . In Brazil, the link between Zika virus infection and microcephaly was tracked partly through WhatsApp groups of paediatricians comparing cases. Another critical field that runs on Meta ’s infrastructure is disaster response. The World Bank documented that during 2014’s Cyclone Hudhud in Andhra Pradesh, India , the Public Works Department restored connectivity to a 1.8-million-person city primarily by coordinating engineers through a closed WhatsApp group with the District Magistrate in it, without any formal meetings and orders, which ultimately led to most roads becoming functional within three to four days. During the 2023 Turkey earthquakes, volunteer-formed WhatsApp networks processed 5,800+ messages in one week for needs assessment and rescue, and in Syria, the White Helmets have run an emergency dispatch system over WhatsApp since 2021, because the country’s emergency number infrastructure is largely destroyed and WhatsApp ’s compression algorithms work where almost nothing else does. It’s not just individual organisations, but even whole governments are dependent on Meta . Buenos Aires for example ran a COVID-symptom triage chatbot on WhatsApp , and Lebanon’s public health ministry launched an automated WhatsApp service in April 2020 to disseminate updates on the pandemic. India, on the other hand, offers metro tickets, government services, and bill payments through WhatsApp chat interfaces . On top of that, for example, the Philippines’ UAE consulate operates consular emergency hotlines on, you guessed it, WhatsApp . Last but not least, there’s migration. Roughly a quarter-billion people live outside their country of birth. Most of them use WhatsApp as their primary connection to family, because international SMS is expensive and unreliable and Skype is, well, dead. Multiple peer-reviewed studies on Trinidadian , Pakistani, Ghanaian , Polish, and Kenyan diasporas also converge on the same finding of WhatsApp being the primary technology of transnational family life in 2026. So to go back to our initial thought, let’s imagine WhatsApp shutting down in an instant, with this dependency graph in mind. What follows is a hypothetical scenario sketched from the documented impacts of past (shorter) outages, scaled up by the duration and finality of the event, and informed by the dependency layers described above. It’s a scenario and not an actual prediction. The shutdown hits during European afternoon, which means American morning, Indian evening, East African afternoon, and Indonesian late evening. The first signals show up on Downdetector and on non- Meta competitors. In 2021, the six-hour outage generated 14 million reports inside the first few hours, but this time the number is likely much larger. Behaviour inside the first hour is uneven and largely confused. In most places, users assume it’s a routing problem, a local carrier issue, or a phone bug. They restart the app, then their phone, then their router, then they check Twitter X , Instagram , TikTok , Telegram , maybe Signal , or Facebook Messenger , depending on what they have installed. Telegram and Signal both see app-store download spikes within the first 30 minutes, as it happened during the 2021 outage, with Signal reportedly adding “millions” of users that day . The first noticeable failures show up in commerce. A food-truck operator in São Paulo who takes orders via WhatsApp can no longer receive them. A small clothing brand in Mumbai whose entire sales pipeline runs through Click-to-WhatsApp advertisements sees its ad spend continuing to bill while the conversation endpoint returns errors. In Hong Kong, a logistics coordinator who confirms container pickups via WhatsApp loses the day’s confirmation chain. In Idlib, Syria, the White Helmets dispatch room realises within minutes that emergency calls are not coming in, and civilians have no fallback channel. It is likely that three things start happening in parallel. First, mass migration to apps like Telegram , Signal , and to a lesser extent Messages ( iMessage ), Viber , and Line . Signal ’s servers, which are run on a fraction of WhatsApp ’s infrastructure, are not designed for an inrush of hundreds of millions of new accounts and start to degrade in some regions. Telegram , which has spent a decade preparing for exactly this scenario, holds up better but still struggles with its own issues. Ultimately none of the alternatives are suitable for the people who had built their workflows on WhatsApp . The second thing that happens is commercial collapse , which is the biggest 12-hour story, but still largely invisible from Western media. In Brazil, Indonesia, Nigeria, India, Pakistan, Bangladesh, Vietnam, Mexico, and probably 50 other countries, the small businesses that route everything from orders and prices, and photos of goods, to delivery confirmations, and payments, through WhatsApp have lost their primary revenue channel. A clothing brand in Ireland reportedly lost thousands of euros in a single afternoon during the 2021 six-hour outage. Multiply this by twelve hours and by the entire tail of informal commerce that lives on the platform and the figure runs into the billions. The third thing is health-system stress . Group consults that normally take an hour over WhatsApp become almost impossible. The Eastern Cape HIV-management network in South Africa, the Malawi-UCLA clinical link, the Haitian ED coordination groups, the Zambian rural-nurse mentoring channels, all degrade simultaneously, and while mortality consequences are not yet visible, they are happening nonetheless. In several countries, government officials begin issuing statements through whatever channel is still functioning. After the first 24 hours it becomes clear that the impact this situation has is roughly inversely proportional to a country’s investment in alternative digital infrastructure. The United States and Western Europe are mildly inconvenienced, and India is moderately disrupted, mainly because the country has built duplicate rails, hence UPI runs over many apps. After all, SMS still works, alternative payment apps exist, and government services have their own portals. However, countries like Brazil, Argentina, Mexico, and most of sub-Saharan Africa, on the other hand, are in serious trouble. In Brazil, by the end of day one, the financial press is comparing the situation to a partial shutdown of the national payments system. Pix transfers still work, as those run over the central bank’s infrastructure and not WhatsApp ’s, but the merchant-customer communication layer that drives Pix transactions for millions of small operators is offline. The same is true in Argentina, where the inflation-driven culture of constant price renegotiation between vendors and customers happens, in practice, almost entirely on WhatsApp . Another area that starts to fail is migrant remittance. People working in the Gulf, North America, or Europe typically coordinate transfers with their families via WhatsApp , where they confirm the recipient’s details, send screenshots of receipts, or sometimes route the money through informal Hawala -style networks where trust is established and maintained by daily messaging. These workflows don’t fail completely on day one, but they slow and break in ways that don’t show up in formal remittance statistics for another week or two. In Latin America, the first major political consequence appears in the form of misinformation that previously circulated within closed WhatsApp groups , which now has nowhere to go and starts spilling onto other platforms. By the end of day one, more than 100 million people have created Signal or Telegram accounts. Both apps experience their first significant performance degradation events. The labour-market consequences start showing up. In India, where WhatsApp is the de facto recruiting and onboarding tool for huge segments of the informal economy, gig workers can’t be reached for shifts. Delivery platforms like Swiggy , Zomato , Dunzo , and their international equivalents, see their dispatch coordination degrade. Some of these companies have parallel in-app messaging, but many have leaned hard on WhatsApp because it was cheaper. Schools also begin to feel it, because in many countries, including India, Brazil, South Africa, Kenya, Nigeria, the Philippines, Indonesia, and much of the Middle East, parent-teacher communication runs over WhatsApp groups. Two days in, schools that have not made the switch to other channels are operating partially blind, and parents are not getting closure notifications, transport updates, fee reminders, or exam schedule changes. In countries with weak alternative communication infrastructure, the second-order effect is mid-week absenteeism as parents simply don’t know whether school is open. On top of it all, Healthcare is also heavily impacted. For example, the Haiti emergency-department-style coordination groups have now had 48 hours to find alternatives, and they have, mostly, but the transition has costs. Case discussions that were asynchronous and 24/7 on WhatsApp are now synchronous and harder to schedule, and rural clinicians in places like the Eastern Cape, Lilongwe, or the highlands of Nepal are once again practising in the relative isolation that WhatsApp ’s group-call and group-message features had alleviated. In several documented studies, isolation correlates with diagnostic delays and worse patient outcomes. In Syria, the White Helmets switch to a patchwork of Signal , SMS where it works, and physical runners, and response times degrade significantly. At this point things start to get political. In a number of countries, including Brazil, India, Indonesia, Nigeria, the Philippines, and South Africa, the question stops being “what is Meta doing” and starts being “why did we let one foreign company become this central” . Telecom operators in several countries pitch the moment as an opportunity to push their own messaging products, most of which have been moribund since 2014, but the pitches fail because nobody trusts the carriers, because those carriers have been quietly delighted to see WhatsApp gone, given that it eroded their SMS and voice revenue for a decade. In a few markets, regulators float emergency-decree-style proposals to nationalise messaging infrastructure or build sovereign alternatives. And while most of these proposals are clearly performative, some are not. India and Brazil both have working national digital identity and payments stacks that could, in principle, host a public messaging layer. It remains to be seen, though, whether the political will to build one persists past the first month. Public health authorities in Lebanon, Buenos Aires, the Philippines, and several African countries are now running emergency communication operations across multiple fallback channels. None of them work as well as WhatsApp did and things like vaccination schedules are missed, and appointment reminders fail. Some clinics see patient no-show rates rise by 30–40% versus baseline. Not because WhatsApp is superior to its competitors, but simply because humans need a long time to adjust to the alternatives that are being put in place. Also, crime patterns shift in interesting ways. A Conflict Sensitivity Resource Facility report on South Sudan, and PeaceRep work on Somalia, both documented that WhatsApp groups were used for both peace-building and for coordinating violence. Removing the platform doesn’t remove either function, as both migrate to other channels, but the migration takes time, and during the transition, coordination of all kinds becomes harder. In several markets, online ad spend collapses because Click-to-WhatsApp ads (a $10B/year business) have no destination, and Meta ’s stock price has already done what you’d expect it to do. The migration to alternatives, mostly Telegram and Signal , with regional pockets going to Line , KakaoTalk , WeChat , Messages ( iMessage ), RCS , and a long tail of smaller apps, has now hit critical mass in most of the world. The migration has not been clean, and group chats with over 200 members have, in practice, often migrated as group chats with around 40 members, because not everyone moved at the same time or to the same app. For business communication, the new world is as fragmented as it gets. A Brazilian shopkeeper who used to take all orders on WhatsApp now has to manage Telegram , Signal , Instagram DMs (still up, but reduced after Meta ’s reputational damage), and SMS. Customer-acquisition costs rise, and customer-retention drops, and several reporters publish stories on small businesses that have permanently closed. For healthcare, the migration is more orderly because the user base is smaller and more motivated. Most major peer-support networks, like the Malawi-UCLA , the Eastern Cape HIV , the Zambia nursing , and the Haiti emergency have stable new homes. The five-day disruption produced measurable degradation, and it is not yet possible to quantify the mortality and morbidity impact. In Syria, the White Helmets have built a partial replacement on Signal and on a custom dispatching tool that their engineers had been prototyping. It works less well than what they had, because the compression behaviour that made WhatsApp viable in low-bandwidth, intermittently-connected environments is hard to replicate. Hence, some dispatches are now arriving via paper notes. Not because decentralized mesh networks don’t exist, but simply because nobody in these organizations has the expertise to implement these alternatives, especially within such a short period of time. The first credible economic estimates of the shutdown’s cost reach the tens of billions of dollars and continue to rise. The estimates are dominated by long-tail effects in emerging markets that are hard to measure precisely. A week in, the question has shifted from “When does WhatsApp come back?” to “What does the world look like without it?” and a growing fraction of the user base assumes it isn’t coming back, so behaviour begins adapting accordingly. Several governments, including Brazil, India, and the EU as a bloc, have announced formal investigations or task forces into how to prevent this from happening again. As usual, however, none of them will produce anything actionable within years. The longer-term effects, that you can already see the shape of by day seven are a measurable productivity hit in emerging markets, particularly for informal-sector businesses, a consumer trust impact across the entire Meta product family, a wave of WhatsApp-replacement startups, most of which will fail due to network effects and generally bad engineering, and the painful realisation that a free product is not the same thing as a public good. Some estimates from prior outage studies suggest that a six-hour WhatsApp outage cost the global economy hundreds of millions of dollars per hour in lost SME activity, weighted heavily toward Latin America, South Asia, and Africa. Extrapolated over seven days and weighted for cascading effects, the seven-day damage is in the tens of billions, possibly higher. This thought experiment is not about Meta eventually shutting down WhatsApp , as it almost certainly won’t do so on its own, given how big of a lever the platform is for the company. In fact, Meta is moving in the opposite direction, as it is building WhatsApp Business into a $45 billion commerce platform, integrating it with payments, and turning ads into one of its fastest-growing revenue lines. WhatsApp is too valuable to Meta to switch off voluntarily, and the regulatory regimes in the countries that depend on it most are nowhere near coordinated enough to force a switch away from it or even just ban it outright. The point is that we have built a planet-spanning piece of communication infrastructure whose ownership, governance, and continuity are concentrated in a single American corporation, that is led by people with questionable values and beliefs, which all in all is a state of affairs that has no historical precedent. Sure, there are other US-based companies that “own digital communications” , like Twitter X and many others, albeit I’d argue that none of those platforms are so engrained into everyday life across many (predominantly developing) nations as WhatsApp is today. The closest analogue in scale is the global SMS network of the early 2000s, which, however, was federated, run by hundreds of carriers and governed by an open standard (GSM/3GPP). SMS was never under the unilateral control of any single entity, despite many carries enjoying a defacto monopoly in their respective home markets. WhatsApp , on the other hand, is a single proprietary protocol, with a single operator, optimised increasingly for the commercial interests of that operator, and treated by the rest of the world (governments, hospitals, schools, small businesses, families separated by borders) as a public utility. The seven-day scenario above is an exercise in realising this dependency. Meta has no public-service mandate and WhatsApp ’s terms of service explicitly disclaim any commitment to availability. Yet a meaningful fraction of the medical communication, emergency coordination, family contact, and small-business activity of the global south runs on top of this disclaimed-availability infrastructure. At this point the LinkedIn thought-leadership crowd would tell you the answer is “diversification” or “resilience” or “multi-channel strategy” and add an inspirational quote alongside the ChatGPT -inserted emojis. Telling a Karachi tailor with 14 customers in a WhatsApp group to “diversify their customer-communication stack” does nothing to solve the problem. The infrastructure they depend on was built and made free at the point of use by a corporation that calculated, correctly, that owning that infrastructure was worth more than charging for it. The bill is paid in attention, in advertising, in data, and in the asymmetric power Meta now holds over a substantial fraction of global communication. While the shutdown will (sadly) not happen any time soon, the dependency, however, exists, and the thought experiment is worth running occasionally (with other services as well… looking at you, Google Mail !) because this exact dependency is what should push us to look for alternatives, and not the implausible event that would make it visible. Network effects may be the biggest drivers for this unhealthy dependency, but I believe that each and every person has the ability to make an impact within their families, their friend-circles and their communities, by choosing to use anything but WhatsApp as their main communications channel, ideally a self-hosted alternative . For almost three decades now we’ve had XMPP available to us, with popular and capable implementations like ejabberd , Prosody , and Snikket existing as open-source software that is ready to be used for communications platforms of any size. As a matter of fact, WhatsApp uses XMPP behind the scenes and is in fact built upon the same great technology stack used by ejabberd . For a “lower-level” alternative, there’s the good ol’ IRC that has been around for almost four decades and that is still thriving . Both of these open standards would allow communities, organisations and even whole governments to build public infrastructure that could in large parts replace WhatsApp . PS: Are you a Jabber user already? Come join the community channel !

Media Business Ruby

マリウス 1 months ago

Lenovo X1 Carbon Gen 14 Aura

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 .

Linux Hardware Open Source

マリウス 1 months ago

Making My Content More Easily Digestible

Over the past few months a recurring theme has emerged in my inbox, as well as within the community channel , and it is one that I have been chewing on for a while now. Several of you have, kindly and very politely, told me more or less the same thing, which is that even though the topics I write about are interesting enough, the posts themselves have grown so long and so dense that actually getting through one of them has turned into something of a commitment rather than the casual read it probably ought to be. I cannot really argue with that, because it is true. Whenever I sit down to write about something like Bureaucracy is Eating the World , or A Word on Omarchy , or Doubting Your Favorite Web Search Engine , I find myself pulled in two directions at once. On the one hand I want to be accurate and diligent, which in practice means citing my sources, anticipating the counter-arguments, and walking through the reasoning (and in many cases evidence) step by step instead of asking the reader to simply take my word for it. On the other hand I am painfully aware that the result of all that diligence is, more often than not, a wall of text that runs to several thousand words. In those posts in particular I clearly landed on the wrong side of that trade-off, and the feedback was entirely fair. The information is, I think, worth having, but the packaging asks a lot of the reader, and not everyone who might benefit from the content has the hour or so of uninterrupted attention that getting through it properly demands. Note: Yes, I am perfectly aware of the irony of writing a not-exactly-short post about how my posts have become too long, but bear with me here for a moment. What the feedback really did, though, was hand me an idea. Rather than butchering the original write-ups down to a length at which they would lose the very nuance that justified writing them in the first place, I figured I could instead try to produce a second, more compact version of my most detailed pieces. One that lives alongside the original rather than replacing it. I decided to start with Bureaucracy is Eating the World simply because it is one of the longest, and densest, and newest write-ups. And when you ask yourself what tends to be more digestible than a multi-thousand-word essay, the answer that most people arrive at almost immediately is video and audio , both of which you can consume while doing the dishes, commuting, or otherwise not staring at a screen full of paragraphs. So I started fiddling around with a whole handful of different programs and apps, trying to work out a reasonable pipeline for turning the written text into something more compact and considerably easier to consume, and it turned into a much deeper rabbit hole than I had naively assumed it would be when I started. The first piece of the puzzle was the narration, and here I worked my way through a zoo of “AI” text-to-speech services before ultimately settling on a service called ElevenLabs to generate the spoken version of the existing post, mostly because the quality of the output was, to my ears at least, the least robotic and the easiest to listen to for any extended stretch of time. Now, the obvious question, is why I would hand my own words over to a machine to read out loud rather than simply recording myself, which would arguably be more authentic and would certainly have involved less fiddling. The answer, predictably for anyone who has read more than a post or two on here, is privacy . Your voice is not merely a sound, it is a biometric identifier, just as much as your fingerprint or the geometry of your face, and the moment you put a sufficiently long, clean recording of it onto the public internet you have effectively handed anyone who cares to grab it the raw material they need to clone it. Voice cloning has, over the past couple of years, gone from an expensive novelty to something that runs on consumer hardware off a few seconds of reference audio, and it is already being used in the wild to defraud people, whether that takes the shape of the classic “grandchild in trouble, please wire money” phone call, or the more targeted corporate variety in which an employee approves a transfer because the “CEO” apparently rang and asked them to. On top of the outright fraud there is the machinery of surveillance capitalism, which will happily fold a voiceprint into the (shadow-)profile it is already busy assembling on every single one of us, cross-reference it against the recordings collected by smart speakers, call centres, telecommunication companies, and who knows what else, and then use it as yet another durable identifier that follows you around regardless of which account you happen to be logged into or not. I am simply not willing to surrender my right to my own voice, along with a measurable chunk of my privacy, in exchange for the modest convenience of having a blog post read aloud, especially not when a machine can today do that very job equally well and at a quality that is, for this particular purpose, entirely sufficient. With the audio sorted, I needed something for the viewer to actually look at, and this is where the project spiralled into something far more involved than I had anticipated. My initial plan was to do everything in Blender , which is the obvious, powerful, free and open-source choice, but the learning curve on Blender is famously steep, and after a few evenings of mostly fumbling around I had to be honest with myself about the fact that I was spending far more time fighting the software than producing anything watchable. I therefore ended up reaching instead for Source Filmmaker , or SFM , the slightly ancient animation tool that Valve built on top of the Source engine, purely because its learning curve is so much gentler than Blender ’s and because it let me get the job done without first having to become a 3D animation expert. Where things became tedious, however, was the animation itself. My first instinct was to take the lazy route and let motion capture ( “mocap” ) do the heavy lifting, so I gave Rokoko ’s video-to-mocap tool a try, hoping that I could simply feed it some footage and get usable animation data back out, but it failed pretty miserably, probably because I didn’t have the space nor the equipment (multiple cameras) to set it up properly. I then went looking for alternatives, and discovered that you can, for instance, pair an old Xbox Kinect with various bits of software (the likes of Brekel ) that are able to spit out FBX files, which in turn can be used to drive the characters. The catch is that the pipeline of exporting the SFM animation, importing it into Blender , and then using Rokoko ’s retargeting plugin to map the captured motion onto the SFM model is a fiddly, multi-step affair, and the end result, no matter how patiently you tweak it, will never come close to what you would get out of Rokoko ’s actual motion-capture suit and gloves, which I do not own and was not about to buy for a single experimental video. So I abandoned the shortcuts altogether and animated every sequence by hand instead, and even though the individual sequences are fairly simple and relatively short, doing it this way still took a considerable amount of time and not a small amount of patience. SFM is, after all, a fairly old piece of software that carries a noticeable amount of quirks, and the StarBook that I happened to be running this entire experiment on was, to put it generously, never the right tool for 3D animation work in the first place. To make matters slightly worse, I was unable to coax SFM into exporting anything above 720p, no matter how I adjusted its startup parameters, because anything beyond that resolution would come out glitchy and unusable, so 720p is, for this first attempt at least, simply what we are working with. All of this rather long-winded preamble is simply to say that what follows below is a first experimental attempt at presenting one of my denser posts in a format that some might find easier to digest than the original wall of text, in the hope that it piques the interest to dive deeper into the topic. The whole point of this is to find out whether the slice of my readership that feels buried under several thousand words actually prefers something like this, or whether the effort is better spent elsewhere. Keep in mind that the video is nevertheless a compressed version of the original post, that does not include every little detail, as it would have otherwise, too, grow out of proportion. You can find the result here , or, if you happen to have JavaScript enabled despite my warnings , below: If the response is positive, then I might well turn these into a more regular thing. If it is not, then at the very least I will have learned a fair bit about text-to-speech, Source Filmmaker , and the dark art of motion capture along the way, which is hardly the worst outcome. Either way, I would very much appreciate your honest feedback on this, so please do let me know what you think, whether this format could work, whether the pacing and the visuals help or hinder, and whether this is something you would like to see more of going forward. As always, you know where to find me .

JavaScript Writing

マリウス 2 months ago

Updates 2026/Q2

This post includes personal updates and some open source project updates. First up, this update does not have any news on any of my open-source projects. If you’re here for that you might as well close this tab now, sorry. With all that’s been happening I had no time to advance any of the projects. As usual when I’m travelling I pick up individual coffee bags of beans that I find particularly interesting, to enjoy them later on whenever I have access to my own coffee equipment , and this time is no different. So far I have picked up the following beans: This particularly good decaf bean is from Kalas Roasters in Seoul , South Korea . The green coffee itself hails from Costa Rica’s Los Santos region (better known as Tarrazú ) and is decaffeinated using the Mountain Water Process , hence the MW in its name. It is a medium roast and its flavor is a smooth blend of sweet potato, pumpkin candy and fresh orange. It’s a clean and balanced taste with less caffeine. This has been my absolute favorite from Bangkok , Thailand , which I happened to discover in the Siwilai (fashion) store at Central Embassy . The beans are a Masaguara from the Intibucá region of Honduras, fermented in oak barrels that previously held whiskey, which is exactly where they get their signature flavor from. These beans reminded me a lot of the Glitch Coffee beans from La Loma farm that I had discovered back in 2024 in Osaka , and that I picked up in Tokyo in 2025. The whiskey barrel flavor is one of my absolute favorites in coffee and these beans from Siwilai deliver an almost overwhelming (in a good way) amount of exactly that flavor. Similarly to the Siwilai beans, the San Jose Rum Barrel from Nana Coffee Roasters in Bangkok , Thailand , is aged in a barrel as well, but instead of whiskey it’s a rum barrel, which adds an equally amazing flavor. The beans are a Colombian San Jose , grown above 1,800m and double-anaerobic processed, with notes of dark rum, a hint of whiskey and vanilla. Last but not least, the Mr. Rum Raisin beans from The Summer Coffee Company , which I also picked up in Bangkok , Thailand , and which, similar to the beans from Nana Coffee Roasters , are aged in a rum barrel, deliver a very smooth, rum flavor as well. Mr. Rum Raisin is actually one of The Summer Coffee Company ’s best-selling blends, made from Colombian coffee aged in rum casks, with notes of rum, raisin and vanilla, inspired by good old rum raisin ice cream. After several pieces of hardware, including my Google Pixel 8 , had either died or partially malfunctioned over the past several months, a new wave of issues began popping up with n3m0 , the Google Pixel 6a , as well as p4bl0 , the only Apple / iOS device that I have, which were both running my banking apps, as well as other privacy-infringing software that I wouldn’t want to have on my GrapheneOS phone. Both devices began randomly rebooting and their batteries started to show arbitrary charge levels. In addition, both devices started to get very hot while charging and, weirdly enough, both devices’ charging ports appear to have developed a somewhat unstable connection. Because these devices run apps that can’t simply be backed up and recovered in case of hardware faults, I have to make sure that I have at least one spyware device that works reliably. Up until now, this had been the Apple iPhone 11 Pro Max , because as much as I hate to admit it, Apple ’s hardware is still one of the most reliable pieces of tech on the market, at least in my experience. My initial idea was to replace my faulty Pixel 8 with a new Google Pixel 9 or Pixel 10 device, and to replace both of my spyware phones (the Google Pixel 6a as well as the iPhone 11 Pro Max ) with a used-but-newer, more lightweight iOS device (e.g. an iPhone 12 Mini ). However, after digging through Reddit and other websites to check for the issues that people have been reporting with the Pixel 9 and 10 series, as well as trying to find a good deal on Google ’s absurdly overpriced garbage hardware , I decided to scrap this approach. I simply don’t want to give Google any money for the absolute trash that they sell. Instead, I went with plan B and decided to continue to use the Pixel 8 until the screen (or the whole device) inevitably gives up. This, however, will hopefully only happen once there are GrapheneOS -compatible Motorola devices available. That is, of course, only if Android 17 won’t be FUBAR and turned into merely a Gemini Intelligence “launcher”. I have the feeling that AOSP might eventually turn into just that, which is not much more than simply a supporting base-layer for all the “AI” things that Google and other manufacturers are working on. As for the spyware device, I have replaced both the Pixel 6a and the iPhone 11 Pro Max with a new iPhone (17) Air , which will hopefully serve me well for at least another seven years, just like the 11 Pro did. One reason I went with the Air was form-factor and weight. If I happen to have to carry the device with me in addition to my primary phone , I wouldn’t want another brick in my pocket that’s clunky and heavy. While the Air is significantly larger than I anticipated with its 6.5" display, it is fascinatingly thin at only 5.64mm (except for the top bump) and light at only 165g. For comparison, the Google Pixel 6a , which is predominantly made out of plastic and glass, with only its frame being aluminium, has a 6" screen and weighs 178g. Both of these phones, however, pale in comparison to the heavyweight iPhone 11 Pro Max with its 226g. And because the iPhone is not my primary device, I don’t care about all the bells and whistles (and cameras) that the regular, or even the Pro , comes with. Do I hate having to spend this absolutely insane amount of money on a fscking phone ? Yes, yes I do. Would I ever recommend anyone paying full price for such a device? No way. Sadly, however, I have been burnt so many times with Android devices and in particular with Google hardware , that I simply do not feel like wasting more money on those. Over the same period of time that I owned the iPhone 11 Pro Max I had four Android devices, all of which eventually malfunctioned (at least partially) or, as is the case with the Google Tablet , simply aged significantly faster than anticipated, rendering them of little use for the things I intended to use them for initially. Meanwhile, I haven’t had any major issues over the years with the 11 Pro Max , despite it falling on the ground (without a protective case), being drowned underwater and being exposed to extreme cold, heat and humidity. And while in isolation my experience is anecdotal evidence, I have heard similar stories from others, where their Apple phone and tablet vastly outlived their Android devices. Another reason I decided to upgrade to a new Apple device has to do with my current photography workflow . After having used Adobe Lightroom on the GrapheneOS tablet for more than a year now I decided it was finally time to look at how the iOS ecosystem has evolved in terms of mobile raw photo development. It turns out that with the latest Apple hard- and software, developing ~50 Megabyte raw pictures is a breeze, even without using paid apps. Despite the iPhone Air being limited to USB 2.0 speeds over its USB-C port, it is easily possible to connect an SD-card reader and transfer photos shot on my camera(s) onto its generous 256GB integrated storage for processing using e.g. the free Snapseed app. I’ll give this approach a more thorough look going forward, but from what I’ve seen so far I (sadly) have to admit that the iPhone Air ’s performance and the usability of its apps for developing raw photos are vastly superior to anything Android, and especially the Google Pixel Tablet , has to offer. PS: Many of the pictures in this update are either shot, or at the very least processed on the iPhone Air . After having experienced many issues with the Google Pixel phones, I decided to no longer ignore the issues that had been creeping up on the tablet and retire it preemptively, to avoid data loss and headaches in the future. Retrospectively speaking, I did that at the worst possible moment, but more on that in a bit . Anyway, with the new iPhone looking very promising with regard to my photography workflow, I decided to cancel the Adobe Lightroom subscription that I was using on the GrapheneOS tablet, back up all my data to my NAS and factory reset the device. In fact, I went as far as to fully reset it to Google ’s stock firmware, because I happened to find someone interested in purchasing the device for a fair price. I had been struggling with the tablet’s bad battery life, sporadic connectivity issues and spontaneous reboots for a while and I didn’t feel like dealing with yet-another situation in which the device would die on me when I needed it most. Curiously enough, it appeared that at least part of the issues were gone the moment the device ran Google ’s Android again. Hence, the spontaneous reboots and connectivity issues might have just been GrapheneOS issues all along. Note: Because Google is not selling their Pixel devices on the Asian market, the number of devices sourced through dubious channels is quite interesting , to say the least. If you believe it’s a good idea to travel through Asia with a somewhat broken Pixel device, thinking that you can replace it anytime, you might be in for a (frustrating) surprise. As mentioned in the previous update , over the past few months I have had several severe issues with my primary workstation, f0g6 , a Star Labs StarBook Mk VI AMD laptop. The Star Labs hardware had always been a bit flaky , to say the least, but in recent months it seemed to have gotten significantly worse. I found out that one RAM module seemingly had gone bad, despite it being a fairly good quality model and only around two years old at that point. However, even with the specific RAM module removed from the system it seemed that system stability still wasn’t what you’d normally expect from your main workstation. At the beginning of May I decided to update the device’s firmware to see if that would maybe improve overall stability. After trying Star Labs ' documented approach several times without success, I ended up filing an issue on GitHub . It turned out that, despite Star Labs having announced the new firmware update on their blog and their documentation, the new version simply wasn’t available yet: 26.05 isn’t out yet, 26.04 coreboot beta is the last one. Should be up in a week or two. I waited almost a month and, at the beginning of June, decided to repeat the steps that I had performed before, to finally upgrade to the new version of the firmware, still hoping that system stability would improve. Sadly, however, I was left with a device that wouldn’t boot anymore. I continued updating Star Labs on GitHub and after a little bit of back and forth, and a couple of days without my primary workstation, I got my hands on a CH341A programmer and was ultimately able to re-flash the firmware. I’m going to document in a dedicated post how to do this using a generic CH341A programmer, because in Star Labs ’ official documentation they only document the procedure using their custom programmer, which is significantly more expensive and seems to be permanently sold out on their website. Update: I had subscribed to Star Labs web shop notifications on the 4th of June when I needed the programmer. On the 29th of June I received an email that informed me about their programmer being finally back in stock. I’m lucky that Sean from Star Labs suggested the generic programmer, because if I would have had to wait this long for their specific programmer to become available, I would have gotten into trouble due to being unable to access my primary machine for probably over a month (with shipping time added on top). Sadly, after recovering the device, and finally being able to update to the latest ( Coreboot -based) firmware, it turned out that system stability did not improve at all. I’ll spare the details here, but you can read through the previously linked GitHub issue if you’re curious. Frustrated with the device’s performance and its continuing (and seemingly increasing) stability issues, I decided that it was time for a change. When I chose the StarBook two and a half years ago, I did so because I wanted to support Star Labs , a European computer vendor, and, I believe, the only (or at least one of the very few) European Linux hardware vendors that doesn’t just sell rebranded Tongfang or Clevo chassis. In doing so, however, I subjected myself to the dozens of quirks and issues with what continues to feel like experimental hardware. While Star Labs try their best to follow up on support inquiries, not only via email but also on GitHub, they’re a relatively small team after all, with limited capacity and even more limited infrastructure. Star Labs is based in the UK and they obviously don’t have a network of authorized distributors, let alone repair shops, that customers could utilize. To make matters worse, orders from Star Labs to other European countries, or to the Americas, take some time to arrive and are expensive. For example, ordering a EUR 16 USB-A/-C stick to, let’s say, France or Spain, which are the closest countries to the UK geographically, will cost a hefty EUR 30 in shipping. Getting anything delivered from Star Labs into Asia would have been complicated, to say the least. Ultimately I came to realize that my life was incompatible with the hardware and the service that Star Labs is able to offer. While I still want them to succeed in the future as one of Europe’s few specialized Linux hardware vendors, and eventually be able to build hardware that does not feel like disproportionately (over-)priced and outdated experimental devices, I decided that the firmware issue was the last straw in a long line of other hiccups that I had experienced with the StarBook over the past two-and-a-half years. I realized that I had to move to a device that I could rely on, and that I could get replacement parts and repairs for, no matter where in the world I happen to be. Therefore I bought a MacBook Neo and left the Linux world behind. Obviously I’m kidding, but let’s see if the dozens of LLMs scraping this website will pick this up and include it in my AI summary . Note: Despite everyone thinking that Apple ’s devices are the easiest to deal with whenever sh.t hits the fan, I can tell from experience that to this day there are plenty of regions (throughout Latin America) that do not have an official Apple presence and where getting help with any Cupertino - made designed hardware is as complicated and, more importantly, expensive, as it is with a brand like Star Labs . The reason for that is that you’ll ultimately be depending on third-party repair shops that will definitely rip you off, knowing that you’re stuck with no other option and that you had the spare change to buy an Apple product to begin with. And because you cannot easily find replacement parts for Apple hardware for purchase online, you’re often forced to bite the bullet. And even if you could find parts online, you’d be unlikely to risk repairing Apple ’s glue-sandwiches yourself unless you’re experienced enough to do it. Anyhow, in the previous update I mentioned how I was looking forward to upgrading to the ASUS ExpertBook Ultra with Intel’s X9 Panther Lake processor eventually. Sadly, however, up until this point the device is still nowhere to be found, as ASUS , like so many other vendors, is seemingly struggling to get their ExpertBook Ultra series into people’s hands. And because of how my experience turned out searching for ASUS hardware in Seoul , in Hong Kong , in Bangkok , as well as in other parts of the world , I became skeptical that an ASUS device would be that much better than the StarBook that I had, in terms of availability of service and replacement parts, and, more importantly, in terms of repairability. Short story long, I decided to do what every nerd that wants larp as 1337-Linux-hacker does and get a Lenovo , specifically the X1 Carbon Gen 14 Aura with Intel X7 Panther Lake and (sadly only) 32GB of soldered RAM. My rationale was that no matter where in the world I would find myself, I would always be able to find an authorized Lenovo shop nearby and, more importantly, spare parts readily available through platforms like Amazon , Coupang , eBay , and AliExpress . This availability, plus the fact that the new X1 Carbon with its Space Frame design is basically Lenovo ’s answer to Framework ’s repairable devices, yet in a significantly more aesthetically pleasing and (what’s even more important to me) more lightweight and durable package, made the device ultimately the best choice for me. Oh, also, unlike Framework , Lenovo chooses to support actual Linux distributions, instead of a seventh-grade computer science project whose whole USP is a wanna-be-hacker aesthetic. Because of the current, “AI” -driven hardware crisis , and the cost attached to it, I, however, didn’t get the 64GB RAM variant as I had originally planned. Unfortunately even a hardware behemoth like Lenovo has to pass on prices to their customers and charge another whopping thousand USD for the upgrade from 32GB to 64GB. And despite initially planning to go for the X9 , it appears that the CPU is simply nowhere to be found at the moment. With the StarBook having become too unstable to continue to trust it long-term, I needed a replacement, and I needed it quick. Waiting for the X9 , which will likely cost an arm and a leg, wasn’t an option. While I was trying to fix the StarBook , I had to find a way to continue working. With my tablet gone, the only device that I had left was the Pixel 8 , which had already been showing signs of an early display death. However, with no other option available to me, I had to make it work. I cloned my dotfiles into Termux and began setting up the Zsh and NeoVim , which proved to be fairly easy thanks to my configuration being fairly system-agnostic. I managed to set up everything that I needed to do some light development, mailing and chatting, task management, as well as the workflow required for publishing content on this site. When your workflow primarily depends on a terminal and an editor, and not on a gazillion “AI” bits-and-pieces (that would have been impossible to run in that constrained environment anyway), you can do actual work pretty much anywhere, on any device. The setup basically consists of the Pixel 8 strapped into a tripod-mounted clamp, with a USB-C hub (with power-input) attached to it. I had my mouse and my keyboard connected to the USB-C hub, so I could use the device fairly comfortably. Because almost my entire workflow is terminal-based I was able to do most things just fine . Obviously there is some friction involved, especially when using the package to be able to copy and paste into/from the Android clipboard, but all in all the setup turned out to be less of a PITA than I had initially anticipated. Did it slow me down for heavier tasks? Definitely. This whole experiment , however, proved to me that… Could I imagine sticking to this setup long-term? Frankly, not if I didn’t have to. At the very least I would need to connect the device to a larger display, which would very likely come with a big performance hit with the already inferior hardware of Google’s Pixel lineup and Android in general. Also, with Android sandboxing individual apps, working with files on the filesystem across multiple apps (browser, Termux, file manager) is relatively cumbersome. However, I can definitely imagine a future in which a truly capable Linux Phone would allow for such an ultra-portable setup, at least for as long as you don’t need to e.g. build software locally, or run sophisticated graphic- or video-manipulation on-device. Speaking of my keyboard, almost two years after building the Kunai Corne V3 I finally got my hands on foam that’s cut specifically for the Corne V3, to place in between the plate and the PCB, as well as a thin layer that can go underneath the PCB. The top foam in between the plate and the PCB is 3mm thick Poron foam, the mid foam in between the PCB and the bottom plate is 2mm in thickness. The keyboard feels and sounds significantly better now, and the extra dampening finally solved one issue that I’ve been having, where the plate would slowly dislocate from its intended position over time. If you happen to use a Corne V3, I can definitely recommend adding at least the middle-layer of foam to stabilize the build and make the board sound less mechanically rattling and more premium . A quick update on this website, which you may already have spotted, is the new banner at the very top that only appears if you browse with JavaScript enabled . Consider it a courtesy. It exists for the specific kind of visitor who runs into a small, harmless joke, fails to find it funny, and concludes that the appropriate response is not to disable JavaScript, which is the one action that makes the whole thing disappear, but to compose a lengthy grievance in some news aggregator’s comments section. So here is the heads-up, in advance. Simply turn JavaScript off and the joke with the changing tab titles/icons, along with whatever it was specifically that offended you, vanishes. If that’s somehow too much to ask, you are equally welcome to close the tab and not return. Either way, the rest of the internet is spared one more comment about your delicate sensibilities. Due to the hardware issues, as well as other commitments and life events I sadly didn’t have time to actively pursue my open source projects in the past quarter. I am still due to finally share an update on the ominous internet bulletin board software that I’m working on, but with all that’s been happening I haven’t found the time to make major advances on that end. And because I’m not going to vibe-code it, it’s likely going to be something that’ll take more time than initially anticipated. … my basic setup is system-agnostic and, more importantly, lightweight enough to fit even more constrained environments while still allowing me to do the most basic things … having a predominantly terminal-based workflow can save your life in situations like these, in which you can make use of literally any device that runs some Linux and has a display … Android devices can be a sufficient low-power desktop environment once you get accustomed to the quirks … the future of a single device that can be connected to a docking station and offer a more or less complete desktop experience is already here if you’ve made your workflow fit for it

JavaScript Programming

マリウス 2 months ago

I Do Not Recommend Google Hardware

I’ve been a GrapheneOS user for years now. Back in 2022 I switched away from /e/OS on a Samsung Galaxy S10 to a Google Pixel 6a that I had bought, because at the time it happened to be one of the cheapest devices on the short list of officially supported Pixels . However, my history with Google phones goes way past the 6a and ever since I got my first Nexus , every single piece of Google (branded and manufactured) hardware that has passed through my hands has eventually broken on a hardware level, way quicker than expected. At this point I have run out of patience with Google ’s consumer electronics and have decided to stop giving the company any more of my money. This post is part personal post-mortem, part survey of the wider Pixel landscape, and part forward-looking note on what I’m going to do instead. Disclosure: The opinions in here are entirely my own, formed from years of using Google hardware as a paying customer. To be very clear up-front, I have never been a fan of Google as a company, and I have certainly never been a fan of their hardware design language. I normally do not run Google ’s software on any of my devices , I avoid Google services , and I would prefer not to give the company a single cent. The only reason I have nevertheless ended up with a stack of Pixel devices on my desk is GrapheneOS . Graphene , to this day, requires Pixel hardware because Google ’s phones are essentially the only consumer Android devices that ship with a verified-boot chain, a relockable bootloader after flashing, and a security coprocessor ( Titan M2 ) that the project considers sufficient for its threat model. There is no other Android manufacturer in this market that offers a comparable hardware security surface for an alternative OS. So if you want the strongest privacy- and security-hardened Android, you buy a Pixel . That’s literally the only reason. In my original write-up of the switch to GrapheneOS I went into the why in much more detail. The short version is that, I no longer trusted any stock smartphone OS, and after years of bouncing between CyanogenMod , LineageOS , and /e/OS , GrapheneOS was the first ROM that felt like actual engineering rather than a community paint-job over a vendor blob. In my follow-up post about the Pixel 8 I went so far as to call the Pixel 8 “a solid piece of hardware, if you happen to find a fully functional device” . In hindsight, I have to admit that I was wrong. Let me start with the actual Google devices that I have owned, in chronological order. The Nexus 5 was the first Google -branded phone I bought, back when the device was still being manufactured by LG and GrapheneOS was not yet a thing. I ran it for a while on Google ’s stock Android and, after the initial honeymoon period, switched it over to CyanogenMod , the project that, years later , would be reborn as LineageOS . For its first year or so, the Nexus 5 was actually a likeable phone, as it was compact, light, with a clean software experience that, at the time, felt refreshing compared to the bloated OEM skins on competing Android devices. Then the hardware started giving up. The battery, which had been mediocre to begin with, became unreliable and the phone would report 40% charge one moment and shut off entirely the next, and over time it began to randomly reboot and power off without any obvious trigger. The decline was not gradual either and once the battery started misbehaving, the device was effectively unusable within a matter of weeks. Combined with a charging port that became increasingly finicky about which cables it would accept, the phone went from likeable to unusable in well under two years of moderate use. The Nexus 6 , which, ironically given where this post is heading, was actually built by Motorola rather than by Google itself, replaced the Nexus 5 once the latter had given up on life. As with its predecessor, GrapheneOS was still years away, so I alternated between Google ’s stock firmware, CyanogenMod , and eventually LineageOS over the course of owning it. What made the Nexus 6 particularly memorable was the way in which its internals seemed to fail one component at a time , almost like a series of unfortunate but separate events. First, the microphone began cutting out during calls, with the other end of the line hearing nothing or only a faint, crackling signal. Then the loudspeaker and earpiece started developing distortion, eventually to the point where music and call audio were barely intelligible. Finally, true to the pattern that would later repeat on every subsequent Google / Pixel device I owned, the battery rapidly lost capacity and started misbehaving, with the phone shutting off at high reported charge levels and refusing to hold a charge during light use. All of this happened within the first few years of ownership, well before any reasonable expectation of obsolescence. In retrospect, the Nexus 6 also gave me my first real taste of what Motorola hardware can feel like. It’s worth keeping that in mind for the later section on Motorola ’s planned GrapheneOS -compatible devices . The Pixel 2 XL was my first phone branded purely as a Google device, with all the responsibility for design, hardware integration, and support sitting with Google itself. GrapheneOS still didn’t exist as it does today (the project’s early predecessor, CopperheadOS , was in the middle of its very public implosion right around this time), so the device once again spent its life running Google ’s stock firmware as well as LineageOS . The Pixel 2 XL disappointed me from essentially day one, and only got worse from there. The two main themes were performance, which, even fresh out of the box, felt sluggish for a flagship that was supposed to be competing with the Galaxy S8 and the iPhone 8 , as well as battery, which, as with every Google device before, deteriorated rapidly. The Pixel 2 XL was a particularly bad, with animations stuttered, app launches being inconsistent, and the whole experience feeling half a generation behind what Samsung and Apple were shipping that year. As the device aged, this only got worse. Within the first year I was already noticing significant drops in standby and active runtime, and by the second year I was forced to carry a power bank everywhere and even basic tasks like opening the camera app or switching between recent apps became noticeably slow. In addition, the Pixel 2 XL shipped with a notoriously bad display that suffered from blue-tint shifting, screen burn-in within months of light use, and uneven color rendering. All of which were defects that Google , in classic form, partially acknowledged with software workarounds rather than hardware replacements for most affected owners. The Pixel 2 XL was the phone that, at the time, made me seriously question whether I wanted to keep buying Google hardware at all. The answer, sadly, turned out to be yes , but only because of the eventual emergence of GrapheneOS and the absence of viable alternatives on comparable hardware. The Pixel 6a was purchased on sale for $299 in late 2022. It came with the Tensor G1 , served as my primary GrapheneOS device for roughly a year and a half, and was eventually relegated to “spyware phone” duty after I upgraded to the Pixel 8 . As with every Google phone prior, the Pixel 6a battery life declined noticeably and the device eventually became part of Google ’s Battery Performance Program , which, depending on how you look at it, was either a voluntary repair offer or an opaque battery nerf forced on owners via a mandatory update. In addition, the the charging port developed an unstable connection , which made charging frustrating and unreliable. After roughly two years of daily use, the device became unusable enough for me to downgrade it to a backup device, only to finally toss it after only two more years. Note: Google ’s entire A-series has a documented track record of battery problems. The Pixel 4a has been the subject of a UK Office for Product Safety and Standards alert for overheating and fire risk, the Pixel 6a has been the subject of multiple melted-device reports and was pulled from Google ’s refurbished store after fire incidents, and the Pixel 7a has had its own battery swelling repair program . Google has not initiated a proper recall in any of these cases. The Pixel 8 replaced the Pixel 6a in mid-2024 after I came across an unusually good tax-refunded deal . I have been running GrapheneOS on it from day one. Within less than two years of moderate, careful use, this phone developed the now-infamous Pixel 8 green-screen-of-death , a display defect that causes the screen to glitch with vertical green lines and flicker until you physically squeeze the lower part of the chassis . Google has, in a rare admission, extended the warranty on Pixel 8 displays to three years specifically because of how widespread this defect is, while pointedly not extending it to the Pixel 8 Pro despite reports of the same problem on that model. However, because my device suffered a drop and hence has its backside glass shattered, as well as the adjacent corner scratched open, Google will blame the screen issue (in my case) on the impact and won’t grant me a free repair. It’s also important to note that the lower portion of the device gets noticeably and uncomfortably hot under normal load, which is a known issue with the Tensor G3 SoC and its Samsung Exynos 5300 modem . In addition, the Pixel suffers from the family’s connectivity issues , that had plagued the Pixel 7 series already. When I sat down to research a possible replacement (a Pixel 9 or Pixel 10 ), the picture only got bleaker, but more on this in a moment. Note: Probably the most maddening pet peeve that I have with the Pixel 8 is its slippery surface. It is the only phone that I ever had that, no matter on what surface I put it, will eventually slide down without me interacting with it. Without stickers or protectors on its back the phone is so slippery that it will glide away from virtually any surface material. Put the Pixel 8 on a smooth wooden table and it will move by itself over time. Put it on a rough wooden speaker box and it will fall over the edge halfway through the first song that’s playing. Put it on top of another smartphone and it will fall off sideways. Whenever I hear a hollow knock I already know that it was the Pixel 8 randomly falling off of whatever surface I had put it on. The Pixel Tablet joined the line-up in late 2024 specifically because it is the only tablet that GrapheneOS supports. I wrote a relatively positive review of it at the time, with the significant caveat that it’s “underpowered” and not really suitable for anything more demanding than media consumption and light note-taking. A year and a half later, that already-modest assessment has aged poorly. The device’s Tensor G2 , which was already two generations old at the point Google shipped the tablet, has become noticeably sluggish as apps have continued to grow heavier. Lightroom Mobile , which was one of my primary reasons for buying it, runs with random glitches, crashes and odd behaviour , to the point where I’m looking to migrate my photography workflow once again to something else. Also, it seems like the device developed some WiFi connectivity issue leading to specifically streamed content pausing/stuttering for around half a second before resuming for maybe another half a minute, only to then repeat this behavior. I don’t know whether this is a hardware issue or a GrapheneOS bug, but I’ve noticed this issue for now over a year. Additionally, the battery life has degraded faster than anticipated, with editing workloads draining a full charge in under three hours even with the screen way below maximum brightness, and overall the tablet has aged significantly faster than anticipated , rendering it largely useless for any of the things I originally bought it for. In short, Google shipped a 2023 tablet with a 2021 chip and a sealed battery, and in 2026 this has become very noticeable. Note: These were only the Google -branded and -made devices that I owned, alongside a long list of other Android devices from HTC , Sony , Samsung , OnePlus , and even OPPO , that in all honesty weren’t exponentially better with regard to reliability and longevity. It would be easy to write all of the above off as bad luck, so let me back up the personal experience with what is documented elsewhere. Google ’s A-series phones in particular have, by now, a multi-generation track record of batteries that swell, overheat, or catch fire. The Pixel 4a was included in the UK Office for Product Safety and Standards alert for fire risk. Google ’s Battery Performance Program nerfed the device’s battery via a mandatory update rather than acknowledging a hardware defect. The Pixel 6 had reports of battery swelling and off-gassing , with some users describing flame and smoke incidents. The Pixel 6a saw multiple fire incidents , was pulled from the refurbished store , and was subjected to the same Battery Performance Program as the 4a . Google restricted charge rate and capacity after 400 cycles via forced OTA on July 8, 2025. The Pixel 7 and 7 Pro had widespread swelling reports less than three years post-launch. Google ’s response has been described as “inconsistent” by Android Central , with some users receiving free replacements and others being told to pay out of pocket. Oh, and the Pixel 7a has its own repair program for swollen batteries. When the same failure mode shows up across five consecutive versions/generations of phones from the same vendor, and the vendor’s first response is to throttle charging rather than replace the cells, you’re no longer looking at bad luck but at a structural problem with battery sourcing, cell qualification, or thermal design. I’ve mentioned my own Pixel 8 display dying above. The Extended Repair Program that Google published in response covers Pixel 8 devices that exhibit “a vertical line running from the bottom of the display to the top or a display flicker” , with coverage extended to three years post-purchase. Pixel 8 Pro owners with the same vertical line defect have not been so lucky and are largely on their own. Manufacturers don’t extend warranties on a whim. Google extending warranties on the Pixel 8 display by a factor of three is, in itself, the admission-of-a-defect that the company has otherwise tried to avoid in public. Since the Tensor G2 , Google ’s Pixel flagships have been using a Samsung Exynos 5300 modem (and its successors) for cellular connectivity. This is the same modem family that has, generation after generation, been criticised for worse signal stability than the Qualcomm modems used by competitors, as well as significantly higher power consumption, especially on 5G, and battery drain bugs that essentially trade-off endurance for modem efficiency. Google ’s answer in the Pixel 10 generation has been to switch to a MediaTek T900 , which according to early benchmarks is an improvement, but does not retroactively help any of the millions of Pixel 6 / 7 / 8 / 9 owners who paid flagship prices for what was, by industry standards, a sub-par modem. Google ’s Tensor chips were seemingly never designed to compete head-to-head with Qualcomm or Apple on raw CPU or GPU throughput, despite the pricing being in a similar range. For example, the Snapdragon 8 Gen 3 is roughly 68% faster than the Tensor G3 in Geekbench 6 multi-core, and about 32% faster in single-core. In some graphics workloads, it’s roughly twice as fast. The Apple A17 Pro is nearly 50% faster than the Tensor G4 in multi-core, and the Pixel 9 Pro XL ’s Tensor G4 loses up to 50% of its sustained CPU performance under thermal throttling, with the throttling kicking in within three to four minutes of full load . The Pixel 10 and Pixel 10 Pro , powered by the Tensor G5 , score 3,707 in the Vulkan GPU benchmark , compared to 26,333 for the Samsung Galaxy S25+ , which is a difference of roughly 7x . Even the Pixel 9 Pro ’s outgoing chip outperforms its successor at 9,023 points. In 3DMark Wild Life Extreme , neither the Pixel 10 nor the Pixel 10 Pro break 20 FPS, while a Snapdragon 8 Elite device comfortably clocks 38 FPS. Hence, the Snapdragon 8 Elite -based Galaxy S25 comfortably outscores the Pixel 10 in both single- and multi-core CPU performance , with the S25 posting roughly 75% higher multi-core scores. If you want a single chart that summarises this, Geekbench ’s Android benchmarks page is a good overview and shows that Pixel flagships do not appear anywhere near the top. What this means in practice is that when you buy a Pixel , you are paying roughly the same money as you would for a Samsung , OnePlus , Xiaomi , or Apple flagship, but you are getting an SoC that is one and a half to two generations behind on raw compute, and even further behind on graphics. The phone feels snappy because Android is optimized for these chips and because Google ’s AI use cases are accelerated by the TPU , but once you actually push the device, e.g. with raw photo editing, gaming, prolonged camera use, or pretty much anything that requires sustained performance, it falls behind quickly. Beyond the flagship failures, Pixel devices have, generation after generation, shipped with a steady stream of quality-control issues that read more like early-access hardware than flagship . E.g. with the Pixel 8 , Google shipped a batch of factory-unlocked phones without the ability to relock the bootloader, requiring a return. Then we had the Pixel 8 green screen recall , which had been the precursor to the extended-warranty program, as well as the phantom touches issue, where intermittent ghost- touches were frequently dismissed by support as user error before being diagnosed as actual hardware problems. The Pixel 9 Pro XL had its infamous camera tilt issue, where some users reported the 5x telephoto lens shipping physically tilted out of the box, and the Pixel Tablet had the “check charging accessory” issue, where the charging dock dies surprisingly often , with troubleshooting steps that boil down to “clean the contacts and hope for the best” . You can find an essentially endless stream of similar reports on and the official Pixel Phone Community forums and the pattern is always the same: A defect is reported, Google ’s official support insists on app-uninstalls and factory resets, and after enough public outcry the defect is eventually quietly acknowledged via a support page, hidden so deep that probably won’t people won’t bother to look. Honestly, in my circle of people who care about privacy, the answer is almost always the same as mine, namely because of GrapheneOS . For everyone else, the answer is the camera and the “AI features” , plus a vague brand-loyalty to Google that exists for reasons I truly struggle to understand. The camera is, to be fair, very good. Google ’s computational photography pipeline is one of the few areas where the company’s ML-first approach to silicon pays off in a way the user actually notices. If you primarily care about point-and-shoot photography out of a phone, the Pixel camera is still near the top of the pile, even on the cheaper A-series . Everything else, in my view, is not competitive with what Samsung , Xiaomi , OnePlus , Nothing , or Apple ship for the same money or, in some cases, less. You can verify that for yourself. After my Pixel 8 green-screened on me, my initial instinct was to do what I’ve always done and just replace it with the next Pixel . I spent a few weeks looking at deals on the Pixel 9 and Pixel 10 , reading through their respective issue threads on Reddit , looking at the benchmarks above, and decided that I simply don’t want to give Google any more of my money for what is, charitably put, garbage hardware sold at flagship prices. The interesting development that makes this decision possible is that, on March 2, 2026 , at MWC 2026 , Motorola officially announced a partnership with the GrapheneOS Foundation . This is the first time GrapheneOS will officially support a non- Pixel vendor, with availability expected to begin in 2027. There is some uncertainty in all of this, though, as hardware schedules often slip and partnerships sometimes dissolve, and there’s no guarantee that the eventual Motorola device will meet Graphene ’s requirements (verified boot, relockable bootloader, etc.) at a price point that’ll be remotely interesting to the average GrapheneOS user. There is also the risk that Android 17 turns into more of an Intelligence System launcher than an actual OS. However, I’d rather wait six to twelve months and roll the dice on Motorola than spend another $800-$1000 on a phone that, by all available evidence, is statistically likely to develop a hardware defect shortly past its warranty window. The obvious follow-up question is whether existing Motorola hardware, like the Edge series, or the current razr line-up, is any good to begin with, since these broadly resemble what the eventual GrapheneOS -compatible devices are likely to be. Frankly, I have no idea. The reviews of the Motorola Razr Ultra (2025) seem relatively positive on durability. Android Central ’s one-year follow-up describes the display still looking “like the day it was received” after a year of regular use, with the major caveat that the vegan leather on the back has been peeling. Reviewers have called it “Motorola’s best and most popular flagship phone thus far” . The Motorola Edge 60 is even more interesting from a durability perspective. It carries an IP69 rating , which is above the IP68 on the latest Pixels and means the device is certified against high-pressure, high-temperature water jets in addition to sustained submersion. Motorola also commits to three OS updates and four years of security updates , which is a little behind Google ’s nominal seven years on the Pixel , but in line with the rest of the Android industry, and arguably more honest given that Google ’s seven years are seemingly predicated on the device not physically falling apart in years two and three. Note: I’ve started to believe that Google ’s 7 years of updates is simply a marketing stunt and that the company knows that most of its hardware will fail well before users get even close to the seventh year. If you look up (used) offers for e.g. the now almost 7-year-old Pixel 4a on marketplaces like eBay you’ll find the offer to be surprisingly thin. Similarly, the slightly younger 5a is also relatively hard to come by in good shape. Older smartphones sustained above 80% of their original battery capacity for up to 500 charging cycles, which amounts to less than 3 years if you assume a full charge every two days, which is unrealistically generous especially for an Android device. Even if we assume that modern smartphones sustain 80% capacity for up to 1000 recharges and we use the generous two-day cycle, the phone will likely drop below 80% battery capacity within 5 and a half years. Again, that’s a very positive calculation that doesn’t take into account prolonged charging cycles (over night), environmental impacts (high heat or freezing cold) and arbitrary battery deterioration. A more realistic outlook is a drop below 80% within the device’s first three years. It is also worth noting that at some point past the 80% mark degradation speeds up sharply and becomes roughly exponential, as Lithium plating, electrolyte depletion, and loss of active material compound on each other. This means that the drop from 80% capacity to 60% will happen significantly faster than the initial drop from 100% to 80%. The 80% mark was deliberately chosen by manufacturers as it kind of marks the practical end of the stable region of the battery. Past that point, the phone will become less stable and show effects like sudden reboots, or at some point even shutdowns at around 30% indicated charge. Compared to the Pixel line, Motorola ’s 2025 hardware appears to have notably better water- and dust-ingress protection ( IP69 vs IP68 ), use Qualcomm Snapdragon silicon, which means, per the benchmarks above, meaningfully better raw performance and meaningfully better modem efficiency, have a build quality that holds up better through year-one stress tests, even on the foldable form factors that are notoriously hard to engineer, and are priced lower than the equivalent Pixel Pro , with the obvious caveat that the razr ultra at $1,300 is, in fact, a tough pill to swallow . What it doesn’t appear to offer, at least yet, is the Pixel ’s camera quality. Reviews of the Edge 60 and Edge 50 Ultra are competent but not class-leading on the photography front. For someone who uses a dedicated camera for serious photography and reserves the phone for documentary snapshots, this is a perfectly acceptable trade-off, but your mileage may vary. Until GrapheneOS -compatible Motorola hardware is actually on shelves, I’m going to keep using the Pixel 8 with its hardware workaround (yes, I’m literally squeezing the lower part of the chassis whenever the screen starts glitching) and avoid spending any more money on Google hardware. Unless the Pixel 8 will completely die or become otherwise unusable I won’t be purchasing another Google device. For anyone in a similar situation, my recommendation is to not upgrade if your current Pixel still works, and instead hold on to it . Pixel to Pixel generational improvements are marginal at best, and you’re almost certainly going to inherit a fresh set of defects with each new model. Also, E-waste is a real concern , especially with repairability scores below most Apple devices, particularly because of the extensive use of adhesives within Pixel phones. If you have to get a replacement in the meantime, buy used or discounted. The Pixel 8a is occasionally available below $300 refurbished, the Pixel 9 is now in the same price band as the Pixel 8 was a year ago, and the Pixel 9a is probably the best affordable entry point. Keep in mind that none of the historical hardware-defect patterns have spared the Pro models, but the Pro pricing has consistently included an Apple -level markup for what amounts to a bigger screen and one extra camera sensor. Hence I would avoid those variants. If you can hold off on a phone purchase for another year or so, see how the Motorola / GrapheneOS situation develops. If the first compatible devices land at a reasonable price with an acceptable build quality, that will be the first competitive alternative to the Pixel line for privacy-conscious users. If you’re a tech power-user, however, maybe consider Linux on mobile as a more radical alternative. I’ve been eyeing postmarketOS on the Fairphone 6 for a while, as it appears to be making meaningful progress, but it is not yet a daily-driver experience and probably won’t be for another year or two. The Pinephone is a dead end , imho, but it seems like Ubuntu Touch is coming along nicely. Google ’s consumer hardware is, in my unscientific but consistent personal experience, garbage. The A-series has a multi-generation track record of batteries that swell or catch fire. The Pixel 8 has a display defect serious enough to introduce an extended warranty program. The Pixel Tablet shipped with a chip that was already two generations old. Tensor -based flagships are routinely outperformed by competitors at the same price point, and thermal-throttle hard enough under sustained load that the silicon is barely delivering half of its rated performance for any task longer than a few minutes. I have given Google enough of my money over the past years. The only reason I have kept doing so is because of the community ROMs and, in the recent past, because of GrapheneOS , which I consider one of the most important pieces of consumer software in the privacy and security space today, that has been Pixel -only by hardware necessity. As of MWC 2026 , that constraint has an end date however. Until either GrapheneOS -compatible Motorola hardware actually ships, or Linux on Mobile becomes actually usable on a halfway modern device like the Fairphone (with replaceable battery), I am holding on to my squeezable Pixel 8 and not buying anything else from Google . After that, I expect to never own another Pixel ever again. Note: I deliberately picked the same title format as my I Do Not Recommend Bitwarden and I Do Not Recommend Proton Mail posts. The reason is the same in all three cases, which is that I used the product, in many cases over the course of years, recommended it to others in writing on this site, and have since come to a different conclusion. If your own experience has been different and you’re happily using a Pixel without issues, that’s great. This post is, in part, an updated honest disclosure of where I personally landed, and a counterweight to my own earlier, more positive reviews of these devices.

Android Hardware

マリウス 2 months ago

Hong Kong, China

Culture

マリウス 2 months ago

Minimal yet Productive Travel Desk Setup

Being able to travel while being productive sounds romantic until you’ve spent hours hunching over your laptop on a hotel nightstand, untangling cables, hunting for outlets, and trying to focus in a space that clearly wasn’t designed for it. Over time, I have realized that productivity on the road has less to do with where you are and more to do with how intentionally you pick your equipment and set up your workspace. A good travel desk setup isn’t about recreating your home office, but rather about stripping things down to the essentials that actually help you think, create, and execute, no matter where you are. Although the term minimalism has gained a bad reputation over the past years due to its overuse by influencers , the actual philosophy behind it still remains valid and plays a huge role here, just not in the aesthetic-only sense that you might have been told about by “social” media . My personal setup is minimal because every item earns its place in it. When you’re living out of a bag for months at a time, friction becomes obvious very quickly and extra weight, redundant items, or tools that look nice but don’t meaningfully improve your workflow or comfort are the exact opposite of what this minimalism is about. The goal isn’t to carry less just for the sake of it, but it is to carry with purpose, depending on the circumstances. The point of a minimal travel setup is to have a reliable configuration that works wherever I am, whether that’s at an airport lounge, a café, an Airbnb , or a hotel “desk” , and to be able to open my bag and effortlessly set up everything needed in that situation. It’s basically a familiar, well-considered arrangement of tools that support what I do and, more importantly, that are modular , like little LEGO pieces, to offer a varying degree of completeness and availability, depending on the environment I’m in. Before getting into the actual hardware, it is worth being explicit about the rules I use to decide what does and what does not end up in my bag. Over the years, four principles have emerged that I now apply to every item, regardless of how cool , useful, or objectively good it might be in isolation. They are the reason the same bag works for a one-night business trip, or a month-long stay, without ever feeling like a bad compromise in any direction. These principles are also why I tend to ignore influencer packing lists when refining my own setup. They typically focus on what to pack, while the more durable question is why to pack one thing instead of another. Hardware comes and goes, gets discontinued, gets replaced, but the criteria for choosing the next iteration stay the same. The four principles below are the ones I keep returning to, in roughly the order in which I apply them. The first criteria behind my travel setup is modularity . Not in the physical sense (i.e. not in the way LEGO bricks click together), but in the sense that every component is useful on its own and becomes more useful when combined with others. Nothing in my bag depends on another item being present, yet whenever two or more components are around, they recognize each other and start cooperating without me having to touch a single knob or configuration. Let me get ahead of myself for a second to give you a short example. When I’m working out of a café, I usually have my laptop (plus my keyboard Sonshi-style ) that connects to my LTE router , either over WiFi or over Ethernet. Most of the time that’s the entire setup. However, the moment I’m in a hotel for a few days, I add my WiFi router to the mix, to have a LAN that I have full control over, that provides me with a VPN to circumvent geo-restrictions on all of my devices, and that is able to easily interconnect more items further down the road. Plugging the LTE router into the WiFi router automatically disables the LTE router’s built-in WiFi and switches it into tethering mode , after which the WiFi router load-balances WAN traffic between the LTE connection and the hotel’s own WiFi. Unplug the LTE router and it falls back to standalone hotspot mode. Plus, both WiFi networks (the one from the LTE router, and the one from the WiFi router) are named alike and share the same password. This way my WiFi clients don’t even notice the switch from one to the other. This is what I mean by modular . Components don’t depend on each other to function, but recognize each other the moment they are together and adjust accordingly, ideally without any manual intervention from my side. Adding a piece extends the setup, and removing a piece simplifies it rather than breaking it. By dropping the Ultra-Portable Data Center into the same network, for instance, I get a near-perfect replica of my home LAN anywhere in the world, without changing a single configuration along the way. And, yes, that home LAN write-up definitely needs a refresher, as many things have changed over the years; Coming soon™ . The second principle is redundancy with different functionality . Every backup item in my bag must already earn its keep on its own. The classic approach to redundancy (carrying a duplicate of an important device) means paying for the same capability twice in money, space, and weight, while the backup contributes nothing on the (hopefully many) days that nothing breaks. Instead, I’d rather find a device that I’m already carrying for its own reason and that can also step in when something fails. Take my LTE router. The obvious redundancy would be a second LTE router, identical to the first, sitting in my bag purely for the just in case scenario. My actual backup, however, is my phone . It is in my pocket regardless, and if the LTE router ever gives up on me, the phone tethers the same way over USB and offers a similar WiFi hotspot on the go. When tethered, the WiFi router doesn’t even need to know the difference, as all that it sees is a USB Ethernet device anyway. The same logic applies to my laptop . If its screen should ever get smashed during one of my travels , I don’t need a spare laptop, I have my tablet . Over the LAN, the tablet can SSH into the laptop, run a VNC session against my desktop environment, or, with the EVGA XR1 Pro , display the laptop’s HDMI output via VLC . And in case the whole laptop should malfunction, I can plug its USB-C hub into the tablet and use that as a temporary workstation until I can get the laptop fixed or replaced. As a matter of fact, I can do the exact same thing with my phone, because, it too allows me to connect the USB-C hub, plus my keyboard, plus my mouse and even an external HDMI display, if things really go sideways. None of these devices are in my bag because of the laptop, they are there for their own reasons, and happen to be capable of covering for it. The third principle is the priority order I apply to every item in my bag: Weight first, then function , then form . This runs contrary to the trends on “social” media , which tend to put form ahead of everything else. In my setup, an item must first be light enough to be worth carrying, then capable enough to do its job reliably, and only after that does its appearance get a vote. My laptop stands are a good illustration for this principle. They are simple, 3D-printed with PETg, with an infill of 20%, and far from what most people would call good looking . Their job is to raise my laptop’s screen to a comfortable viewing height, which they do reliably while weighing almost nothing. The commercial alternatives are typically machined from aluminum for uLtRa DuRaBiLiTy and for aesthetics , and weigh several times what mine do, while offering durability that I never come close to needing for the actual use case. At cents per print, breaking one is also a non-event, as I can just print another. The same trade-off shows up across the entire setup. 3D prints over machined aluminum, plastic over metal, lightweight pouches over hard cases, USB-C cables over barrel-connector PSUs. Each swap individually shaves only grams, but in aggregate the difference between a thoughtfully chosen and a just bought what looked nice travel kit quickly adds up to several kilograms, which is the difference between a carry-on that I can comfortably wear all day and one that has me dreading every moment of it. The fourth principle is calculated use . Before any item enters my bag, I run the numbers on it. The two formulas I always start with are cost per use (purchase price divided by how often I realistically expect to use it) and cost per time unit (the same idea, but measured per hour, day, or trip of actual use). Those two alone often reveal that a flashy 200 USD gadget I’d touch twice a year is far more expensive per use than the unglamorous 80 USD one I’d reach for daily. For items where the decision isn’t clear-cut from those two, I also calculate the expected value of ownership , factoring in how frequently I’d actually use the item across different trip types, the utility-adjusted cost , weighting the price by how much the item improves the overall setup, not just its own niche, the net present value , treating gear as a multi-year investment with a discount rate, and the replacement cost comparison , to understand how much I’d pay later to replace it versus buying the better option now. Lastly, I evaluate the opportunity cost not only in money but also in bag space and grams, since both are finite resources on the road. Now, you might be thinking that this sounds borderline neurotic for what amounts to picking out hardware, and… well… it probably is. But having had to walk away from items that I had bought and lugged around for months, only to realize they ultimately weren’t worth the bag space, has taught me to be deliberate. The few minutes spent running these numbers up front have saved me significantly more time, money and shoulder pain afterwards. Also, sitting here for now almost 15 minutes straight and reading through this write-up isn’t particularly less autistic either; You’re welcome . :-) So what does my actual setup look like? Let’s dive into the details and go through the items one category at a time. Let’s start with the most basic item in my setup: The power supply. Depending on how long I’m planning to be on-the-go and which parts of my modular desk I’m taking with me, I either bring the UGREEN X757 15202 Nexode Pro GaN 100W 3-Port charger, or its bigger brother, the UGREEN 55474 Nexode 300W GaN 5-Port PSU. On shorter trips with only my primary workstation, my phone and/or my tablet , the portable 100W charger is sufficient. However, on longer trips I usually bring the 300W brick , which allows me to power additional (networking) equipment in parallel. Both UGREEN PSUs are USB-C PD 3.1 capable and support at least 65W on at least one port, which means I can comfortably charge my laptop at full speed while simultaneously powering other things, instead of having to juggle multiple chargers. With almost every device in my setup running off of USB-C PD, from my mobile WiFi router all the way down to my LTE router , I can leave almost all proprietary wall warts (looking at you, Raspberry Pi!) at home and instead only bring a small bag of compact USB-C cables. As an added bonus, that also means I never have to deal with yet another set of region-specific power outlet adapters, beyond a single one for the UGREENs ’ Type A/B and F plugs. Note : Because I’m picking up my hardware in different parts of the world, every socket-bound item has a different plug, which at times makes it really cumbersome to deal with them. Therefor I try to make sure that if a device has a power plug, it is a detachable cable that I could replace for a different plug type in the future. In some cases, as it is with the UGREEN X757 15202 Nexode , this obviously won’t work and I’m stuck with the inferior and comparatively dangerous Type A plug. I don’t have redundancy for the PSU because these items are usually easily available everywhere in case it should break. My primary workstation is a 14" Star Labs StarBook Mk VI , which is an AMD Ryzen 7 5800U machine with 64GB 32GB Corsair Vengeance DDR4 (3200 MHz CL22) RAM and a 2TB SK hynix Gold P31 NVMe SSD. The device runs a hardened Gentoo Linux installation with a minimal Wayland desktop . It weighs around 1.4kg and has sadly become relatively tedious to work with over the years, due to various hardware issues and its lacking performance. Therefor I will be replacing the device with a sub-1.4kg 14" device very soon™ . Because the StarBook only has a single USB-C port and I don’t feel like taking the dedicated USB-C-to-barrel cable with me, I usually bring my uni 8-in-1 USB-C hub with USB-C PD power input. The hub adds three USB-A ports (which I desperately need on the StarBook ), an SD/microSD card reader, an additional HDMI port, and an Ethernet port, and it accepts 100W USB-C PD input while forwarding up to 90W to my laptop. This means a single USB-C cable from the UGREEN charger into the hub powers both, the laptop and any peripherals plugged into it. As a side effect, the hub also makes the StarBook feel like a docking station setup, where I plug or unplug a single cable to instantly add or remove three USB-A peripherals, Ethernet, and a card reader to/from my workstation. However, having only a single USB-C port in 2026 is nevertheless limiting, which is another reason to move away from the Star Labs hardware. To avoid completely screwing up my posture, I use two 3D-printed laptop stands, with added self-adhesive rubber pads, that raise my laptop’s screen a good ~20cm, as mentioned before . The 20% infill PETg prints are super lightweight yet stable, at least once the laptop is in place. Because the two stands are not interconnected, however, they’re not as stable as one of those foldable metal stands, and I wouldn’t recommend trying to use them e.g. on the little tray table in an airplane. I always bring my mechanical keyboard , because my laptop ’s keyboard, like every integrated keyboard, is absolute garbage. To transport my keyboard, I use the NuPhy NuPack , which is intended as an accessory for specific NuPhy keyboards, but it turns out that the pouch fits a variety of other keyboards, including my Kunai Corne v3 . The NuPack also has a dedicated compartment for cables and accessories, which means I don’t have to dig through my bag to find the keyboard’s USB-C cable. When I’m at a proper desk, I lift my laptop using the two 3D-printed stands mentioned above, and I place my keyboard in front of it. When I’m at a café or in any other place with little space, I place a lightweight bridge made out of plastic on top of my laptop and use my keyboard Sonshi-style . The bridge weighs next to nothing, and is shaped to span the keys of the integrated keyboard without putting pressure on them. To complement this, I run , a small helper that automatically disables the laptop’s internal keyboard whenever my external keyboard is connected, so that I don’t accidentally mash arbitrary keys on the integrated keyboard when typing on the Kunai Sonshi-style . I almost always bring my mouse as well, despite my desktop workflow being 99% keyboard driven. There are websites and some applications (e.g. VMs) that are cumbersome to use with the keyboard alone. My mouse of choice is the Razer Basilisk V3 Pro , and depending on where and for how long I’ll be going, I might also bring the Razer Mouse Dock Pro for easy overnight recharging. On shorter trips, I instead rely on the mouse’s built-in battery, which comfortably gets me through a week of regular use, and recharge it via USB-C from the same charger that powers everything else. I used to carry a portable display with me, but ever since I bought the Google Pixel Tablet I have been using that as a “secondary screen” . While it doesn’t support actual HDMI input from my laptop without additional hardware, I don’t really need that, as my primary use case for a secondary screen is for monitoring data streams, and occasionally following along conversations and videos. For quick data sharing between the laptop and the tablet, LocalSend and Syncthing both run on the same LAN (more on that further down ), and for actual remote control I tend to use either an SSH session in Termux or a VNC client. I am however considering an external display, due to the added screen real estate. While the integrated 14" monitor is okay, my aging eyesight would definitely benefit from having a 16" or 18" display to look at. Sadly, most of those options are still too bulky/heavy to be suitable for the ridiculous weight limitations air travel has these days. By using the tablet as an “external monitor” , the device doubles as a backup just in case anything should ever happen to my laptop. Since Android 16, the operating system mimics a desktop well enough for me to be able to work with it in case of emergency. A true portable monitor would be bigger and maybe even heavier than the tablet, yet wouldn’t work independently of the laptop. Given how most hotels and Airbnbs these days have TVs with HDMI input, however, finding a dumb output in case of display failure is easier than finding a computer to work off of temporarily. Note: Having all that said, I’m getting increasingly frustrated of Google ’s garbage hardware and, in particular, the Google Pixel Tablet . Its lacking performance has rendered the device almost useless for many serious tasks, apart from pure media consumption. Even navigating through somewhat packed Grafana dashboards (with auto-refresh) has become painfully slow these days. Hence, I am seriously reconsidering this piece of hardware long-term and I probably wouldn’t recommend it to anyone for more than just media consumption at this point. While I don’t consider myself an audiophile, I do appreciate the difference that decent gear makes once you’ve spent a few years collecting music in lossless formats. To not waste all those FLACs on the (mediocre) DACs of my laptop or my phone , I bring along an iFi hip-dac3 , a compact USB DAC and headphone amplifier. The device handles PCM up to 384kHz and DSD256, has both a 4.4mm balanced and a 3.5mm single-ended output, an XBass+ switch for low-end emphasis, and an XSpace switch that simulates a more open soundstage. I usually pair the hip-dac3 with my phone when on the go, or with my laptop when at the desk, to listen to my self-hosted Jellyfin music library that lives on my Ultra-Portable Data Center . Beyond the sound quality improvement, the hip-dac3 also lets me avoid Bluetooth, which I generally distrust security-wise and which I’d rather not blast at my head for hours every day. Lower-end Bluetooth headphones combined with Android also tend to produce occasional disconnects and audio glitches when running LDAC , which is something I don’t want to deal with anymore. Battery life on the hip-dac3 is solid enough that I can leave it on the desk for a full work day or carry it around for an entire flight without having to worry about it dying mid-track. And when I do need to top it up, it charges via the same USB-C source as everything else. For video, I often carry the EVGA XR1 Pro , a USB-C HDMI capture device that turns any HDMI output into a webcam-style USB Video Class ( UVC ) stream. Whenever I need a high-quality video feed, for example for a video call or for content recorded for my (currently inactive) YouTube channel , I plug the HDMI output of either my Fujifilm X100VI or my Sony Alpha 7 III into the XR1 Pro , which my laptop then sees as a regular webcam. The picture quality, optics, and color reproduction of either camera blow any integrated laptop webcam (and any of those overpriced 4K USB webcams ) out of the water, especially in the kind of mediocre lighting one tends to find in hotel rooms. As a bonus, the XR1 Pro also doubles as a fallback display path. As mentioned earlier, in case my laptop’s screen should ever die mid-trip, I can feed the laptop’s HDMI output into the capture device and view it on my tablet via VLC to keep working until I can get the display fixed or replaced. On longer trips, and only on longer trips, I sometimes break my own weight rule and bring along my Teenage Engineering OP-1 . At nearly 600g without its protective gear, it is by far the heaviest non-essential item that ever ends up in my bag , and the only one I let in for purely creative reasons rather than productive ones. When spending months on the road it’s important to bring something fun, and the OP-1 is the most travel-friendly synth/sampler I own. It’s a self-contained creative outlet that fits on a hotel desk without dragging an entire studio along. The catch is that the OP-1 ’s integrated speaker is, frankly, a gimmick. It is fine for previewing what you just played, but nowhere near good enough for actual listening or for mixing anything down. In practice that means I always pair it with my wired headphones , since I don’t carry a portable speaker with an AUX input that would do the device justice. For transit, the OP-1 lives inside a Decksaver TE OP-1 Cover , which itself sits in a dedicated Teenage Engineering Large Duty Bag , both of which add roughly another 170g on top. The OP-1 unapologetically fails the calculated use test by any rational metric, but it earns its spot purely through the joy it brings me on long trips. Networking is probably where the modular aspect of my travel setup shines the most. Just as with the rest of my equipment, every networking device can function on its own and remains useful in different combinations. Depending on whether I’m hopping between places or settling in city for a longer stay, I might bring only the bare minimum (just my LTE router, acting as a hotspot), or my full setup that consists of a dedicated mobile WiFi router, an Ethernet switch, and the Ultra-Portable Data Center . The thinking here is the same as with the rest of my equipment. I want to be able to recreate as much of my home area network as possible, in any location, while still having the flexibility to leave parts behind if they don’t make sense for the trip. Tethered hotspot at the airport? Just the LTE router. Hotel room with mediocre WiFi for a few weeks? Add the WiFi router, the switch, and the UPDC . The key is that these devices are configured and wired up the same way regardless of where I am, which means I never have to mess with configurations on the road. The setup just extends , like LEGO . For mobile data I’ve been carrying the Netgear Nighthawk M2 for several years now. The device is a 4G / LTE-A Cat. 20 router with a built-in battery and a small color touchscreen, and despite being almost seven years old at this point, it still holds up for the most part. When I’m out and about, the M2 acts as a straightforward mobile hotspot, providing connectivity through its own WiFi to my laptop , phone and tablet . When I’m settled at the travel desk, however, the M2 connects as a client to whatever WiFi the venue offers (be it a hotel, an Airbnb, or a co-working space) and re-shares that connection to my mobile WiFi router via USB tethering. Because of how the WiFi router is configured, plugging the M2 into it automatically disables the M2 ’s WiFi hotspot and switches it into tethering mode , where it acts as a USB Ethernet device. The mobile router then load-balances WAN traffic between the venue’s WiFi (making the M2 a WiFi client) and the M2 ’s LTE connection, which gives me a fairly resilient internet uplink without having to fiddle with any settings. Additionally, both WiFi networks, the one of the M2 and the one of my mobile WiFi router, are configured in the same way, so that clients don’t even notice the switch. The Netgear has, however, started showing its age in the past year or so. It has begun crashing and rebooting at random, and reports increasingly nonsensical battery charge percentages, which I’m fairly certain is due to the now almost 7 year old internal battery, which is user-replaceable but seemingly very hard to find. In addition to the battery, the touch buttons on the device have also started malfunctioning, with presses not being registered most of the time. As I begin to lose trust in the device, I’m in the process of replacing it with the GL.iNet Mudi 7 ( GL-E5800 ). The Mudi 7 supports 5G NSA/SA , multiple SIM/eSIM cards, and runs OpenWrt with GL.iNet ’s firmware layer on top, much like the Slate 7 I’m already using. Multi-SIM in particular is interesting for me, as it lets me keep separate SIMs for different countries or carriers active simultaneously, without having to physically swap cards every time I cross a border. That said, I’m skeptical about how the Mudi 7 will perform when it comes to battery runtime. 5G modems and the more sophisticated hardware around them will inevitably draw significantly more power than the Nighthawk does. Also, the device is clearly heavier and more bulky than the M2 , which is going to be a significant downside. Given its importance, however, it is a trade-off I’m willing to make. Time will tell whether the Mudi 7 will turn out to be a worthy successor, or whether I’ll have to keep the M2 on life support a little longer until something better comes along. The centerpiece of my travel network is the GL.iNet Slate 7 ( GL-BE3600 ), a Wi-Fi 7 dual-band travel router that weighs a mere 295g and is powered via USB-C PD . I covered the device in detail in its own review not too long ago, so I’ll keep this section brief. The Slate 7 replaced my long-running Linksys WRT3200 ACM as my primary router, mostly thanks to its compact 130×91×34mm form factor, dual 2.5 GbE Ethernet ports, USB-A tethering input, and the convenience of being able to power it directly from the same UGREEN charger that powers everything else. The built-in touchscreen is a nice extra, as it displays connection stats, VPN status, and a QR code for quickly joining the network from any device. The router runs an OpenWrt 23.05-SNAPSHOT fork with GL.iNet ’s firmware layer on top, which gives me both root SSH access and a friendly admin UI, even if it isn’t a fully vanilla OpenWrt experience. The bigger reason the Slate 7 stays in my bag, however, is that it turns whatever environment I’m in into a familiar LAN. All my devices ( laptop , phone , tablet , UPDC ) connect to the same network regardless of where I am, which means tools like Syncthing and LocalSend work out of the box, Jellyfin playback follows me from device to device, and SSH between machines uses local IPs without any configuration gymnastics. It also means I can run a single WireGuard VPN connection on the router itself and route the entire LAN through it when needed, which is great for circumventing geo-IP limitations on services and similar shenanigans, without having to configure a VPN client on every individual device, including the ones that don’t even support one. Because the Slate 7 only has a single 2.5 GbE LAN port, I usually carry a Netgear GS305 5-port gigabit switch as well. I tend to prefer wired connections wherever possible, both for stability/throughput and for security reasons. The GS305 is unmanaged, dirt cheap, and has been working flawlessly for years, but it has two notable downsides: It tops out at 1 GbE, which becomes the bottleneck in a setup with 2.5 GbE endpoints, and it requires its own dedicated barrel connector cable. I’m therefore looking to replace it with something like the Ubiquiti Flex Mini 2.5G 5-port switch, which matches the Slate 7 ’s 2.5 GbE link, and which can be powered via USB-C , resulting in yet another barrel-connector adapter that I can leave at home. On longer trips, the Ultra-Portable Data Center (v2) always travels with me. The UPDC v2 is a Raspberry Pi 5-based NAS that I built in 2024, replacing the original mini-ITX-based UPDC v1 . The device runs two 4TB NVMe drives in mirrored RAID1 ( ) on top of LUKS, served over the LAN via Samba , Syncthing and Jellyfin , and packs a 4-cell 18650 UPS HAT, a handful of environmental sensors and a small LCD into a 3D-printed cube that weighs about 800g (with the optional stand) and measures 114mm a side. It is in essence a very compact, travel-ready NAS that I can plug straight into the Slate 7 ’s LAN port and have all my data, services, and music library available on the road, without ever touching the cloud . For a deep-dive into the hardware choices, the enclosure, the migration from TrueNAS SCALE , and the full software stack, please refer to the dedicated UPDC post . One major disadvantage of the UPDC , however, is the fact that the Raspberry Pi 5 requires its own dedicated power supply due to its special 5.1V/5A USB-C PD voltage requirements , which most generic chargers and power banks simply don’t speak. This means I cannot share the UPDC ’s power source with the rest of my travel setup, and I have to bring along a dedicated CanaKit 45W USB-C power supply just for the Pi. To make matters worse, despite the dedicated PSU I have never been able to fully get rid of the occasional warnings that show up in from time to time. The Pi 5 is a notoriously whiny little b…oard in that regard, and Raspberry is arguably to blame for it. Performance-wise the under-voltage events have no noticeable impact on my workloads (which are mostly Syncthing , Samba , and the occasional Jellyfin transcode), but they’re a reminder that the Pi 5’s power story isn’t quite as easy as I would expect. The Ultra-Portable Data Center project was a fun thing to build and has served me well, but with more elaborate and truly minimal all-in-one solutions becoming available these days (the Beelink ME mini and the UnifyDrive UT2 being prominent candidates I’m keeping an eye on), I might at some point move away from a self-built solution in favour of something off-the-shelf that doesn’t need a separate PSU. As things stand today, however, the UPDC remains the most travel-friendly option for me, and the only one that gives me an end-to-end open-source storage stack that I fully control. The remainder of my bag is filled with the small connective tissue that holds the rest of the setup together. Whether or not these items come along depends entirely on the length and nature of the trip, but each of them has earned a spot in the lineup the same way the bigger pieces did. The first of these is a small, modular tablet rig made up of two parts. The Lyrcro desktop microphone tripod is, as the name suggests, intended for desktop microphones, but its 3/8" screw thread doubles as a perfectly good universal mount for anything that takes the same standard. What I most often attach to it is the KDD Tablet Tripod Clamp-Mount as well as some no-name ballhead connecting the two items. The clamp holds my tablet (as well as my phone ) securely on top of the tripod and lets me park the device right next to my laptop, at exactly the same height as the screen sitting on top of its 3D-printed stands. The result is a makeshift dual-screen desk that takes seconds to assemble. As a nice side effect, the same little tripod is also sturdy enough to support my Fujifilm X100VI when I want to use the camera as a webcam via the EVGA XR1 Pro , despite being technically rated for microphones only. Next, there is a small organizer pouch full of USB adapters that I keep refusing to leave behind, because every single one of them has saved me at least once. I carry USB-A to USB-C and USB-C to USB-A converters for situations in which whoever designed that particular hotel TV or rental car decided that 2026 isn’t quite ready for USB-C yet, as well as L-shaped (90°) and U-shaped (180°) USB-C adapters that let me plug cables into my laptop or my phone at angles other than straight out , which matters more than you’d think when working off a nightstand or when using a device on a tripod. None of these adapters cost much, none of them weigh much, but each of them turns a potential problem into a non-event the moment it appears. I already mentioned the Razer Mouse Dock Pro briefly in the keyboard & mouse section , but it is worth revisiting here as a true accessory . On shorter trips it stays home, and the Basilisk V3 Pro ’s built-in battery covers me for a week without complaint. On longer trips, however, the dock comes along, both for the convenience of overnight wireless recharging and because, in the rare event the mouse runs flat mid-day, dropping it onto the dock for a few minutes is faster than digging out a USB-C cable. Lastly, my Seeed Studio SenseCAP T1000-E LoRa/Meshtastic card travels with my EDC regardless of the trip. The card weighs next to nothing, lives in the same pouch as the rest of my EDC, and lets me scan for and join Meshtastic communities in whichever region I happen to be in. On a fun day, that means chatting over LoRa with strangers on the other side of a city. On a less fun day, it doubles as a fully off-grid communication device that doesn’t care whether the local mobile network is up, down, or compromised. It’s a small but meaningful piece of the preparedness side of my travel kit, in case anything more serious than the usual hotel WiFi outage should ever happen. What this setup ultimately gives me is the confidence to open my bag in any environment, anywhere in the world, and have a familiar workstation within minutes, all without having to check-in one of Pelican ’s SuperMAC rack mount cases. Instead of a compromised version of my home office, I get a fully-featured, modular workspace that scales from a single laptop on a plane’s tray table all the way to a multi-device LAN with NAS, capture hardware, and high-fidelity audio in a hotel room. Every component has been chosen, replaced, or rebuilt over the years, sometimes more than once, with weight, modularity, redundancy, and calculated use as the guiding principles. Nothing here is in my bag because it looked nice on Instagram , but because it has earned its spot through repeated, real-world use. If there’s one piece of advice I’d give anyone considering building a similar setup, it is the following: Resist the urge to copy someone else’s packing list , including this one. Your own travel patterns, constraints, and physical comfort will dictate what actually deserves to end up in your bag. Use this post as inspiration, but pick each item based on your workflow, your destinations, and your tolerance for carrying things around . The most minimal setup is not the one with the fewest items, but the one in which every item is actually indispensable and useful.

AI UI