gsnedders

You are, of course, correct.

But the fact that they made a new release with it undeprecated shows they _do_ care about their users (direct and indirect), and at least from my point of view (both from the Python ecosystem and the browser ecosystem) this was a pretty foreseeable outcome.

This is exactly the sort of breaking change that I really struggle to see the value of — maintaining the deprecated method seems incredibly unlikely to be a notable maintenance burden when it is literally just:

    @deprecated("Use response.headers.get(name) instead")
    def getheader(self, name):
        return self.headers.get(name)

Like sure — deprecate it, which might have _some_ downstream cost, rather than having two non-deprecated ways to do the same thing, just to make it clear which one people should be using; but removing it has a much more significant cost on every downstream user, and the cost of maintenance of the old API seems like it should be almost nothing.

(I also don't hate the thought of having a `DeprecationWarning` subclass like `IndefiniteDeprecationWarning` to make it clear that there's no plan to remove the deprecated function, which can thus be ignored/be non-fatal in CI etc.)

Note the spec does recommend providing a user option: https://drafts.csswg.org/css-color-hdr-1/#a11y

The second link isn't applicable to Apple's WebKit ports — it's entirely built via Xcode.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines USE_JPEGXL only for macOS < 14 (which aren't actually supported any more!).

All the in-tree JPEG XL support, e.g., https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... is behind a "USE(JPEGXL)" ifdef — so none of that is compiled in.

Instead, it's using what Apple ships at a system level, in Image I/O.

https://github.com/WebKit/WebKit/blob/39386f4547897c89c510d0... defines HAVE_JPEGXL for recent versions of Apple's OSes. https://github.com/WebKit/WebKit/commit/932073284e4c73ce9884... is the commit which added this — there's really not much there, because it's just setting the define and adding it to the allowlist of image types.

And yeah, currently I believe this is libjxl — or a fork thereof — hence the inclusion of libjxl in the Acknowledgements.rtf file on macOS.

Arguably this is a problem in when the patch is unapplied.

Presumably in the coverage case it’s being called by a trace function, which inevitably runs during test execution — and while we want the trace function to be called during the test function, we really want it without any patches the test function is using. But this arguably requires both an ability for the trace function to opt-out of patches and for the patcher to provide a way to temporarily disable all of them.

I’ve been in so many Ubers in the UK with check engine lights and the similar — but at least some of the difference is Uber UK has much higher requirements for cars, which I expect is probably partly because of competition from private hires.

I felt like that seems a little long from EDI to MAN (after all, EDI to LHR is typically a flight time of under an hour!), so:

https://globe.adsbexchange.com/?icao=4d2256&lat=54.720&lon=-... is the track of this flight.

Went around at EDI at about 19:10Z, landed at about 19:51Z, so about a 41 minute flight.

As others have said, final fuel reserves are typically at least half an hour, and you shouldn't really be cutting into them. What if their first approach into MAN had led to another go around?

With a major storm heading north-easterly across the UK, the planning should have reasonably foreseen that an airport 56 miles east may also be unavailable, and should've further diverted prior to that point.

They likely used the majority of their final fuel reserve on the secondary diversion from EDI to MAN, presumably having planned to land at their alternate (EDI) around the time they reached the final fuel reserve.

Any CAA report into this, if there is one produced, is going to be interesting, because there's multiple people having made multiple decisions that led to this.

At a battery level it’s very doable — and certainly not as extreme as in most racing applications — it’s just a bunch of trade-offs.

Tyres are almost certainly the limiting factor here; also I forget how close to the (admittedly banked) turn it was when it hit its top speed.

Motor output, so you’ll still have transmission loses beyond that (but with a fixed drivetrain, with no multi-speed gearbox, quite possibly more like 95%).

How close are the GNU coreutils with the POSIXLY_CORRECT environment variable set?

I wouldn't be surprised if there were still patches required, but at least on the face of it that should get you most of the way there.

To some extent, it's cases like this which show the real fragility of everything existing as a unified whole in google3.

While clearly maintenance and ownership is still a major problem, one could easily imagine deploying something similar — especially read-only — using GCP's Cloud Run and BigTable products could be less work to maintain, as you're not chasing anywhere near such a moving target.

