Live data from Hacker News

Engineering for Slow Internet

brr.fyi

21–30 of 406 posts

Re: Engineering for Slow Internet

#21
post #3

IMO author shouldn't have censored the app names. The world deserves to know.

Those I recognize (from interface, branding, strings, etc.): * Slack -- https://brr.fyi/media/engineering-for-slow-internet/load-err... * Signal (main screen) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * 1Password (config/about page) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * Zoom (updater screen on Mac) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d.…

You got all the same answers I did, which helps me determine how good my sleuthing skills are. I used exclusively strings, either API routes, error codes, or version/build numbers.

Re: Engineering for Slow Internet

#22
post #7
post #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.

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".

Or they could be making a joke about how quickly trends shift in IT. It's like how people joke (or at least used to joke) that you'd get a dozen new JavaScript frameworks daily.

Exaggeration for comedic effect, in other words.

Re: Engineering for Slow Internet

#23
post #2

I 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…

> I 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 don't think that this is a valid assessment of the underlying problem.

Slow internet means many things, and one of them is connection problems. In connection-oriented protocols like TCP this means slowness induced by drop of packets, and in fire-and-forget protocols like UDP this means your messages don't get through. This means that slowness might take multiple forms, such as low data rates or moments of high throughput followed by momentary connection drops.

One solid approach to deal with slow networks is supporting offline mode, where all data pushes and pulls are designed as transactions that take place asynchronously, and data pushes are cached locally to be retried whenever possible. This brings additional requirements such as systems having to support versioning and conflict resolution.

Naturally, these requirements permeate onto additional UI requirements, such as support for manually synching/refreshing, displaying network status, toggling actions that are meaningless when the network is down, rely on eager loading to remain usable while offline, etc.

Re: Engineering for Slow Internet

#24
> a lot of the end-user impact is caused by web and app engineering which fails to take slow/intermittent links into consideration.

Technology today is developed by, and for, privileged people. Has been that way for a while. Ever since you had to upgrade your computer in order to read the news, there has been a slow, steady slog of increasing resource use and conspicuous consumption.

I remember using the 9600 baud modem to get online and do the most basic network transactions. It felt blazing fast, because it was just some lines of text being sent. I remember the 2.5KBps modem, allowing me to stream pictures and text in a new World Wide Web. I remember the 5KBps modem making it possible to download an entire movie! (It took 4 days, and you had to find special software to multiplex and resume cancelled downloads, because a fax on the dialup line killed the connection) I remember movies growing to the size of CDROMs, and later DVDROMs, so those who could afford these newer devices could fit the newer movies, and those who couldn't afford them, didn't. I remember the insane jump from 5KBps to 1.5Mbps, when the future arrived. Spending days torrenting hundreds of songs to impress the cool kids at school, burning them CDs, movies, compiling whole libraries of media [hey, 15 year olds can't afford retail prices!].

I remember when my poor friends couldn't use the brand new ride-sharing services Uber and Lyft because you had to have an expensive new smartphone to hail them. They'd instead have to call and then pay for a full fare taxi, assuming one would stop for them in the poor neighborhood, or wait an hour and a half to catch the bus. I remember when I had to finally ditch my gaming laptop, with the world-class video card you could've done crypto mining on, because opening more than 5 browser tabs would churn the CPU and hard-drive, max out the RAM, and crash the browser. I remember having to upgrade my operating system, because it could no longer run a new enough browser, that was now required to load most web pages. I remember buying smartphone after smartphone after smartphone - not because the previous one stopped working, but because more apps required more cpu and more memory and more storage. I remember trying to download and run a chat app on my local machine, and running out of memory, because the chat app had an embedded web browser. I remember running out of my data cap on my cell phone because some app decided it wanted to stream a load of data as if it was just unlimited. I remember running out of space on my smartphone because 70% of the space was being used just to store the Operating System files.

I'm not complaining, though. It's just how the world works. Humanity grows and consumes ever more resources. The people at the top demand a newer, better cake, and they get it; everyone else picks up the crumbs, until they too get something resembling cake. I sure ate my share. Lately I try to eat as little cake as possible. Doesn't change the world, but does make me feel better. Almost like the cake is a lie.

Re: Engineering for Slow Internet

#25
What are the hopes for "engineering for slow internet" to happen, when people have engineered applications for "fast internet" when all we had was "slow internet".

Nice thought in theory but unnecessarily gives false hope.

Confluence/Jira sometimes need to download 20 megabytes in order to show a page with only text and some icons. I have a friend that tells me that in their company they had two jiras, one for developers, one for the rest of the company, because it was that dead slow.

I've lost all faith already that this will change for better.

Re: Engineering for Slow Internet

#26
I had a similar experience as the author on a boat in the south pacific. Starlink was available but often wasn't used because of its high power usage (60+ watts). So we got local SIM cards instead which provided 4G internet in some locations and EDGE (2G) in others.

EDGE by itself isn't too bad on paper - you get a couple dozen kilobits per second. In reality, it was much worse. I ran into apps with short timeouts that would have worked just fine, if the authors had taken into account that loading can take minutes instead of milliseconds.

Low bandwith, high latency connections need to be part of the regular testing of software. For Linux, there's netem (https://wiki.linuxfoundation.org/networking/netem) that will let you do this.

An issue that the anonymous blog author didn't have was metered connections. Doing OS or even app upgrades was pretty much out of the question for cost reasons. Luckily, every few weeks or so, we got to a location with an unmetered connection to perform such things. But we got very familiar with the various operating systems' ways to mark connections as metered/unmetered disable all automatic updates and save precious bandwidth.

Re: Engineering for Slow Internet

#27
post #2

I 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…

There’s a diner in SF I frequent. I usually sit 15 feet from the door, on a busy retail corridor, with Verizon premium network access. My iPhone XS reports two bars of LTE but there’s never enough throughout for DNS to resolve. Same at my dentist’s office. I hope to live in a post slow internet world one day, but that is still many years away. (The XS does have an Intel modem, known to be inferior to the Qualcomm fla…

I think this is a tough because a lot of bands have been repurposed for 5G and an Xs doesn’t support any of those.

Re: Engineering for Slow Internet

#29
post #26

I had a similar experience as the author on a boat in the south pacific. Starlink was available but often wasn't used because of its high power usage (60+ watts). So we got local SIM cards instead which provided 4G internet in some locations and EDGE (2G) in others. EDGE by itself isn't too bad on paper - you get a couple dozen kilobits per second. In reality, it was much worse. I ran into apps with short timeouts th…

> Low bandwith, high latency connections need to be part of the regular testing of software.

One size does not fit all. It would be a waste of time and effort to architect (or redesign) an app just because a residual subset of potential users might find themselves on a boat in the middle of the Pacific.

Let's keep things in perspective: some projects even skip testing WebApps on more than one browser because they deem that wasteful and an unjustified expense, even though it's trivial to include them on a test matrix, and this is a UI-only.

Re: Engineering for Slow Internet

#30
As a web developer I actually resisted much faster internet for ages.

Until 2022 I had a rock-solid, never-failed 7 megabit/s-ish down, 640k up connection and I found it very easy to build sites that others describe as blazing fast.

This was slow really by the standards of much of the UK population even by 2015.

So all I had to do was make it fast for me.

A change of provider for practical reasons gave me an ADSL2+ connection that is ten times faster; still arguably slower than a lot of residential broadband in the UK but not so helpfully.

So now I test speed on mobile; even in the south east of England it is not that difficult to find poor mobile broadband. And when it’s poor, it’s poor in arguably more varied ways.

Post reply on HN