![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
Golang and Let's Encrypt: a free software story
Jun. 26th, 2025 02:52 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
fanfhttps://dotat.at/@/2025-06-28-boulder.html
Here's a story from nearly 10 years ago.
( Read more... )
Origins: other stuff
Jun. 24th, 2025 04:04 pmcellioWe went to Origins Game Fair last week. My previous post covered the games we played; this post is about everything else.
The convention was, overall, pleasant -- not as crowded as I expected for the 50th year, at least in the parts we frequented, but we had critical mass for all the games we played and it was nice to not have to push through crowds like at GenCon.
We had one excellent teacher, several good ones, and a couple terrible ones. In one game it became clear two hours in that we were missing an important rule, and another was very disorganized. There is a wide range from "enthusiastic fan who wants to evangelize the game" at one end to "I'm hoping to book enough game-running slots to get free admission" at the other, and I don't know if there is any sort of feedback to the convention. I didn't see a way to let them know that that person running Terraforming Mars was outstanding and should be invited back, for instance. And maybe that's not even the right model; I have no idea how Origins makes decisions about who can run games, or if they even do. They collect the tickets at games, so they know both how many people registered for a game and how many actually showed up, but I don't know if that affects future years for that game, that game-runner, or nothing.
I was satisfied with most of the games we played; we expected both positive and negative reactions, so a game I don't like very much (or feel neutral about) is still useful data. We can try many more games than we can ultimately bring back to our gaming groups, after all, so eliminating candidates is important too. That said, we identified half a dozen games that we liked enough to want to get (though one of them is way too expensive so we won't unless that changes), so I consider that to be very successful.
We did not do a good job of pacing this year, exacerbated by getting locked out of most of our choices for the middle day, when our first-draft schedule had some breaks built in. We ended up with a lot of long, solid blocks and didn't factor in the cognitive load of learning all those games. We can invite friends over and play games we already know for ten hours and be quite happy, but that doesn't mean ten straight hours of new convention games with strangers are a good idea. I need to remember this for next year. Also, we should front-load more and give ourselves more breaks on Friday and especially Saturday. There is a temptation to book Saturday solid because it's Shabbat so it's not like we're going out for lunch or having dinner much before 10PM, but it's a mistake.
In two or three games this year, the game-runners used an app to choose the starting player (everyone touch this phone). For the game that was on Shabbat I declined and was ready to accept going last, but the person just shrugged and randomized a different way, which was nice. I've see people use that app (or an app, anyway) before, and it always makes me wonder: did this problem need an app? We have been randomly choosing a meeple or rolling dice for this for decades and I've never felt that to be lacking. Only later did the info-security aspect occur to me: I should also maybe not be eager to hand over a fingerprint impression to someone who knows my name (from the event ticket), just on general principle.
We went to two seminars (though both on the same day, so they didn't help as much with pacing as they could have). One was pretty good; in the other one, halfway through I asked Dani if he was enjoying it, he said "no me neither", and we left as discreetly as we could. Three other people followed us out, almost like they were waiting for someone to start. The presenter probably had interesting things to say but did not seem to have prepared the talk. We've had that experience before with this particular fan group (some groups run "tracks" of activities), so I'll pay more attention to that in future years. Origins also has a films room, a few comedy or music performances, and a little bit in the way of crafts, so we should look at those too. I don't think I can lure Dani into the figure-painting area, but I used to enjoy that and it could be a way to break up a non-Shabbat day.
Most of the games are run in one of the big halls in the convention center. I think there's a cumulative draining effect from the harsh fluorescent lights and the background noise of all those other games, and that's another thing to take into account when we try to build a schedule -- if that information is available in April when we choose events, which I don't remember.
Some game-runners were good about accommodating my vision needs, but a few brushed me off and in one game, both the game-runner and two of the other players were kind of rude about it. When I asked for help during the game because I couldn't see and couldn't memorize everything ("which tile is that (points)?" etc), I picked up some sighs and the vague sense that the reaction might have been different if I were not the only woman at the table. I can't point to anything specific and I'm not someone who jumps to conclusions about sexism, but this kinda felt like it. I was often the only woman at the table in the games I played and most of the time I didn't pick up this vibe, so I think it was just that one group of people.
We did one quick run through the dealers' room. We only saw one "general" games vendor, as opposed to publishers selling their own games. We also walked past a lot of banners, plushies, dice, jewelry, miniatures, and LARP gear. Several publishers had raffles for unspecified games or expansions/components, winner must be present at such-and-such time on Sunday. That's easy for the vendor but hard for participants, so even though we got handed free tickets at some games we played, we didn't bother with any of them.
The first year we went to Origins we got a hotel that was about a mile away, so we walked to the convention in the morning and stayed all day. There aren't a lot of good places in the convention center to sit and take a break for an hour, though, so after that, we started paying for closer hotels. This year we were right across the street from the convention center, and being able to go back to the room for an hour between sessions turns out to be a really huge win. Also, our hotel had coffee available all day in the lobby, so that was a nice bonus. We never had to stand in the long lines at the coffee places in the convention center (or pay $5 or more for a cup of coffee).
The multi-day heat wave started during the convention. This made the drive home a little challenging. Under normal circumstances we wouldn't have made that extra stop to get something cold to drink and sit in Panera's air conditioning, but it sure helped this time! Originally we had planned to leave Columbus after the hottest part of the day, but a no-show game-runner messed with our plans and we left earlier.
Why is there no consistent single signon API flow?
Jun. 23rd, 2025 10:36 pmmjg59Single signon is a pretty vital part of modern enterprise security. You have users who need access to a bewildering array of services, and you want to be able to avoid the fallout of one of those services being compromised and your users having to change their passwords everywhere (because they're clearly going to be using the same password everywhere), or you want to be able to enforce some reasonable MFA policy without needing to configure it in 300 different places, or you want to be able to disable all user access in one place when someone leaves the company, or, well, all of the above. There's any number of providers for this, ranging from it being integrated with a more general app service platform (eg, Microsoft or Google) or a third party vendor (Okta, Ping, any number of bizarre companies). And, in general, they'll offer a straightforward mechanism to either issue OIDC tokens or manage SAML login flows, requiring users present whatever set of authentication mechanisms you've configured.
This is largely optimised for web authentication, which doesn't seem like a huge deal - if I'm logging into Workday then being bounced to another site for auth seems entirely reasonable. The problem is when you're trying to gate access to a non-web app, at which point consistency in login flow is usually achieved by spawning a browser and somehow managing submitting the result back to the remote server. And this makes some degree of sense - browsers are where webauthn token support tends to live, and it also ensures the user always has the same experience.
But it works poorly for CLI-based setups. There's basically two options - you can use the device code authorisation flow, where you perform authentication on what is nominally a separate machine to the one requesting it (but in this case is actually the same) and as a result end up with a straightforward mechanism to have your users socially engineered into giving Johnny Badman a valid auth token despite webauthn nominally being unphisable (as described years ago), or you reduce that risk somewhat by spawning a local server and POSTing the token back to it - which works locally but doesn't work well if you're dealing with trying to auth on a remote device. The user experience for both scenarios sucks, and it reduces a bunch of the worthwhile security properties that modern MFA supposedly gives us.
There's a third approach, which is in some ways the obviously good approach and in other ways is obviously a screaming nightmare. All the browser is doing is sending a bunch of requests to a remote service and handling the response locally. Why don't we just do the same? Okta, for instance, has an API for auth. We just need to submit the username and password to that and see what answer comes back. This is great until you enable any kind of MFA, at which point the additional authz step is something that's only supported via the browser. And basically everyone else is the same.
Of course, when we say "That's only supported via the browser", the browser is still just running some code of some form and we can figure out what it's doing and do the same. Which is how you end up scraping constants out of Javascript embedded in the API response in order to submit that data back in the appropriate way. This is all possible but it's incredibly annoying and fragile - the contract with the identity provider is that a browser is pointed at a URL, not that any of the internal implementation remains consistent.
I've done this. I've implemented code to scrape an identity provider's auth responses to extract the webauthn challenges and feed those to a local security token without using a browser. I've also written support for forwarding those challenges over the SSH agent protocol to make this work with remote systems that aren't running a GUI. This week I'm working on doing the same again, because every identity provider does all of this differently.
There's no fundamental reason all of this needs to be custom. It could be a straightforward "POST username and password, receive list of UUIDs describing MFA mechanisms, define how those MFA mechanisms work". That even gives space for custom auth factors (I'm looking at you, Okta Fastpass). But instead I'm left scraping JSON blobs out of Javascript and hoping nobody renames a field, even though I only care about extremely standard MFA mechanisms that shouldn't differ across different identity providers.
Someone, please, write a spec for this. Please don't make it be me.
This is largely optimised for web authentication, which doesn't seem like a huge deal - if I'm logging into Workday then being bounced to another site for auth seems entirely reasonable. The problem is when you're trying to gate access to a non-web app, at which point consistency in login flow is usually achieved by spawning a browser and somehow managing submitting the result back to the remote server. And this makes some degree of sense - browsers are where webauthn token support tends to live, and it also ensures the user always has the same experience.
But it works poorly for CLI-based setups. There's basically two options - you can use the device code authorisation flow, where you perform authentication on what is nominally a separate machine to the one requesting it (but in this case is actually the same) and as a result end up with a straightforward mechanism to have your users socially engineered into giving Johnny Badman a valid auth token despite webauthn nominally being unphisable (as described years ago), or you reduce that risk somewhat by spawning a local server and POSTing the token back to it - which works locally but doesn't work well if you're dealing with trying to auth on a remote device. The user experience for both scenarios sucks, and it reduces a bunch of the worthwhile security properties that modern MFA supposedly gives us.
There's a third approach, which is in some ways the obviously good approach and in other ways is obviously a screaming nightmare. All the browser is doing is sending a bunch of requests to a remote service and handling the response locally. Why don't we just do the same? Okta, for instance, has an API for auth. We just need to submit the username and password to that and see what answer comes back. This is great until you enable any kind of MFA, at which point the additional authz step is something that's only supported via the browser. And basically everyone else is the same.
Of course, when we say "That's only supported via the browser", the browser is still just running some code of some form and we can figure out what it's doing and do the same. Which is how you end up scraping constants out of Javascript embedded in the API response in order to submit that data back in the appropriate way. This is all possible but it's incredibly annoying and fragile - the contract with the identity provider is that a browser is pointed at a URL, not that any of the internal implementation remains consistent.
I've done this. I've implemented code to scrape an identity provider's auth responses to extract the webauthn challenges and feed those to a local security token without using a browser. I've also written support for forwarding those challenges over the SSH agent protocol to make this work with remote systems that aren't running a GUI. This week I'm working on doing the same again, because every identity provider does all of this differently.
There's no fundamental reason all of this needs to be custom. It could be a straightforward "POST username and password, receive list of UUIDs describing MFA mechanisms, define how those MFA mechanisms work". That even gives space for custom auth factors (I'm looking at you, Okta Fastpass). But instead I'm left scraping JSON blobs out of Javascript and hoping nobody renames a field, even though I only care about extremely standard MFA mechanisms that shouldn't differ across different identity providers.
Someone, please, write a spec for this. Please don't make it be me.
Origins: games played
Jun. 22nd, 2025 10:51 pmcellioWe got home from Origins Game Fair today. As usual, we focused on games we don't already know, which means we expect some winners and some losers. This year, most of our pre-convention information about these games came from Board Game Geek (and, in one case, a fan among my readers). We also attended a couple non-games.
Origins has a ton of games, and you really want to preregister for them instead of taking your chances at the con. Dani winnowed the huge list down to a smaller number of candidates, and then we sorted those into four buckets: A (really want to play), B (looks good), C (would play), and X (nope!). I'm going to list the bucket we put each game into, so I can start tracking prediction versus reality. We had to do a second round of scheduling after we got locked out of some of our initial picks, so not all games have buckets.
Theoretically most games at Origins are taught. Some require experience (we didn't sign up for any of those). Some games were additionally listed as "learn to play", suggesting more active teaching and guidance. Some, but not all, of those are run by the publishers. We had one outstanding learn-to-play non-publisher experience.
Wednesday
Keep the Heroes Out!: Cooperative game where the players are dungeon monsters trying to keep the invaders (heroes, adventurers) from getting their hard-earned treasure. Each monster has different abilities. It sounded like a fun concept and some of the mechanics were interesting, but a lot depends on random chance and it was hard to strategize. It's icon-heavy; there was a player cheat sheet (good), but it was not entirely accurate (bad). Thumbs down. (Bucket: A.)
Pandemic: The Cure (it looks like we were playing with the Experimental Meds expansion): This is an abstraction of Pandemic, using six zones instead of a world map and role-specific dice to constrain your actions. On your turn you roll your dice, which tell you which actions (including role-specific ones) are available to you this turn. You can re-roll, but if the biohazard face comes up that moves the group along the infection track (and you can't re-roll that die). Diseases are asymmetric dice, with the number telling you which zone it affects. Curing diseases involves players collecting dice of the same color, replacing the cards in the original game. It's a quick game and we enjoyed it. We want to get it. (Bucket: C.)
Thursday
Metro: The board made me think of Tsuro when I saw it. Players are trying to build train tracks connecting starting positions with a station. The edge of the board alternates starting positions and stations and there's a station in the center of the board. You're trying to make your tracks as long as possible and there's a bonus for connecting to the center station. On your turn you place a tile into the 8x8 grid; each tile has two track connections on each edge, and it's designed so that there's always a valid placement. It's a quick game; our teaching game was about 40 minutes. We both liked this a lot and want to get it. (Second-round pick.)
Weather Meeple: A lightweight game about manipulating the weather. You're trying to use your weather cards (which can produce sun, rain, lightning, clouds, or snow) to "build" the weather systems for four "goal" forecasts. It's sort of an engine-building game (your cards and what they produce), with new card draws affecting which of your cards can produce this round, which you can mitigate with an action... cute, ok. I'd play again if a friend brought it over and wanted to, but otherwise, meh. (Second-round pick.)
Dwellings of Eldervale: No. Just...no. Ok, I understand why it appeals to some; it's sort of worker-placement, sort of area-control, definitely monster-fighting, cards you can buy to gain abilities, sixteen different "factions" to choose from each with its own special abilities, variable dynamic board with special spaces... I should have taken stronger note of the game-runner asking us, at the beginning, to just go with it and if we aren't having fun don't let it show. The game has a lot of stuff, so you need a large table, and the con's options for that are bad, and the game components were already visually challenging even before that... Thumbs down. (Bucket: A.)
High Frontier: Dani really likes the idea of Phil Eklund's games, which tend to be about biology and evolution and get very, very detailed. I noted the BGG complexity rating of 4.35 (out of 5) and suggested that maybe we split up for that session. He reported that the game has a lot of potential and he'd like to figure it out, but if he's going to burn social capital on getting a group together to figure out a long complex game, it's not going to be this one.
Learn to play: Nassau: Rum & Pirates is a good game. It didn't need a second level, adding a seafaring phase after each city phase. 'Nuff said. (Bucket: A.)
Foundations of Rome: Loved this. Players are building three types of buildings (residential, commercial, civic) on a shared grid. You each have a supply of buildings of different sizes and shapes. In order to build, you first have to acquire deeds to the land you'll need. Deeds come out for purchase in random order, so while your goal might be that big bank that requires four spaces in a square, you might have to start with a couple one-space houses or bakeries or whatever and then replace them as you get the land you need. (You can always replace to grow, but you can't subdivide.) Most buildings score based on what they're adjacent to, so there's a lot of player interaction. Our game took about an hour.
The game is physically beautiful. You get a tray of three-dimensional, decorated little buildings, with clear indications on their tops about how they score. Based on the images at Board Game Geek, there's a whole fandom around painting those miniatures. The game is very expensive (over $300). I don't think it would be nearly as satisfying to play without the nice components, but we're not shelling out for that, either. This game might be one we look for at conventions. (Bucket: A.)
Friday
We got almost none of our first-round picks for Friday, so we ended up assembling this from still-available parts.
Learn to play: Liftoff 2.0, run by the designer: Competitive space-program development starting in the 1950s. Players develop technologies (like orbital satellites, first-stage rockets, and capsules) and do research to improve their safety. You schedule future launches and do your best to develop what you'll need to a level of safety you're willing to go with, and then you roll the dice for each stage of the launch to see how you did. You gain prestige points from successful launches and from being the first to do things like put a man in orbit. Prestige begets better funding. Failures and random events can set you back, and you might decide to scrub a scheduled launch if your research didn't pan out enough (or you ran out of money to fund it). This is a remake of an older game I've never played. I'm interested in seeing the finished game (we played with a prototype and I gave some feedback on some vision issues).
Town Builder: Coevorden: Tableau-building card game. Each card can be used as either a specific (proto-)building or a specific resource. To build a building, you buy its card and then accumulate the resources that will be needed to construct it. When you have all the resources, your building is built and you can use any special abilities it gives you. Buildings are worth victory points (harder buildings are worth more), and there are also some random goals like "have three civic buildings". It's a fairly quick game, maybe 45 minutes (box says 30-60). We chose it in part because of the publisher, First Fish -- we like another of their games. We bought this at the convention.
Corps of Discovery: Lewis and Clark and Monsters. This is a cooperative deduction game with periodic specific goals. Players are exploring a map, turning over tiles to reveal things like water, food, forts, and threats. You are told some "rules" for placement like "water and food will always be adjacent", which lets the group reason about the not-yet-revealed spots. You need to collect certain resources at certain times, have food and water and a campfire at the end of the day, and gather things to improvise weapons for when the monsters find you. We both liked it a lot and want to get it. I do hope there's enough map variability, given that there are those constraints, to keep it interesting. (I mean, I used to accidentally memorize the eye chart at my vision exams before they introduced more variability. I didn't want to...) (Bucket: A.)
We also attended two seminars, one on 19th-century science fiction and one allegedly on military logistics in ancient and medieval times.
Saturday
Kingsburg: Each player has a province that you're trying to improve. The game plays through five years of four seasons; spring, summer, and fall are for production and building, and in the winter the monsters come out. By winter you need to have enough strength from the buildings you built or the mercenaries you hired. On your (non-winter) turn you roll three dice and can spend them to claim positions from 1 through 18 -- standard worker-placement rules, first come first served. You could use just one of your dice to get that wood on 4 that you really need, or you can combine them to get higher-value items. You need an exact match, so depending on how you rolled, you might not get what you were trying for. You can see what other players rolled, so you can reason about what they might take from you or what you can safely leave for later. We both liked this. (Bucket: B.)
Learn to play: Canals of Windcrest: Sequel to Mistwind, which we like. Despite it being marked "learn to play", there was a large, fast info dump at the beginning and it looked like there wouldn't be a lot more, and there are a lot of moving parts, and I was not feeling good about it, so (after confirming it wouldn't mess up the table) I bailed. Dani played and reported that it's a good game but, yes, lots of moving parts that he only started to understand after playing. (Bucket: A.)
Unpub: There is an area set aside for game designers to test-drive works in progress. For players, you can just show up, look around for something that looks interesting and has the "needs players" flag up, and go join. While Dani was playing Canals I wandered in there and joined a game called Toll the Dead. (This turned out to be thematically coincidental; see next entry.) This is a cooperative game with limited communication (made me think of Crew in that regard). The dead and also the destroyer are working their way up through the nine circles of hell trying to escape; the players have to stop them. Your tools: bellringers who do damage to enemies in the same space (maybe more) and then move, and variable special abilities. You roll dice and then allocate them semi-secretly; everyone can see if you're bringing in a new ringer and where, but most other actions are secret. (There's more to it, but I don't want to do anything that might impede the designer. For example, Origins has a no-photography rule in this room.) I enjoyed the game a lot and after we played the designer asked for feedback (general and some specific questions) and we had a good conversation. She's hoping to pitch it to a publisher, not Kickstart it, so there's no URL to follow right now but I did get a card so I can check back later.
Inferno: A "soul management" game, the publisher says. Each turn has two places, below and above. Below, you are trying to guide souls to the correct circles of Hell, gaining infamy (victory) points when you deliver them. Above, you are placing workers in various buildings in Florence to get corresponding game effects. What you did in Hell restricts what you can do in Florence. Hell gets restocked when players use the Florence action to accuse someone of sin, which gets you benefits in Hell. There are scoring tracks (one for each circle) and you only get to score a track at all if (a) you have one of your markers there and (b) you managed to place a different marker there, the means for which were a little unclear to me. It felt like a very complicated game; BGG says 3.57 but I would have put it at 4+. I don't mind that I played but I'm not looking for another game of it. (Bucket: A.)
Learn to play: Terraforming Mars: Ok, it's like this. I've been around games of Terraforming Mars. I've been around one struggling teaching session of Terraforming Mars that persuaded me to be elsewhere in a hurry. It looks super-complicated and super-fiddly. This session, though, was a delight. The person running it (just a regular gamer, not from the publisher) was excellent and enthusiastic. I now understand why some of my readers like this game.
Players are each playing a corporation who are collectively trying to make Mars habitable. There are joint goals, like increasing the oxygen level and temperature, and you get victory points when you contribute to those goals. You also have other ways to get points. At its core everything depends on two things: what resources you have (and can generate), and what cards you choose to buy and later play. Card-management is probably pretty strategic once you know what you're doing; in this game I was playing more tactically, becuase how would I know if this card I can buy on turn 2 might be useful five turns from now when the temperature is high enough to allow me to play it? Stuff like that. Cards can give you resources, better resource generation, ways to earn points (I had "Pets", which collects points when people build cities), discounts on standard actions (like placing a forest tile), and lots more. Each round there's a card draft where you can choose cards to keep (for a fee). Playing them also costs money. Your corporation gives you some special advantages, which you should factor in, but sometimes the best cards just don't show up (or show up at the right time).
Our session, with teaching and coaching and some discussion after, ran a little over three hours. With experience, it's probably a two-hour game, or maybe even shorter. (Bucket: B.)
Sunday
We were signed up for two two-hour games on Sunday (both in bucket A). The first one was a no-show, and we decided that the second one wasn't compelling enough to wait for and headed home instead. Playing games most of the day for several days is already pretty tiring (more for me than for Dani I think), and we didn't do a great job this time of padding the schedule with non-game (or non-game-in-the-room-with-the-enervating-fluorescent-lights) activities. One solution there -- at the cost of making the jigsaw puzzle more complicated -- might be splitting up here and there like we did this time. For example, I like RPGs more than Dani does, and I haven't played any at conventions.
My a11y journey
Jun. 20th, 2025 01:11 ammjg5923 years ago I was in a bad place. I'd quit my first attempt at a PhD for various reasons that were, with hindsight, bad, and I was suddenly entirely aimless. I lucked into picking up a sysadmin role back at TCM where I'd spent a summer a year before, but that's not really what I wanted in my life. And then Hanna mentioned that her PhD supervisor was looking for someone familiar with Linux to work on making Dasher, one of the group's research projects, more usable on Linux. I jumped.
The timing was fortuitous. Sun were pumping money and developer effort into accessibility support, and the Inference Group had just received a grant from the Gatsy Foundation that involved working with the ACE Centre to provide additional accessibility support. And I was suddenly hacking on code that was largely ignored by most developers, supporting use cases that were irrelevant to most developers. Being in a relatively green field space sounds refreshing, until you realise that you're catering to actual humans who are potentially going to rely on your software to be able to communicate. That's somewhat focusing.
This was, uh, something of an on the job learning experience. I had to catch up with a lot of new technologies very quickly, but that wasn't the hard bit - what was difficult was realising I had to cater to people who were dealing with use cases that I had no experience of whatsoever. Dasher was extended to allow text entry into applications without needing to cut and paste. We added support for introspection of the current applications UI so menus could be exposed via the Dasher interface, allowing people to fly through menu hierarchies and pop open file dialogs. Text-to-speech was incorporated so people could rapidly enter sentences and have them spoke out loud.
But what sticks with me isn't the tech, or even the opportunities it gave me to meet other people working on the Linux desktop and forge friendships that still exist. It was the cases where I had the opportunity to work with people who could use Dasher as a tool to increase their ability to communicate with the outside world, whose lives were transformed for the better because of what we'd produced. Watching someone use your code and realising that you could write a three line patch that had a significant impact on the speed they could talk to other people is an incomparable experience. It's been decades and in many ways that was the most impact I've ever had as a developer.
I left after a year to work on fruitflies and get my PhD, and my career since then hasn't involved a lot of accessibility work. But it's stuck with me - every improvement in that space is something that has a direct impact on the quality of life of more people than you expect, but is also something that goes almost unrecognised. The people working on accessibility are heroes. They're making all the technology everyone else produces available to people who would otherwise be blocked from it. They deserve recognition, and they deserve a lot more support than they have.
But when we deal with technology, we deal with transitions. A lot of the Linux accessibility support depended on X11 behaviour that is now widely regarded as a set of misfeatures. It's not actually good to be able to inject arbitrary input into an arbitrary window, and it's not good to be able to arbitrarily scrape out its contents. X11 never had a model to permit this for accessibility tooling while blocking it for other code. Wayland does, but suffers from the surrounding infrastructure not being well developed yet. We're seeing that happen now, though - Gnome has been performing a great deal of work in this respect, and KDE is picking that up as well. There isn't a full correspondence between X11-based Linux accessibility support and Wayland, but for many users the Wayland accessibility infrastructure is already better than with X11.
That's going to continue improving, and it'll improve faster with broader support. We've somehow ended up with the bizarre politicisation of Wayland as being some sort of woke thing while X11 represents the Roman Empire or some such bullshit, but the reality is that there is no story for improving accessibility support under X11 and sticking to X11 is going to end up reducing the accessibility of a platform.
When you read anything about Linux accessibility, ask yourself whether you're reading something written by either a user of the accessibility features, or a developer of them. If they're neither, ask yourself why they actually care and what they're doing to make the future better.
The timing was fortuitous. Sun were pumping money and developer effort into accessibility support, and the Inference Group had just received a grant from the Gatsy Foundation that involved working with the ACE Centre to provide additional accessibility support. And I was suddenly hacking on code that was largely ignored by most developers, supporting use cases that were irrelevant to most developers. Being in a relatively green field space sounds refreshing, until you realise that you're catering to actual humans who are potentially going to rely on your software to be able to communicate. That's somewhat focusing.
This was, uh, something of an on the job learning experience. I had to catch up with a lot of new technologies very quickly, but that wasn't the hard bit - what was difficult was realising I had to cater to people who were dealing with use cases that I had no experience of whatsoever. Dasher was extended to allow text entry into applications without needing to cut and paste. We added support for introspection of the current applications UI so menus could be exposed via the Dasher interface, allowing people to fly through menu hierarchies and pop open file dialogs. Text-to-speech was incorporated so people could rapidly enter sentences and have them spoke out loud.
But what sticks with me isn't the tech, or even the opportunities it gave me to meet other people working on the Linux desktop and forge friendships that still exist. It was the cases where I had the opportunity to work with people who could use Dasher as a tool to increase their ability to communicate with the outside world, whose lives were transformed for the better because of what we'd produced. Watching someone use your code and realising that you could write a three line patch that had a significant impact on the speed they could talk to other people is an incomparable experience. It's been decades and in many ways that was the most impact I've ever had as a developer.
I left after a year to work on fruitflies and get my PhD, and my career since then hasn't involved a lot of accessibility work. But it's stuck with me - every improvement in that space is something that has a direct impact on the quality of life of more people than you expect, but is also something that goes almost unrecognised. The people working on accessibility are heroes. They're making all the technology everyone else produces available to people who would otherwise be blocked from it. They deserve recognition, and they deserve a lot more support than they have.
But when we deal with technology, we deal with transitions. A lot of the Linux accessibility support depended on X11 behaviour that is now widely regarded as a set of misfeatures. It's not actually good to be able to inject arbitrary input into an arbitrary window, and it's not good to be able to arbitrarily scrape out its contents. X11 never had a model to permit this for accessibility tooling while blocking it for other code. Wayland does, but suffers from the surrounding infrastructure not being well developed yet. We're seeing that happen now, though - Gnome has been performing a great deal of work in this respect, and KDE is picking that up as well. There isn't a full correspondence between X11-based Linux accessibility support and Wayland, but for many users the Wayland accessibility infrastructure is already better than with X11.
That's going to continue improving, and it'll improve faster with broader support. We've somehow ended up with the bizarre politicisation of Wayland as being some sort of woke thing while X11 represents the Roman Empire or some such bullshit, but the reality is that there is no story for improving accessibility support under X11 and sticking to X11 is going to end up reducing the accessibility of a platform.
When you read anything about Linux accessibility, ask yourself whether you're reading something written by either a user of the accessibility features, or a developer of them. If they're neither, ask yourself why they actually care and what they're doing to make the future better.
These numbers don't seem to work
Jun. 19th, 2025 08:52 pmhistory_monkThe SpaceX Starship project is in serious trouble. The last three test launches have failed, and yesterday the ship for the next launch exploded while being fuelled for a static firing test. However, even if things were working perfectly, there's a serious problem with the logistics of the project.
Starship Block 1 was rated to deliver 100 tons of payload to LEO. Block 2 numbers are a bit vaguer at 100-150 tons, Block 3 targets 200 tons, and Block 4 is intended to carry 400 tons, if the vehicle is expended, which makes it much more expensive. Fuel carried to orbit counts as payload. For Starship to travel beyond LEO, it needs to be refuelled. It holds 1,500 tons of fuel. That's a lot.
So far, no Starship has completed a full Earth orbit. The plan for the Human Landing System variant which is supposed to take astronauts back to the Moon is to carry out several large and entirely automated fuel transfers in orbit. Pumping fuel between large spacecraft in microgravity has not yet been demonstrated. The transfers have to happen in rapid succession because all the fuel is cryogenic and boils away as it warms up. Filling up 1,500 tons of fuel requires somewhere between four and twenty successful flights and successful transfers to deliver the fuel, depending on your assumptions.
The test flights of Starship have demonstrated that a very high-performance vehicle - which it genuinely is - needs exquisite care before launch, which slows down the launch rate. SpaceX has two launch stands in Texas, and is building another at the Kennedy Space Centre. But that seems to be all of what they'll have for the next few years
Currently they're planning an unmanned demonstration landing on the Moon this year, and the manned landing in 2027. They aren't going to meet those deadlines, as is quite obvious, and should stop pretending. They've built what seems like a pretty good rocket, but it won't do the things claimed for it any time soon. Those need something even bigger.
Starship Block 1 was rated to deliver 100 tons of payload to LEO. Block 2 numbers are a bit vaguer at 100-150 tons, Block 3 targets 200 tons, and Block 4 is intended to carry 400 tons, if the vehicle is expended, which makes it much more expensive. Fuel carried to orbit counts as payload. For Starship to travel beyond LEO, it needs to be refuelled. It holds 1,500 tons of fuel. That's a lot.
So far, no Starship has completed a full Earth orbit. The plan for the Human Landing System variant which is supposed to take astronauts back to the Moon is to carry out several large and entirely automated fuel transfers in orbit. Pumping fuel between large spacecraft in microgravity has not yet been demonstrated. The transfers have to happen in rapid succession because all the fuel is cryogenic and boils away as it warms up. Filling up 1,500 tons of fuel requires somewhere between four and twenty successful flights and successful transfers to deliver the fuel, depending on your assumptions.
The test flights of Starship have demonstrated that a very high-performance vehicle - which it genuinely is - needs exquisite care before launch, which slows down the launch rate. SpaceX has two launch stands in Texas, and is building another at the Kennedy Space Centre. But that seems to be all of what they'll have for the next few years
Currently they're planning an unmanned demonstration landing on the Moon this year, and the manned landing in 2027. They aren't going to meet those deadlines, as is quite obvious, and should stop pretending. They've built what seems like a pretty good rocket, but it won't do the things claimed for it any time soon. Those need something even bigger.
Locally hosting an internet-connected server
Jun. 16th, 2025 09:20 pmmjg59I'm lucky enough to have a weird niche ISP available to me, so I'm paying $35 a month for around 600MBit symmetric data. Unfortunately they don't offer static IP addresses to residential customers, and nor do they allow multiple IP addresses per connection, and I'm the sort of person who'd like to run a bunch of stuff myself, so I've been looking for ways to manage this.
What I've ended up doing is renting a cheap VPS from a vendor that lets me add multiple IP addresses for minimal extra cost. The precise nature of the VPS isn't relevant - you just want a machine (it doesn't need much CPU, RAM, or storage) that has multiple world routeable IPv4 addresses associated with it and has no port blocks on incoming traffic. Ideally it's geographically local and peers with your ISP in order to reduce additional latency, but that's a nice to have rather than a requirement.
By setting that up you now have multiple real-world IP addresses that people can get to. How do we get them to the machine in your house you want to be accessible? First we need a connection between that machine and your VPS, and the easiest approach here is Wireguard. We only need a point-to-point link, nothing routable, and none of the IP addresses involved need to have anything to do with any of the rest of your network. So, on your local machine you want something like:
[Interface]
PrivateKey = privkeyhere
ListenPort = 51820
Address = localaddr/32
[Peer]
Endpoint = VPS:51820
PublicKey = pubkeyhere
AllowedIPs = VPS/0
And on your VPS, something like:
[Interface]
Address = vpswgaddr/32
SaveConfig = true
ListenPort = 51820
PrivateKey = privkeyhere
[Peer]
PublicKey = pubkeyhere
AllowedIPs = localaddr/32
The addresses here are (other than the VPS address) arbitrary - but they do need to be consistent, otherwise Wireguard is going to be unhappy and your packets will not have a fun time. Bring that interface up with wg-quick and make sure the devices can ping each other. Hurrah! That's the easy bit.
Now you want packets from the outside world to get to your internal machine. Let's say the external IP address you're going to use for that machine is 321.985.520.309 and the wireguard address of your local system is 867.420.696.005. On the VPS, you're going to want to do:
iptables -t nat -A PREROUTING -p tcp -d 321.985.520.309 -j DNAT --to-destination 867.420.696.005
Now, all incoming packets for 321.985.520.309 will be rewritten to head towards 867.420.696.005 instead (make sure you've set net.ipv4.ip_forward to 1 via sysctl!). Victory! Or is it? Well, no.
What we're doing here is rewriting the destination address of the packets so instead of heading to an address associated with the VPS, they're now going to head to your internal system over the Wireguard link. Which is then going to ignore them, because the AllowedIPs statement in the config only allows packets coming from your VPS, and these packets still have their original source IP. We could rewrite the source IP to match the VPS IP, but then you'd have no idea where any of these packets were coming from, and that sucks. Let's do something better. On the local machine, in the peer, let's update AllowedIps to 0.0.0.0/0 to permit packets form any source to appear over our Wireguard link. But if we bring the interface up now, it'll try to route all traffic over the Wireguard link, which isn't what we want. So we'll add table = off to the interface stanza of the config to disable that, and now we can bring the interface up without breaking everything but still allowing packets to reach us. However, we do still need to tell the kernel how to reach the remote VPN endpoint, which we can do with ip route add vpswgaddr dev wg0. Add this to the interface stanza as:
PostUp = ip route add vpswgaddr dev wg0
PreDown = ip route del vpswgaddr dev wg0
That's half the battle. The problem is that they're going to show up there with the source address still set to the original source IP, and your internal system is (because Linux) going to notice it has the ability to just send replies to the outside world via your ISP rather than via Wireguard and nothing is going to work. Thanks, Linux. Thinux.
But there's a way to solve this - policy routing. Linux allows you to have multiple separate routing tables, and define policy that controls which routing table will be used for a given packet. First, let's define a new table reference. On the local machine, edit /etc/iproute2/rt_tables and add a new entry that's something like:
1 wireguard
where "1" is just a standin for a number not otherwise used there. Now edit your wireguard config and replace table=off with table=wireguard - Wireguard will now update the wireguard routing table rather than the global one. Now all we need to do is to tell the kernel to push packets into the appropriate routing table - we can do that with ip rule add from localaddr lookup wireguard, which tells the kernel to take any packet coming from our Wireguard address and push it via the Wireguard routing table. Add that to your Wireguard interface config as:
PostUp = ip rule add from localaddr lookup wireguard
PreDown = ip rule del from localaddr lookup wireguard
and now your local system is effectively on the internet.
You can do this for multiple systems - just configure additional Wireguard interfaces on the VPS and make sure they're all listening on different ports. If your local IP changes then your local machines will end up reconnecting to the VPS, but to the outside world their accessible IP address will remain the same. It's like having a real IP without the pain of convincing your ISP to give it to you.
What I've ended up doing is renting a cheap VPS from a vendor that lets me add multiple IP addresses for minimal extra cost. The precise nature of the VPS isn't relevant - you just want a machine (it doesn't need much CPU, RAM, or storage) that has multiple world routeable IPv4 addresses associated with it and has no port blocks on incoming traffic. Ideally it's geographically local and peers with your ISP in order to reduce additional latency, but that's a nice to have rather than a requirement.
By setting that up you now have multiple real-world IP addresses that people can get to. How do we get them to the machine in your house you want to be accessible? First we need a connection between that machine and your VPS, and the easiest approach here is Wireguard. We only need a point-to-point link, nothing routable, and none of the IP addresses involved need to have anything to do with any of the rest of your network. So, on your local machine you want something like:
[Interface]
PrivateKey = privkeyhere
ListenPort = 51820
Address = localaddr/32
[Peer]
Endpoint = VPS:51820
PublicKey = pubkeyhere
AllowedIPs = VPS/0
And on your VPS, something like:
[Interface]
Address = vpswgaddr/32
SaveConfig = true
ListenPort = 51820
PrivateKey = privkeyhere
[Peer]
PublicKey = pubkeyhere
AllowedIPs = localaddr/32
The addresses here are (other than the VPS address) arbitrary - but they do need to be consistent, otherwise Wireguard is going to be unhappy and your packets will not have a fun time. Bring that interface up with wg-quick and make sure the devices can ping each other. Hurrah! That's the easy bit.
Now you want packets from the outside world to get to your internal machine. Let's say the external IP address you're going to use for that machine is 321.985.520.309 and the wireguard address of your local system is 867.420.696.005. On the VPS, you're going to want to do:
iptables -t nat -A PREROUTING -p tcp -d 321.985.520.309 -j DNAT --to-destination 867.420.696.005
Now, all incoming packets for 321.985.520.309 will be rewritten to head towards 867.420.696.005 instead (make sure you've set net.ipv4.ip_forward to 1 via sysctl!). Victory! Or is it? Well, no.
What we're doing here is rewriting the destination address of the packets so instead of heading to an address associated with the VPS, they're now going to head to your internal system over the Wireguard link. Which is then going to ignore them, because the AllowedIPs statement in the config only allows packets coming from your VPS, and these packets still have their original source IP. We could rewrite the source IP to match the VPS IP, but then you'd have no idea where any of these packets were coming from, and that sucks. Let's do something better. On the local machine, in the peer, let's update AllowedIps to 0.0.0.0/0 to permit packets form any source to appear over our Wireguard link. But if we bring the interface up now, it'll try to route all traffic over the Wireguard link, which isn't what we want. So we'll add table = off to the interface stanza of the config to disable that, and now we can bring the interface up without breaking everything but still allowing packets to reach us. However, we do still need to tell the kernel how to reach the remote VPN endpoint, which we can do with ip route add vpswgaddr dev wg0. Add this to the interface stanza as:
PostUp = ip route add vpswgaddr dev wg0
PreDown = ip route del vpswgaddr dev wg0
That's half the battle. The problem is that they're going to show up there with the source address still set to the original source IP, and your internal system is (because Linux) going to notice it has the ability to just send replies to the outside world via your ISP rather than via Wireguard and nothing is going to work. Thanks, Linux. Thinux.
But there's a way to solve this - policy routing. Linux allows you to have multiple separate routing tables, and define policy that controls which routing table will be used for a given packet. First, let's define a new table reference. On the local machine, edit /etc/iproute2/rt_tables and add a new entry that's something like:
1 wireguard
where "1" is just a standin for a number not otherwise used there. Now edit your wireguard config and replace table=off with table=wireguard - Wireguard will now update the wireguard routing table rather than the global one. Now all we need to do is to tell the kernel to push packets into the appropriate routing table - we can do that with ip rule add from localaddr lookup wireguard, which tells the kernel to take any packet coming from our Wireguard address and push it via the Wireguard routing table. Add that to your Wireguard interface config as:
PostUp = ip rule add from localaddr lookup wireguard
PreDown = ip rule del from localaddr lookup wireguard
and now your local system is effectively on the internet.
You can do this for multiple systems - just configure additional Wireguard interfaces on the VPS and make sure they're all listening on different ports. If your local IP changes then your local machines will end up reconnecting to the VPS, but to the outside world their accessible IP address will remain the same. It's like having a real IP without the pain of convincing your ISP to give it to you.
synagogue alternatives
Jun. 16th, 2025 02:08 pmcellioMy synagogue is being acquired [1] and this was the final nudge to find an alternative. This past Shabbat they cancelled our services in favor of the other place, so I went to Beth Shalom, which I last visited during Pesach. Beth Shalom is a large congregation, which is a little challenging for this introvert, but I assume that if I go there regularly I'll gradually meet people and maybe even be able to learn their names.
Their service is uplifting and pretty efficient. They're Conservative, so they include a lot of things that my current (Reform) congregation doesn't do, but it didn't make the service that much longer. I will need to practice the Hebrew in some unfamiliar sections so that I can sing the songs with them; I was kind of singing this time, hitting maybe one word in four and faking the rest. (I know how to read Hebrew; I'm just slow.)
I had not noticed that they had designated this week as Pride Shabbat until the rabbi spoke. I mean yes, I saw some pins and rainbow talitot and stuff, but I saw those the last time I was at Beth Shalom too, so that's just ordinary support/visibility stuff. And there'd been some signs outside, but I hadn't noticed dates. In other words, they integrated the already-welcome queer community into the Shabbat service, honoring people without replacing the whole service with a bunch of creative readings. (Temple Sinai's Pride Shabbat feels more like a poetry slam; Shabbat barely makes an appearance.) I haven't been to a bar or bat mitzvah at Beth Shalom yet, but I imagine it's the same idea there: celebrate together in the context of Shabbat. Conservative and of course Orthodox synagogues tend to prioritize the community, and Shabbat itself, integrating celebrations into the whole instead of carving them off as separate things as Reform is wont to do. It's refreshing.
They have a kiddush lunch every week, which is presumably the best way to meet and get to know people. During Sukkot I went there and ended up in a lunch conversation with another Babylon 5 fan who was explaining the show to a third person. (I haven't seen the fan again yet, alas.) This week I couldn't stay because we had a friend coming, but there'll be a next time and probably soon.
There was a passing comment about the senior rabbi's upcoming sabbatical. I don't know more than that, and I'll want to have a chat with him before, or as part of, joining there, but it's not urgent. There is also an associate rabbi who I like so far; I plan to soon start going to a weekly class he teaches. While exploring their web site I discovered that both rabbis have blogs, which I'm now subscribed to.
Beth Shalom, not unusually, does not publish their dues expectations; you need to have a conversation with someone. Large old congregations with large old buildings tend to have high dues, which I might not be able to afford, especially if they don't have the concept of an individual membership. It can be worked out I'm sure, but it's a little awkward and embarrassing to have that conversation, and I wish I had some data going into it. Oh well; we'll get there. The high holy days (the one time a year when this really matters) are not for a few months yet.
Rodef Shalom (the synagogue Temple Sinai cancelled services for) puts their services on YouTube, so I skimmed that service yesterday. I knew they were having a guest musician, Dan Nichols, as part of celebrating their rabbi's retirement. I knew from a past Dan Nichols visit that he leans toward creative songs and less liturgy (more of a concert than a service), but I was still surprised by what I saw. How do you have a Shabbat morning service that goes almost two hours and not do Kri'at Sh'ma or the T'filah?! By caring I am a minority in the Reform movement, I know, and while this is extreme, it's also a hint of where Rodef Sinai is going. It's time to be elsewhere.
[1] This is not how the leaders characterize it, but I have seen some of the sausage-making and I stand by this description.