[hnwizard]

There's a staggering, mind blowing, astronomical levels of bloat and complexity in modern systems, be it SoCs, Operating systems or apps.

Many mobile apps nowadays are larger in binary size than whole operating systems+applications doing extremely useful work.

It's staggering, scary and, where is this all going? Will someone or something put a damper on it? Probably not.

[lproven]

> Will someone or something put a damper on it? Probably not.

Oh yes.

Global warming will.

The fossil-fuels companies have been very effective at spreading propaganda, so some readers are probably laughing and thinking "ha! Idiot! It's not real!"

If so, I am sorry for you: you are flat-earthers. You have been eaten by the brain worms.

We are heading for 80-90% of the land on Earth being uninhabitable by humans inside 2-3 decades, and a small remnant population at the poles. All silicon chips, RAM, storage, etc. is made in tropical and subtropical regions, and they will all be gone.

If we are lucky we'll be back to handmade computers with individually soldered components scavenged from dead consumer electronics.

The CollapseOS person is probably right: http://collapseos.org/

Here is a quick guide to the science for those with the brain worms: https://medium.com/@samyoureyes/the-busy-workers-handbook-to...

It is the length of a short book, but that's because there is a lot to get in for those who've been trained to bury their heads in the sand because they listen to billionaire's BS.

[hdjjhhvvhga]

Only if there is an economic incentive to it. Currently, there is none. (A cynic in me would say the reverse is true at least in Apple ecosystem, as more resource-hungry apps push users to upgrade their devices more often.)

Moreover, I'm not sure how much you can gain, actually. You can probably get some reduction in app size as far as code segment is concerned, but usually most of the space is taken up by assets, especially in games, and they're already well compressed. So basically we could optimize the last 20% which are the hardest to get right.

[eru]

If we really needed to, we could compress assets a lot, eg with procedural generation. (Including the neural network kind.) But that would be a lot of hassle, and would probably trade run time for space.

As for code: I think shaving of bytes isn't all that important, especially compared to assets; but simplifying logic can give various benefits. However, that also takes time and is probably not worth it for many applications.

A distinction I like to make is being careful to distinguish between bloat that worsens throughput and bloat that worsens latency.

Throughput still gets better almost for free over time by general hardware improvements. Latency still requires attention.

An example: an early word processing software (I think it was part of GEOS for the Commodore 64) paid a lot of attention to keeping the latency between you pressing a key and a letter appearing on the screen low. By today's standards, the Commodore 64 was slow as molasses, so when you typed quickly GEOS eg temporarily disabled breaking wrapping words at the end of the line and just jumped to the next line in the middle of a word.

After you had finished your burst of typing, GEOS would go back and calculate proper line breaks.

Compare that with textfields in modern websites, which sometimes have a noticeable delay before a letter shows up.

GEOS's code for such latency reduction was probably incredible convoluted and messy (I am just guessing here) and made it hard to a nightmare to add new features, but was worth it back then. The modern bloated website can probably sustain a higher throughput, even without no one taking any care to optimize that. But latency is horrible.

[OhMeadhbh]

I wrote the PC equivalent for a similar product in the 1980s and wrote some different GEOS code. It was less convoluted than you might imagine. But it was very unforgiving in terms of de-referencing null pointers and memory leaks. Instead of using a little too much memory or causing a process to crash, it would often cause the system to hang. Windows 3 (and to a lesser degree Windows 95) had similar problems.

[ralphc]

In modern times the argument is the economic incentive is to optimize for the developer, not the hardware. Python, Node etc. over C.

[eru]

And most of the time that's the right trade-off.

Not all the time, though. Eg consider a video game: the image frames have to be pumped out on a tight time budget every couple of milliseconds, but the logic to decide whether you have finished your quest can afford to run for a few seconds in the background.

Even though the latter is much simpler and could probably be coded up to run on even the Timex m851 in fractions of a second.

[hnwizard]

I totally agree, there's no economic incentive, and sadly the "industry" will make sure complexity/size/scale will keep on growing. How much more performance and quantity do we need in CPU/RAM/storage/storage bandwidth for regular apps which I assume is the vast majority of computing at home/office.

Sure, games are ever-demanding and will continue going that way probably for a while longer especially on the pure graphics side.

Many apps do contain truck loads of libraries and dependencies, which have dependencies and all of that alone, accounts to massive code size.

[omneity]

One of my hopes is that LLM technology can eventually be used to fight technical debt and help us clean up the software stack.

[eru]

It'll probably just allow us to get away with even more technical debt.

[hnwizard]

That's also what I'm afraid of...