6 ms·

I can run a Windows 95 app on Windows 10 and it has a reasonable chance of success. Should Linux (userland) strive for that? Or is Year of the Linux Desktop on

I can run a Windows 95 app on Windows 10 and it has a reasonable chance of success. Should Linux (userland) strive for that? Or is Year of the Linux Desktop only covers things compiled in the last 10 years?

deleted 4y ago
[deleted]
ivraatiems 4y ago
It's what the kernel strives for. They're remarkably consistent in their refrain of "we never break userspace." I think it would be reasonable for glibc and similar to have similar goals, but I also don't run those projects and don't know what the competing interests are.
- pantalaimon 4y ago
  > I think it would be reasonable for glibc and similar to have similar goals I don’t think userspace ever had this goal. The current consensus appears to be containers, as storage is cheap and maintaining backwards compatibility is expensive
  - lpghatguy 4y ago
    Containers are not a great solution for programs that need graphics drivers (games) or quick startup times (command line tools). I've been wrestling with glibc versioning issues lately and it has been incredibly painful. All of my projects are either games or CLI tools for games, which means that "just use a snap/flatpak/appimage" is not a solution.
    - bityard 4y ago
      There's no reason launching a container _must_ be slow. Under the hood, launching a containerized process is just making a few kernel syscalls that have very little overhead. You might be thinking of docker, which is slow because it's intended for certain use cases and brings a lot of baggage with it in the name of backward compatibility from a time when the Linux container ecosystem was much less mature. There are several projects working on fast, slim containers (and even VMs) with completely negligible startup times. I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it.
      - vetinari 4y ago
        > I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it. Cloud providers have graphics hardware with SR-IOV support. It is exactly the kind of functionality, that the GPU vendors use for segmentation of their more expensive gear.
      - bnieuwen 4y ago
        The problem with containers and graphics drivers is that those drivers have an userspace component. This depends on the hardware (e.g. AMD vs. Intel vs. NVidia all have different drivers of course) and in the case of NVidia this has to be exactly matched with the kernel version (this is less of an issue with VMs, but then you need something like SR-IOV which isn't quite on consumer HW, or do dedicated PCIE throughput which doesn't allow the host to use it). So version management becomes a major pita, from shipping drivers too old to support the hardware to having a driver that doesn't match the kernel. In the cloud this is mostly solved by using VMs and hardware with SR-IOV. (and a fixed HW vendor so you know which set of drivers to include)
Woodi 4y ago
Here is some game from '93. Compile it yourself (with some trivial changes). https://github.com/DikuMUDOmnibus/ROM https://github.com/DikuMUDOmnibus/ROM Trivial ! But if you still have some obiections then let's wait ~27 years and then talk about games developed on Linux / *nix.
- erk__ 4y ago
  Does that not miss the point of the above poster, this does not show that Linux have good binary compatibility, but that C is a very stable language. Would it run fine if you compiled it on a 27 year old compiler and then tried to run it on Linux is the question that should be asked if I am not mistaken.
  - Woodi 4y ago
    I think it shows that compiling is prefered way to go. So it's more like twisting around the point :) But what with old, binary only games ? Same as with old movies you want to watch and Hollywood prefers to not show anymore... They are super stupid IMO but maybe they have their reasons. And that DT_HASH lack can be easily patched if someone wants. And if GNU will keep to sabotage like this then there is time to move off GNU. Ah, right - noone wants to sponsor libc fork for few years... Maybe article is right about binaries after all ;)
  - janef0421 4y ago
    Is it really a reasonable goal to want an operating system to run a 27 year old binary without any modification or compatibility tool? There does need to be some way to run such binaries, but doing that by making the kernel and all core ABIs stable over several decades would make evolving the operating system very difficult. I think it would be better to provide such compatibility via compatibility layers like wine and sandboxing in the style of flatpak.
    - kibwen 4y ago
      Which is also how Windows itself does it. Wanna run DOS or 16-bit binaries, you reach for an emulator.
CommanderData 4y ago
Just try changing your hosts or nameservers across different versions of Ubuntu Server. The fragmentation is such a mess even between 1.x major versions. Their own documentation is broken or non existant.
SubjectToChange 4y ago
> Should Linux (userland) strive for that? The linux "userland" includes thousands of independent projects. You'll need to be more specific. > Or is Year of the Linux Desktop only covers things compiled in the last 10 years? If you want ABI compatibility then you'll have to pay, it's that simple. Expecting anything more is flat out unreasonable.
- cbarrick 4y ago
  > The linux "userland" includes thousands of independent projects. You'll need to be more specific. I think it's pretty clear from the context. The core GNU userland: glibc, coreutils, gcc, etc.

