Comment by guardiangod
3 years ago
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?
3 years ago
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?
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.
3 replies →
> 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.
2 replies →
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.