The memory footprint of workbench was incredibly low. A base alpine image with no support for any graphics is several times that size. What are we doing?
Workbench had a very limited hardware it supported. Linux Kernel supports 1000x as many pieces of hardware from different CPU configurations, all the way to the most random USB/Firewire devices.
Like, software bloat is totally a thing, but comparing Workbench to the Linux Kernel (let alone the entire GNU/Linux environment) is ridiculously naive.
An alpine docker container doesn't have the kernel, so all that hardware support, and the kernel itself are still on top of that ~8MB GUI-less image. 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.
> An alpine docker container doesn't have the kernel, so all that hardware support
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:
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
Can you point to a base install of workbench being able to do all of that? About the only thing in the alpine base layout that it is directly comparable to is BusyBox+bash.
> 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).
I remember when Linux kernel came in floppies, and a plain CD-ROM would give me basically the same what many kids now use on their text terminals with tmux.
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.