8 ms·

Fedora stupidly uses beta compiler in new release, Torvalds blindly upgrades, makes breaking, unreviewed changes in kernel, then flames the maintainer who was w

Fedora stupidly uses beta compiler in new release, Torvalds blindly upgrades, makes breaking, unreviewed changes in kernel, then flames the maintainer who was working on cleanly updating the kernel for the not-yet-released compiler? I admire Kees Cook's patience.

eb0la 1y ago
IMHO Cook is following good development practices. You need to know what you support. If you are going to change, it must be planned somehow. I find Torwalds reckless by changing his development environment before release. If he really needs that computer to release the kernel, it must be stable one. Even better: it should be a VM (hosted somewhere) or part of a CI-CD pipeline.
- evgpbfhnr 1y ago
  He releases rc every single week (ok, except before rc1 there's two weeks for merge window), there's no "off" time to upgrade anywhere. Not that I approve the untested changes, I'd have used a different gcc temporarily (container or whatever), but, yeah, well...
  - jaapz 1y ago
    I find it surprising that linus bases his development and release tools based on whatever's in the repositories at that time. Surely it is best practice to pin to a specified, fixed version and upgrade as necessary, so everyone is working with the same tools? This is common best practice in many environments... Linus surely knows this, but here he's just being hard headed.
    - IsTom 1y ago
      People downloading and compiling the kernel will not be using a fixed version of GCC.
      - charcircuit 1y ago
        Why not specify one?
        mort96 1y ago
        What would that help? People use the compilers in their distros, regardless of what's documented as a supported version in some readme.
        GTP 1y ago
        Because then, if something that is expected to compile doesn't compile correctly, you know that you should check your compiler version. It is the exact same reason why you don't just specify which library your project depends on but also the libraries' version.
        leenify 1y ago
        That can work, but it can also bring quite a few issues. Mozilla effectively does this; their build process downloads the build toolchain, including a specific clang version, during bootstrap, i.e., setting up the build environment. This is super nice in theory, but it gets murky if you veer off the "I'm building current mainline Firefox path". For example, I'm a maintainer of a Firefox fork that often lags a few versions behind. It has substantial changes, and we are only two guys doing the major work, so keeping up with current changes is not feasible. However, this is a research/security testing-focused project, so this is generally okay. However, coming back to the build issue, apparently, it's costly to host all those buildchain archives. So they get frequently deleted from the remote repository, which leads to the build only working on machines that downloaded the toolchain earlier (i.e., not Github action runner, for example). Given that there are many more downstream users of effectively a ton of kernel versions, this quickly gets fairly expensive and takes up a ton of effort unless you pin it to some old version and rarely change it. So, as someone wanting to mess around with open source projects, their supporting more than 1 specific compiler version is actually quite nice.
        1y ago
- hyperpape 1y ago
  I'm completely unsure whether to respond "it was stable, he was running a release version of Fedora" or "there's no such thing as stable under Linux". The insanity is that the Kernel, Fedora and GCC are so badly coordinated that the beta of the compiler breaks the Kernel build (this is not a beta, this is a pre-alpha in a reasonable universe...is the Kernel a critical user of GCC? Apparently not), and a major distro packages that beta version of the compiler. To borrow a phrase from Reddit: "everybody sucks here" (even Cook, who looks the best of everyone here, seems either oblivious or defeated about how clownshoes it is that released versions of major linux distros can't build the Kernel. The solution of "don't update to release versions" is crap). (Writing this from a Linux machine, which I will continue using, but also sort of despise).
- ploxiln 1y ago
  The real problem here was "-Werror", dogmatically fixing warnings, and using the position of privilege to push in last-minute commits without review. Compilers will be updated, they will have new warnings, this has happened numerous times and will happen in the future. The linux kernel has always supported a wide range of compiler versions, from the very latest to 5+ years old. I've ranted about "-Werror" in the past, but to try to keep it concise: it breaks builds that would and should otherwise work. It breaks older code with newer compiler and different-platform compiler. This is bad because then you can't, say, use the exact code specified/intended without modifications, or you can't test and compare different versions or different toolchains, etc. A good developer will absolutely not tolerate a deluge of warnings all the time, they will decide to fix the warnings to get a clean build, over a reasonable time with well-considered changes, rather than be forced to fix them immediately with brash disruptive code changes. And this is a perfect example why. New compiler fine, new warnings fine. Warnings are a useful feature, distinct from errors. "-Werror" is the real error.
  - mort96 1y ago
    With or without -Werror, you need your builds to be clean with the project's chosen compilers. Linux decided, on a whim, that a pre-release of GCC 15 ought to suddenly be a compiler that the Linux project officially uses, and threw in some last-minute commits straight to main, which is insane. But even without -Werror, when the project decides to upgrade compiler versions, warnings must be silenced, either through disabling new warnings or through changing the source code. Warnings have value, and they only have value if they're not routinely ignored. For the record, I agree that -Werror sucks. It's nice in CI, but it's terrible to have it enabled by default, as it means that your contributors will have their build broken just because they used a different compiler version than the ones which the project has decided to officially adopt. But I don't think it's the problem here. The problem here is Linus's sudden decision to upgrade to a pre-release version of GCC which has new warnings and commit "fixes" straight to main.
  - llm_nerd 1y ago
    This is my take-away as well. Many projects let warnings fester until they hit a volume where critical warnings are missed amidst all the noise. That isn't ideal, but seems to be the norm in many spaces (for instance the nodejs world where it's just pages and pages of warnings and deprecations and critical vulnerabilities and...). But pushing breaking changes just to suppress some new warning should not be the alternative. Working to minimize warnings in a pragmatic way seems more tenable.
