4 ms·

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

by mouse_ 4y ago

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?

whoisthemachine 4y ago
That exists - https://appimage.org/ https://appimage.org/.
- oynqr 4y ago
  Appimages are not statically linked at all.
  - Infernal 4y ago
    While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
    - rewgs 4y ago
      Which causes the aforementioned ballooning storage issue.
      - Infernal 4y ago
        The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
    - whoisthemachine 4y ago
      Yes, this was what I meant! For most users (at least for this user), it gives essentially the same outcome.
jvanderbot 4y ago
Fwiw, I do this for everything I release. But I doubt that's much "better" than something like flatpack, because just static linking doesn't really help me with dependencies at build time. Flatpack Runtimes do this for common dependency lists, but still allow some customization, without me having to recompile openssl- or some other annoying upstream.
badsectoracula 4y ago
On Win32 you don't static link everything, all OS functionality is provided through shared libraries (aka DLLs), the OS provides a ton more functionality out of the box (GUI, multimedia, input, graphics, etc) than you'd get with Linux, which while it provides strong backwards compatibility is just the kernel and practically everything else a regular desktop program uses is provided by libraries talking with it. 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
throw_a_grenade 4y ago
> Why can't we just static link everything, and distribute binaries 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.
michaelt 4y ago
That works on Windows because Microsoft have made a commitment to doing things that way, as an intentional moat. 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.
- badsectoracula 4y ago
  > some of those stakeholders take the opinion that closed source software can go fuck itself. 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

by mouse_ 4y ago

whoisthemachine 4y ago

That exists - https://appimage.org/ https://appimage.org/.

oynqr 4y ago
Appimages are not statically linked at all.
- Infernal 4y ago
  While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
  - rewgs 4y ago
    Which causes the aforementioned ballooning storage issue.
    - Infernal 4y ago
      The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
  - whoisthemachine 4y ago
    Yes, this was what I meant! For most users (at least for this user), it gives essentially the same outcome.

jvanderbot 4y ago

Fwiw, I do this for everything I release. But I doubt that's much "better" than something like flatpack, because just static linking doesn't really help me with dependencies at build time. Flatpack Runtimes do this for common dependency lists, but still allow some customization, without me having to recompile openssl- or some other annoying upstream.

badsectoracula 4y ago

On Win32 you don't static link everything, all OS functionality is provided through shared libraries (aka DLLs), the OS provides a ton more functionality out of the box (GUI, multimedia, input, graphics, etc) than you'd get with Linux, which while it provides strong backwards compatibility is just the kernel and practically everything else a regular desktop program uses is provided by libraries talking with it. 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

throw_a_grenade 4y ago

> Why can't we just static link everything, and distribute binaries 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.

michaelt 4y ago

That works on Windows because Microsoft have made a commitment to doing things that way, as an intentional moat. 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.

badsectoracula 4y ago
> some of those stakeholders take the opinion that closed source software can go fuck itself. 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