This is still the header! Main site

Trivial Inconveniences are Underappreciated

This is post no. 43 for Kev Quirk's #100DaysToOffload challenge. The point is to write many things, not to write good ones. Please adjust quality expectations accordingly :)

Those who appreciate freedom (either in software or in a broader sense) often blame people for giving it up for convenience.

If only everyone was making a little bit more effort and was using Linux; Microsoft would go bankrupt, there would be less spying, more software options, and everyone would be happier. Likewise: just leave Facebook and build your own blog. (And then you can also turn all this into a social network, just set up these 23 things & pass the relevant test suite.)

I actually used to be a fan of indieweb; here is an article I wrote about its fancy auth protocol (which is, by the way, a lot better than most of what we're using these days). And yet... I still got to implement all these things. Well. One day.

(Maybe once everyone finally gets their own domain name.)

And yet... people just keep not doing inconvenient things.

A "servers" example

Once upon a time, I had a server running on a local network. I also had an Android phone. This is the dream I was hoping for about 20 years ago: I have an always online system that I can connect to whenever I want. How awesome is that?

As it turns out, "whenever I want" didn't quite end up happening that often.

Even though it was totally doable. All I would need to do is:

I was also running Miniflux (the RSS reader) on the local network. Not even a yubikey was needed: just fire up the VPN.

These are definitely doable things. And yet... they were... not... really being done.

The update

I can now just type on my phone; it'll load it up.

Meanwhile, I can connect to my Windows desktop (yes I know... but... that's kind of part of the point) by starting the RDP app (one click) and selecting the connection (another click).

I seem to be doing these two things a whole lot more.

The point

There is not a whole lot of difference between these. And yet... just having to go through trivial steps each time makes you consider whether it's worth it or not, every single time.

Even if you know this.

This is especially underappreciated in the Free Software world. Yes, you can technically make it to work; whether many users will actually do it often gets forgotten. But the same is also true for modifying software: if it takes three days of work to just recompile the thing with debug symbols, in practice you won't see much benefit from having the source code. Same if it's five million lines of ugly code.

(Compare this to Emacs; extending it definitely has a learning curve, but it's a curve, not a cliff. You can get from "let's rebind this key" to "here is a new major mode" without ever having to Set Up a Development Environment.)

... more about that VPN setup

I'll just also refer everyone to Remembering the LAN.

Yes, Tailscale (the VPN in question) is a proprietrary product (it's pretty much free for one-human-sized entities though). However... it exemplifies "simplicity" fairly well.

It's really easy to setup. You download the thing. You do authentication. And then it just works. Even on Android, you can keep it running all the time. Your local LAN servers will be just there. And you don't have to switch it off even if you're home; it'll be smart and not make a round trip somewhere.

You also don't need to care about how your servers get onto the network. One time, one of mine found itself behind a double NAT (thanks, local ISP). Tailscale didn't particularly care; I could still ping & connect (although it was via one of their TURN servers I think)... letting me fix the double NAT problem from half a planet away. (My forwarded SSH port obviously wouldn't have worked.)

Yes, you could do the same thing with Wireguard and very clever configs. In fact... Tailscale is mostly just Wireguard and clever configs. But this simplicity matters.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.