Last rites for Gentoo's Chromium package

Last rites for Gentoo's Chromium package Chromium, the open-source upstream project for Google's Chrome web browser, is the browser of choice for many Linux users. It has also gained a reputation as being difficult for Linux distributions to package and build: Chromium has a complex build system, the project bundles many of its dependencies, and it has frequent releases. All of that, plus user complaints, has led the maintainers of the Gentoo Chromium package to give up on trying to maintain the package. Gentoo focuses on allowing users to build their own software from source using the Portage software-management tool. Gentoo packagers create ebuild files, which are text files written in a Bash-like syntax that contain the information needed by Portage to build the software. Users then build packages themselves using emerge, which is the command-line interface for Portage. A recent ebuild for Chromium illustrates the complexity of the package. Gentoo does offer prebuilt binary packages for some software via its Binhost project. However, building from source gives users the flexibility to declare USE flags to set compile-time options or change a package's configuration. For example, a user may wish to specify which optional libraries are linked with a package, or whether to install the accompanying documentation. With Chromium in particular, a user might employ the -bundled-toolchain USE flag (which tells Portage not to use the bundled toolchain) in order to use their system's version of Clang to compile Chromium rather than the bundled version included by the upstream project. That is optional for Gentoo users on x86-64 systems, but -bundled-toolchain is required for users on other architectures, since Chromium's bundled toolchain is only shipped for x86-64. It is worth noting that Chromium is currently not available as a binary package from Gentoo due to problems with building the package with proprietary codecs. Last rites Many distributions, including Arch Linux, Debian, and Fedora, use the term "orphan" to refer to packages that have been abandoned by their maintainer; the developer announces that a package has been orphaned, and other contributors have the opportunity to claim maintainership of it if they wish to do so. Gentoo's terminology is a bit more dramatic: a package maintainer announces "last rites" for a package on the gentoo-dev-announce mailing list to notify the project that it will be unmaintained, and as an opportunity to allow other developers to claim maintainership. After a developer has declared last rites, the package's ebuild is masked in Gentoo's ebuild repository to ensure that users will not accidentally install a package that is no longer being maintained. Users who have the package installed and attempt an upgrade will receive a warning that it has been masked. Chromium package maintainer Sam James declared last rites for the Chromium package on September 24, after a lengthy conversation in a bug report filed by Roman Žilka. On September 9, Žilka had complained that the latest stable version of the Chromium ebuild was outdated: The latest stable www-client/chromium (and google-chrome and possibly others) is 151.0.7922.169, which contains a catastrophic 602 known vulnerabilities of all severities. Measures need to be taken by somebody qualified that this doesn't keep happening in packages as important as these. He had attached an ebuild for a newer version of Chromium to the bug report, but noted that it would not work if a user tried to compile Chromium with the -bundled-toolchain USE flag. James replied, "Chromium is horrible to maintain as a source package. It is easily the package in Gentoo that burns through maintainers the most." Complaining about its maintenance isn't helpful, he said, and added that the maintainers have come close to giving Chromium last rites several times over the years due to the difficulty in keeping it up to date. He also noted that he had mentioned this to Žilka before, and said that it would be welcome if he wanted to assist with the package. Indeed, Žilka had filed a similar bug in August complaining about the number of vulnerabilities present in the Chromium ebuild; James had replied then that the package had always been difficult to maintain, "and now they've added Go" as a dependency as well. Prior to that, Žilka had shown up in a bug report filed by Matt Jolly about Chromium vulnerabilities to complain that "the update process needs fixing, so that events like these don't happen again in packages as critical as these!" Jolly had replied that the maintainers are a team of volunteers who do their best, but "build failures, human factors ('I messed up assigning the bug and automation didn't pick it up'), and my own limited free time are the biggest causes of delays". The best way to change the situation, he said, would be for Žilka to volunteer his help. Trial and error There are various third-party repositories, called overlays, that provide additional and alternative ebuilds for Gentoo. On September 11, Nick Reale said that he had tried ebuilds for a newer version of Chromium from the Bentoo and Fireburn overlays, but he couldn't get either one to work. A few days later he reported success with Bentoo's ebuild and a specific set of USE flags. There was some follow-on discussion from Reale and François Valenduc about various incantations they were able to use to compile an updated version of Chromium on Gentoo from other ebuilds. On September 18, Valenduc commented that version 153.0.8010.47 of Chromium was out, and that version was already available in Arch Linux, openSUSE, SUSE, and Ubuntu. "We are still waiting for Gentoo despite all the proposals made here." James replied that none of the maintainers have had a chance to look into the problems with the Chromium package yet. He said that the patches and ebuilds that had been submitted with the bug report were "useful and appreciated, but it's not as simple as just grabbing it and committing it". Users would complain, he said, if the maintainers had not tested the ebuilds and it broke on their systems. It'll get done when it's done, but it's more likely to be last-rited if nobody is interested in handling it in the way these things have to be done (which goes beyond just attaching ebuilds). Valenduc said that he was not able to maintain the package, "but taking the ebuild from the bentoo overlay was not that difficult [...] It's just frustrating to see no updates in Gentoo." James replied that just because the ebuild worked for Valenduc did not mean it had all USE flags working. He added that no one had submitted a patch to the Gentoo ebuild, which meant that the maintainers would need to reverse-engineer the changes by diffing the ebuilds and work out what had been modified. "All of that is a non-trivial amount of work and while having some ebuild to start with is useful for that, it doesn't mean one can just git add && git commit && git push it." Valenduc acknowledged that he could not test all possible USE flags, since it took between 15 and 16 hours to compile Chromium on his laptop. On September 24, Žilka commented: "This is ridiculous". A few minutes later, James replied "OK then", and issued the last rites for the package. Can we keep it? Maciej S. Szmigiero asked if it would be possible to keep the ebuild in Gentoo's repository and just declare that it was maintained at "best effort" level. "Removing buildable/patchable Chromium is a huge loss for a Gentoo desktop." James said that he did not think that was possible. He had already explained that Chromium was being maintained by volunteers, and that explanation had not been accepted. People were free to maintain the ebuild in another repository, he said, but that meant they would have to do the work themselves or accept someone doing it to a lower standard. He pointed out that the ebuilds from the Bentoo overlay had been cited in the discussion, but creation of those ebuilds seemed to be "heavily automated" and had missed some fixes in the Gentoo version. "Copying ebuilds works fine until it doesn't." James added that someone could still pick up the Chromium package before the end of the last-rites period on October 24, or that the package could be restored in the future. He did not want to see that, though, unless there was a plan for sustainable maintenance. "Chromium has a history of burning out maintainers in Gentoo because of the high rate of churn upstream, though some of the contents of this bug don't help motivation at all either." Matt Whitlock wondered if the developer-burnout factor could be reduced by eliminating most of the USE flags for Chromium, or if the maintainers stopped unbundling third-party libraries. Basically, what I am asking is: can we give up _all_ of the flexibility to which we have grown accustomed in www-client/chromium, in exchange for a package that is actually maintainable but that is still built from sources by a toolchain that is not distributed as opaque binaries? He added later that part of the problem was that the upstream project developers "do not test their builds with any of their allegedly 'optional' features disabled". That left the responsibility with the downstream package maintainers. "In the case of Chromium, keeping all the toggle switches working (despite chronic neglect from upstream) is a monumental, nigh-insurmountable task." Complexity That was a good question, James said, but part of the recent complexity with Chromium was the addition of Rust and Go dependencies. The packagers had to do some wrangling to ensure that the Go build did not require network access, which is forbidden with Gentoo ebuilds, but that was not the only problem. He said that Google developers seem to keep using experimental Rust features that break on new releases as well. On top of that, "yet another problem is that upstream's CI to produce release tarballs isn't reliable". One of the Gentoo Chromium maintainers had sent patches to fix that, to little avail. "It took ages to get [the patches] reviewed, and it's broken again a few times since. They didn't seem to notice or care that it either wasn't producing tarballs or was producing incomplete ones." Jolly added some of his observations about problems with maintaining Chromium for Gentoo. He said that maintaining Chromium can take more than six hours each week, and that was counting only compilation time on a fast PC with "an absurd amount of RAM". Compilation time is even longer for 64-bit Arm machines. It's a commitment to volunteer at least a business day's worth of your free time each week when you include rebasing patches, cherry-picking fixes, iterating on `ebuild ... clean compile`, plus trying to identify and fix any new bugs, working out how much you violate Gentoo policy by not unbundling more of the browser, spending time on automation to save time and mistakes later, etc. There's immense pressure to keep builds up-to-date, especially in the age of hundreds of weekly browser CVEs. He included a "pre-emptive FAQ" in his reply about the last rites for Chromium, and what it would require to restore the package. He said that there were no insurmountable technical issues to maintaining Chromium, but it would need multiple maintainers with a broad set of skills—including familiarity with C, C++, Go, JavaScript, and Rust. "There are also a huge number of NIH [not invented here] Google tools that you'll [have to] develop skills for and never be able to use anywhere else - you have been warned." Using Google's toolchain would be simpler, but it would also restrict the ebuild to x86-64, he said. "We'd lose arm64, ppc64, and the RISC-V overlay - better to just rip the band-aid off now as it doesn't materially make the situation better". He added that he would be willing to review commits and offer advice to anyone who wanted to maintain the source ebuild, but he felt that at least three people would be needed. "History has shown that one maintainer isn't working, and we've had the release cycle shorten twice since I started maintaining the package in 2023; it was bad then, and it's worse now." The release cadence for Chromium is aggressive, to say the least. Chromium has multiple channels including stable, beta, and development. There is a new major branch of the browser roughly every two weeks via the stable channel, and a new version is shipped every week. Getting Chromium For now, it appears that Gentoo users will need to search elsewhere for a suitable Chromium ebuild, choose a different browser, or find a different distribution method to acquire Chromium. For example, Gentoo users could install the Flatpak from Flathub, but it is an unverified package built by a third party—not by the Chromium upstream project. The Flatpak is also of no help for users who are not on x86-64 or 64-bit Arm systems. It is technically possible for Chromium users to build and compile the browser on their own using the upstream's instructions, but it does not appear that the Chromium project cares a great deal about making that easy to do. It does have a page on getting the code but the links to instructions for Linux (as well as macOS and Windows) return a 503 error. Searching for instructions turns up this page, though it is undated so it is unclear if it is the most up-to-date. Assuming the instructions are current and correct, building Chromium using those directions is quite an ordeal. Users can download pre-built binaries from the project, but only for x86-64 systems. Other distributions continue to supply Chromium packages, of course, though their approach does not provide the same flexibility as Gentoo's. Fedora's package (which is described as "A WebKit (Blink) powered web browser that Google doesn't want you to use") is at version 154.0.8037.92—one version behind the upstream (154.0.8037.97) release that was published on October 1. Likewise, the package in Debian's security repository is the same version (currently) as Fedora's and the information page shows that there are at least 11 known CVEs addressed in 154.0.8037.97. Keeping up with Chromium is not an easy task. Perhaps Gentoo will find a team that is willing and able to take on the burden of maintaining the Chromium ebuild up to the standards that Gentoo users expect. Whatever happens, it seems unlikely that Chromium will become any easier to maintain in the interim. On expectations Posted Oct 6, 2026 14:38 UTC (Tue) by sam_c (subscriber, #139836) [Link] (12 responses) On bundled dependencies: one additional issue is that if we were to go "fully (Google) native" and eschew system libraries in favour of Google's bundled copies, the costs would in some way become greater: longer build times, unhappy users, greater portability issues (consider non-amd64), and losing out on features like distcc compatibility which in part presently mitigates the build time suffering. That is, at a point, are we only performing a "from source" build on the face of it, but not to the standards users have reasonably come to expect? But even this is rather taxing to maintain. From my survey of other distributions, it appears they're often also behind by at least one major version (perhaps made worse by the release cadence change), and they don't have the permutations to handle that we do: it only has to build on the set of architectures $DISTRO supports, and it only has to build with one set of build options on a particular builder machine, rather than on all machines from users. I think we're all suffering. On expectations Posted Oct 6, 2026 14:52 UTC (Tue) by collinfunk (subscriber, #169873) [Link] (5 responses) I wonder, is packaging other browsers (I guess, only Firefox, really) similarly challenging, or are these issues unique to Chromium? From my perspective as an outsider, it seems Firefox is equally massive and riddled with security issues. But perhaps they make it easier to build and to release less frequently? Anecdotally, I have tried to make the projects I work on easy for downstream maintainers. But, then again, I don't work on anything the size of Chrome. On expectations Posted Oct 6, 2026 15:52 UTC (Tue) by sam_c (subscriber, #139836) [Link] (2 responses) Firefox is also challenging but Mozilla seems to care at least a bit about downstreams being able to consume Firefox's sources: you don't have the disappearing or incomplete source tarballs, they're generally receptive to patches, and they seem to help at least sometimes (I can't say always because I'm not as familiar with it, but it doesn't mean they aren't) when folks get stuck. Firefox increased its release cadence a few years ago and maybe even more recently again, but I believe the changes on the build side are usually quite small. The biggest problems we have there involve some small components which sometimes break with newer Rust (SIMD I think). qtwebengine benefit from Qt's efforts to wrap it in something sane, so is more tolerable than Chromium. But it's often behind Chromium by a fair bit, though they do backport (some? again, not certain if it's all; not claiming it is definitely not all) security fixes. webkit-gtk is also mostly okay though it does take a significant time to build (same for all of these) and we have to build several variants right now for some ABI changes, which is unfortunate. Firefox maintenance Posted Oct 6, 2026 18:03 UTC (Tue) by sam_c (subscriber, #139836) [Link] (1 responses) I was under the impression (I think wrongly?) that anonymous comments could be made with subscription links but it looks like not. Posting juippis's comment on his behalf then: Hey, sam asked me to fill in as Gentoo's current Firefox maintainer. Firefox is a lot of work, but I'd like to share few points why I believe it's easier than Chromium. Note that I have close to 0 experience packaging Chromium, I've just aided with some updates previously. Hey, sam asked me to fill in as Gentoo's current Firefox maintainer. Firefox is a lot of work, but I'd like to share few points why I believe it's easier than Chromium. Note that I have close to 0 experience packaging Chromium, I've just aided with some updates previously. I could write a long detailed post about everything I do with each Firefox release, but since I'm a guest here, I'll try to keep it short. I could write a long detailed post about everything I do with each Firefox release, but since I'm a guest here, I'll try to keep it short. TLDR as a whole is: TLDR as a whole is: Doing the version bumps properly takes a lot of time - mostly because I test with multiple USE flag combinations, gcc/clang, and simply testing pgo itself takes like an hour to build once. It can be hard, because Gentoo carries few custom patches, e.g. to enable different system-* libraries to be used instead of bundled ones, and those regularly break / need patch rebasing. But upstream is rather welcoming, and bigger issues affecting the whole Linux ecology are usually fixed fast by upstream. Upstream also has a CI building using Ubuntu. We usually find toolchain / system-lib related issues amongst the first ones due to the nature of Gentoo being a rolling-release distro, with newer toolchain available. Some of the Firefox developers seem to use Gentoo, too. Therefore I'd say the relations between upstream and other distros is stronger with Firefox, especially since Firefox is often the default browser in other distributions. Doing the version bumps properly takes a lot of time - mostly because I test with multiple USE flag combinations, gcc/clang, and simply testing pgo itself takes like an hour to build once. It can be hard, because Gentoo carries few custom patches, e.g. to enable different system-* libraries to be used instead of bundled ones, and those regularly break / need patch rebasing. But upstream is rather welcoming, and bigger issues affecting the whole Linux ecology are usually fixed fast by upstream. Upstream also has a CI building using Ubuntu. We usually find toolchain / system-lib related issues amongst the first ones due to the nature of Gentoo being a rolling-release distro, with newer toolchain available. Some of the Firefox developers seem to use Gentoo, too. Therefore I'd say the relations between upstream and other distros is stronger with Firefox, especially since Firefox is often the default browser in other distributions. Gentoo offers "two channels" - Firefox-157.0 with testing keywords, and Firefox-153.4.0esr with stable keywords. Thunderbird is identical; Thunderbird-157.0 and Thunderbird-153.4.0esr. Thunderbird releases come immediately after Firefox and sometimes requires TB-specific patches to be added. Firefox recently switched to 2-week release cadence, where it used to be 4 weeks, so the work is now doubled each month. It currently takes me ~20 hours every 2 weeks to do everything related to version bumps (both Firefoxes, both Thunderbirds, Spidermonkey, security bugs...) and I've even skipped a step recently, and am pushing ESR's straight-to-stable (after testing on stable system) to save some time. Most of the hours go into running build-tests, which can be done by leaving the pc to run on its own. There's I'd guess ~3-4 hours of "active" work (without bugs) whenever major releases happen. So there's one less active channel to monitor than what Chromium currently has, but I think handling Thunderbirds make it equal here. Gentoo offers "two channels" - Firefox-157.0 with testing keywords, and Firefox-153.4.0esr with stable keywords. Thunderbird is identical; Thunderbird-157.0 and Thunderbird-153.4.0esr. Thunderbird releases come immediately after Firefox and sometimes requires TB-specific patches to be added. Firefox recently switched to 2-week release cadence, where it used to be 4 weeks, so the work is now doubled each month. It currently takes me ~20 hours every 2 weeks to do everything related to version bumps (both Firefoxes, both Thunderbirds, Spidermonkey, security bugs...) and I've even skipped a step recently, and am pushing ESR's straight-to-stable (after testing on stable system) to save some time. Most of the hours go into running build-tests, which can be done by leaving the pc to run on its own. There's I'd guess ~3-4 hours of "active" work (without bugs) whenever major releases happen. So there's one less active channel to monitor than what Chromium currently has, but I think handling Thunderbirds make it equal here. Gentoo also offers different variety outside use flags: you have musl, libcxx, different architechtures (arm, x86, riscv) that all require their own quirks. Luckily the power users with these setups know to provide patches, which I then test on glibc and add them if it's ok. Any rust-related issues are somewhat hard to debug, and you can bet there's plenty. Chromium has similar challenges there, but I'd say the nature of Chromium's bundled toolchain vs. system toolchain makes it harder for everyone even with "normal" setup. Gentoo also offers different variety outside use flags: you have musl, libcxx, different architechtures (arm, x86, riscv) that all require their own quirks. Luckily the power users with these setups know to provide patches, which I then test on glibc and add them if it's ok. Any rust-related issues are somewhat hard to debug, and you can bet there's plenty. Chromium has similar challenges there, but I'd say the nature of Chromium's bundled toolchain vs. system toolchain makes it harder for everyone even with "normal" setup. Overall Firefox takes a lot less time to build than Chromium which makes it more bearable. And as sam said, the build system changes affecting us between major releases are usually rather minimal. As the sole Firefox maintainer in Gentoo, I also do feel like there's a bit more community support for Firefox. Often times when a bug for Firefox in Gentoo is filed, I'm not even the first one to reply there. And through collaboration there's been cases where we discovered a bug in GCC directly, which was then fixed in GCC (by GCC developer sam) :) Overall Firefox takes a lot less time to build than Chromium which makes it more bearable. And as sam said, the build system changes affecting us between major releases are usually rather minimal. As the sole Firefox maintainer in Gentoo, I also do feel like there's a bit more community support for Firefox. Often times when a bug for Firefox in Gentoo is filed, I'm not even the first one to reply there. And through collaboration there's been cases where we discovered a bug in GCC directly, which was then fixed in GCC (by GCC developer sam) :) Firefox maintenance Posted Oct 7, 2026 11:10 UTC (Wed) by rwky (subscriber, #119998) [Link] I can understand giving chromium last rites considering how time consuming qt-webengine is it must be a nightmare to compile/test. I'd rather it was shelved and people were encouraged to switch to more developer friendly options. On expectations Posted Oct 6, 2026 15:59 UTC (Tue) by NHO (subscriber, #104320) [Link] (1 responses) On expectations Posted Oct 6, 2026 16:02 UTC (Tue) by NHO (subscriber, #104320) [Link] Packaging Chromium with limited manual effort Posted Oct 6, 2026 16:02 UTC (Tue) by DemiMarie (subscriber, #164188) [Link] (5 responses) Would a package that worked as follows be sustainable? Use the bundled copies of everything, including the prebuilt toolchains. Cross-compile from x86_64 to aarch64. Build with Internet access enabled. Use a powerful build machine. Avoid patching Chromium at all. Automate not only checking when a new version is released, but the entire fetch-build-upload process. This means that updates are shipped with no human intervention. Ship a distro-agnostic container image. That starts to sound a lot like Canonical’s Chromium snap, though. Trivalent would be a good choice, except it only ships RPMs and is only tested on Secureblue. Packaging Chromium with limited manual effort Posted Oct 6, 2026 16:25 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (1 responses) That would make it not a good choice for Gentoo. :) The odd tone of this message makes me think it is LLM-generated. Apologies if it isn't. But, if it is... please don't do that here! :) Packaging Chromium with limited manual effort Posted Oct 6, 2026 17:00 UTC (Tue) by ttuttle (subscriber, #51118) [Link] Packaging Chromium with limited manual effort Posted Oct 7, 2026 20:49 UTC (Wed) by NAR (subscriber, #1313) [Link] (1 responses) Packaging Chromium with limited manual effort Posted Oct 8, 2026 8:14 UTC (Thu) by smurf (subscriber, #17840) [Link] A lot of reasons … known provenance. Less (if any) bundled libraries that already exist on the system. Wider arch support. Debuggability. Removal of anti-features. And so on. Packaging Chromium with limited manual effort Posted Oct 11, 2026 2:15 UTC (Sun) by Kangie (guest, #161139) [Link] Gentoo ebuilds must run offline - it's a requirement for air gapped networks (etc.) Cross compilation is reasonable - it's how upstream produce binaries, but at that point we're talking about building a full set of Chromium binary CI infrastructure.... which is on upstream to provide; we'd happily consume the binary but they don't want it distributed that way to compete with Chrome. > Automate not only checking when a new version is released, but the entire fetch-build-upload process. This means that updates are shipped with no human intervention Part of distro packaging is doing the testing and validation before pushing out a package to your users; you can automate and abstract a lot of that but eventually you need to test your package (or risk shipping a horrible regression). Understandable Posted Oct 6, 2026 15:40 UTC (Tue) by Curan (subscriber, #66186) [Link] (1 responses) I really hope the same fate will never reach Firefox in Debian and I can't thank Mike Hommy enough every day for his work. And often overlooked: the same applies to Thunderbird and its two maintainers (Carsten and Christian). Though, admittedly, part of the issue seems to be the flexibility of Gentoo here. Understandable Posted Oct 7, 2026 8:48 UTC (Wed) by gspr (subscriber, #91542) [Link] AI could help Posted Oct 6, 2026 15:44 UTC (Tue) by cen (subscriber, #170575) [Link] (52 responses) I am not saying distros should start vibe coding but when you pair an experienced package maintainer with a frontier AI agent the maintenance burden becomes much less painful and a lot of things can be done that were previously not possible. Because as it was mentioned in the article, experts in C++, rust, golang and packaging are not just behind every corner but your friendly (or evil, depending who you ask) agent knows all of that and is approaching senior dev levels if not there already. I've already seen first hand certain distro packages being able to advance past years of deadlock and failure with some help from AI and that is a good thing. AI could help Posted Oct 6, 2026 15:48 UTC (Tue) by sam_c (subscriber, #139836) [Link] (3 responses) It also doesn't help the build time issues or lack of cooperation or interest from Google with say, the tarballs missing for periods of time and having to produce our own. Matt Jolly already had used LLMs to write tools for handling some aspects of Chromium, but not the ebuilds and not patches themselves, but e.g. release notifications and aggregating fixed vulnerabilities. I think it extended the time for which keeping Chromium was viable. So maybe you're right in that regard, but not right enough. AI could help Posted Oct 6, 2026 17:29 UTC (Tue) by Baughn (subscriber, #124425) [Link] (2 responses) AI could help Posted Oct 6, 2026 17:46 UTC (Tue) by sam_c (subscriber, #139836) [Link] AI could help Posted Oct 11, 2026 2:41 UTC (Sun) by Kangie (guest, #161139) [Link] I don't have the depth of Rust or C++ knowledge to dig into Crubit and work out how to make it work in a distro context with only stable and released LLVM and Rust for example, and I couldn't trust the output without a lot of validation (and probably spending a lot on tokens for what's supposed to be volunteering.) There's definitely a place and time for the technology, but it's not the solution to every single problem. I'll continue to use LLMs where they make sense, but they're not a silver bullet either; they don't save me from 6+ hours of compilation a week, or from having to actually think about problems. AI could help Posted Oct 6, 2026 16:31 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (6 responses) "I've already seen first hand certain distro packages being able to advance past years of deadlock and failure with some help from AI and that is a good thing." Which ones? And how did "AI" help in those cases? An important aspect to consider is also that a distro is not just it's output. It is also the combined knowledge and wisdom of it's maintainers, and the 'pipeline' that brings on new maintainers. If an LLM is doing all the 'under the hood' work, then the "knowledge" becomes centered within the LLM, not the maintainers, if you're not careful. Cheers. AI could help Posted Oct 6, 2026 16:46 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses) Who will pay for the token use in a volunteer-run distro? Who will pay for the token use in a volunteer-run distro? Most likely, the volunteers. Or their employer. Or some other company who donates GPU time + power. Debian has already acquired one sponsor for inference; there's no reason other distros couldn't do that also. combined knowledge and wisdom of its maintainers, and the 'pipeline' that brings on new maintainers combined knowledge and wisdom of its maintainers, and the 'pipeline' that brings on new maintainers That's one aspect. The other is that, frankly, reconciling patches and writing packaging rules, no matter which distro, is a rather tedious process, and I for one am very happy about the fact that the LLM in my data center handles those chores for me. You still need some expertise, to determine when (not if …) the LLM's output is pure AI slop, of course. But (a) I am not sure that slogging your own unaided way through the process is the best way to gain that, (b) recognizing slop and knowing the intricacies of exactly which stanza does what are not the same skill set. NB: *its. (Both times.) Please. AI could help Posted Oct 6, 2026 18:18 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses) AI could help Posted Oct 7, 2026 7:37 UTC (Wed) by taladar (subscriber, #68407) [Link] AI could help Posted Oct 6, 2026 20:00 UTC (Tue) by cen (subscriber, #170575) [Link] (2 responses) > "I've already seen first hand certain distro packages being able to advance past years of deadlock and failure with some help > from AI and that is a good thing." > > Which ones? And how did "AI" help in those cases? One random example I saw on a mailing list, Debian's gradle package has been stuck at version 4 for years with many people trying to update it and giving up. Recently someone threw AI at it and managed to get a few minor versions further than before. I'm sure there are and will be many more examples out there in the future. >An important aspect to consider is also that a distro is not just it's output. It is also the combined knowledge and wisdom of >it's maintainers, and the 'pipeline' that brings on new maintainers. If an LLM is doing all the 'under the hood' work, then the >"knowledge" becomes centered within the LLM, not the maintainers, if you're not careful. Completely agree. I think we are doomed in that regard. Old guard will start losing knowledge due to over reliance on AI and the convenience factor while the new guard will never acquire the same level of knowledge unless they really care for some reason. Some say that art of software development will slowly be lost which I think is entirely possible. When AI becomes good enough, we become the assembly line workers replaced by robots. AI could help Posted Oct 6, 2026 20:54 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses) Excellent, now we'll have even fewer volunteers to maintain all of this crap. Mission accomplished, I guess? AI could help Posted Oct 6, 2026 21:53 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] Indeed, the goal isn't to help volunteers necessarily. The goal is to make the LLM selling companies more valuable. If volunteers benefit by the currently heavily investor subsidized subscriptions, that is just a temporary cost that LLM selling companies are willing to tolerate to boost their profile that can come out of their growing marketing budget. Nothing to see here, folks. AI could help Posted Oct 6, 2026 17:24 UTC (Tue) by notriddle (subscriber, #130608) [Link] (8 responses) But why is compiling Chromium so difficult in the first place? According to sam_c, Firefox isn’t as bad. Other projects that I would expect to be comparable, like OpenJDK, have caused plenty of drama around bundling, but they still manage to ship working release tarballs. AI could help Posted Oct 6, 2026 18:17 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses) Probably because the Google devs don't bother, they have their own infrastructure with precompiled dependencies and whatnot. working release tarballs working release tarballs Tarballs are not source code. Not since the last decade. A git tag or commit ID, and all that hangs off it, is source code. (Source code: the thing you touch when you modify it.) AI could help Posted Oct 7, 2026 6:50 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses) No. The preferred form for making modifications. You don't modify the whole commit graph, nor do you need it: it's perfectly possible to make modifications after "git clone --depth 1". So tarballs are perfectly fine as source code. And if they were not, all Linux distributions would be violating the GPL/LGPL. AI could help Posted Oct 7, 2026 7:08 UTC (Wed) by mb (subscriber, #50428) [Link] AI could help Posted Oct 9, 2026 5:11 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] (3 responses) As you traverse the industry, most ex-Googlers realize it's just an odd quirk of the company, but a few believers try to carry it over to new Company X... And it rarely works out well. Although I think redfin managed to duplicate the idea, for various definitions of success. And Microsoft Office also did at some point, although, I don't know if the reported day-long builds count as "successfully executed". I had one manager (at old company) that kept trying to convince our team to do it. He kept excitedly reporting how his old company had embraced a monorepo, again and again. Maybe he thought the blank looks he got in response was an indication that he just needed to repeat himself again, and people would go "ah-hah, I see it now". No one ever did. AI could help Posted Oct 9, 2026 10:05 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses) AI could help Posted Oct 9, 2026 23:19 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses) On the balance, monorepos were better from the organizational standpoint. Packages tend to result in dependency hell on every upgrade, with all the issues of ownership, maintenance, etc. Monorepos centralize dependencies, making it easier to do tree-wide changes. I'd say that the main issue with monorepos is tooling. Git is just not designed for that. AI could help Posted Oct 11, 2026 14:20 UTC (Sun) by Wol (subscriber, #4433) [Link] This is why, when I designed the project management system I was working on many moons ago, it was an explicit design goal that the only thing the parent project knew about the subproject was the standard task data. To the parent, the sub was an opaque blob that filled in the standard "this job" task info, and in return read the standard parent task data to find out what resources it had available. Looking at the fun with SHA-1 / SHA-256 in git, I now realise that was probably one heck of an ask (but the company nearly sank before I found that out). If we want a monorepo, we really need to provide some way of telling git "this directory contains a repo with its own git structure, DON'T TOUCH". And some way of exporting the status of that sub-repo up that simply says "this is the live head", with a matching mechanism (maybe manual) of updating the sub-repo to its parent to report "this is the upstream live head" and maybe triggering the subrepo to do its own update/rebuild. Problem is, I think this is going to be a rather tricky problem ... Cheers, Wol AI could help Posted Oct 11, 2026 2:24 UTC (Sun) by Kangie (guest, #161139) [Link] But why is compiling Chromium so difficult in the first place? But why is compiling Chromium so difficult in the first place? Recently ex-downstream package maintainer here. There are a few reasons. Google / upstream only care about their developer workflow. That's understandable - it's their browser, but that means doing things like using system compilers is almost completely unsupported. Google / upstream only care about their developer workflow. That's understandable - it's their browser, but that means doing things like using system compilers is almost completely unsupported. Chromium is huge. It's the largest package that I'm aware of in terms of lines of code. It has tons of vendored dependencies, and the compilers that they're targeting shift regularly (as in, they pick a new rust and llvm commit and start using those). Chromium is huge. It's the largest package that I'm aware of in terms of lines of code. It has tons of vendored dependencies, and the compilers that they're targeting shift regularly (as in, they pick a new rust and llvm commit and start using those). It's huge. I said that, but to put it in perspective, a build with 32 threads, all I/O on ramdisk and no paging can take 3+ hours locally. Google work around this by having a ton of build nodes that you can farm out work to. It's huge. I said that, but to put it in perspective, a build with 32 threads, all I/O on ramdisk and no paging can take 3+ hours locally. Google work around this by having a ton of build nodes that you can farm out work to. Upstream don't really care about consumers. The purpose of Chromium is to support Google Chrome. That's really about it. If their workflow works they don't even notice thousands of CI failures where tarballs stop being generated. Upstream don't really care about consumers. The purpose of Chromium is to support Google Chrome. That's really about it. If their workflow works they don't even notice thousands of CI failures where tarballs stop being generated. AI could help Posted Oct 7, 2026 8:52 UTC (Wed) by gspr (subscriber, #91542) [Link] (31 responses) AI could help Posted Oct 7, 2026 12:40 UTC (Wed) by stijn (subscriber, #570) [Link] (30 responses) AI could help Posted Oct 7, 2026 20:26 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] (29 responses) It is the same as spending a few hours trawling stackoverflow answers or related, but usually compresses into seconds or minutes and a much better interactive experience. It is the same as spending a few hours trawling stackoverflow answers or related, but usually compresses into seconds or minutes and a much better interactive experience. It is not the same as that. In the case of a few hours trawling Stackoverflow, you might learn some useful things you didn't know - even about things tangential to your problem at hand. In those minutes with an LLM, you often only learn that the LLM "knows" and your own understanding is not increased. You also don't get the social and 'gamified' experience of stackoverflow. (And yes, you also don't get slapped by Stackoverflow users, either.) And, of course, you might be inspired to actually answer questions that other humans have, and yours has a chance of being accepted as a good answer. LLMs certainly do not improve the experience of those who answered questions on the StackExchange sites... who now get zero credit for their work. :( For better or worse, StackExchange is a community of humans. LLMs, as used by big-tech capitalists, are just knowledge vacuums that abstract away the humans who actually shared the knowledge. AI could help Posted Oct 8, 2026 8:27 UTC (Thu) by kleptog (subscriber, #1183) [Link] (28 responses) Really? That's not my experience at all. I learn new things from LLMs all the time. I learned this yesterday from a bash script it generated: next=$(printf "%02d" $((10#$h + 1))) Did you know that bash can interpret numbers in different bases? I didn't. The LLMs sometimes come up with different solutions than I would have but it's always fascinating to see what it comes up with. Most of the time they just produce the code I would have written, just faster. > LLMs certainly do not improve the experience of those who answered questions on the StackExchange sites... who now get zero credit for their work. :( Is that the only purpose of SO, so people can get credit? SO only worked in so far as Google could correctly map your question to a SO question, which it did pretty poorly most of the time. That's why it took hours. It seems like you are arguing: you should use crappy tools because in the time wasted you learn more than using helpful tools. Instead of just giving people a hammer you give them a pile of junk and they have to figure out which objects will work best on a nail. AI could help Posted Oct 8, 2026 11:26 UTC (Thu) by pizza (subscriber, #46) [Link] (5 responses) That's one of the main reasons people *answer* stuff on SO. WTF do you think the LLMs have been getting their answers? AI could help Posted Oct 9, 2026 8:24 UTC (Fri) by taladar (subscriber, #68407) [Link] (3 responses) AI could help Posted Oct 10, 2026 1:33 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses) I don't think it was the gamification itself (for me). It was the enforcers of the rules looking for those seeking Fake Internet Points™ by any means to enact punishment. I think they cried wolf far too often, on balance. I've had a better answer to a common SO question for quite some time that I just never bother posting because the current answer is so up-voted to drown my better one out and I don't feel like arguing about it. For those curious, it's that the common "pipe the output of set after running vcvarsall.bat to get the environment you need" fails to account for newlines in values. An environment variable with the value foo\nPATH=hahaha will happily overwrite PATH much to everything after that's sadness. Discovered when an MR description injected environment variable settings into CI that ruined things. The solution is to invoke PowerShell and dump env: as a JSON document and then recover it on the outside as JSON. Go forth and karma farm if you want. AI could help Posted Oct 12, 2026 7:11 UTC (Mon) by taladar (subscriber, #68407) [Link] AI could help Posted Oct 12, 2026 19:55 UTC (Mon) by madscientist (subscriber, #16861) [Link] I had a discussion with some sort of moderator about this, who then suspended me for a week for arguing with them. I've never even logged into my account again, much less answered questions there. AI could help Posted Oct 11, 2026 6:01 UTC (Sun) by ras (subscriber, #33059) [Link] They are definitely biased towards "official" sources - man pages, documentation, RFC's, Python PEP's and the writings and reasoning of people whose names appear on those documents. For example, if you ask an AI (ChatGPT, Claude, Gemini - I tried them all) to give you the references they used for "does bash allow numbers in bases other than 10" they to the man refer you to https://www.gnu.org/software/bash/manual/html_node/Shell-... Stack overflow is definitely ranked below sources like that. I'm suspect it's ranked below most Wikipedia articles too. My guess is what they get from sites like Stack Overflow is how themselves clearly to software engineers. Don't underestimate the value of that - how to express themselves clearly to mathematicians was notable by absence is the recent Mathocalypse paper dump. AI could help Posted Oct 8, 2026 15:38 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (18 responses) AI could help Posted Oct 8, 2026 16:02 UTC (Thu) by marcH (subscriber, #57642) [Link] (2 responses) There are differences but good luck drawing a line that simple and clear between the two. AI could help Posted Oct 8, 2026 16:07 UTC (Thu) by NightMonkey (subscriber, #23051) [Link] (1 responses) However, LLMs do not innovate in that way. They do not 'describe nature' - they are statistical engines that work with probabilities. They don't have a consciousness to make observations with. And the problem with assigning them agency in this way is that it makes it much easier to pull the wool over people's eyes about how they are being used by humans. AI could help Posted Oct 8, 2026 16:20 UTC (Thu) by marcH (subscriber, #57642) [Link] I agree LLMs are not conscious but I don't think anyone mentioned that either before. Another tangent? Trying to go back to the initial topic(s): yes LLMs can totally outclass search engines in some contexts. And yes you learn much less when someone gives you the answer as opposed to struggling - but you don't learn nothing either. What's new here? Derek Muller has a great talk about how no technology has been evolving this learning trade-off despite all of them promising it. AI could help Posted Oct 8, 2026 16:09 UTC (Thu) by marcH (subscriber, #57642) [Link] What is creativity? There is simply no formal definition. People often agree that A is more creative than B but that's it; it's relative. AI could help Posted Oct 8, 2026 17:13 UTC (Thu) by zdzichu (subscriber, #17118) [Link] AI could help Posted Oct 8, 2026 21:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses) From the recent Scott Aaronson: https://scottaaronson.blog/?p=10169 > The UGC proof invents a completely new bizarre code with a noise test. It’s some crazy recursive construction. > It’s not the long code, not the short code – some alien craziness This seems to me like it's creativity. AI could help Posted Oct 9, 2026 10:17 UTC (Fri) by paulj (subscriber, #341) [Link] (5 responses) To quote Scott quoting a mathematician describing the proof, as the mathematical community tries to understand these proofs: "It feels like something written by someone who’s on psychedelics. So much unclear and doesn’t make sense. Lots of name dropping of previous work without discussing why it can be used despite impossibility results" It doesn't seem to be a fact that LLMs have solved loads of old, hard maths problems. Currently it sounds like mathematicians are trying to figure it IF they have OR if LLMs have just spat out a bunch of features learned from prior work it was trained on, composed together in the usual "plausible looking bullshit" way that LLMs excel at. What is the most probable here? AI could help Posted Oct 9, 2026 10:31 UTC (Fri) by stijn (subscriber, #570) [Link] (1 responses) AI could help Posted Oct 10, 2026 12:51 UTC (Sat) by malmedal (subscriber, #56172) [Link] Perfection is not(yet) attainable so the lack of corrections would be highly suspicious. AI could help Posted Oct 9, 2026 10:42 UTC (Fri) by paulj (subscriber, #341) [Link] Well, if so, it's definitely a brave new world we're heading into. AI could help Posted Oct 9, 2026 23:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses) LLM produced the proof in Lean, so it can be automatically verified to be correct. And it is, nobody is arguing with it. But the _way_ it is produced definitely looks like the LLM was on psychodelics. It definitely is a result of very alien creativity. AI could help Posted Oct 10, 2026 12:28 UTC (Sat) by smurf (subscriber, #17840) [Link] LLMs have a really large memory; both short term (basically their context window) and long term (their weights, i.e. a fuzzy image of the training corpus). Humans can keep something like seven ideas at a time in their head … AIs, a couple of thousand or so; we can think about maybe three of these … an AI, 16, or however many attention vectors OpenAI trained their model with. As a human, I basically have to be on psychedelics to even being able to imaging having 16 hands with which to juggle a thousand balls, each different. So, no wonder that's what the output reads like. AI could help Posted Oct 9, 2026 6:50 UTC (Fri) by smurf (subscriber, #17840) [Link] You do understand that, by definition, LLMs do not create anything new. You do understand that, by definition, LLMs do not create anything new. I understand that your definition does not fit the real world. "Real" innovation often happens when people try some random st, just to see what the effects are, and then we keep whatever works and toss out (or even actively advocate against) what does not. Guess what? LLMs have this thing called "temperature" which causes them to do exactly the same thing. AI could help Posted Oct 9, 2026 11:45 UTC (Fri) by kleptog (subscriber, #1183) [Link] (4 responses) None of the code I write is very new, otherwise the answers wouldn't be on SO. It's all of the form: read from interface X, do some data mapping, write to interface Y. It's so stupid an LLM can write it. Not everybody is working on cutting edge software you know. However, I'm not sure I agree that "LLMs can't create anything new" because "new" depends on your point of view. Is mathematics created or discovered? That's a philosophical point, but if you're in the "math is discovered" camp, then mathematicians do not ever create anything new. That doesn't mean it's not useful. > You think 'it' is teaching you something. It is not. The original author(s) of those ideas are teaching you. This makes no sense. I'm learning something, does it really matter where it came from? In the example above it says it in the bash(1) man page if you look for it, I'd just never considered looking for it. Half of knowledge is knowing it is possible. One you know something it possible it changes the way you approach other problems. AI could help Posted Oct 9, 2026 12:22 UTC (Fri) by intelfx (subscriber, #130118) [Link] (3 responses) However, I'm not sure I agree that "LLMs can't create anything new" because "new" depends on your point of view. Is mathematics created or discovered? That's a philosophical point, but if you're in the "math is discovered" camp, then mathematicians do not ever create anything new. That doesn't mean it's not useful. However, I'm not sure I agree that "LLMs can't create anything new" because "new" depends on your point of view. Is mathematics created or discovered? That's a philosophical point, but if you're in the "math is discovered" camp, then mathematicians do not ever create anything new. That doesn't mean it's not useful. Heh, why is this even an argument, let alone a philosophical one? Methinks the answer is blindingly obvious: laws are discovered (what are mathematical laws, if not "natural laws" of interaction of specifically constructed objects?), and proofs are created. AI could help Posted Oct 10, 2026 20:02 UTC (Sat) by cyphar (subscriber, #110703) [Link] (2 responses) There's a whole field of philosophy dedicated to this topic, so a little more intellectual curiousity might be worthwhile. You appear to be in the empricist camp. The common counterargument to empiricism is that physical sciences (which are clearly hypothesis-driven) are inexplicably far more fallible than mathematics. The existence of Lean itself is probably one of the better examples of this -- you can probably use Lean alone to discover and prove new mathematical concepts but you can't do that in physics, chemistry, or biology. AI could help Posted Oct 11, 2026 9:23 UTC (Sun) by intelfx (subscriber, #130118) [Link] (1 responses) so a little more intellectual curiousity might be worthwhile so a little more intellectual curiousity might be worthwhile That’s why I posted (as an invitation to object), so please don’t accuse me of lack of intellectual curiosity of all things, thank you very much. AI could help Posted Oct 12, 2026 8:08 UTC (Mon) by cyphar (subscriber, #110703) [Link] I really am struggling to see how anyone could possible interpret Heh, why is this even an argument, let alone a philosophical one? Methinks the answer is blindingly obvious: ... Heh, why is this even an argument, let alone a philosophical one? Methinks the answer is blindingly obvious: ... as anything other than dismissive. AI could help Posted Oct 15, 2026 15:04 UTC (Thu) by turistu (guest, #164830) [Link] (2 responses) next=$(printf "%02d" $((10#$h + 1))) Did you know that bash can interpret numbers in different bases? next=$(printf "%02d" $((10#$h + 1))) Did you know that bash can interpret numbers in different bases? Yes, it's documented in the manual. Some of us even know that it's possible to inject executable via the $h variable, something that Gemini confidently says it's not possible -- e.g. by setting h='13+q[$(rm -r /just-kidding)]'. BTW, this kind of argument from ignorance / lack of knowledge/imagination is kind of offensive and condescending and makes you sound like a shill, even if your wonder at the marvels of "AI" is genuine. AI could help Posted Oct 15, 2026 16:06 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses) Yes, it's documented in the manual. Yes, it's documented in the manual. Cool, good for you. The person you're replying to didn't, and prompting an LLM taught him that, directly invalidating the great-grand-parent's argument. The fact that you personally happened to spend more time with said manual and did not need this specific piece of knowledge does not invalidate anything said previously. BTW, this kind of argument from ignorance / lack of knowledge/imagination BTW, this kind of argument from ignorance / lack of knowledge/imagination What "argument from ignorance"? An "argument from ignorance" is claiming that something is true or false because of lack of evidence to the contrary. Saying that one learned something valuable by doing X, and therefore X is capable of teaching people something valuable, is not an argument from ignorance. is kind of offensive and condescending is kind of offensive and condescending What is kind of offensive and condescending is your tone and style of communication. You are, of course, free to communicate as you wish, but if you intend to actually win someone over with your ideas or arguments, that tone and style isn't doing you or your ideas any favors. AI could help Posted Oct 16, 2026 2:43 UTC (Fri) by smurf (subscriber, #17840) [Link] prompting an LLM taught him that prompting an LLM taught him that The other interesting point here is that the "10#" prefix to avoid mis-octal-izing a number is really not that common. I mean, yeah we should code defensively and all that, but how often are we just plain lazy (or sloppy) and forget to quote our filenames in shell scripts? The real bug here is of course the fact that the shell word-expands its variables by default in the first place. But we don't have a time machine, thus can't tell Mr. Bourne to not do that. Tarballs? Posted Oct 6, 2026 16:37 UTC (Tue) by smurf (subscriber, #17840) [Link] (2 responses) "They didn't seem to notice or care that it either wasn't producing tarballs or was producing incomplete ones" "They didn't seem to notice or care that it either wasn't producing tarballs or was producing incomplete ones" Yeah, well. Notice that their build instructions do not mention downloading tarballs. Also, why the heck would you want to? links to instructions for Linux (as well as macOS and Windows) return a 503 error links to instructions for Linux (as well as macOS and Windows) return a 503 error They work now — probably 'cause somebody™ read this article. Tarballs? Posted Oct 8, 2026 0:42 UTC (Thu) by tbodt (subscriber, #120821) [Link] Tarballs? Posted Oct 11, 2026 2:29 UTC (Sun) by Kangie (guest, #161139) [Link] Tarballs are the canonical way that Linux distributions get their source code for a particular release. A git clone of Chromium is _massive_ and has overheads versus a tarball that's generated once, for example. A good reason for wanting to use a tarball over a live git repo, even if you're targeting a tag, is working in an offline or air-gapped environment - you want the tarball to contain everything that you need to build the software (except for dependencies). Gentoo isn't alone in using tarballs, and upstream do provide them; they just don't notice when it fails to generate because their CI is entirely based on git (which is fine - it's their workflow) Sad Posted Oct 6, 2026 17:23 UTC (Tue) by maharmstone (subscriber, #174156) [Link] (8 responses) A large part of the problem is, as noted, quite how long Chromium takes to compile: three and a half hours on my beefy machine. It is the slowest package by quite literally a factor of 10. It's ridiculous how much it's ballooned in recent years. Sad Posted Oct 6, 2026 17:44 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses) Sad Posted Oct 6, 2026 18:01 UTC (Tue) by maharmstone (subscriber, #174156) [Link] Sad Posted Oct 7, 2026 13:14 UTC (Wed) by marcH (subscriber, #57642) [Link] (5 responses) Chrome (and all browsers to some extend) are mini-operating systems. Operating systems are big and take a long time to compile. Chrome developers never compile on a single system, they always use advanced caching and remote execution to distribute the build on multiple systems. Which is one more build challenge when you are not a Google employee. Sad Posted Oct 7, 2026 14:15 UTC (Wed) by ceph3 (guest, #164777) [Link] (1 responses) Google build infrastructure Posted Oct 8, 2026 2:17 UTC (Thu) by gutschke (subscriber, #27910) [Link] Sad Posted Oct 8, 2026 5:39 UTC (Thu) by maharmstone (subscriber, #174156) [Link] (1 responses) No - Firefox takes 10 minutes. Chromium is not 20 times more complicated than Firefox. Or if it is, it shouldn't be. Sad Posted Oct 8, 2026 14:52 UTC (Thu) by marcH (subscriber, #57642) [Link] Sad Posted Oct 15, 2026 15:44 UTC (Thu) by turistu (guest, #164830) [Link] Chrome (and all browsers to some extend) are mini-operating systems. Operating systems are big and take a long time to compile. Chrome (and all browsers to some extend) are mini-operating systems. Operating systems are big and take a long time to compile. I still remember a test I did in 2006 or so, where building the entire plan9 OS from scratch (kernel, user-space, compilers, etc) took less time than firefox just starting up. And a) firefox was actually quite snappy, compared to some java-written horrors I had to run and b) half of the time building plan9 was actually spent building the imported ghostscript ;-) Thanks and an alternative Posted Oct 6, 2026 18:08 UTC (Tue) by q3cpma (subscriber, #120859) [Link] (1 responses) A note, ungoogled-chromium is relatively well maintained in the overlay of one of its main devs (https://github.com/PF4Public/gentoo-overlay) and might be an alternative for desperate people. Personally, I can only hope the new wave of browsers (Ladybird, Servo) bring a bit of sanity or at least less historical cruft to our world in the coming years. Guess most of us will have to endure Firefox crumbling under the weight of its piggy-backed foundation full of suits and used car salesmen. Thanks and an alternative Posted Oct 11, 2026 2:30 UTC (Sun) by Kangie (guest, #161139) [Link] https://groups.google.com/a/chromium.org/g/embedder-dev/c... Could this be intentional? Posted Oct 7, 2026 0:05 UTC (Wed) by tlb (subscriber, #178072) [Link] (4 responses) Could this be intentional? Posted Oct 7, 2026 10:13 UTC (Wed) by jengelh (subscriber, #33263) [Link] Any sufficiently large project might also be struggling under its own weight. (too few maintainers for too much existing code and too many submissions) If you're trying to implement/manage everything under the sun, I can see this easily happening. Could this be intentional? Posted Oct 7, 2026 13:24 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses) You've just described Hanlon's razor perfectly. One very rarely ever gets a promotion by fixing the build system. Maybe a bit less unlikely at Google but still nothing like "real" developers working on the actual product as opposed to the infrastructure or test code. One or two years ago when LLMs where not as good as today, I very clearly remember many people describing them as "not great but good enough for test code". Dirty little secret: products don't match specifications, they only match their test coverage. If there's no test coverage or buggy coverage then it does not work. Could this be intentional? Posted Oct 7, 2026 19:41 UTC (Wed) by smurf (subscriber, #17840) [Link] IMHO this is not a matter of promotions. It's a matter of open and bidirectional stewardship of the source code you released into the world … a task which Google is rather bad at. Don't forget that they don't even have a source repository for Chromium / Chrome / whatever. They have a source repository for their private, closed-off corner of the world, thus zero incentive (and, apparently, zero intent) to fix anything they don't need, or want, fixed. I'm not exactly calling this intentional — don't attribute to malice which can adequately explained by stupidity, and all that — but … Could this be intentional? Posted Oct 9, 2026 5:17 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] Google has some non-normal deeply held beliefs about monorepos and dependencies in builds. It's a long-standing thing, before any open-source efforts. I suspect even some ex-googlers would be inclined to attribute it to intentions, so adverse are they to admitting their old company.. might have been wrong about something. But I've ran into several that admit it's just an odd .. quirk .. of the company. Maintain our own CI Posted Oct 7, 2026 6:41 UTC (Wed) by kxxt (subscriber, #172895) [Link] I have been maintaining (unofficial) RISC-V continuous delivery pipeline for electron https://github.com/riscv-forks/electron-riscv-releases and Chromium https://github.com/riscv-forks/chromium-riscv for some time. Setting up a continuous integration workflow greatly helped with that. Currently my CI runs weekly and it helped me to discover bugs that affects RISC-V before it hits a stable release and gives me a chance to open a CL to the gerrit instance so that I (and potentially other packagers of chromium/electron RISC-V) don't need to deal with patching if the CL is submitted before the next major stable version of Chromium branches. But that does not eliminate the maintenance burden (for me). It just brings forward the burden so that I can release Chromium and Electron releases on schedule. For many RISC-V CLs I submitted to the gerrit in the past, most of the time reviewers are responsive and helpful. But the two CLs I opened recently seen no activity from the reviewers. I am not sure what's exactly happening, though. Is there cross-distro collaboration for e.g. unbundling? Posted Oct 7, 2026 9:39 UTC (Wed) by Karellen (subscriber, #67644) [Link] (2 responses) Would anything like that be useful here, or are the packaging systems too diverse (and upstream too active, unlike AOO?) for that to work? Is there cross-distro collaboration for e.g. unbundling? Posted Oct 7, 2026 13:53 UTC (Wed) by smcv (subscriber, #53363) [Link] (1 responses) Is there cross-distro collaboration for e.g. unbundling? Posted Oct 8, 2026 2:15 UTC (Thu) by dilinger (subscriber, #2867) [Link] For debian (and for ubuntu, debxtra packages are available for debian's chromium patches on ubuntu), I predict that we'll be pulling in more and more u-c patches. I would encourage other distributions to do the same. Typical Google software Posted Oct 7, 2026 10:29 UTC (Wed) by cyperpunks (subscriber, #39406) [Link] (2 responses) I really don't understand how such clever Devs can create such chaos in every project, must be nightmare to develop software in such environments. Typical Google software Posted Oct 7, 2026 11:36 UTC (Wed) by pizza (subscriber, #46) [Link] It's a perfect example of Conway's Law in action: "An organization's software architecture will always mirror its internal communication structure and organization chart." Google is a total mess internally, therefore any software it produces will reflect that mess. Typical Google software Posted Oct 7, 2026 13:24 UTC (Wed) by farnz (subscriber, #17727) [Link] Part of it will be that Google has organization-wide tooling (like Blaze, Forge remote execution, Piper/CitC and more) that overcomes the chaos if you're working with Google's internal tooling and Google's internal code review systems. As a result, the huge mess is manageable because the tooling makes it manageable, not because it's a good state for a project. Igalia support? Posted Oct 7, 2026 14:19 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (6 responses) Perhaps funding Igalia to alleviate things like "reliably make source tarballs" would be useful? Any Gentoo-oriented companies that might be in consideration? Though such work helps any distro, really. Igalia support? Posted Oct 7, 2026 16:13 UTC (Wed) by mussell (subscriber, #170320) [Link] The largest deployment of Gentoo as far as I know is ChromeOS, so Google would be the best Gentoo-oriented company to help, but their ebuilds for Chrome don't use tarballs and is otherwise incompatible with Gentoo's www-client/chromium (also ChromeOS is dying). Otherwise I don't think there's that many Gentoo companies that focus on desktops that also care about Chromium support since Firefox has a similar feature set and doesn't take hours to build. Igalia support? Posted Oct 7, 2026 17:55 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] Gentoo's packaging format (ebuilds are Bash!) and documentation makes it quite easy for a person to discover how a package is created and installed and use in other distributions. I can imagine that other distribution's packagers "look over the fence" to see how to get past local packaging problems. Igalia support? Posted Oct 8, 2026 4:15 UTC (Thu) by dilinger (subscriber, #2867) [Link] (3 responses) Igalia support? Posted Oct 10, 2026 1:42 UTC (Sat) by dilinger (subscriber, #2867) [Link] (2 responses) https://groups.google.com/a/chromium.org/g/embedder-dev/c... I can verify a bunch of the things he's laid out. I honestly don't understand how upstream does "release management", because it's like a bunch of the worst practices I've ever seen. I'd encourage everyone who's saying things like "just use AI!" or "have $Company pay for it!" to read that email. It's not just a lack of volunteer/paid hours, it's upstream tossing things out there that simply _don't work_ for various distributions. Igalia support? Posted Oct 10, 2026 3:15 UTC (Sat) by mathstuf (subscriber, #69389) [Link] There seems to have been one champion back in 2014 inspired by a post by spot from 2009 (linked there). Maybe we just need 5 years for this message to provoke progress too? Igalia support? Posted Oct 11, 2026 2:35 UTC (Sun) by Kangie (guest, #161139) [Link] Please do contribute if you have something to add, or even a +1 on the concerns; I don't want to dogpile upstream but the situation they've left us with isn't one that can be easily solved. It's either carry ever-growing reverts or use unreleased LLVM and Rust rolls. :( Ironic Posted Oct 7, 2026 18:29 UTC (Wed) by lwn4096 (subscriber, #177466) [Link] A huge thank-you Posted Oct 9, 2026 5:22 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]