Blink 1.0 | Hacker News Reader

Blink 1.0

github.com

336 pointstodsacerdoti71 comments

For those not familiar with the project/name: Blink is a brand-new unprivileged userspace virtual machine that can emulate x86-64-linux binaries on any POSIX platform. It's basically a 220kb dependency-free static binary that implements about 600 x86 instructions and 180 Linux system calls, which makes Blink pretty good at running simple command line programs.

What does that mean, though? I can run x64 Linux binaries on BSD? How about on ARM processors? On an M2?

Yes to all of that.

ARCHITECTURES = x86_64 x86_64-gcc49 i486 aarch64 arm mips s390x mipsel mips64 mips64el powerpc powerpc64le (https://github.com/jart/blink/blob/master/Makefile#L6)

Would love a second pair of eyes on the powerpc64le JIT, since it partially works but hangs on some tests. https://github.com/jart/blink/issues/17

you can run some x86 binaries on any arch/os Yes, bsd/x86, mac/arm and all other posix compatible OS/arch.

As the other commenters have said - yes. From the last paragraph of the link:

> One of the projects currently using Blink is Cosmopolitan Libc. Blink is more embeddable than qemu-x86_64 since Blink is 22x tinier in terms of binary footprint. So what Cosmo does is it vendors prebuilt Blink binaries inside each of the x86-64 executables it compiles. That way, whenever someone tries to run these programs on a different architecture like Arm, the Actually Portable Executable shell script wrapper will simple extract the appropriate blink binary and re-run itself.

Cosmopolitan LibC is truly “write once run anywhere” except instead of using JVM virtualization, it used x86_64 as the portable VM. Your users don’t need to install a VM or runtime, and you can ship a single exe that runs on all popular architectures and operating systems, including bare metal.

See https://justine.lol/cosmopolitan/

Huh, that's pretty damn cool, thanks!

It's pretty sick, but is anyone actually doing it? It seems pretty scary to use to me.

It's an unprivileged VM, so unless you're the type to do binary analysis before running things this is just as safe as any other binary.

What about direct syscall runtimes like Go's?

According to google, there are somewhere between 900 to 4000 x86 instructions (not sure which value is correct or what variants means in this context), and 329 Linux calls. Meaning, there is a lot missing. Which leaves the question: will it communicate in an obvious way if it encounters an unknown instruction or call? Or can I check at least for potential problems before executing a program?

The default build (make MODE=) has logging enabled (so do the release binaries). If any system calls are missing, then Blink will return ENOSYS to the program and then create a "blink.log" file in the current directory reporting that, e.g.

    master jart@nightmare:~/cosmo$ blink ruby --yjit -e 'printf("%d\n",2+2)'
    <main>: warning: timer_create failed: Function not implemented, signals racy
    4
    master jart@nightmare:~/cosmo$ cat blink.log
    I2023-06-05T04:22:15.525179:blink/syscall.c:1020:29575 unsupported prctl op 0x29
    I2023-06-05T04:22:15.556803:blink/syscall.c:5720:29575 missing syscall 0x122
    I2023-06-05T04:22:15.556866:blink/syscall.c:5720:29575 missing syscall 0x122
    I2023-06-05T04:22:15.556886:blink/syscall.c:5720:29575 missing syscall 0x0de

You can also use `blink -es program...` to log system calls to stderr, similar to strace, when you need to troubleshoot further. Once you do that, please file a feature request.

Is there a list of unsupported syscalls and instructions, and how to add support for them for people interested in contributing?

Here are the missing system calls that people filed issues requesting: https://github.com/jart/blink/issues?q=is%3Aissue+is%3Aopen+... The place where they go is https://github.com/jart/blink/blob/master/blink/syscall.c Looking forward to any changes you send us!

A lot of those are post-SSE2 SIMD instructions. It's not something I would worry about.

Do applications not typically make use of SSE3+?

They do!

The most important post-SSE2 extensions are SSSE3 (pshufb) and SSE4.1 (rounding, min/max, blending, etc...). Pure SSE2 is a nightmare to use as it's a totally unbalanced SIMD ISA (a lot of missing stuff here are there requires a lot of workarounds and sometimes it's just better to go scalar). In addition, just [V]PSHUFB alone can do wonders and has a lot of application - I would say that almost all interesting problems can take the advantage of PSHUFB.

It's above 4400 instructions actually if you count different encoding of SIMD instructions (like SSE2, VEX, and EVEX variations) and consider instructions using 128-bit, 256-bit, and 512-bit SIMD as separate instructions.

Instructions can be comfortably explored here:

https://asmjit.com/asmgrid/

Why was it named after the chrome rendering engine?

From your explanation, I knew it must have been Justine before I saw the link in the post. Her work is nothing short of amazing.

Not to be confused with Blink, the Chrome / chromium browser engine that was forked from Webkit: https://en.wikipedia.org/wiki/Blink_(browser_engine)

That's a really unfortunate naming collision. I immediately thought this was browser tech.

I thought it was the first version of the browser engine too --- which was released in 2013. Looking at the history, this one only showed up in late 2022, so the browser engine came first.

Blink, the browser engine, was named after <blink> and its speed. It's a really clever, relevant, meaningful name.

This project seems to want to be "Blinkenlights". That's a cool name. Or "Blinken" or something mainframe-related.

