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, <[email protected]> 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 > [email protected] > https://gtalug.org/mailman/listinfo/talk >
--- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
