scottlamb

I can think of two reasons.

The first is what they describe here: as an attack. It's like why would anyone ever overflow a buffer with shellcode.

The second is that they are implementing a spec that requires appending a varint length-prefixed field to a buffer but don't really care about the space optimization, don't know the field's length when they start appending it, and don't want to put the field into a second, temporary buffer or slide it down into place. https://github.com/FFmpeg/FFmpeg/blob/468a743af1653a08f47081... vs say my own code which does the slide: https://github.com/scottlamb/retina/blob/6972ac4261ce7bf5b58...

Oh, no, I remembered the actual exploits because they were comically trivial. I searched for them and found the ids to paste here. I don't in general follow security vulnerabilities closely enough to be the one to ask about CVE visualizations and the like.

    $ login -n root
    Login incorrect
    login: backdoor
    No home directory specified in password file!
    Logging in with home=/
    #

I think this is supposed to be something like CVE-1999-0113 (or its very recently discovered/disclosed friend CVE-2026-24061). It's the sort of thing you might just know off the top of your head that would be handy for getting into a computer that hasn't been updated in 20 years.

> I think [`git log -n1 -- <path>`] is the fastest way to get the most recent commit time on a single file?

In terms of machine time? I'd guess so, but I'd also guess calling it for each of `git ls-files` is not the fastest way to get the most recent commit of all the files in a typical scenario (large repo, recent time of interest, most files not changed that recently). And especially if you're okay assuming the most recent commit by parentage is the one you want (even if parentage doesn't match chronological order); then filtering with `git log --name-only --since` (no path argument) seems better. A `git log` post-processing script could also stop early if it's seen a commit for each the files of interest (again, assuming you don't want to return a later date that is attached to an ancestor commit).

Anyway, cool tool, and it's rare that I would actually care about the machine efficiency of this pipeline enough to bother with the approach I just described.

On the other hand, the RP2350 actually is a microcontroller, and IMO a nice one for many purposes. PIO, high-quality datasheet, nice ecosystem, etc. And the Pi Zero 2(W) can do most things the Pi/Pi 2 could, with a smaller footprint and less power consumption. Variety is nice.

> It is missing the Italian, Japanese, Greek and Mexican cooking - that are incredibly popular worldwide and it is incomplete without them, and nothing from Africa at all or Middle East.

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.

But I'm talking about general day-to-day security as well as off-boarding. What stops a single disgruntled employee from doing this before being fired? And if you have a good story there, why do you need the most extreme approach to "off-boarding"?

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.

> Too complicated and subjective, stinks of more risk.

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. :-(

You always have to be careful about overfitting to a specific scenario like "this but if they had also forgotten to lock out the other evil twin". I'd prefer a system that is robust to a malicious employee (more likely: compromise of an employee's credentials) but has a slight gap in the "evil twins" scenario over one that prevents all post-firing malicious access from twins but doesn't consider at all what happens if a current employee's credentials are compromised.

> Just think of all the info you have in your inbox.

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.

> When you are talking about access like they had "make firings as abrupt as possible including terminating all access immediately" not doing this is incompetence.

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.

> [Opexus] said that “the individuals responsible for hiring the twins are no longer employed by Opexus.”

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.

> Datacenters are focused on "never letting the equipment go down for any reason."

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.

You're reminding me that I have a couple conventional UPSs sitting in the garage. I should unload them before convincing everyone they're junk!

I've found the difference in runtime between similarly-priced low-end units with similar power rating is hour+ (LifePO4 power station) vs not advertised but actually just minutes (lead acid UPS). And you can spend a bit more on the LifePO4 power station and get a proportional increase in runtime and power, vs. the lead acid UPS where the cost would quickly become prohibitive. And the LifePO4 power station gives you the choice to cut off above 0% or not, where the lead acid unit doesn't give you any control. So you can trade off 30% of your capacity for increased longevity if you choose and still come out way way ahead on runtime. Or you can not and still have much better battery longevity than lead acid. You can choose a spot on a Pareto frontier that lead acid can't even approach.

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.

Where is it a good option? I'd expect datacenters to be more focused on efficiency, not less.

Had the exact same thoughts.

* 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.

