I can't figure out why this font is better than DejaVu Mono, or Monaco (mac). They all look basically the same to me. I actually would love someone to explain what the difference/improvement is, in other parts of life I know subtle changes add up.
HN user
rhaps0dy
Yes. That's why you should use Doom Emacs.
Thank you, this was fun, I sang notes for a bit :)
Thank you for saving me a skim
No RSS? I want to subscribe :'(
Possible! But fixing this seems easier than re-writing in Rust with reasonable expectation that the software behaves the same?
Most Linux CVEs are memory corruption bugs. Previously I argued that we should compile C to be memory-safe rather than translating all C to Rust, to avoid introducing logic bugs.
Here, I argue that several parts of the kernel can also be compiled in a memory-safe way.
Unless we go extinct. But I concur.
I'm vegan, I don't eat tortured animals. Thanks though.
Yeah, that's fair. There's hope though!
Yeah, but long term it will increase GDP due to the UK being able to have better (fewer) regulations than those allowed by the EU. It does require Parliament getting it together.
To solve all the problems with Helm it seems easy enough to use Python dataclasses that serialize to YAML (or your favourite language).
Then to convert a new Helm chart to this you can just use AI + tests that check the two things render to the same output.
This is awesome. Measurement and experiment for a very quotidian thing is a great vibe.
Yeah, it's very clearly LLM-edited, but it's fun to read. The LLM did a good job.
It's not just a tech blog post - it's a thriller. ;)
Basically Emacs Lisp. Where `nil` is the only falsy value, and anything else (including `t`, which analogizes to `Some(())`) are truthy values.
First, like others mentioned, you'll have N+1 problems for nested lists. That is, if we call comments() on each post and author() on each comment, we absolutely don't want to have one individual call per nested object. In GraphQL, with the data loader pattern, this is just 3 calls.
Why is that a problem? As far as I can tell, those calls are all done on the server, where they're cheap normal function calls, and the results are all sent back with 1 roundtrip; because of the pipelining.
Super cool work!! How much of a limitation is it to have the robot be basically 3D-printable? Though I can see it's basically required for making it buildable by others.
The easiest thing to do is probably use A* to find the solution, then imitation learning on the NN to learn it. (The immediate feedback gets rid of the vanishing/exploding gradients problem).
latest update from Xe:
After further investigation and communication. This is not a bug. The threat actor group in question installed headless chrome and simply computed the proof of work. I'm just going to submit a default rule that blocks huawei.
Wouldn't the other way around be easier for finding good tools?
I agree, and Pyrefly seemed good; I was just wondering why people don't mention it.
Thank you for the comparison thread and post, I've read it and found it useful! Thanks to that post I know ty has a "gradual typing" philosophy, which I disprefer.
I mean, sqlalchemy until very recently needed a mypy plugin to type correctly (https://docs.sqlalchemy.org/en/20/orm/extensions/mypy.html), which was just deprecated in 2.0.0.
Perhaps you should do the upgrade (https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...) and try again?
Hah, I stand corrected. In my defense, Ty make it a lot more obvious and ominous on their github (https://github.com/astral-sh/ty):
/!\ Warning
ty is in preview and is not ready for production use.
We're working hard to make ty stable and feature-complete, but until then, expect to encounter bugs, missing features, and fatal errors.
I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/
Is there a good reason to avoid using Pyrefly?
I would describe it as exactly "resolving a license compatibility issue". Taint in linux kernel refers to marking this kernel as not supported, which often just means not purely GPLv2 compatible anymore. Proprietary AMD and nVidia drivers also cause taints. https://unix.stackexchange.com/a/118117/251582
Though if the rust compiles to NVVM it’s exactly as bad as C++ CUDA, no?
Sutton was talking about progress in AI overall, whereas Pinhasi (OP) is talking about building one model for production right now. Of course adding some hand-coded knowledge is essential for the latter, but it has not provided much long-term progress. (Even CNNs and group-convolutional NNs, which seek to encode invariants to increase efficiency while still doing almost only learning, seem to be on the way out)
The whole story, or the 3x7r3m3 13375p34k 0f 7h3 5k1dd13?
Oh no, Pytorch does the same thing:
a = torch.tensor(-2*31, dtype=torch.int32) assert a == a.abs()
I've been in conferences in Ciudad de México and it was a very pleasant experience. I honestly haven't been anywhere else in Mexico.
You could host it in Mexico or Canada, they're pretty nice!