11 ms·

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 Wi

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 8y 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 8y ago
  On Windows, you can easily install lots of parallel versions of libraries.
  - icebraining 8y 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 8y 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 8y 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 8y 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 8y ago
  Serious question; doesn’t static compilation do the same thing essentially?
  - ObscureScience 8y 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 8y ago
      Static has its own issues. GPL vs LGPL forces a lot of apps to dynamic. Also security vulnerabilities in libraries become unpatchable.
      - AnIdiotOnTheNet 8y ago
        Apps are always the most secure when they can't run at all because of ABI changes in their dependencies.
      - chronogram 8y 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 8y 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 8y 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 8y 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 8y ago
  TLDR: The developers of the GNU/Linux userland libraries do not care about binary compatibility.
  - josteink 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y ago
    I'm ready. Will you pay for my work to achieve your goal?
    - wolfgke 8y 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 8y 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 8y 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 8y 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 8y 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.

yani 8y 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 8y ago
On Windows, you can easily install lots of parallel versions of libraries.
- icebraining 8y 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 8y 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 8y 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 8y 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 8y ago
Serious question; doesn’t static compilation do the same thing essentially?
- ObscureScience 8y 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 8y ago
    Static has its own issues. GPL vs LGPL forces a lot of apps to dynamic. Also security vulnerabilities in libraries become unpatchable.
    - AnIdiotOnTheNet 8y ago
      Apps are always the most secure when they can't run at all because of ABI changes in their dependencies.
    - chronogram 8y 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 8y 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 8y 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 8y 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 8y ago
TLDR: The developers of the GNU/Linux userland libraries do not care about binary compatibility.
- josteink 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y 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 8y ago
  I'm ready. Will you pay for my work to achieve your goal?
  - wolfgke 8y 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 8y 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 8y 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 8y 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 8y 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.