newtonsmethod
Joined 2 years ago
Joined 2 years ago
It's just that the open-weights aren't yet available (although the long delay is slightly annoying).
So saying you said something because my non-existent position is "absurd" and "clearly false" indicates massive levels of confusion.
You then go on to imply I haven't read the article, using an acronymised swear (I'm not a pious person but clearly directing a swear to someone makes a message come off as aggressive), even though your understanding of what I said is based off non-existent messages. (This is quite ironic).
Flock is a company. Companies are a type of organisation: it makes no sense to describe a company as AI, as AI is a type of computer system. It may make sense to say Flock is an AI-based company, but calling them "AI" in itself makes no sense.
I can't find anything indicating that an LLM was used in this case, and this county seems to mainly have Falcon cameras (https://www.scribd.com/document/983922612/250730110407Flock-...). Reverse engineering seems to indicate these are powered by non-LLM AIs like Tensorflow vision NNs. These have been around for ages, and notably no-one is alleging these models hallucinated etc.
People also (perhaps wrongly) use "Flock" to refer to the camera system. CrendKing explicitly calls "Flock" a "camera system". A system of cameras is not AI, and the point of the comment seems to be that it's inappropriate to bring up LLM related AI fears about this system.
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.
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).
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/... )
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.
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.
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.
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.