Also worth noting https://lwn.net/Articles/1097760/ - Gentoo has given up on building Chromium from source, because upstream "do not test their builds with any of their allegedly 'optional' features disabled" and "[i]n the case of Chromium, keeping all the toggle switches working (despite chronic neglect from upstream) is a monumental, nigh-insurmountable task." One maintainer said he could not possibly test all the combinations of USE flags in the Gentoo build, since his laptop took 15-16 hours to compile Chromium (I presume for just one build, which would have to be repeated 2^N times to test all possible flag combinations).
Much more in the LWN article, I'm not going to quote everything.
I only glanced at Helium's site, but I suspect from what I saw that they pick a status (enabled/disabled) for all those optional features, meaning they just have to test one (or maybe two or four) combinations of `--enable-foo` / `--enable-bar` flags. Whereas Gentoo tried to allow users to set whatever combination they wanted, and that wasn't working so well when upstream wasn't helping.
upstream "do not test their builds with any of their allegedly 'optional' features disabled"
I've noticed this too and it's really annoying. Their CI doesn't even run `gn` for the use-flag permutations, which would take a trivial amount of compute. They could easily compile-but-not-link for every combination of flags in CI too at only a modest compute expenditure. At least that way people who break the #ifdef maze would be forced to fix it.
To be fair though: that's a gentoo fault. They want to be able to be as customizable as possible, which is fine, but if you support all flag-combinations, you are going to either test them all, or forego testing them. It's also a bit awkward that they don't mention this with regards to the linux kernel. Are the use flags that limited to begin with?
I'm betting the Linux kernel actually tests their config combinations. The complaint is that Chromium doesn't test turning off their allegedly-optional features, so when one of those features turns out not to be as optional as it claims to be, it's Gentoo maintainers who bear the brunt of discovering that (or users end up finding it out if it's not tested).
I can't tell you what Gentoo does with the Linux kernel in terms of USE flags; it's been over a decade since I last tried Gentoo and I don't want to spend the time looking it up since I doubt anyone truly cares. (If someone does care enough and looks it up, I care just enough to be curious to know what you find).
> I'm betting the Linux kernel actually tests their config combinations.
What makes you bet that?
As far as I know, the kernel doesn't have any official CI. People test as they feel like it. Some people/companies build some CI initiatives, others don't use them.
all config combinations aren't valid (because of dependencies), and when there isn't they are mostly independent (e.g. 2 builds with CONFIG_FOO=y/CONFIG_BAR=y and CONFIG_FOO=n/CONFIG_BAR=n cover 100% of the cases for unrelated FOO/BAR), so it's not that bad.
And folks do build stuff, including with the awesome "randconfig" mode which generates a.. random config, so while it's still possible for some specific config to not actually work at runtime it's actually quite unlikely for build itself to fail (for releases at least)
What you're saying is "maybe they should stop being Gentoo". The whole point of Gentoo is customization of your built-from-source packages. (As I recall, but it's been over a decade since I tried it so I might be remembering things wrong). Every optional feature in a piece of software, that would be controlled by some `--with-foo` option to `configure`, gets turned into a USE flag in Gentoo. Packages that have `--with-foo`, `--with-bar`, `--with-baz`, and `--with-quux` then have four USE flags, with 16 possible combinations of enabled or disabled. And the Gentoo maintainers team tries to make sure that all those combinations work, except for ones that obviously contradict each other.
So it's not Gentoo's decision to have so many flags, it's upstream's decision. I bet the Gentoo maintainers would love it if upstream acknowledged "okay, this 'optional' feature isn't really optional any longer". But they don't, and they continue to have dozens of flags, which Gentoo (due to their build philosophy) dutifully copied and tried to test — an overwhelming task.
> So it's not Gentoo's decision to have so many flags, it's upstream's decision.
That's a weird statement to make though. I would say that it was Gentoo's decision to test for all functionality.
But, even ignoring this for the moment: how does this apply to the linux kernel? Because the config file has TONS of options. Does Gentoo support all of these via use flags? If not, why not? Because that distinction to me would be totally arbitrary.
Would you say they should NOT test the options they're offering the user?
Because Gentoo has basically three options; let me know if you can think of a fourth option I'm missing.
1. Turn every optional feature from upstream into a USE flag, and test them. Which means testing all the 2^N combinations.
2. Turn every optional feature from upstream into a USE flag, but do not test them. Which means users can end up with untested combinations, some of which have proven in the past to be buggy.
3. Stop turning every optional feature from upstream into a USE flag. Which means giving up on Gentoo's distinguishing characteristics for this package.
Okay, I guess there's a fourth option:
4. Stop packaging the Chromium package at all. Which is what they've ended up doing.
I can tell you what Gentoo shouldn't do: blame upstream for having assigned themselves the mission to support and test 2^N combinations of options for which they don't get to curate N.
They're free to limit which options they offer, they're free to limit which combinations they support, and they're free to fork or drop the software they offer if they insist on keeping the 2^N purity (which they eventually did). But that's Gentoo's mission, not upstream's. Upstream is just giving them software for free on an as-is basis.
Traditionally, the Gentoo package manager didn't actually compile the Linux kernel at all. Instead it just extracted the source code to a folder on your hard drive and you were supposed to go configure, build, and install it yourself. Gentoo Wiki pages would list out the options you had to go set in the `make menuconfig` menu to get specific software to work.
These days there is a package that builds the kernel for you, but it relies on the "savedconfig" system to just save/load the entire kernel config file instead of using USE flags. So you still have to root around in the config menu yourself to change things.
In my experience Linux is very good at correctly declaring dependencies between options, and still working with options disabled, so this isn't as much of a problem as it seems to be for Chromium.
I am sorry but I don't really have any respect for developers
who help empower the evil AdChromium empire. I understand that
people invest their time in making money; I have no problem
with that. But I am not going to read a chromium-promo - aka
a Google-promo - at the end of the day. That company should
have already been split up decades ago.
Also worth noting https://lwn.net/Articles/1097760/ - Gentoo has given up on building Chromium from source, because upstream "do not test their builds with any of their allegedly 'optional' features disabled" and "[i]n the case of Chromium, keeping all the toggle switches working (despite chronic neglect from upstream) is a monumental, nigh-insurmountable task." One maintainer said he could not possibly test all the combinations of USE flags in the Gentoo build, since his laptop took 15-16 hours to compile Chromium (I presume for just one build, which would have to be repeated 2^N times to test all possible flag combinations).
Much more in the LWN article, I'm not going to quote everything.
I wonder how the Helium [0] project solves this, since they also work off of an opinionated-ish Chromium base.
[0] https://helium.computer
I only glanced at Helium's site, but I suspect from what I saw that they pick a status (enabled/disabled) for all those optional features, meaning they just have to test one (or maybe two or four) combinations of `--enable-foo` / `--enable-bar` flags. Whereas Gentoo tried to allow users to set whatever combination they wanted, and that wasn't working so well when upstream wasn't helping.
upstream "do not test their builds with any of their allegedly 'optional' features disabled"
I've noticed this too and it's really annoying. Their CI doesn't even run `gn` for the use-flag permutations, which would take a trivial amount of compute. They could easily compile-but-not-link for every combination of flags in CI too at only a modest compute expenditure. At least that way people who break the #ifdef maze would be forced to fix it.
To be fair though: that's a gentoo fault. They want to be able to be as customizable as possible, which is fine, but if you support all flag-combinations, you are going to either test them all, or forego testing them. It's also a bit awkward that they don't mention this with regards to the linux kernel. Are the use flags that limited to begin with?
I'm betting the Linux kernel actually tests their config combinations. The complaint is that Chromium doesn't test turning off their allegedly-optional features, so when one of those features turns out not to be as optional as it claims to be, it's Gentoo maintainers who bear the brunt of discovering that (or users end up finding it out if it's not tested).
I can't tell you what Gentoo does with the Linux kernel in terms of USE flags; it's been over a decade since I last tried Gentoo and I don't want to spend the time looking it up since I doubt anyone truly cares. (If someone does care enough and looks it up, I care just enough to be curious to know what you find).
> I'm betting the Linux kernel actually tests their config combinations.
What makes you bet that?
As far as I know, the kernel doesn't have any official CI. People test as they feel like it. Some people/companies build some CI initiatives, others don't use them.
https://lwn.net/Articles/972713/
Also the kernel has > 10000 Kconfig options. Somebody told me that 2^64 is a lot, and that 2^10000 is a lot more.
all config combinations aren't valid (because of dependencies), and when there isn't they are mostly independent (e.g. 2 builds with CONFIG_FOO=y/CONFIG_BAR=y and CONFIG_FOO=n/CONFIG_BAR=n cover 100% of the cases for unrelated FOO/BAR), so it's not that bad.
And folks do build stuff, including with the awesome "randconfig" mode which generates a.. random config, so while it's still possible for some specific config to not actually work at runtime it's actually quite unlikely for build itself to fail (for releases at least)
Then those chromium flags should not exist.
Well. Maybe they should just not have so many flags than?
What you're saying is "maybe they should stop being Gentoo". The whole point of Gentoo is customization of your built-from-source packages. (As I recall, but it's been over a decade since I tried it so I might be remembering things wrong). Every optional feature in a piece of software, that would be controlled by some `--with-foo` option to `configure`, gets turned into a USE flag in Gentoo. Packages that have `--with-foo`, `--with-bar`, `--with-baz`, and `--with-quux` then have four USE flags, with 16 possible combinations of enabled or disabled. And the Gentoo maintainers team tries to make sure that all those combinations work, except for ones that obviously contradict each other.
So it's not Gentoo's decision to have so many flags, it's upstream's decision. I bet the Gentoo maintainers would love it if upstream acknowledged "okay, this 'optional' feature isn't really optional any longer". But they don't, and they continue to have dozens of flags, which Gentoo (due to their build philosophy) dutifully copied and tried to test — an overwhelming task.
> So it's not Gentoo's decision to have so many flags, it's upstream's decision.
That's a weird statement to make though. I would say that it was Gentoo's decision to test for all functionality.
But, even ignoring this for the moment: how does this apply to the linux kernel? Because the config file has TONS of options. Does Gentoo support all of these via use flags? If not, why not? Because that distinction to me would be totally arbitrary.
Would you say they should NOT test the options they're offering the user?
Because Gentoo has basically three options; let me know if you can think of a fourth option I'm missing.
1. Turn every optional feature from upstream into a USE flag, and test them. Which means testing all the 2^N combinations.
2. Turn every optional feature from upstream into a USE flag, but do not test them. Which means users can end up with untested combinations, some of which have proven in the past to be buggy.
3. Stop turning every optional feature from upstream into a USE flag. Which means giving up on Gentoo's distinguishing characteristics for this package.
Okay, I guess there's a fourth option:
4. Stop packaging the Chromium package at all. Which is what they've ended up doing.
I can tell you what Gentoo shouldn't do: blame upstream for having assigned themselves the mission to support and test 2^N combinations of options for which they don't get to curate N.
They're free to limit which options they offer, they're free to limit which combinations they support, and they're free to fork or drop the software they offer if they insist on keeping the 2^N purity (which they eventually did). But that's Gentoo's mission, not upstream's. Upstream is just giving them software for free on an as-is basis.
Which option was chosen for the Linux kernel?
Traditionally, the Gentoo package manager didn't actually compile the Linux kernel at all. Instead it just extracted the source code to a folder on your hard drive and you were supposed to go configure, build, and install it yourself. Gentoo Wiki pages would list out the options you had to go set in the `make menuconfig` menu to get specific software to work.
These days there is a package that builds the kernel for you, but it relies on the "savedconfig" system to just save/load the entire kernel config file instead of using USE flags. So you still have to root around in the config menu yourself to change things.
In my experience Linux is very good at correctly declaring dependencies between options, and still working with options disabled, so this isn't as much of a problem as it seems to be for Chromium.
Honestly, I wonder how much money she gave up? I would need to be "post-economic" before I could do something like that.
I am sorry but I don't really have any respect for developers who help empower the evil AdChromium empire. I understand that people invest their time in making money; I have no problem with that. But I am not going to read a chromium-promo - aka a Google-promo - at the end of the day. That company should have already been split up decades ago.
I've read it, it was nice and doesn't really promote Chrome or Google.