The only functional improvements I can note over two decades are: Unicode support, higher resolution of everything (from hardware to content), and system reliability thanks to driver isolation.
Also, it’s kind of amazing that many web pages these days are larger than Doom shareware’s zip size.
When I was a teenager, I wanted to see what was the maximum resolution my monitor supported. It was a Samsung Syncmaster 14" entirely analog, no OSD, with analog adjustment knobs on the bottom. The video card was a Matrox Millennium II 8MB VRAM and the OS was Windows 3.10. The maximum resolution that I could get was 1600x1200 @ 41Hz interlaced. That's almost 2K (1.92K to be more precise). 41Hz interlaced hurt my eyes like hell but everything worked on the software side.
I can run a full virtual music studio on my Mac, with tens of channels, each with a collection of plugins, and multiple samples and audio files streaming off SSD at the same time.
None of that is GPU accelerated - except maybe the UI, which is split across three 4k monitors
On Windows 95 I could barely play a single WAV at once, and a dual monitor system was an exotic luxury.
Hardware has gotten a lot faster, and the software can do more without crashing. (Mostly.)
The real problem has been the move to browser+cloud for productivity applications. The OS is a front end for the browser, which is a front end for remote compute. This is hugely slow and inefficient compared to making everything work locally, and perhaps including some cloud-ish hooks for sharing.
Animations: NO, THANK YOU!
Font rendering quality: It increases with font size, which is needed for high res displays. Besides, current font authors don't waste any time doing manual font hinting like the old fonts had. Good luck having crisp font rendering without manual hinting! It's all just a blur since antialiasing was introduced.
Huge images: How huge? Win95 without any patches can allocate 500MB to a single program (image viewer). That's 170 megapixels @ 24bit-color.
Orthography and grammar checking was too slow. You had to press a button to check them, and it missed a lot of tricky cases.
It's easy to confuse the bad performance of old software with the hardware it's on. But really a lot of the trouble is that the solutions we had to software problems back then are primitive and naive compared to the current state of the art. There's no reason that current software design practices can't massively improve older systems.
Hell, just try installing a modern Linux on an ancient PC, you'll see what I mean. Even considering that the hardware is physically slower, your experience is much, much closer to modern computing than 98 could ever hope to achieve.
Making use of what is cheap (hardware (CPU/ram) and network bandwidth) while avoiding to use what is expensive: programmers, tech guy helping you with an upgrade or a troubled windows install.
Like, software bloat is totally a thing, but comparing Workbench to the Linux Kernel (let alone the entire GNU/Linux environment) is ridiculously naive.
Or since the subject is Amiga.
A 500 wouldn't make, but a A3000UX would.
Only if you run it on Linux through para virtualization; in which case it's using the host's kernel. Potato/potato.
The fact that it supports virtualizing an entire other OS in a safe and privileged manner should just further reinforce why the kernel is larger. But ok, got me.
> 8MB GUI-less image
Sure, and you can see all of the contents of that here:
https://github.com/linuxserver/docker-baseimage-alpine/blob/...
Let's just pick a few things from that:
curl - a library that can handle full bidirectional HTTP communication in Unicode, including via SSL/TLS and arbitrarily manage file streams *or* utilize linux's built-in piping/redirection functionality
ssl - a full suite of cryptographic libraries and keys to allow secure communications and integration into other libraries/code (the aforementioned curl, for instance)
onigurama - a full regular expression library for use in other programs (language VMs like Ruby, for instance)
musl - a libc runtime and it's standard library
zlib - in-built compression functionality utilized by gzip, png and others
> Part of it is elf header size vs hulk. Part of it is that no one bothers stripping symbols. But the reason for both of those reasons is simply that memory isn't scarce so we are lazy/efficient.
This is just some old guy "bah humbug" rant/conspiracy. Your Amiga with workbench is nowhere comparable to modern hardware+OSes. It can do somethings similarly, if you squint appropriately. At a much degraded image fidelity, color quality, insecure, primitively multitasking and non-networked manner with heavy RAM and CPU constraints.
I fully acknowledged software bloat is a thing. But we're not comparing some half-ass coded Electron app to some sleek handcoded C/C++/Rust desktop app. You're comparing base software built by decently-well educated engineers that does inordinately more than the comparison set, by so much moreso that it's ridiculous on its face. And then going on a rant about debug symbols and ELF headers (which brings a ton of benefits itself).