dotwaffle

From a network point of view, BitTorrent is horrendous. It has no way of knowing network topology which frequently means traffic flows from eyeball network to eyeball network for which there is no "cheap" path available (potentially causing congestion of transit ports affecting everyone) and no reliable way of forecasting where the traffic will come from making capacity planning a nightmare.

Additionally, as anyone who has tried to share an internet connection with someone heavily torrenting, the excessive number of connections means overall quality of non-torrent traffic on networks goes down.

Not to mention, of course, that BitTorrent has a significant stigma attached to it.

The answer would have been a squid cache box before, but https makes that very difficult as you would have to install mitm certs on all devices.

For container images, yes you have pull through registries etc, but not only are these non-trivial to setup (as a service and for each client) the cloud providers charge quite a lot for storage making it difficult to justify when not having a check "works just fine".

The Linux distros (and CPAN and texlive etc) have had mirror networks for years that partially addresses these problems, and there was an OpenCaching project running that could have helped, but it is not really sustainable for the wide variety of content that would be cached outside of video media or packages that only appear on caches hours after publishing.

BitTorrent might seem seductive, but it just moves the problem, it doesn't solve it.

> also now includes a hazard perception test

I took my test nearly 25 years ago, and this was present then -- for the avoidance of doubt, the UK test has always been very thorough, though not quite as thorough as those in places like Finland where apparently they have skid pans and similar!

The "go x.yy" line in go.mod is supposed to be that MSGV, but `go mod init` will default it to the current version on creation. While you could have tooling like `cargo-msrv` to determine what that value would be optimal, the fact that only the latest two Go versions are supported means it's not particularly useful in most cases.

Now that I think about it more, when I've seen it happen before, it tends to be on projects that use dependabot / renovate. If any of those updates depend (directly or transitively) on a later version of Go, the go.mod would be bumped accordingly for them.

I have a vague feeling it was related to testcontainers or docker, and at the time that job's Go install was always at least 6 months behind. At least with recent Go, it'll switch to a later version that it downloads via the module proxy, that would have helped a lot back then :S

Just watch as most libraries now update their go.mod to say 1.25, despite using no 1.25 features, meaning those who want to continue on 1.24 (which will still have patch releases for six months...) are forced to remain on older versions or jump through lots of hoops.

It's a "minimum" version, not a dependency lock!

> Compared to 6+ intermediaries in a standard SWIFT payment

Huh? I think the message format in ISO20022 can only 3 intermediaries before having to resort to more complex mechanisms. Most SWIFT payments have 0 or 1 intermediaries.

At first glance I thought this was going to be a reinvented Sun Ray!

SSHFP records largely solves the host key problem, but yes, the user is the weak point in the chain there.

Hesiod uses txt records. I am using IN class records too, as I do not have a DNS provider that supports HS class... But that's fine, it works!

And I may well do. But it's probably not the best idea to do this on a larger scale, there are valid reasons why this is not a good thing to recommend -- if you miss one part (DNSSEC signing, or running a local validating resolver) you can end up with a vulnerable system.

A blog on this.

My TTL is lower than most people's SSH certificate validity duration, for sure :)

Good luck with that. DNS TXT records are used for a lot of infrastructure right now, from DMARC/SPF/DKIM to DNS-01 validation through LetsEncrypt afaik.

It would be rude of me to decline such an offer ;)

My DNS zones are not hosted on those servers, Google Cloud DNS does the dnssec signing, and there is a breakglass key installed on there too that when used automatically sends alerts out.

You'd have to compromise not only the root keys just to get into my infrastructure, but sign all the zones from there downwards, and intercept all DNS traffic leaving that server in the first place. That's secure enough for me.

I store my authorized_keys in DNS TXT records, that are DNSSEC signed, with a validating resolver on the box. I then just use "/usr/bin/hesinfo %u ssh" as my AuthorizedKeysCommand in OpenSSH.

I wrote a little tool that allowed you to "#include" other DNS records etc, but "hesinfo" is generally easily installable/available so it's just easier.