freedinosaur's comments

https://github.com/hyprspace/hyprspace is built on top of that. It's remarkably simple: libp2p's DHT + libp2p's NAT punching + TUN device.

I don't think it offers authn/authz, but that's fine: neither does my ISP. I just want SSH reachability.

> In theory, there is no path for a malicious Tailscale control plane to remotely execute code on your machine, unless you happen to run network services that are designed to allow it, like an SSH server with Tailscale-backed authentication.

Now I feel less crazy for not using Tailscale SSH for similar reasons.

I'd like to see a security evaluation of Tailscale, on a per feature basis.

I'd like to see tailscaled run with far fewer privileges.

Is there a Tailscale alternative that just does Wireguard + NAT traversal and doesn't try to do key management?

> Consider removing any mention of ESP/XBOOTLDR from /etc/fstab, and just let systemd-gpt-auto-generator do its thing.

TIL! My NixOS configuration just got a little bit simpler, and more uniform between machines.

The root partition already contains a set of empty directories, and Lennart has been working on reducing those where possible (see usr-merge).

TIL. Maybe I could get into the habit of using branches for experiments, and then including the branch name in --profile-name.

> Specialisations will allow me to run a stable and candy track, on per generation.

Typos:

Specialisations will allow me to run a stable and canary track, one per generation.

This makes testing changes easier in other ways too: when I make experimental changes, I'm reluctant to commit them until I know they're working, since I like being able to checkout an old commit and know it boots. In practice this means I end up with a dirty checkout, and uncertainty on which changes have been tested.

In theory I could manage this with git rebasing and/or tagging, but in practice I lose confidence in whether I've accurately tracked.

With specialisations, I'd comfortably commit an experimental change to my canary track, even though it might break, safe in the knowledge that the stable track continues to boot.

TIL specialisations: https://nixos.wiki/wiki/Specialisation

I plan to use this for testing changes to my boot units.

In theory, plain old generations allow you to safely test changes to boot units, by allowing you to jump to the previous generation. In practice, this involves remembering which generations have known-good boots.

Specialisations will allow me to run a stable and candy track, on per generation.

What other usecases do specialisations improve?

It feels odd that Github is deciding this policy.

A high-impact package on another forge wouldn't be subject to the same constraint.

This seems more approachable than NixOS/Guix, which I see as state or the art for declarative hosts.

https://discourse.nixos.org/t/documentation-team-flattening-... aims to flatten the learning curve for NixOS.

As a keen Sourcehut subscriber that's disappointing. I don't care much for cryptocurrency, but prefer my service providers to be far less selective than this.

Sourcehut is open first, so all is not lost: those excluded could host their own.

On balance, I'm looking at alternatives, but might stay.

The motte: censoring abuse and threats.

The bailey: Twitter censoring NY Post during election time.

Disclaimer: I don't follow US politics, but do follow online censorship.

+1 to the winding down by trying to use alternatives, and working on the gaps

Facebook Messenger < Signal < XMPP. I have a few stragglers on FB Messenger, but don't have the app installed.

Facebook Marketplace < Gumtree. Gumtree at least is searchable without an account.

I subscribe to Mastodon and Twitter accounts via RSS.

Github < Sourcehut: I only use Github for contributing to other repos.

Mobile Linux > Open app stores > closed app store: WIP. :)