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

171–180 of 224 posts

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

#171

Post by Dylan16807 »

dvdkhlng wrote: post #9
junon wrote: post #2

Yet another case of GPL virality causing more issues than it solves. E: Downvoters, have you read the article? The program started a new process for each address lookup instead of using a library because that library is GPL. Shall we have a discussion?

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…

The difference in license only matters because of a broad interpretation of virality. The easy way to show this is to mentally replace GPL with LGPL and notice that the problem disappears.

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

#172

Post by Someone »

monocasa wrote: post #142
Macha wrote: post #122

Earlier quoted context omitted.

I think it's acceptable to not want an organisation to be able to relicense your software under arbitrary terms, which the GPL does allow the FSF to do. The GPL 3 is a pretty benign improvement on the GPL 2 (though I know Linus objects to the Tivo clause). I don't think anyone who was happy with their software being used under the terms of GPL 2 would be unhappy with it being used under the terms of the GPL 3 additio…

Sure, but that still means that the fault of not being in the ecosystem falls on the person who specifically edited their license to not be a part of the full ecosystem going forward regardless of whatever reasons they had for doing that.

Calling that a fault shows bias. You could just as well call it a choice.

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

#173

Post by Dylan16807 »

dasyatidprime wrote: post #44
lnxg33k1 wrote: post #36

Earlier quoted context omitted.

The thing is with GPL you have to contribute back, see how much Linux has grown in functionalities and how backwards are other kernels with MIT --- You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable so…

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.

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

#174

Post by touisteur »

scottlamb wrote: post #164
touisteur wrote: post #158

Earlier quoted context omitted.

I'll ask about opensourcing the tool. But just in case, the recipe is to use pipe mode and pre-parse all frames, stream them as messages, sometimes to several targets (pub/sub) with some streaming-zstd, and also splitting the pmu/probes/Intel-PT streams and treating them separately. Stack-traces are analysed (precomputed cfg optimised structure so unwinding is faster) before storing in adhoc in-house format with all…

Sounds more specialized than I was imagining but a cool system. The idea of a more efficient compressed encoding seems generally applicable. I imagine just piping through zstd would be an improvement over plain perf record directly to a file, but it sounds like your tool's splitting makes zstd more effective. It'd be handy to be able to just do perf record ... | fancy-recompress > out, and even better to upstream the…

Well it started working even better when i separated streams and compressed separately pmc and Intel-PT, and syscalls/dynamic probes.

But yes, in a pinch piping to zstd has far less overhead than writing directly to disk.

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

#175

Post by Someone »

p1necone wrote: post #169
anticristi wrote: post #112

Earlier quoted context omitted.

"or any later" is controversial. It essentially puts your project under the agenda of the FSF, which not everyone wants.

Doesn't "GPLv2 or any later version" mean that you can use the software under the terms of GPLv2 or GPLv3 (or some hypothetical GPLv4)? It can't possibly add any restrictions to the use of your project, because people can always just use it under the terms of GPLv2 if they want. I guess it could remove restrictions, if the hypothetical GPLv4 was a total 180 and looked more like the MIT or Apache licenses, so I guess…

If a new version of the GPL adds restrictions, that still can be undesirable for the writer if the original software.

If a third party forks a GPLv2+ project, adding features that are GPLv3+ licensed, the result is GPLv3+ licensed.

That means those wanting the GPLv2 licensed project won’t be able to use those new features.

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

#176

Post by ufo »

Aengeuad wrote: post #154
bostonsre wrote: post #146

Earlier quoted context omitted.

Would that >= license be enforceable in court? It seems lame to create a license that forces you to agree to whatever future license changes come about.

It could go several ways but I can't see a judge wanting to entertain complaints that a new GPL version isn't to your liking if the changes are minor, especially so since it's always going to remain valid in GPLv3. If the FSF goes rogue and changes the GPL to be incredibly restrictive (i.e., allowing proprietary redistribution, and I realise this can be considered permissive..) it might be possible to get it to be ru…

If GPLv4 were more restrictive, people would still be able to use the software under the terms of gplv2 or gplv3.

The scenario where FSF goes "rogue" would be if gplv4 became more permissive, e.g. if it stopped being a copyleft licence.

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

#177

Post by monocasa »

Someone wrote: post #172
monocasa wrote: post #142

Earlier quoted context omitted.

Sure, but that still means that the fault of not being in the ecosystem falls on the person who specifically edited their license to not be a part of the full ecosystem going forward regardless of whatever reasons they had for doing that.

Calling that a fault shows bias. You could just as well call it a choice.

A choice that results in consequences is normally how you assign fault for those consequences.

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

#179

Post by aidenn0 »

medstrom wrote: post #152
joosters wrote: post #148

Earlier quoted context omitted.

This isn't true at all - Linus made the licensing decision in version 0.12 of the kernel, back in 1992! The certainly wasn't any corporate interest in Linux that needed to be protected back then. http://lkml.iu.edu/hypermail/linux/kernel/0009.1/0096.html

TIL, thanks. Guess cui bono isn't a reliable method of deduction.

So you're telling me Chicxulub impact wasn't caused by small mammals?

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

#180

Post by tverbeure »

geofft wrote: post #70
tverbeure wrote: post #66

Earlier quoted context omitted.

I’ve wondered about similar situations. Take Yosys, an open source synthesis platform that allows external commands by adding shred libraries. It’s MIT licensed. There is the Yosys-GHDL plug-in that allows using VHDL instead of Verilog compilation. It’s an independent open source project that can’t be merged into the main Yosys tree because GHDL itself is GPL 2.0. Is the author of that plug-in violating the GHDL lice…

The plugin is potentially a derivative work of both Yosys and GHDL, but that's fine - it's possible to comply with the requirements of both the MIT license and the GPLv2 at the same time. The resulting work is GPLv2-licensed. (To be precise, you also need to preserve any copyright notices from the MIT-licensed project and the text of the MIT license. The MIT license has only one condition, but you do need to follow i…

Your answer and the one from another commenter mention distribution.

In this spirit, is there any legal issue with downloading perf and libbfd separately, compiling it, and running using it for yourself only? I assume not?

What about using it then as a tool within your company? That might be seen as distribution, and thus not allowed?

Post reply on HN