That's overstating it. There are certainly English-language sources describing Italian, Japanese, Greek, Mexican, African, and Middle Eastern recipes. They're likely not the most authoritative sources, but it's not as if I'd expect these cuisines to be completely absent.

The actual corpuses they used are listed in the supplement: https://arxiv.org/src/2605.22391v1/anc/supplement.pdf

edit: that document also breaks it out by region, including 33,923 Japanese recipes which seems respectable. 324 from Sub_Saharan_African which is tiny but still more than 0. Italian and Greek are likely a fair chunk of Mediterranean (164,107). I don't see a breakout for Middle Eastern. Some might be lumped into Mediterranean as well.

It makes sense to terminate someone's high-risk credentials immediately when they're fired. But it's extremely worrying if every credential held by every employee is considered high-risk. It suggests a bigger failure. "Unilateral access to a database filled with plain-text passwords" shouldn't ever exist. "Email account filled with dangerous stuff" should at least be unusual.

I actually think there's less risk, because it's not as narrowly focused on what a just-fired employee can do. That's not the only scenario of concern.

> Also, I don't think it's dehumanizing it all (having been on the receiving end of it way back when during a layoff, and involved in the process more times than I care to count).

Interesting. Thanks for the perspective. I've been fortunate enough to not be on the receiving end of a lay-off, knock on wood. It's happened to my teammates/reports though. Wasn't my decision. :-(

Meh? Sure, stuff that would help assemble a credible phishing attack, but not customer SPII or huge amounts of intellectual property or anything. If the assumption is that employees' inboxes are full of dangerous things, I would focus on fixing that.

