|
|
|
|
|
|
by possiblerobot
2053 days ago
|
|
|
You might be right with respect to non-techie users. But, it's not about whether it merely works. It's about what we could be doing with modern hardware if we used it as efficiently as old software had to use its hardware. What kinds of wild things could we accomplish on this hardware if we weren't bogged down in gigabytes and teraflops of bloat? |
|
|
Not that many: An early 1990s PC platform could be thoroughly described in a 200 page book and you could write a boot loader for the CPU, a VGA driver, and drivers for the most common peripherals from scratch in a few weeks.
In fact, games of that era shipped with their own audio drivers, (C/E/V)GA libraries and peripheral support.
Today this would be a) impossible because many manufacturers (cough NVIDIA cough) don't even release OSS drivers and specs and b) individual programs don't own the hardware anymore - the OS does. Also the multitude of target platforms (CPU types, -core counts, and -speeds, graphics cards, peripherals, etc.) makes it virtually impossible to ship code that it optimal for each of even the most common combinations of hardware.
The final nail in the coffin of the "super lean no bloat why-not-just-unikernel-everything-for-maximum-performance" idea can be summed up in one word: cost.
Development costs would be insane if we started optimising every aspect of every program for performance (on every possible platform, no less), memory use, and (binary-) size.
And that's even ignoring the fact that it's more often than not outright impossible to optimise for binary size, runtime performance, and memory footprint all at the same time.
Plus interactions between programs (plugins, {shell-}extensions, data formats, clipboards, etc.) require "bloat" like common interfaces and "neutral" protocols.
Most of the myth of great "old software" comes from the fact that functionality was severely limited compared to modern apps and that many folks simply weren't around to actually see and feel how much some of them actually sucked.
Sure, Visual Studio 6.0 runs incredibly fast on a vintage 3.2 GHz Pentium 4 with 2GiB of RAM using Windows 2000 - but when it released in 1998 many PCs had a 60MHz Pentium 1 or a 100MHz 486DX4 with 64MiB of RAM and it ran like a three-legged dog with worms on these machines compared to the DOS-based Borland-C...
Speaking of which, remember when sometime around the 2000s all Borland Pascal program stopped working, because CPUs had become too fast (>200MHz IIRC)? That was because their runtime used a loop to determine how fast the CPU was, which caused a divide-by-zero on fast machines IIRC.
Good times indeed...