State of the Kernel Self Protection Project

Posted Sep 12, 2016 15:01 UTC (Mon) by pizza (subscriber, #46)
In reply to: State of the Kernel Self Protection Project by PaXTeam
Parent article: State of the Kernel Self Protection Project

> let's review some facts before coming to the conclusion, shall we?

Oooh, yes, let's.

Fact -- Stuff that has been upstreamed is infinitely more useful to general end-users than the stuff that hasn't.
Fact -- You've stated that as-is, PaX is not suitable for upstream and requires a lot of work to do so
Fact -- You've stated that you're not willing to upstream anything.
Fact -- You're complaining that someone else is willing to upstream selected bits or re-implement some of the ideas.

Oh, one more thing:

> there's not a single line of code in PaX that was paid for by somebody. out of the last 16 years i spent over a decade in unemployment to make the necessary amount of free time [...]

Fact -- Your work on PaX has been largely subsidized by other people. Unless you're claiming that you haven't been supported by taxpayers or a spouse/family during this decade of no income?

Conclusions?

If your goal is to repeatedly demonstrate why nobody wants to work with you, you're succeeding admirably.

to post comments

State of the Kernel Self Protection Project

Posted Sep 12, 2016 15:35 UTC (Mon) by PaXTeam (guest, #24616) [Link] (9 responses)

> Fact -- Stuff that has been upstreamed is infinitely more useful to general end-users than the stuff that hasn't.

what does this have to do with people making demands on my own free time? it's also wrong since being upstream != enabled.

> Fact -- You've stated that as-is, PaX is not suitable for upstream and requires a lot of work to do so

nope, what i said was there were parts of PaX that were implemented to minimize my efforts of maintenance which may or may not be what an upstreamable implementation would look like. ironically, some of the stuff that got upstreamed is evidence of upstream devs not realizing this fact.

> Fact -- You've stated that you're not willing to upstream anything.

not on my free time, correct.

> Fact -- You're complaining that someone else is willing to upstream selected bits or re-implement some of the ideas.

wrong, you should probably read and understand what you're replying to. my complaint is that people make *more* demands on my free time and have the guts to blame me when i refuse to do their bidding.

> Fact -- Your work on PaX has been largely subsidized by other people.

got a proof of that fact or shall we call it what it is, a baseless speculation?

> Unless you're claiming that you haven't been supported by taxpayers or a spouse/family during this decade of no income?

it's not really your business but no, that's not what happened, it was all my own savings.

> Conclusions?

your 'facts' speak for yourself quite well i think: thank you for demonstrating what clueless arrogance looks like to the outside world. yes, that's a fact ;).

State of the Kernel Self Protection Project

Posted Sep 12, 2016 16:18 UTC (Mon) by pizza (subscriber, #46) [Link] (8 responses)

> you're basically making demands on me to spend thousands of hours more of my free time on upstreaming my code

I shouldn't have to point out that something requiring "thousands of hours" to upstream, is, by definition, not something that is currently suitable for upstreaming.

> it's not really your business but no, that's not what happened, it was all my own savings.

Fair enough, I retract my statement to that effect. (I have to say that blowing a decade's worth of savings on a vanity project strikes me as being a rather unwise investment, but it's your time and money to do with what you will)

However, I stand by the rest -- You're saying that you're not willing to put forth the effort to upstream things because it's a lot of work, while simultaneously complaining about those who do, and the efforts to document that ongoing work.

If nothing else, it's incredibly boneheaded PR, but I doubt I'm the only one who's reads what you write and concludes that your public attitude demonstrates why you have such long bouts of unemployement.

But hey, it's your time, money, and life. Have at it, you answer only to yourself, and thus only have yourself to blame for the outcome.

State of the Kernel Self Protection Project

Posted Sep 12, 2016 17:22 UTC (Mon) by PaXTeam (guest, #24616) [Link] (4 responses)

> I shouldn't have to point out that something requiring "thousands of hours" to upstream, is, by definition, not something that is currently suitable for upstreaming.

you're wrong, there're many features in the kernel that i'm sure required even more time to get in shape (e.g., -rt, file systems, etc), second, this estimate isn't for a single particular feature but the ones i've heard people express an interest for.

> on a vanity project...

... that fundamentally influenced the entire industry to the point that you've been running code implementing my ideas for over a decade now. as for (not) being an investment, i'm not sure you realize but you're arguing against yourself and saying that i should have asked money from the get go (e.g., via patents, etc) instead of keeping it as a hobby that i gave away for free (gratis, in addition to libre).

> You're saying that you're not willing to put forth the effort to upstream things because it's a lot of work,

no, that's not what i'm saying. let me quote myself back, perhaps it'll sink the second time: not on my free time.

> while simultaneously complaining about those who do, and the efforts to document that ongoing work.

wait, are you saying that i should stop having an opinion just because it happens to be about my own code?

State of the Kernel Self Protection Project

Posted Sep 12, 2016 17:53 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> wait, are you saying that i should stop having an opinion just because it happens to be about my own code?

As the saying goes, "Opinions are like a**holes. Everybody's got one and everyone thinks everyone else's stinks."

State of the Kernel Self Protection Project

Posted Sep 13, 2016 10:25 UTC (Tue) by sdalley (subscriber, #18550) [Link] (2 responses)

pizza, such remarks are unworthy of you.

The opinion of one who has, by the sweat of his brow, produced good working code, (for example, code in wide use by those who care about robust security-hardened kernels), will always be worth a lot more than the opinions of those who snipe from the sidelines.

Any of us would find continual criticism demoralizing. Why not try constructive praise?

State of the Kernel Self Protection Project

Posted Sep 13, 2016 11:35 UTC (Tue) by jubal (subscriber, #67202) [Link] (1 responses)

The opinion of one who has, by the sweat of his brow, produced good working code, (for example, code in wide use by those who care about robust security-hardened kernels), will always be worth a lot more than the opinions of those who snipe from the sidelines.

Perhaps you should address this to the lovely and gentle folks of the PaX fame when they again decide that it's time to talk down the whole kernel community. You might also want to remind them, that they are not the sole authors of the whole kernel, and their contribution, useful and needed as it is, is by far and large not the most important.

State of the Kernel Self Protection Project

Posted Sep 13, 2016 12:49 UTC (Tue) by PaXTeam (guest, #24616) [Link]

jubal, in general, if you have something to tell us/me, you can always address us/me directly.

> Perhaps you should address this to the lovely and gentle folks of the PaX fame when they again decide
> that it's time to talk down the whole kernel community.

first of all, you're trying to judge characters based on a very small sample of interactions which i guess speaks volumes more about yourself, than us. hint: we've worked with various kernel and other developers just fine for as long as our projects existed. you can find the evidence on lkml, bugzillas, distro lists, etc. as far as i recall, the only topic that ended up in flamewars was about high level policy decisions (about the handling of security related issues), which represents a small fraction of the interaction of all participating sides.

as for 'talking down' the whole kernel community, it's of course nonsense (present the evidence if you think otherwise). we did and do criticize people who we find do something stupid and we don't mince words about that either, not unlike certain kernel (and non-kernel) developers by the way. you just have to learn to deal with it.

> You might also want to remind them, that they are not the sole authors of the whole kernel, and their contribution,
> useful and needed as it is, is by far and large not the most important.

and why do we need to be reminded of this again? or was it just a strawman?

State of the Kernel Self Protection Project

Posted Sep 13, 2016 9:23 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Not every technically capable person is adept at soft skills.

Maybe PaXTeam hasn't done the right things to secure funding. Maybe they're not capable of it. However, doesn't the fact we're discussing the work of a paid group to unpick PaXTeam's code and upstream suggest that it might be a good idea to also fund PaXTeam too?

State of the Kernel Self Protection Project

Posted Sep 13, 2016 12:40 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> However, doesn't the fact we're discussing the work of a paid group to unpick PaXTeam's code and upstream suggest that it might be a good idea to also fund PaXTeam too?

A commercial organization is far more likely to fund developers who have a history of pushing code upstream and are not antagonistic with that community of developers. Linux kernel developers have historically not been very welcoming to contributions that harden the kernel and omitting info on vulnerabilities they know about, so it isn't surprising to see that has been a constant source of friction but here we are now.

State of the Kernel Self Protection Project

Posted Sep 13, 2016 16:09 UTC (Tue) by paulj (subscriber, #341) [Link]

Well, of course. However, that doesn't change the fact that in an ideal world some way would be found to fund the developer who did the core work despite that, given that those unpicking that work are being paid.