Brief items

Some people enter the technology industry to build newer, more exciting kinds of technology as quickly as possible. My keynote will savage these people and will burn important professional bridges, likely forcing me to join a monastery or another penance-focused organization. In my keynote, I will explain why the proliferation of ubiquitous technology is good in the same sense that ubiquitous Venus weather would be good, i.e., not good at all. Using case studies involving machine learning and other hastily-executed figments of Silicon Valley's imagination, I will explain why computer security (and larger notions of ethical computing) are difficult to achieve if developers insist on literally not questioning anything that they do since even brief introspection would reduce the frequency of git commits. At some point, my microphone will be cut off, possibly by hotel management, but possibly by myself, because microphones are technology and we need to reclaim the stark purity that emerges from amplifying our voices using rams' horns and sheets of papyrus rolled into cone shapes. I will explain why papyrus cones are not vulnerable to buffer overflow attacks, and then I will conclude by observing that my new start-up papyr.us is looking for talented full-stack developers who are comfortable executing computational tasks on an abacus or several nearby sticks.

Imagining the worst scenario with the most stupid user doesn't prove anything. We have sensible users who want to achieve security. Our job is to design processes that help them with that goal.

So this merge window has been horrible.

This issue was fixed fairly quickly, because you really don't want to be in a situation where drunk people would have financial motivation to pour liquids on high voltage equipment in crowded rooms. This is not a problem one has to face in most data centers.

Flexibility sits on a scale between fragile and robust. The trick is working out how many footguns are appropriate to leave around our distribution.

I understand and accept that the sponsorship of this kids football team is unusual. I will not be voting for every such request. [...]

I consider this one decision an opportunity to see if we get any traction or interest from putting our logo prominently in an unusual place. And I think that's a worthwhile idea - after all we're not going to attract new blood with totally new ideas to the Project if we only advertise ourselves in the usual places.

Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.

It didn't take long to find many sections of code from similar blog posts. Almost all of the blog posts either wrote a disclaimer or should have written one. They all solved one small piece of a problem, but took many liberties in their solution to make it simpler to read. It's understandable. Most readers appreciate brevity when learning a concept.

The code from these blog posts had spread through the codebase like a disease, scattering issues here and there without any rhyme or reason. And there wasn't any obvious cure other than to read everything manually and fix issues as I went along. Without unit tests or automated deployments, this took almost a year. I'm almost certain the cost of fixing the code exceeded the margin on revenue due to writing it in the first place.