perf-report's slowness is very frustrating. This slowness started around 2017 or so. However, you can get around it by passing --no-inline and the graphs will be exactly the same.
60x speed-up of Linux “perf”
111–120 of 224 posts
Re: 60x speed-up of Linux “perf”
#112Earlier quoted context omitted.
Kind of ironic that RMS campained against proprietary software to allow reuse of code. Now we have two islands of open source code ... .
RMS advises to use "GPLv2 or any later version", which is compatible with GPLv3, instead of "GPLv2 only" license.
"or any later" is controversial. It essentially puts your project under the agenda of the FSF, which not everyone wants.
Re: 60x speed-up of Linux “perf”
#113Earlier quoted context omitted.
> carefully avoiding making the code too similar to what I happen to remember Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?
The issue is that the only way to guarantee no liability is a clean room implementation. It's why most open source reimplementations require no mention or examination of the source/machine code. Google got dinged over a trivial method they copied in their java implementation, even though it was extremely trivial. You can't risk any chance of copying, regardless of how trivial the code.
Patent and copyright trolls have shown that even a clean room implementation is no guarantee.
Re: 60x speed-up of Linux “perf”
#114Earlier quoted context omitted.
IMO it's not "GPL virality" that is at the root of the issue here. The authors' decision to license theis works this way causes the problem. You can still ask both libraries' authors for relicensing their work in a less restricted / more compatible way. If they don't want to do that, then being authors and owning their copyrights, that's their right to do. That's nothing I would blame on the GPL. I mean we should be…
Can someone ELI5 to me where the problem is because both perf and bfd seem to be GPL. Why would the former not be allowed to link to the latter?
GPLv2 and GPLv3 are difference licences, despite sharing a name. The GNU people (FSF) intentionally made the GPL3 incompatible with GPL2, to enforce the virality of the GPL3 license (which they perceive to be superior to the older GPL2).
Re: 60x speed-up of Linux “perf”
#115Earlier quoted context omitted.
Kind of ironic that RMS campained against proprietary software to allow reuse of code. Now we have two islands of open source code ... .
RMS advises to use "GPLv2 or any later version", which is compatible with GPLv3, instead of "GPLv2 only" license.
One could also suggest that the BFD project adopt "GPLv2 or any later version" (like it had prior to 2008), which is compatible with the GPLv2, instead of the "GPLv3 or any later version" license.
Re: 60x speed-up of Linux “perf”
#116Earlier quoted context omitted.
So what's the solution? You can use a permissive licence which has a huge "backdoor" allowing derivatives to turn up under any licence, including GPLv3 (or v4). Or you can use GPLv2 with no "or later" clause which means you get situations like this.
This incompatibility is a unique feature of GPL. Wherever it goes, it's incompatible with something (in this case, with itself). You could use MPL or CDDL and, as long as GPL isn't involved, you won't have problems with license compatibility. However, in the case of the Linux kernel (which "perf" is distributed with) changing the license is not an option --- no CLA and, even if it was practical to ask so many people…
It's not a feature of GPL, it's an unfortunate side-effect of copyleft. If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.
Re: 60x speed-up of Linux “perf”
#117Earlier quoted context omitted.
This is the comment that points out the issue. perf is licensed under GPL v2 only and libbfd is a GNU tool that is licensed GPL v3 and higher. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815 Really wish the Linux kernel would start mandating new patches to be GPL v2 and higher and get buy in from the largest contributors. A decade later new code would like replace the smaller contributors code and we could c…
You might as well blame GNU for updating from GPLv2+ to GPLv3+, creating the problem in the first place. Since, realistically, neither Linux nor GNU will budge, maybe the practical solution would be to look into integrating with the equivalent library in the LLVM ecosystem (assuming it exists).
It was always clear that gnu would create newer versions of the GPL and start releasing under it. The blame is pretty clearly on the people who editted the license text to be GPL2 only.
Re: 60x speed-up of Linux “perf”
#118So all I am understanding is, we could make linux 10-100 times faster, but licensing-quirks don't allow it? Physical electricity, time and whatnot is wasted because of legal foo?
Re: 60x speed-up of Linux “perf”
#119So all I am understanding is, we could make linux 10-100 times faster, but licensing-quirks don't allow it? Physical electricity, time and whatnot is wasted because of legal foo?
No, you're not understanding it. Perf is a profiling tool. It's slow on Debian because reasons.
Re: 60x speed-up of Linux “perf”
#120So all I am understanding is, we could make linux 10-100 times faster, but licensing-quirks don't allow it? Physical electricity, time and whatnot is wasted because of legal foo?
The GPL requires that software linking to GPL projects are also licensed in GPL. This issue could be solved easily by releasing GPL software, that respects users' freedom.