4 ms·

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no

by mappu 2y ago

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

cyberax 2y ago
There are few issues: 1. GNU libc is an exception in the world of compatibility. 2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
- kccqzy 2y ago
  That is solved by containerization (cgroups and namespaces), which is initially popularized by docker, which appeared about 12 years ago. And newer things like flatpak and snap are just bells and whistles over this.
  - cyberax 2y ago
    I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.
    - GoblinSlayer 2y ago
      I heard OpenGL has a bad compatibility story, which was the reason games used DirectX.
- mappu 2y ago
  In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
  - int_19h 2y ago
    Yep, but you can still install .NET 3.5 on Windows today, which will run .NET 2.0 apps just fine. .NET 1.x tho, yeah.
  - cyberax 2y ago
    The most recent .NET Framework still keeps 1.1 assemblies for compatibility. And yep, .NET sucked and eventually got semi-abandoned.
    - DonnyV 2y ago
      What are you talking about??? .NET never got abandoned! If anything its hit a very high bar now. Its one of the top frameworks to build an app across platforms.
      - p_ing 2y ago
        They're referring to (I hope), the .NET Framework which is Windows-only and the last/latest version being 4.8. It should live a very long life, as Microsoft server infrastructure is built on it (SharePoint/Exchange).
      - cyberax 2y ago
        .NET Framework is indeed getting sidelined, along with WPF and the other technologies from the .NET 1.1 era.
    - recursive 2y ago
      This must be from an alternate timeline. There is no way to call what is currently going on with .net anything other than 0% abandoned.
      - Uvix 2y ago
        The .NET Framework 1.x runtime is no longer supported, and the .NET Framework 2.0 runtime (used by v2.0-3.5 applications) won’t be supported after 2029. They are slowly abandoning support for old apps. (Yes, if you fiddle with the config file they might work on the .NET 4.0 runtime. But that’s not something a typical user can/will do.)
- asddubs 2y ago
  I still run an unmodified GTK2 app from 2012 that I just grabbed a .deb from an ancient debian version, because I don't like the GTK3 version.
GoblinSlayer 2y ago
Thankfully gtk2 is now stable too.
- awill 2y ago
  because it's EOL? :)
geokon 2y ago
I hit quirks with glib semi-regularly (~1/year) For example, recently I tried to run Emacs' Appimage and it has a glib issue https://github.com/probonopd/Emacs.AppImage/issues/22#issuecomment-2644864214 https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...
- Narishma 2y ago
  glibc, not glib. That's a different library.
  - geokon 2y ago
    that's embarrassing.. you're right. Thank you for the correction. Wish I could delete my comment
- lelandbatey 2y ago
  That's talking about 'glib' which is not the same as 'glibc'. Glib is a library from the GTK project which offers utility functionality related to the GTK widget toolkit, while glibc is the GNU C Library. Amusingly, these kinds of beyond-the-core libraries are the ones that have always caused problems for me, never actual core GNU C Library.
ur-whale 2y ago
> Glibc has great backwards compatibility We're clearly not living in the same universe here. glibc backward compatibility is horrible. Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it. And these days, you can't even link glibc statically, when you try it barks at you with vehemence. As a matter of fact, as pointed out in the article, this particular shortcoming of glibc completely negates the work done by Linus to keep userland backward compatible at all cost.
- account42 2y ago
  [citation needed] Please post actual issues encountered, including non-paraphrased errors instead of FUD. And if you want to statically link your libc there is nothing forcing you to use glibc. You're only stuck with glibc (and even then you don't actually need to use any functions from it yourself) if you need dynamic linnking for e.g. OpenGL/Vulkan. Also, glibc wasn't designed for static linking even before they put in safeguards against that.

by mappu 2y ago

cyberax 2y ago

There are few issues: 1. GNU libc is an exception in the world of compatibility. 2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.

kccqzy 2y ago
That is solved by containerization (cgroups and namespaces), which is initially popularized by docker, which appeared about 12 years ago. And newer things like flatpak and snap are just bells and whistles over this.
- cyberax 2y ago
  I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.
  - GoblinSlayer 2y ago
    I heard OpenGL has a bad compatibility story, which was the reason games used DirectX.
mappu 2y ago
In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
- int_19h 2y ago
  Yep, but you can still install .NET 3.5 on Windows today, which will run .NET 2.0 apps just fine. .NET 1.x tho, yeah.
- cyberax 2y ago
  The most recent .NET Framework still keeps 1.1 assemblies for compatibility. And yep, .NET sucked and eventually got semi-abandoned.
  - DonnyV 2y ago
    What are you talking about??? .NET never got abandoned! If anything its hit a very high bar now. Its one of the top frameworks to build an app across platforms.
    - p_ing 2y ago
      They're referring to (I hope), the .NET Framework which is Windows-only and the last/latest version being 4.8. It should live a very long life, as Microsoft server infrastructure is built on it (SharePoint/Exchange).
    - cyberax 2y ago
      .NET Framework is indeed getting sidelined, along with WPF and the other technologies from the .NET 1.1 era.
  - recursive 2y ago
    This must be from an alternate timeline. There is no way to call what is currently going on with .net anything other than 0% abandoned.
    - Uvix 2y ago
      The .NET Framework 1.x runtime is no longer supported, and the .NET Framework 2.0 runtime (used by v2.0-3.5 applications) won’t be supported after 2029. They are slowly abandoning support for old apps. (Yes, if you fiddle with the config file they might work on the .NET 4.0 runtime. But that’s not something a typical user can/will do.)
asddubs 2y ago
I still run an unmodified GTK2 app from 2012 that I just grabbed a .deb from an ancient debian version, because I don't like the GTK3 version.

GoblinSlayer 2y ago

Thankfully gtk2 is now stable too.

awill 2y ago
because it's EOL? :)

geokon 2y ago

I hit quirks with glib semi-regularly (~1/year) For example, recently I tried to run Emacs' Appimage and it has a glib issue https://github.com/probonopd/Emacs.AppImage/issues/22#issuecomment-2644864214 https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...

Narishma 2y ago
glibc, not glib. That's a different library.
- geokon 2y ago
  that's embarrassing.. you're right. Thank you for the correction. Wish I could delete my comment
lelandbatey 2y ago
That's talking about 'glib' which is not the same as 'glibc'. Glib is a library from the GTK project which offers utility functionality related to the GTK widget toolkit, while glibc is the GNU C Library. Amusingly, these kinds of beyond-the-core libraries are the ones that have always caused problems for me, never actual core GNU C Library.

ur-whale 2y ago

> Glibc has great backwards compatibility We're clearly not living in the same universe here. glibc backward compatibility is horrible. Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it. And these days, you can't even link glibc statically, when you try it barks at you with vehemence. As a matter of fact, as pointed out in the article, this particular shortcoming of glibc completely negates the work done by Linus to keep userland backward compatible at all cost.

account42 2y ago
[citation needed] Please post actual issues encountered, including non-paraphrased errors instead of FUD. And if you want to statically link your libc there is nothing forcing you to use glibc. You're only stuck with glibc (and even then you don't actually need to use any functions from it yourself) if you need dynamic linnking for e.g. OpenGL/Vulkan. Also, glibc wasn't designed for static linking even before they put in safeguards against that.