It's unfortunate that he uploaded this without notable commit history, it would be interesting to see how long it takes a programmer of his caliber to bring up a project like this.
That said, judging by the license file this was based on QuickJS anyway, making it a moot comparison.
If he's anything like me (doubtful but roll with it), the commit history when prototyping is probably something like "commit", "commit", "fixed a bug", etc.
He is extremely productive in its specialty: the intersection of programming language and system programming. I don't think that makes him superhuman.
It's more a model of what a really talented person who applies themselves building things they enjoy building can do.
I prefer thinking of it this way: if Bellard can make a small JS engine from scratch by himself, what's really stoping you from knocking down this library you are thinking about.
> He is extremely productive in its specialty: the intersection of programming language and system programming.
Why do you say that specifically is his specialty? He also started QEMU and ffmpeg which are foundational pieces of software for several industries, and his day job is as founder of a company that makes software defined radio test equipment for cellular networks. There isn't one thing I could point at as a specialty.
All of this seems to fit the bill pretty closely to me.
Ffmpeg uses a ton of arcane C and assembly knowledge to make multimedia system manageable and efficient. QEMU uses dynamic binary translation for hardware emulation and virtualization. Amarisoft speciality is basically using software to do things which are usually done by hardware.
The intersection of programming language and system programming seems to me like a pretty fair description of what Fabrice Bellard is extremely good at.
Being on the receiving end of valid, technical criticism in response to making misleading claims about GrapheneOS for falsely marketing products is their own choice. It's certainly a lot nicer than being on the GrapheneOS team heavily targeted by libel, bullying and harassment from those groups. Here's a recent example of the founder of /e/ and Murena linking to libelous harassment content on a conspiracy site, which links to a Kiwi Farms style character assassination video from someone friends with neo-nazis:
Check out the site for yourself. The linked video is plainly filled with extraordinarily dishonest claims that are widely disproven. Copperhead is losing the legal battle very badly and should end up paying our years of legal expenses soon. Other groups attacking us can look forward to similar losses in court when our attention moves to them. Years of libel, bullying and harassment has consequences.
The requirements are monstrous: 300GB storage, 32GB RAM. My everyday working laptop has a 240GB SSD. I've build the kernel, Firefox, and the heaviest packages which I use from sources with a fraction of those resources.
I can't even fathom what the build system is doing in order to require this amount of storage.
> I can't even fathom what the build system is doing in order to require this amount of storage.
A large number of 17 year old repositories, prebuilt toolchains, and the fact that you otherwise have every little bit of source code, intermediary results, and output to create a full operating system all in the same place.
As for the memory, the very first step (that basically already is the benchmark for the most memory usage) is loading the entire build tree and generating build steps. Yes, that takes 32GB of RAM, if not 64GB nowadays.
No, GrapheneOS is partnered with a major Android OEM and has security partner access through them. Our security preview releases are in full compliance with the terms set by Google. It's permitted to ship the patches early with delayed source releases for the patches on the dates the embargoes end. The current patches are from the November 2025, December 2025 and January 2026 bulletins. We've shipped the full set of currently available patches for those 3 months.
I don't know the exact terminology, but they described what they currently have as security partner access or at least advanced access to security patches. To my knowledge they are still working on full partner access that would grant them timely access to the AOSP source code.
The cask has not been majorly updated in almost 10 years years and is used to connect to a mobile app that hasn't been on the Play Store for almost 5 years, while easily underneath the minimum threshold of downloads for being removed. What's wrong with asking to expedite the removal process, considering the process is detailed in the guidelines?
> What's wrong with asking to expedite the removal process, considering the process is detailed in the guidelines?
Asking is one thing, the other thing is not accepting the decision of a maintainer on a topic that is at the maintainers discretion and instead taking it to social media [1] [2] for it to be brigaded.
Addendum: It additionally appears that this was filed before the browser was even launched, if the Wayback Machine and their social media posts are anything to go by.
Just so that nobody ends up confused: This is the same topic as posted here [1] a week ago, but presented in a blog post series format instead of as a slide deck.
> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables through fully intentional operations (i.e. operations that would be available to any program with Administrator privileges on Windows, or the root user on Linux).
As far as I know virtually all of the EFI vars will be stored on battery-backed NVRAM, so the usual solution is to just clear that, by removing the CMOS battery. I am pretty sure the only solution are things you definitely can not read or write from the host OS (e.g. BIOS passwords.) Does require partially disassembling the laptop though, and I know there's at least a couple random models of laptop that actually stop working if you clear the NVRAM (lol)
That said, judging by the license file this was based on QuickJS anyway, making it a moot comparison.
reply