undefined

points

[-]

I can't even run a binary from one Linux distro to the other, let alone one from a random Unix from the 80s. If a rebuild from source is allowed (which would need to allow modifications to the build system) that's a completely different game.

by xattt13 hours ago|

parent|

[-]

    > I can't even run a binary from one Linux distro to the other

Is this actually a thing?

by kragen8 hours ago|

parent|

[-]

Yesterday I built a binary in an Ubuntu 24.04 Podman container and tried to run it on my Debian Bookworm system:

    [filename]: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by [filename])

Because I have glibc 2.36, you see.

The other way around works fine, though, and you can avoid it by statically linking the binary when you build it.

by jeroenhd11 hours ago|

parent|

prev|

[-]

I had to run a Linux binary compiled for Ubuntu 10.something a few years ago. I couldn't get the drivers to work properly in libvirt and getting the binary to run on modern Linux was practically impossible, even with 32 bit support installed.

The downside of dynamically linked binaries: every tool of medium complexity needs a close-enough version of a common library, and once those get upgraded, the tool dies.

Most statically compiled version should work with a compatible enough libc, but I haven't seen many old programs like that.

Wine, on the other hand, runs tools from the 90s just fine, as long as they're 32 bit.

by boomlinde1 hours ago|

parent|

[-]

AFAIK Wine will run 16-bit applications just fine now, through WoW64.

by 0x020313 hours ago|

parent|

prev|

[-]

Many programs are dynamically linked to at the very least, libc. If the system libc is older than what the binary was developed for, it will often fail. Failures going the other direction are less common, but can and do still happen. If the binary was statically linked with everything it needs, you've got a pretty good chance it'll work, but that's a bit harder to do with GUI programs that need to interact with X or Wayland.

by the__alchemist13 hours ago|

parent|

prev|

[-]

It depends. I've found for example, if i compile on Ubuntu or Debian, it will probably work on any Ubuntu, Debian, or Debian-based distro released at or newer than the one I compiled it on. There are other cross-compatible examples.

More broadly, there are things like manylinux and MUSL which allow cross-distro applications.

by martijnvds13 hours ago|

parent|

[-]

Containers fix this.

As long as the container bundles the right libc, the program should work.

by mrheosuper4 hours ago|

parent|

[-]

Just like Python venv, The system is too broken that it's the only real practical fix

by the__alchemist12 hours ago|

parent|

prev|

[-]

I agree - the model I use for why containers (Docker etc) exist is to abstract over Linux ABI incompatibility. I don't think they're a great solution, as it complicates software distribution. I should be able to distribute an executable and have it just work.

by Rohansi4 hours ago|

parent|

[-]

Linux isn't the source of the incompatibility. The kernel itself is very strict about not breaking userspace. Your userspace is breaking compatibility on its own, containers fix it by shipping the userspace components within the container, which only works because the kernel maintained compatibility. If the kernel broke compatibility you would need to use a VM so you can run a different kernel version.

by toast08 hours ago|

parent|

prev|

[-]

That's what win32 is for...

by the__alchemist7 hours ago|

parent|

[-]

Hah well yes for Windows. This is a mercy, but my mindset is still "Works on Windows, Linux and Mac". (The last being dropped for anything that requires Cuda...)

by toast06 hours ago|

parent|

[-]

Win32 is the stable ABI for Linux, too.

by dekhn12 hours ago|

parent|

prev|

[-]

I've had static binaries on linux machines that worked across distributions for decades.

by layer813 hours ago|

prev|

[-]

As an unmodified binary from the 1980s on current Linux/Unix? Highly unlikely.

by ndiddy13 hours ago|

parent|

[-]

From the article, the time to beat is November 16, 1992. This might be possible on one of the BSDs, as FreeBSD and NetBSD both document support for running a.out executables with the 4.3BSD ABI. I guess it would depend on whether anyone had ported X11 to run on a BSD on i386 before then. Alternatively, maybe you'd be able to get something running on SCO OpenServer (if you count that as a current OS, it IS still getting security patches). It documents support for XENIX x.out binaries ( https://www.scosales.com/ta/kb/126704.html ) so you might be able to run software compiled in the late 1980s for XENIX/386.

by spijdar12 hours ago|

parent|

[-]

NetBSD has excellent binary compatible with 80s "unix", the problem is most (all?) of the 80s unix platforms it supports aren't x86.

Current NetBSD still has good support for running SunOS binaries, though, including graphical ones. I'm certain you could get a SunOS 4.x binary from pre-1992 to run on NetBSD/SPARC. I've no idea how far back you could potentially go on NetBSD/m68k -- probably quite a ways, especially if the binaries are statically linked. SunOS pre-1988 was all static linking!

(Running "real" 4.3BSD binaries might be hard -- I think NetBSD/VAX defaults to ULTRIX compat, which is an either/or thing versus strict Berkeley Unix compatibility. Same binary format, similar but incompatible syscalls/data structures.)

by dvh13 hours ago|

prev|

[-]

Just used xev today (bought new mouse few days ago and it wasn't responding in chrome so I wanted to be sure).

by LeFantome10 hours ago|

prev|

[-]

xwm from 1984 and twm from 1989 will still execute on Xorg today.

And if you want to run them on Wayland, Worg will do that for you. https://github.com/jmalcolm137/Worg

by 13 hours ago|

prev|

[-]

deleted