> maybe arm64 binaries always had 16kb aligned segments?

Yes — because the move to 16k pages happened at the same time as the move to arm64.

This depends on who the Border Agency officer is:

An Immigration Officer may search you until they are satisfied you are a citizen. As long as you have a passport (or emergency travel document) listing you a citizen, this should be straightforward and they're unlikely to have grounds for any further search. At that point, you have been let into the country.

Customs Officers are much more likely to have grounds for a search — if they believe you are bringing prohibited material on the electronic device into the country (and "reasonable grounds" is low, as it typically is for customs — "you're acting kinda sus" is a reasonable ground), they can search your device. It is an offence to refuse a search, so while you've been admitted to the UK, you could be arrested for that offence.

This is all broadly comparable to most other countries immigration and customs laws; the UK is not an outlier here.

The problems with the UK are primarily things that apply to everyone, not just at the border — for example the Terrorism Act 2000 and Regulation of Investigatory Powers Act 2000. But again, in the border case — that's basically all going to be _after_ you are admitted to the UK.

iTIP (RFC 5546) / iMIP (RFC 6047) are a standard for sending and responding to calendar invites, implemented on top of email.

Certainly some implementations are pretty poor, but in theory this is all standardised.

> a new "Adminless" account model with linux-like just-in-time escalation

This was the promise of User Account Control, was it not? Or does that just prompt for confirmation for various actions, without actually enforcing a security boundary?

> The HTTP/1.1 spec actually recommends limited to 2 connections per domain.

This is no longer true.

From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4):

> Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.

> I suspect the corporation employs more people than the foundation?

Yes; the corporation is, last I knew, about a thousand, and the foundation about a hundred.

If there is capacity, they are obliged to provide it on a non-discriminatory basis. If there isn't capacity, then it gets into questions of allocation (which still needs to be done in a fair and documented basis).

To reply mostly with my WPT Core Team hat off, mostly summarising the history of how we've ended up here:

A build script used by significant swaths of the test suite is almost certainly out; it turns out people like being able to edit the tests they're actually running. (We _do_ have some build scripts — but they're mostly just mechanically generating lots of similar tests.

A lot of the goal of WPT (and the HTML Test Suite, which it effectively grew out of) has been to have a test suite that browsers are actually running in CI: historically, most standards test suites haven't been particularly amenable to automation (often a lot of, or exclusively, manual tests, little concern for flakiness, etc.), and with a lot of policy choices that effectively made browser vendors choose to write tests for themselves and not add new tests to the shared test suite: if you make it notably harder to write tests for the shared test suite, most engineers at a given vendor are simply going to not bother.

As such, there's a lot of hesitancy towards anything that regresses the developer experience for browser engineers (and realistically, browser engineers, by virtue of sheer number, are the ones who are writing the most tests for web technologies).

