[HN Gopher] Alpine Linux in the Browser (2020)
___________________________________________________________________
Alpine Linux in the Browser (2020)
Author : kevmo314
Score : 148 points
Date : 2023-01-13 17:41 UTC (5 hours ago)
(HTM) web link (bellard.org)
(TXT) w3m dump (bellard.org)
| lxgr wrote:
| 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
| skrowl wrote:
| This tech appears to have not changed since 2019 -
| https://bellard.org/tinyemu/
|
| Why is it noteworthy / in the new page here?
| tomcam wrote:
| Has it suddenly become unimpressive? Things get reposted all
| the time in HN. It's part of the site's DNA.
| brazzy wrote:
| Presumably because of this:
| https://news.ycombinator.com/item?id=34365515#34365977
| robotnikman wrote:
| 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.
| c0balt wrote:
| Not really unrelated, this url was referenced in one of the
| comments in the alpine.js thread.
| keewee7 wrote:
| 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.
| detrites wrote:
| Is this letting anyone use the owners internet?
| allanrbo wrote:
| 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.
| ratorx wrote:
| 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.
| ahachete wrote:
| 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
| reginaldo wrote:
| 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...
| ashton314 wrote:
| 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.
| [deleted]
| [deleted]
| dathinab wrote:
| 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.
| 0xbadcafebee wrote:
| dude, you're not an impostor just because you're not Beethoven.
| the world needs punks too (and they weren't impostors either)
| lxgr wrote:
| To add on to that, JSLinux was written in 2011, in pure
| JavaScript (i.e. before both Emscripten (2014?) and asm.js
| (2013)).
| williamstein wrote:
| 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-...
| rahen wrote:
| 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.
| manmal wrote:
| 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.
| msie wrote:
| I used to think that. But loving someone and being loved seems
| better.
| ddyevf635372 wrote:
| Yep, as the wises usually say, compare yourself to your
| previous self, where you were a year ago, and where you are
| now.
| agumonkey wrote:
| that's why we give him god status, so we can stop comparing :p
| piyh wrote:
| benchmark.py is 100x slower in browser than native on my 16 inch
| macbook.
| ilaksh wrote:
| 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.
| minimaxir wrote:
| 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
| mikepurvis wrote:
| 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/
| davidhay wrote:
| 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.
| FinalBriefing wrote:
| 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.
| horsawlarway wrote:
| 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.
| lxgr wrote:
| 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?
| horsawlarway wrote:
| 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.
| guilhas wrote:
| 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...
| tyingq wrote:
| 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...
| zitterbewegung wrote:
| You can also run Python in the browser
| https://www.anaconda.com/blog/pyscript-python-in-the-browser
| hardwaregeek wrote:
| 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...
| thewataccount wrote:
| 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.
| KMnO4 wrote:
| > 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.
| throwawaaarrgh wrote:
| 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.
| Arnavion wrote:
| >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.
| rezonant wrote:
| 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.
___________________________________________________________________
(page generated 2023-01-13 23:00 UTC)