5 ms·

I'm probably naive, but I see another way forward. If all the t64 binaries are static linked, they have no danger of mixing abis. After 2038, all the t32 code

I'm probably naive, but I see another way forward. If all the t64 binaries are static linked, they have no danger of mixing abis. After 2038, all the t32 code is broken anyway so there's no additional risk for going back to dynamic linking then. I feel if this was a solution the author would have mentioned it but I'm willing to look foolish to hear what others will say.

layer8 2y ago
Static linking is probably impractical for applying security updates, as often you’d have to recompile/relink basically the whole system. In some cases it could also significantly increase memory usage.
- GeorgeTirebiter 2y ago
  with fast networks, huge disks, fast processors --- it seems wasteful to me to even consider shared libraries. Shared libraries is a technology that was useful when we were memory starved. We are no longer memory starved. So you replace the static binary? Big deal, size is not an issue (for 99% of the cases) given what we have today. Recall, too, that the "link" step of those .o files is actually a "link / edit" step, where routines in the libraries not used are not linked.
  - account42 2y ago
    Have you looked at the size of your average GUI toolkit lately. Dynamic linking is still very much needed. Besides I like my faster processor and larger disks/ram actually making things faster for me and letting me do more instead of being wasted on developer lazyness.
  - layer8 2y ago
    It’s much more straightforward to ensure consistency with shared libraries, and not having to rebuild stuff. Wasting disk space, RAM, network bandwidth and processing time is what seems wasteful to me.
  - gotoeleven 2y ago
    [flagged]
  - jiggawatts 2y ago
    Static linking is the root cause for “modern” apps based on Electron taking minutes to start up and be useful. They’re statically linking almost an entire operating system (Chromium), an entire web server, server runtime framework, and an equivalent client framework for good measure. On the fastest PC that money can buy this is somewhere between “slow” and “molasses”. I miss the good old days when useful GUI programs were mere kilobytes in size and launched instantly.
  - messe 2y ago
    Remember that this is for 32-bit systems. Size can be an issue there, especially on an embedded system.
  - cbmuser 2y ago
    > with fast networks, huge disks, fast processors --- it seems wasteful to me to even consider shared libraries. The problem is that you will always have to rebuild all packages that link against a certain library when a security update is released so that if the user installs a security update, they will have to download several gigabytes instead of just a few megabytes.
troad 2y ago
Considering the most important remaining use case for 32-bit is embedded systems, wouldn't static linking be a non-starter due to space and performance constraints?

layer8 2y ago

Static linking is probably impractical for applying security updates, as often you’d have to recompile/relink basically the whole system. In some cases it could also significantly increase memory usage.

GeorgeTirebiter 2y ago
with fast networks, huge disks, fast processors --- it seems wasteful to me to even consider shared libraries. Shared libraries is a technology that was useful when we were memory starved. We are no longer memory starved. So you replace the static binary? Big deal, size is not an issue (for 99% of the cases) given what we have today. Recall, too, that the "link" step of those .o files is actually a "link / edit" step, where routines in the libraries not used are not linked.
- account42 2y ago
  Have you looked at the size of your average GUI toolkit lately. Dynamic linking is still very much needed. Besides I like my faster processor and larger disks/ram actually making things faster for me and letting me do more instead of being wasted on developer lazyness.
- layer8 2y ago
  It’s much more straightforward to ensure consistency with shared libraries, and not having to rebuild stuff. Wasting disk space, RAM, network bandwidth and processing time is what seems wasteful to me.
- gotoeleven 2y ago
  [flagged]
- jiggawatts 2y ago
  Static linking is the root cause for “modern” apps based on Electron taking minutes to start up and be useful. They’re statically linking almost an entire operating system (Chromium), an entire web server, server runtime framework, and an equivalent client framework for good measure. On the fastest PC that money can buy this is somewhere between “slow” and “molasses”. I miss the good old days when useful GUI programs were mere kilobytes in size and launched instantly.
- messe 2y ago
  Remember that this is for 32-bit systems. Size can be an issue there, especially on an embedded system.
- cbmuser 2y ago
  > with fast networks, huge disks, fast processors --- it seems wasteful to me to even consider shared libraries. The problem is that you will always have to rebuild all packages that link against a certain library when a security update is released so that if the user installs a security update, they will have to download several gigabytes instead of just a few megabytes.

troad 2y ago

Considering the most important remaining use case for 32-bit is embedded systems, wouldn't static linking be a non-starter due to space and performance constraints?