Much more in the LWN article, I'm not going to quote everything.
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.
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'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.
Between 63 and 68% of Google is owned by households, directly or via funds.
I'm not sure why would it be more fair for a company to be private and owned by its workers, versus being owned by anybody who wants to.
"Anybody who wants to" is precisely the problem -- there's no correlation between a rando's wishes and the health of a project or working environment. You need people with skin in the game, and in the right game.
That's up to regulators to fix.
As an investor a company's duty is towards shareholders.
But they should be marked experimental in that case, not optional. Optional flags ought to work together, or at least it should be considered a bug worth quickly fixing if they don't. Combining experimental flags otoh is Buyer Beware.
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.
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)
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.
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.
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.
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.
While the "we're entitled to bugfixes" attitude is definitely annoying for software maintainers to deal with, and you (as the end user) aren't entitled to anything from 99% of open-source projects... this is Chromium we're talking about. The browser engine that powers 75-95% of all Web browsing (it's very hard to pin down actual numbers, but it's huge). It is not too much to ask that the Chromium maintainers either 1) test all the combinations of optional flags they have, or 2) declare that some of those optional flags are no longer optional. In other words, to act like professionals.
(I don't use Chromium myself — switched to Firefox years ago because I tend to open a lot of tabs, which make Chromium seem to just gobble up RAM, and Firefox appears a little better at RAM management, or at least it did at the time I switched (haven't checked recently). So this isn't "the Chromium team owes me something", this is shaking my head in disappointment at what the Gentoo maintainers report that Chromium team is doing, or rather not doing. As I said, there are some projects — the Linux kernel is one, and Chromium is another — that are so widely used that a certain level of professionalism should be expected of their maintainers. I agree that that attitude of entitlement is not deserved in about 99% of open-source projects. But Chromium is part of the 1% exception, IMHO).
I just don't like this idea that downstream maintainers need to be saved from themselves by limiting the options upstream provides them.
Downstream are not end users, which I agree should only get tested builds. They're professionals too, and they can be trusted to pick the configurations they want to build, evaluate how much more testing they need, and cut out configurations from their support matrix if they don't have the resources to support them.
Also, this idea that a professional project wouldn't offer untested combinations of settings to other professionals is why people follow up asking about Linux. A quick search tells me it's got ~19,000 Kconfig options[1].
[1]: https://dl.acm.org/doi/fullHtml/10.1145/3646548.3676548