Engineering for Slow Internet
1–10 of 406 posts
Re: Engineering for Slow Internet
#2I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far from land, and ice. This was at the same time OP was in Antartica. Whatever that constraint was, it's just contracting for the service and getting terminals to the sites. The polar coverage is relatively sparse, but still plenty, due to the extraordinarily low population.
Re: Engineering for Slow Internet
#3IMO author shouldn't have censored the app names. The world deserves to know.
Re: Engineering for Slow Internet
#4> Please keep in mind that I wrote the majority of this post ~7 months ago, so it’s likely that the IT landscape has shifted since then.
Not sure if this is serious or intended as a joke. It made me giggle nonetheless. Which is kind of sad.
Re: Engineering for Slow Internet
#5I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far…
Slow Internet isn't just remote places, it also crops up in heavily populated urban areas. It's sad that you had better connectivity above the Arctic circle than the typical connectivity with hotel WiFi. Bad connectivity also happens with cellular connections all over the place.
Re: Engineering for Slow Internet
#6I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far…
Not really the point of your post, but that sounds like a really cool trip. What were you doing up there?
Re: Engineering for Slow Internet
#7> Please keep in mind that I wrote the majority of this post ~7 months ago, so it’s likely that the IT landscape has shifted since then. Not sure if this is serious or intended as a joke. It made me giggle nonetheless. Which is kind of sad.
They're being obtuse. What "it's likely the IT landscape has shifted" actually means is "they got Starlink and their connection is fast now, and I know this for certain but I want to downplay it as much as possible because I'm trying to make a point".
Re: Engineering for Slow Internet
#8> Please keep in mind that I wrote the majority of this post ~7 months ago, so it’s likely that the IT landscape has shifted since then. Not sure if this is serious or intended as a joke. It made me giggle nonetheless. Which is kind of sad.
It’s serious presumably because Starlink coverage includes the poles now. 7 months ago was around the time they did a demo with the McMurdo base IIRC.
Re: Engineering for Slow Internet
#9Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions.
On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to connect to each AP as a train with 500 people on it all try to connect at the same time.
In Australia you're just 200ms from everything most of the time. That might not seem like much, but it really highlights which apps trip up on the N+1 request problem.
The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast.
Re: Engineering for Slow Internet
#10IMO author shouldn't have censored the app names. The world deserves to know.
Querying an exact match of a few strings on Google shows me that Slack is the very first example given in the blog post. For additional confirmation, the "6-byte message" screenshot lists an xoxc token and rich_text object, both of which you will frequently encounter in the Slack API. To be honest, I was expecting it to be Jira at first since I was unaware of Slack's size.
Searching for an exact match of "PRL_ERR_WEB_PORTAL_UNEXPECTED" gives away Parallels as the first example of a hard-coded HTTPS timeout.
So on, so forth.