2,327 karma · joined June 30, 2015
Some feedback:
- I definitely don't want three long new messages on every PR. Max 1, ideally none? Codex does a great job just using emoji.
- The replay is cool. I don't make a website, so maybe I'm not the target market, but I'd like QA for our backend.
- Honestly, I'd rather just run a massive QA run every day, and then have any failures bisected, rather than per-PR.
- I am worried that there's not a lot of value beyond the intelligence of the foundation models here.
> Your smartphone contains materials processed through semiconductor fabrication, chemical etching, metal anodizing, glass tempering, and electroplating — none of which you could start a new facility for in California without years of litigation.
I agree that we should make it easier to do things, specifically by decreasing the amount of litigation involved in doing stuff. But the risk of a bunch of litigation isn't a ban, right? I get that it's trying to be attention-grabbing, but calling it a ban when it's not just sort of confuses the issue.
Instead, I now swear by atuin.sh, which just remembers every command I've typed. It's sort of bad, since I never actually get nice scripts, just really long commands, but it gets you 50% of the way there with 0 effort. When leaving my last job, I even donated my (very long) atuin history to my successor, which I suspect was more useful than any document I wrote.
My only hot tip: atuin overrides the up-arrow by default, which is really annoying, so do `atuin init zsh --disable-up-arrow` to make it only run on Ctrl-R.
I wonder if for almost any bulk inference / generation task, it will generally be dramatically cheaper to (use fancy expensive model to generate examples, perhaps interactively with refinements) -> (fine tune smaller open-source model) -> (run bulk task).
How/why did the package maintainers start using all these improvements? Some of them sound like a bunch of work, and getting a package ecosystem to move is hard. Was there motivation to speed up installs across the ecosystem? If setup.py was working okay for folks, what incentivized them to start using pyproject.toml?
But, there's really good stuff that I've loved just a bit down the list: Foundation, The Left Hand Of Darkness, The Dispossessed, Stories of Your Life and Others, Exhalation, Children Of Time, Dune.
Was surprised the Mars trilogy was pretty low (might be the keyword indexing?) - highly recommend, as long as you don't get too bored by descriptions of rock.
I disagree that ML-KEM is "obviously weaker". In some ways, lattice-based cryptography has stronger hardness foundations than RSA and EC (specifically, average -> worst case reductions).
ML-KEM and EC are definitely complementary, and I would probably only deploy hybrids in the near future, but I don't begrudge others who wish to do pure ML-KEM.
If an organization wants to force its clients or servers to use pure ML-KEM, they can already do this using any means they like. The standardization of a TLS ciphersuite is besides the point.
> He comes with historical and procedural evidence of bad faith. Why is this ridiculous?
Yes, the NSA has nefariously influenced standards processes. That does not mean that in each and every standards process (especially the ones that don't go your way) you can accuse everyone who disagrees with you, on the merits, of having some ulterior motive or secret relationship with the NSA. That is exactly what he has done repeatedly, both on his blog and on the list.
> why wouldn't you equate that to working for the NSA (or something equally bad)?
For the simple reason that you should not accuse another person of working for the NSA without real proof of that! The standard of proof for an accusation like that cannot be "you disagree with me".
AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.
He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous.
You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb
I would pay you guys for E2EE syncing, but I think it’s free at the moment. Charge me!
I had not heard of this metric before - it’s neat and simple to understand. If you scaled it down to 0-100 (by dividing by 100), I think it would make the numbers more immediately understandable. I’d even consider inverting it (so 0 = centralized and 100 = decentralized), since the website title implies measuring progress ‘towards’ decentralization.
While it’s true that FHE schemes continue to get faster, they don’t really have hope of being comparable to plaintext speeds as long as they rely on bootstrapping. For deep, fundamental reasons, bootstrapping isn’t likely to ever be less than ~1000x overhead.
When folks realized they couldn’t speed up bootstrapping much more, they started talking about hardware acceleration, but it’s a tough sell at time when every last drop of compute is going into LLMs. What $/token cost increase would folks pay for computation under FHE? Unless it’s >1000x, it’s really pretty grim.
For anything like private LLM inference, confidential computing approaches are really the only feasible option. I don’t like trusting hardware, but it’s the best we’ve got!
Do you run into rate limits or other issues with TLS cert issuance? One problem we had when doing this before is that each spinup of the enclave must generate a fresh public key, so it needs a fresh, publicly trusted TLS cert. Do you have a workaround for that, or do you just have the enclaves run for long enough that it doesn’t matter?
"No worthy use of an LLM involves other human beings reading its output."
If you use a model to generate code, let it be code nobody has to read: one-off scripts, demos, etc. If you want an LLM to prove a theorem, have it generate some Coq and then verify the proof mechanically. If you ask a model to write you a poem, enjoy the poem, and then graciously erase it.
(of course, it’s still interesting to read about 90s encryption, so I appreciate that they did it the fun way)