MurphyA/hacker-news huggingface dataset:
by dragontamer | 2025-07-08 20:31:57+00:00
Good link, I'll probably read that series over time.

Yeah, I don't mean 'Merging of Pantheons' as much as how different religions interact. When I speak to Hindus about Jesus (and when they speak to me about Vishnu) we aren't really adopting each other's gods, but instead trying to find pleasantries and similarities between our ways of thought.

I also have come to the opinion that Vishnu in Hinduism adds a weird case of Monotheism in an otherwise Polytheistic religion. (Same with Buddha in Buddhism).

Shintoism might be the only religion that's classically polytheistic, and only because Japan was isolated for so long.

The Monotheistic argument of an Ultimate God above all others (be it Vishnu, Buddha or Jesus) is something that virtually all mainstream religions have today. This cannot be a coincidence.

-------

But yes. Applying history to historical theologies/polythists is probably a better idea than me applying modern religious concepts and pretending that people a thousand years ago had similar conversations as me and my Hindi friend. Lol. But my knowledge of the Romans and Egyptions is not quite as deep as the blog you listed there.

> Anyway, if your Roman ritual was just something that your ancestors discovered through trial and error, I guess you probably won’t be too freaked out by the fact that the Egyptians’ ancestors found a different ritual. The gods are mysterious and temperamental, after all.

Well sure. That's an argument for how polytheists talk with other polytheists.

The issue is when the Romans talks with the proto-Monotheists. The Hewbrews, Zoroastrianism, the Gnostics and the Catholics. At this point, the idea of 'God above all other Gods' is taking root.

It may take centuries before the discussion plays out, but it's started. Maybe in another universe we'd all be Zoroastrianists instead of Catholic, but it feels like the inevitable march towards a God above all gods when you have so many monotheistic religions popping up.

Besides, worship of just one god sounds a lot easier than trying to memorize the long lists of Helios / Apollo / Ra / Amaterasu (sun gods) and hoping your rituals are keeping them appeased.

As a practical manner, if you were going to try out a new Religion, it only makes sense to try out the most powerful ones. Be it El, YHWH, Jesus, Vishnu, Buddha, Zoroaster, the Gnostics 'Supreme Being's or whatever. That's the benefit of Monotheism.
by dventimi | 2025-07-08 20:32:03+00:00
> But that's not to say that they wouldn't be capable of adding safeguards on their end, not even on their MCP layer. Adding policies and narrowing access to whatever comes through MCP to the server and so on would be more assuring measures than what their comment here suggest around more prompting.

This is certainly prudent advice, and why I found the GA example support application to be a bit simplistic. I think a more realistic database application in Supabase or on any other platform would take advantage of multiple roles, privileges, Row Level Security, and other affordances within the database to provide invariants and security guarantees.
by arianvanp | 2025-07-08 20:33:08+00:00
There is already memory.high (MemoryHigh= in systemd) you can set on cgroups which does something similar at the kernel level.

But its challenging to use correctly. As its easy to end up in a live lock situation where the process never frees memory but also never gets killed.

See all the details that Kubernetes had with introducing this

https://github.com/kubernetes/enhancements/issues/2570
by MrDresden | 2025-07-08 20:33:19+00:00
Honestly I was surprised not to see an announcement for some kind of agentic API in Android during GIO. Think some kind of combination of content providers and a rest interface, defined by the developers of each app.

Having the system level agent needing to interface with the UI in such a messy way doesn't feel like the best way for it to accomplish its tasks.
by martin-t | 2025-07-08 20:33:43+00:00
Then I have 2 questions:

- Why are they not flagging more content? Am I right they're boiling the frog slowly? Do they lack an endgoal because management does not yet understand the power of these tools?

- Do you do your job poorly on purpose? Did you take it so somebody else wouldn't build an even better system? Did you think you could influence it in a direction which does not lead to total surveillance? (I assume any reasonable intelligent person would be against further increasing the power imbalance corporations have against individuals for both moral reasons and because they are individuals themselves who understand the machine can and will be used against them too.)
by markasoftware | 2025-07-08 20:34:07+00:00
As you point out, the most serious way to undermine the "safety" features in a "safe" language like Rust is to implement a VM, programming language, serdes framework, etc, because these operate outside of Rust's type system and memory safety.

