Hacker News Reader

Comment by josephg | Hacker News Reader

About 10 years ago I tried installed Little Snitch on my laptop. I set it up to check with me every time any native app tried to connect to the internet. "Here we go" I thought. "I'm going to actually see what apps are doing!".

I think I naively thought I'd end up with 10 rules or something, blocking telemetry. Oh what a sweet naive child I was. Its constant. Everything on my computer seemed to use about 8 different telemetry and update services. The sheer number of packets of environmental waste being produced every second by modern computers is breathtaking. It never stops.

Reading this article, I wonder what would happen if you tried selling software the old way again. "Buy our software! Pay once. We'll mail you out a USB stick with the program on it. Our software does not access the internet." It would be terribly inefficient, but it'd probably be fun to try. It would definitely force a lot more rigour around releases & testing.

View on HN

It’s got to the point where I turn off my WiFi now to do performance-sensitive work, because of the boost that killing all this background rubbish gives. Anything I need online I can just offload to my phone while my computer is offline.

The problem with doing that, is that the standard TCP timeout is 60 seconds.

All of a sudden, you are beset with 60-second hangs.

You just gave me flashbacks of mistyping a folder share name on windows and having the whole PC lock up for a minute or two.

If the computer doesn't have any online network connection, shouldn't it outright error? I understand that the timeout sucks when your network is not connected to the internet but still alive, then that's an issue, but if there is no connection at all, why would the timeouts matter?

It wouldn't be able to open a TCP connection without knowing what IP address / interface to use.

You're right--it should outright error. You should only see timeouts like that if you were dropping the packets from some middleware or middlebox, but your client still had a valid IP address.

> All of a sudden, you are beset with 60-second hangs.

No, that's not how it works. Frankly, I'm astonished to see this claim here.

Depends.

I have a couple of apps on my computer that do exactly that.

I am looking forward to learning how it does work...

> I am looking forward to learning how it does work...

It's basic sockets. If you call connect() when the internet is disabled, the errno is ENETUNREACH.

The higher-level API are built on sockets. If any apps are misbehaving, they're simply badly coded.

> It's basic sockets.

Yup. I've done a bit of that stuff, in my time.

> If any apps are misbehaving, they're simply badly coded.

Plenty of that stuff, going around.

Might want to ease back on the "instant insult" thing. Not a good look.

> Yup. I've done a bit of that stuff, in my time.

So are you willing to admit now that "the standard TCP timeout" was a misdiagnosis of your problem?

You appeared to be projecting a personal problem with some unnamed badly coded apps onto everyone, as if it were inevitable, but the original commenter who said they turned off WiFi obviously does not experience this problem, and neither do I for that matter.

I don't think you can get ENETUNREACH from recv though. If the request was sent, it'll time out.

It can cause problems to flip off the internet when you already have open connections, though there are also API to detect changes in network availability. But I don't see that as a significant problem for "I turn off my WiFi now to do performance-sensitive work". First turn off WiFi, then launch the app you need, in that order. Problem solved.

You're not thinking like a systemd developer. The right thing to do is to ignore all anecdotes and direct evidence that a problem exists. I am talking about systemd renaming your network interfaces because you added or removed hardware.

systemd should add and remove interfaces connected in the exact same hardware path with the same name they had before.

Default literally insane legacy behaviour is just vomiting eth${RAND} where RAND depends on racing conditions.

My educated guess is that people that insist on using the legacy eth${RAND} never had a surprise random firewall and routing rules suddenly apply to different interfaces at a inconvenient time, making production halt and catch on fire, yet.

hardware paths change when you add or remove hardware. systemd developers deny this despite it affecting half of all desktop computers in existence. Your one network jack used to be eth0, systemd now changes it each time you add or remove hardware and insist they're making it more stable instead of more variable whilst they are making it more variable.

Yep. I've experienced on several computers that the systemd-approved "predictable" network device name changes when adding or removing a SSD. The solution is to turn off the network device renaming and allow the single ethernet interface in the machine to always be known as eth0.

systemd developers like to come up with clever solutions to the problems they care about, and ignore the side effects for any use cases they don't care about. And quite often those afflicted use cases are the ones most people would consider to be the more typical use cases.

Because of systemd I often have to add udev rules to rename my devices to something consistent, which has the advantage I can use even more sensible names, like "upper" and "lower", or "eth" and "wifi", but the disadvantage I have to learn udev.

The problem with this is some apps do incredibly stupid things. Now I'm not saying the operating system itself, but I had some ide screw off and go into long pause mode when my laptop was in airplane mode.

I'm sure there are stupid apps out there, but "the standard TCP timeout" was a misdiagnosis of the problem.

Just a wrap-up.

It was a badly-written comment. I meant some apps (and background tasks) on my computer hang. Most deal with it, but a surprising number don’t. I gave up on sniffing with Terminal and other tools, trying to figure out which ones. I have a number of dev tools installed on my computer, and a lot of those have a … casual … approach to quality.

I have no issue admitting fault (I do it way too often), but I don’t really dig rewarding boorish behavior, so I just figured I’d leave it alone.

> I wonder what would happen if you tried selling software the old way again. "Buy our software! Pay once. We'll mail you out a USB stick with the program on it. Our software does not access the internet."

FWIW all of my Mac and iOS apps are upfront paid, with no telemetry or server-side component.

Of course I don't distribute them via snail mail though.

I'm doing pretty well. I'm certainly not rich, and probably not making as much money as corporate software engineers in the US, but I'm doing better financially than the majority of people. It's not impossible to follow the old business model.

How do you know they don't have telemetry?

I wrote them. I'm baffled by your question.

I (and presumably the commenter you're responding to) initially read "all of my Mac and iOS apps" as "all of the Mac and iOS apps I use" instead of "all of the Mac and iOS apps I've written".

Did you and the other replier stop reading my comment after the first sentence? Because the second and following sentences make very clear—e.g., "distribute"—that I was talking about apps developed and sold by me.

I preferentially select for this software model. What applications to you make and where might I find them?

I eagerly and quickly pay for major version upgrades to the independent software I buy. I’d like that model to stick around.

> What applications to you make and where might I find them?

https://underpassapp.com

Thank you. Just bought StopTheMadness Pro and StopTheScript.

And then Minecraft writes to a log 18,000 times a second, moaning about being unable to contact the telemetry provider until your disk fills up.

I don’t know if they ever fix that bug, because I uninstalled the thing. The third-party launchers didn’t have that problem.

Have you tried using Linux?

Reply on news.ycombinator.com