LisPi on Nostr: Haelwenn /элвэн/ :triskell: npub1zdmwg…3g0vj npub19dtz5…505k8 ...
Haelwenn /элвэн/ :triskell: (npub1ysu…2jyl) npub1zdmwgufa05tqfv49tftj3pgawd995dcwkh2z4vpe4l5tne3har6qd3g0vj (npub1zdm…g0vj) npub19dtz5045lnpakgchhjfnxkpzm32zhxer8q7enqtg7k4mxauwwkrqv505k8 (npub19dt…05k8) npub1mg0vfl2twyuytejcglvc7nq3z78m4ys00hvsrtju3t6kud75htpswjr7j0 (npub1mg0…r7j0) > with static linux binaries (like Mosaic can be ran that way)
This is an issue mostly because the wrong layer is being distributed. The Operating System APIs for Linux are specified and standard at the ABI level, so particular cached computations (a binary) targeting that ABI will continue working in environments supporting it (different computer architectures being different environments). The stable/standard compatibility layer for most Linux binaries is typically at the source level inherited by libraries that only provide compatiblity & reliability guarantees at the source level.
It makes no sense to distribute the program at a layer that is not subject to reliability guarantees otherwise mentioned. (related: https://gbracha.blogspot.com/2020/01/the-build-is-always-broken.html)
(I don't think GNU LibC makes any claims of ABI stability across versions, so a given cached version of it cannot be used as a reliable primary artifact.)
> But it'll also mean just throwing out security entirely, which enterprise software does all the time.
Unless cryptography is involved, that shouldn't be the case and suggests there's something wrong with the running environment rather than the program.
For cryptography there are ways of handling that, mainly presenting a stable API at some layer or another. Programs using SSH don't need to know more than its command line interface (which SSH itself has somewhat standardized I think), programs using I2P (as clients) need nothing more than standard HTTP or TCP support (through reverse-proxy tunnels) & do not care about the I2P version used. And of course, libraries presenting a stable API (whether type/function-call based or protocol-based, with appropriate upgrade support in the background), which I think is the standard way to go now, will simply keep working.
This is an issue mostly because the wrong layer is being distributed. The Operating System APIs for Linux are specified and standard at the ABI level, so particular cached computations (a binary) targeting that ABI will continue working in environments supporting it (different computer architectures being different environments). The stable/standard compatibility layer for most Linux binaries is typically at the source level inherited by libraries that only provide compatiblity & reliability guarantees at the source level.
It makes no sense to distribute the program at a layer that is not subject to reliability guarantees otherwise mentioned. (related: https://gbracha.blogspot.com/2020/01/the-build-is-always-broken.html)
(I don't think GNU LibC makes any claims of ABI stability across versions, so a given cached version of it cannot be used as a reliable primary artifact.)
> But it'll also mean just throwing out security entirely, which enterprise software does all the time.
Unless cryptography is involved, that shouldn't be the case and suggests there's something wrong with the running environment rather than the program.
For cryptography there are ways of handling that, mainly presenting a stable API at some layer or another. Programs using SSH don't need to know more than its command line interface (which SSH itself has somewhat standardized I think), programs using I2P (as clients) need nothing more than standard HTTP or TCP support (through reverse-proxy tunnels) & do not care about the I2P version used. And of course, libraries presenting a stable API (whether type/function-call based or protocol-based, with appropriate upgrade support in the background), which I think is the standard way to go now, will simply keep working.