deleted 4y ago

[deleted]

ivraatiems 4y ago

It's what the kernel strives for. They're remarkably consistent in their refrain of "we never break userspace." I think it would be reasonable for glibc and similar to have similar goals, but I also don't run those projects and don't know what the competing interests are.

pantalaimon 4y ago
> I think it would be reasonable for glibc and similar to have similar goals I don’t think userspace ever had this goal. The current consensus appears to be containers, as storage is cheap and maintaining backwards compatibility is expensive
- lpghatguy 4y ago
  Containers are not a great solution for programs that need graphics drivers (games) or quick startup times (command line tools). I've been wrestling with glibc versioning issues lately and it has been incredibly painful. All of my projects are either games or CLI tools for games, which means that "just use a snap/flatpak/appimage" is not a solution.
  - bityard 4y ago
    There's no reason launching a container _must_ be slow. Under the hood, launching a containerized process is just making a few kernel syscalls that have very little overhead. You might be thinking of docker, which is slow because it's intended for certain use cases and brings a lot of baggage with it in the name of backward compatibility from a time when the Linux container ecosystem was much less mature. There are several projects working on fast, slim containers (and even VMs) with completely negligible startup times. I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it.
    - vetinari 4y ago
      > I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it. Cloud providers have graphics hardware with SR-IOV support. It is exactly the kind of functionality, that the GPU vendors use for segmentation of their more expensive gear.
    - bnieuwen 4y ago
      The problem with containers and graphics drivers is that those drivers have an userspace component. This depends on the hardware (e.g. AMD vs. Intel vs. NVidia all have different drivers of course) and in the case of NVidia this has to be exactly matched with the kernel version (this is less of an issue with VMs, but then you need something like SR-IOV which isn't quite on consumer HW, or do dedicated PCIE throughput which doesn't allow the host to use it). So version management becomes a major pita, from shipping drivers too old to support the hardware to having a driver that doesn't match the kernel. In the cloud this is mostly solved by using VMs and hardware with SR-IOV. (and a fixed HW vendor so you know which set of drivers to include)

Woodi 4y ago

Here is some game from '93. Compile it yourself (with some trivial changes). https://github.com/DikuMUDOmnibus/ROM https://github.com/DikuMUDOmnibus/ROM Trivial ! But if you still have some obiections then let's wait ~27 years and then talk about games developed on Linux / *nix.

erk__ 4y ago
Does that not miss the point of the above poster, this does not show that Linux have good binary compatibility, but that C is a very stable language. Would it run fine if you compiled it on a 27 year old compiler and then tried to run it on Linux is the question that should be asked if I am not mistaken.
- Woodi 4y ago
  I think it shows that compiling is prefered way to go. So it's more like twisting around the point :) But what with old, binary only games ? Same as with old movies you want to watch and Hollywood prefers to not show anymore... They are super stupid IMO but maybe they have their reasons. And that DT_HASH lack can be easily patched if someone wants. And if GNU will keep to sabotage like this then there is time to move off GNU. Ah, right - noone wants to sponsor libc fork for few years... Maybe article is right about binaries after all ;)
- janef0421 4y ago
  Is it really a reasonable goal to want an operating system to run a 27 year old binary without any modification or compatibility tool? There does need to be some way to run such binaries, but doing that by making the kernel and all core ABIs stable over several decades would make evolving the operating system very difficult. I think it would be better to provide such compatibility via compatibility layers like wine and sandboxing in the style of flatpak.
  - kibwen 4y ago
    Which is also how Windows itself does it. Wanna run DOS or 16-bit binaries, you reach for an emulator.

CommanderData 4y ago

Just try changing your hosts or nameservers across different versions of Ubuntu Server. The fragmentation is such a mess even between 1.x major versions. Their own documentation is broken or non existant.

SubjectToChange 4y ago

> Should Linux (userland) strive for that? The linux "userland" includes thousands of independent projects. You'll need to be more specific. > Or is Year of the Linux Desktop only covers things compiled in the last 10 years? If you want ABI compatibility then you'll have to pay, it's that simple. Expecting anything more is flat out unreasonable.

cbarrick 4y ago
> The linux "userland" includes thousands of independent projects. You'll need to be more specific. I think it's pretty clear from the context. The core GNU userland: glibc, coreutils, gcc, etc.