This one drives me nuts. Not just on Mac, also on iPhone/iPad. It's 2026, and 5G is the killer feature advertised everywhere. There's no reason to default to downloading gigabytes of audio files if they could be streamed with no issue whatsoever.

I'm on 5G right now and it just struggled to load the HN front page due to local network congestion. At times of day when it's not congested it reaches 60-90Mbyte/s in the same physical location

Spotify just gave up while trying to show me my podcasts. I can't listen to anything not already downloaded right now.

Yet at 3am I'll be able to download a 100GB LLM without difficulty onto the same device that can't stream a podcast right now.

Unfortunately I don't think 5G is the streaming panacea you have in mind. Maybe one day...

Shared medium will always have congestion. It will never get better. Technology can get faster, but congestion is forever.

Only reason I still download from Apple Music to device is for lossless and hi-res lossless, which would otherwise use a lot of cellular data.

On 5G, it depends. There are still plenty of people around the world who don't have unlimited data plans.

Then they can enable downloads in the settings. I’m not saying they should remove the feature. I’m saying setting this as a default on a non-budget device is a bad design choice.

Europe is nice this time of year

“It was careless, blatantly amateuristic, and lacking any ambition, to put it gently. Microsoft unworthy.”

Seems to be perfectly on brand for Microsoft, I don’t see the issue.

LLM infested crap, directly pushed to customers without any pushback

so standard Microslop

Hell naw

contingency plan: Don't build your data center out of wood.

Plastic is made from the same stuff as gasoline.

Drain cleaner and hydrochloric acid makes salt water. Water is made of highly explosive hydrogen. Salt is made of toxic chlorine and explosive sodium.

Competition is always good. It's sad that there's been so little alternatives in the past. I'm glad that this is now slowly changing.

What we should work towards, though, is interoperability and open source solutions.

That's still a thing. Happens to me as we speak.

For me it just doesn't resolve at all on Cloudflare dns. So annoying.

“Not a shutdown—something worse. The routers didn't go silent. They screamed.”

“This wasn't a cascade—it was coordinated demolition.”

puking noises

I'm glad I'm not the only one who noticed that and got yucked by it. I was genuinely looking for a contact email on the webpage to complain to them about it. Such pretty visualization of data to then have LLM garbage explain it.

I’m learning there’s a significant portion of the population that is completely unbothered and unnoticing of AI slop smell. Some days I wish I could ignore or tolerate it too, given how prevalent it has become so quickly - but it repulses me too much.

Maybe some college of theirs on HN recognized the story and shared it with them.

“cannot contact port 25 on <remote host>” may very well be a configuration error. How should the program know?

>How should the program know?

if we're talking about logs from our own applications that we have written, the program should know because we can write it in a way that it knows.

user-defined config should be verified before it is used. make a ping to port 25 to see if it works before you start using that config for actual operation. if it fails the verification step, that's not an error that needs to be logged.

What about when the mail server endpoint has changed, and for whatever reason, this configuration wasn’t updated? This is a common scenario when dealing with legacy infrastructure in my experience.

the whole point of the essay here is that you should make a distinction between errors that you care about and plan to fix, and errors that you don't care about and don't intend to do anything about. and if you don't intend to do anything about it, it shouldn't be logged as error.

i'm following the author's example that an SMTP connection error is something you want to investigate and fix. if you have a different system with different assumptions where your response to a mailserver being unreachable is to ignore it, obviously that example doesn't apply for you. i'm not saying, and i don't think the author is saying that SMTP errors should always or never be logged as errors.

when the mailserver endpoint has changed, you should do the thing that makes sense in the context of your application. if it's not something that the person responsible for reviewing the logs needs to know about, don't log it. if it is, then log it.

So when the random error on a remote party happens at one time your system ignores it, bu when it happens at another time, it prevents the server from booting? That's a very brittle system.

log level error prevents your server from booting? i'm pretty sure that's not how logging works.

Would it make sense to consider anything that prevents a process from completing it's intended function an error? It seems like this message would fall into that category and, as you pointed out, could result from a local fault as well.

SMTP clients are designed to try again with exponential backoff. If the final attempt fails and your email gets bounced, now that's an error. Until then, it's just a delay, business as usual.