[GTALUG] Dan Kaminsky Bugs aren't random ...

[David Thornton]

Conjecture:

Developers are the worker bees, they don't decide what gets done. The
business decides what get's done. They are the expressers of morals and
values. They can choose to cow-tow to the market or standup for something
at odds with the crowd.

Classically businesses have operated with a short-sighted, reductionist,
"externalization of cost" mind set.

The cycle is roughly one employment term in length.  You just gotta push
the cost off to the next cohort and make off like a bandit myself. ( either
to the next hustle or retirment. )

Show me a peice of software you use for greater than 10 years and I'll show
you a peice of software that's starting to mature ( windows, chrome, linux?
).

Sometimes maturity only comes through the death of the parent ( klang, v8 ).

David






David Thornton @northdot9 https://wiki.quadratic.net

On Sat, Aug 11, 2018, 10:48 AM Russell Reiter via talk, <talk at gtalug.org>
wrote:

> Nice talk on the physics of power management in the most recent shared
> cache exploits. Defcon 26 was held in China this year.
>
> https://www.youtube.com/watch?v=f3cyCg7itOI
>
> Dan says;
> It can take looking at a few thousand bugs, but eventually hacking feels
> like getting really good at telling the same joke, over and over again.
> It's OK, the computer still laughs, but why isn't software engineering
> delivering the reliability and predictability of other engineering
> disciplines? That's a question with an answer. It's not an easy answer,
> like "devs are lazy" or "tools are bad". Who are hackers to complain about
> either? But it's an answer I intend to explore, in true hacker fashion, by
> seeing traditional boundaries as mostly false, but useful for identifying
> what to fuzz. Why should we separate the humans that write bugs, from the
> tools the tools they use? Humans write tools. Why these tools in
> particular? Why would we separate forward and reverse engineering, dev from
> test? Wait, are those the same thing? Does any other field isolate the
> creator from the consequences of their creation? Is this going to be just
> some fluffy exploratory keynote? No, this is way too long a flight for
> that. We're going to talk about where I think software and hardware
> architecture is going to go, with actual code you're welcome to try to
> break. I'll tell you exactly where to look.
> ---
> Talk Mailing List
> talk at gtalug.org
> https://gtalug.org/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180814/b58e8657/attachment.html>