6,078 karma · joined July 31, 2013
Wow, peak ableism. It is a post about how I use an LLM as an accessibility aid for reading and writing. We're not all out here faking creative writing you know...
https://rustc-dev-guide.rust-lang.org/offload/internals.html https://github.com/rust-lang/rust/issues/131513
No idea how that compares to running a larger model and context though.
I LOVE reading LLM content. I find that they tend to present things in a way that keeps my attention - something I have struggled with my whole life. I also use LLMs to assist with managing my own thoughts and helping make things coherent overall.
Sure, there is a LOT of slop out there, but the promotion of quality content is what crowd-sourced curation like HN tends towards. Much of the LLM assisted content here has a high signal to noise ratio, and is clearly a lot more involved than simply prompting "write an article on X" - despite what the haters say.
Why not just block all the inbound connections you don't need? Is there a particular reason your firewall policy needs to be xenophobic?
"Microblogs, for example on Twitter..." https://dictionary.cambridge.org/dictionary/english/microblo...
"Some popular social networks such as X (formerly Twitter), Threads, Tumblr, Mastodon, and Bluesky can be viewed as collections of microblogs." https://en.wikipedia.org/wiki/Microblogging
I just wanted to give a bit of feedback as someone who reads them - and point out that on almost every twitter/bluesky submission to HN they are using ways to work around the 280/300 char limitations.
To play devils advocate - 500 also seems a bit arbitrary ;) If I were making a platform like this myself, I would go for a power of 2 that makes sense for storage/buffering. Maybe 1KiB including all meta, etc. You could comfortably fit a post the size of your about page, and all associated meta in that - even when serialised as JSON or something. I'd go from there and work backwards to come up with a size that has a real technical purpose.
My comment on the about page was that it needed more than 280 chars to communicate what the app is about - even the title + intro exceeds the limit.
If it is truly believed that 280 chars is enough to communicate an idea, then the about page should follow that philosophy.
Almost every twitter/x post submitted to HN has people labelling their posts as "X of Y" threads, using images as text, or using pro account posts.
You can see it yourself: https://news.ycombinator.com/from?site=twitter.com Ive just looked at 30 and each of them exceed 280 chars by far.
If you are going to limit it to short posts, maybe the length of a short post is the length to limit it to, rather than emulating the 2xSMS of every twitter clone?
Other than that, it looks really clean and neat - I just dont think being 280 chars adds anything other than resulting in people posting with pagination as per X 1/3.
The gameplay itself was a bit rough, but the music and immersion I felt while playing it I still recall to this day.
Whats is wrong with this?
I work with durable tracing (not using NATS, or k8s though) and this looks almost exactly what I would expect to see in a coordinator log after repartition of a storage cluster.
Obviously I don't know what your actual context was, though.
Isn't that what current agents already do? e.g. codex: https://ibb.co/Y71qJJZb
I also did some light simulations so we could see how the skirting roof around the building would allow light in for summer vs winter.
We have been very happy we used VR. It allowed us to iterate on what felt right, communicate exactly what we wanted to the builder, and the sunlight simulations have allowed it to be comfortably usable year round - letting light in during the winter, but keeping direct light out during the summer.
Dont try and handle the entire project in context.
Use a well structured filesystem layout for your code with a few lines in an AGENTS.md describing the layout and core architectural requirements (no more than that, as per the article!).
Then work on small-medium tasks at a time with a fresh context.
At the end of your task, ask the agent if there are any key points about the project layout or architecture it would want to add to memory - audit those manually and amend your AGENTS.md accordingly.
If your code is well structured and you keep your tasks localised, you can get away with seemingly minuscule context windows.
It's also worth noting that high effort models love to slurp up whatever context they can. You almost never need/want high effort for non cross-cutting tasks.