You're proving my point—employers take the most extreme lesson and it's considered expected practice. They absolutely should have immediately terminated the credentials that granted unilateral access to sensitive databases. (Ideally those would never exist in the first place—there are two-person schemes. A pair of bad actors...well apparently happens according to this article...but is far more unusual.) But employers regularly (but shouldn't) terminate all access including credentials that allow last email to colleagues exchanging personal contact info or something.

Getting close to the classic Monty Python line: "Those responsible for sacking the people who have just been sacked, have been sacked."

Jokes aside, stuff like this sucks because I suspect many employers will take from it the most extreme, dehumanizing lessons, e.g.: (a) make firings [edit: including lay-offs] as abrupt as possible including terminating all access immediately, (b) never give second chances to anyone with any sort of criminal record (even say decades old marijuana posession or something).

I'd prefer a more balanced version: limit unilateral access to sensitive systems in general (not just of recently-fired employees), when someone is fired immediately shut off particularly sensitive credentials if they do exist (but not their general-purpose login/email account), avoid hiring people convicted of wire fraud as sysadmins, hash your @!#$ing passwords, etc.

Disagree. I'm most familiar with Google. For a long time at least their UPSs were built in to each machine and not super reliable. They built entire datacenters without cooling with the understanding that for a few days a year it may be too hot for human access. The reliability is from failing over to other equipment—machine, cluster, even region.

Small/on-prem/co-location datacenters may make totally different choices, but I think the major cloud/AI providers would be similar to Google in this respect.

The sibling comment about other industries was enlightening to me though.

The rationale I've heard to justify conventional UPSs not even trying to compete on runtime is that they're just for giving you a few minutes to cleanly shut down your crap software that isn't crash-safe and/or for your auto-start generator to start up. But what I actually want is to keep working for an hour+ after the power goes out without owning/installing/maintaining a generator.

* I thought at first they meant "later" was too vague, but omitting the word only makes the message more terse, not more specific. It's as if they decided ahead of time that the old message was bad and embodies certain qualities (which they highlighted) and the new was good and embodies certain other qualities (also highlighted), and they didn't bother to rethink the new one after seeing almost the same phrase used as examples of bad and good.

* "Your changes were saved": yeah, if the change is connecting your account to a third-party service, and they were unable to connect...did they save the intent to connect? How do you resume it? Or was this part of a greater set of changes? The reassurance works best if it's consistently true, but I'm doubtful.

I've read that the newest PSUs are only guaranteed to last 12ms. Of course they may last much longer, especially if running near idle, but I'd prefer something that works well with any compliant device.

Here's one source: "Measured in milliseconds, hold-up time indicates how long a PSU can sustain its output within specified voltage limits after a loss or drop in input power. ATX 3.1 features a shorter hold-up time of 12ms, compared to ATX 3.0's 17ms hold-up time. This results in a small improvement in the PSU's efficiency." https://www.corsair.com/us/en/explorer/diy-builder/power-sup...

I haven't dug through the spec itself.

* These power stations are better than conventional (lead-acid battery) UPSs in the sense that they're cheaper, more flexible, have dramatically longer battery life, and require battery replacement less often.

* ...but I haven't seen any that claim to be "line-interactive" or even say specifically when they fail over (other than a total power cut). They do talk about how long it takes to fail over: older models are >20ms (long enough that your machine will probably reboot); many newer ones are <10ms. I'm not sure how high-quality their sine wave is when on battery.

I'd just be happy if it let me use the multiplier; don't care if it's not exactly pixels.

> Apple probably also didn't want to translate multitouch to scroll in hardware,

That much doesn't seem unique to Apple; both Windows and Linux appear to prefer accepting raw multitouch data.

> since scrolls are not reported the same in all contexts (e.g. applications can choose whether it locks to an axis; which axes it can lock to depends on the capabilities of the view; etc.)

I don't think they're actually taking advantage of this. My MBP's built-in trackpad will lock into pinch/rotate gestures when the cursor's over say Zed or iTerm2. (Zed's a bad example actually, as it has no accessibility tree to speak of. But I think it will lock into pinch/rotate anywhere.)

And for my own app, as far as I know (I'd be very happy to be corrected) there's no way to inspect a view to know what kinds of gestures it supports. It certainly would be nice to eliminate the possibility of locking into pinch/zoom in a place where that's meaningless but I don't see a way to do it.

> Applications can choose to ignore synthetic events, IIRC. Probably not an issue for scrolling, but for instance Little Snitch can be configured to ignore synthetic inputs to its security settings.

Yuck. I'm doing everything this way, including cursor movement and taps. I hope I don't come across such an app/configuration.

* There's a standard way to enable high-resolution scroll reporting (pixel-level instead of line-level), but Apple doesn't use it.

* There's a standard approach to multi-touch digitizers/trackpads (documented and I think to some extent created by Microsoft, called PTP) which Apple doesn't support.

* Apple's own Magic Trackpad speaks a proprietary protocol and it appears you can only speak it if you claim to use their USB VID/PID. And I don't think doing that would go over well in a commercial product. (And if you do manage to speak it, it turns out their driver really doesn't do two-finger scrolling well with tiny trackpads anyway. They probably only tested it on the generous dimensions of their hardware.) (Also, it attaches to your entire device, so having an additional interface with a different driver doesn't appear to work either.)

But...you can inject smooth scrolling events via Core Graphics. So you can run a userspace program with accessibility permission that scrolls smoothly. And you can also communicate with USB devices from such a program. There are some existing programs for doing smooth scrolling with standard mice (Mac Mouse Fix is one). I'm writing a userspace driver for PTP to make my keyboard's built-in trackpad work properly.

Another somewhat reasonable interpretation occurred to me later: that they're using "AI-native" as a shorthand for "AI-native systems" aka systems designed with AI / to take advantage of AI from the start, and thus "AI-native talent" as a shorthand for "people talented in creating those systems", rather than the people themselves being AI-native. But again, given who said it, I'm not going to assume that's what they meant.

scoot's comment [1]: "I'm not sure exactly which children they're planning to replace all their staff with, nor how they plan to get around the child labour laws" sounds exactly right to me.

[1]: https://news.ycombinator.com/item?id=48030120

You might assume they aren't going to be so stupid as to try to exclude everyone who isn't new to programming. I wouldn't. They're a crypto business.

See also "digital native", a popular term which is absolutely about growing up after the technology in question was ubiquitous. https://en.wikipedia.org/wiki/Digital_native