Technology

It is quite real. The satellite links are like 10 Mbps. You go far enough south, and you cant even hit the satellite because it's over the horizon. There aren't any high-speed polar satellites. Companies don't send their satellites that far south because there are too few customers to justify the cost.

That's changing with starlink, though, since those ones are in a polar orbit.

Local mirrors and caching proxies.

I've worked in an environment like this. We had a local server for Windows and Mac updates. Direct updates were blocked. It's a solved problem, you just need developers to participate.

This is what IPFS is for. Instead of linking to a location that would be way far away off planet, it links to the content which could very well be cached on planet or on a relay station closer. Sure, one person has to pull it down from the incredibly far away place, but once it's pulled down at least one time, everybody else pulls it from the more local version that that person has. However, though, timeouts will need to be increased. Maybe not to some insanely stupid amount, but they will need to be increased somewhat.

Maybe Microsoft will let us have local accounts again?

This is one of the reasons why I preach against Electron apps and the “storage is cheap” argument. Additionally, it may also be really expensive for people in 3rd world countries to buy storage.

Instead of sneaker-net it will be rocket-net... and at a certain point you need an ~~on-prem~~ on-planet support team to just figure things out.

Yes, Windows peer to peer update downloads work over LAN. (In theory, I've never verified it.)

HTTP caching still works fine, if your proxy performs SSL termination and reencryption. In an enterprise environment that's fine, for individuals it's a non-starter. In this case, you'd want to have a local CDN mirror.

I remember there is some timeout flags you can do on curl that you can use in conjunction with git...but its been nearly a decade since Ive done anything of the sort. Modern day GitHub is fast-ish...but yeah bigger stuff has some big git issues.

Good points! Didn't know about Lemmyverse.net!

A bit of banging away later

I haven't touched Linux traffic shaping in some years

I've got a quick-and-dirty script to set a machine up to temporarily simulate a slow inbound interface for testing.

# !/bin/bash
# Linux traffic-shaping occurs on the outbound traffic.  This script
# sets up a virtual interface and places inbound traffic on that virtual
# interface so that it may be rate-limited to simulate a network with a slow inbound connection.
# Removes induced slow-down prior to exiting.  Needs to run as root.

# Physical interface to slow; set as appropriate
oif="wlp2s0"

modprobe ifb numifbs=1
ip link set dev ifb0 up
tc qdisc add dev $oif handle ffff: ingress
tc filter add dev $oif parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

tc qdisc add dev ifb0 root handle 1: htb default 10
tc class add dev ifb0 parent 1: classid 1:1 htb rate 1mbit
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 1mbit

echo "Rate-limiting active.  Hit Control-D to exit."
cat

# shut down rate-limiting
tc qdisc delete dev $oif ingress
tc qdisc delete dev ifb0 root
ip link  set dev ifb0 down
rmmod ifb

I'm going to see whether I can still reproduce that git failure for Cataclysm on git 2.47.2, which is what's in Debian trixie. As I recall, it got a fair bit of the way into the download before bailing out. Including the script here, since I think that the article makes a good point that there probably should be more slow-network testing, and maybe someone else wants to test something themselves on a slow network.

Probably be better to have something a little fancier to only slow traffic for one particular application

maybe create a "slow Podman container" and match on traffic going to that?

but this is good enough for a quick-and-dirty test.

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
-- Andrew S. Tanenbaum

heh! Thats such a funny/cool protocol.