tombl (u/tombl) - Readit News

tombl commented on Running TypeScript Natively in Node.js nodejs.org/en/learn/types... · Posted by u/jauco

I don't mean this rhetorically, but what are the benefits of using node over something like deno now? It has been so long since I lived in the node ecosystem. I imagine it has gotten quite a bit better. Is the main benefit just ecosystem/compatibility stuff? Deno sometimes has some odd compatibility issues, but not often. The low-overhead, sane defaults, just-build kind of nature of it has become very appealing to me. Being able to build CLIs in portable binaries using a language my coworkers understand is really nice (despite that they're like 60mb, haha). I prefer Go personally, but ultimately prefer being able to collaborate.

tombl · a month ago

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.

tombl commented on JSLinux bellard.org/jslinux/... · Posted by u/TechTechTech

jerf · 4 months ago

"I'm implementing exec() support now"

Bah. Details, details dismissive hand wave.

It's just minimalism, right? I hear it's all the rage.

tombl · 4 months ago

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.

tombl commented on JSLinux bellard.org/jslinux/... · Posted by u/TechTechTech

pantalaimon · 4 months ago

This produces

        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 ]---

on any command

tombl · 4 months ago

yep, that's to be expected, this is a very wip demo. I'm implementing exec() support now, so currently only shell builtins work.

tombl commented on JSLinux bellard.org/jslinux/... · Posted by u/TechTechTech

fsiefken · 4 months ago

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.

tombl · 4 months ago

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.

tombl commented on JSLinux bellard.org/jslinux/... · Posted by u/TechTechTech

tombl · 4 months ago

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

tombl commented on Show HN: Nue – Apps lighter than a React button nuejs.org/blog/large-scal... · Posted by u/tipiirai

tipiirai · 5 months ago

Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!

tombl · 5 months ago

hmm, it looks like you've got a bug in the demo app. if you type too quickly into the search bar, the entire app slows to a halt.

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.

tombl commented on Not dropping RISC-V support after all, maybe chimera-linux.org/news/20... · Posted by u/todsacerdoti

yjftsjthsd-h · 5 months ago

There's also Alpine Linux, using openrc, musl, and busybox.

tombl · 5 months ago

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.

tombl commented on Not dropping RISC-V support after all, maybe chimera-linux.org/news/20... · Posted by u/todsacerdoti

jbaber · 5 months ago

I am very tempted to install solely so I could say "Ah, ah, ah: it's not GNU/Linux, it's Linux." The distro is a Linux kernel with BSD userland.

tombl · 5 months ago

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.

tombl commented on Greg K-H: "Writing new code in Rust is a win for all of us" lore.kernel.org/rust-for-... · Posted by u/mustache_kimono

AlotOfReading · 6 months ago

Yes, cargo is involved. R4L currently works by invoking kbuild to determine the CFLAGS, then passes them to bindgen to generate the rust kernel bindings. It then invokes cargo under the hood, which uses the bindings and the crate to generate a static lib that the rest of the kernel build system can deal with.

tombl · 6 months ago

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.

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

tombl commented on We replaced our React front end with Go and WebAssembly dagger.io/blog/replaced-r... · Posted by u/miranda_carter

potamic · 7 months ago

What about Go causes large binaries?

tombl · 7 months ago

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.

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