Brief items

The notion that software engineers are not responsible for things that go wrong will be laid to rest for good, and we will have to work out how to develop and maintain code that will go on working dependably for decades in environments that change and evolve. And as security becomes ever more about safety rather than just privacy, we will have sharper policy debates about surveillance, competition, and consumer protection.

On Tuesday, researchers reported attackers are abusing a previously obscure method that delivers attacks 51,000 times their original size, making it by far the biggest amplification method ever used in the wild. The vector this time is memcached, a database caching system for speeding up websites and networks. Over the past week, attackers have started abusing it to deliver DDoSes with volumes of 500 gigabits per second and bigger, DDoS mitigation service Arbor Networks reported in a blog post.

Do you think that lack of safety is a _good_ thing?

Do you realize that most of the lack of safety is almost directly about flexibility, simplicity, and good code generation?

But what if I told you that some of the lack of safety doesn't actually add to flexibility, simplicity, _or_ good code generation? Wouldn't you say "we don't want it to be unsafe" then?

I'm literally telling you that lack of variable initialization is almost purely a bad thing. C would be a safer language, with less undefined behavior, if it just made the initialization of automatic variables be something you cannot avoid.

On the other hand, such activities must always be oriented to compliance, and compliance only. Collecting huge amounts of contractual penalties is questionable. And if it was necessary to collect such huge amounts to motivate large corporations to be compliant, then this must be done in the open, with the community knowing about it, and the proceeds of such contractual penalties must be donated to free software related entities to prove that personal financial gain is not a motivation.