Hacker News Reader

Comment by guardiangod | Hacker News Reader

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?

View on HN

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.

> 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

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.

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.

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)

> 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.

> 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.

> 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.

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.

Here is some game from '93. Compile it yourself (with some trivial changes).

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.

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.

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.

Which is also how Windows itself does it. Wanna run DOS or 16-bit binaries, you reach for an emulator.

It should be noted that 32-bit versions of Windows include support for 16-bit DOS and Win16 binaries. The last 32-bit version of Windows was Windows 10, which is still actively supported.

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 ;)

YSK, this code will likely fail in weird ways on platforms with default unsigned char like ARM because it makes the classic mistake of assuming that the getc return value is compatible with char type despite getc returning int and not char. EOF is -1, and assigning a char on ARM changes to 255 so you'll read past the end of some buffers and then crash.

Maybe there will be some problems on weird platforms. But if game is good some datails can be resolved. With bad games too ;) With source code, that is.

Reply on news.ycombinator.com