9 ms·

This is actually super impressive. Managing to create an application bundle which doesn't break down every now and then with new system updates is super challen

This is actually super impressive. Managing to create an application bundle which doesn't break down every now and then with new system updates is super challenging. 10 years is just wild. Unless you only have libc as a dependency but I doubt that for a graphical application.

deleted 7y ago
[deleted]
skrebbel 7y ago
Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? I mean, lots of things are wrong with Windows but I can double-click a .exe from 1998 and in most cases it'll just run. I'd assume Linux, being used a lot for servers and long-running apps, would have this too?
- yani 7y ago
  Missing a runtime... missing dll... missing direct3d or different version of it, compatibility for certain version of Windows. It is all the same everywhere.
  - wolfgke 7y ago
    On Windows, you can easily install lots of parallel versions of libraries.
    - icebraining 7y ago
      So can you on Linux. Libraries are installed with their full version in the filename (e.g. /usr/lib/libpurple.so.0.13.0) so you can keep lots of parallel versions.
- ekianjo 7y ago
  > Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? Not Linux, libraries instead are the ones breaking compatibility over time. Or missing libraries as well...
  - badsectoracula 7y ago
    As far as the user is concerned it is "Linux", when people say they use "Linux" they do not just mean the kernel, they mean the entire OS. On Windows these libraries have APIs that remain backwards compatible (new methods can be exposed, but existing stuff remains there). Unless the equivalent Linux libraries also decide to provide backwards compatibility, they'll just make Linux look broken (even if it isn't the kernel's fault). (and no, this isn't something you solve by being pedantic about what is userspace and what is kernelspace and who controls what, as that information doesn't solve the actual problem - you solve it by cultivating a culture that actually cares about backwards compatibility)
- pantalaimon 7y ago
  Linux itself has this and is very strict about not breaking old userspace. It's the userspace libraries that likes to drop compatibility with old binaries left and right and with most distributions it's not possible to install old versions of libraries. Containers like Flatpack and Snap promise to solve this by just bundling the application with all the libraries it needs, frozen in time. The Kernel then can handle it.
  - dijit 7y ago
    Serious question; doesn’t static compilation do the same thing essentially?
    - ObscureScience 7y ago
      Kind of, but I guess the other solutions are slightly better at accomodating services that are more than a single binary. I think static binaries really should be evaluated again as they seem to be written off by most big players. Though Go(lang) has preferred static linking which has been something that seem to have been appreciated.
      - tfigment 7y ago
        Static has its own issues. GPL vs LGPL forces a lot of apps to dynamic. Also security vulnerabilities in libraries become unpatchable.
        AnIdiotOnTheNet 7y ago
        Apps are always the most secure when they can't run at all because of ABI changes in their dependencies.
        chronogram 7y ago
        I’d rather be able to run something that’s security flawed than not run it at all. Those security issues in libraries are probably not such a big deal anyway, because you can run Unreal Tournament 1 multiplayer now and not immediately get hacked, I’m sure. Maybe I just got very lucky.
- ObscureScience 7y ago
  No Linux distributions does not work like that. The kernel interface is pretty stable but userland is not. Dynamically linked executables will not work with new versions of the libraries they depend on in most cases. This is one of the problems flatpak, snap, appimage, docker and nix/guix are trying to solve.
  - v_lisivka 7y ago
    Flatpack, snap, aappimage, docker, static linking, etc. are solving other problem: how to bypass package manager and ship outdated and buggy libraries to user, because it will save some money for developer at expense of user. Whole GNU foundation was created to bash with this "solution", then Linux kernel + GNU runtime was used to create Linux distributions, which are free from binary-only distribution problem, but developers are creative. Why not just ship partially compiled binary or IR code, or obfuscated source with open-source adaptation layer? It will make adaptation problem much easier for end user at any distribution or/and architecture.
