Every system and package manager will be affected if it cannot download source code to build a package.
NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.
I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.
Thanks Tim… my memory is fuzzy - that was a lot of phones ago.
… and thank you for your continued effort! I have very big love for CyanogenMod/LineageOS, and that’s coming from a heavy pre-XDA user (I’ve had them all - PalmOS, Zaraus, XDA o2, Maemo, FirefoxOS, Ubuntu phone user).
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.
NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.
I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.
reply