This is very good example how engineering discussion should proceed:
The project lead (Linus) pushed back first with reasonable-looking point, but it is hit back by a thorough research. And finally a clever workaround broke it through.
It was very energizing to me who has habit to rely on non-engineering tools to push through these kind of discussions.
Speaking as someone who maintains a fair bit of legacy infrastructure for a living, the hard part is knowing what is unused and what isn't. That's the whole rationale behind Linus' "don't break user space" policy.
A quick trivia question: when you compile a program using GCC and do not specify the name of the output binary, an A.out file gets created. Is that A.out binary using the A.out format, or is it an ELF binary?
The name and the format are distinct. The linker output (the a.out file) will be in whatever is considered native by the compiler, which for most people is the format of the system they are running the compiler on.
“a.out” is barely a format: just a block of executable, a block of data initialization and an integer to say how large the (uninitialized) heap should be. Later some symbols and a bit of debugging info was added. But remember back then a lot of stuff was still written in assembler and machines were not that powerful, so something simple was not only sufficient but better.
Separating code and data wasn’t even really needed but back then it wasn’t clear that (almost) every machine would be a von Neumann architecture. There were still plenty of Harvard architecture machines (split I/ D) space. Of course these days we’ve partially circled back with write protected executable blocks and execute permission forbidden to data and stack.
When I started designing bfd in 89 or 90 I started with a.out. There were already other formats (predominantly forms of COFF) because the limitations of a.out had started to be a problem.
An aside on BFD, which doesn't seem to have come up, and I suspect relatively few people have read the History node of the ‘Binary File Descriptor’ Library manual on the back-constructed name: “The name came from a conversation David Wallace [gumby] was having with Richard Stallman about the library: RMS said that it would be quite hard--David said "BFD". Stallman was right, but the name stuck.”. [I gather that's ‘Big’, ‘Deal’, and something like an adjective.]
I was just thinking about this in the shower. The death of the Harvard architecture combined with the slow adoption of w^x seems to vindicate the problem, but I think there's a deeper truth to it: Turing complete machines can emulate any other Turing complete machine. Harvard architecture is immune to stack-smashing, but it's not immune to privilege escalations - Fundamentally, there's a usability tradeoff of "Loading new executable code from the data segment" that makes true Harvard architectures inoperable. We've settled on a happy if imperfect medium.
That also was my question. The wikipedia article on the format addresses it in the second paragraph
> "a.out" remains the default output file name for executables created by certain compilers and linkers when no output name is specified, even though the created files actually are not in the a.out format.
The NetBSD kernel still has support for a.out. On BSD, a.out is something simpler than ELF that works without any problems.^1 On Linux, a.out may have caused problems when building shared libraries thus motivating the switch to ELF.^2
1. ELF is OK, but times have changed since ELF was created. The same constraints no longer exist. Personally, I prefer static binaries and can afford the space for them. It is good to have options for people who prefer shared libraries as well as those who prefer static binaries.
> It seems to be a universal rule that somebody always has to come along to ruin the party. In this case, just as it seemed like there were no further obstacles to the removal of a.out, James Jones showed up to let it be known that he was still using a.out:
I find it surprising that the Kernel doesn't have a formal and easy way to know who is using what for the purpose of dropping support except to go fishing for complaints and hoping by chance nobody bites.
There should be something like a list of legacy features on kernel.org where people can easily subscribe to a mailing list which will ask for them to know if they still need the feature when there are plans to phase it out. A phase-out list so to speak.
Anyone can start using Linux as part of their product or environment, and so today there are literally billions of resulting end users effectively using Linux systems with uncountable configurations.
Unless you want at least every developer and system administrator in the world to subscribe to that mailing list and regularly read it, I don’t know how this can really solve the problem.
Add to that the fact that the classification of a “feature” is rather fuzzy…
There are already announcements and discussions through various channels, but at the end you can never be sure. Fortunately systems don’t have to always be updated immediately (aside from for security concerns).
I'm not sure if they "solve" this. In this current case, this was solved by working with the person that need the feature, rather than just tracking their usage of said feature.
Apple solves this by removing whatever it is they don't like anymore and expecting developers to get on with migrating to the new thing that replaces it.
Microsoft hasn't solved it, Windows is drowning in its own moat.
Halfway through the article I was wondering if it wouldn't be possible to write an ELF wrapper for a.out binaries. I was pleasantly surprised to not be the first person to consider that, and that it turned out to be easy to do.
I like the binfmt_misc suggestion in the LWN comments. The fact that I could just run a jar file like it was an executable made me unreasonably happy when I first learned about it. It was one of those things (like X11 being network transparent) that made Linux seem almost magical to me as a 90's teen. Anyway, this seems like a perfect use case for that functionality.
Even crazier: you can use binfmt_misc with qemu-user to transparently run Linux executables compiled for other architectures. Debian (and Ubuntu) packages the required configuration as "qemu-user-binfmt".
LWN.net is absolutely amazing and well worth every cent.
Just to pick one thing, their kernel index has been so useful when I run into an area of the kernel I need to learn about: https://lwn.net/Kernel/Index/
> The use case is running an old set of tools to build programs for the Atari Jaguar.
This seems really weird as an a.out removal opposition. If you're already using ancient tools to compile programs for ancient hardware, why do you need the latest kernel for it? Why not keep a VM with a system dedicated for that task which you'll never need to update or change in any way?
There's likely a single digit number of people who actually have that use case, right?
I think the question of my GP is: Aren't better new kernels better for most people than slightly worse new kernels that are better for only very, very few people? :)
It would be impossible to quantify, but all code has a maintenance cost. Removing a.out was brought up several times. That strongly implies its overhead crosses the threshold to be noticed.
Readit News
The project lead (Linus) pushed back first with reasonable-looking point, but it is hit back by a thorough research. And finally a clever workaround broke it through.
It was very energizing to me who has habit to rely on non-engineering tools to push through these kind of discussions.
Deleted Comment
“a.out” is barely a format: just a block of executable, a block of data initialization and an integer to say how large the (uninitialized) heap should be. Later some symbols and a bit of debugging info was added. But remember back then a lot of stuff was still written in assembler and machines were not that powerful, so something simple was not only sufficient but better.
Separating code and data wasn’t even really needed but back then it wasn’t clear that (almost) every machine would be a von Neumann architecture. There were still plenty of Harvard architecture machines (split I/ D) space. Of course these days we’ve partially circled back with write protected executable blocks and execute permission forbidden to data and stack.
When I started designing bfd in 89 or 90 I started with a.out. There were already other formats (predominantly forms of COFF) because the limitations of a.out had started to be a problem.
> "a.out" remains the default output file name for executables created by certain compilers and linkers when no output name is specified, even though the created files actually are not in the a.out format.
https://en.wikipedia.org/wiki/A.out
Dead Comment
1. ELF is OK, but times have changed since ELF was created. The same constraints no longer exist. Personally, I prefer static binaries and can afford the space for them. It is good to have options for people who prefer shared libraries as well as those who prefer static binaries.
2. https://people.freebsd.org/~nik/advocacy/myths.html
I find it surprising that the Kernel doesn't have a formal and easy way to know who is using what for the purpose of dropping support except to go fishing for complaints and hoping by chance nobody bites.
There should be something like a list of legacy features on kernel.org where people can easily subscribe to a mailing list which will ask for them to know if they still need the feature when there are plans to phase it out. A phase-out list so to speak.
Unless you want at least every developer and system administrator in the world to subscribe to that mailing list and regularly read it, I don’t know how this can really solve the problem.
Add to that the fact that the classification of a “feature” is rather fuzzy…
There are already announcements and discussions through various channels, but at the end you can never be sure. Fortunately systems don’t have to always be updated immediately (aside from for security concerns).
1) Some old feature, like an obscure filesystem, is causing some pain to maintain.
2) Therefore people suggest to add it to the phase-out list.
3) After some discussion it is decided it is a worthy candidate for removal and so it is placed on the phase-out list.
4) Some people starts subscribing, but not too much. Turns out it's some obscure distribution for an Atari emulator.
5) Time pass and years later these people have moved on to better things, they reply to the reminder email saying it's fine now.
6) Feature gets removed safely.
Microsoft hasn't solved it, Windows is drowning in its own moat.
Quickly sent a mail to LWN and got their authorization in the next 10 minutes.
Big up to the team and awesome content! This motivated me to buy a subscription to support them.
Just to pick one thing, their kernel index has been so useful when I run into an area of the kernel I need to learn about: https://lwn.net/Kernel/Index/
Deleted Comment
This seems really weird as an a.out removal opposition. If you're already using ancient tools to compile programs for ancient hardware, why do you need the latest kernel for it? Why not keep a VM with a system dedicated for that task which you'll never need to update or change in any way?
There's likely a single digit number of people who actually have that use case, right?
I'm generally of the mindset to keep something until there's reason to remove it.