Follow

*looks at guix compiling ungoogled-chromium*

wait a minute
the google chromium source tarball is... 1.3gb?

why is a single browser's source bigger than like a linooks live cd with a whole desktop and everything

@carcinopithecus firefox appears to be under 500mb, not small either, but less than half

they're both monsters of course

@cwebber yeah i have permanently purged ungoogled-chromium from my workstation, it’s just woeful

@cwebber linux live cd is precompiled; source code is big and full of stuff only humans care about like comments, line breaks, and separate files/directories

@cwebber do a quick grep for binary blobs contained in strings maybe?

@cwebber its to do with Google's slow takeover of web standards but yeah

@cwebber I have a chromium_101.0.4951.64.orig.tar.xz here that's "only" 566MB. Unpacked it's 4.6GB ~

@cwebber Hypercorps win when only they can afford to implement browsers.

@emily @cwebber This is literally true. ChromeOS is embedded in the Chromium source code, including desktop and window manager.

@cwebber @dl @emily wow and here I thought I was joking in the other thread D:

@dl @cwebber I'd just like to interject for a moment. What you're referring to as Chrome, is in fact, Chrome/Chrome, or as I've recently taken to calling it, Chrome plus Chrome. Chrome is not an operating system unto itself, but rather another free component of a fully functioning Chrome system made useful by the Chrome corelibs, browser utilities and vital browser components comprising a full OS as defined by Chrome.

(yes I know it uses linux as a kernel but this is funnier)

@emily @dl @cwebber
I've really been enjoying Kuberneties Foundation/Docker Inc/Apache Foundation/Red Hat/Canonical Ltd/GNU Linux.

as we all call it obviously

@emily @dl @cwebber <FOSS bro voice> akshully it's pronounced chrome slash chrome

TechPost, building chromium 

@dl @emily @cwebber Well, sort of. Components of chromium that are re-used throughout ChromiumOS are de-coupled from the rest of Chrome, iirc. They're taking this to its logical conclusion with LaCrOS which will de-couple Chromium from ChromiumOS.

It's not just chrome stuff, though. It also contains vendored dependencies.

One of Chromium's lowest-level defenses is control flow enforcement, which they implement using CFI (forward-edge control flow integrity) and CET (Backwards-edge, Windows-only). This is where the heaviness of the build process comes in. Your distro's libs probably don't use CFI so they have to use their own vendored libs to fully benefit.

To do an official build (highly recommended for all the hardening and perf optimizations to take effect), you're also encouraged to use their patched Clang toolchain. So your source build would take way longer if you bootstrap those toolchains. A lot of Clang's exploit mitigations (CFI, shadow call stacks, etc) are actually from the Chromium and Android teams' work which often starts in their forked toolchains.

Finally, the whole thing is LTO'd with ThinLTO so they can use Clang's forward-edge control-flow integrity. Which makes link times and memory usage shoot up. Just doing ffmpeg alone (Chromium used a version of ffmpeg with statically-linked encoders/decoders) will max out my laptop's RAM if I do it with 4 threads or more.

They're also investigating "full LTO" to improve CFI coverage, but they're hesitant because could require over 64GB RAM at link-time. LTO is really hard to scale. The Hexavalent downstream project will probably use this first.

So basically: CFI requires LTO and benefits from vendored libs that are also built with CFI. Many of these libs are statically linked for a variety of reasons. All of that together means a big, slow, RAM-heavy build.

LMK if I got anything wrong. Thank you for coming to my TED talk.

re: TechPost, building chromium 

@dl @cwebber @emily FWIW Firefox is going down a similar path, though much more slowly. Official builds use vendored libs with custom hardening and they're removing blockers for future adoption of CFI.

It probably won't be as big as Chromium because Mozilla just doesn't have the resources to do all this work.

@Seirdy @dl @cwebber @emily And this is what you get for collectively jumping onto literally a remote-code-execution platform known as HTML5.

@dl @emily @cwebber wait. Can it be activated in a normal copy of chrome?

@mcc @dl @emily @cwebber It's basically a monorepo with vendored dependencies. Some components are mostly unused. So, no. If my understanding is correct.

@mcc @emily @cwebber You have to enable the necessary options in the build.

@dl @mcc @emily @cwebber Well you can compile them if you want but they won't be useful as-is. By default it only builds required deps with the features enabled for the target version of Chromium.

It's one repo for all platforms. You can build code for other platforms the same way you would for other software.

@cwebber idk does google's tendency to fork and forget extend to internal code? maybe there's like 4 different forks of webkit in there.

@cwebber like maybe there's the entire source for webkit base64 encoded inside another fork of webkit for Reasons

@cwebber @Greg gotta love corporate FOSS. Free as in "fuck you I've got mine" software

@cwebber Hope you have 64GB of RAM for the linking phase!

@cwebber They bundle all of the source for everything. IIRC Fedora was very frustrated trying to build Chromium packages that just linked to standard versions of libraries rather than the randomly patched versions that Google bundles in. Also horrible for getting upstream bug fixes, etc

lwn.net/Articles/886609/ covered this nicely

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!