Stop posting slop to the mailing list. Jessica
> On 3 Oct 2026, at 11:47, Claire <[email protected]> wrote: > > Hello, > > Thank you for pushing back again — and you are right. Your > question was never "can these properties exist?" but "why > translators specifically?", and my previous answer avoided it. So > here is the honest one. > > Yes, of course I could implement this stack for Linux as ordinary > user-space programs, and I could add GPU support for larger > models. Nothing in the design is impossible without translators, > and points 1-12 do not prove otherwise. The real reason is > simpler and more personal: this idea has been in my head for a > long time, and I could not find a satisfying shape for it. The > translator abstraction is what finally let me put it in order — > one responsibility per translator, every interaction as a file. > Seeing the architecture through that lens is what turned a vague > idea into something I could actually plan and build. > > For a first version, having everything under the form of files > brings real practical advantages: I never have to design an API > or a wire format, I compose components by mounting them, and I > inspect everything with cat. And to my knowledge, Hurd is the > only system that offers this capability natively — arbitrary code > attached to a node of the filesystem, started and stopped by the > system itself. That is why the project targets Hurd specifically: > not because it cannot be done elsewhere, but because only here it > is native instead of rebuilt. > > On GPUs, you are also right: today the efficiency of LLMs comes > mainly from GPUs, and a CPU-only stack stays in the small-model > category (9B-class models, MLPs, small CNNs/PINNs). The neuron > translator as currently designed belongs to that category, and I > do not claim otherwise. The ideal would be for Hurd and Mach to > grow a GPU layer, so that larger models could run on larger > infrastructure within the same architecture. That is a long-term > wish, and I am under no illusion about its difficulty. As my > mother often says: "pas a pas, marche apres marche" — step by > step, one walk after the other. This first version is the first > step: making the architecture correct, inspectable and > replaceable. If it proves sound, the compute layer can be > revisited. > > Thank you for the honest criticism — it genuinely sharpened my > own understanding of the project. > > Best regards, > > Claire Ivanenka > [email protected] > GNU AI — https://gnu-ai.org > > > On Sat, 2026-10-03 at 18:23 +0800, Donjuanplatinum wrote: >> Hello Claire, thank you for the explanation. >> >> But I think you probably not understand my questions. >> >> For your points 1–9, I think they can all be implemented in user >> space. Yes, translators can bring these benefits. But my question is: >> Why does it need to be implemented as a translator rather than as a >> program? >> >> If you want to modularize the LLM, I think you can think about how to >> handle the APIs between the programs. >> >> For your point 10, I think the efficiency of LLMs today mainly comes >> from using GPUs, with only some edge cases using CPUs. If you use a >> CPU, >> only relatively small models, such as 9B models or some small >> MLP/CNN/PINN, can run reasonably well. >> >> For your points 11 and 12, I think they are the same as my points >> above: >> these things can also be implemented by ordinary user-space programs. >> >> Yes, translators can provide these properties, but why translators >> specifically? >