When I originally announced this project I called it "das blinkenlights" and was quickly mobbed by a group of Germans on Reddit for misappropriating their culture (even though I was quoting The Jargon File). Normally I try to focus on cosmo corpo speak that couldn't possibly rub anyone the wrong way, which is why I like "blink" because blinking is something man has been doing for centuries, so as a word I feel that it really unites humanity rather than dividing it.

Major props on your work here! It's incredible.

Who am I to bikeshed on your project and its name?

I would have doubled down with "däs ßlinkënlights"...

I thought it was about microcontrollers, because usually the Hello World for microcontrollers is blink - turn a LED on and off repeatedly.

I guess I thought wrong.

Or https://github.com/blinksh/blink which I thought this was at first.

Same

Or https://en.wikipedia.org/wiki/Project_Blinkenlights which i thought about first.

"Blinkenlights" always takes me back to the BeBox - which actually had blinkenligts for CPU usage and disk activity on the front "columns" of the bezel.

Or https://icanblink.com/ Blink the softphone

Funny, the commenters saying "I thought it was...". I saw "jart" in the github URL and immediately thought it was a tiny open source commandline executable packing a host of amazing/useful functions for low-level cross-platform dev.

Justine Tunney is a true genius. Similar to Fabrice Bellard, a truly unique mind. Well done. Amazing!

Tunney is amazing relative to the average developer, but Bellard is another order of magnitude or more beyond this.

Also younger. We may be looking at the baby steps of a new bellardesque figure here.

Is there any need to trying to figure out who is actually the better developer? There is no competition here, and it never makes for good discussion.

Of course it’s a competition. You said he is 10x a regular engineer so someone could be 10x him? It’s not insulting to know there are betters. After all you said he is better than us regular develops.

I tend not to opine, as a lowly mortal, on which is the better God in the Olympus. Nor do they care to know, as this is only an argument for jealous peasants. I just expressed my admiration, comparing their output to mine.

I reckon we all got better things to do than do a dick measuring contest on their behalf.

Bellard is not 10x. More like 100x or even 1000x.

It's not for Us to judge the Gods.

Justine or Fabrice are the true 10x engineers, their output is world class and they are much rarer than any hiring article about these gurus want us to believe.

With Justine's work, I feel I would need to be more than a 1x engineer myself just to find the time to play with all of her creations.

as an ANSI compliant 13.37x engineer jart && bellard are much more like 100x engineers than us crappy 10xers.

oh, you are not ISO certified?

one can only dream of such acclaim... :')

I fully agree, and I note that they both use C as their primary language.

Can’t wait it hits version 182

Wanted to write the same :D

While it is a very interesting project, why would I prefer this over something like Go/Zig with a single toolchain for multiple OS/arches or Java with its byte code as a cross platform deployable artifact?

I should make it absolutely clear that this is in no way taking a dig at the author’s work — I’d simply like to understand the practical use for something like this.

I was thinking it'd be cool to use it as a way to make portable multi-arch script/devops binary. Or perhaps universal multi-arch tools for things like jq.

Understatement of the week: This is very cool.

It seems that it does not support Windows natively, instead it has to be run inside Cygwin for now?

Correct-- Blink needs a (reasonably) POSIX-compliant system to compile and run, so it should work on Linux or BSD or macOS, but needs Cygwin on Windows.

Not directly (or at least not yet), although Cosmopolitan already supports Windows natively; blink extends this support for Cosmopolitan and other x86-64-linux binaries to more platforms.

In other words, you can build a cosmopolitan executable (that runs on Linux, Windows, and other platforms) and extend it with blink, allowing the same binary to also run on those platforms that blink emulates.

For non-comsmopolitan binaries it needs a posix-compliant host (hence cigwin, but not Windows in general).

> It seems that it does not support Windows natively,

It'll likely run on top of wsl

Blink was a linker programmmed by Bjorn Freeman-Benson. It was distributed by Zortech for years.

Justine’s work is truly remarkable.

Is Blink a replacement for VMMs like Firecracker and Cloud Hypervisor?

I don't think so. By all accounts this seems to be doing true emulation like QEMU TCG does. IIRC firecracker is more of a hypervisor?

No, it's a Type 2 emulator, so more like Qemu or VirtualBox.

I'm not familiar with this way to classify emulators. What's this mean / refer to?

It seems to be more about hypervisors.

"KVM is a type 1 hypervisor, which essentially means it is able to run on bare metal. QEMU is a type 2 hypervisor, which means that it runs on top of the operating system." -- https://linuxconfig.org/qemu-vs-kvm-hypervisor-whats-the-dif...

AFAIK Actually Portable Executables produced by Cosmopolitan run on bare metal too so that would make Blink a type 1 hypervisor.

This is amazing. I've been wanting to create something very much like this for ages, but never got around to it (because life).

Is there a contributors guide for the project?

> that can emulate x86-64-linux binaries on any POSIX platform.

This must be leveraging that cosmopolitan libc awesomeness/insanity also by jart, then?

Since it is the same developer, quite possible...

Wow, that's wow

What's the use case? These days, POSIX is fairly synonymous with Linux. Is it for the BSDs? Some other use case?

181 to go

Reply on news.ycombinator.com