[marten-de-vries]

From the article:

> Scripts are delayed only when added dynamically or as async. Tracking images are always delayed. This is legal according all HTML specifications and it’s assumed that well built sites will not be affected regarding functionality.

(emphasis mine)

[peterwwillis]

I don't know about you, but I don't browse the World Wide Implements-The-Specification-Perfectly Web.

[mquander]

If you aren't complaining because it violates the spec, what are you complaining about? Is any change to any detail about how a browser works necessarily bad?

[mehrdadn]

I understand the complaint. Let me put it this way: how would you feel if your ISP was delaying your connections to a subset of websites for a few seconds? It wouldn't violate any specs, as far as I know. But a lot of people have expressed the sentiment that they don't want middlemen messing with websites. It's not clear to me that Firefox qualifies as an exception to the rule, especially if this becomes something other browsers adopt.

[peterwwillis]

It's not even a NN-type middlemen issue for me, though that is exactly what's going on here. The bigger problem for me is causing regressions for users. On top of that they're causing regressions just because they don't like X traffic, and they're not even exclusively affecting X traffic - they're affecting unrelated traffic too. It's just an incredibly arrogant, annoying, bad thing to do to users who never requested this to begin with.

[yjftsjthsd-h]

Should only affect pre-broken code. Like complaining that a compiler is doing something with undefined behavior than you wanted: I get that it's annoying, but maybe fix your code so it's not a problem?

[peterwwillis]

This isn't even a broken code issue. This is a totally unnecessary functionality regression issue. Instead of just loading a page, they're waiting four seconds to load the page, because the page uses an asset on a domain they flag as a tracking domain.

This is like if the compiler generated loops with 4000ms sleeps because the app links a library the compiler thinks is annoying.

Technically the compiler never said it wouldn't add random sleeps into loops. It's totally in spec! What's the big deal?

Meanwhile, my app is slow now. Or in the case of some apps, actually broken for active use cases where it used to work fine. Which, again, is totally regression by any QA standard.

[frenchy]

I would go to my package manager and install a new ISP, of course /s

[TeMPOraL]

You should expect it, though.

[peterwwillis]

I have both written software for standards-based protocols, and used software written to standards-based protocols, so no, I would not expect it.

Not breaking backwards compatibility for existing users is the golden rule of software support. When an unfortunate pull-requester attempts to break backwards compatibility with Linus Torvalds' software, he has some very choice language to complain about the practice. If they were attempting to break backwards compatibility just because they dis-liked some particular app or service or use case, he might even use foul language.

Fortunately, I am a very well behaved and good little HN user, so I will not repeat that language here. But imagine what Linus would have said, really loudly, with all capital letters. There. That's better.

[testvox]

Linux breaks backwards compatibly all the time. Just not for userland programs. But if you are expecting your kernal module to be low maintenance you are in for a surprise...

[peterwwillis]

The kernel has a clear definition of what will be backwards compatible, and what never will be. In-kernel interfaces are never stable, and kernel-to-userspace interfaces are very stable, with an ABI docs directory breaking out what is and isn't.

https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690...

If the kernel's user interface just started blocking on open for 4000 milliseconds for no apparent reason, people would not be happy. Firefox expects users to demand that app writers edit, recompile, test, and ship them a new app to prevent the block. This is <insert lots of not very nice adjectives>.

[zlynx]

This is an interesting example because the kernel's open() interface blocks for 4,000 ms all the time. Heavy swapping or the ext3 journal is full and some other app just called fsync().

Apps have to handle it. If they don't, because for example, they access the disk while also trying to be a display compositor, then they are simply broken. It does not matter if the kernel is usually fast enough. Because sometimes it isn't.

[mehrdadn]

Do you know what the reason for this distinction is? On Windows, it seems kernel-mode APIs seem to stay quite stable as well... there are exceptions mostly on the device driver side because hardware tends to evolve (e.g. display/graphics drivers), but generic drivers (= kernel modules) generally seem to be able to rely on backwards-compatibility too.

[yjftsjthsd-h]

My understanding is that it's to intentionally discourage trying to keep things out of tree, where they will inevitably break in worse ways. It also makes the GPL enthusiasts happy, but I doubt that was Linus's big goal.