> I don't think that's the best use of everyone's time or energy.

Seems like there's a simple solution to this dilemma. Assuming build time is the single determining factor:

If the value of two hours' build time overnight is less than the value of a privacy-enabled build of Chrome, then build Ungoogled Chromium overnight.

Else, get Firefox.

Sure, that's a solution if you think that running their binary is unacceptable. But that's begging the question.

Most people running macOS (as vemv at least is) run a lot of random binaries from various types of strangers – mostly proprietary applications, although there's also things like Homebrew cached binaries, 'curl | sh' installers, etc. Now, in this case downloading a binary isn't necessary, since there's the option of building it yourself. That's great, and it's definitely (somewhat) safer to build it yourself... but that doesn't make the binary less trustworthy than if that weren't an option. If building sounds like too much effort, you shouldn't automatically give up on using the program, but just fall back to your personal baseline policy for running binaries. And for a lot of people, for better or worse, I think that policy is fairly trusting.

Aren't you forgetting the fact that binaries aren't provided by the project itself? They come from contributors (in the project's words: 'anyone').

That's wildly different from the typical CI-built binary.

> Various efforts to include chromium or derivatives in Fdroid have failed.

Fixed[1] in rattlesnakeos-stack[2]

[1] https://www.reddit.com/r/RattlesnakeOS/comments/953dfj/v0025...

[2] "A cross platform tool that provisions all of the AWS infrastructure required to build your own privacy focused Android OS on a continuous basis with OTA updates." https://github.com/dan-v/rattlesnakeos-stack

No, that doesn't fix it. It has always been possible to build chromium, just not in a way that meets fdroid's requirements (i.e., build with a foss stack on their debian vm).

This is the most current fdroid issue from what I can tell: https://gitlab.com/fdroid/rfp/issues/378

That's sad Chromium cannot being built without binary Google blobs for now, but that would be much better to have Chromium (ungoogled) in f-droid - with a 'anti-feature' sign - than to not have it at all.

It's already there on the bromite repository. If you go to bromite's page, they have an f-droid repo which has both bromite and vanialla chromium. It will not get into fdroid proper until it's fully compliant (given they also get the build resources, which is also challenging)

I wonder whether anyone tried to build it with open-source versions of the ninja and other tools, not blobs?

Heh, I wonder how much that costs. You certainly don't want to be building the whole Android tree on the free tier.

Edit: that's really well done - https://github.com/dan-v/rattlesnakeos-stack#how-much-does-t...

I actually recently added a feature to search for the cheapest spot instance price across a number of different regions. Right now for example the cheapest price for the instance type used c5.4xlarge is ~$0.15/hour in us-east-2. This equates to a full AOSP build with Chromium build included (~5.25 hours) costing $0.80 and without Chromium (~1.75 hours) costing $0.30

How do you handle spot instances being shut down mid-build? Can you recover any built artifacts before the system goes down? IIRC you get a 2 minute warning.

Right now if a spot instance terminates mid-build it doesn't attempt to save any progress. I do have an open item to at least alert users that this has happened though (https://github.com/dan-v/rattlesnakeos-stack/issues/41). Although if Chromium is built it will checkpoint that by saving the built artifact to S3 and would then skip the Chromium build next time. I've found it's much cheaper to do full builds on AWS each time rather than trying to store the source tree for AOSP and Chromium as they are just so large.

That's amazing the Chromium is almost 3 times longer to build than AOSP.

Yes, that's well done. But it would be nice to port RattlesnakeOS build system from AWS to e.g. Nextcloud - because you pay for your Nextcloud VPS anyway, most of the time it's doing nothing, and most of the time you don't really care would it build in 2 hours or 2 days.

I don't know enough Go - but it'd be awesome to port it to packet.net in particular for the 24 core Epyc boxes.

Most people's VPS won't have enough RAM to run the Android builld process.

If you were looking to just do something similar but running on another platform, knowledge of Go isn't required. The core build process is a shell script, which just has some variables injected through Go templates: https://raw.githubusercontent.com/dan-v/rattlesnakeos-stack/...

I'd definitely like to talk to you further about this - it still looks like there's a lot of hardcoded AWS stuff in there, and your terraform code assumes AWS, but it's super cool - thanks.

For sure. I'd love to have this script be able to run standalone as a local build process that would be portable across platforms and only run the AWS specific bits if you passed a flag for example. Anyways, happy to chat - you can shoot me an email [email protected]

If you don't really care would the build take 2 hours or 2 days, using swap on SSD might solve the RAM problem.

I think you underestimate just how slow that'd be. My recollection is that the Android build tree is 30+GB and the build is extremely IO intensive.

There are cheap VPS with even NVMe storage nowadays. And to port it on VPS is not much different from porting it to 'any Linux box or VM' which might be local server or even a laptop (when you could just run it with nice settings in background).