Bloat is still software's biggest vulnerability (2024)

I thought about this several years ago and I think I hit the right balance with these 2 rules of thumb:

* The closer something is to your core business, the less you externalize.

* You always externalize security (unless security is your exclusive core business)

Say you are building a tax calculation web app. You use dependencies for things like the css generation or database access. You do not rely on an external library for tax calculation. You maintain your own code. You might use an external library for handling currencies properly, because it's a tricky math problem. But you may want to use your own fork instead, as it is close to your core business.

On the security side, unless that's your speciality, there's guys out there smarter than you and/or who have dedicated more time and resources than you to figure that stuff out. If you are programming a tax calculation web app you shouldn't be implementing your own authentication algorithm, even if having your tax information secure is one of your core needs. The exception to this is that your core business is literally implementing authentication and nothing else.

Now, with systems like npm, maven or cargo, all you need to do to get a package is to add a line in a configuration file

They can't hack what doesn't exist.

Reducing surface area is sometimes the easiest security measure one can take.

How many vulnerabilities were due to badly reinventing the wheel in C/C++ though?

Also, people often complain about "bloat", but don't realize that C/C++ are often the most bloated ones precisely because importing libraries is a pain, so they try to include everything in a single library, even though you only need to use less than 10% of it. Look for example at Qt, it is supposed to be a UI framework but it ends up implementing vectors, strings, json parser and who knows how much more stuff. But it's just 1 dependency so it's fine, right?

In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant.

I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.

This is something that I think about constantly and I have come to the same conclusion. While the idea of being able to trivially share code worldwide is appealing, so far it seems to encourage shittier software more than anything else, and the benefit of sharing trivially seems to be defeated by the downsides that bloat and bad software bring with it. Adding friction to code re-use (by means of having to manually download shit from a website and compile it yourself like it's 1995) seems to be a good thing for now until a better package management system is figured out. The friction forces you to think seriously where you actually need that shit or you can write the subset of the functionality you need yourself. To be clear, I also think C++ projects suffer a lot from re-inventing the wheel, particularly in the gamedev world, but that seems to be less worse than, e.g., initializing some nodejs framework project and starting with 100+ dependencies when you haven't even started to write shit.

When you "Reinvent the wheel", you implement only what you need in an optimized way.

This gives a couple of advantages: you own your code, no bloat, usually simpler due to not having all the bells and whistles, less abstraction, so faster because there is no free lunch, minimize the attack surface for supply chain attacks...

For fun, the next time you are tempted to install a BlaZiNg FaSt MaDe in RuSt software: get the source, install cargo audit and run the cargo audit on that project.

See how many vulnerabilities there are. So far, in my experience, all the software I checked come with their list of vulnerabilities from transitive dependencies.

I don't know about npm, I only know by reputation and it's enough for me to avoid.

Writing everything from scratch by hand is an insane take. It is not just reinventing the wheel but there are whole frameworks one should use because writing that thing on your own will take you a lifetime.

Yes you should not just pull as dependency thing that kid in his parents basement wrote for fun or to get OSS maintainer on his CV.

But there are tons of legitimate libraries and frameworks from people who are better than you at that specific domain.

100, ha! The official rust docs, built in rust, use ~750 dependencies - queue the apoligists

No. What you described is known as technical debt.

Bloat affects the end user, and it's a loose definition. Anything that was planned, went wrong, and affects user experience could be defined as bloat (many toolbars like Office had, many purposes like iTunes had, etc).

Bloat and technical debt are related, but not the same. There is a lot of software that has a very clean codebase and bloated experience, and vice-versa.

Speed is an ambiguous term. It is often better to think in terms of real performance and user-perceived performance.

For example, many Apple UX choices prioritize user perceived performance instead of real performance. Smooth animations to cover up loading times, things such as that. Their own users don't even know why, they often cannot explain why it feels smooth, even experienced tech people.

Things that are not performant but appear to be fast are good examples of good user-perceived performance.

Things that are performant but appear to be slow exist as well (fast backend lacking proper cache layer, fast responses but throttled by concurrent requests, etc).

> At the distro level, it is ridiculous that so long after Alpine Linux, the chasm between them and Debian/RHEL remains. A minimal Linux install shouldn’t be 1GB…

I would say this is a feature and not a bug. Alpine Linux is largely designed to be run in containerized environments so you can have an extremely small footprint cause you don't have to ship stuff like a desktop or really anything beyond the very very basics.

Compare that to Ubuntu which for the 5GB download is the "Desktop" variant that comes with much more software

Alpine's biggest hurdle is musl. Most of the software still relies on libc. You should look into unikernels [0], it's the most slimmed down version of linux that you can ship. I am not sure how different a unikernel is from a distroless image tho

[0] - https://unikraft.org/

> Want a simple web server ? Well, you’re going to get something with a JSON parser, PAM authentication, SSL, QUIC, websockets, an async framework, database for https auth, etc.

Simple means different things for different people it seems. For a simple web server you need a tcp socket.

If you want a full featured high performance web server, it's not gonna be simple.

I think we lost something with static linking when going from C to Dotnet. (And I guess Java.) Many C (and C++, especially "header only") libraries when statically linked are pretty good at filtering out unused code.

Bundling stuff in Dotnet are done much more "runtime" often both by design of the library (it uses introspection¹) and the tools².

1: Simplified argument - one can use introspection and not expect all of the library to be there, but it's trickier.

2: Even when generating a self contained EXE, the standard toolchain performs no end-linking of the program, it just bundles everything up in one file.

>A minimal Linux install shouldn’t be 1GB

Why not this seems pretty arbitrary. Seemingly developer time or functionality would suffer to achieve this goal. To what end?

Who cares how many floppies grub would require when its actually running on a 2TB ssd. The actually simpler thing is instead of duplicating effort to boot into Linux and use Linux to show the boot menu then kexec into the actual kernal or set it to boot next. See zfsbootmenu and "no more boot loader" this is simpler and less bloated but it doesnt use less space

How do you propose we do this?

When tech reports a library as insecure, but it takes a year to approve removal, much of the difficulty doesn't lie at the coder level of the corporation's infrastructure.

Being mandated to throw away simple and stable code in favor of the “new platform” that changes every 18 months has been one of the most frustrating experiences of my working life and turned me into a bit of a nihilist (in a work context).

While I agree with the overall post, I think the iMessage-preview is a bad example.

If they instead had filtered/disabled previews the security problems would still exist - and potentially have less visibility.

Of the three great programmer virtues of Larry Wall, only laziness remains.

This is why cruft removal is linked to the value delivered to the user

You do not say : "there is two task: add some feature, takes 1 day, and delete some cruft, takes 1 day".

You say: "Yes, that feature. That's one task. It will take 2 days."

And once a level of "story points" is achieved within a Sprint you can't go backwards and you can't deliver less value to the Customer. There is no room for re-evaluation. Forwards, moar!

As per Tame Impala's Elephant:

He pulled the mirrors off his Cadillac

Because he doesn't like it looking like he looks back

Looking back gives the impression of missteps or regret. We have no such thing!

Scrum points are about engineering controllability, rather than performance. But that's a complexity most don't get.