Hacker News Reader

Comment by vemv | Hacker News Reader

Coincidentally I had found out this one today and compiled it myself after a frustrating experience with `brew install chromium` (videos wouldn't play; inputs would blink).

I guess this has more flags set up by default, and it makes it easier to target a stable commit to compile against.

Also as a word of caution, don't use ungoogled-chromium binaries - they never are fully official/confirmed/reproducible. Running opaque blobs from strangers defeats the purpose of leaving Chrome for increasing privacy.

Just bite the bullet and run the 2h compilation process yourself.

View on HN

>Just bite the bullet and run the 2h compilation process yourself.

I don't think that's the best use of everyone's time or energy. Not to mention, it may be more error prone, or even insecure depending on what your base system is like. And you'll have to track updates. It seems like chromium is problematic to build in general. Debian hasn't marked it as reproducible. It is also not clear if it is possible to build it for Android using a Foss stack. Various efforts to include chromium or derivatives in Fdroid have failed.

> 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

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

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 dan@vittegleo.com

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

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.

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?

> Also as a word of caution, don't use ungoogled-chromium binaries

Unless you’re reading every line of code yourself before compiling it, I’d say you’re no safer going you’re route than downloading the binaries offered from the same source.

Generally as a software developer I can assess which projects' source to trust, else I wouldn't be running thousands of transitive dependencies in my machine.

Binaries which are unofficial to even ungoogled-chromium itself surpass my threshold of trust.

But yes, one could take a further step and extract the interesting bits from this project and apply them to the official Chromium trunk.

How do you assess the trustworthiness of thousands of transitive dependencies with a far greater number of code contributors in a way that scales? This is a serious question, and it would be great if you shared the solution you found. Thanks.

I should admit that my procedures are only marginally better than an average developer's.

Sadly I have no arbitrarily deep audit in place. I just try to pick solid projects, and assume / quickly check that their dependencies don't suck.

Also I'm particularly cautious with npm (as opposed to rubygems or clojars).

I should be looking into either (or both of):

- setting up a multi-user macOS ('me' + 'admin' + 'dev'. I normally operate under 'me'. sudo is only ever executed under 'admin'. Developer tooling is installed for 'dev', an account which cannot access the rest of the filesystem)

- using Docker and/or a VM for all dev activity, as a sandbox.

In spirit I'm with you but somebodies bound to do it and that alone makes it safer to compile from publicly provided source.

I did it one time. It was really long to download all the build tools and source code then even more to compile the thing. A lot of free space was required (there was few remaining on my SSD). After that the resulting browser was approximately two times slower (in my perception) than Chrome, so I ditched the thing after ten minutes. So it’s somewhat understandable that not everyone is willing to go thru this, especially for the disappointing result.

Wasn't the compiled-from-source chromium also downloading binary blobs without telling the user? There was an advisory about chromium doing it awhile ago.

Chromium suddenly starts downloading a binary blob https://lwn.net/Articles/648392/

Is there a flag for compiling out integrated login?

ungoogled-chromium has deterministic builds

EDIT: never mind, I was wrong

Reply on news.ycombinator.com