[ my public key: https://keybase.io/gsnedders; my proof: https://keybase.io/gsnedders/sigs/mzGxtKUO-Q2yYme3MggWJzaLZS6USlZuc8xRrS7iQi4 ]
- > Performance isn't all that matters, especially once you have an established codebase and ecosystem.
And this is no small part of why Java and JS have frequently been pushing VM performance forward — there’s enough code people very much care about continuing to work on performance. (Though the two care about different things mostly: Java cares much more about long-term performance, and JS cares much more about short-term performance.)
It doesn’t hurt they’re both languages which are relatively static compared with e.g. Python, either.
- Is there any plan about how to deal with indirect prompt injection attacks that could trivially be lurking in malicious web pages, given the agent can navigate to an arbitrary URL?
- Is there anything at a protocol level that prevents using a modern font rendering stack for it?
- Not just WM/DE, but also the toolkit too.
- I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
- 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:
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.@deprecated("Use response.headers.get(name) instead") def getheader(self, name): return self.headers.get(name)(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.
It’s gonna be very interesting to watch exactly how the adoption of WebDriver BiDi goes with Selenium, especially once WebDriver Classic starts to go away, and how API stability is balanced with exposing more and more async capabilities.