Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does.
Why can't we just static link everything, and distribute binaries like we're on win32?
Why can't we just static link everything, and distribute binaries like we're on win32?
The big difference isn't static vs dynamic but that on Windows the DLLs that come with the OS do not break backwards compatibility so applications can rely on them whereas on Linux only a very tiny number of libraries do not break backwards compatibility (from the top of my head that'd be glibc[0], X11/Xlib/etc, curl and OpenGL). Most importantly the libraries for making a GUI application do tend to break backwards compatibility (see the breakage in Gtk1->Gtk2->Gtk3->Gtk4 and Qt1->Qt2->Qt3->Qt4->Qt5->Qt6 though with the latter being C++ they can't help it as C++ itself makes it harder with not having a stable ABI). Not all do (AFAIK Motif has been backwards compatible since the early 90s) but those that don't aren't that common (for unrelated reasons - e.g. most provide only a small fraction of the functionality Gtk/Qt provide or, in cases like Motif, the license was unpopular with FLOSS developers so no ecosystem was built around it).
[0] they do break compatibility for programs using unsupported APIs though
If you've got $$$$ of CAD software (or whatever) in binary form, which you know will work on pretty much every version of Windows but will absolutely not work on Linux or OS X - that's a good reason to stay on Windows. Microsoft is willing to do a bunch of compatibility testing etc to maintain that moat. They've got the money to pay developers to make sure Office 97 still runs on Windows 11.
Linux, on the other hand, has a lot of different stakeholders - and some of those stakeholders take the opinion that closed source software can go fuck itself. Maybe a Linux distribution wants to update from OpenSSL 1.1 to OpenSSL 3.0 and they're quite happy to patch all the software that's part of the distro. If you want to run some closed-source binary-only software from 1997 - that's between you and the software vendor, buddy.
It is sadly a very common misconception that backwards compatibility is only for close source software but in reality FLOSS benefit a ton from backwards compatibility too.
Imagine for example if glibc decided to add a third parameter to fopen (ignore if it is realistic for glibc to do that, this is for the sake of argument).
The only benefit of FLOSS[0] would be that it'd be easier for someone to update it to use the third parameter instead of waiting for the original developer to do so - but still every program, FLOSS or not, would need to be updated anyway and someone would need to spend time doing that update.
A more realistic example would be GIMP: the stable releases (last was made a few weeks ago) still rely on Gtk2 and the Gtk3 port (i.e. the effort to move from Gtk2 to Gtk3) is still in beta while the Gtk devs consider it deprecated. And this is all open source, no closed source software in sight, yet see how much time was lost (not only for GIMP but for any software that relied on Gtk2 and had to switch to Gtk3, with the story repeating for Gtk4) - time that could have spent improving the actual functionality that the GIMP users use the program for - adding functionality for manipulating images - instead of using yet another approach to draw and lay out buttons, menus and checkboxes - something that was already solved back in Gtk 1.x days.
[0] actually of any source available that doesn't have a "see but don't touch" rule
Because what happens if there's vulnerability in say zlib or openssl. As a distributor you'd need to rebuild everything (volunteer-run distros don't have sufficient cpu time to rebuild the whole archive at once), and in the process check if the update won't break anything in each and every package. Or rely on upstream (which may be unresponsive, because they're also volunteers).
This might be manageable in relatively small, single-language, corporate-backed apps, but is not viable in volunteer-run operating systems with ~50k packages written in every single programming language invented.
No one distro will risk this (imagine Phoronix article: "After 1 year, CVE-2023-123456 fixed in only 30% of packages in StaticLinux!").
I mean, you're free to try. I'll provide time-to-fixed statistics for all your CVEs.
Flatpack Runtimes do this for common dependency lists, but still allow some customization, without me having to recompile openssl- or some other annoying upstream.
Example: LibreOffice download size (source)
- AppImage ~248 MByte
- Snap 463 MByte [July 2020 update]
- Flatpak 543 MByte