Apparently no discussion on Linux-Libre mailing list of Linux ensloppification risk.
I'm kind of wondering if there's any plan there.
I'm kind of wondering if there's any plan there.
Timeline
Post
Remote status
Context
17
I agree that by integrating slop into GPLed codebases, there are risks of adding code that could be derivative of GPL-incompatible code, and that would spell trouble to that who integrated it and to everyone downstream.
I expect that, if it happens, we (Linux-libre) would be in a position of unintended infringement, we wouldn't be hit first, and as soon as Linux puts its act together, we'd inherit the fix.
if third parties go about notifying us and terminating our licenses over infringement of the integrated bits, they will apply to those bits, not to the fixed upstream version.
if Linux copyright holders go about notifying and terminating licenses over the unauthorized combination with GPL-incompatible code, we'd get the grace period that the Linux community imported from GPLv3 to inherit the fixed codebase, so we should be fine.
overall it doesn't strike me as intolerable legal risk
it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel. if it brings slop in it, it would only be of concern if that turned out to be nonfree (no license or incompatible license) or otherwise FSDG-incompliant. the former case would likely be handled upstream before we even knew about it. the latter would be up to ourselves, but it's hard to even imagine something like that coming up from slop.
CC: @sally@freesoftwareextremist.com
I expect that, if it happens, we (Linux-libre) would be in a position of unintended infringement, we wouldn't be hit first, and as soon as Linux puts its act together, we'd inherit the fix.
if third parties go about notifying us and terminating our licenses over infringement of the integrated bits, they will apply to those bits, not to the fixed upstream version.
if Linux copyright holders go about notifying and terminating licenses over the unauthorized combination with GPL-incompatible code, we'd get the grace period that the Linux community imported from GPLv3 to inherit the fixed codebase, so we should be fine.
overall it doesn't strike me as intolerable legal risk
it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel. if it brings slop in it, it would only be of concern if that turned out to be nonfree (no license or incompatible license) or otherwise FSDG-incompliant. the former case would likely be handled upstream before we even knew about it. the latter would be up to ourselves, but it's hard to even imagine something like that coming up from slop.
CC: @sally@freesoftwareextremist.com
@lxo @lispi314
> it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel
Yeah, I guessed it'd be this approach because that's also the same treatment Rust codebase gets even though can't be bootstrapped and every relevant compiler is proprietary, and the Rust issue is far worse and more concerning than garbage printer code snippets.
> it sucks to carry slop though, but as sally said, our goal is to make minimal changes to Linux to get an FSDG-compliant kernel
Yeah, I guessed it'd be this approach because that's also the same treatment Rust codebase gets even though can't be bootstrapped and every relevant compiler is proprietary, and the Rust issue is far worse and more concerning than garbage printer code snippets.
@newt @sally @lxo I do not actually have the relevant skills to implement a full compliant Ada compiler in anything resembling a reasonable amount of time.
Given I *rarely* work on resource-constrained low-level projects my actual need for it is fairly light.
I care because instead we have this spec-less thing being merged into the kernel.
(This makes implementation diversity a nightmare.)
The most "reasonable" way to do it, given the language is fairly large at this point, would be to pick up an old version and then chain bootstrap from GNATs built from it.
It is still hardly trivial. Ada, unlike C, was not designed for ease of implementation.
As for why no one else has done it since? Few people cared about reproducible builds until fairly recently. Now there is enough interest for an nlnet project to do so to actually get funded (which also provides a vague idea of how much labor one might expect to be involved in that).
Given I *rarely* work on resource-constrained low-level projects my actual need for it is fairly light.
I care because instead we have this spec-less thing being merged into the kernel.
(This makes implementation diversity a nightmare.)
The most "reasonable" way to do it, given the language is fairly large at this point, would be to pick up an old version and then chain bootstrap from GNATs built from it.
It is still hardly trivial. Ada, unlike C, was not designed for ease of implementation.
As for why no one else has done it since? Few people cared about reproducible builds until fairly recently. Now there is enough interest for an nlnet project to do so to actually get funded (which also provides a vague idea of how much labor one might expect to be involved in that).
while that is true, it, erhm, used to be truer
I recall having a conversation with a former customer about that some 20 years ago, when ICC was aiming at GCC compatibility to be able to compile Linux, and that wasn't even close to viable, to the point of looking impossible
yet now clang, that came into existence later than ICC, has caught up with all that baggage that used to be GCC only
besides, a number of features that used to be GCC extensions have been standardized and can now be taken for granted with many more compilers
it makes for a much more interesting and competitive landscape
CC: @sally@freesoftwareextremist.com @lispi314@udongein.xyz
I recall having a conversation with a former customer about that some 20 years ago, when ICC was aiming at GCC compatibility to be able to compile Linux, and that wasn't even close to viable, to the point of looking impossible
yet now clang, that came into existence later than ICC, has caught up with all that baggage that used to be GCC only
besides, a number of features that used to be GCC extensions have been standardized and can now be taken for granted with many more compilers
it makes for a much more interesting and competitive landscape
CC: @sally@freesoftwareextremist.com @lispi314@udongein.xyz
@lxo @newt @sally @lispi314 The reason why clang quickly caught up with GCC is because it needed to replace old gcc on multiple systems after the GPLv3 relicense. It probably had millions thrown at it at this point. If that relicense never happened, clang wouldn't be where it is today and llvm most certainly wouldn't be as popular.
@phnt @sally @lxo @lispi314 not exactly. Even without the relicence, gcc was lagging due to 
mental retardation. For one, he was vehemently against stabilising the intermediate representation in GCC (the gimple) and making GCC modular (splitting the backend into a library), for the fears that the evil corpos will employ parts of GCC in their proprietary IDEs. The unholy abominations like gccxml were attempts to do exactly that without 
approval.
If you have ever wondered why L'Eunuchs development tooling is so mindbogglingly inadequate and why Windows had proper autocomplete and an integrated build system in MSVS in since 90s while gnutards were stuck with emacs, this is the reason. One man's crusade to infect the world with his particular strain of rectally flavoured software-obsessed cretinism.
In other words, LLVM was inevitable.
mental retardation. For one, he was vehemently against stabilising the intermediate representation in GCC (the gimple) and making GCC modular (splitting the backend into a library), for the fears that the evil corpos will employ parts of GCC in their proprietary IDEs. The unholy abominations like gccxml were attempts to do exactly that without approval.If you have ever wondered why L'Eunuchs development tooling is so mindbogglingly inadequate and why Windows had proper autocomplete and an integrated build system in MSVS in since 90s while gnutards were stuck with emacs, this is the reason. One man's crusade to infect the world with his particular strain of rectally flavoured software-obsessed cretinism.
In other words, LLVM was inevitable.
@newt @sally @lxo @lispi314
>For one, he was vehemently against stabilising the intermediate representation in GCC (the gimple) and making GCC modular (splitting the backend into a library), for the fears that the evil corpos will employ parts of GCC in their proprietary IDEs. The unholy abominations like gccxml were attempts to do exactly that without
approval.
This is still the case where gcc devs can't stop changing the diagnostics format every few releases and refuse to provide a way to output AST from the frontend. gcc is utterly useless in anything besides compiling a project. Which is why everyone uses clang and/or treesitter for that. Once again the usual shoot-yourself-in-the-foot.
>For one, he was vehemently against stabilising the intermediate representation in GCC (the gimple) and making GCC modular (splitting the backend into a library), for the fears that the evil corpos will employ parts of GCC in their proprietary IDEs. The unholy abominations like gccxml were attempts to do exactly that without
approval.
This is still the case where gcc devs can't stop changing the diagnostics format every few releases and refuse to provide a way to output AST from the frontend. gcc is utterly useless in anything besides compiling a project. Which is why everyone uses clang and/or treesitter for that. Once again the usual shoot-yourself-in-the-foot.
@lispi314 @sally @lxo @newt Depends, a compiler has unique insight to the code it is trying to compile and can give more accurate diagnostics and help with it. Clang will yell at you by default for implicit fallthroughs I think when used as an LSP, but GCC doesn't care unless you set -Wimplicit-fallthrough I think.
With treesitter, it's similar but since it just parses it into an AST, there's less things to be different.
With treesitter, it's similar but since it just parses it into an AST, there's less things to be different.
Replies
1@phnt @sally @lxo @newt Going by the manual I think Wimplicit-fallthrough might explicitly be about silencing the warning.
edit: No, nevermind, the documentation just needs fixing because it's unclear as written. It clarifies lower but if one checks the direct option itself and is scrolled up just wrong? Easy to miss.
edit2: Also, Wextra sets it as a bundle.