I visited a long-time friend recently and was surprised that they were using modern LP player for music. But the surprise itself actually turned into curiosity. I got the urge to buy one too, if only to go back to the more-dedicated experience of choosing a disk from a catalog and playing it with explicit intention.
Maybe LPs are too much, but trying physical CDs again sounds like a cool idea. Especially because they can easily be rewritten and maybe I could get kids to create their own "mix tapes".
Shameless plug for my https://blogsystem5.substack.com/p/beyond-the-1-mb-barrier-i... article from a couple of years ago. You'll find a deep dive on unreal mode (I just learned it's also known as "vodoo mode") and some hands-on code to play with it ;-P
I'm sorry but the landing page at fuzix.org (the top page nonetheless) is terrible as it does not even try to explain what FUZIX even IS. I went to the GitHub project page, which contains some more details, but it still doesn't answer the question and only talks about how FUZIX differs from UZI.
To be honest, I still have no idea what I'm looking at.
"Munitions"? "Intelligent distribution panel"? Look, the UNIX part might not be obvious at all, but if you somehow didn't have enough of a rough idea after seeing that many retro CPUs and systems listed below, that might say more about you than the author.
That wasn't ever in doubt. That's also not the relevant piece of information - people looking for a summary want to know why the thing is worth paying spending time on, not random attributes
You do realize when you say that you do assume they know it's an OS and by that you effectively have to regress into using the same level of argument as me just like how I assume they don't know it's an OS, right?
LLMs definitely can do this. The output tends to be overly positive though, claiming that any sort of rough draft you give them is "great, almost ready for publishing!". But the feedback you can get on clarity, narrative flow, weak spots... _is_ usually pretty good.
Now, following that feedback to the letter is going to end up with a diluted message and boring voice, so it's up to you to do with the feedback whatever you think best.
I never ask the LLM to evaluate my text in terms of being good or bad. Instead I try something like this:
"In this section I tried to explain X, I intended to sound in Y and Z fashion, and I want a reader to come out with ateast W impression. Is the text achieving these goals? Do I communicate my ideas clearly and consisely, or are they too confuse and meandering?"
I typically get useful feedback. I preface specifically asking it to not rewrite, simply pointing the bits that it finds faulty and explaining why.
Of course the prompt is different is I am writing, for example, technical documentation, or if it is an attempt at creative writing.
I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
I feel like if you want to learn Nix with some hand-holding, resist the urge to use Claude Code or Codex, but instead just use the chatbot in the browser or something. Ask it questions, explicitly copy and paste in errors as they come up, and manually copy and paste out the generated stuff.
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
> and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI).
That's (one of the reasons) why I'm favoring Codex over Claude Code.
Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving aside that GPT's responses also seem more concise). At some point, I had both chewing concurrently on the same machine and same project, and Claude Code was using multiple GBs of RAM and 100% CPU whereas Codex was happy with 80 MB and 6%.
Performance _is_ a feature and I'm afraid the amounts of code AI produces without supervision lead to an amount of bloat we haven't seen before...
I think you’re confusing capital c Claude Code, the desktop Electron app, and lowercase c `claude`, the command line tool with an interactive TUI. They’re both TypeScript under the hood, but the latter is React + Ink rendered into the terminal.
The redraw glitches you’re referring to are actually signs of what I consider to be a pretty major feature, a reason to use `claude` instead of `codex` or `opencode`: `claude` doesn’t use the alternate screen, whereas the other two do. Meaning that it uses the standard screen buffer, meaning that your chat history is in the terminal (or multiplexer) scrollback. I much prefer that, and I totally get why they’ve put so much effort into getting it to work well.
In that context handling SIGWINCH has some issues and trickiness. Well worth the tradeoff, imo.
Codex is using its app server protocol to build a nice client/server separation that I enjoy on top of the predictable Rust performance.
You can run a codex instance on machine A and connect the TUI to it from machine B. The same open source core and protocol is shared between the Codex app, VS Code and Xcode.
That's the same reason I don't like Opencode, but Codex doesn't use the alternate screen. I remember it did when it was very very new, but now it doesn't.
Ah nice, good to know. I hadn’t used codex in a while. I actually really like opencode and its ui, just wish it didn’t clear the screen on exit. It could at least redraw whatever was last in the chat, that would be better than nothing.
I had a nasty slow claude code startup time at one point something like 8s, a clean install sorts it all out. Back up your mcp config and skills and you're good.
I think Go might be a better choice but not for that reason at all.
Go could implement something like this with no dependencies outside the standard library. It would make sense to take on a few, but a comparable Rust project would have at least several dozens.
Also, Go can deliver a single binary that works on every Linux distribution right out of the box. In Rust, its possible but you have to static compile with muslc and that is a far less well-trodden path with some significant differences to the glibc that most Rust libraries have been tested with.
My personal opinion is that I like Rust much more than Go, but I can’t deny that Rust is a big, and more dauntingly to newcomers, pretty unopinionated language compared to Go.
There are more syntax features, more and more complex semantics, and while rustc and clippy do a great job of explaining like 90% of errors, the remaining 10% suuuuuck.
There’s also some choices imposed by the build system (like cargo allowing multiple versions of the same dep in a workspace) and by the macro system (axum has some unintuitive extractor ordering needs that you won’t find unless you know to look for them), and those things and the hurdles they present become intuitive after a time but just while getting started? Oof
LLMs should know that, for maybe a CRUD app, there should be taken care of security at various layers, i.e. input validation in controllers. Knowledge from popular frameworks that communicate security boundaries should be transferable for them, even if everything is custom code. Very confusing to me how they manage to completely ignore so much of it. I guess they are too good following suit of a productivity minded vibe coder.
Frankly I don't think one even needs to learn it, if you know a bunch of other languages and the codebase is good. I was able to just make a useful change to an open source project by just doing it, without having written any lines of Go before. Granted the MR needed some revisions.
Rust is my favorite, though. There are values beyond ease of contribution. I can't replicate the experience with a Rust project anymore, but I suspect it would have been tougher.
agents don't really care and they're doing anywhere between 90-100% of the work on CC. if anything, rust is better as it has more built-in verification out of the box.
Rust is accessible to everyone now that Claude Code and Opus can emit it at a high proficiency level.
Rust is designed so the error handling is ergonomic and fits into the flow of the language and the type system. Rust code will be lower defect rate by default.
Plus it's faster and doesn't have a GC.
You can use Rust now even if you don't know the language. It's the best way to start learning Rust.
The learning curve is not as bad as people say. It's really gentle.
Java (incl. Scala, Closure, Groovy, Jython, etc.) is better suited to running as a server. Let agents write clean readable code and leave performance concerns to the JIT compiler. If you really want you can let agents rewrite components at runtime without losing context.
Erlang would offer similar benefits, because what we're doing with these things is more message passing than processing.
Rust is what I'd want agents writing for edge devices, things I don't want to have to monitor. Granted, our devices are edge devices to Anthropic, but they're more tightly coupled to their services.
There is literally no reason to write it in a JVM language in 2026 when better options exists. Either Go for simplicity and maintaininability or Rust to get the most out of the machine works.
Also, it'll be hard for them to lure good people to work on that thing. Absolutely no one is getting excited to write, vibe, or maintain Java.
I am not thrilled to use java, but it really does what it says on the tin. A customer copied the jar file I sent them to their as400 and it just worked. There is nothing quite like it.
Hi go binary, unfortunately you don't exist, because there is no cross compiler for that platform. Also please don't crash if you ever do get cross compiled, since the target system doesn't understand your utf8 strings.
I run many instances of Claude Code simultaneously and have not experienced what you are seeing. It sounds like you have a bias of Rust over Typescript.
No, they are describing a typical experience with the two apps. Just open both apps, run a few queries, and take a look at the difference in resource management yourself. It sounds like you have a bias of Claude Code over Codex.
Uh, it sounds like you're having trouble understanding that people in this thread are talking about two wildly different "claude code" applications. Those who are claiming the resources issues don't apply to them are referring to the cli application, ie: `claude` and those are saying things like "Just open both apps..." are surely referring to their GUI versions.
No, I've never used the GUI version. I literally just had to close and reopen the terminal running the Claude Code CLI on my Mac yesterday because it was taking too many resources. It generally happens when I ask Claude to use multiple sub agents. It's an obvious memory leak.
I visited a long-time friend recently and was surprised that they were using modern LP player for music. But the surprise itself actually turned into curiosity. I got the urge to buy one too, if only to go back to the more-dedicated experience of choosing a disk from a catalog and playing it with explicit intention.
Maybe LPs are too much, but trying physical CDs again sounds like a cool idea. Especially because they can easily be rewritten and maybe I could get kids to create their own "mix tapes".
reply