Live data from Hacker News

JSLinux Now Supports x86_64

bellard.org

41–50 of 148 posts

Re: JSLinux Now Supports x86_64

#43
post #7
post #2

I've always been fascinated by this, but I have never known what it would be useful for. Does anyone know of any practical use cases?

Most such emulators have Internet access on the IP level. Therefore, this is a very cheap way to test anything on the Internet. apk add nmap nmap your.domain.com However, the speed is heavily throttled. You can even use ssh and login to your own server. It can also be used as a very cheap way to provide a complete build environment on a single website, for example to teach C/C++. Or to learn the shell. You don't have…

You need backend proxies, the browser doesn't allow ignoring CORS by default.

Re: JSLinux Now Supports x86_64

#44
post #2

I've always been fascinated by this, but I have never known what it would be useful for. Does anyone know of any practical use cases?

We are a playful species. People enjoy play. If we didn't have to work for a living but still enjoyed food security that is all most of us would do. But we are also a very exploitative species, some more than others. Companies have made billions of dollars on top of Fabrice Bellard's works, qemu, ffmpeg etc.

These companies don't have any imagination. Their management has no vision. They could not create anything new and wonderful if they tried. People like Fabrice do and we are all richer for it. If your asking about the practical use you are likely in the exploitative mindset which is understandable on HN. The hacker/geek mindset enjoys this for what it is.

Re: JSLinux Now Supports x86_64

#47
post #19

The thing I most want to use this (or some other WASM Linux engine) for is running a coding agent against a virtual operating system directly in my browser. Claude Code / Codex CLI / etc are all great because they know how to drive Bash and other Linux tools. The browser is probably the best sandbox we have. Being able to run an agent loop against a WebAssembly Linux would be a very cool trick. I had a play with v86…

This is not the technical solution you want, but I think it provides the result that you want: https://github.com/devcontainers

tldr; devcontainers let you completely containerize your development environment. You can run them on Linux natively, or you can run them on rented computers (there are some providers, such as GitHub Codespaces) or you can also run them in a VM (which is what you will be stuck with on a Mac anyways - but reportedly performance is still great).

All CLI dev tools (including things like Neovim) work out of the box, but also many/most GUI IDEs support working with devcontainers (in this case, the GUI is usually not containerized, or at least does not live in the same container. Although on Linux you can do that also with Flatpak. And for instance GitHub Codespaces runs a VsCode fully in the browser for you which is another way to sandbox it on both ends).

Re: JSLinux Now Supports x86_64

#48
post #29
post #26

Earlier quoted context omitted.

Simon, this HN post didn't need to be about Gen AI. This thing is really inescapable those days.

Parallel thread: https://news.ycombinator.com/item?id=47311484#47312829 - "I've always been fascinated by this, but I have never known what it would be useful for." I should have replied there instead, my mistake.

[dead]

Re: JSLinux Now Supports x86_64

#49
post #32
post #20

Earlier quoted context omitted.

What's wrong with a well protected VM? Especially compared to something where the security selling point is "no one uses it" (according to your argument; I don't know how secure this actually is)

Nothing, but "there are already working options" does not necessarily mean we shouldn't try new (and sometimes weird) things

Yeah but GP was answering to a comment saying "you don't want to run code in a well protected VM". Which is of course complete non sense to say and GP was right to question it.

Re: JSLinux Now Supports x86_64

#50
post #32
post #20

Earlier quoted context omitted.

What's wrong with a well protected VM? Especially compared to something where the security selling point is "no one uses it" (according to your argument; I don't know how secure this actually is)

Nothing, but "there are already working options" does not necessarily mean we shouldn't try new (and sometimes weird) things

GP says "You don't want to just run that code in ... even a very well protected VM." Why?
Post reply on HN