josefx 1y ago
> makes breaking, unreviewed changes in kernel, And reverted them as soon as the issue became apparent. > then flames the maintainer who was working on cleanly updating the kernel for the not-yet-released compiler? Talking aboutchanges that he had not pushed by the time Linus published the release candidate. Also the "not yet released" seems to be a red herring, as the article notes having beta versions of compilers in new releases is a tradition for some distros, so that should not be unexpected. It makes some sense since distros tend to stick to a compiler for each elease, so shipping a soon to be out of maintenance compiler from day one will only cause other issues down the road.
- Kwpolska 1y ago
  Fedora releases are supported for about 13 months after release. They could live with an older version of GCC for a year.
  - Denvercoder9 1y ago
    > They could live with an older version of GCC for a year. That's just not what Fedora is, though. Being on the bleeding edge is foundational to Fedora, even if it's sometimes inconvenient. If you want battle-tested and stable, don't run Fedora, but use Debian or something.
    - Kwpolska 1y ago
      Bleeding-edge is fine, but shipping a beta C compiler seems a bridge too far. Even Arch does not ship GCC 15 yet.
rwmj 1y ago
The GCC 15 transition has been very disruptive, but Fedora is known for being on the bleeding edge ("first" is in the "four foundations" [1]). Be glad because eventually everyone will get GCC 15, and we've worked out most of the problems for you already. [1] https://docs.fedoraproject.org/en-US/project/ https://docs.fedoraproject.org/en-US/project/
- genewitch 1y ago
  Do you work in marketing
- stefan_ 1y ago
  GCC 15.1 was released today. Your Fedora release was two weeks earlier, now using a nonexistent version of 15.0.1, ironically now including bugs you reported and that were fixed for 15.1. That just seems like poor decision making.
  - rwmj 1y ago
    You're belittling the large amount of work done across thousands of packages to get them ready for GCC 15, which did involve backporting fixes to GCC 15 itself. All those fixes went into GCC upstream. GCC 15.1 was released two hours ago as of writing this message, even before the US wakes up, yet I'm sure there will be a build of it in Fedora later today.
    - blueflow 1y ago
      Creating the fake release for gcc was by no means necessary for that.
    - rwmj 1y ago
      GCC 15.1 building: https://koji.fedoraproject.org/koji/buildinfo?buildID=2705125 https://koji.fedoraproject.org/koji/buildinfo?buildID=270512...
- deleted 1y ago
  [deleted]
JoshTriplett 1y ago
Exactly. As quoted in the article: > you didn't coordinate with anyone. You didn't search lore for the warning strings, you didn't even check -next where you've now created merge conflicts. You put insufficiently tested patches into the tree at the last minute and cut an rc release that broke for everyone using GCC <15. You mercilessly flame maintainers for much much less. Hypocrisy is an even worse trait than flaming people.
- genewitch 1y ago
  On the one hand, sure, fine. He has raked people for less. However this is just an RC. Further, how long has Linus been doing this? I remember Maddox on xmission having a page explaining that while he may make a grammatical error from time to time, he has published literally hundreds of thousands of words, and the average email he receives contains 10% errors. However, Linus is well-known for being abrasive, abusive, call it what you want. If you can't take it, don't foist it, Linus. Even if you've earned the right, IMO.
  - 7bit 1y ago
    Nobody earns the right to be an asshole. That is nothing that can be earned.
    - wizzwizz4 1y ago
      I'd say if you're doing truly-heroic solo efforts, then you can earn that. (But I can only think of fictional examples.) For team efforts like the Linux kernel, sure, no amount of individual contribution to that project grants you the right to belittle the other contributors.
      - nick__m 1y ago
        Fabrice Bellard as earned that right but somehow I don't think he is !
        1y ago

eb0la 1y ago

IMHO Cook is following good development practices. You need to know what you support. If you are going to change, it must be planned somehow. I find Torwalds reckless by changing his development environment before release. If he really needs that computer to release the kernel, it must be stable one. Even better: it should be a VM (hosted somewhere) or part of a CI-CD pipeline.

evgpbfhnr 1y ago
He releases rc every single week (ok, except before rc1 there's two weeks for merge window), there's no "off" time to upgrade anywhere. Not that I approve the untested changes, I'd have used a different gcc temporarily (container or whatever), but, yeah, well...
- jaapz 1y ago
  I find it surprising that linus bases his development and release tools based on whatever's in the repositories at that time. Surely it is best practice to pin to a specified, fixed version and upgrade as necessary, so everyone is working with the same tools? This is common best practice in many environments... Linus surely knows this, but here he's just being hard headed.
  - IsTom 1y ago
    People downloading and compiling the kernel will not be using a fixed version of GCC.
    - charcircuit 1y ago
      Why not specify one?
      - mort96 1y ago
        What would that help? People use the compilers in their distros, regardless of what's documented as a supported version in some readme.
        GTP 1y ago
        Because then, if something that is expected to compile doesn't compile correctly, you know that you should check your compiler version. It is the exact same reason why you don't just specify which library your project depends on but also the libraries' version.
      - leenify 1y ago
        That can work, but it can also bring quite a few issues. Mozilla effectively does this; their build process downloads the build toolchain, including a specific clang version, during bootstrap, i.e., setting up the build environment. This is super nice in theory, but it gets murky if you veer off the "I'm building current mainline Firefox path". For example, I'm a maintainer of a Firefox fork that often lags a few versions behind. It has substantial changes, and we are only two guys doing the major work, so keeping up with current changes is not feasible. However, this is a research/security testing-focused project, so this is generally okay. However, coming back to the build issue, apparently, it's costly to host all those buildchain archives. So they get frequently deleted from the remote repository, which leads to the build only working on machines that downloaded the toolchain earlier (i.e., not Github action runner, for example). Given that there are many more downstream users of effectively a ton of kernel versions, this quickly gets fairly expensive and takes up a ton of effort unless you pin it to some old version and rarely change it. So, as someone wanting to mess around with open source projects, their supporting more than 1 specific compiler version is actually quite nice.
        1y ago
hyperpape 1y ago
I'm completely unsure whether to respond "it was stable, he was running a release version of Fedora" or "there's no such thing as stable under Linux". The insanity is that the Kernel, Fedora and GCC are so badly coordinated that the beta of the compiler breaks the Kernel build (this is not a beta, this is a pre-alpha in a reasonable universe...is the Kernel a critical user of GCC? Apparently not), and a major distro packages that beta version of the compiler. To borrow a phrase from Reddit: "everybody sucks here" (even Cook, who looks the best of everyone here, seems either oblivious or defeated about how clownshoes it is that released versions of major linux distros can't build the Kernel. The solution of "don't update to release versions" is crap). (Writing this from a Linux machine, which I will continue using, but also sort of despise).
ploxiln 1y ago
The real problem here was "-Werror", dogmatically fixing warnings, and using the position of privilege to push in last-minute commits without review. Compilers will be updated, they will have new warnings, this has happened numerous times and will happen in the future. The linux kernel has always supported a wide range of compiler versions, from the very latest to 5+ years old. I've ranted about "-Werror" in the past, but to try to keep it concise: it breaks builds that would and should otherwise work. It breaks older code with newer compiler and different-platform compiler. This is bad because then you can't, say, use the exact code specified/intended without modifications, or you can't test and compare different versions or different toolchains, etc. A good developer will absolutely not tolerate a deluge of warnings all the time, they will decide to fix the warnings to get a clean build, over a reasonable time with well-considered changes, rather than be forced to fix them immediately with brash disruptive code changes. And this is a perfect example why. New compiler fine, new warnings fine. Warnings are a useful feature, distinct from errors. "-Werror" is the real error.
- mort96 1y ago
  With or without -Werror, you need your builds to be clean with the project's chosen compilers. Linux decided, on a whim, that a pre-release of GCC 15 ought to suddenly be a compiler that the Linux project officially uses, and threw in some last-minute commits straight to main, which is insane. But even without -Werror, when the project decides to upgrade compiler versions, warnings must be silenced, either through disabling new warnings or through changing the source code. Warnings have value, and they only have value if they're not routinely ignored. For the record, I agree that -Werror sucks. It's nice in CI, but it's terrible to have it enabled by default, as it means that your contributors will have their build broken just because they used a different compiler version than the ones which the project has decided to officially adopt. But I don't think it's the problem here. The problem here is Linus's sudden decision to upgrade to a pre-release version of GCC which has new warnings and commit "fixes" straight to main.
- llm_nerd 1y ago
  This is my take-away as well. Many projects let warnings fester until they hit a volume where critical warnings are missed amidst all the noise. That isn't ideal, but seems to be the norm in many spaces (for instance the nodejs world where it's just pages and pages of warnings and deprecations and critical vulnerabilities and...). But pushing breaking changes just to suppress some new warning should not be the alternative. Working to minimize warnings in a pragmatic way seems more tenable.

