Recent submissions

Comment · 1 month ago
Comment · 1 month ago
You can try it on their website, https://console.mistral.ai/playground

It's just that the open-weights aren't yet available (although the long delay is slightly annoying).

Comment · 1 month ago
Comment · 1 month ago
I don't think ANPR systems should be held responsible for matching number-plates or car models. That's their job, and police have had access to such tools for many many years. It seems relatively clear that Flock was providing a commonplace technology here, that was misused.
Comment · 1 month ago
What a weird thing to say. The headline is supposed to be the takeaway of the material. People are certainly allowed to discuss an article's choice of headline (which is what people remember), and should give no care to you telling them to go elsewhere.
Comment · 1 month ago
I very much agree with what you say on automation bias.

Certain technology just has too much potential to be misused / people repeatedly prove they can't use it properly. It also comes with risks of making authoritarian takeover easier.

However, here, it seems they used Flock a bit like a regular ANPR. The actions they took independent of Flock show there are better stories to use to criticise this technology.

Comment · 1 month ago
How is Flock responsible in this case?? There may be cases where Flock is responsible, but I don't see it here.
Comment · 1 month ago
Flock is not an AI. That they have AI features on certain products does not mean "Flock" is an AI. That's the fallacy of composition.

Flock does have AI components (this one seems LLM based). Basically every ANPR system will also use some level of AI.

Also, on "reality would like a word". Why not just speak normally instead of using what seems like a high-school grade comeback?

The main Flock related issue here is that officers treat results that come out of the systems as gospel. The same thing has happened with face recognition systems. There is also the broader issue of access controls to Flock, 5A, and whether places should be building up a technology so powerful (surveillance infrastructure can easily be used for evil).

Comment · 1 month ago
What a strange strawman. You are deciding now to substitute a different complaint than what was originally sense, because it is simply true that if you don't want to use Apple Intelligence, you don't need to.

The complaint now shifts to that you'll still have files on your system, or can't control exactly what models are stored on your computer. Apple has reasons not to give this fine control: what you have on HN is a group of people who are vehemently anti-AI, use Apple products, and still want features very specific to their control of the system.

Apple caters to the general user. If they think a setting is going to be confusing or likely to be misused, they won't implement it. People know the reality that if Apple intelligence is successful and if this feature is implemented, the general user won't know which parts of their workflow use which features. Removing the models will be advertised as a cheap hack to save storage, and people will be confused when they can't turn intelligence on again.

The fact that the core premise of the article (repeated in the title and first sentence) is about "phoning home": > The nice thing about keeping a blog is that I can say at precisely 9:51am, Wednesday 5th February 2025, I discovered that macOS 15.3 had enabled a feature that was phoning home every 15 minutes with personal data. And that I said “no” and turned it off.

The entire basis of this complaint is not understanding the difference between "duration" and "interval". And not being able to click the link that is given to you in the settings menu or just search Apple's docs for the setting ( https://support.apple.com/en-mn/guide/mac-help/mchlfc0d4779/... )

Comment · 1 month ago
This is literally the main point of the article: "The nice thing about keeping a blog is that I can say at precisely 9:51am, Wednesday 5th February 2025, I discovered that macOS 15.3 had enabled a feature that was phoning home every 15 minutes with personal data. And that I said “no” and turned it off."
Comment · 5 months ago
I assume they're using a more candid definition where they're not counting all the countries a company may be based, but rather the primary country they're based in.

I don't think they're trying to flex this as a large number. They don't want to give an exact number, as that may change etc / is fuzzy, but also want to give you an idea of the scale.

They say "In the future, we intend to expand our geographical reach much further". I imagine this commentary is somewhat related to the concerns that AI will create an even worse "global underclass". AI developments are first accessible to Americans, then allies, and then later the whole world.

Comment · 5 months ago
There's a comment on the GitHub thread which also mentions pinning rsync version would be a bad idea. Many of the people affected by reversions are those with workflows vulnerable to the prior CVEs.
Comment · 5 months ago
I don't actually see much evidence the usage of AI here was an issue. I think you can obviously identify areas where the code isn't perfect. I'd blame this slightly on human prompting, slightly on AI.

But I'm not a sure a human on their own would've done better. There aren't enough resources to make the changes required.

Comment · 5 months ago
Can you tell me any of the bugs? All claims I have seen so far of people being affected by bugs seem deeply implausible.

The current ones I see are: * Can't build on Linux < 5.6. But people aren't complaining strongly about this, since it requires a build from source / isn't a result of an update from a distribution (and people can wait for updates / implement them themselves). * An issue hit with chroot false + daemon. People running this in an automated manner (as some claims suggest) are already using it in a way fairly likely to be insecure, chroot false is strongly discouraged here, and the whole point of these commits was that they fixed CVEs impacting precisely these people.

Comment · 5 months ago
> Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.

This happens frequently when there are fixes for CVEs, since regression tests can't catch many things which incremental rollouts can. It happened for example in 2025. People are right to imply the reaction is totally outsized here, and it's almost certainly the case that people are overreacting to AI (rather than the somewhat weak idea that it's because of the frequency of these issues).

What's really funny is that the people opposing AI here are showing far less literacy than those who wrote the code. People claiming to be affected by this bug severely are likely exposing themselves: * One bug is for Linux < 5.6, where it didn't hit distributions. This is a low severity bug where it can't build, where distribution maintainers may be reasonably expected to fix it themselves (although rsync will also fix it eventually too).

* The other bug affects precisely the people impacted by the CVE https://github.com/RsyncProject/rsync/issues/897

You probably don't want to revert in this scenario. If someone is hit by this bug and is running rsync in an automated manner, it is highly likely they're ignoring very many security practices: you're usually not supposed to run native rsync in an automated manner (the main use case is for public users, where you can't SSH etc; since it's unencrypted, you're supposed to check a checksum against a website etc); these cases are hit with chroot false, which is deeply discouraged and leads to far larger attack surfaces.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton