It is a headline bait though, the twitterverse likes to only read headlines and judge things on that. I intentionally chose the title so that people on Twitter taking it out of context would look ridiculous.
Yes, so much I understood, but donāt you think that with a title like that yourāre somewhat betraying the reader. Probably the next time you post, Iāll not so eager read your post. Just my two cents.
āFor a developer, the hardening effort could be a great boon, in that
it could show nasty bugs early, it could make them easier to report,
and it could add a lot of useful information to that report that makes
them easier to fix too.ā
This is actually one of the point fans of Design-by-Contract have been making since it takes you right to the bug. Memory-safe languages can prevent them. You donāt see Linus adopting many things like that in this quest to squash all the bugs. I say heās mostly talking.
Now, letās say I tried to commit something with hardening. He wants it to show the bug with a report. It can sometimes be obvious where something was hit but not always. So, a app gets hit with a non-obvious one eventually triggering some containment code. Iām guessing the Linux kernel already has support for pulling the code and data in the app from memory to analyze it in a way that shows where the attack is? Or does he expect me to dump all of that in a file to pull off the machine for manual analysis? Or just the writable parts in memory? Iām just wondering whatās standard in terms of support infrastructure for those doing it his way. There could even be opportunities to design mitigations around it.
You donāt see Linus adopting many things like that in this quest to squash all the bugs. I say heās mostly talking.
I say this a lot whenever the new userspace rant crops up.
And not even in the context of memory safe languages. Itās far more basic than that. Linux doesnāt really have an extensive set of API/regression tests or a test infrastructure.
Without any of that, ādonāt break userspaceā is completely hollow. Itās really ādonāt let me see you breaking userspaceā; if folks actually cared about that that much then they would test for it.
This is also why I mostly consider attempts to rewrite linux in a safer language premature; without good testing itās just not going to be doable.
Browsers are quite similar to operating systems in many ways (specifically, that they expose a large API/ecosystem within which you can program, and have a huge base of programs written for them). Browsers have extensive tests which go everywhere from testing the basic behavior of a feature to its million edge cases, including ānobody should write code that relies on this but weāre going to test it anywayā edge cases. When we did the Stylo work for Firefox a large, possibly majority, component of the work was just getting all these tests to pass, because we had lots of edge cases we missed. I canāt even begin to imagine how weād do it without tests. I canāt even begin to imagine how a project like Linux would do it without tests.
I didnāt know they were lacking a test infrastructure. Yeah, thatās even worse than what I was saying. I especially like your characterization here:
āWithout any of that, ādonāt break userspaceā is completely hollow. Itās really ādonāt let me see you breaking userspaceā; if folks actually cared about that that much then they would test for it.ā
Yeah, this stuff is Linusā ego until they get tests or contracts helping ensure that behavior. I also remember CompSci people bug-hunting the APIās had problems due to under or no specification of some components. They had to reverse engineer it a bit while they did the formal specs. They all found bugs, too.
I expected a little testing like that. Manishearth and Iās point is that this is a huge, critical project with more contributors than most whose leader is supposedly all about protecting the stability of the userspace. Yet, thereās no testing infrastructure for doing that. Yet, smaller projects and startups routinely pull that off for their growing codebases.
So, Linus is a hypocrite to not be doing what he can on testing side. Thereās also a benefit to submitters where they could run the tests to spot breaks before submitting.
When I saw that the company on the āreceivingā end of the receivership is Pivotal Solutions my hopes went up since I thought they were some branch of Pivotal, but that doesnāt seem to be the case :(
Not at all what I expected as a post. I figured there would be much more political argument clarifying the title. Oh well.
I am working on a larger rant on cargo culting Google, but I have to build up more satire juice to get on the level of this
That article is a thing of beauty š
Yeah, the subtitle was a 180 for me. At least it was there to let me know what it was actually about, though.
Same. I want a reason to hate it, I have an irrational distaste towards it for some reason
For me itās all the yaml.
Look at the bright side, at least it isnāt a clickbait.
It is a headline bait though, the twitterverse likes to only read headlines and judge things on that. I intentionally chose the title so that people on Twitter taking it out of context would look ridiculous.
Yes, so much I understood, but donāt you think that with a title like that yourāre somewhat betraying the reader. Probably the next time you post, Iāll not so eager read your post. Just my two cents.
Wellā¦ of course? Am I missing something here?
Itās proprietary software distributed by Microsoft.
āFor a developer, the hardening effort could be a great boon, in that it could show nasty bugs early, it could make them easier to report, and it could add a lot of useful information to that report that makes them easier to fix too.ā
This is actually one of the point fans of Design-by-Contract have been making since it takes you right to the bug. Memory-safe languages can prevent them. You donāt see Linus adopting many things like that in this quest to squash all the bugs. I say heās mostly talking.
Now, letās say I tried to commit something with hardening. He wants it to show the bug with a report. It can sometimes be obvious where something was hit but not always. So, a app gets hit with a non-obvious one eventually triggering some containment code. Iām guessing the Linux kernel already has support for pulling the code and data in the app from memory to analyze it in a way that shows where the attack is? Or does he expect me to dump all of that in a file to pull off the machine for manual analysis? Or just the writable parts in memory? Iām just wondering whatās standard in terms of support infrastructure for those doing it his way. There could even be opportunities to design mitigations around it.
I say this a lot whenever the new userspace rant crops up.
And not even in the context of memory safe languages. Itās far more basic than that. Linux doesnāt really have an extensive set of API/regression tests or a test infrastructure.
Without any of that, ādonāt break userspaceā is completely hollow. Itās really ādonāt let me see you breaking userspaceā; if folks actually cared about that that much then they would test for it.
This is also why I mostly consider attempts to rewrite linux in a safer language premature; without good testing itās just not going to be doable.
Browsers are quite similar to operating systems in many ways (specifically, that they expose a large API/ecosystem within which you can program, and have a huge base of programs written for them). Browsers have extensive tests which go everywhere from testing the basic behavior of a feature to its million edge cases, including ānobody should write code that relies on this but weāre going to test it anywayā edge cases. When we did the Stylo work for Firefox a large, possibly majority, component of the work was just getting all these tests to pass, because we had lots of edge cases we missed. I canāt even begin to imagine how weād do it without tests. I canāt even begin to imagine how a project like Linux would do it without tests.
I didnāt know they were lacking a test infrastructure. Yeah, thatās even worse than what I was saying. I especially like your characterization here:
āWithout any of that, ādonāt break userspaceā is completely hollow. Itās really ādonāt let me see you breaking userspaceā; if folks actually cared about that that much then they would test for it.ā
Yeah, this stuff is Linusā ego until they get tests or contracts helping ensure that behavior. I also remember CompSci people bug-hunting the APIās had problems due to under or no specification of some components. They had to reverse engineer it a bit while they did the formal specs. They all found bugs, too.
Itās not like the kernel doesnāt get tested, though: https://stackoverflow.com/a/3180642/942130
I expected a little testing like that. Manishearth and Iās point is that this is a huge, critical project with more contributors than most whose leader is supposedly all about protecting the stability of the userspace. Yet, thereās no testing infrastructure for doing that. Yet, smaller projects and startups routinely pull that off for their growing codebases.
So, Linus is a hypocrite to not be doing what he can on testing side. Thereās also a benefit to submitters where they could run the tests to spot breaks before submitting.
He seems to have been found: https://twitter.com/MabbsSec/status/893166585736724481
https://securityintelligence.com/the-father-of-zeus-kronos-malware-discovered/
http://www.telegraph.co.uk/technology/2017/08/03/fbi-arrests-wannacry-hero-marcus-hutchins-las-vegas-reports/
:( Whatās the status of Riak?
When I saw that the company on the āreceivingā end of the receivership is Pivotal Solutions my hopes went up since I thought they were some branch of Pivotal, but that doesnāt seem to be the case :(
I read somewhere else that Erlang Solutions was going to carry on support.