YHK - yet another hacker news clone

P.S.: I've got to admit, though, that I was always impressed by the really great quality of Gentoo's documentation!

I used it on an off as my daily machine for around 15-20 years I think. It is fast in terms of execution-on-hardware speed, and genuinely puts you in control. For a certain kind of user this is more important than anything.

These days I'm on OSX mostly because of the frequency of business trips meant I needed something small and portable a few years ago, and now the hardware is so much better than what you can get for the PC world. Plus, I am hyper-conscious of my time and can't really afford to be fiddling with new system libraries, kernel configurations and so forth.

Frankly Gentoo was never polished, at some point the system state would break and you'd have to reinstall, and after enough iterations I'd started to err to Ubuntu at some point. But it was by far the most fun of any Linux I used, save perhaps Slackware which was my first.

I think in a few years' time the next machine I build will be a non-Apple ARM custom portable, hopefully running Gentoo, with a lot of custom machining and hardware features.

Daily Gentoo desktop user since 2007. Compilations/ricing is one thing, the variety and flexibility of the portage and USE flag system is another. For me it just makes sense to stay with this proven distro. I use Ubuntu variants on my work PC and they just have all this crap that I don't have to tolerate on my gentoo installs.

I remember triggering my third recompile of kde-base because I wanted a gui calculator. I moved away not long after that.

I'm using it as my main OS. I have it installed on 4 machines: a RK3288 SBC, a RK3588 desktop, a x86-64 desktop and a x86-64 laptop. Main incentive for me is customization.

- It makes it very very easy to patch any package before they're installed - just put the patches in /etc/portage/patches/<pkg name>/, and that includes the kernel too.

- I can exclude package features that I don't like. For example, my Firefox doesn't try/offer to turn on the wifi.

- I can also exclude entire packages that I don't like, because the entire dependency chains can be eliminated by disabling USE flags. For example, none of my systems have systemd or dbus. Since last year I don't even have openrc anymore (the other Gentoo service manager). One of them doesn't even have udev. I tweaked it so much, I'm not even sure I can still call it Gentoo.

My understanding is that compiler flags yielding speed boosts where an actual thing back in the day, but not anymore really.

Nowadays the speed come from other things. For example a few years ago i realised my firefox on linux was doing video encoding/decoding on cpu without using the intel gpu’s hardware encoder/decoder. I did not have to rebuild firefox from scratch but rather fiddle with configurations and environment variables to make sure Firefox wouldn’t assume the lowest common denominator.

That saved battery on my laptop and yielded better performance.

So basically they'd be new CVE's appearing by the time someone built the previous release at this pace? :P

No ccache?

I was ok with Chromium alone taking ~6h. I moved away when I started experimenting with Rust.

The main problems seem to be that it takes a long time to build all combinations of USE flags and that users complain that volunteers are not working fast enough, causing annoyance of the maintainers. Can you explain how AI would help here?

Most ai wouldn't know how to write a proper ebuild to save their lives.

Maintaining Gentoo ebuilds for complex packages such as Chromium is as peak Linux as one can get. You're talking about developers who _often_ discover and then submit upstream patches for the most obscure and difficult bugs that upstream projects haven't heard of. Often because Gentoo users are the only ones trying different compilation options, or they're the first to try building with more modern dependencies than the upstream project has yet attempted.

For just one of many examples, see [1] where the Gentoo developer had to submit a patch upstream for a Chromium build toolchain bug that to 99% of experienced Linux users is bordering on unintelligible due to how much specific knowledge is needed to understand the bug.

[1] https://bugs.gentoo.org/956054#c2

Chromium looks like a build system for a complex integrated project where the engineers have one priority: make the application work as best it can. You will quickly find that when you focus on that then making the build system convenient, especially convenient for distribution packagers with their myriad of own rules and modifications that they want to make on top of your system, is quite a big blocker to the primary goal. You can see similar things with applications like OBS, where they bundle modified libraries to fix problems and then distributions unbundle them and release broken packages, causing no end of grief for users and the developers.

There is not some arbitrary notion of wheel reinvention just for browsers. Calling browsers 'just browsers' is doing their feature set a huge disservice: they are bona fide operating systems or virtual machines, which have to load and run untrusted, unverified data and code within critical system libraries (many of which with kernel-mode access, such as GPU drivers, sound drivers, USB subsystems, and more), and do a huge amount of sandboxing to guard against escalations.

Within Google, a Chromium build uses remote build execution by default, upstream Clang by default (for the latest features and fixes, and Chromium developers regularly contribute to LLVM), and needs to cross-compile easily for at least a dozen different OS-architecture triples (Linux x86-64, Linux ARM, macOS, Windows x86-64, Windows on ARM, iOS, Android x86-64, Android ARM, Android TV, some BSDs, etc).

Everything you've listed—from ninja, to Clang, to libraries with custom patches, to Clang releases, including requiring pre-releases sometimes—is optimised for Google's scale, rather than the lone warrior developer. What you call 'sane Linux defaults' (especially the examples you have listed: GCC, automake, so-called 'system libraries') are highly antagonistic to all of the above.

