How about any x86 OS in the browser, with JIT translation to WASM and including network access?

https://copy.sh/v86/

To be fair, I believe Bellard's JS x86 emulator predates this (and WASM, and to my knowledge also possibly emscripten) by several years :) It has a very interesting history itself:

> I wrote the initial version of JSLinux[...] in Javascript

> [...] I modified it to use the asm.js Javascript subset [...]

> [...] so I converted the JSLinux asm.js code to C and converted it back to Javascript with emscripten!

[1] https://bellard.org/jslinux/tech.html

so I've played with this a few times and it's awesome. but how do I enable network access? whenever I try and ping 8.8.8.8 I get network unreachable.

The VPN websocket service (wss://relay.widgetry.org/) is probably overloaded. I sometimes get this error but not all the time.

Both versions seem to use the same service.

Related links:

https://github.com/copy/v86/blob/master/docs/networking.md

Network section in https://bellard.org/jslinux/faq.html

It's worth mentioning that the initial version of this didn't use WebAssembly. Bellard literally implemented i386/PC emulation in pure JavaScript (ES5) back in 2011.

It did require W3C Typed Arrays to perform decently, but I remember with polyfills it even ran in the contemporary version of Internet Explorer (9 if memory serves correctly?)

Is this letting anyone use the owners internet?

Yes, but [1]:

"Can I access to the network from the virtual machine ? Yes it is possible. It uses the websocket VPN offered by Benjamin Burns (see his blog[2]). The bandwidth is capped to 40 kB/s and at most two connections are allowed per public IP address. Please don't abuse the service. "

[1] https://bellard.org/jslinux/faq.html [2] http://www.benjamincburns.com/2013/11/10/jor1k-ethmac-suppor...

Too bad there isn't a way to use the network of the machine running the browser... Maybe one could write some code that intercepts any outgoing network traffic from the VM, and instead of sending it via websockets to that 3rd party VPN, instead just finds packets that are part of a HTTP call and rewrites them to XMLHttpRequests. Would obviously only work for HTTP traffic, but that's probably a big majority. Might not work for HTTPS though. Oh, and DNS would have to respond with some sort of fantasy IP's that the Javascript host would have to keep track of.

HTTP support seems possible, but it’s unlikely to be useful by itself. HTTPS is probably the majority and that’s a lot trickier (you’d have to MITM TLS in JS).

DNS is comparable to HTTP probably, since you could just use DNS-over-HTTPS and intercept DNS packets.

Wait until the emulator can run a modern kernel with eBPF support. Then use eBPF to intercept the SSL calls pre encryption, push via a map the requests to userspace, and then translate them to HTTP as you wish. Simple! ;P

I'm sure it can run modern kernels just fine, but how would eBPF help with TLS (which is almost exclusively implemented in userspace)?

You’d probably be looking for something like https://en.wikipedia.org/wiki/Slirp.

Unrelated but still a coincidence, there is also a post on the front page about Alpine.js, and I ended up getting the 2 mixed up for a sec.

Not really unrelated, this url was referenced in one of the comments in the alpine.js thread.

Has it suddenly become unimpressive? Things get reposted all the time in HN. It’s part of the site’s DNA.

Presumably because of this: https://news.ycombinator.com/item?id=34365515#34365977

This guy again?! Fabrice Bellard gives me serious imposter syndrome. He's built QEMU, ffmpeg, and the Tiny C Compiler that can run off of a floppy. Ugh. If I build one thing in my career that's as cool as any one of those, I'll be delighted.

Check out his latest creation, nncp, a lossless, neural network based file compression algorithm.

https://bellard.org/nncp/

And of course, he wrote it in plain ANSI C for the efficiency.

Don't worry there are just a handful of people like him world wide. But the software industry needs myrads, no, millions of people.

Given some arbitrary metric it's generally not the best to compare yourself with the best of the best (on that metric), just doing the best you can do and striving to learn and improve (and live and be there for your family etc.) is more then good enough.

I feel similarly. At the same time, comparing oneself to one of the, what, top ten (?) hackers alive might not be a recipe for happiness.

Fabrice seems to know an insane amount about how computers work, knows all the CS stuff, has a tight grasp of all kinds of algorithms, great math intuition, and a lot of time on his hands to write OSS code. I bet he spent a lot of time learning the basics.

The „a lot of time“ part is key. If you have young kids…

Also note that, this site is like any other social media sites. The top posts are naturally going to be talented people who seem to effortlessly accomplish things we can only dream about.

I would not at all feel bad about not measuring up anywhere close to Fabrice Bellard. Be happy with what you've done.

If necessary take time away from social media, including HN. Personally I've stopped visiting most social media and simultaneously feel more satisfied, less harried, and also have had more time to accomplish some small personal projects.

To add on to that, JSLinux was written in 2011, in pure JavaScript (i.e. before both Emscripten (2014?) and asm.js (2013)).

Emscripten has been under active development since at least 2010. Here's the commit frequency history

https://github.com/emscripten-core/emscripten/graphs/contrib...

and an article from 2012 about using it

https://www.webpronews.com/easily-port-c-to-html5javascript-...

Yep, as the wises usually say, compare yourself to your previous self, where you were a year ago, and where you are now.

dude, you're not an impostor just because you're not Beethoven. the world needs punks too (and they weren't impostors either)

that's why we give him god status, so we can stop comparing :p

I used to think that. But loving someone and being loved seems better.

This man is too powerful

.

I have heard that Alpine is really light on resources. Would it be practical for Rust, Node, Python projects in general? Or am I better off sticking with Ubuntu? I know that projects often have extra dependencies and I believe Ubuntu is still very good as far as those being easily available with the package manager. Or maybe about the same thing goes for Debian.

It's great for packaging a project in containers. The package management is actually pretty good specifically for anything server/service related, you just have to be a bit more hands on since it doesn't come with all of the bells and whistle dependencies.

The only issue I've really had is libc vs musl for some of my dependencies.

Its _tiny_ compared to ubuntu.

I haven't looked at daily driving it because it doesn't feel like it's really meant for desktop use (although I'm sure it'll work), Something like arch makes more sense if you want something more lightweight while also having decent documentation and support for desktop use, and better packaging for things like chrome, vscode, etc. Especially because of musl I suspect you'll run into a lot of issues in general.

EDIT: Also most images like python have alpine variants now which is really nice.

> Also most images like python have alpine variants now which is really nice.

You probably don’t want to use Alpine for Python containers. Many packages don’t provide wheels for Alpine (the Python version of prebuilt binaries), so you’ll have to build them from source, countering the space savings.

You’re often better just using something like Debian-slim or something.

I would use whatever Alpine-y containers the official Python docker hub has, and switch to a Debian-based one if there are bugs. Building extra wheels isn't necessarily an issue, you can squash layers with a multistage build from scratch.

>I haven't looked at daily driving it because it doesn't feel like it's really meant for desktop use (although I'm sure it'll work),

Many people use it on desktops. Also many people use postmarketOS (phone-specific packages on top of Alpine repos) on phones.

It’s probably a bad idea to use this for your desktop, since Alpine isn’t particularly performance-focused.

I hit some nasty segfaults in musl, with gRPC above it in the stack trace while doing some rather heavy YouTube API operations-- opted to switch to a glibc distribution rather than track down that mess. The segfaults were gone after that.

I was doing some very similar things (gRPC with Alpine containers) and also had the segfault things. `gcompat` solved all of them.

ooh good to know in a pinch

The big issue with alpine is that it uses musl libc instead of glibc. Python and other languages work just fine on it but the problem is when you install packages from pip, conda or other package managers, if those packages have binaries they're likely not compatible with musl libc and won't work. You have to find alpine-specific packages which can be difficult or annoying.

For code that compiles into a binary like Rust, distroless is another option for a minimal image that doesn't run into the compiling issues of Alpine. (Python and Node are supported but lose benefits rapidly depending on any added dependencies)

https://github.com/GoogleContainerTools/distroless

Just to clarify for anyone who isn't aware, the "compiling issues", at least historically, have been that Alpine uses musl, and PyPI's manylinux wheels are built against old glibc versions. So stuff like numpy that would trivially and quickly install from whl on glibc distros (like a bare-bones Ubuntu image) trigger compilations and the installation of build-only dependencies/toolchains on Alpine.

That said, it looks like as of late-2021, at least some projects are offering musllinux wheels as well, per the discussion here: https://github.com/pypa/manylinux/issues/37 (not numpy yet, though: https://pypi.org/project/numpy/#files)

Here's a longer version of the above, originally published in 2020, but with an update regarding PEP 656: https://pythonspeed.com/articles/alpine-docker-python/

Ugh dynamic linking claims a few more victims

I use it for Node all the time. There are published docker images with Alpine as the base and just Node and any required packages installed. I've had to manually install a handful of libraries to support image processing, or anything else that NPM might not install itself.

Same here. It's a great base image for node projects.

the Node 19 release alpine image is ~175mb, the same release on debian (bullseye) is roughly 1gb (998mb). Still ~80MB smaller than the bullseye-slim release (247mb).

---

That said - if the ask was for using it as a daily driver on a machine (primary OS), I'd probably still pick a more fully featured distro (ex: my daily driver is Arch, not Alpine). The available packages and tooling in Alpine aren't really geared towards daily use as an OS, although some folks definitely do it.

Is it just me, or does this still seem about an order of magnitude larger than it reasonably needs to be?

Given the size of Alpine itself (less than 10 MB, last time I checked), is it node that pulls in so much extra stuff, or something else?

Node is about 60mb on it's own.

Taking a peak at the official dockerfile for alpine node (https://github.com/nodejs/docker-node/blob/28ad5e0e5d0e80df4...), they're also pulling in the following packages

        && apk add --no-cache --virtual .build-deps-full \
        binutils-gold \
        g++ \
        gcc \
        gnupg \
        libgcc \
        linux-headers \
        make \
        python3

My guess is the most weight is probably coming from linux-headers (~10mb), python3 (~50mb), and nodejs (~60mb). Plus 1 to 10 mb for each of the other pacakges, and you end up right there around 175mb.

Why does a minimal nodejs 19 distro need python3 ?

Yeah, I looked again and it looks like they're actually only pulling those packages in when they need to build node for the current ARCH. (that's what I get for just scanning to the first call to apk add)

They also appear to be cleaning them up, so I'm not actually sure where all that extra weight is coming from.

Node itself is fairly trimmed down in the packages for alpine (40MB installed), but they're not using that package, they're pulling in their own version from their download sources - so it's possible they're including a lot of extra junk there. They also add yarn which is another 10mb.

But in general - I agree, there's about 100mb of weight I can't actually explain in that image from a very quick look.

My understanding is that it’s because of node-gyp, used to build native addon modules for Node.js.

I'd run it mostly for cloud projects that need to be lightweight. I just ran into a quite unpleasant issue with Alpine and Go where Go compiled as a shared library with musl cannot work in Alpine. In fact it segfaults and doesn't give any indication as to why it segfaults (the stack is even corrupted if you try to use gdb). You can read about it here: https://github.com/golang/go/issues/13492

Of course one could argue that's mostly Go's fault...

It doesn't use GNU at all which can break compatibility with a lot of software but is no big deal if the packages are available.

Aside from packaging, do also look into any potential issues with musl libc. It's fixed now, but the malloc in musl made Python noticably slower for some real world tasks roughly three years ago and earlier. This fixed it: https://git.musl-libc.org/cgit/musl/commit/?id=ea6d7847ac128...

Alpine is strong in package availability, but needs some manual work for a usable desktop. Also I did some browser benchmarks, uses less RAM but it's not noticeably faster and some situations slower

You would be better trying Xubuntu, MX linux, NixOS...

Void Linux is also worth trying. It's lightweight, fast boot times with runit, stable rolling release, and a unique packaging system xbps. Comes with either glibc or musl.

You can also run Python in the browser https://www.anaconda.com/blog/pyscript-python-in-the-browser

I've only used Alpine when creating containers with docker and has worked for me. Not sure about it being a daily driver though, prob best to stick with Ubuntu.

benchmark.py is 100x slower in browser than native on my 16 inch macbook.