Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

60x speed-up of Linux “perf”

eighty-twenty.org

Post reply on HN
Print view View original

191–200 of 224 posts

Re: 60x speed-up of Linux “perf”

#191

Post by fhaldridge7 »

mistrial9 wrote: post #104
saurik wrote: post #96

FINALLY AN ACTUAL ANSWER!! :D I had done a bunch of research into this a while ago and filed an issue with the Ubuntu bug tracker, but was told it was due to ABI stability (which did not make any sense). https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 Understanding that there is actually an underlying license problem is like finally being told all of the reasons for everything that happened on LOST ;P.

> This bug affects 3 people (!)

I'm sure it affects more people than that. Not everyone who experiences this bug is going to create an account on the ubuntu launchpad platform and write a comment about it

Re: 60x speed-up of Linux “perf”

#192

Post by tanjor »

I do know Boost.Stacktrace calls addr2line too. From the code(https://github.com/boostorg/stacktrace/blob/develop/include/...), it seems Boost.Stacktrace also shells out to addr2line for every address. But in practice, I found the overhead of boost::stacktrace::stacktrace() is not as horrendous as my crappy implementation, which calls addr2line, too. Is there something I missed in Boost's code?

Re: 60x speed-up of Linux “perf”

#193

Post by dasyatidprime »

Dylan16807 wrote: post #173
dasyatidprime wrote: post #44

Earlier quoted context omitted.

The GPL doesn't require “contributing back”. You can't just give out binaries without source, but you can choose not to release anything . The thing is, as usage models shift to include a lot of what the FSF very reasonably relabels SaaSS (Service as a Software Substitute), you can release nothing but provide the functionality over the network and reasonably expect people to use it that way. Since you haven't distrib…

> very reasonably relabels SaaSS (Service as a Software Substitute) Heck no. "as a" already means that. Rewriting the acronym is far more petty than reasonable.

They both contain both elements, but the point is to sharply alter the emphasis. “Software as a Service” is a reasonable description in the salience model of the mainstream software industry, because it is something that you choose and integrate and use like software, except it just so happens to be a service, coming with various costs like subscription fees and very direct vulnerability to upstream changes, and various benefits like installation and maintenance functions being centralized far away where you don't have to directly manage them.

“Service as a Software Substitute” pushes the ‘service’ part to be the most salient. It depicts something which is fundamentally a service, where ‘substitute’ once more emphasizes that you do not, in fact, have the software itself, even though it is taking the role of software. The FSF considers this very important, because they wish users to be able to copy and modify the software they use, and pseudo-distribution purely as a service does not naturally allow for this. If that is not something you care about, then the emphasis will seem strange, yes.

Re: 60x speed-up of Linux “perf”

#194

Post by garaetjjte »

lathiat wrote: post #46
ziml77 wrote: post #27

Earlier quoted context omitted.

Is it just me or is the incompatibility especially absurd given that perf is currently using libbfd, just 1 step removed via addr2line? I wonder if a patch to addr2line would be accepted which allows the executable to stay running to accept multiple requests through stdin.

This is kind of the crux of a long history of these licensing arguments. That dynamic linking is problematic because it potentially creates a derived work. And then you might distribute that derived work. But shelling out to something or in some cases having an automated script create or download the derived work automatically is sometimes acceptable. It’s a bit of a silly line in some ways. But it’s a long story.

There's also interpretation that merely linking with compatible interface would be infringing even without distributing two parts together (curiously, used by Stallman): https://news.ycombinator.com/item?id=26606328

Re: 60x speed-up of Linux “perf”

#195

Post by thisisinterest »

saurik wrote: post #96

FINALLY AN ACTUAL ANSWER!! :D I had done a bunch of research into this a while ago and filed an issue with the Ubuntu bug tracker, but was told it was due to ABI stability (which did not make any sense). https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894407 Understanding that there is actually an underlying license problem is like finally being told all of the reasons for everything that happened on LOST ;P.

Perhaps you should add a link to this article as a comment in that ubuntu bug tracker. That way it's useful for others who have the same question.

Re: 60x speed-up of Linux “perf”

#196

Post by saurik »

tyree731 wrote: post #143
saurik wrote: post #98

Earlier quoted context omitted.

The AGPL licenses are explicitly compatible with the GPL ones. FWIW, this issue is essentially entirely caused by Linus, who refuses to use or accept GPL3.

> FWIW, this issue is essentially entirely caused by Linus, who refuses to use or accept GPL3. That's a bit disingenuous. Linus has said no to the GPLv3, yes, but his reasons for doing so have merit.

Linus's reasons for causing this issue having merit does not mean he wasn't entirely the cause of the issue: those are unrelated axes.

Re: 60x speed-up of Linux “perf”

#197

Post by spockz »

LeoPanthera wrote: post #140
faho wrote: post #3

> Michał Sidor suggests building against libbfd, something that the Debian maintainers don’t want to do. "don't want to" isn't quite correct - they can't . Perf is licensed under the GPLv2, libbfd under the GPLv3. The licenses are incompatible, which makes the combination unredistributable - which is what Debian would be doing with it. Debian is legally not allowed to do this.

Debian could provide a tool which builds it for you, on your system, right? The resulting binary would not be redistributable but you could use it. I've often wondered why more linux distros don't provide a similar tool to build ZFS into the kernel for you.

So this means the distributor can fix this by building this package locally and use the result to link other binaries to? This isn’t uncommon right?

Re: 60x speed-up of Linux “perf”

#198

Post by canadianfella »

monocasa wrote: post #117
jabl wrote: post #102

Earlier quoted context omitted.

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.

No way. Letting someone else change your license is dumb.

Re: 60x speed-up of Linux “perf”

#199

Post by marcthe12 »

thayne wrote: post #63
faho wrote: post #56

Earlier quoted context omitted.

This... is some weirdness in Arch's clang package. It depends on gcc, for some reason, and that depends on binutils? (and I have no idea if anything here uses libbfd, since it's just a part of the binutils package and not split out)

Maybe it depends on gcc so it can use gcc's assebler for inline assembly?

no its for linking. basically clang unless configured in the source it does not know what link options to give. Actually even rust uses gcc or clang to do same thing.

Re: 60x speed-up of Linux “perf”

#200

Post by josefx »

globular-toast wrote: post #116
yakubin wrote: post #59

Earlier quoted context omitted.

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.

> If you have a better way to "disable" copyright than copyleft then I'm sure it would supersede the GPL.

In absence of copyright anyone could publish binaries build on GPL code without sharing the sources. So a central feature of the GPL would cease to be if copyright was in any way disabled. Saying the GPL is about disabling copyright is about as true as McDonalds being about healthy diets.

Post reply on HN