5.1 Merge window part 1

Posted Mar 19, 2019 21:24 UTC (Tue) by dvdeug (guest, #10998)
In reply to: 5.1 Merge window part 1 by anton
Parent article: 5.1 Merge window part 1

I thought about Windows NT, but I forgot about Win32s. But by that standard, Linux wins hands-down; it can run applications written for Unix in 1977, provided they were written in Bourne Shell. The question is running the applications that people want to run on the modern systems they're running, and the last 16-bit Windows programs came out quite a bit after the last Linux a.out programs.

Most versions of Linux can't run ix86 binaries; only those compiled for ix86 or AMD64 can. Had Intel had their way, we'd be running Itanium without direct support for ix86 binaries. Perhaps in five or ten years, we'll be running ARM64 without direct support for ix86 or AMD64 binaries.

We can better study something in its home environment, not by running it on a modern system where various things might not work (audio, modern resolutions, USB).

Out of the box, Retropie supports the ZX-Spectrum, the TI-99, the MSX, the Atari ST, the Coco, the Colecovision, the Amstrad CPC, Amiga, SAM Coupé, the Macintosh, MS-DOS and the Commodore 64, along with dozens of other, usually more gaming focused, systems. It seems unlikely emulating x86, one of the most common computer hardware platforms of all time, will be a big problem for the foreseeable future.

You're demanding that Linux accept your solution for your obscure problem; there's not that many people who ran Linux before 1996, and many of those have given up all their old binaries from the time. If you were volunteering as a maintainer, you'd have more say in if this feature stays; if you were looking for solutions to a problem, people will be more willing to help. But to demand that a feature that doesn't fully work (i.e. core dumps were broken) be the only possible solution to your problem isn't helpful.

5.1 Merge window part 1

Posted Mar 21, 2019 17:57 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

Most versions of Linux can't run ix86 binaries; only those compiled for ix86 or AMD64 can.

That's beside the point. This is not about running binaries for one architecture on other architectures, this is about removing support for a binary format, i.e., a pure software issue.

[But anyway, the statement is wrong. IA-32 binaries could be run on Linux-Alpha. Someone reported running an ARM binary of Gforth on an Intel-based Android tablet; and I expect that Android also has emulation the other way round.]

We can better study something in its home environment, not by running it on a modern system where various things might not work (audio, modern resolutions, USB).

I study and compare things in many different environments. One thing that I study is how the various versions of the software perform on hardware, both on old hardware and new hardware. And to do that, I need to run the old software on new hardware, with (necessarily) new kernels. Retropie won't help me with that. And fortunately, audio, resolutions, and USB are no problems for the stuff I do.

You're demanding that Linux accept your solution for your obscure problem

I just object to removing a feature from the kernel that I use.

If you were volunteering as a maintainer, you'd have more say in if this feature stays

Did anybody ask for a maintainer? In any case, are you suggesting that, when Linus Torvalds says "Breaking user programs simply isn't acceptable", he means "Breaking maintainer programs simply is not acceptable, but breaking non-maintainer programs is"?

But to demand that a feature that doesn't fully work (i.e. core dumps were broken) be the only possible solution to your problem isn't helpful.

The feature works better now than with the proposed change; that's why I object to the change.

Someone suggested a userspace loader for a.out binaries. When that works with little overhead, it will be acceptable for me, too, but somebody has to write it, while the kernel support exists, and works better than the current state (non-existence) of the userspace loader.

5.1 Merge window part 1

Posted Mar 21, 2019 19:53 UTC (Thu) by excors (subscriber, #95769) [Link]

> Someone reported running an ARM binary of Gforth on an Intel-based Android tablet; and I expect that Android also has emulation the other way round.

Intel developed an ARM-to-x86 binary translator (Houdini) for their Android BSP, for compatibility with popular apps that contain ARM-only native code; I suspect that's why it worked. I doubt anyone has done it the other way round, because there are approximately zero Android apps with Intel-only native code.

5.1 Merge window part 1

Posted Mar 22, 2019 0:42 UTC (Fri) by dvdeug (guest, #10998) [Link]

Then Windows is moot? Cross-Linux compatibility versus Windows was certainly was part of the original discussion.

At this point, I question the relevance of any numbers you get comparing these a.out binaries to modern systems. You're comparing a program compiled for the original Pentium with GCC 2.7 (at the latest) and libc4 to a different program natively running on a recent version of AMD64 using modern versions of GCC and GNU libc. Where the faults lay for speedups and slowdowns is going to be very hard to tell. In any case, for the near future, you can run a Linux 5.0 kernel in an virtual machine if you want to compare things.

I'm not Linus, but I'm certainly more worried about some of the lost filesystem support making file recovery quite complex than I am about forcing a.out binaries to be run via qemu or a userspace loader, if anyone cares to write one. Supporting ancient binaries is much better and easier handled by emulators than trying to maintain a 25-year old environment mixed in with a modern one.