Critical severity vulnerabilities are only critical when they are reachable, but are completely meaningless if your application doesn't touch that code at all. It's objectively more risky to "patch" those by updating dependencies than just let them be there.

I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea.

Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that often, really when something either breaks or there is a legitimate security reason to do so, which in deep systems software is quite infrequent.

Funnily enough for frontend NPM code our policy was to never ever upgrade and run with locked dependencies, running few years old JS deps. For internal dashboards it was perfectly fine, never missed a feature and never had a supply chain close call.

Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view.

Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.

In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.

But if you're buying a $500k GPU server putting 100TB of nvme in there for $50-100k is justifiable.

At least our local GPU server still serves Kimi K2.5 to my team just fine.

In principle this model should also work much better with desktop AI agents, but that is not a problem I need to solve now.

Comments URL: https://news.ycombinator.com/item?id=46571726

Points: 1

# Comments: 0

And those are the worst models we will have used from now on.

I don’t believe I can do the same with Rust.

Maybe the value prop is not clear, the website talks a bunch about AI agent integrations, that sounds like a completely different product to a parser library, which however advanced it may be, investors will likely see as tangential bit of IP that a senior engineer can build for $10-20k in a few days.

It’s definitely complicated, but it’s a kind of usb-c of smart home - you only worry about the complex part when building a product. Just wish there was a better device reset/portability story.

Unlike websockets you can supply "cert hash" which makes it possible for the browser to establish a TLS connection with a client that doesn't have a certificate signed by a traditional PKI provider or even have a domain name. This property is immensely useful because it makes it possible for browsers to establish connections to any known non-browser node on the internet, including from secure contexts (i.e. from an https page where e.g. you can't establish a ws:// connection, only wss:// is allowed but you need a 'real' tls cert for that)

Also it’s borderline impossible to tune nfs to go above 30gbps or so consistently, with WebDAV it’s a matter of adding a bunch more streams and you’re past 200gbps pretty easily.

Only tricky thing is if currents induced in motors are too hard to reject in driver circuitry, tho even at the extreme this should be possible to insulate with capacitors (or worse/heavier with transformers)