- josteink 7y ago
  > Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? "Broken" is a strong word. "Different" might be more fitting. While I don't think anyone in the world of Linux and Linux-distros work with the explicit aim of breaking compatibility, you have to realize that Linux and most Linux-distros are built entirely around open-source software. Most users install software via a distro-provided package-manager which fetches binaries from a repo. These binaries have been built from source, by the distro-vendor, specifically for that distro. That means Linux compatibility traditionally has been more about source-level and compile-time compatibility more so than 100% uncompromised binary compatibility. If a change breaks binary compatibility, but the distro/system as a whole still builds fine, that's still compatible in most day-to-day scenarios of a common Linux end-user. And unconstrained by having to maintain strict binary compatibility, it also allows developers to clean up historical garbage and technical debt they otherwise couldn't. This approach obviously has both drawbacks and advantages, but calling it "broken" seems unfair, overly opinionated and really just wrong.
  - wolfgke 7y ago
    TLDR: The developers of the GNU/Linux userland libraries do not care about binary compatibility.
    - josteink 7y ago
      Binary compatibility is only a pressing issue if the majority of the software you run is closed source and not provided by your distro. Why waste time maintaining something which is not needed?
      - wolfgke 7y ago
        > Binary compatibility is only a pressing issue if the majority of the software you run is closed source and not provided by your distro. Binary compatibility is a very pressing issue if there exist software that is closed source and you want to have more users than just some nerds.
