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?