josefx 1y ago

> makes breaking, unreviewed changes in kernel, And reverted them as soon as the issue became apparent. > then flames the maintainer who was working on cleanly updating the kernel for the not-yet-released compiler? Talking aboutchanges that he had not pushed by the time Linus published the release candidate. Also the "not yet released" seems to be a red herring, as the article notes having beta versions of compilers in new releases is a tradition for some distros, so that should not be unexpected. It makes some sense since distros tend to stick to a compiler for each elease, so shipping a soon to be out of maintenance compiler from day one will only cause other issues down the road.

Kwpolska 1y ago
Fedora releases are supported for about 13 months after release. They could live with an older version of GCC for a year.
- Denvercoder9 1y ago
  > They could live with an older version of GCC for a year. That's just not what Fedora is, though. Being on the bleeding edge is foundational to Fedora, even if it's sometimes inconvenient. If you want battle-tested and stable, don't run Fedora, but use Debian or something.
  - Kwpolska 1y ago
    Bleeding-edge is fine, but shipping a beta C compiler seems a bridge too far. Even Arch does not ship GCC 15 yet.

rwmj 1y ago

The GCC 15 transition has been very disruptive, but Fedora is known for being on the bleeding edge ("first" is in the "four foundations" [1]). Be glad because eventually everyone will get GCC 15, and we've worked out most of the problems for you already. [1] https://docs.fedoraproject.org/en-US/project/ https://docs.fedoraproject.org/en-US/project/

genewitch 1y ago
Do you work in marketing
stefan_ 1y ago
GCC 15.1 was released today. Your Fedora release was two weeks earlier, now using a nonexistent version of 15.0.1, ironically now including bugs you reported and that were fixed for 15.1. That just seems like poor decision making.
- rwmj 1y ago
  You're belittling the large amount of work done across thousands of packages to get them ready for GCC 15, which did involve backporting fixes to GCC 15 itself. All those fixes went into GCC upstream. GCC 15.1 was released two hours ago as of writing this message, even before the US wakes up, yet I'm sure there will be a build of it in Fedora later today.
  - blueflow 1y ago
    Creating the fake release for gcc was by no means necessary for that.
  - rwmj 1y ago
    GCC 15.1 building: https://koji.fedoraproject.org/koji/buildinfo?buildID=2705125 https://koji.fedoraproject.org/koji/buildinfo?buildID=270512...
deleted 1y ago
[deleted]

JoshTriplett 1y ago

Exactly. As quoted in the article: > you didn't coordinate with anyone. You didn't search lore for the warning strings, you didn't even check -next where you've now created merge conflicts. You put insufficiently tested patches into the tree at the last minute and cut an rc release that broke for everyone using GCC <15. You mercilessly flame maintainers for much much less. Hypocrisy is an even worse trait than flaming people.

genewitch 1y ago
On the one hand, sure, fine. He has raked people for less. However this is just an RC. Further, how long has Linus been doing this? I remember Maddox on xmission having a page explaining that while he may make a grammatical error from time to time, he has published literally hundreds of thousands of words, and the average email he receives contains 10% errors. However, Linus is well-known for being abrasive, abusive, call it what you want. If you can't take it, don't foist it, Linus. Even if you've earned the right, IMO.
- 7bit 1y ago
  Nobody earns the right to be an asshole. That is nothing that can be earned.
  - wizzwizz4 1y ago
    I'd say if you're doing truly-heroic solo efforts, then you can earn that. (But I can only think of fictional examples.) For team efforts like the Linux kernel, sure, no amount of individual contribution to that project grants you the right to belittle the other contributors.
    - nick__m 1y ago
      Fabrice Bellard as earned that right but somehow I don't think he is !
      - 1y ago