Yeah, nommu absolutely doesn't imply zero memory isolation. I have a kernel port to an architecture with a nonstandard way of doing memory isolation and the existing nommu infrastructure is the only reason it can exist.
It's funny, I would actually argue the opposite point. When Deno and Bun first came out, they promised a hard break from the Node ecosystem, like how Deno leaned heavily into browser compatibility, and Bun into framework features like Bun.App.
At some point they both decided that Node compatibility was more important than their unique features, but in the time since their release Node got type stripping, require(esm), sqlite, single executable apps, a permission system, a test runner, and basically ever other Deno/Bun feature they could port over.
So at this point why use runtimes that imitate Node when you could just use Node? You'll get most of the modern niceties, but also get 100% compatibility with the existing ecosystem.
> When Deno and Bun first came out, they promised a hard break from the Node ecosystem
I don't think that's true for Bun. In fact Bun was planned to NOT break from Node ecosystem as much as possible:
"Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more." - 2022
Fabrice does a great job at building these self-contained pieces of software which often grow to have lives of their own. As a lesser known example, JSLinux's terminal emulator was forked a few times and is now known as xterm.js, which has become the predominant web embeddable terminal emulator.
This all comes full circle, because now I'm building a true successor to JSLinux that's way faster because I've natively compiled the kernel/userspace to wasm, and of course I'm using xterm.js for the terminal emulation.
If you like buggy demos that probably shouldn't be shared yet, you should check out https://linux.tombl.dev, but note that it's currently just a busybox shell and nothing else, so I hope you're good with `echo *` instead of `ls`.
attempted to munmap
------------[ cut here ]------------
WARNING: CPU: 3 PID: 36 at kernel/exit.c:812 0x00000000
CPU: 3 PID: 36 Comm: sh Not tainted 6.1.132 #
Stack:
at vmlinux.o.__warn (https://linux.tombl.dev/dist/vmlinux-NLTKI6YG.wasm:wasm-function[278]:0x17655)
at vmlinux.o.warn_slowpath_fmt (https://linux.tombl.dev/dist/vmlinux-NLTKI6YG.wasm:wasm-function[279]:0x1772b)
at vmlinux.o.do_exit (https://linux.tombl.dev/dist/vmlinux-NLTKI6YG.wasm:wasm-function[329]:0x1985e)
at vmlinux.o.task_entry_inner (https://linux.tombl.dev/dist/vmlinux-NLTKI6YG.wasm:wasm-function[154]:0x12249)
at vmlinux.o.task_entry (https://linux.tombl.dev/dist/vmlinux-NLTKI6YG.wasm:wasm-function[153]:0x12155)
at self.onmessage (https://linux.tombl.dev/dist/worker-MHWHWELT.js:151:53)
---[ end trace 0000000000000000 ]---
I'm effectively lying to the kernel about the environment it's executing in, and trying to convince it that it's running on the kind of hardware it expects, when in reality it's running inside a very different environment.
Since I map guest threads 1:1 to host threads in JS, and architecture-specific code manages the loading/unloading of programs, the exec syscall is exercising these lies in a way that they're not currently equipped to handle.
What I'm currently doing is improving those lies to the point where exec stops noticing they're lies and just starts functioning as expected.
I got that with echo * which you suggested to use :)
I opened that on my Android Phone and half expected it not to boot at all. But it does. I have no idea about the state of WASM n stuff, but apparently, it's much more eadvanced than I anticipated. Mind blown.
This brings back memories. I haven't looked at it in a while, but I'm glad to see the fork[1] of my fork[2] from 12 years ago is still thriving. Looks like it's been mostly rewritten. Probably for the better.
Awesome, I suppose it's more energy efficient then jslinux and can be run on iOS, it might be a good alternative for A-Shell or iSH.
I tried it on my a MacBook, but the keyboard input doesn't register.
Thanks for pointing this out, I've deployed a fix. One of my goals for the project is to create a useful computing environment on top of any arbitrary locked down platform, so I'd love to turn it into an iOS app at some point.
I'm slightly hesitant to mention it for fear of a flamewar, but as someone with a niche usecase that procludes me from using systemd/glibc, I'm very grateful to Chimera as a modern take on non-GNU/Linux.
yeah I'm also taking great inspiration from Alpine, but I like to see diversity in the space.
as one example, musl values portability over performance (great for my usecase), which makes it often significantly slower than glibc. Alpine keeps their musl relatively close to upstream, where Chimera is patches theirs more heavily.
no? there's only a single mention of cargo in the entire kernel, and it's in a docs page describing how to install bindgen, a toolchain dependency of the kernel, below a whole list of other non-cargo ways to install bindgen.
Go's "nothing is async because everything is async" model, combined with WebAssembly's (current) lack of support for stack switching and arbitrary goto, essentially mean that the compiler needs to insert extra code everywhere to support arbitrarily un/rewinding the stack.
This massively bloats binaries and means that go compiled to wasm is much slower than native speed, significantly more so than than the equivalent slowdown for c/rust.
I believe this is still true. Originally you could store a compiled wasm module in IndexedDB and cache it manually, but that was removed in favor of {instantiate,compile}Streaming, which take a HTTP response and hook into the existing HTTP caching layer, which was already storing the compliation output for JS.
wasm has no way to remap writable memory as executable, but you can absolutely call back into javascript to instantiate and link a new executable module, like https://github.com/remko/waforth does.
Yes, I understand that you can do anything with imports. But that's not part of the Wasm spec. That's a capability the host has decided to give the module. Of course the person with the most privilege can always open holes up, but that capability is not there by default.
