SpaceX's mobile strategy is becoming clearly with its latest spectrum purchase, and it might work.
Nice moment in iOS: when you reduce the volume to zero, subtitles come up automatically – and they go away the moment you increase the volume again. This is from YouTube on the iPad, but it appears to be system-wide: (Feels extra meaningful in the face of so many people playing their media on speaker in public these days.)
Listen to this post : Three revolutionary products — you know the line. A wide-screen iPod with touch controls, a revolutionary mobile phone, and a breakthrough Internet communications device. That was how Steve Jobs introduced the iPhone: Today, we’re introducing three revolutionary products of this class. The first one is a wide-screen iPod with touch controls. The second is a revolutionary mobile phone. The third is a breakthrough Internet communications device. So, three things: a widescreen iPod with touch controls, a revolutionary mobile phone, and a breakthrough Internet communications device. An iPod. A phone. And an Internet communicator. An iPod. A phone. Are you getting it? These are not three separate devices, this is one device, and we are calling it iPhone. Today, Apple is going to reinvent the phone. I’ve linked to this snippet before , usually to note how the audience didn’t really understand what an “Internet communications device” was, even though that was the iPhone’s most revolutionary capability. The phrase I’m thinking of right now, however, is “Are you getting it?” Are you getting that messaging — chatbots now, natural interfaces later — is how we will communicate with AI? Are you getting that not only will we not program computers, we won’t use them — AI will? Are you getting that pre-built UI — write once, run everywhere, for everyone — is dead? These are not three separate predictions: this is reality, right now, in 2026. The future is here, even if it’s not widely distributed. Or is it? I wrote on February 18, 2014 that Messaging was Mobile’s Killer App ; I specify the date because I fortuitously published that Article the day before Facebook acquired WhatsApp . My thesis was that phones may have started out as convenient information devices, but the killer use case was a very human one: Seven years ago, the computer became pocketable, but the original use cases were about making the passive presentation of information accessible not just at a time convenient to the viewer, but also at any place: the web was now everywhere. Still, it’s only recently that the killer app for this era, when the nodes of communication are smartphones, has become apparent, and it is messaging. While the home telephone enabled real-time communication, and the web passive communication, messaging enables constant communication. Conversations are never ending, and friends come and go at a pace dictated not by physicality, but rather by attention. And, given that we are all humans and crave human interaction and affection, we are more than happy to give massive amounts of attention to messaging, to those who matter most to us, and who are always there in our pockets and purses. Meta’s WhatsApp acquisition was actually a step back in ambition; a year earlier the company had launched its own interface for Android called Facebook Home; CEO Mark Zuckerberg told Wired at the time: Home turns your phone into a Facebook device. Even with the lock screen on, a photo stream of your friends’ activities fills the screen. Updates appear on your home screen, too. What’s more, Home makes Facebook the primary means of communication on your device. The company’s messaging software merges with SMS, and you can continue using its “chat heads” to text while inside another app. Zuckerberg believes that the social network plays too big a role in its users lives to be drowned out by a vast sea of apps. “Apps aren’t the center of the world,” he says. “People are.” I stridently disagreed, writing in Apps, People, and Jobs to Be Done : Apps versus People. According to Zuckerberg, that’s the dichotomy. And he’s wrong. He forgot about jobs to be done. Here are my (carefully curated) home screens: Focus on how many of the icons are about “People”…four in total across three screens. People matter to me, but I use my phone for so much more. So what if I consider “Jobs to be Done”?…Total tally: 151 apps, 80 jobs to be done, 4 foci on people Apps aren’t the center of the world…But neither are people. The reason why smartphones rule the world is because they do more jobs for more people in more places than anything in the history of mankind. Facebook Home makes jobs harder to do, in effect demoting them to the folders on my third screen. Who is Facebook to prioritize my jobs? Those screenshots show 151 apps; today my phone has 689. No, I rarely open most of them, but hey, if I again need the random app I downloaded for whatever reason in the past, it’s there. More generally, those numbers speak to what the iPhone and the App Store made possible: customized interfaces for a whole host of activities that were previously inaccessible on the go. Still, the core set of apps has remained remarkably consistent: messaging apps, including WhatsApp, social media, primarily X, and now ChatGPT and Claude. I got a new app yesterday, inspired, coincidentally enough, by a WhatsApp group chat. I have been all-in on agents for a while. First coding agents, then an overall idea tracker agent I fashioned from a dedicated Claude thread, and most recently an agent specifically tuned to my company’s needs. It was that experience that made me instantly excited about Muse , which actually gave people the infrastructure necessary to have an agent of their own. The key thing to understand about agents is that they are not just AI: they are an AI that has access to a computer. It was clear very early on in the ChatGPT era that AI would not replace computers, but rather operate them; from 2023’s ChatGPT Gets a Computer , on the occasion of ChatGPT adding plugins, including one from Wolfram|Alpha: The fact this works so well is itself a testament to what Assistant AI’s are, and are not: they are not computing as we have previously understood it; they are shockingly human in their way of “thinking” and communicating. And frankly, I would have had a hard time solving those three questions as well — that’s what computers are for! And now ChatGPT has a computer of its own. The idea was not that probabilistic LLMs would somehow become deterministic, but rather that LLMs would be able to leverage deterministic computers to do computer things; that’s exactly what an agent does, augmented by its ability to write things down . It follows, then, that to actually deliver an agent that is usable by people unable or unwilling to set up a computer for their agent, you have to give people not just an agent but also a computer for their agent. This is why the aspect of the Muse launch I latched onto was not the Muse Spark model that undergirded Muse, but rather the fact that Meta was provisioning every user in the U.S. (and presumably, eventually the world) with a virtual machine with a 2-core processor, 8GB of RAM, and 8GB of storage. That’s a real-deal computer , which is pretty remarkable, and also the only way to make agents work for most people. Of course the question remains what you actually use this computer for, which is where my new app comes in: after hearing about how a friend used Muse to look at his Instagram favorites, I asked Muse: Can you organize all of the recipes I’ve saved in Instagram? After first delivering a PDF (“Hmm, a PDF isn’t very useful. You can’t store them in a more accessible format?”), I got myself a new app: It took 5 minutes, and the entire conversation took place while I was walking my dog. The app’s not perfect: right now it’s really a way to categorize Instagram videos; I asked Muse to actually read the captions and watch the videos; it’s working on it, subject to Instagram rate-limiting: I can be patient; I have 689 other apps to look at in the meantime. Of course I’m not going to do that; in fact, the number of apps I look at are plummeting. I understand why the idea of giving agents access to your own computer is scary, but every app with a command-line has been usable by agents for a long time; starting with GPT-5.6 Sol, every app with a user interface was usable too, albeit slowly. Astra made it fast. And, well, that’s it: AI can basically use any app or any website that I don’t want to. And frankly, I’m fine with it. The reason why I had 689 apps was because I had that many services or games that I did, at least at some point, want or need to interact with; all of them required learning how they worked to get done what I wanted to get done. That, after all, was the point: I’m not a professional app user, I’m just someone who wants to get things done. And AI gets it done. I framed my new Muse-built Recipe Box app as number 690 on my phone. In fact, however, it represents the infinite app: the agent of my choosing can create any app that I want on command, even if that app is only for me. This is the earliest manifestation of another future that has been clear with the rise of LLMs: truly customized UI. From 2024’s The Gen AI Bridge to the Future : This is where you start to see the bridge: what I am describing is an application of generative AI, specifically to on-demand UI interfaces. It’s also an application that you can imagine being useful on devices that already exist. A watch application, for example, would be much more usable if, instead of trying to navigate by touch like a small iPhone, it could simply show you the exact choices you need to make at a specific moment in time. Again, we get hints of that today through deterministic programming, but the ultimate application will be on-demand via generative AI. Of course generative AI is also usable on the phone, and that is where I expect most of the exploration around generative UI to happen for now. We certainly see plenty of experimentation and rapid development of generative AI broadly, just as we saw plenty of experimentation and rapid development of the Internet on PCs. That experimentation and development was not just usable on the PC, but it also created the bridge to the smartphone; I think that generative AI is doing the same thing in terms of building a bridge to wearables that are not accessories, but general purpose computers in their own right. Last week’s Meta Connect was, as it is every year, about new Meta devices, primarily glasses; what was notable about this year, however, was how Muse made everything make sense. Meta’s devices are not AR or VR devices, or even AI glasses: they are Muse delivery mechanisms. Indeed, the general purpose computer I was talking about exists: Meta gave it to every user for Muse to use. And, as we saw with my recipe box app, generative UI is here. No, it’s not the just-in-time UI that I do still think is coming, but it’s certainly on that path: I had custom UI generated just for me, with no need that the app be shared with anyone else. It’s effectively disposable, because it’s infinite. This is a replay of what happened with websites. Publications used to be scarce, dependent as they were on printing presses and delivery trucks; then, distribution became free, and the web became abundant. That, by extension, meant the most important problem to be solved was discovery; the companies that solved discovery aggregated demand, giving them power over suppliers, and in the case of Meta and Google in particular, incredible advertising businesses (this is Aggregation Theory ). What remained scarce, however, was actually doing things on the web, or in apps. What is happening with agents is that the ability to do stuff is becoming abundant; what is scarce is volition. The problem to be solved is not discovery, but rather inspiration; the companies who solve inspiration will gain power over every entity that has things that need to be done. Once the user is focused on solving a problem, every app and service required to do so is abstracted away into an implementation detail, mere suppliers facing the fate of publications under Aggregators, scrapping for crumbs from the Agent, the ultimate gatekeeper of not just user demand, but desire. From The Verge : After teasing its new Copilot “super app” last month, Microsoft is officially unveiling it today. The redesigned Copilot app bundles three AI capabilities into a single interface of chat, coding, and agents…The Code tab is the surprise addition to this so-called “super app,” and not one you’d typically associate with an app designed for knowledge workers. It will let anyone create an app, tracker, dashboard, or automation and share the results with colleagues as cloud-hosted internal apps… Autopilot is a new addition to the Copilot experience, and one that [Microsoft VP Jared] Spataro describes as a “digital teammate.” Previously called Scout and available initially as a desktop app, Autopilot is the cloud equivalent that enables a personal AI assistant to keep running while you’re asleep. Like many other AI agents, Autopilot has its own cloud computer instance that can be tasked to do things like watch Teams channels, run recurring work tasks, or handle follow-ups. The real difference against some other AI agents is that Microsoft has made Autopilot enterprise grade, appealing to businesses that rely on its Office and identity management suites. “Autopilot lives in your tenant with its own identity, memory, computer, and workspace, and it’s built on Microsoft IQ so it understands how your organization actually works,” says Spataro. “It shows up where people already work — Teams, Outlook, chats, channels, and documents — so you can @mention it like a colleague, with permissions, audit, and governance behind it.” Satya Nadella made clear on X that Microsoft’s strategy was the same as it ever was: be the OS for work. We’re building Copilot as a new OS for work that spans every model, every form factor, and every task. Today, we’re announcing our biggest update to Copilot to date, bringing four things together: · Autopilot: proactive and long-running agent built for the enterprise · Code:… pic.twitter.com/W2ClHHkCK3 I wrote years ago that the best way to understand Teams was as Microsoft’s OS for SaaS; the new Copilot is the obvious new iteration of that. The point has always been to own the interface, and to force everyone else to integrate into that interface on your terms. To that end, it’s not a surprise that the new Copilot isn’t dissimilar to Muse — note that bit about Autopilot including its own cloud computer instance — just with all of the enterprise controls you would expect tied into it. This is the new prize in technology, and it is the ultimate one: not just a platform like Windows, or an Aggregator like Facebook. What Muse and Copilot are making a bid to be is both: the only interface you need for everything, using a computer on your behalf, and generating whatever UI you need when you want it, and doing stuff without you but for you the rest of the time. What is weird about writing this all down — and why I come back to Jobs’ “Are you getting it?” — is that if you are actually using agents, all of this is very obvious. And yet, so many are not, which raises the question as to whether they ever will. I think, in the fullness of time, the answer is yes: no one wants to use apps because they are apps, apps were just the vehicle for people to accomplish something or entertain themselves; once people realize they can get straight to the job to be done it will seem odd they did it any other way. Meanwhile, definitely no one wants to use enterprise UI; those inscrutable interfaces were just the way to expose arcane functionality and lock people in. Once people realize they can simply say what they want — and that, with computer use, you don’t need to depend solely on an underdeveloped and intentionally limited API — it will seem barbaric they did it any other way. Some enterprise companies can see this future coming. I watched the most recent Dreamforce with interest : Salesforce is going to try and charge a three-digit premium to make their flagship product a Claude plugin; I salute the audacity of the cash grab in the face of computer use that will ensure the Salesforce UI is never interacted with by a human again. What will draw the most attention, however, is the fight to be the agent users talk to. Models are relatively substitutable; agents, however, operate better the more context they have about you, and the more access they have to things like your logins and files. That increases their stickiness, and thus the stakes: most people and companies will only have one agent, not multiple. The challenge everyone else will face is that the two companies first out the door with agent products that actually fit the use case — broad exposure to a person or employee’s life and environments, established messaging services, a computer per agent, etc. — are the two companies who have distribution and experience leveraging it. Meta reaches nearly every person on earth; Microsoft reaches nearly every employee. The future may be distributed more rapidly than you expect.
I don't think there was any official announcement, but I'm pretty sure Microsoft is secretly trying to trick you into using Edge. Well, it has always been trying to trick us, but this time it's even more aggressive. You can no longer tell Edge from Chrome. Just go ahead and try. Just last week, I wrote about Edge trying to get users to launch it automatically at boot time . Shortly after, I noticed that Chrome was asking for the exact same thing. Today, I clicked on the weather app on my Windows machine, and of course it opened Edge and asked me to set it as the default. I dismissed the popup and noticed that the website was pushed down from the top by another browser message, this one asking to transfer my data from my other browser to Edge. Bring your favorites, passwords, history, cookies and more from other browsers each time you browser in Microsoft Edge. I visited a few other pages and saw a bunch of ads, which reminded me to switch back to Chrome. I did, but I noticed something odd: when I tabbed between the two browsers, I couldn't tell which was which. Can you tell the difference I know they are both built on Chromium, but until fairly recently Edge had a distinct Microsoft look. It seems Microsoft is aggressively pursuing the fight for the front page of the internet. On my mobile device, I use the Outlook app for one of my email accounts. I noticed that when I click a link, instead of opening it directly in my browser, the app asks whether I want to open it with Microsoft Edge. Note that Edge isn't even installed on my device. Microsoft is trying every tactic in the book to get in front of the user. The front page of the internet is still the only race that matters for large tech companies. It doesn't matter whether your product is good or bad; your success largely depends on how many eyes you can get on your app. Google owns prime real estate. It is the default search engine on most desktop browsers. It is the default on all Android devices, with a negligible margin of error. It is the default on all iOS devices, for a cool $20 billion a year. And of course, it owns the largest ad network in the world. If Microsoft owned the front page today, it wouldn't be able to monetize it as well as Google does. It's one thing to own the front page; it's another to consolidate data from every branch of our web activity. For example, if I look up a product on YouTube on my TV, Google can later retarget me with an ad for that product while I'm reading an article on my iPhone. Microsoft has little to no presence on my iPhone. This mesh of front pages is what makes it worthwhile for Google to be the front page on every device. Even OpenAI has started tracking user web activity outside its own website in an effort to better monetize its position. Google continues to win even though its language models don't top the benchmarks and are often beaten by much smaller models. Meanwhile, Microsoft still doesn't have a model to its name, so it is trying to look enough like Google that people won't notice. Google Search and Bing Search play with the same theme. PS: It was a challenge to take screenshots for this post because half the time I didn't know which browser I was using. PS2: Edge makes it so hard to navigate between browsers because it puts each browser tab you open in its own ALT+TAB menu.
In response to a previous post , one of the readers wrote this: I would phrase this as the fault of the animation having violated the Hippocratic oath for animations, which is “first, do no harm” a.k.a. “first, don’t interfere with user input”. Yes, one has to be afraid of hyperbole – was there ever an onscreen transition that saved a life? – but there is something I really liked about this phrasing. After all, most transitions and animations are decorators, and every transition and animation is, by definition, also a delay . Here’s Shazam as I open it, and overlaid are my frantic taps as I’m trying to make it start the song recognition process: It’s a cute cold start animation, but: What’s particularly frustrating here is how Shazam is being used. On the other end of this whole flow is a song that might already be fading out – timing myself, a user, can’t control – so time wasted on the uninterruptible animation might be seconds separating failure from success. I know it does feel like a blink of an eye when watched out of context, and it is literally just a bit over a second of a delay in the best case scenario, but I wanted to share it as a general example. I believe these seconds add up, especially in a stressful moment, on an older device, repeated many times a day, across different apps… or all of the above. (My go-to example: Imagine your keyboard keys reacting with a second of delay!) At least, I should compliment Shazam for not making another mistake: after the recognition starts, tapping the same button doesn’t cancel it – instead, you have to tap a close box in the corner. Here, the designers realized I might actually be slamming the big button many times over, and I shouldn’t be punished for it even more. It’s not interruptible, like animations should be. It doesn’t even buffer the taps, so – in case the animation covers for something truly uninterruptible, like loading from the cloud – I can’t simply tap and forget, but instead have to wait and tap after it’s done animating.
You can tell how tired someone is of the always-online life pretty easily. When they get home, watch the distance between the phone and the body. The people who love being connected never let the thing leave them be it pocket, palm, face-down next to the fork. Everyone else sets it down the way you drop a heavy backpack after a long day of walking. My wife does not set her phone down so much as launch it. From her hand to the far corner of the room, the phone travels from indispensable to litter in under a second. For my part, I've come to resent the smartphone, which is an embarrassing thing to admit, because I used to be a believer. I researched every new model. I switched between iOS and Android just to taste each new future as it arrived. I lined up for the first iPhone at 3 a.m., stood in the dark to get a glimpse of the thing itself. I remember being genuinely moved when the Apple Store employees clapped for me. In hindsight this is mortifying, roughly on par with the year I dyed my hair blonde and shopped at Hot Topic. We used to have passionate arguments about whether iOS or Android was the future. Sitting here right now, I cannot tell you which model of iPhone is in my pocket. I can't name a single reason I'd upgrade, except that eventually the battery dies, and I don't feel like swapping it myself. Again. It was a dream, for a while: internet everywhere, always. Star Trek made real. I could send an email from a country road. I could read a webpage from a bathroom, which, fine, is where a lot of it belonged. My first computer had no networking at all, and then: dial-up, ethernet, wireless, the phone in my pocket. Each step felt like proof that the future arrived on schedule. These were prized possessions. You cherished them. You had feelings about the merits of one versus another. Now the smartphone is a tax. I get to choose my tax collector be it Apple, Samsung, Google, Nothing, Fairphone, but I don't get to choose whether to pay. In Denmark I'm expected to carry the Aula app for school, the Rejsekort app for trains, MitID to prove to the state that I am me, and e-Boks for official messages from the government and its authorized friends. I need the thing at the airport, at the hotel, at the gym. All of this, I'm told, is a choice. I "choose" to take part in the digital economy. It isn't a choice in any meaningful sense. It's compliance. It's the one physical counter open Tuesdays from 10 to 12, and the ticket machine that no longer takes cash. And the offline option exists the way the wheelchair ramp exists at certain train stations: installed after the fact, satisfying a regulation, pitched at an angle no wheelchair on earth can climb. We are all expected to pretend grandma can make it up, and to act only mildly surprised when we find her at the bottom again. So every few years I buy the identical slab of metal and glass. I admire the color for a moment, because color is the only decision left to make. The last honest pleasure in a new phone is peeling the plastic film off the screen after which the box contains nothing of interest. I put the slab in a case so durable I never see the color again, restore from backup, and everything the old slab knew migrates, whole and continuous, into the new one. A soul transfer, over Wi-Fi, in ninety seconds. I feel nothing for the old slab, despite years of daily intimacy. I hand it off or sell it and never think of it again. I understood something had gone wrong in me the first time I dropped the phone and didn't mind. I was standing in my living room, mid-negotiation of a play date over WhatsApp, when an email arrived from my mother and a calendar alert reminded me I'd never scheduled the dog's vet appointment. It was as if the phone simply left my hands on its own. It hit the floor with that specific thonk of expensive object meeting laminate. When I picked it up and saw that the screen had survived, I was a tiny bit sad. After that, I couldn't stop seeing everything I hated about the thing. It was like the last months of a relationship, when everything the other person does induces fury. Why am I out of storage? I don't control the size of the apps that install themselves, or whether my photos are kept at full resolution or quietly compressed into nothing. I'm not allowed to control any part of the experience, so I don't consider the disk space my fucking problem. Apple pings me, yet again, about my three complimentary months of Apple Music. I open the App Store and find an endless sea of garbage with ads floating on top of the garbage, developers screaming for attention on the burning trash river that is the iOS App Store in 2026. My maps have ads. My apps have ads. Many of the ads are for installing more apps. My podcast app shows me an ad for a podcast about digital detox. I get on my bike and start a podcast. The first thing I hear, at maximum volume, is a Danish advertisement for a new kind of sandwich bread. Then I learn about the grand opening of an electronics store at a mall near me. As I round the corner and join the mob of Danish cyclists, furiously ringing their bells at tourists, the hosts remind me I can subscribe to the premium edition of the podcast. I long for the days of driving through the night with AM radio, where at least the ads were interesting. I have come to actively hate this rectangle of annoyances. It is a rectangle I carry from room to room and charge every night so it can go on notifying me, on behalf of applications I was forced to install, because somebody's OKR that quarter was "increase app installs by 15 percent." I don't need to know about the AliExpress sale. There is always an AliExpress sale. To keep from subconsciously smashing the current slab and having to buy its successor, I started leaving the phone by the front door, next to where I stack the garbage. But the fatigue found me anyway. I'd sit down to play something and get hit with a dozen download prompts. The Steam Deck is always downloading something, or trying to. Streaming has ads now, or else the show has quietly gone missing. My wife and I say insane things to each other, like, "Which app had the show from last week?" HBO counts it off — "ad one of seven" — then detonates sports-betting commercials at maximum volume, until whatever fragile interest I had in the show dies of exposure. There is an incredible sameness to all of it. Everyone online speaks in the same broken loop of the same ten phrases. Every streaming show (except, weirdly, Apple TV+, and who called that) is written as though I'm the stupidest person alive, plot beats arriving on schedule, like a waiter screaming the order at a customer with a head injury who has already nodded twice. Emily in Paris is on: the story of an American woman trapped in a Parisian time loop. She's with the French chef. Now she isn't. Now she is again. Different dress. Compared to what's arrived since, poor Emily is Shakespeare. For short-form, TikTok offers a stranger's very confident opinion of an article they did not read. Instagram offers puppies and softcore pornography. For the long-form connoisseur there's Twitch, the premier cyber-dystopian hellscape, where a woman in a bathing suit films herself in a windowless room for twelve hours a day, or a man with nineteen subscribers sits in a sad home office on patchy carpet pleading, "Guys, come hang out with me!" I lingered once, out of a guilt I still can't locate, and he read my username out loud and welcomed me by name. I wanted to scream, not at him, but at the sheer horror of the situation. The snake has begun eating itself. Netflix has shows about TikTok stars running their social-media empires. HBO has a murder documentary where most of the commentary is social-media clips of people theorizing about the murder. It's a closed loop. Soon we'll produce the documentary while the original event is still happening. Whatever hope I had for the internet is long dead, and I've made a shaky peace with most of what killed it. We persist anyway because I can't retire and wouldn't have anything to do if I did. For me: a bare circuit board. I still like playing with tech, I just need something contained. I need something where I can just engage with something that doesn't involve a million hooks and attempts to get me to do something else. I'd heard the MiSTer was the best way to play old video games. There are a million ways to play old video games now, and that's sort of the problem. Most "retro" devices come with fourteen million games preloaded, which means you play none of them. My whole session becomes scrolling an infinite menu of things I half-remember from the backs of comic books, dipping in and out, retaining nothing. What I wanted was fewer choices. Something that stays offline. So I ordered one. Setup was easy: flash an SD card, run an update script, copy over the games. Then I pulled the ethernet cable out, and it kept working exactly as before which is both the entire point and, in 2026, a minor miracle. There is something deeply liberating about owning one object that does not attempt to walk me through an onboarding flow. No EULA. No cookie consent. From my television to my goddamn refrigerator, everything else in my life is clawing its way onto the internet. The MiSTer just sits there and does the job. The refinement that made it click is TapTo or Zaparoo, depending on how old the website you're reading is. It's an NFC card system that allow for basically a physical shortcut to the game. Tap the card, the game loads. It sounds like a gimmick but it is actually the secret to why the whole thing works. It's the difference between scrolling a menu and picking a cartridge off a shelf, and it finally scratched the itch. (Time Extension reviewed it here: [ link ]. If you want the full rundown on what a MiSTer is and how it works, RetroRGB is the canonical source: [ link ].) The short version of what the MiSTer does: software emulation is a very good impressionist doing an SNES. FPGA is reincarnation with the original chip logic rebuilt, cycle-accurate, no frame skip, able to drive a CRT if you happened to keep one. Is it objectively better than emulation? Who cares. Every slowdown, every piece of weirdness, belongs to the original game and not to some setting I need to go find. I do not open menus. The end result looks like this (not my actual unit — I dropped it and cracked the plastic so: imagine this, but worse): The first game I loaded was Crash Bandicoot for the PlayStation. When I played it as a kid, it was a technical marvel. It is hard to overstate how Crash looked and felt, coming from the Genesis and the NES. PS1 games in general have a soothing grammar, because they assume nothing. They know you rented this from a Blockbuster on a Friday night, that the manual is missing, and that you need to understand the game inside of thirty seconds. Each Crash level introduces exactly one new thing, shows it to you up front in a low-stakes loop, and lets you figure it out. It starts easy. Then the mechanics stack, and stack, until the jumps demand something close to pixel-perfect, and I notice I'm leaning forward on the couch, fully dialed in to the triangle-headed marsupial. It puts me back in the arcade at the mall a town over from my house. My dad would drop me off at the Defiance mall, which had a small arcade near the movie theater, across from the Chinese food stand in the food court. We'd line up in the dark for a shot at one of the Street Fighter II machines, quarters stacked on the bezel to call the next game. The carpet was always weirdly sticky. The joysticks were still sweaty from the last failed challenger. The mechanics of that era were simple, but you had to execute them perfectly, in public. After a few hours I take a break. I pause the game and leave the box running, and hours later I come back to find everything exactly where I left it. No session expired. Nothing has decided I need to log in again. It just keeps humming, the little fan I installed purring away. It exists to keep doing the thing I asked it to do, and it has no other ambitions. When we first got computers, this is simply what they were. By default they did nothing. They sat there and waited for you to have an idea. My old Macintosh LC II would basically wait around for inspiration to strike, or for me to waste an afternoon opening and closing folders, because software was expensive and folder-clicking was free. They felt like tools, not toys, and (ironically) the reason we knew how to do anything on them was that we spent hours poking around System 7, figuring out where everything lived. They crashed. Often, if we're being honest. But nothing in that machine wanted anything from me. Is the MiSTer perfect? No. It's a board engineers test things on, and the software is flawed in exactly the ways you'd expect software like this to be flawed. The UI is clunky, pairing your first controller sorta sucks, and at no point has anyone optimized my experience. But it exists not as the physical manifestation of some roadmap I'll be subjected to later, but as a snapshot of a thing that exists on its own terms. Like the LC II, it's a thing designed to do a thing. It sits there with wires dangling out of it, doing exactly that. It asks nothing of me. It knows nothing about me.
= 3x)" srcset="https://unsung.aresluna.org/_media/apple-has-developed-an-unexpected-workaround/1-framed.1600w.avif" type="image/avif"> From The Verge : Apple has developed an unexpected workaround to prevent the iPhone 18 Pro Max from being hit by shipping restrictions on big batteries. There’s a “battery-firmware solution” in place on the new iPhones, according to Apple’s support page , which keeps capacity below the 20Wh limit for single-cell batteries set by international shipping regulations — but this firmware lock automatically removes itself when the device is booted up for the first time. […] If the user needs to send off their phone for repair or resale, the charging limitation can be restored using the “Prepare to Ship” feature, which caps charging to 80 percent for 14 days. This is interesting, and reminds me of a category that should be present on Unsung more often – software fixing the sins of hardware.
I've been running Quartermaster on my phone for months now, watching it grow from a solid Sonarr and Radarr companion into something that's trying to handle my entire homelab in one app. When I reviewed it back in the spring , it was already doing more than most apps in this space attempt. Since then, developer Lewis Egley has shipped an enormous amount of work, and the app is now getting a Docker-based companion tool that changes what it's capable of entirely. I sat down with Lewis, virtually and asynchronously (Lewis as you will find is British and I'm located in California so there is an 8 hour time difference and Lewis doesn't sleep much) over Discord, to talk about where Quartermaster came from, what Companion actually does under the hood, and where he sees this whole thing heading. He was candid about the late nights, the pressure of shipping fast in a space that's gotten suspicious of anyone who does, and what it's like going from a private side project to something with a real user base watching every move. If you want to follow along or dig into any of this yourself, the app is on the App Store and the GitHub repo for Companion is open source under MIT. There's an active community over on Reddit and in the Discord server, which is honestly the best place to catch build announcements before anyone else does. Walk me through your path in tech, how'd you go from where you started to building Quartermaster? It's a very good question and sort of cliché if you will :) The world of computers has always interested me, ever since I was young. I started making little programs as a child using Python, and weird little websites I'd show my friends. At the time, people my age didn't understand, but I did, and that was enough. In regards to my professional career, I started as any other young and hungry tech advocate. I got my study on! I majored in Computer Science and got my diploma, and then I started out in the working world. My first ever job was IT 1st line, a helpdesk position. Looking back, I hated it, but it's the only way in. A true rite of passage for anyone who wants to start. Over the years I started picking up skills and moved quickly into cloud infrastructure, building out cloud environments for businesses up and down the UK. That opened the door to DevOps and ultimately software engineering. I built Quartermaster as a personal project and ran it locally for a few months. Then I was speaking with a few guys on a tech forum and they really wanted to test it. They gave me improvement ideas, I built them, and so on and so on. The app launched on the 3rd of July and I haven't looked back since, just a lot of late nights, haha. Is Quartermaster your full-time thing now, or are you building it around a day job? Believe it or not, Quartermaster is not my full-time job. It is, and probably always will be, a side project. I love my full-time job, the companies I get to work with and the people I meet. It has taught me everything I know and I just don't think I'm ready to turn my back on it just yet. What pulled you into the homelab space specifically? Are you running a big stack yourself, and if so what's in it? One word. Community. The ideas people come up with, and everything in between, is honestly captivating. It's odd, because it's essentially its own ecosystem, and once you're in it, you're in it. I've been homelabbing for around three years and every day I'm amazed by what people do. No matter where you look there's something out there for everyone, a dashboard here, a service there. There just isn't anything quite like it. The stack I run is small compared to some. I have a soft spot for networking, so it's Unifi throughout, switches, CCTV, the gateway. For media I run a 16GB ECC box with a 12TB array, which covers around 60% of what Quartermaster supports. Obviously I have to spin the rest up locally for proper testing. Any other apps, side projects, or open-source work people might know you from? No, lol. Long-time lurker, first time going public. I'm a very honest guy who keeps himself to himself, so opening the floodgates on a project like QM as a solo dev has been a very big learning curve. Your day job took you through cloud infrastructure and DevOps before software engineering. How much of Companion's design, the proxy layer, the tiered access, the whole approach, came out of instincts from that world rather than from building consumer apps? Almost all of it, if I'm honest. The consumer app side I had to learn as I went, but the Companion architecture came out of habits I already had. The clearest example is the Docker access model. A consumer app instinct would be a settings toggle, switch on Docker management, done. What I built instead is a ceiling you set at deploy time. The Compose profile you start with decides the maximum access the process can ever have, and every profile boots into read only regardless. The owner can raise the active mode from inside the panel, but only up to the ceiling they already committed to on the host. You cannot escalate past it from the UI, because the UI was never given the authority in the first place. That's just least privilege, and it's the sort of thing you internalise building cloud infra for other people's businesses. Nobody gets prod write access because a toggle in a dashboard said so. The socket proxy is the same idea. Companion doesn't get the raw Docker socket, it gets a keyed proxy in front of it with its own scoped surface. The other bit that came from that world is being blunt in the docs about what the thing can actually see. Docker inspection exposes container metadata, mounts, network layout and anything sitting in environment variables. A read only mount still means Companion can read that file. That is in the README because someone running this at home deserves the same honesty I'd give a client during a design review. Do you see Quartermaster becoming a full home lab platform in its own right, or is Companion still in service of the mobile app? I don't know yet in all honesty, and I'd rather say that than invent a roadmap. Companion came about because I hit the ceiling of what a phone can do on its own. Some things need something running on the box with real permissions, and no amount of clever iOS code gets you round that. So it started very much in service of the app, and it does that job well. Where it goes from here is the exciting part, because it isn't entirely my call anymore. Open sourcing it under MIT means people are already running it for things I never designed it for, and that's brilliant to watch. It's the whole reason I love this space. You put something out and the community immediately finds uses you'd never have thought of on your own. I'm still careful with the word platform, mind. It carries promises about support and longevity, and I want to earn those rather than claim them. But if it keeps growing the way it has, and I can keep it secure and well maintained, then I'd love to see where it ends up. Right now I'm just enjoying building it. You clearly thought hard about the trust boundary here, the proxy, the hard ceiling, the tamper-evident config. Was there a specific moment or scare that shaped that approach, or was it just discipline from day one? Discipline, mostly, though it came from a very specific realisation rather than a scare. When I sat down and properly thought about what I was asking people to install, it focused things fast. Companion holds service credentials and can be granted Docker control on the host. Get the owner session and you don't have a media dashboard, you've got someone's box. Once that landed, a lot of the design decided itself. That's why the setup transfer is short lived and single use. It's why pairing makes you compare words on both screens before you approve anything. It's why the default install is read only, and anything beyond that has to be a deliberate choice you make at the host level rather than a toggle in an app. The bit I'm most pleased with is that you don't have to take my word for any of it. There's a verification script in the repo that runs the boundaries against a live instance. If you're going to ask people to trust something running on their own hardware, they should be able to check rather than just believe you. Homelabbers are all over the map, some just want Home Assistant, Unraid for media, and Immich for the family photos. Others are running full racks with oddball switch configs, learning Proxmox, juggling Tailscale, Twingate, ZeroTier, Netbird, Netmaker. That's a massive range of technical comfort under one roof. How do you think about serving both ends of that spectrum with Quartermaster, and does that split change how you approach onboarding and documentation? The way I've approached it is that the complexity lives in their setup, not in mine. I don't try to guess how someone's network is put together. I just give them enough ways to describe it that whatever they've built, they can point QM at it. So you get a local address, an optional remote one, a home WiFi pin so it forces local when you're in, reverse proxy domains, Cloudflare Access header sets, custom headers, basic auth, and certificate pinning for self signed setups. Tailscale isn't a special mode, it's just an address, because to the app it should be. Someone on a Synology with three apps uses one field of that. Someone with a rack and five overlay networks uses most of them. Same app, same flow. Onboarding does branch, though not by skill level. It branches by how you're arriving. There's a manual path, a Companion path where the server exports your whole stack and the phone imports it in one go, a demo mode, and a restore path. Then you pick your services off a list, and it walks you through connecting them one at a time, most depended on first. There's very little discovery, which is deliberate. Where I'd say I've genuinely got it right is what happens when a connection fails. The Test is the moment everything hinges on, so that's where the work went. Four stages, real error codes, the server's own refusal text surfaced verbatim rather than swallowed, and one tap fixes for the specific traps, certificate trust, SSH host keys, Synology OTP, a port left prefilled on a public domain. You can't save a service that hasn't passed a Test, so nothing sits there claiming to be connected when it isn't. You mentioned there's very little service discovery by design, and that onboarding branches by how someone arrives rather than their skill level. That's a strong opinion, a lot of apps in this space lean hard into auto-discovery as a selling point. What made you bet against that? Mostly that on iOS it doesn't work as well as the marketing suggests, and the failure mode is brutal. The Local Network permission is a one hot prompt. You get it once, and if the user denies it there is no API to ask again. They have to go into Settings and find it themselves. So if that prompt fires during a background dashboard load rather than something the user deliberately did, the request races the prompt, fails as a generic "couldn't connect", and you've burned your one chance. The app actually fires a throwaway probe when onboarding opens specifically to get that prompt out of the way at a moment that makes sense to the user. Then there's the yield. Bonjour browsing on iOS needs you to declare every service type up front in the app's config, and most selfhosted software doesn't advertise over mDNS anyway. Radarr doesn't. Sonarr doesn't. SABnzbd doesn't. So you'd be building it for almost nothing. Subnet scanning is worse. Hundreds of connection attempts, straight into iOS's six per host limit, and a conversation with App Review about why your media app is port scanning. And a big chunk of these users are on Tailscale or behind CGNAT, where sweeping the local subnet finds nothing that matters. So I moved discovery to where it can actually work, which is a box that already has Docker. Companion reads the container list, works out what's running, and reads the API keys straight out of the config files on disk. The *arrs keep theirs in config.xml, SAB in sabnzbd.ini, and so on. The user types nothing. That's real discovery, it just isn't happening on the phone. Plex is the other exception, and it's the same principle. It's account side, not network side. You sign in and Plex tells you every server on your account with every route, so the app picks the best one. Where a proper API exists I'll use it. I'm just not going to guess at somebody's subnet. A lot of the competition in this space, LunaSea, Zagreus, Ruddarr, Unraid Deck, are unitaskers, they do one thing really well. You told me you're not using AI to build any of this, it's all hand-written. That's a lot of surface area to cover solo without leaning on tooling to move faster. What made you go all-in on the everything-app bet instead of picking a lane and doing it well? Because the unitasker advantage disappears the moment you run more than one thing, and almost everyone in this space runs more than one thing. The bet wasn't really "cover everything". It was that the hard part isn't the services, it's the layer underneath them. Getting a connection to somebody's box is genuinely difficult. Dual local and remote addresses that switch on their own, self signed certificates on iOS, reverse proxies, Cloudflare Access, custom headers, per host concurrency limits, a transport that won't follow a redirect and replay your API key somewhere you never configured. That's about thirteen thousand lines of plumbing, and I only had to write it once. Everything after that is a service riding on top of it. A new integration inherits the URL assembly, the auth handling, the certificate pinning, the reachability engine, the four stage connection test, the add form, the backup and restore, all of it. I won't pretend it's cheap though. A new service is still six to eight thousand lines by the time you've done the client, the screens, the mappers and the demo data (needed for Apple review). There's no plugin system, no manifest, nothing schema driven. It's all compiled in. That's linear cost forever and I knew that going in. What I got for it is that each of the 59 services has a real screen and real actions rather than a generic card. The schema driven approach would have let me claim two hundred services that all look identical and none of which actually does anything. I'd rather have 59 that work. Unraid Deck does almost exactly what Companion does, direct Docker control, SSH, local push notifications, no hosted relay, but it stays narrowly focused on just Unraid. Companion's trying to sit underneath a much bigger app that spans dozens of services. What's the trade-off there, and do you think staying narrow like that is actually the smarter long term bet? Narrow is smarter if you're solving one platform's problem. I'd not argue with that at all, and I think Unraid Deck is doing the right thing for what it's for. Companion isn't Unraid specific. It's a Node app talking to the Docker API, so it works against Proxmox, Synology, bare metal, whatever. Unraid is just the best documented install path because that's where a lot of people are. But that generality has a cost. Deck can make assumptions about paths, about the array, about the whole shape of the system. I can't make any of those, so I end up handling Linux host paths generically, Synology's volume layout, socket proxying instead of a raw socket mount, and so on. The trade off is what Companion is for. It isn't primarily a Docker manager, it's the thing that makes setup disappear. It reads your config files, finds your keys, works out you're running three Radarrs on different ports, and hands the phone an encrypted bundle so you type nothing. That job only exists because there's a big app sitting on top of it that needs 59 services configured. A narrow tool doesn't have that problem to solve, which is exactly why it can stay narrow. How do you decide what to actually support in the mobile app? I noticed Companion now has a marketplace, is that the mechanism for covering more of these different setups without you having to hand-build support for every single one in the mobile app and just let Companion handle it? It's a catalogue generated from Companion's/QMs own supported list of what it knows about. There are exactly three hand reviewed Compose starters in there. Everything else is either generated from a template or connect only. And no, it isn't a way round hand building support. I wish it were, but I'd be lying if I said otherwise. The app's list of service types is compiled in. It's a fixed union in the source, it's a key in dozens of exhaustive lookups, and it's the discriminant the app stores things under. There's a hard boundary on import that drops anything not in that list, with a test asserting it does. So if Companion learns about something new tomorrow, it can detect it, deploy it and show it in the web UI, but the phone will not treat it as a service. No card or even screen and certainly no status probe. That's a build time thing and no amount of Companion architecture changes it. There's one escape hatch, and it's honest about it all, the Companion control plane in the app shows containers, stacks, images and events generically, without knowing what any of them are. So something new turns up there the moment you deploy it. But it turns up as a container, not as an integration. How I actually decide what to support is much less interesting than that. It's what people ask for in the Discord, weighted by whether I can get a real instance running to test against. That last bit matters more than people expect. I pulled up the actual Marketplace in Companion. Right now every one of the built-in entries is first-party, curated by you, and the catalog banner says every deployment still starts with a review. But there's already a Sources tab sitting there, empty at zero right now, that lets people point Companion at external Portainer v2 template feeds, and it says outright those entries aren't reviewed by you. That's a real two-tier trust model already built and waiting. Was that the plan from day one, community sources living alongside your own with clearly different guarantees, and how worried are you about someone pointing that at something malicious? I wouldn't say the exact shape of it was mapped out from day one, but the separation was deliberate once the Marketplace started taking shape. There had to be a hard distinction between something included by me and something a user has added themselves. If it appears in the built-in catalogue, I'm putting my name against it. I've looked at it, I know where the image comes from, I know what it mounts and I know what permissions it asks for. An external source cannot inherit that trust just because Companion happens to be displaying it. And yes, a malicious feed is a real risk. A Compose template can ask for privileged mode, mount the Docker socket, mount the host filesystem or run an image that does something completely different from what its description claims. There is no honest way for Companion to turn arbitrary third-party Compose into something safe automatically. That's why external entries are labelled differently and why deployment still starts with a review. Companion shows you what is actually going to be created before anything runs. It doesn't quietly install something because it appeared in a feed. But I don't want to pretend that removes the responsibility from the person deploying it. If you add an untrusted source and then approve a template with access to your host, Companion can't make that decision harmless. The aim is to make the trust boundary obvious and make dangerous requests visible, not to claim I can sanitise arbitrary code from the internet. You mentioned there are only three hand-reviewed Compose starters in the Marketplace right now, everything else is generated or connect-only, and even if Companion learns about something new, it can't become a real integration in the phone app because the service list is compiled in. So what would "other devs contributing to the Marketplace" actually look like in practice, more Compose starters and Sources feeds on the Companion side, or is there a future where the compiled-in service list itself opens up somehow? Right now it means the Companion side. Other developers can publish Portainer feeds, build Compose starters and help Companion understand how something is deployed or detected. If something is going into the first party catalogue, I still need to review it before it gets that guarantee. Alternatively, somebody can maintain their own source and users can choose to add it with the external-source warning attached. What it does not mean today is dropping a manifest into Companion and suddenly gaining a full Quartermaster integration on the phone. The phone app is deliberately much stricter than that. A service type is compiled into the app and tied into the connection layer, storage, backup and restore, onboarding, demo data and native screens. Opening that at runtime would either require an enormous plugin system or reduce integrations to generic cards driven by a schema. Neither gives me what I want from Quartermaster. So in the near term, community contribution means deployments, templates, detection and knowledge on the Companion side. For the app itself, people can request integrations, help me get a test instance running, document strange API behaviour and test the result, but the actual implementation still has to become part of the app and go through a release. I won't say the service system can never open up, but there isn't a hidden plugin SDK around the corner. If I ever do it, it has to produce something that feels like a real Quartermaster integration rather than a web form wearing an iOS skin. A while back a security researcher found serious auth bypass vulnerabilities in Huntarr , and the maintainer banned people who raised concerns about it. It's become the go-to cautionary tale people point to for vibe-coded apps cutting corners. Has that story stuck with you? Does having something like that out there change how you think about your own pace, or your own security process? It's stuck with me in the sense that I've watched how the community reacted to it, and that told me something useful. People in this space care about this stuff. They will look, they will test, and they'll say something when they find it. What it reinforced more than anything is how you handle it when someone does come to you. If a researcher turns up at my door tomorrow with a genuine finding, that's someone doing me an enormous favour for free. The right response is thanks, then a fix, then telling everyone what happened. Closing the door on that is how a small problem becomes a permanent reputation. On pace, it hasn't changed it exactly, but it's part of why the security model went in early rather than later. It's much harder to bolt a trust boundary onto something after people are already running it. Do it up front and you're building on top of it rather than retrofitting round it. There's a lot of noise right now about "vibe coded" apps, and Huntarr's become the example everyone points to, real security holes, a maintainer who didn't seem to understand what he was shipping. Where do you actually sit on that? Do you use AI tools in your workflow, and if so, how do you keep the line between using them well and leaning on them too hard? I sit somewhere that probably annoys both camps. I don't use AI to build Quartermaster. Not the app, nor the Companion. Where I do use it is checking a GitHub URL for a new integration in case an API's changed and I'd otherwise miss it. That's a research task and it's genuinely useful for that. But I think the "vibe coded" label gets used as a lazy shorthand, and it points at the wrong thing. The tool isn't the problem. You can write every line by hand and still ship something dangerous if you've never had to think about a trust boundary. Equally you could use AI sensibly, review properly, and be completely fine. The real question is whether you understand what you're shipping. That's it. Can you explain what you decided, what it exposes, and what happens if someone attacks it? If you can't answer that, it doesn't matter who or what wrote the code. I'll use it to research and to check my blind spots. I won't use it to make decisions I'd struggle to defend afterwards. I've watched you build this out in real time, and you've even put a verification script in the repo so people can check the security boundaries themselves instead of just taking your word for it, which is the exact opposite of what happened with Huntarr. But I know "vibe coding" accusations get thrown around fast, especially with that story still fresh in people's minds. Does being anywhere near that comparison worry you? Has anyone actually come at you with that kind of accusation, and how do you handle it when the work itself is the real answer? It doesn't worry me, no. If someone wants to lob that at me they're welcome to, but they'll be arguing with a repo that's sat there in the open. The security model was designed deliberately, because I've spent years doing exactly this kind of work for businesses and I know what happens when you get it wrong. Least privilege, a ceiling you set at deploy time, read only by default, a proxy in front of the socket rather than handing over the socket itself. None of that is accidental and I can explain every bit of it. But the strongest answer isn't me telling anyone that. It's that I'd rather nobody took my word for it in the first place. That's the entire reason the verification script exists. Run it against a live instance and it tests the setup and authentication boundaries for you. If you think I've cut corners, that's the quickest way to prove it. The repo's open, the app's on the store. Have at it. You've shared some pretty stark numbers on what the hosted notification relay was actually costing you to run. What made you consider dropping it entirely, and how did you land on moving notifications into Companion as a local relay instead? Did that same cost reality shape the new pricing structure for 1.2, and how did you balance that against keeping your lifetime purchasers taken care of? The relay costs got out of hand, plainly. We're talking millions of requests a day through Cloudflare, and that's not sustainable for one person funding it out of pocket. The fix is Companion. Notifications are moving to a local relay, which means people will be able to set their own alerts and run the whole thing on their own box rather than everything routing through infrastructure I'm paying for. That's better architecturally as well as financially, which is the nice version of a cost problem. It's also more in keeping with the whole point of self-hosting. Your stuff, your box. The 1.2 price change is partly those notification costs and partly everything else that's landed since launch. Companion, the custom built macOS version, all of it. I've kept the increase as small as I can and it'll still come in cheaper than the alternatives. The important bit: every current subscription stays at the price you're on until you cancel, and everyone who bought lifetime keeps lifetime. That was never up for discussion. People backed this thing early, before it had proved anything, and they're not getting punished for it. You mentioned QM is a side project on top of a full-time job, and you shipped an enormous amount of work in eight weeks. What does a week actually look like for you right now, and how close have you come to burning out on it? Honestly? Weekends are soaked. During the week it's evenings after work, and more often than not I'm going to bed around four in the morning. Then up for the day job. That's just been the rhythm since launch. My partner hasn't always been thrilled about it, and I don't blame her. But when I show her what's actually happening, the numbers, the people using it, the messages coming in, she's amazed. That helps. It's my passion, and having someone who gets that even when it's eating the weekend makes a big difference. As for burnout, it's real and I won't pretend otherwise. I make mistakes when I'm running on not much sleep. Things slip through that wouldn't if I'd been fresh. That's genuinely where the closed beta community has been unreal. They catch things and they tell me straight when something's broken. When you're a solo dev at two in the morning, having a group of people who care about the project as much as you do is worth more than any amount of extra hours I could put in. I'd have shipped a much worse app without them. You said this is the first project you've taken public after being a long-time lurker. What's that jump been like, going from something you built quietly for yourself to a real app with a user base and an active Discord community? Terrifying, then brilliant, roughly in that order. Building something quietly for yourself is safe. Nobody sees the bad decisions, nobody files a bug at midnight, and if it breaks it only breaks for you. Putting it out means every choice you made alone is suddenly up for discussion by people who know what they're talking about. That first week I checked everything constantly. What I didn't expect was how generous people would be. I'd braced for criticism and what I got was people wanting it to work. Detailed bug reports, feature ideas better than mine, folk explaining their setups so I could understand why something wasn't behaving. The Discord has genuinely made the app better in ways I couldn't have on my own. The other thing is that it's changed how I build. When it was just mine I could cut corners and know where the bodies were buried. Now there are people relying on it, and that raises the bar on everything. Not in a stressful way particularly, more that it makes you take it seriously. I'm still a fairly private person, so going from lurker to having a community around something I made has been a big adjustment. But I'd not go back. Whatever I thought I'd get out of shipping this, the people have been the best part of it by a distance. I'd just add a closing note on that. Quartermaster is ultimately just code running on people's devices. What actually drives the late nights, the new features and everything in between is the community. They keep me going and I couldn't ask for a better one. There's a stereotype that British people apologize for everything, even when it's not their fault, always "ever so sorry" or "terribly sorry" for the smallest things. You've said sorry in Discord more than once for delays on something you're building for free in your spare time. Is that just very British of you, or do you genuinely feel like you owe people an apology? How do you deal with the pressure of a deadline you set for yourself versus one the community's expecting, and which one do you think has more pressure? Bit of both, honestly. It's very British, lol. When someone clicks purchase, or takes time out of their day to message me about a problem, I think they deserve the best service I can give them. That's not me being self flagellating about it, it's just how I think it should work. They've given me something, whether that's their money or their time, and a delay means I've not held up my end. As for which deadline has more pressure, it's mine by a distance. The community are generous. They're patient, they tell me not to worry about it, and nobody in the Discord has ever given me grief over a slipped date. The pressure is entirely internal. I set a date, I want to hit it, and when I don't, that's on me. Which is probably exactly why I keep apologising for things nobody's actually asking me to apologise for. You mentioned "the custom built macOS version" when talking about what's driven the 1.2 pricing changes, so it sounds like Mac already got real dedicated attention rather than just running the iPad build. What does "custom built" actually mean there, is it a fully native AppKit app, or an iPad app with Mac-specific work layered on? And what about Android or Windows, are those actually on the table, or does it make more sense to lean into a solid web app for anyone outside the Apple ecosystem instead of chasing every platform natively? It's the iPad app running on Apple silicon through "Designed for iPad", with a significant amount of Mac specific work layered on top. It's not Catalyst and it's not AppKit. Shipping it is a checkbox. Making it feel like a Mac app was not. There's a whole separate shell for it, a sidebar, a today column, a desk bar, sat behind a flag with a kill switch. Detecting you're even on a Mac needed a small native module, because React Native reports Catalyst as false in that mode. Then there's window minimum sizing, hardware keyboard shortcuts, and disabling keyboard avoidance in three places because the system still fires keyboard events for the input accessory strip with a hardware keyboard, and the maths for a movable window is completely wrong. There's a good story in there about boring choices too. The sidebar was originally a real UISplitViewController via an experimental router feature. It misbehaved three times in one day during beta (as you know), so I ripped it out and replaced it with a plain flex row. It's less clever and it works. Android and Windows, honestly, not soon. There's more Android scaffolding than you'd guess. Five of the twelve native modules already have real Kotlin implementations. But there are over a thousand icon call sites using SF Symbols with no Android fallback, seven native modules with no Android side at all, and the whole visual language is built on iOS 26 glass. The business logic would port cleanly, because the connection layer and the data mapping are deliberately framework free and tested under plain Node. The presentation layer would be a rewrite. I might even need to bring on a dev to help me, the project has grown that large. 1.2 shipped later than planned, but the delay was actually Apple's review process, not you. What's it like waiting on something completely out of your hands after you've done everything you can on your end? Honestly, worse than when the delay is mine. If something is broken, I can fix it. If testing turns something up, I can stay up late and deal with it. Once the build is submitted and sitting with Apple, there is nothing useful left for me to do. You end up refreshing App Store Connect even though you know perfectly well that refreshing it isn't going to move the queue. The frustrating part was that everybody could see me saying 1.2 was ready, but nobody could actually download it. From the outside, a delay is still a delay, even when the finished build is just waiting for somebody else to press the button. Apple review is part of shipping an iOS app, so ultimately it is still something I have to allow for. The lesson for me is probably to stop treating submission day as release day when I talk about dates publicly. I can control when I finish a build. I cannot control exactly when Apple lets it out. You just announced QM Reader for 1.3, a full request/read/listen experience for books. That's a real expansion beyond media and homelab management. What made now the right time to go there, and how does it relate to the book and audio tools already in the Marketplace, Audiobookshelf, Kavita, Shelfarr? It looks like a jump from the outside, but from inside the app it feels like the next missing piece. Quartermaster already understands the different parts of that stack. Shelfarr is about finding and requesting something. Kavita is about the library and reading side. Audiobookshelf handles audiobooks and playback. They are good tools, but today those experiences still live next to each other rather than feeling like one journey. QM Reader is the layer that joins them together. The idea is that you should be able to find a book, request it through the service you already run, see when it arrives, then read or listen without the experience suddenly falling apart into three unrelated integrations. It isn't about replacing Audiobookshelf, Kavita or Shelfarr. They remain the servers and the source of truth. Quartermaster is the native experience across them. Now feels like the right time because the underlying work is finally there. The connection system, multiple instances, secure credential storage, downloads, media handling and Companion discovery have all already been solved in other parts of the app. I can build Reader on top of those foundations instead of creating another isolated app and asking people to configure the same stack twice. It is a bigger piece of work than adding another dashboard, definitely, but it also feels like the first time Quartermaster can turn several integrations into one complete feature rather than simply putting them beside each other. With Pulsarr, PeaNUT, Uptime Kuma, QM Reader, and a pricing review all confirmed for 1.3, that's a lot on the plate right after shipping the biggest release yet. How are you pacing yourself into this next stretch instead of just running the same sprint again? By trying not to pretend all five of those things are the same size. Pulsarr, PeaNUT and Uptime Kuma are contained integrations. They still need proper clients, screens, tests and demo data, but they inherit the connection and onboarding work that already exists. QM Reader is the large piece. The immediate priority after 1.2 is stability. There is no point announcing the biggest release I've done and then sprinting past every bug people find because I'm already chasing 1.3. I'll deal with the real-world feedback first, then build the next pieces behind TestFlight rather than trying to land everything at once internally. I'm also being more careful about dates. I am very good at turning my own estimate into a deadline and then treating that deadline like somebody else imposed it on me. Nobody in the community is asking me to work like that. That's entirely self-inflicted. So the plan is to keep moving, because I'm obviously not very good at sitting still, but to sequence it properly. Stabilise 1.2, land the smaller integrations, give Reader the time it actually needs and only call 1.3 ready when it is ready. Whether I manage to behave that sensibly for the entire release is a separate question. What are you most excited for people to actually experience once this update is in their hands? The moment Companion makes the setup disappear. People have heard me list service counts and talk about Docker discovery, but the number isn't the interesting bit. The interesting bit is scanning once and watching the app fill itself with the services you actually run, including their addresses and credentials, without spending half an hour copying API keys out of config files. That's the point where Companion stops being another thing you have to manage and starts earning its place. I'm also excited for people to see that 1.2 isn't just a collection of integrations. The app, the Mac experience and Companion now feel like parts of the same system. You can still use Quartermaster directly without Companion, exactly as before, but if you do run Companion the whole thing becomes much more joined up. I've been looking at individual screens and broken beta builds for so long that I'm probably too close to it now. I want to see what it feels like when somebody encounters the complete flow for the first time. Is there anything I haven't asked that you think people should know, or that you've been wanting to say? Probably that Companion being here does not change the original promise of Quartermaster. It is optional. The phone can still connect directly to your services. There is still no Quartermaster account, no analytics profile and no requirement to send your homelab through infrastructure I control. Companion is there when running something locally makes the experience better, not to drag a self-hosted app towards somebody else's Cloud. The other thing is that beta genuinely means beta. I've tried to be clear about where the boundaries are, what has been verified and what still needs real-world testing. I would rather tell somebody a feature has a limitation than quietly let them discover it after trusting it with their server. And, genuinely, the amount of useful feedback people have given me has changed the app. A lot of what is in 1.2 exists because somebody joined the Discord , explained their strange setup and then patiently tested three builds while I got it right. It might be one person writing it, but it has not been built in isolation. Where should people go to follow along, report bugs, or get involved, Discord, GitHub, somewhere else? Discord is the main place. That's where I post development updates, TestFlight builds, feature previews and the occasional message apologising for a delay nobody has complained about. It is also the quickest place to report a Quartermaster bug, request an integration or show me a setup that behaves differently from mine. GitHub is the better place for Companion issues that need logs, reproduction steps or a technical discussion around the implementation. The Companion repo is open, so people can inspect it, run the verification tooling and raise something properly if they find a problem. For security issues, please report them privately first rather than dropping exploit details into a public channel. I will take them seriously, confirm what is affected and be open about the fix. The website and App Store have the polished version of what Quartermaster is. Discord and GitHub are where you see how it is actually being built. What stuck with me most out of all of this wasn't the security model or the thirteen thousand lines of connection code, it was watching someone build in the open and mean it. Lewis is still answering bug reports in Discord at hours most people are asleep, still apologizing for things nobody's upset about, and still building toward something bigger than what fits in one app. I'll be watching what QM Reader turns into, and I'd bet a lot of you reading this already have Quartermaster running somewhere in your stack. If you don't yet, now's a genuinely good time to start. I'd love to hear in the comments what you think about Quartermaster, how you are using it and how friendly we are in the Discord there.
These days, while I’m having more and more difficulties appreciating software in general, I’m getting a lot more joy and delight from tiny apps and little utility programs that offer very few features. In the past couple of days alone, I’ve discovered — or rediscovered in some cases — a few of these that I thought would be worth your time. The first one is History Book , from Zhenyi Ta n (of And a Dinosaur’s fame) that I use as my new read-later app. The twist is that it is not really a read-later app. The app’s purpose is actually to be an alternative to Safari’s browsing history. It vastly improves on it by making the content of the pages visited searchable as well, and not only the title of the page as it is mostly the case with browsers’ browsing history logs. By default, the app will save only pages where an article is found, but it can also be set up to save all pages automatically, whether after a few seconds or after a waiting period. There is a third way to save URLs in this app: by clicking a button the old-fashioned way. This is what I do, and, despite a few bugs, I adopted the app very gladly. You see, I love an app like GoodLinks , but somehow, I find it quite difficult to manage, and maybe over-complicated for my humble needs? Between the read/unread status and the different tag folders, I end up being lost on what I’ve read, what I want to keep, what I need to archive, and what I can delete. In History Book there are just folders, and that’s it. Barely any other setting is available, and I love this purposefulness in an app. Also, and you must have seen this coming if you’re a regular reader , it’s superfast and light (only 2.9 MB). I just wish it had a few comfort updates: Great icon, though. The second app I want to recommend is also from Zhenyi Tan. If this app is harder to recommend, even harder to find a good use case for it, Lucky Notes is probably my favourite app of the year. For starters, this has to be the cutest app for the Apple ecosystem: the icon alone makes it worth keeping the app in the dock, but the overall vintage Mac look is delightful. Zhenyi Tan describes Lucky Notes as an app to save text snippets, and the app is actually a companion app to the Lucky Safari extension , which greatly improves Google Search result pages. Indeed, notes in Lucky Notes are only searchable via the companion extension. The app on its own is more than bare-bones, it’s lacking a lot of basics, even a settings window. But I don’t seem to mind, that’s the crazy part. I’ve spent the last couple of days trying to find a reason to add this app into my setup because it really is an app crush: I want to use it. I’m currently using it as a separate note collection from the ones I store on my Mac via BBEdit, and the ones I keep in Apple Notes as an easy way to have them shareable and synced between my devices. If this app had the following features, I’d consider committing to put all my notes in this: Hard to write a post about tiny utility programs without mentioning one of Sindre Sorhus’s apps ; the third and final app I want to recommend is Plain Text Editor . *2 I’ve recently added this editor to my Mac setup because if there is one thing that’s missing from BBEdit , it’s a proper full-screen distraction-free mode. Plain Text Editor provides me with that, and, most importantly, just that. I’ve liked this app for a while now, but if it’s limited as a main writing app, it’s brilliant as a companion app for first drafts. I used it to draft this very post. The only thing that’s missing is a line-height setting. The app could also use a few fixes when it comes to tiny visual bugs. That’s it: I think any extra feature more would make this program too complex and probably would disqualify it for this “tiny app” category. These three apps, History Book, Lucky Notes, and Plain Text Editor made me realise that I have a soft spot for simple, bare-bones apps. Piezo , Yoink , Tot also come to mind. What I like the most in these apps is the minimal number of things to configure. Coming from a new BBEdit aficionado , this may sound strange, but this feels like plug and play, for apps. Download, launch, enjoy. Despite my strong enjoyment of digging into settings, this is very refreshing and somehow reassuring: reinstalling each of these apps on a new computer is a breeze. What about you, dear reader? I’m very curious to know which tiny little program you’re found of, which are the ones you recommend and why. Please let me know which is your latest tiny app crush. It’s worth noting that in the past couple of days alone History Box received a few updates fixing a lot of my initial issues, forcing me to gladly update this draft a few times. By the time you read this, it’s possible all the things I listed will be covered. ^ Among the other numerous Sindre Sorhus apps, I like Aiko : I purchased it a while ago to use on my work computer to replace MacWhisper (a bit too “power user” for me), and it’s brilliantly efficient and simple. I also recommend Hyperduck . ^ The ability to assign a specific folder to the extension button, separate from the background history saving if enabled Extra metadata on saved articles (not just the time it was saved, but the publication date for instance, author, reading time, etc.) A proper export system, just in case. The current solution documented is a bit messy Extra Mac functionalities like the ability to hide the toolbar, a status bar to preview URLs, better default keyboard shortcut support like Cmd + F for search, etc. *1 a search box without the need for the Lucky extension a text size/line length setting a better resolution system for syncing conflicting versions of a note an option to only use windows instead of tabs (which would feel even more classic Mac-ish). a proper export/backup system. It’s worth noting that in the past couple of days alone History Box received a few updates fixing a lot of my initial issues, forcing me to gladly update this draft a few times. By the time you read this, it’s possible all the things I listed will be covered. ^ Among the other numerous Sindre Sorhus apps, I like Aiko : I purchased it a while ago to use on my work computer to replace MacWhisper (a bit too “power user” for me), and it’s brilliantly efficient and simple. I also recommend Hyperduck . ^
Recently, during a very relaxing holiday in Cyprus, I had a revelation of sorts: my brain was rotting. I know this because I read a lot of books on holiday. It’s the only time I do read books! Well, I did read a lot on holiday, but the last couple of years I really struggled to focus. I used to put it down to “I’m just super tired, man, I don’t have the mental strength to concentrate” but that was probably only a part of it. I struggle to concentrate all the time — brains, innit — but it looks like algorithmic feeds of content, such as Instagram, TikTok and Bluesky (For You feed) have been doing a lot more damage to that existing problem than I thought. I decided to cut loose. I deleted Instagram, TikTok and Bluesky from my phone because I don’t use anything else. The feeling I had, for the first couple of days after that was the exact same feeling I had in attempts to quit nicotine, which was rather concerning. I persisted though, leaning more and more into my beloved RSS feeds whenever I had a pang to pick up my phone and scroll. I get my Bluesky content via RSS too, via a little system I’ve been tinkering with. I don’t like to miss what my pals are up to — especially where there’s an opportunity to signal boost — but I also think there’s value in reading posts from my peers and others. This is serviced well by my RSS setup, so if you see me in your notifications tab, that’s why. When I Log On™ to Bluesky, all I see is this: No surprises here! I’m feeling a lot less ground down and my brain is working much better, only after a week. My phone always has battery too, which is handy. The thing that’s really surprised me is I’m sleeping so much better than I was. I’ve had a hard rule for years: my phone doesn’t come into the bedroom, but even then, my brain was clearly struggling to relax after watching TikTok for an hour or whatever. I’m going to keep going with this to see where it takes me. I’ll miss sending good videos to my pals in Instagram and discovering new music to listen to, but that’s about it. The algorithms on that service, as well as TikTok (since the Americans took over) are really quite shit when you think about it and if you think about it even more, the content you do actually end up seeing really doesn’t improve your life at all. It just fills time. I guess I’m in a pretty fortunate position. I don’t rely on these services for my income so I have the option to just leave. I feel really bad for those who do rely on these services because it must feel like a prison a lot of the time. I’m also fortunate that I’m not rotting my brain talking to LLMs all day either. I can see the immense damage that is having on everyone that is into this technology. If you’re thinking “not me, though”, I’m afraid to say that yes, you too. I see it every day in my peers and it’s rather distressing. Protecting your intelligence is, and will continue to be, the most important thing to do. That’s a topic for another day though! Try removing yourself from algorithmic feed slop. It’s only affected me in a positive way so far, so it’s certainly worth a shot if you’re also feeling like your brain is rotting too.
Ivory is a Mastodon client, and their account switcher has a few interesting mechanics. The standard one is that you can tap on your avatar, and get a menu in response: But you can also drag down on the avatar, and get a different reaction: This, I believe, is meant to be a slightly faster way. The settings option is gone to simplify, and the whole thing looks and feels more… gestural, in lack of a better word. But I think it also serves one more purpose. The moment I saw this, I thought to myself “I wonder if I could just swipe on the icon itself?” and, lo and behold, this is actually possible: Why does it matter? I think for some power users of social media – perhaps people doing it professionally – you switch accounts all the time, and investing in this interaction being fast and smooth is important. This whole small interaction system feels similar to switching apps on a Mac. You can choose an app in your dock with a mouse (the slow, but well-lit way). You can then learn to use ⌘⇥ and hold ⌘ to get to it quicker from a temporary menu. Eventually, you will also start tapping ⌘⇥ quickly, skipping any visible UI surface altogether. There is also something great in seeing an interface that grows with you, or one where you can say “I wonder if…” based on your prior interactions and expectations, and the interface actually rewarding you for that thought. #flow #onboarding #system design #touch
A nice moment in iOS – even if you delete an app, you might still be on the hook for its subscription, so the operating system shows this right after deletion: = 3x)" srcset="https://unsung.aresluna.org/_media/got-your-back-pt-8/1-framed.1600w.avif" type="image/avif"> (Context for the screenshot: I’m only uninstalling Quiche Browser to reinstall it and get back to the pristine onboarding for the previous post .) #got your back #ios
Phones grow big and their top edges inch closer and closer toward the horizon. Over time, iOS and apps moved some of the important surfaces to the bottom (for better or worse – I still struggle with seeing results and completions appearing above inputs), and the well-designed Reachability gesture helps, too. Still, the iOS web browser called Quiche Browser chose to tackle the problem, not the symptoms. It offers “Comfort Mode,” where you can ask it to move down the top edge of a bunch of surfaces closer to your fingers: = 3x)" srcset="https://unsung.aresluna.org/_media/a-tricky-problem-i-had-to-be-thoughtful-about/1-framed.1600w.avif" type="image/avif"> On top of that, true to the spirit of the app which revels in power-user customization, Quiche Browser allows you to decide precisely where the top should go in order to accommodate different people’s hands, and it even offers to do so per surface: These are the affected surfaces with the option off and on: The author, Greg de J., expanded on that on Threads : While designing Comfort Mode in Quiche Browser, a tricky problem I had to be thoughtful about: When you hold your phone in your right hand, favorite icons in the top left are harder to reach than ones on the right. Search suggestions don’t have this problem, since they span the width of the screen. That’s why favorites need to sit slightly lower than search suggestions, and why Comfort Mode lets you position both independently, so they all stay easy to reach one-handed. It’s an interesting idea and I wonder if it’s seeing a lot of use. The only design thought I had was: could the top space be filled or stylized so that this looks more intentional, rather than a potential rendering bug? Reachability does a good job of making it feel physical and adding a little arrow: Then again, given my job, my brain might be perfectly primed to see rendering errors everywhere. #ergonomics #touch
I've noticed recently that my phone needs to be charged way more often than I used to have to do it. I used to be able to go for nearly 2 days on an 80% charge, but I started having to charge daily . Sometimes even multiple times per day! My first thought was that my 2.5 year old Pixel 9A might be starting to show signs of age, and the battery was on its way out. But I have always had charging optimised, so it only charges to 80%. Looking at the health of my battery in settings, it shows the health as normal and reports a 100% capacity. So it's not the battery. The final straw came when I went to bed one evening with a charge of around 65%, only to wake up the next morning with just 30% of my battery remaining. How the fuck had my phone used so much battery while I was sleeping?? I checked which apps had used all that battery and to my surprise it was Google Maps and Android Auto. 6.5 hours of "screen time" while I was asleep! Ok, something is clearly fucked with Android Auto here, but I've been using it for years and it's been fine, so what's changed? The only thing that has really changed from an Android Auto perspective was that I'd got a new car which now used wireless Android Auto instead of having to plug a cable in. After some research, it turns out that wireless Android Auto is an absolute resource hog. Unlike standard Bluetooth audio, the wireless projection that Android Auto uses forces your phone to continuously compress and stream a high frame rate video feed over a Wi-Fi link, all while aggressively hammering the GPS and cellular radios too. To make matters worse, if the car is parked anywhere near the house, the phone can get stuck in a persistent background polling loop that blocks deep sleep, basically turning the handset into an expensive pocket radiator. Nice in winter, but not so bueno when you need your phone and it has a dead battery! The fix, dear reader, was rather simple. Disable wireless Android Auto . However, in practice it was more difficult than I had expected. I had to enable developer options within Android Auto's settings so the " disable wireless Auto " option became available. Why is that even a "developer option"? It should be a standard option IMO. Then I had to fiddle with the car's settings to not force wireless Android Auto, but instead prefer plain old Bluetooth. By doing this it allows me to still use Android Auto when I plug a USB C cable in, but by default it only uses Bluetooth. The infotainment display in my car is pretty nice, so I'm not really missing anything by not using Android Auto. Plus, it annoys me that Navigation always shows up - I don't need it most of the time, so why waste the computing power and screen real estate? Anyway, it's been a few days now and my battery is back to lasting me a couple of days. Worst case I need to quickly pull out my phone to open Spotify or my podcast app, AntennaPod, before I drive away, so the car picks up the media stream. If I really need it, full Android Auto is only a USB C cable away, and I know it won't hammer my battery after I get out of the car. I've ranted about how complicated modern cars are before , but this is just another example of how annoying it is. I'm a technical person, so can work this out for myself, but many of my friends and family would have had no chance in figuring this shit out, let alone fixing the problem. It's too much - they're too intrusive. I don't need to be connected everywhere. I don't need phone notifications in my car, and I usually don't need a sat nav - plus my car has it's own sat nav! I just want a way to stream media from my phone, without it getting as hot as the surface of the sun and wasting a tonne of battery power. Is that too much to ask? Anyway, it's fixed now (I think). If you're having battery issues on your phone, it might be worth checking your wireless phone connection to your car too. Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .
Every so often I hit some small, specific annoyance, and instead of living with it I spend an afternoon vibe coding my way to a fix. The results are niche beyond belief, held together with optimism, and exactly what I wanted. They work for me. They’re all on one page now at apps.dmcc.io . I’m not selling anything. I’ve put them up for the fun of it, on the off chance one of these itches is one you’ve got too. Every one of them started as my own problem. I build the thing, live with it for a bit, and open it up once I trust it not to embarrass me. Mostly. AudioLock is the one I actually use every day. Android decides where your audio goes and it decides wrong constantly. Media drifts back to the phone speaker mid-ride while my helmet headset sits there connected and silent. AudioLock overrules it. Pick a Bluetooth device, a Cardo or a pair of hearing aids, and it stays the output for media, calls and notifications until that device is genuinely gone. It watches where the audio is actually playing rather than where Android claims, and drags it back when it wanders off. No account, no store listing, a debug-signed APK you sideload. Deeply unglamorous. Fixes the exact thing that was driving me up the wall. whoop-tasker is more of the same, smaller. A screen you have to look at is useless when you’re riding, in a meeting, or asleep, so this gives Tasker a new trick: buzz my WHOOP strap. Front door opens, calendar fires, washing machine finishes, and my wrist knows. The one rule I gave myself was that it must not cost me a single day of the stats WHOOP has been nagging me to keep for months. (Remind me why I paid to be nagged?) So it doesn’t fight the official app for the connection or re-pair anything — it just leans on the same link for the two seconds a buzz takes, then clears off. It physically can’t do anything except buzz. Not a byte of recovery data goes missing. CityWall is completely pointless and I love it. It draws the streets and rivers around you and makes them your phone wallpaper, then quietly redraws it as you travel. Wake up somewhere new and so has your phone. It only ever knows your rough city, never the exact spot, because a wallpaper has no business tracking anyone. Does it need to exist? No. Do I like it? Enormously. May is the oldest itch: where does my money actually go on these vehicles. A self-hosted dashboard for fuel, expenses, maintenance and reminders across every car and bike, with DVLA lookups for MOT and tax so I don’t have to remember either. It’s named after James May, purely so the Top Gear set is complete now that Clarkson and Hammond already exist. Somehow it’s the one strangers have taken to most. Didn’t expect that at all. feedstand is my answer to feeds that decide what you see. An RSS reader that sets articles like a book instead of dumping them in a web view — proper typography, offline caching, full-text search over everything you’ve read, all of it staying on the phone. Paste any URL and it finds the feed, including the ones lurking behind a YouTube channel or a Mastodon profile. No server, so nothing to sign into. It’s the most finished-feeling of the lot, which tells you how long the feed thing has been bothering me. Two of these exist to make a point rather than fix a chore. Bluehood was a weekend thing that got a bit out of hand. It passively watches the Bluetooth devices around you — phones, cars, headphones, delivery vans — and tracks the patterns. With enough data you can tell what time someone walks the dog purely from the metadata their gadgets leak. That was the whole point of building it. It’s firmly alpha, so treat anything it tells you as a rough draft. It’s also, bafflingly, the thing I’ve made that most people have actually looked at. Loyalty Roulette is the same gripe, lighter. I’ve moaned before about privacy poverty — discounts quietly becoming a tax on your data — so this goes after the loyalty-card version. It pools shared card numbers so anyone can take the member price to the till: the savings without handing over your weekly shop, and no single number left tied to a person. mydronefeed is the odd one out because it’s genuinely quite polished, which wasn’t the plan. Point a DJI controller at it and you get a private, sub-second live view of every flight on the web, plus a link you can hand to anyone. Type it into a car screen and there’s your drone, full-screen, no sign-in. There’s a proper free tier for search and rescue teams, too, which is the bit I’m actually pleased with. And GRID/OS , which isn’t solving anything at all. It’s a browser game — Uplink by way of Spooks (MI5: 9 to 5, for my American friends), where you run cyber ops for the Service from a classified terminal at Thames House. Real Cisco, Ubiquiti and MikroTik consoles you work by hand, a trace clock narrowing on you the whole time, and a campaign that ends by asking you to name the mole. No install, nothing to sign in to. I built it because I wanted to, and that’s the entire justification. Not all of them last. I built one called Casey , used it every morning for a while, then quietly stopped. Building this way is cheap and fast, which is the appeal, but it’s also how you end up with a pile of half-used tools and a nagging sense that the time and the energy weren’t free. Worth keeping in mind before the next one. None of these are trying to be a product. They’re specific, slightly janky, and built for an audience of one who happens to be me. If any of them happen to scratch the same itch for you, brilliant, they’re all up there. If not, no harm done — I was going to build them anyway.
Apple's App Store is finally facing the reality of lower fees, and the EU should be satisfied with its work; it's ok it's late.
I praised the note-taking app Bear before for its memory ; the app would always remember your last-visited note and the precise place within it, even if it had every right to forget it. But there is a general problem here: memory that kicks in when not expected can be frustrating, as you have to undo its results and “reset to normal.” For Bear that’s not a problem, though, right? The whole iOS has a nice “ tap near the top to scroll to the top ” gesture that would work here as well, making it easy to recover if you return to the note where you last happened to type. Except, with any writing app, the very bottom is as valid of a destination as the very top. Bear designers understood it and tried to solve it in a new way, by adding two gestures: a two-finger swipe up takes you to the very top, and a two-finger swipe down to the very bottom: It doesn’t quite work as well as I hoped – for some reason, it scrolls way too far down, and does feel a bit sticky mechanically. It’s also, like any complex gesture , not very discoverable. But here’s where Bear tries to help, by… adding even more gestures atop these two. There is a two-finger swipe left or right for jumping back and forward in history… …and even a two-finger tap to reveal a navigation menu. That last one feels like overkill to me, but there is something interesting about the app building an entire little universe of compatible gestures – “Come here for all your navigation needs!” – knowing that it increases the chances users will develop a habit of learning and using them. (The gestures also work whether you’re in view or edit mode.) I am curious, though: Would allowing to tap somewhere near the bottom edge not work as the “obvious” solution to get all the way down? #bear #system design #text editing #touch
Gambiarra, de modo geral, é conhecida como uma espécie de quebra-galho ou atalho para conseguir algo usando a criatividade, muitas vezes de forma pejorativa. Ressalto que, neste texto, a ideia é justamente enfatizar a criatividade diante de grandes desafios. Certa vez, enquanto trabalhava com aplicativos mobile e livros digitais, fui encarregado de renderizar um livro em um aplicativo Android nativo. React Native ainda não existia. Talvez o Sencha Touch já existisse, mas, de qualquer forma, os tablets-alvo eram muito lentos e tinham pouquíssimos recursos. Pois bem, o que você faria nessa situação? Fácil, não é? Renderizaria as páginas do PDF como imagens JPEG e criaria um aplicativo para paginá-las, a.k.a. um livro digital. Não, claro que não! Seu gerente gosta de desafiar você e não gostou nem da qualidade das imagens nem do espaço ocupado em disco. Então, ele propôs usar Adobe Flash. Sim, naquela época ele ainda existia, embora já estivesse no fim da vida. Mas como? Ninguém sabia. Foi então que tive a ideia de criar uma WebView de um pixel por um pixel e embutir o Adobe Flash nela para renderizar as páginas sob demanda e com a máxima qualidade. As páginas viriam de um arquivo , pois o software usado para criar os livros exportava a arte vetorial para SWF. Nos PDFs, por algum motivo, tudo era convertido em bitmap. Mas surgiu outro problema: como transferir dados entre o aplicativo Android, escrito em Java, a WebView, em JavaScript, e o Adobe Flash? Criei uma WebView de um pixel por um pixel com o Flash Player rodando dentro dela. Na época, essa era a única maneira de executar Flash no Android, pois o Adobe AIR ainda não existia. Fazendo o Java chamar , eu conseguia executar uma função JavaScript e passar o bitmap renderizado da página solicitada. Sim, o bitmap inteiro era transmitido como uma string. Por sorte, a WebView não tinha uma limitação de 4.096 caracteres, ou algo semelhante às limitações comuns em servidores HTTP. Portanto, era possível transmitir páginas muito grandes e em alta resolução. Feito isso, bastava repassar os dados para o Flash. Mas como? Exemplo simplificado: No lado do Flash, em ActionScript: Então, no lado da WebView, em JavaScript: Feio? É, eu sei. Mas funcionou perfeitamente. Passamos a ter páginas com alto DPI, zoom, rotação e tudo mais. Como bônus, ficou bem rápido, pois o aparelho precisava renderizar cada página apenas uma vez. Isso acontecia em menos de meio segundo. Depois, bastava desenhar a imagem na tela. :-)
From Marton Barcza at TechAltar, a good 12-minute video analyzing what went wrong with the famed Live Tiles that Microsoft was pushing throughout most of the 2010s: = 2x) and (width >= 700px)" srcset="https://unsung.aresluna.org/_media/microsofts-most-ambitious-attempt-to-reinvent-the-start-screen/yt1-play.2096w.avif" type="image/avif"> = 3x) or (width >= 700px)" srcset="https://unsung.aresluna.org/_media/microsofts-most-ambitious-attempt-to-reinvent-the-start-screen/yt1-play.1600w.avif" type="image/avif"> Now, among Windows Phone fans the pervasive opinion is that Live Tiles have failed because Microsoft did a poor job with them, which I think is at least partially true – after all, even many key Microsoft apps like Skype had broken Live Tiles half the time, the Windows 10 start menu was filled by Microsoft with Live Tiles that were clearly just animated ads rather than showing you something actually useful, and the company of course never built out any of their advanced interactive concepts either. But while all of that might be true, the fact that every major company has walked away from this idea and nobody else has picked it up since, means that there probably are more fundamental problems with this idea. And I can think of three distinct ones: Barcza goes on to talk about some specific interactions and problems, and arrives at the conclusion that Live Tiles ended up at this unpleasant intersection where they’re tried to be icons, widgets, and notifications all at once, not doing a particularly great job at either task. That, and there were also challenges with the design primarily being mobile-first, and struggling surviving a jump to a large screen. (Live Tiles were abandoned in the 2017, at which point desktop Windows reverted back to what it was before, and the mobile/tablet lines were altogether disbanded.) What I found interesting in watching this today is that it feels Apple has made some similar mistakes in their Liquid Glass approach and wider platform unification desires (see: macOS Settings). Both these and Live Tiles attempted to create A System Of Systems, and both ended up occasionally feeling like they awkwardly crowbarred some wider concepts into places where they didn’t truly belong. If it helps with your further research, I understand Live Tiles were part of a bigger UI effort called Metro and started in earnest with Windows Phone . #apple #change management #complexity #touch #windows #youtube user experience, form factors, and horizontal integration.
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.
Mobile
Programming
iOS
Design
AI
Business
Performance
Go
Culture
Open Source
Java
Android
JavaScript
Shell
C
CSS