rivetfasten

Speaking of low effort, "ban Z" does not constitute a thoughtful and intelligent solution to "Z created a problem."

Z=AI in this case, but lazy solutions are as old as time.

Colorado and a few other states have zero knowledge proof apps capable of this.

This is fantastic, except that the idea of mandatory government software only available on chosen proprietary platforms feels way worse.

If there were a way to crypto-notarize a third-party wallet token etc blah blah, then it would be interesting.

At the end of the day though, this is about protecting the powerful, not the kids.

It seems to me that plenty of privacy-preserving techniques already exist, don't require research level technology, don't take 100x the energy and time...

and average people still can't or don't use them.

I'm excited about HE, and I also think we shouldn't be confused that tangible, drastic privacy improvements are an unsolved research problem.

Also the idea of making LLMs consume even more compute is nauseating. This is still good research mind you, but the same effort put into making local LLMs run better/faster on modest hardware would have more social value.

The discussion about cpu caching challenges etc seems like it's missing the point. Wouldn't it be more likely to DMA the results to a GPU anyway?

I was under the impression they're doing a chiplet thing to get heterogenous processes for that reason.

My b&w laser from brother has been working perfectly for over 10 years. No software installation. Wifi, Ethernet, or USB. Everything I need and nothing I don't. Color would be nice but I've never seen it be worth the hassle to own.

That works fine for some crypto algorithms, but as stated in the paper not for everything.

As I understand it, this proof needs to support conditionals for example.

I use neovim on NixOS and many others do too. I don't see what one has to do with the other.

It blows my mind that Algebraic types are only just breaking into the mainstream. Someone told me Rust invented them, which is funny because Rust wasn't around in 1961!

It's very nice that SQL dbs have the same bones such that a migration between them is even reasonable for a small team.

That said I've led such a migration, and there's no such thing as "standard SQL" in real practice. You're always going to need extras or optimizations.

Rel itself looks really nice, but I have a hard time imagining trying to justify a new query language in business terms. Breaking with SQL completely doesn't seem worth it compared to simply extending or restricting the language like every engine does anyway.

Rel seems to offer more than SQL, it's just hard to assess the value.

A SQL engine whose dialect enforces unique rows and doesn't include NULL isn't even so different from standard.

Knoppix was the first Linux distro I ever tried back in the early 2000s. IIRC it was only a few hundred megs.

At the time it didn't have the overlayfs feature which often felt limiting since most directories were read only. Slax felt like a serious upgrade since you could install more packages after booting the CD.

I think Knoppix was the original live CD distro though?

Cool, I'll have to try it in the next 18 months before they turn it down.

"... the equivalent of a broadcast TV channel that only showed 7 minutes of actual TV content per hour, devoting the other 53 minutes to paid commercials and promotions ... Almost no one would watch such a channel."

QVC exists. That channel is ONLY ads.

Not to detract from the point, which seems to be "yes what this other guy said."

Thanks for the post!

Question: While you would want any official arch built natively, maybe an interim stage of emulated vm builds for wip/development/unsupported architectures would still be preferable in this case?

Comparing the tradeoffs: * Packages disabled and not built because of long build times. * Packages built and automated tests run on inaccurately emulated vms (NOT cross compiled). Users can test. It might be broken.

It's an experimental arch, maybe the build cluster could be experimental too?

I don't know the reason TextFormat was invented, but in practice it's way easier to work with TextFormat than JSON in the context of Protos.

Consider numeric types -

JSON: number aka 64-bit IEEE 754 floating point

Proto: signed and unsigned int 8, 16, 32, 64-bit, float, double

I can only imagine the carnage saved by not accidentally chopping of the top 10 bits (or something similar) of every int64 identifier when it happens to get processed by a perfectly normal, standards compliant JSON processor.

It's true that most int64 fields could be just fine with int54. It's also true that some fields actually use those bits in practice.

Also, the JSPB format references tag numbers rather than field names. It's not really readable. For TextProto it might be a log output, or a config file, or a test, which are all have ways of catching field name discrepancies (or it doesn't matter). For the primary transport layer to the browser, the field name isn't a forward compatible/safe way to reference the schema.

So oddly the engineers complaining about the multiple text formats are also saved from a fair number of bugs by being forced to use tools more suited to their specific situation.