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.

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.

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`.

seems like you'd want to move the filtering logic off the main thread, or you'd want to reinvent React's "Fiber" suspendable rendering architecture.

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.

https://github.com/search?q=repo%3Atorvalds%2Flinux%20cargo&...

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.

see https://github.com/golang/go/issues/65440

Like you would with Yocto, I just build my systems on a proper host then remotely deploy them.

(random question, totally understand if you're not the right person to ask)

Given part of the patch was software emulation for unsupported CPUs, it's possible that people would've implemented support for it anyway, incentivising Intel to push it more broadly.

They've been silent about the patch since at least January 2023[0], and archived the repo for their kernel fork[1] in April.

It's a real shame because this kind of innovation seems valuable.

[0]: https://www.phoronix.com/news/Linux-SPR-Intel-User-Interrupt...

[1]: https://github.com/intel/uintr-linux-kernel

For those that appreciate this approach of JSX returning concrete DOM elements, Solid works exactly like this, with the addition of a proper reactivity layer.