- gambiting 7y ago
  The main difference is that most Windows apps are statically linked. A game from 1998 will very often come with its own set of .dlls that were built with the game and unless the underlying Win32 api changed, they should "just work". On Linux it's also possible to statically link libs, but it's far less common to do so - most apps rely on the libs in the system. Which in theory is a great thing, your app will always use the latest, safest version of whatever library it needs(while the windows app continues using the unsafe 1998 version of libs for instance). But of course in practice people who make the libs can't test their changes with every single app in existence, so inevitably the back compatibility gets broken, and Linux does have the issue of "oh I installed some system updates and now this app that always worked doesn't work anymore". Again, in theory apps are supposed to say which libs they need and package managers should respect that. But theory and real life are not necessarily the same.
  - SmellyGeekBoy 7y ago
    Day-to-day Linux system updates won't change major version numbers of libs in most distros, though. These breaking changes only seem to occur in major releases in my experience.
  - wolfgke 7y ago
    > The main difference is that most Windows apps are statically linked. A game from 1998 will very often come with its own set of .dlls that were built with the game and unless the underlying Win32 api changed, they should "just work". Delivering a set of DLLs is not static linking.
    - Sahhaese 7y ago
      It's almost like the D in DLL stands for something. That said, it's not strictly static linking but it is closer to it in effect than the global assembly cache or the shared DLLs which resulted in the kind of "DLL hell" that windows 95 was famous for.
  - badsectoracula 7y ago
    > The main difference is that most Windows apps are statically linked. No, the main difference is that on Windows the GUI libraries (USER32.DLL, etc) are considered part of the OS and have an API that remains backwards compatible. The applications are not statically linking the GUI libraries, they are dynamically linked against them, pretty much like on Linux. However on Linux the GUI libraries do not care a bit about preserving backwards compatibility (see Gtk1, Gtk2, Gtk3 and soon Gtk4, see Qt1, Qt2, Qt3, Qt4, Qt5 and soon Qt6 - although in Qt's case they cant do much thanks to C++'s ABI issues and TBH i wouldn't expect them do since Qt is primarily made by a company with interests in providing a crossplatform UI library, not the native GUI library for Linux). Windows simply provides a much richer API than Linux as a standard that applications can rely on.
- SmellyGeekBoy 7y ago
  Yes and no. It's a different mindset. In many cases Linux can run CLI software from the 1960s just fine but the desktop moves fast and breaks things often. The legacy support in Windows is admirable but does bloat the OS and create security and performance issues, for example. I suppose one could always fire up a VM with a 10-year-old version of Ubuntu to run older software, but it is indeed a hassle. The correct answer depends where your priorities lie.
  - wolfgke 7y ago
    > Yes and no. It's a different mindset. In many cases Linux can run CLI software from the 1960s just fine but the desktop moves fast and breaks things often. Serious question to all the GNU/Linux hackers: why can't we standardize the desktop on GNU/Linux similarly?
    - v_lisivka 7y ago
      I'm ready. Will you pay for my work to achieve your goal?
      - wolfgke 7y ago
        The problem rather is that even if you do, many distributions will not obey "your" standard. EDIT: So the problem is that it is not a problem of work to be done, but a problem of willingness to standardize.
    - JetSpiegel 7y ago
      Some are trying to, but there is a bazaar of interests. Microsoft has no competing interests, they just enforce it top to bottom. Lennart Poetering is trying to standardize from the bottom up, correctly IMHO, there's some push back, but mostly inertia and lack of resources.
    - thedaemon 7y ago
      Not exactly desktop, but for GUI Linux has GTK and QT. GTK is by far the most common and I'd say the standard. Anyone who argues is a KDE fanboy ;)
- MisterTea 7y ago
  > Doesn't that mean Linux is entirely broken? It depends on how you look at it. Linux does not break kernel-userspace but userspace libraries, like the c libraries, constantly change as security holes and bugs are patched. This is a more secure approach as updates bring in security and bug patches. The flip side is that approach can sacrifice backwards compatibility if an api interface changes or removed. This forces the developer to constantly rebuild and check if anything is broken. The idea is everyone is proactive and stays up-to-date. That's how Linux works. Microsoft's approach is to let the application developer bundle the libraries with the application if necessary. That's what all of those visual c++ updates are for when you install certain software, they install the libs the application was linked against. So your computer is littered with multiple library versions, some of which may contain security flaws. The latest approach in Linux is to bundle the application and libraries in containers. It's a hybrid approach that takes the MS idea of bundling the linked libs with the application but wrapping it up into a neat container that in theory should isolate the system from any vulnerabilities the libraries may contain.
- PhasmaFelis 7y ago
  > I mean, lots of things are wrong with Windows but I can double-click a .exe from 1998 and in most cases it'll just run. There are many old games that won't run properly on modern Windows.
wolfgke 7y ago
> 10 years is just wild. Most 20 year old Windows applications still run on Windows 10.
- deleted 7y ago
  [deleted]
badsectoracula 7y ago
> 10 years is just wild. And on Windows, a 10 year old program NOT working is extremely rare. Hell, a 20 year old program is most likely to be running too (most common issue would be the installer but usually it can be worked around). > Unless you only have libc as a dependency but I doubt that for a graphical application. You can also have xlib as a dependency and it'll work since unlike whatever madness is built on top of it, the X11 API is stable (but of course modern developers dislike that stability and want to replace it with Wayland that breaks everything again so they have new toys to play with). Example: https://i.imgur.com/YxGNB7h.png https://i.imgur.com/YxGNB7h.png (from an old toolkit of mine, showing the same binaries running in 90s RedHat and last year's Debian).
- Piskvorrr 7y ago
  [citation-needed]. Heck, I've gone as far as running Windows, a Linux VM inside, and running the old program in Wine: more likely to run that way than in Win10. I'm aware of all the impressive Windows compat work that went into keeping the Win32 ecosystem ticking, but recently (last ~2 years) this seems to have gone downhill. In the long run, it always comes down to emulation, regardless of system (e.g. Win16 is no longer a part of current Windows). Perhaps ReactOS has some promise w/r/t old Windows executables...
