[anamax]

> Now, as a software guy, can I stop hearing about how software "bloat" keeps absorbing all the hardware advances?

Why should you stop hearing it? Hardware is getting faster and SW is using the capacity.

> If hard drives had been advancing, errr, at all,

They have been, just not uniformly. There have been huge increases in capacity. Less so in transfer rate, but still significant. Seek time hasn't been improving much and rotational latency is stuck.

In the same time, arithmetic and logical operations have essentially become free. Branch mispredictions are a big deal. Cache misses are a killer but memory bandwidth is about to become the biggest problem. (It already is for some people.)

[jerf]

When someone wants to talk about bloat, the odds of Microsoft Office being trotted out are around 80%.

Yet, here we see that with a modern system that is mostly only special in the I/O department that Microsoft Office as a whole opens in .5 seconds, which, believe me, is radically faster than Office 95 opened back in the day it was still cutting edge.

Yes, it was a powerful system, but the only thing that was radically more powerful that what anybody can buy for cheap was the I/O system.

Maybe it's "bloat" in the abstract if programs are simply "larger" than they used to be, but really, who cares about bloat if hardware is actually outpacing software development... in everything but the I/O hardware.

I'm just a bit tired of people babbling on about software bloat when this pretty conclusively proves its the I/O subsystem that is the problem.

[anamax]

> I'm just a bit tired of people babbling on about software bloat when this pretty conclusively proves its the I/O subsystem that is the problem.

This proves nothing of the sort. (Office95 was bloated too....)

The time to boot is large because software is huge, scattered all over the disk, and has unnecessary dependencies.

It may be convenient to believe that everything fits in L1 cache, but doing so often results in slow programs. The same principle applies here. Some operations cost more than others. Software which uses slow operations will run slower than software that doesn't.

To put it another way, big O is the start, not the end.