That said, there are probably ways we could make things better: a decent number of tests for things like Grid use check-layout-th.js (e.g., https://github.com/web-platform-tests/wpt/blob/f763dd7d7b7ed...).

One could definitely imagine a world in which these are a test type of their own, and the test logic (in check-layout-th.js) can be rewritten in a custom test harness to do the same comparisons in an implementation without any JS support.

The other challenge for things like Taffy only targeting flexbox and grid is we're unlikely to add any easy way to distinguish tests which are testing interactions with other layout features (`position: absolute` comes to mind!).

My suggestion would probably be to start with an issue at https://github.com/web-platform-tests/rfcs/issues, describing the rough constraints, and potentially with one or two possible solutions.

And it's worth noting VLIW survived longer in GPUs—where there isn't any expectation of ISA stability, which avoids that problem.

Note the Eurostar is perhaps an especially bad example in terms of affordability, versus most HSR in Europe:

* the Channel Tunnel has very high access charges (because construction was very expensive, and as a private entity it took on a lot of debt and wants to pay that off!), and

* the terminals in both London and Paris are too small for the time taken by border control now the UK is no longer in the EU (which has led to Eurostar running fewer trains—but the demand has hardly decreased).

What would you consider part of a PWA focus area?

You link to https://web.dev/learn/pwa/capabilities and https://whatpwacando.today elsewhere, but I think many would consider many of those features to not be inherently PWA features. Many, _many_, of those features have wide usage outside of PWAs, which makes putting them into a "PWA" bucket somewhat meaningless. Constructing buckets like "Storage" or "Media" would probably be more meaningful to web developers.

If you look at the basic definition of PWAs, it's primarily about manifests and service workers, and about using the web platform in combination with these.

Manifests are hard to test automatically — their content is largely shown in differing parts of browser UI, and UI is by-and-large unspecified in web standards (because vendors want freedom to make their own UI decisions) — which makes including them difficult. It's also unclear how much there is in way of interoperability problems.

Service workers are definitely something that could be proposed (though haven't been in recent years); I again don't believe there's been that much in way of interoperability problems there recently.

This has been done to some degree at Green Park station, which still very much is quite warm in places, for ~£9M about a decade ago.

But when TfL has had its budget slashed, and such projects are competing for financing with other projects with more direct operational benefit… it's hard to justify. And it's still not necessarily easy to drill at all!

AFAIK they were contractually obliged to produce a new generation.

However:

> [The 2017 CPU] has no microarchitecture improvements over [the 2012 CPU]; despite nominally having a different stepping, it is functionally identical with the 9500 series, even having exactly the same bugs, the only difference being the 133 MHz higher frequency of 9760 and 9750 over 9560 and 9550 respectively.

So they practically _didn't_.

> It really amused me that people think "RDF never caught on" when it is the basis of so many major standards such as RSS, Adobe's XMP metadata, and, I just found out, ActivityPub.

What does it mean to have caught on or not, though? How many RSS, XMP, ActivityPub implementations are actually considering things as triples and not just considering parent-child relationships within the XML tree?

Modern HTML, per the HTML spec, has implicit namespaces: if you look at the DOM on any site, you'll find the root element of any HTML page is an element in the "http://www.w3.org/1999/xhtml" XML namespace (c.f. `document.documentElement.namespaceURI`).

It was _absolutely deliberate_ that the DOM produced by parsing HTML and XHTML is now the same in overall structure, with the same XML namespaces, as it means browsers don't need to have things like `if localName == "html" and (namespaceURI == "http://www.w3.org/1999/xhtml" or isHTMLDocument)` all over the place.

Modern WHATWG specs put a lot of effort into reducing the number of places where the behaviour of a given DOM depends on whether the document is an HTML document—and most of those are places where non-namespace aware APIs default to the "http://www.w3.org/1999/xhtml" namespace in HTML documents.

> I guess unless we want to assume Opera were digging their own grave by actively engaging in HTML5 and WHATWG, we have to conclude HTML parsing wasn't the hard part

As someone who was around the WHATWG from relatively on, and worked at Opera over the period when it moved to Chromium, I'd strongly suggest that HTML5 was a _massive_ win for Opera: instead of spending countless person hours reverse-engineering other browsers to be compatible with existing web content, things like HTML parsing become "implement what the spec says" (which also implicitly made it match other browsers). Many of the new features in the HTML5 spec of that period were things that either were already basically supported (in SVG especially) or were relatively minor additions; I don't think they played a significant role either.

There's a good reason why Opera was heavily invested in the WHATWG, and it's the fact that by having a spec implemented cross-browser defining how to parse HTML and how cross-page navigation works you eliminate one of the biggest competitive advantages more major browsers have: web compatibility, both through legacy content targetting the browser specifically and also web developers being more likely to test in those browsers. (And to be clear—this would've been true for any form of error handling, including XML-style draconian error handling; but the long-tail of existing content needed to be supported, so even if major sites had migrated to XML you still needed to define how to handle the legacy content.)

The downfall of Presto is arguably mostly one of mismanagement and wrong priorities decisions being made; I don't think Presto was unsaveable, and I don't think the Presto team was so significantly under-resourced it couldn't compete.

This isn't how it works at all; a server sends a message to a push service which then delivers it to the user agent. It is only once the user agent receives the message that it needs to start an installed service worker (if it isn't already running) to deliver the message in the form of the notification. (There's some interest in making it possible to send a notification directly via the push service without having the cost of starting a service worker, but that's future work.)

In the Safari case, this push service is essentially the same as is used for native apps, and it will do the same aggregation as you see for other notification types.