We can't all agree on the definition of 'software bloat'.
Is using more memory resources for caching "bloat"? It irks me when someone pulls a task manager screenshot, orders by memory usage, and picks one application out of it. "See, program X is using XXXMBs of memory! Bloated!" Well, perhaps it is, perhaps it isn't. You are still using it, so it is probably doing its job well. Perhaps that "wasted" memory is being used for caching.
This is specially true when people compare OS memory consumption. If an OS is not using all your memory, you are wasting it. It should be using it for something, be it caching, eager loading, whatever. As long as you can quickly reclaim it when needed.
Same goes for CPU usage. "It's using 100% of my CPU!". Well, did you tell it do anything? If so, isn't that what you want? You want the task to complete quickly so it can go back to idle. Now, if it is supposed to be idling, and using a lot of CPU, that's a problem (Slack, I'm looking at you).
From the article:
> The same CD that hasn’t been able to fit Ubuntu since 2011 still fits approximately 150,000 pages of unformatted English text without any compression.
Well, yeah. But one-dimensional metrics are useless. What about the number of packages? Did it increase? Is Ubuntu now packing high-resolution artwork, to be used with our 5k displays? What else has changed? I'm certain that the CD is not all source code, so the English text comparison is meaningless.
>The burden of selecting software that is not bloated is entirely on the user. The default is bloated, if you want the unbloated version, you’ll have to work (search) for it yourself. And in many cases (e.g. anything that needs a web browser) such a search may not even be fruitful.
Sometimes, the opposite is true. Take Vim and Atom, which are mentioned in the article. You can add packages to them, so increasing the perceived "bloat" is entirely up to the user. Unless the user takes the easy way and installs a "vim-full" package. Which, if we have memory and cpu to spare, isn't usually a problem. We are talking about VIM in the age of laptops with 16GB of RAM.
> There are very little tools available to to help the user select unbloated software. Very few packages make any claims about their storage and runtime charactaristics at all
Now, here I agree. It is something difficult to measure.
> Over time, the battle against bloat is always lost. Even Ubuntu, which has traditionally presented itself (besides other things) as a method to extract a few extra life-years out of old hardware, is mentioned in the list above. In other words: it’s only less bloated than the alternatives.
Yes. And yet it is inching closer and closer of being "ready for the desktop". It has to cater to a lot of people, which means bundling lots of features. Still less "bloated" than other commercial operating systems. Considering the number of available packages, Ubuntu offers a very good deal.
> or even simply the introduction of flash screens.
Oh, now we are in agreement. See, if you are waiting for a splash screen, you can't do your job. The software is not doing its job. Therefore, the amount of time being spent at the splash screen should be reduced, so that we can eliminate the need for one. In the bargain, eliminating the code and artwork for the splash screen, thus reducing bloat.
Still, in some cases, this is unavoidable. Take games. They will often present splash screens when loading a level (if they have such a concept). Some of them will even go as far as present animated 3D geometry, using the GPU (and CPU). Which are mostly idle anyway, waiting for I/O. Sometimes, one can devise a better way of packing the files, to reduce loading times. Even more so when the actual serialization mechanism is inefficient(hi, Kerbal Space Program). But what they are usually trading off is a lag-free game play, in exchange of a loading screen (think of it as warming a huge cache). Is that bloat? The assets are huge, because we want them to be.
Are you developing for an embedded platform? No, mobile doesn't count, they are effectively shrinked PCs from a few years ago (with non-mechanical storage even). If so, then worry about every CPU cycle you are using, as well as storage. Build your own linux distribution if you have to, compile with the exact flags for your platform so you can generate optimal code.
Running in a battery powered device (no matter the size)? Then try not to use too much CPU, and certainly not constantly. Batch stuff, run in bursts, get it over quickly. Disable any non-essential tasks.
Is a background task? Try not to disturb the rest of the system, please.
A foreground, interactive desktop application? You are likely the focus of the user's attention, do whatever it takes to minimize the latency! The only reason not to gobble all RAM is that the user may be running other stuff too. And the reason for minimizing CPU usage is heat and power. Other than that, I bet a user will rather have an application that is making use of all resources available, if it means getting work done quickly. And feeling... "snappy"!
If the user is not being impacted, then I don't see the problem. My issue with Slack, for instance, is that it uses a lot of system resources and doesn't feel fast in return.