[rollcat]

Mesa alone is like 50mb of tightly optimized x86-64 machine code (Windows 95, by comparison, came on 8x1.4mb floppies); and that's just to talk to the actual kernel drivers - you need that for the GPU to draw things on the screen (unless you want software rendering = idle silicon).

Does every program need all of that code? There's libraries in there to handle OpenGL (in half a million different versions), Vulkan, AMD, Intel, Nouveau, etc... Nope, you usually need just the tiny bits relevant to your application+hardware. But what's easier, figuring out which bits you don't need - or making the stack more portable and future-proof, by always shipping everything?

A lot of complexity is accidental, but most of it comes from conscious choices to make life simpler for everyone. Of course taken to the logical extreme, we do end up with Electron, but where are we supposed to draw the line?

[pixelesque]

I think Windows 95 came on 13 1.4MB floppies actually...

[rollcat]

I checked, and it was Win3.11 that came on 8 floppies! https://archive.org/download/dos-622-3

Windows 95 was almost 30: https://ia803207.us.archive.org/view_archive.php?archive=/22...

Another fun article currently on the front page, diving into the insanity that is 8086/286/386 addressing modes: https://blogsystem5.substack.com/p/from-0-to-1-mb-in-dos

Even these "simple" operating systems managed to pack an incredible amount of complexity - again, just to deal with hardware, portability, different APIs, etc. Consumers - we, we demanded all of that.

If we really wanted/needed simpler software, OpenBSD is right around the corner. I've used it on&off as a daily driver for a bit, and it has an incredibly high ratio of code quality/readability vs how practical it is for everyday things (while remaining very portable). But simplicity is an uphill battle.

[guappa]

mesa is a shared library, electron isn't. That's a way to draw a line.

[rollcat]

There are several very compelling arguments against shared libraries.

You could (theoretically, I think) link Mesa statically.

[palata]

And there are several very compelling arguments in favour of shared libraries in sane system packages :-).

[rollcat]

"Sane" package managers is how you end up hiding the difference in complexity between installing a static Go executable, an Electron app, a C++ Gtk/Qt app, a Python app, etc.

Hiding the complexity is not necessarily bad, but that decision should be made consciously. Some complexity is inherent to the problem space, some is accidental - but even the latter must sometimes be tolerated. So again, how do we draw the line?

[palata]

I did not understand that. How is a system package manager hiding the difference in complexity between Go executables, Electron apps, etc?

My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.

[rollcat]

> How is a system package manager hiding the difference in complexity between Go executables, Electron apps, etc?

Consider:

    apt-get install myapp

You have no way of knowing if this will install a bundled copy of Chrome or not.

    CGO_ENABLED=0 go install example.com/myapp@latest

You can be 100% certain that it will produce exactly one static executable (OR fail to build anything), that all dependencies are pure Go, inspect the SBOM, read the entire source (including the compiler, which is reproducible), and so on. There are certain ways to sidestep these guarantees, but these involve very dark magic and are non-portable.

Also consider that the former command merely installs a pre-built artifact - try building Chromium from source. How is this not hiding complexity?

> My point was that a sane system package manager has maintainers for the packages and should not accept to ship a full OS in a single package.

How do you make that choice? Where do you draw the line? Why does Emacs make the cut, but VS Codium doesn't?