- rincebrain 7y ago
  To be fair, X11 sans extensions is stable, but those extensions are how they provide a lot of the more complicated functionality that's been built since X11 was born. Wayland originated, AIUI, because we've got layers upon layers of complexity and indirection to bend X11 into what we want on a more recent environment, and building a system with more awareness of what the constraints are in recent systems lets you implement things much more cleanly than those levels of complexity (or, at least, not much worse, if you're using XWayland). (Of course, it's not implausible that in 20 years or less, we'll think of Wayland as requiring lots of kludges and hacks to do what we need then, but you can only plan for known knowns and known unknowns.)

deleted 7y ago

[deleted]

skrebbel 7y ago

Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? I mean, lots of things are wrong with Windows but I can double-click a .exe from 1998 and in most cases it'll just run. I'd assume Linux, being used a lot for servers and long-running apps, would have this too?

yani 7y ago
Missing a runtime... missing dll... missing direct3d or different version of it, compatibility for certain version of Windows. It is all the same everywhere.
- wolfgke 7y ago
  On Windows, you can easily install lots of parallel versions of libraries.
  - icebraining 7y ago
    So can you on Linux. Libraries are installed with their full version in the filename (e.g. /usr/lib/libpurple.so.0.13.0) so you can keep lots of parallel versions.
ekianjo 7y ago
> Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? Not Linux, libraries instead are the ones breaking compatibility over time. Or missing libraries as well...
- badsectoracula 7y ago
  As far as the user is concerned it is "Linux", when people say they use "Linux" they do not just mean the kernel, they mean the entire OS. On Windows these libraries have APIs that remain backwards compatible (new methods can be exposed, but existing stuff remains there). Unless the equivalent Linux libraries also decide to provide backwards compatibility, they'll just make Linux look broken (even if it isn't the kernel's fault). (and no, this isn't something you solve by being pedantic about what is userspace and what is kernelspace and who controls what, as that information doesn't solve the actual problem - you solve it by cultivating a culture that actually cares about backwards compatibility)
pantalaimon 7y ago
Linux itself has this and is very strict about not breaking old userspace. It's the userspace libraries that likes to drop compatibility with old binaries left and right and with most distributions it's not possible to install old versions of libraries. Containers like Flatpack and Snap promise to solve this by just bundling the application with all the libraries it needs, frozen in time. The Kernel then can handle it.
- dijit 7y ago
  Serious question; doesn’t static compilation do the same thing essentially?
  - ObscureScience 7y ago
    Kind of, but I guess the other solutions are slightly better at accomodating services that are more than a single binary. I think static binaries really should be evaluated again as they seem to be written off by most big players. Though Go(lang) has preferred static linking which has been something that seem to have been appreciated.
    - tfigment 7y ago
      Static has its own issues. GPL vs LGPL forces a lot of apps to dynamic. Also security vulnerabilities in libraries become unpatchable.
      - AnIdiotOnTheNet 7y ago
        Apps are always the most secure when they can't run at all because of ABI changes in their dependencies.
      - chronogram 7y ago
        I’d rather be able to run something that’s security flawed than not run it at all. Those security issues in libraries are probably not such a big deal anyway, because you can run Unreal Tournament 1 multiplayer now and not immediately get hacked, I’m sure. Maybe I just got very lucky.
ObscureScience 7y ago
No Linux distributions does not work like that. The kernel interface is pretty stable but userland is not. Dynamically linked executables will not work with new versions of the libraries they depend on in most cases. This is one of the problems flatpak, snap, appimage, docker and nix/guix are trying to solve.
- v_lisivka 7y ago
  Flatpack, snap, aappimage, docker, static linking, etc. are solving other problem: how to bypass package manager and ship outdated and buggy libraries to user, because it will save some money for developer at expense of user. Whole GNU foundation was created to bash with this "solution", then Linux kernel + GNU runtime was used to create Linux distributions, which are free from binary-only distribution problem, but developers are creative. Why not just ship partially compiled binary or IR code, or obfuscated source with open-source adaptation layer? It will make adaptation problem much easier for end user at any distribution or/and architecture.
josteink 7y ago
> Doesn't that mean Linux is entirely broken? Isn't the whole point of OSes that things that used to work, keep working? "Broken" is a strong word. "Different" might be more fitting. While I don't think anyone in the world of Linux and Linux-distros work with the explicit aim of breaking compatibility, you have to realize that Linux and most Linux-distros are built entirely around open-source software. Most users install software via a distro-provided package-manager which fetches binaries from a repo. These binaries have been built from source, by the distro-vendor, specifically for that distro. That means Linux compatibility traditionally has been more about source-level and compile-time compatibility more so than 100% uncompromised binary compatibility. If a change breaks binary compatibility, but the distro/system as a whole still builds fine, that's still compatible in most day-to-day scenarios of a common Linux end-user. And unconstrained by having to maintain strict binary compatibility, it also allows developers to clean up historical garbage and technical debt they otherwise couldn't. This approach obviously has both drawbacks and advantages, but calling it "broken" seems unfair, overly opinionated and really just wrong.
- wolfgke 7y ago
  TLDR: The developers of the GNU/Linux userland libraries do not care about binary compatibility.
  - josteink 7y ago
    Binary compatibility is only a pressing issue if the majority of the software you run is closed source and not provided by your distro. Why waste time maintaining something which is not needed?
    - wolfgke 7y ago
      > Binary compatibility is only a pressing issue if the majority of the software you run is closed source and not provided by your distro. Binary compatibility is a very pressing issue if there exist software that is closed source and you want to have more users than just some nerds.
gambiting 7y ago
The main difference is that most Windows apps are statically linked. A game from 1998 will very often come with its own set of .dlls that were built with the game and unless the underlying Win32 api changed, they should "just work". On Linux it's also possible to statically link libs, but it's far less common to do so - most apps rely on the libs in the system. Which in theory is a great thing, your app will always use the latest, safest version of whatever library it needs(while the windows app continues using the unsafe 1998 version of libs for instance). But of course in practice people who make the libs can't test their changes with every single app in existence, so inevitably the back compatibility gets broken, and Linux does have the issue of "oh I installed some system updates and now this app that always worked doesn't work anymore". Again, in theory apps are supposed to say which libs they need and package managers should respect that. But theory and real life are not necessarily the same.
- SmellyGeekBoy 7y ago
  Day-to-day Linux system updates won't change major version numbers of libs in most distros, though. These breaking changes only seem to occur in major releases in my experience.
- wolfgke 7y ago
  > The main difference is that most Windows apps are statically linked. A game from 1998 will very often come with its own set of .dlls that were built with the game and unless the underlying Win32 api changed, they should "just work". Delivering a set of DLLs is not static linking.
  - Sahhaese 7y ago
    It's almost like the D in DLL stands for something. That said, it's not strictly static linking but it is closer to it in effect than the global assembly cache or the shared DLLs which resulted in the kind of "DLL hell" that windows 95 was famous for.
- badsectoracula 7y ago
  > The main difference is that most Windows apps are statically linked. No, the main difference is that on Windows the GUI libraries (USER32.DLL, etc) are considered part of the OS and have an API that remains backwards compatible. The applications are not statically linking the GUI libraries, they are dynamically linked against them, pretty much like on Linux. However on Linux the GUI libraries do not care a bit about preserving backwards compatibility (see Gtk1, Gtk2, Gtk3 and soon Gtk4, see Qt1, Qt2, Qt3, Qt4, Qt5 and soon Qt6 - although in Qt's case they cant do much thanks to C++'s ABI issues and TBH i wouldn't expect them do since Qt is primarily made by a company with interests in providing a crossplatform UI library, not the native GUI library for Linux). Windows simply provides a much richer API than Linux as a standard that applications can rely on.
SmellyGeekBoy 7y ago
Yes and no. It's a different mindset. In many cases Linux can run CLI software from the 1960s just fine but the desktop moves fast and breaks things often. The legacy support in Windows is admirable but does bloat the OS and create security and performance issues, for example. I suppose one could always fire up a VM with a 10-year-old version of Ubuntu to run older software, but it is indeed a hassle. The correct answer depends where your priorities lie.
- wolfgke 7y ago
  > Yes and no. It's a different mindset. In many cases Linux can run CLI software from the 1960s just fine but the desktop moves fast and breaks things often. Serious question to all the GNU/Linux hackers: why can't we standardize the desktop on GNU/Linux similarly?
  - v_lisivka 7y ago
    I'm ready. Will you pay for my work to achieve your goal?
    - wolfgke 7y ago
      The problem rather is that even if you do, many distributions will not obey "your" standard. EDIT: So the problem is that it is not a problem of work to be done, but a problem of willingness to standardize.
  - JetSpiegel 7y ago
    Some are trying to, but there is a bazaar of interests. Microsoft has no competing interests, they just enforce it top to bottom. Lennart Poetering is trying to standardize from the bottom up, correctly IMHO, there's some push back, but mostly inertia and lack of resources.
  - thedaemon 7y ago
    Not exactly desktop, but for GUI Linux has GTK and QT. GTK is by far the most common and I'd say the standard. Anyone who argues is a KDE fanboy ;)
MisterTea 7y ago
> Doesn't that mean Linux is entirely broken? It depends on how you look at it. Linux does not break kernel-userspace but userspace libraries, like the c libraries, constantly change as security holes and bugs are patched. This is a more secure approach as updates bring in security and bug patches. The flip side is that approach can sacrifice backwards compatibility if an api interface changes or removed. This forces the developer to constantly rebuild and check if anything is broken. The idea is everyone is proactive and stays up-to-date. That's how Linux works. Microsoft's approach is to let the application developer bundle the libraries with the application if necessary. That's what all of those visual c++ updates are for when you install certain software, they install the libs the application was linked against. So your computer is littered with multiple library versions, some of which may contain security flaws. The latest approach in Linux is to bundle the application and libraries in containers. It's a hybrid approach that takes the MS idea of bundling the linked libs with the application but wrapping it up into a neat container that in theory should isolate the system from any vulnerabilities the libraries may contain.
PhasmaFelis 7y ago
> I mean, lots of things are wrong with Windows but I can double-click a .exe from 1998 and in most cases it'll just run. There are many old games that won't run properly on modern Windows.

wolfgke 7y ago

> 10 years is just wild. Most 20 year old Windows applications still run on Windows 10.

deleted 7y ago
[deleted]

badsectoracula 7y ago

> 10 years is just wild. And on Windows, a 10 year old program NOT working is extremely rare. Hell, a 20 year old program is most likely to be running too (most common issue would be the installer but usually it can be worked around). > Unless you only have libc as a dependency but I doubt that for a graphical application. You can also have xlib as a dependency and it'll work since unlike whatever madness is built on top of it, the X11 API is stable (but of course modern developers dislike that stability and want to replace it with Wayland that breaks everything again so they have new toys to play with). Example: https://i.imgur.com/YxGNB7h.png https://i.imgur.com/YxGNB7h.png (from an old toolkit of mine, showing the same binaries running in 90s RedHat and last year's Debian).

Piskvorrr 7y ago
[citation-needed]. Heck, I've gone as far as running Windows, a Linux VM inside, and running the old program in Wine: more likely to run that way than in Win10. I'm aware of all the impressive Windows compat work that went into keeping the Win32 ecosystem ticking, but recently (last ~2 years) this seems to have gone downhill. In the long run, it always comes down to emulation, regardless of system (e.g. Win16 is no longer a part of current Windows). Perhaps ReactOS has some promise w/r/t old Windows executables...
rincebrain 7y ago
To be fair, X11 sans extensions is stable, but those extensions are how they provide a lot of the more complicated functionality that's been built since X11 was born. Wayland originated, AIUI, because we've got layers upon layers of complexity and indirection to bend X11 into what we want on a more recent environment, and building a system with more awareness of what the constraints are in recent systems lets you implement things much more cleanly than those levels of complexity (or, at least, not much worse, if you're using XWayland). (Of course, it's not implausible that in 20 years or less, we'll think of Wayland as requiring lots of kludges and hacks to do what we need then, but you can only plan for known knowns and known unknowns.)