Fossil Friday
Jun. 20th, 2025 06:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
purplecat
Dilophosaurus. Image stolen from Great Dinosaur Discoveries by Darren Naish, though wikipedia is using a very similiar image under a Creative Commons licence.
purplecatDilophosaurus. Image stolen from Great Dinosaur Discoveries by Darren Naish, though wikipedia is using a very similiar image under a Creative Commons licence.
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.
Inca Trail: Day 3
Jun. 19th, 2025 07:31 pmpurplecatUnlike Day 2, which was hard work and not terribly rewarding, we loved Day 3 on the Inca Trail. Once again we set off almost as soon as it was light. Wilbert's plan was again to have all the walking done before lunch, in part because of convenience, but this time he also knew there were a lot of ruins to see and was quite keen to get us to them before everyone else got there. In this he was successful. We generally got to look around ruins on our own, but a big group would arrive just as we were leaving.
The first of these was Runkuraqay which Wilbert described as a fuel station for people, which we interpreted as meaning an Inn.
( Runkuraqay Pictures )
We then went up and over a pass, a little lower than Dead Woman's Pass the previous day, and a shorter climb because we'd started higher. Then we came down towards Sayacmarca, a much larger ruin.
( Pictures )
Once we left Sayacmarca we continued down to about 3,500m. After that the trail was much more level. Strava shows a steady climb, but I felt much more able to look about me at the scenery rather than paying close attention to where I was putting my feet. As the trail levelled out we got to Qunchamarka, another Inn. It wasn't clear how to access this, but we walked around the outside. I think at this point we were up in a Cloud Forest - though I'm hazy on the difference between Cloud Forest, Rainforest and regular forest, all of which I think we walked through at various points.
( Pictures )
Wilbert spent some time telling us about the Inca Tunnel we would meet. B was pretty sure this was just a large fallen rock which the Inca's had run the path under. Wilbert got distracted at this point since he found a dog in the brush above the tunnel. After some encouragement he got it to climb down and it ran off down the path ahead of us. We met it again at the next campsite where, presumably, it belonged. I'm afraid we failed to photograph the dog, so you'll just have to imagine it.
( B did photograph the tunnel, however )
We arrived at our campsite in good time for lunch. The camp was above another Inca ruin, Phuyupatamaca, and after lunch Wilbert packed us off to take a look at it on our own. This involved going down some steep steps and it seemed like the water source for the camp was at the bottom, because we were passed by a lot of porters carrying water back up them. At the time we assumed he sent us to look at it then, rather than the next day, because the plan was to leave before light so that we would get to Machu Picchu in time to meet up with the rest of our group. However it transpired that pretty much everyone was leaving before light and we seemed to be the only party who's guide thought to encourage us to check out the ruins we would miss in the dark.
( Pictures of Phuyupatamarca )
We had an excellent position in the camp right next to a large rock that overlooked the view. We were next to the camp of a group of three people who were on the "Luxury" tour. Wilbert was very contemptuous - they had three guides and a masseuse. They were also served cocktails in glasses made of glass when they reached camp. The most disconcerting thing was that they were played into camp by Andean pipes. B felt he would have been quite happy with the cocktails and the larger tents (including a shower tent!) and so on, but felt he wouldn't have coped with the pipes.
( Pictures in the Camp )
The first of these was Runkuraqay which Wilbert described as a fuel station for people, which we interpreted as meaning an Inn.
( Runkuraqay Pictures )
We then went up and over a pass, a little lower than Dead Woman's Pass the previous day, and a shorter climb because we'd started higher. Then we came down towards Sayacmarca, a much larger ruin.
( Pictures )
Once we left Sayacmarca we continued down to about 3,500m. After that the trail was much more level. Strava shows a steady climb, but I felt much more able to look about me at the scenery rather than paying close attention to where I was putting my feet. As the trail levelled out we got to Qunchamarka, another Inn. It wasn't clear how to access this, but we walked around the outside. I think at this point we were up in a Cloud Forest - though I'm hazy on the difference between Cloud Forest, Rainforest and regular forest, all of which I think we walked through at various points.
( Pictures )
Wilbert spent some time telling us about the Inca Tunnel we would meet. B was pretty sure this was just a large fallen rock which the Inca's had run the path under. Wilbert got distracted at this point since he found a dog in the brush above the tunnel. After some encouragement he got it to climb down and it ran off down the path ahead of us. We met it again at the next campsite where, presumably, it belonged. I'm afraid we failed to photograph the dog, so you'll just have to imagine it.
( B did photograph the tunnel, however )
We arrived at our campsite in good time for lunch. The camp was above another Inca ruin, Phuyupatamaca, and after lunch Wilbert packed us off to take a look at it on our own. This involved going down some steep steps and it seemed like the water source for the camp was at the bottom, because we were passed by a lot of porters carrying water back up them. At the time we assumed he sent us to look at it then, rather than the next day, because the plan was to leave before light so that we would get to Machu Picchu in time to meet up with the rest of our group. However it transpired that pretty much everyone was leaving before light and we seemed to be the only party who's guide thought to encourage us to check out the ruins we would miss in the dark.
( Pictures of Phuyupatamarca )
We had an excellent position in the camp right next to a large rock that overlooked the view. We were next to the camp of a group of three people who were on the "Luxury" tour. Wilbert was very contemptuous - they had three guides and a masseuse. They were also served cocktails in glasses made of glass when they reached camp. The most disconcerting thing was that they were played into camp by Andean pipes. B felt he would have been quite happy with the cocktails and the larger tents (including a shower tent!) and so on, but felt he wouldn't have coped with the pipes.
( Pictures in the Camp )
Inca Trail: Day 2
Jun. 18th, 2025 07:15 pmpurplecatDay 2 on the Inca Trail was the least fun of the trip. We had to climb 1,200m to get up and over "Dead Woman's Pass". Wilbert, our guide's plan was to get going as soon as it was light (around 5:30am) and aim to reach our campsite at lunch time. His reasoning was to get most of the actual climbing done while we were in the shadow of the tall mountains around us. It also made life simpler for the support team who wouldn't have to pick somewhere en route, unpack to make lunch, and then pack up again to get to the campsite. He also, I think, quite liked the idea of catching up with the group that were ahead of us who were starting around 700m up the climb and who would be having lunch at our evening campsite. In the event we arrived at our campsite about 2 hours after they had left, having another pass to go over before they got to their campsite for the night.
We were on modern trails, according to Wilbert, and although I think we passed some Inca ruins at a campsite en route, we didn't look at them. Wilbert's explanation for the route wasn't entirely clear. As I understood it the original Inca road went over a different pass, though I never figured out if it was higher or lower. I got the impression a large section of the road from Cusco to Machu Picchu was destroyed by the Inca themselves, triggering landslides, in order to prevent the Spanish finding their way along it, so maybe that explains why we were following a modern alternative.
We started at about 3000m. At around 3,700m I began to feel quite tired and a little concerned about the 500m still go. At 3,900m as we came out of the shade and into the sun, my legs felt like lead and I made it up to the pass only by doggedly walking 300 steps and then stopping (300 steps, if you are interested, gets you up about 50m). At the time we put this down to the fact Manchester is super-flat and so our uphill muscles don't get a lot of exercise. However, I wasn't remotely stiff the next day, at which point it occured to us to measure my blood oxygen using my watch. It was down at 81%, rising to 88% if I took several deep breaths (B., in contrast was generally in the high 80s/low 90s). So it's possible the issue was lack of blood oxygen - even though I wasn't showing any other symptoms of altitude sickness.
Once over the pass we descended around 600m to our campsite. I badly wanted to go to sleep, but B. and Wilbert forced me to have some lunch first. Then I slept for an hour, after which I felt much more like myself.
We walked a total distance of just under 12km.
( Pictures under the Cut )
We were on modern trails, according to Wilbert, and although I think we passed some Inca ruins at a campsite en route, we didn't look at them. Wilbert's explanation for the route wasn't entirely clear. As I understood it the original Inca road went over a different pass, though I never figured out if it was higher or lower. I got the impression a large section of the road from Cusco to Machu Picchu was destroyed by the Inca themselves, triggering landslides, in order to prevent the Spanish finding their way along it, so maybe that explains why we were following a modern alternative.
We started at about 3000m. At around 3,700m I began to feel quite tired and a little concerned about the 500m still go. At 3,900m as we came out of the shade and into the sun, my legs felt like lead and I made it up to the pass only by doggedly walking 300 steps and then stopping (300 steps, if you are interested, gets you up about 50m). At the time we put this down to the fact Manchester is super-flat and so our uphill muscles don't get a lot of exercise. However, I wasn't remotely stiff the next day, at which point it occured to us to measure my blood oxygen using my watch. It was down at 81%, rising to 88% if I took several deep breaths (B., in contrast was generally in the high 80s/low 90s). So it's possible the issue was lack of blood oxygen - even though I wasn't showing any other symptoms of altitude sickness.
Once over the pass we descended around 600m to our campsite. I badly wanted to go to sleep, but B. and Wilbert forced me to have some lunch first. Then I slept for an hour, after which I felt much more like myself.
We walked a total distance of just under 12km.
( Pictures under the Cut )
Costume Bracket: Round 4, Post 2
Jun. 17th, 2025 06:46 pmpurplecatTwo Doctor Who companion outfits for your delectation and delight! Outfits selected by a mixture of ones I, personally, like; lists on the internet; and a certain random element.
( Outfits below the Cut )
Vote for your favourite of these costumes. Use whatever criteria you please - most practical, most outrageously spacey, most of its decade!
Voting will remain open for at least a week, possibly longer!
Costume Bracket Masterlist
Images are a mixture of my own screencaps, screencaps from Lost in Time Graphics, PCJ's Whoniverse Gallery, and random Google searches.
( Outfits below the Cut )
Vote for your favourite of these costumes. Use whatever criteria you please - most practical, most outrageously spacey, most of its decade!
Voting will remain open for at least a week, possibly longer!
Costume Bracket Masterlist
Images are a mixture of my own screencaps, screencaps from Lost in Time Graphics, PCJ's Whoniverse Gallery, and random Google searches.
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.
Inca Trail: Day 1
Jun. 16th, 2025 08:07 pmpurplecatWe did our Inca Trail holiday with Explore! who (out of necessity as I understand it) subcontracted to a local tour company. At some point something went wrong with getting permits for the trail. The story we were told was that the local agent forgot to apply for our permits, but several other people in the group had had permits delayed, so we concluded that there had been a more general permit mix-up which was simplified for our consumption as "forgot to apply for your permits". The up-shot of all this was that instead of travelling as part of a group of ten walkers with a guide, cook and porters it was just the two of us with a guide, cook and porters, setting out a day after everyone else with the aim of catching up with them at Machu Picchu. This was a mixed blessing, we got a lot more time with our guide and didn't have to worry that we were slowing anyone down, on the other hand it felt like an awful lot of staff for just us and even though our guide as very good at leaving us alone for various stretches, or sending us off on our own to explore things, it was quite intense.
( Photos and more under the cut! )
( Photos and more under the cut! )
The Prince With a Thousand Enemies
Jun. 14th, 2025 08:52 aml33tminionI finished reading Erica the rest of the Princess Academy series by Shannon Hale. There's definitely a whole lot to like about the series. I'm always looking for good stuff to read to Erica, so grateful to Melissa for recommending that one.
For our next book, we've started on Watership Down, which has been on my "I should read this sometime" list for a long time.
Speaking of rabbits, it seems to be a good time for them this year. I've never seen so many about in the neighborhood, especially near the Knox bike path out back of Kendall Square.
For our next book, we've started on Watership Down, which has been on my "I should read this sometime" list for a long time.
Speaking of rabbits, it seems to be a good time for them this year. I've never seen so many about in the neighborhood, especially near the Knox bike path out back of Kendall Square.
