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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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).
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.