They may make life easy for the so-called 'default case' of desktop Linux (arguable; Chromium was first released on Windows, and secondly since desktop Linux's most common C library, glibc has an unstable ABI, making back-portability impossible), but make it incredibly hard to get out a project of such immense complexity. All of Chromium's tooling and 'complexity' was developed in response to the 'sane' defaults being not so sane after all.

To get a GCC cross-compile for a given set of architecture triples, one needs a complete graph of GCC toolchains targeting every pair of host and target. On the other hand Clang is natively a cross-compiler; pass in `--sysroot` and the host compiler will redirect for the target instantly. Automake (and the autotools in general) is slow as molasses compared to ninja. It is based on computing and compilation from the 1970s, and their defaults probe for long-since-dead string comparison functions that are expected to work by default nowadays on most hosted systems. Not to mention it has an extraordinarily complicated configure step[1], and an equally appalling macro-based configure language.

Ninja is purely declarative, and is not even meant to be human-readable, as it is a back-end for a variety of build generator tools (CMake, XMake, build2, Bazel (Blaze internally at Google), Meson, probably more). Google have in fact rewritten Ninja to be a remote-build-capable tool from the outset[2], and they call it Siso. Siso has more than halved my Android build times even compared to Ninja because of its incredible use of RBE.

Frankly I think it should be evident why they have opted for 'rewriting the world' including vendoring and modifying system libraries, as well as including efforts like Skia, ANGLE, and more: directly relying on 'system libraries' is painful. I mentioned GPU drivers. Imagine rewriting the same code over and over to have precisely the same behaviour on D3D, Vulkan, OpenGL, Metal, and every single vendor GPU driver on every single system (and there are a lot more on mobile than on desktop: ARM Mali, Qualcomm Adreno, Samsung Xclipse, Imagination PowerVR, Huawei, MediaTek; this is not even close to exhaustive, just look at the Khronos vendor list).

When comments like yours are made I wonder if there is ever a consideration beyond 'it makes the developer's life hard'. As developers, our ultimate target audience are the users of our software. We should be willing to do anything come hell or high water, even making the dev-ex extraordinarily convoluted, if it means the user experience will be the smoothest and fastest possible. Sure, there is a balance, but I believe it should be strongly skewed towards the user story first.

[1]: https://upload.wikimedia.org/wikipedia/commons/8/84/Autoconf...

[2]: https://chromium.googlesource.com/build/+/refs/heads/main/si...

  # I_ALLOW_TO_BREAK_MY_SYSTEM=yes emerge -1v =sys-libs/glibc-2.43-r4
  These are the packages that would be merged, in order:
  <snip>
  [ebuild     UD ] sys-libs/glibc-2.43-r4:2.2::gentoo [2.44-r3:2.2::gentoo] <snip>

  Total: 1 package (1 downgrade), Size of downloads: 0 KiB

  >>> Verifying ebuild manifests
  
  >>> Running pre-merge checks for sys-libs/glibc-2.43-r4
  
  >>> Emerging (1 of 1) sys-libs/glibc-2.43-r4::gentoo
   * glibc-2.43.tar.xz BLAKE2B SHA512 size ;-) ...           [ ok ]
   * glibc-2.43-patches-5.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ]
   * Checking whether python3_14 is suitable ...
   *   dev-lang/python:3.14 ...                              [ ok ]
   * Using python3.14 to build (via PYTHON_COMPAT iteration)
  >>> Unpacking source...
   * Checking general environment sanity.
   * Sanity check to keep you from breaking your system:
   *  Downgrading glibc is not supported and a sure way to destruction.
   * Performing simple compile test for ABI=amd64 ...
   <snip>

  * Call stack:
  *     ebuild.sh, line  143:  Called src_unpack
  *   environment, line 3570:  Called sanity_prechecks
  *   environment, line 3199:  Called die
  * The specific snippet of code:
  *               [[ ${I_ALLOW_TO_BREAK_MY_SYSTEM} = yes ]] || die "Aborting to save your system.";

The Chromium build process is just a consequence of the monorepo mindset. For Google, depending on specific versions of tools and dependencies is not a problem because all their engineers will automatically get those versions. For the Linux distribution model it's a pain.

gentoo's emerge is awesome. I keep a gentoo vm just to compile firefox, because it is impossible any other way. even though i don't use gentoo overall.

the comments trying to defens chrome (and old OBS) are completely corporate shills or missing the point. yeah obs at first did that because they had to, since it was such a small and niche project the devs had no pull upstream. after distros did all the unbundling job and helped them move patches upstream now every software benefit from those libraries fixes.

Google took chromium et al from open source and actively moved in the wrong direction, while having all the pull and influence like no open source project will ever have! its malice and/or incompetence. if you don't see that you're either shillings or lying to yourself. or have no knowledge of what open source is about.

> Linux defaults (GCC, automake, system libraries)

Last time I tried Gentoo desktop I ended up with 8 separate autotools versions, and gcc & glibc was not that far behind in count. And just like in https://xkcd.com/927/ every C developer tries to improve the situation by creating another build system.

> Firefox is bad to compile yourself, because it's slow and often requires a library version you don't have, such as a new ICU version. Updating ICU also requires you to build packages that depend on it

> Chromium does not compile with gcc. Of course, it needs a specific clang release, sometimes even a pre-release, or again a load of patches to compile

And that is what is wrong with today software: it is an uncompilable mess. It is "This program requires Windows 98 and Internet Explorer 4" brought to a new level.

Software has become balkanized.

Use of the passive voice is a giveaway. People seem to write as if these are large corporate projects with managers and all, not volunteer driven.

Current Gentoo user here. This hasn't been a real issue for me in years.

Companies hardly ever contribute anything to the projects they depend on.