Yes, thousands of times, an order of magnitude improvement over lead acid. And the increased capacity means that they're much less likely to hit 0% (or whatever defined cut-off you set) during a typical outage anyway.

> 20 milliseconds is barely distinguishable from a single 60 Hz sine wave period.

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.

I toyed with this too, but I guess I have a slightly more diverse set of devices than you do. A few more weird voltages, and some things that expect mains. I looked into finding a DC version of their power supplies (e.g. the pico-box X9-ATX-500 to replace a conventional ATX PSU, tracking down DC versions of network switch hot-swappable PSUs from eBay) but decided it wasn't worth it. I just bought a stock LifePO4 power station. I found that I got most of the benefit [edit: measured in terms of runtime after power outage, not power draw while input power was available] just from switching to LifePO4 rather than from avoiding DC->AC->DC, and it was cheap and easy.

I would be curious to see how LifePO4 power stations compare.

* 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.

> Last I checked, high-resolution scroll reporting over USB is not based on pixels but on fractions of a detent, which is annoying to say the least.

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.

macOS is a whole thing in terms of smooth scrolling, or HID (human interface devices) in general. It seems like Apple just doesn't put a lot of effort in terms of working with third-party HIDs:

* 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.

That's the most reasonable interpretation I've heard. I'm not assuming they're being reasonable, though. I have a deeply negative view of the crytocurrency industry including Coinbase, and they just wrote "non-technical teams are now shipping production code", so I'm more primed to assume they mean something unethical, short-sighted, unrealistic, and negligent.

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

Everybody had a chance to learn it those year. No one who had already learned to code had a chance to learn it first, as in before other ways of coding. Not everyone can be AI-native.

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

> I am among the oldest on our team and also the most in tune with AI.

Congratulations. But you completely missed my point. I didn't say old people can't be in tune with AI.

> I see AI-native as those who have embraced it

That's not what the word "native" means. In the human language situation I referred to, it's about the language you learned first. It's not a synonym of proficient or fluent. If you learned to code first without AI tools, you are not AI-native by any definition I would understand, no matter how good at using AI you may be.

It's not just "English-native" that makes me think they have this meaning in mind. It's also the term "digital native" that gets thrown around a lot and is absolutely about how old you are. https://en.wikipedia.org/wiki/Digital_native

> We’ll be concentrating around AI-native talent

Is this code for "we're firing all the old people"? As I understand it, I can say I'll only hire proficient English speakers (a "bona fide occupational requirement"), but I can't say I'll only hire native speakers, as that would discriminate against various protected groups. This seems like the same thing—proficiency may be a bona fide requirement, but expecting they learned this year's workflow first is age discrimination.

I don't expect ethical conduct from crypto companies and will not be sad if they are sued into oblivion.

> Paraphrasing the crux of the issue: "It's regular practice in Colorado to list license plates with both versions, the one with 'O's and the other with Zeros in the warrant list." Insane. Practice.

Agree.

> As always, this story has have nothing to do with the cameras or AI, but "law enforcement has an insane lazy practice" doesn't make for a very good headline anymore.

Flock allows them to execute their intent at scale. That's a regression, unless it leads to the realization their intent is harmful and stupid.

(Lots of other reasons Flock is bad too.)

> I didn't quote anything from the article.

You referred to it: "just now I glanced at the article and it seems the author writes in a confusing way..."

> I was responding to the comment, not the article.

It sure looks like you were responding to both, and I addressed both. Also, you're going to have a hard time understanding HN comments if you don't read top-level comments as responses to the article, even if they don't start with "I agree with the article" as max_k's comment did.

>> FastCGI is better than HTTP for these things.

> FastCGI and HTTP are at two different levels. HTTP is for data transfer from, say, a browser and a server. FastCGI is for handling that data between the server and an application. Just now I glanced at the article and it seems the author writes in a confusing way to imply that HTTP and FastCGI are interchangeable and they are not.

That might be just you. The article is littered with the qualifier "for reverse proxies", including in the title and two section headers, and "as the protocol between reverse proxies and backends" in the second paragraph. I don't know how it could be any more clear on this point.

The max_k comment you've quoted includes "for these things"; context clues suggest by "these things" he also means to limit his comment to the reverse proxy <-> backend leg.