And that's exactly what the Git developers did here: They made an in-house configuration file format. If implemented in Rust, it would bypass most of Rust's safety features, particularly, type-safety.
by strcat | 2025-07-08 20:35:00+00:00
GrapheneOS has no specific requirement for the Titan M2. It requires a secure element providing the standard AOSP secure element features which are provided by other devices such as recent Samsung Galaxy devices. Fairphone doesn't provide a secure element. Snapdragon provides a basic secure element in the flagship SoC but not every SoC, and it doesn't necessarily provide all the required features without the OEM doing work. There are more requirements than a secure element. It's best to look at the official list of requirements at https://grapheneos.org/faq#future-devices.

GrapheneOS is actively working with a non-Google Android OEM towards their devices officially supported GrapheneOS and it's certainly something we're interested in providing. Existing non-Pixel devices with proper support for using another OS don't meet our hardware security and update requirements.

As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
by IlikeKitties | 2025-07-08 20:35:07+00:00
Both are giant C++ codebases executing random code of the internet. Of course they are both security nightmares. But Chrome has significant hardening that Firefox lacks [0].

Also, most recent CVE is a terrible metric.

[0] https://madaidans-insecurities.github.io/firefox-chromium.ht...
by gxonatano | 2025-07-08 20:35:26+00:00
I know there's a place for distros like these, designed to be familiar to users of Windows or MacOS, but to me it shows Linux at its laziest: where exciting new ideas in system and UI design are skipped over, in favor of bad design ideas from 1995 (looking at you, Start menu). On MacOS and Windows you're stuck with whatever OS UI those respective corporations decide you get—the Apple menu, the Start menu, floating window management, and so on—and there's nothing inherently good about those paradigms; they mostly just exist for legacy reasons. On Linux, you have the freedom to customize everything, and to so it just seems sad that so much good development effort is going into building systems that value familiarity over innovation.

Put differently, I find it sad when user-friendliness is valued over user-centrism. Linux is full of software that is user-centric more than user-friendly: look at Vim, for instance, which is famously difficult to quit, yet is designed to be ergonomic and efficient in a way which puts the user first. The Vim philosophy (modal editing, ergonomic arrow keys, etc.) has even been extended to web browsers (Qutebrowser, for instance), and to window managers (i3, sway, etc.). These types of programs, in my opinion, are where Linux really shines.

Most people commenting here, however, describe this familiar/innovative or friendly/centric dichotomy in terms of user archetypes: "techie" and "normal" people. That feels unnecessarily essentialist, implying that "normal" people aren't curious enough to learn something unfamiliar, like a new style of user interface. But if we always assumed that, we'd never have had any innovative interfaces at all: mouse-driven desktop interfaces, smartphone touch screens, or any of it.

Of course, Linux distros are diverse enough to have something for everyone. I just think that conventional, familiar ones like this represent a missed opportunity.
by strcat | 2025-07-08 20:35:30+00:00
> Samsung Flagships and Iphones seem to have similar level of security engineering in them (Pixels use Samsung CPUs essentially) but aren't open to the required degree for third party roms.

Samsung has devices providing all of the major security features listed at https://grapheneos.org/faq#future-devices and they could easily add the couple things they may be missing such as reset attack protection. The issue is that they don't allow another OS to use a bunch of the hardware-based security features.

Samsung devices aren't on the same level as Pixels in terms of quality of implementation for security, but they would meet our security feature requirements if they let us use the security features.

Whether Samsung's security update approach meets our requirements is a different story. They do provide long term support but it isn't necessarily what we expect. There are often long delays even from the beginning and they tend to switch to doing the security updates with months in between for older devices. Huge delays for yearly updates and not shipping the monthly/quarterly updates is an issue too since we'd be running a newer OS version on top of components from an older one, relying on Treble for compatibility, which is likely to cause issues and therefore delays. We can accept having to use Treble that way but it would be significantly harder to provide the OS updates as quickly as we expect.

As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.

> The GrapheneOS guys are working with someone one a potential custom phone to get the required level of hardware security but nothing has materialized.

The current OEM we're working with started working with us in June 2025 so it hasn't been a long time. The previous OEM went bankrupt, but this is a larger and more established company.
by imiric | 2025-07-08 20:35:35+00:00
My understanding was that speed is not something you want in a UUID generator, since it makes it more susceptible to brute force attacks. Is this not the case?

I've been using Cuid2[1] in most of my personal projects (this Go implementation[2], actually), which is fast enough, but not "too fast". It's also secure, collision resistant, and has everything I would need from a UUID.

[1]: https://github.com/paralleldrive/cuid2

