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

Next steps for BPF support in the GNU toolchain

lwn.net

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Next steps for BPF support in the GNU toolchain

#21

Post by loeg »

bawolff wrote: post #17
loeg wrote: post #5

Earlier quoted context omitted.

Copyright applies to literal reproduction of documents; not to ideas. It is straightforwardly allowed to read some implementation of an idea, think about it, and write your own implementation of the same idea.

You're correct that copyright does not apply to ideas only implementations. However if you take an existing implementation and base yours on it, generally the original work's copyright applies (there are a whole lot of details this is skimming over). As an example, if you take a painting someone else made, and try and make your own version using the original as a reference, that is probably subject to the original au…

> I think you're more stating how you would like copyright to work, not how it actually does.

Nope. This is just how it works. I don’t care one way or another.

Re: Next steps for BPF support in the GNU toolchain

#22

Post by ggm »

LegionMammal978 wrote: post #16
mustache_kimono wrote: post #11

Earlier quoted context omitted.

> It's of course not ridiculous. I have the feeling you're arguing against and about something I never said. To clarify, I'll restate: "I believe Linus has even opined that any filesystem which was developed after Linux, whose developers are aware of Linux, could be considered a 'derived work'. [The view that any new filesystem, simply aware of, but created independent of , and after Linux, is a derived work of Linux…

I agree, some of the Linux people have a very broad notion of what counts as a derived work, but I haven't seen much in the way of actual case law to support the conclusion that "white box reverse engineering is generally illegal". Software generally receives wide protection for its 'non-literal elements', but it's not the case that every possible iota of its function falls under its protectable expression. Indeed, p…

Linux/Linus is not the FSF, hence the FSF insistence on referring to gnu/Linux.

Re: Next steps for BPF support in the GNU toolchain

#23

Post by netbsdusers »

bayindirh wrote: post #7
loeg wrote: post #5

Earlier quoted context omitted.

Copyright applies to literal reproduction of documents; not to ideas. It is straightforwardly allowed to read some implementation of an idea, think about it, and write your own implementation of the same idea.

IBM published its initial BIOS code in a manual bundled with the PC. Having any knowledge of it, even if you don't implement it verbatim makes you tainted , and makes you guilty in any of the subsequent cases. This is why Black Box Reverse Engineering Exists . Same is true for console reverse engineering. No self respecting reverse engineer reads code leaks from official console development. Otherwise they'd be in a…

There's no legal concept called "tainting". Black boxing is just a means by which you try to make yourself completely irreproachable (for if you haven't seen something, then it's outright impossible that you copied it). It obviously doesn't follow that the converse is true. If it were, musicians would not listen to other's music nor would painters look at other's paintings!

Re: Next steps for BPF support in the GNU toolchain

#24

Post by schoen »

netbsdusers wrote: post #23
bayindirh wrote: post #7

Earlier quoted context omitted.

IBM published its initial BIOS code in a manual bundled with the PC. Having any knowledge of it, even if you don't implement it verbatim makes you tainted , and makes you guilty in any of the subsequent cases. This is why Black Box Reverse Engineering Exists . Same is true for console reverse engineering. No self respecting reverse engineer reads code leaks from official console development. Otherwise they'd be in a…

There's no legal concept called "tainting". Black boxing is just a means by which you try to make yourself completely irreproachable (for if you haven't seen something, then it's outright impossible that you copied it). It obviously doesn't follow that the converse is true. If it were, musicians would not listen to other's music nor would painters look at other's paintings!

The part that they're trying to avoid is the "access" in "access and substantial similarity"

https://en.wikipedia.org/wiki/Substantial_similarity

(usual factual elements in determining the possibility of a copyright infringement in U.S. law).

I agree with you that it's possible in principle that copyright infringement would not be found even when there was evidence of access. But I think the courts would usually give the defendant a higher burden in that case. You can see in the Wikipedia article that there has been debate about whether access becomes more relevant when the similarity is greater and less relevant when the similarity is less (apparently the current Ninth Circuit standard on that is "no"?).

Re: Next steps for BPF support in the GNU toolchain

#25

Post by phiresky »

tremon wrote: post #14
inoffensivename wrote: post #13

I wish these articles would have a one sentence description of what BPF stands for. It would help passers-by.

Alternatively, the use of BPF without explanation signals that the article is a deep-dive and not intended for random passers-by. I don't support the position that every article should be written to cater to the lowest common denominator. The first line of the article: > Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended BPF. Should the article also explain which kernel the…

I disagree, you can always spend one or two sentences at the top to immediately bring everyone to a good starting point, regardless of how much technical depth the rest of the article has.

For example in this case: "eBPF is a method for user space to add code to the running Linux kernel without compromising security. They have been tied [...]. The GNU toolchain, the historical and still by many preferred system to build Linux currently has no support.

The description of what LWN and Linux is would be in the about page linked in the article.

It costs almost nothing for an expert to skim/skip two sentences while saving loads of time for everyone else.

The article is also completely missing motivation (why do we care whether BPF is supported in the second toolchain?) Which would be helpful for almost everyone, including people who think it is obvious.

Edit: To be clear though, I love LWN. But the articles are very often missing important context that would be easy to add that I suspect would help a large portion of the reader base.

Re: Next steps for BPF support in the GNU toolchain

#26

Post by cassepipe »

inoffensivename wrote: post #13

I wish these articles would have a one sentence description of what BPF stands for. It would help passers-by.

Here is what I gathered without really ever checking.

It's a safe script that has access to part of the kernel and that unlocks a lot of monitoring. You could use a kernel module that's much unwieldy, error-prone etc.

How correct am I ?

Re: Next steps for BPF support in the GNU toolchain

#27

Post by tuna74 »

ggm wrote: post #22
LegionMammal978 wrote: post #16

Earlier quoted context omitted.

I agree, some of the Linux people have a very broad notion of what counts as a derived work, but I haven't seen much in the way of actual case law to support the conclusion that "white box reverse engineering is generally illegal". Software generally receives wide protection for its 'non-literal elements', but it's not the case that every possible iota of its function falls under its protectable expression. Indeed, p…

Linux/Linus is not the FSF, hence the FSF insistence on referring to gnu/Linux.

FSF/Stallman wanted the whole OS (Grub + Linux + Glibc + SysV init + ...) called Gnu/Linux.
Post reply on HN