{"id":42148,"date":"2024-02-16T14:14:40","date_gmt":"2024-02-16T19:14:40","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42148"},"modified":"2024-02-20T13:47:30","modified_gmt":"2024-02-20T18:47:30","slug":"on-the-insecurity-of-software-bloat","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/02\/16\/on-the-insecurity-of-software-bloat\/","title":{"rendered":"On the Insecurity of Software Bloat"},"content":{"rendered":"

Bert Hubert<\/a> (via Hacker News<\/a>):<\/p>\n

The really short version: the way we build\/ship software these days is mostly ridiculous, leading to 350MB packages that draw graphs<\/a>, and simple products importing 1600 dependencies of unknown provenance<\/a>. Software security is dire, which is a function both of the quality of the code and the sheer amount of it. Many of us know the current situation is untenable. Many programmers (and their management) sadly haven’t ever experienced anything else. And for the rest of us, we rarely get the time to do a better job.<\/p>

In this post I briefly go over the terrible state of software security, and then spend some time on why it is so bad. I also mention some regulatory\/legislative things going on that we might use to make software quality a priority again. Finally, I talk about an actual useful piece of software I wrote<\/a> as a reality check of the idea that one can still make minimal and simple yet modern software<\/a>.<\/p>\n

I hope that this post provides some mental and moral support for suffering programmers and technologists who want to improve things. It is not just you, we are not merely suffering from nostalgia: software really is very weird today.<\/p><\/blockquote>\n\n

Niklaus Wirth<\/a>:<\/p>\n

\n

Reducing complexity and size must be the goal in every step—in system specification, design, and in detailed programming. A programmer's competence should be judged by the ability to find simple solutions, certainly not by productivity measured in “number of lines ejected per day.” Prolific programmers contribute to certain disaster.<\/p>\n

[…]<\/p>\n

With Project Oberon we have demonstrated that flexible and powerful systems can be built with substantially fewer resources in less time than usual. The plague of software explosion is not a “law of nature.” It is avoidable, and it is the software engineer’s task to curtail it.<\/p>\n<\/blockquote>\n\n

See also: Bert Hubert<\/a> (via Bruce Schneier<\/a>).<\/p>\n\n

Previously:<\/p>\n