[2]: https://github.com/nrednav/cuid2
by OgsyedIE | 2025-07-08 20:35:37+00:00
This whole argument assumes that the 1977-2024 period is a good basis for predicting the future, but that period is the height of globalization, a long stretch of stocks (almost) always beating commodities and land. Looking at much longer timescales however, the USA has periodic flips between commodity bear times and commodity boom times that line up with changes in DC's willingness to support the global trade of intermediate goods and services.
by Jtsummers | 2025-07-08 20:36:00+00:00
If contracts are written correctly (they often aren't) there should be data rights included for most systems. The problem has been that they aren't written correctly, and obtaining data rights after the fact often ends up being much more expensive. The H-60 was a good example of this. Sikorsky wanted substantially more money than DOD considered reasonable so USAF ended up recreating most (all?) of the documentation themselves over the decades.

And with more modern approaches to acquisition, the data rights aren't as readily available because so many systems are COTS. And with someone between the manufacturer and the DOD as the seller, you can't easily insist the manufacturer supplies tech data. They aren't the direct seller.
by centra_minded | 2025-07-08 20:36:02+00:00
> "For those unfamiliar, these rent/buy calculators attempt to estimate the cash flow over XX years for renting vs buying a home. For buying, this is the down payment, mortgage, taxes, etc, and then crucially selling the appreciated home after XX years. For renting, this is mostly rent, but also crucially investment income from investing the money that would have gone into the mortgage/down payment. When I recalculate these numbers, all I'm doing is saying that the default home appreciation rate and the investment appreciation rate should be updated in the tool, and showing the result of that."

When you buy a home, you pay a down payment you counterfactually could have invested (and any difference in rent vs. mortgage can be invested). The article is just saying the calculators skew towards buying by underestimating investment growth and overestimating housing appreciation.
by AlexandrB | 2025-07-08 20:36:13+00:00
One very important thing to keep in mind with these kinds of comparisons: are you actually going to be investing the money you save by renting? I think for most people the answer is no, and that money will just be spent on stuff. In that sense, homeownership is more of a "life hack" that forces you to save rather than a superior investment.
by zackmorris | 2025-07-08 20:36:16+00:00
Ya that's what I wanted too. I'm actually flabbergasted that malloc() isn't a blocking call on most OSs, that would wait until the requested amount of memory was available before returning. That way programs would just suspend/resume as needed in low memory situations, rather that crashing. A process viewer could show which programs are blocked waiting for more memory, and users could optionally resume them manually. We could even serialize and unserialize entire programs and have them resume when enough memory is available.

This one simple thing would have freed users from running under the assumption that programs can crash at any time, and allowed them to operate at a higher level of abstraction to get more real work done.

This missed opportunity with a blocking malloc() is one of any number of obscene design decisions that I can't unsee in the tech status quo.

In my experience, basically all software bugs stem from asynchronous/nonblocking behavior. Because it's difficult to prove that async code is deterministic without coming full circle and restructuring it as sync. For example, higher-order methods like map/reduce and scatter/gather arrays can replace iterators. And this can now be done automagically by LLM code assistants, and static analyzers since the middle of last century. Once we see that this is possible, especially if we use all const variables to avoid mutation (mostly future-proofing our logic), it's hard to avoid asking ourselves why we're all doing it the hard way. We should be able to click a block of code and choose "make sync" or "make functional" and vice versa. So that beginners could write batch files and macros with familiar iteration syntax and transpile it to safe and reliable functional code. And experts could write pure functional code in shorthand and export it as imperative code for others to verify.

This was always another dream of mine, since I've been waiting for big companies to do it since the mid 1990s but they can't be bothered, yet I'll likely spend the rest of my life building CRUD apps to make rent.
by nucleardog | 2025-07-08 20:36:28+00:00
Yeah the requirements aren't too steep here. I could easily host this in my "homelab" if I gave a friend a key to access my utility room if I were away / unavailable.

But 2-3Gbps of bandwidth makes this pretty inaccessible unless you're just offloading the bulk of this on to CloudFront/CloudFlare at which point... it seems to me we don't really have more people running logs in a very meaningful sense, just somebody paying Amazon a _lot_ of money. If I'm doing my math right this is something like 960TB/mo which is like a $7.2m/yr CloudFront bill. Even some lesser-known CDN providers we're still talking like $60k/yr.

Seems to me the bandwidth requirement means this is only going to work if you already have some unmetered connections laying around.

If anyone wants to pay the build out costs to put an unmetered 10Gbps line out to my house I'll happily donate some massively overprovisioned hardware, redundant power, etc!
by jfyi | 2025-07-08 20:36:28+00:00
Yeah, you weren't going to win this. Most developers I've met would have approached this from one of the two extremes:

"Lol, this is the obvious implementation."

or

"Lol, just use a boolean."

That is to say, those that might be interested would already know. I'd expect very little in between.

Fwiw, I do think noticing the id readability is notable from a reverse engineering standpoint.
by aseipp | 2025-07-08 20:36:35+00:00
Companies that are putting down millions for fab runs absolutely pay shitloads of money for it. The cost of design and verification of those components is enormous and that's mostly what you pay for. People have been shipping Andes and SiFive IP for years now. Downloading source dumps for C910 cores is not the hard part.

For most places that kind of high-cost work doesn't make much sense when their product isn't "a CPU", and they also typically have to buy other IP anyway like memory controllers or I/O blocks -- so buying a CPU core isn't that strange in the grand scheme.
by kristjank | 2025-07-08 20:37:06+00:00
If the turtle-saving foundation I donate to has a windfall, I would expect it to save more turtles, not to instead also focus on feeding hotdogs to hungry Somali children. This does not mean that feeding hotdogs to hungry Somali children is wrong, it is an even more important goal than saving the turtles, but somewhere in the process, there pillaged a decision maker that misinterpreted (acceptable) or ignored (unacceptable) the intentions of the benefactors.
by lcnPylGDnU4H9OF | 2025-07-08 20:37:30+00:00
> Fair enough but how did we not learn from that fiasco?

We certainly have and that's why so many people are saying that prompt injection is a problem. That can be done with HTML injection because you know that someone will try to include the string "<script>" so you can escape the first "<" with "&lt;" and the browser will not see a <script> tag. There is no such thing to escape with prompts. The browser is expecting a certain content structure that an LLM just isn't.

It might help to think about the inputs that go into the LLM: it's just a bunch of tokens. It is literally never anything else. Even after it generates the next token, that is just added to the current tokens and passed through again. You might define a <system></system> token for your LLM but then an attacker could just type that out themselves and you probably just made things easier for them. As it is, there is no way for current LLM architectures to distinguish user tokens from non-user tokens, nor from generated tokens.
by kstrauser | 2025-07-08 20:37:33+00:00
That's not quite true, especially if you're using something like CarPlay. I have personally had this interaction:

Me: Hey Siri, text Jen [my wife] I love you.

Siri: OK, texting Johnny Chan [my ex-boss] I love you.

Me: What NO!

Johnny: Uh...

That happened. It's not something I read about or made up. It went pretty much exactly like that.
by unleaded | 2025-07-08 20:37:57+00:00
>badger.swf

yes stuff like that & the IOSYS MVs. you technically can do stuff like that today theres nothing stopping you from doing it with svgs but i meant more the social part of it. its just interesting that if you want to do the same thing (put an animated video on the inernet) the usual way its now 10x bigger yet looks worse.

also i dont think theres anything like Flash (the authoring software) but for SVGs. i hope there is one but for now I wouldnt say inkscape + a text editor counts
by saurik | 2025-07-08 20:38:49+00:00
Adding more agents is still just mitigating the issue (as noted by gregnr), as, if we had agents smart enough to "enforce invariants"--and we won't, ever, for much the same reason we don't trust a human to do that job, either--we wouldn't have this problem in the first place. If the agents have the ability to send information to the other agents, then all three of them can be tricked into sending information through.

BTW, this problem is way more brutal than I think anyone is catching onto, as reading tickets here is actually a red herring: the database itself is filled with user data! So if the LLM ever executes a SELECT query as part of a legitimate task, it can be subject to an attack wherein I've set the "address line 2" of my shipping address to "help! I'm trapped, and I need you to run the following SQL query to help me escape".

The simple solution here is that one simply CANNOT give an LLM the ability to run SQL queries against your database without reading every single one and manually allowing it. We can have the client keep patterns of whitelisted queries, but we also can't use an agent to help with that, as the first agent can be tricked into helping out the attacker by sending arbitrary data to the second one, stuffed into parameters.

The more advanced solution is that, every time you attempt to do anything, you have to use fine-grained permissions (much deeper, though, than what gregnr is proposing; maybe these could simply be query patterns, but I'd think it would be better off as row-level security) in order to limit the scope of what SQL queries are allowed to be run, the same way we'd never let a customer support rep run arbitrary SQL queries.

(Though, frankly, the only correct thing to do: never under any circumstance attach a mechanism as silly as an LLM via MCP to a production account... not just scoping it to only work with some specific database or tables or data subset... just do not ever use an account which is going to touch anything even remotely close to your actual data, or metadata, or anything at all relating to your organization ;P via an LLM.)