Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Like everything else in this world, its utterly and completely unfixably broken: There is no way you can have complex huge dependencies properly.

The best most paranoid thing is to have multiple networking layers hoping they have to exploit multiple things at once, and whitelist only networking for exactly what you are expecting to happen. (which is completely incompatible with the idea of ssl, we would need a new type of firewall that sits between ALL applications before encryption, like a firewall between applications and the crypto library itself, which breaks a bunch of other things people want to do)



You can have complex huge dependencies, provided that they can be audited properly. Which means that, for starters, they need to be broken into smaller chunks for which the behavior can be fully specified. They need to be written in languages that are, inasmuch as it is possible, formally verifiable against the spec, even at considerable expense of performance. And where that is not possible, the languages still need to be the kind where any behavior that is not straightforward sticks out like a sore thumb.

Then once you do all that, of course, you have one particular version that has been audited and can be used as a dependency. Which means that "ship early, ship often" and "move fast and break things" are completely off the table.

In short, it means doing more or less the exact opposite of the trends in the industry for the past 50 years or so. Starting with rewriting everything that we already have.

And it will be insanely expensive, of course, because the sheer amount of man-hours needed on all this are massive. Nor can you get away with cheap disposable labor for most of it, since writing specs and formal proofs and doing audits all requires a very skilled labor force.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: