20 ms·

A Way Out for A.out

335 points by bitcharmer 5y ago

copperx 5y ago
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?
- necheffa 5y ago
  It has been ELF for a while now.
  - jandrese 5y ago
    Since around 1995 to be specific.
    - icedchai 5y ago
      I remember manually migrating my Slackware install from a.out to ELF around that time. Maybe it was 1996.
      - anyfoo 5y ago
        Me too, then later the same again with libc5 to glibc. Obviously learned a ton about the system by manually reconstructing it that way (using only source tarballs, no packages).
        incompatible 5y ago
        I upgraded my TAMU-based system to ELF. It seems there are a few of us "crazier people" that the article mentions still around. For several years I didn't get any distribution updates but installed new versions of packages from source instead. It was fighting GNOME updates that finally made me throw in the towel.
      - deckard1 5y ago
        '96 feels about right. I, too, was on a.out briefly on Slackware before the big ELF migration. Was actually rather smooth. Not nearly as bad as the lib32 to lib64 pain train
  - flatiron 5y ago
    On Linux. Did FreeBSD switch?
    - toast0 5y ago
      Yeah; looks like in the FreeBSD 3.0 release (October 1998), mentioned in old versions of the FreeBSD handbook[1]: > FreeBSD comes from the ``classic'' camp and used the a.out(5) format, a technology tried and proven through many generations of BSD releases, until the beginning of the 3.X branch. Though it was possible to build and run native ELF binaries (and kernels) on a FreeBSD system for some time before that, FreeBSD initially resisted the ``push'' to switch to ELF as the default format. [...] > So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF. > However, as time passed, the build tools that FreeBSD derived their build tools from (the assembler and loader especially) evolved in two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU folks that originally write these programs rewrote them and added simpler support for building cross compilers, plugging in different formats at will, and so on. Since many people wanted to build cross compilers targeting FreeBSD, they were out of luck since the older sources that FreeBSD had for as and ld were not up to the task. The new GNU tools chain (binutils) does support cross compiling, ELF, shared libraries, C++ extensions, etc. In addition, many vendors are releasing ELF binaries, and it is a good thing for FreeBSD to run them. > ELF is more expressive than a.out and allows more extensibility in the base system. The ELF tools are better maintained, and offer cross compilation support, which is important to many people. ELF may be a little slower than a.out, but trying to measure it can be difficult. There are also numerous details that are different between the two in how they map pages, handle init code, etc. None of these are very important, but they are differences. In time support for a.out will be moved out of the GENERIC kernel, and eventually removed from the kernel once the need to run legacy a.out programs is past. It looks like default support of a.out was removed in 5.0 (January 2003), but you can still load a kernel module (shipped with the generic kernel) or compile a custom kernel with support built in. At least on i386/amd64. [1] https://docs.freebsd.org/doc/4.9-RELEASE/usr/share/doc/handbook/binary-formats.html https://docs.freebsd.org/doc/4.9-RELEASE/usr/share/doc/handb...
    - bell-cot 5y ago
      From a quick look at the FreeBSD 13.0-RELEASE Release Notes ( https://www.freebsd.org/releases/13.0R/relnotes/ https://www.freebsd.org/releases/13.0R/relnotes/ ) and the a.out-related commits that it links to, I'd say that FreeBSD is close to having a.out fully walked to the door. (They suggest installing a ~2-decade-old version of FreeBSD if you still need to work with a.out...)
  - pjmlp 5y ago
    Aix uses COFF, which makes it interesting being the only UNIX with import libraries similar to Windows.
- technothrasher 5y ago
  Why a.out format, of course… on my Sun 3/80.
- gumby 5y ago
  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.
  - GauntletWizard 5y ago
    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.
    - gumby 5y ago
      Van neumann is more general and provides more flexibility (what if you need more data space and don't need all that code space?). There are still new harvard architecture microcontrollers being designed. It provides some security in the field as well as simplifying the chip layout.
      - ludamad 5y ago
- hoten 5y ago
  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. https://en.wikipedia.org/wiki/A.out https://en.wikipedia.org/wiki/A.out
- sedatk 5y ago
  Is it even possible to create a.out format binaries on the latest GCC? "objdump -i" doesn't show it as an option on my Ubuntu.
  - mueddib 5y ago
    yes. please learn -g3 and -Wl and --oformat parameter (gcc). objdump -i only display (info).
    - mueddib 5y ago
      Wl (linker) oformat (output format try a.out)
- bumblebritches5 5y ago
jabyess 5y ago
Once again, XKCD[0] proved to be right [0] https://xkcd.com/1172/ https://xkcd.com/1172/
- larusso 5y ago
  Thank you sir. I had to laugh so damn hard. It‘s such a nice parody about these discussions in the kernel which I actually love. I would appreciate if more software producers would stop breaking or removing features because they think in percentages of users who will be pissed etc. on the other hand it can become quite silly. I had a good laugh thanks again :)
jandrese 5y ago
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.
- flatiron 5y ago
  Are you referring to https://www.freebsd.org/cgi/man.cgi?query=brandelf&sektion=1 https://www.freebsd.org/cgi/man.cgi?query=brandelf&sektion=1 ?
  - jandrese 5y ago
    No, that only works on ELF and was intended to make it easier for the Linuxulator to distinguish between FreeBSD and Linux ELF binaries.
- pavon 5y ago
  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.
  - duskwuff 5y ago
    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".
    - gnufx 5y ago
      For what it's worth, qemu-user-static is more general, e.g. for a foreign container image that won't find the shared library. (Wheeled out when it was said people needed to build ppc64le images on x86 boxes and it was impossible, rather than trivial.)
flakiness 5y ago
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.
- zamalek 5y ago
  And engineering in general, it is a great day when someone notices that something is unused and pushes for its removal.
  - bityard 5y ago
    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.
    - duxup 5y ago
      > knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”
      - girvo 5y ago
        My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...
    - inopinatus 5y ago
      Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
      - ketzo 5y ago
TeeMassive 5y ago
> 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.
- lloydatkinson 5y ago
  Windows and macOS solves this by the much hated "user tracking" (aka analytics).
  - Zababa 5y ago
    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.
    - yyyk 5y ago
      "The" person. How do we know there's only one? Well, in this case, the story was sexy enough to be transmitted all the way to HN. Also two decades have passed. But in general, the 'post removal notice on some list and hope people notice' isn't a good method.
  - tonyedgecombe 5y ago
    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.
- anyfoo 5y ago
  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).
1vuio0pswjnm7 5y ago
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. 2. https://people.freebsd.org/~nik/advocacy/myths.html https://people.freebsd.org/~nik/advocacy/myths.html
linkdd 5y ago
I wrote a french translation to this article[0] without noticing I was in violation of their copyright (my bad). 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. [0] - https://linuxfr.org/users/linkdd/journaux/lwn-une-porte-de-sortie-pour-a-out-63380a9d-20e0-44de-979d-74afcb6f3910
- rwiggins 5y ago
  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/ https://lwn.net/Kernel/Index/
- deleted 5y ago
  [deleted]
donatj 5y ago
I'm curious how much overhead and developer-time keeping a.out support adds? I'm generally of the mindset to keep something until there's reason to remove it.
- incompatible 5y ago
  Perhaps it's potentially an attack vector for security holes, and removing it means no more worries?
  - userbinator 5y ago
    ELF seems like a bigger attack surface due to its complexity.
- manfre 5y ago
  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.
genr8 5y ago
Kees Cook is a legend. Actually wrote a new ELF wrapper for a.out binaries !
rayiner 5y ago
Excellent and publicly available book on this subject if you find it interesting: https://www.iecc.com/linker/ https://www.iecc.com/linker/
malkia 5y ago
Wow... This level of backward compatibility + dedication to support (even if for that rare case) reminds me of the good old days of Windows!
viraptor 5y ago
> 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?
- CyberRabbi 5y ago
  Because new kernels are better than old kernels.
  - dxdm 5y ago
    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? :)
    - CyberRabbi 5y ago
      If your point is that a.out support makes kernels worse for everyone else, you can simply compile it out and it will not affect you. The issue is keeping the code in tree. Its inclusion doesn’t affect the quality of the kernel, its just a maintenance burden.
  - viraptor 5y ago
    In what way specifically are they better for the use case of compiling Atari Jaguar software using decades old toolchain?
    - CyberRabbi 5y ago
      If I want to run these binaries on my daily driver, it’s much easier if I don’t have to start up a VM. I want the latest Linux kernel on my daily driver for hopefully self-evident reasons.
tomcam 5y ago
What… what’s bad about a.out? It seems to be the default executable produced by GCC? I read the article but I couldn’t quite understand what the problem is to begin with. Is it a seldom used or outmoded executable format that is used for nothing but the default output or what?
- varajelle 5y ago
  From the Wikipedia entry on a.out: > "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.
  - tomcam 5y ago
    So you just rename the file, right? I honestly don’t understand why this is a big deal. Though in general I have always thought it was weird that UNIX defaults to that name instead of the name of the main source file.
    - HoppyHaus 5y ago
      GCC a.out is an ELF file (except in extremely rare circumstances). "a.out" as a executable format is like ELF, but different and practically no longer used. This is a proposal to remove the latter
      - tomcam 5y ago
        Ah! Thanks.
underdeserver 5y ago
I'm surprised nobody asked for the title to be changed from "A.out" to "a.out".
pjmlp 5y ago
> Still, Linux used a.out for some time, until support for the newfangled ELF format was first added to the 0.99.13 development kernel in 1993. When I got Slackware 2.0 as my first Linux distribution, the CD-ROM box had a sticker asserting "now with ELF support!" kind of statement.

335 points by bitcharmer 5y ago

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?

necheffa 5y ago
It has been ELF for a while now.
- jandrese 5y ago
  Since around 1995 to be specific.
  - icedchai 5y ago
    I remember manually migrating my Slackware install from a.out to ELF around that time. Maybe it was 1996.
    - anyfoo 5y ago
      Me too, then later the same again with libc5 to glibc. Obviously learned a ton about the system by manually reconstructing it that way (using only source tarballs, no packages).
      - incompatible 5y ago
        I upgraded my TAMU-based system to ELF. It seems there are a few of us "crazier people" that the article mentions still around. For several years I didn't get any distribution updates but installed new versions of packages from source instead. It was fighting GNOME updates that finally made me throw in the towel.
    - deckard1 5y ago
      '96 feels about right. I, too, was on a.out briefly on Slackware before the big ELF migration. Was actually rather smooth. Not nearly as bad as the lib32 to lib64 pain train
- flatiron 5y ago
  On Linux. Did FreeBSD switch?
  - toast0 5y ago
    Yeah; looks like in the FreeBSD 3.0 release (October 1998), mentioned in old versions of the FreeBSD handbook[1]: > FreeBSD comes from the ``classic'' camp and used the a.out(5) format, a technology tried and proven through many generations of BSD releases, until the beginning of the 3.X branch. Though it was possible to build and run native ELF binaries (and kernels) on a FreeBSD system for some time before that, FreeBSD initially resisted the ``push'' to switch to ELF as the default format. [...] > So ELF had to wait until it was more painful to remain with a.out than it was to migrate to ELF. > However, as time passed, the build tools that FreeBSD derived their build tools from (the assembler and loader especially) evolved in two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU folks that originally write these programs rewrote them and added simpler support for building cross compilers, plugging in different formats at will, and so on. Since many people wanted to build cross compilers targeting FreeBSD, they were out of luck since the older sources that FreeBSD had for as and ld were not up to the task. The new GNU tools chain (binutils) does support cross compiling, ELF, shared libraries, C++ extensions, etc. In addition, many vendors are releasing ELF binaries, and it is a good thing for FreeBSD to run them. > ELF is more expressive than a.out and allows more extensibility in the base system. The ELF tools are better maintained, and offer cross compilation support, which is important to many people. ELF may be a little slower than a.out, but trying to measure it can be difficult. There are also numerous details that are different between the two in how they map pages, handle init code, etc. None of these are very important, but they are differences. In time support for a.out will be moved out of the GENERIC kernel, and eventually removed from the kernel once the need to run legacy a.out programs is past. It looks like default support of a.out was removed in 5.0 (January 2003), but you can still load a kernel module (shipped with the generic kernel) or compile a custom kernel with support built in. At least on i386/amd64. [1] https://docs.freebsd.org/doc/4.9-RELEASE/usr/share/doc/handbook/binary-formats.html https://docs.freebsd.org/doc/4.9-RELEASE/usr/share/doc/handb...
  - bell-cot 5y ago
    From a quick look at the FreeBSD 13.0-RELEASE Release Notes ( https://www.freebsd.org/releases/13.0R/relnotes/ https://www.freebsd.org/releases/13.0R/relnotes/ ) and the a.out-related commits that it links to, I'd say that FreeBSD is close to having a.out fully walked to the door. (They suggest installing a ~2-decade-old version of FreeBSD if you still need to work with a.out...)
- pjmlp 5y ago
  Aix uses COFF, which makes it interesting being the only UNIX with import libraries similar to Windows.
technothrasher 5y ago
Why a.out format, of course… on my Sun 3/80.
gumby 5y ago
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.
- GauntletWizard 5y ago
  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.
  - gumby 5y ago
    Van neumann is more general and provides more flexibility (what if you need more data space and don't need all that code space?). There are still new harvard architecture microcontrollers being designed. It provides some security in the field as well as simplifying the chip layout.
    - ludamad 5y ago
hoten 5y ago
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. https://en.wikipedia.org/wiki/A.out https://en.wikipedia.org/wiki/A.out
sedatk 5y ago
Is it even possible to create a.out format binaries on the latest GCC? "objdump -i" doesn't show it as an option on my Ubuntu.
- mueddib 5y ago
  yes. please learn -g3 and -Wl and --oformat parameter (gcc). objdump -i only display (info).
  - mueddib 5y ago
    Wl (linker) oformat (output format try a.out)
bumblebritches5 5y ago

jabyess 5y ago

Once again, XKCD[0] proved to be right [0] https://xkcd.com/1172/ https://xkcd.com/1172/

larusso 5y ago
Thank you sir. I had to laugh so damn hard. It‘s such a nice parody about these discussions in the kernel which I actually love. I would appreciate if more software producers would stop breaking or removing features because they think in percentages of users who will be pissed etc. on the other hand it can become quite silly. I had a good laugh thanks again :)

jandrese 5y ago

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.

flatiron 5y ago
Are you referring to https://www.freebsd.org/cgi/man.cgi?query=brandelf&sektion=1 https://www.freebsd.org/cgi/man.cgi?query=brandelf&sektion=1 ?
- jandrese 5y ago
  No, that only works on ELF and was intended to make it easier for the Linuxulator to distinguish between FreeBSD and Linux ELF binaries.
pavon 5y ago
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.
- duskwuff 5y ago
  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".
  - gnufx 5y ago
    For what it's worth, qemu-user-static is more general, e.g. for a foreign container image that won't find the shared library. (Wheeled out when it was said people needed to build ppc64le images on x86 boxes and it was impossible, rather than trivial.)

flakiness 5y ago

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.

zamalek 5y ago
And engineering in general, it is a great day when someone notices that something is unused and pushes for its removal.
- bityard 5y ago
  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.
  - duxup 5y ago
    > knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”
    - girvo 5y ago
      My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...
  - inopinatus 5y ago
    Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
    - ketzo 5y ago

TeeMassive 5y ago

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

lloydatkinson 5y ago
Windows and macOS solves this by the much hated "user tracking" (aka analytics).
- Zababa 5y ago
  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.
  - yyyk 5y ago
    "The" person. How do we know there's only one? Well, in this case, the story was sexy enough to be transmitted all the way to HN. Also two decades have passed. But in general, the 'post removal notice on some list and hope people notice' isn't a good method.
- tonyedgecombe 5y ago
  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.
anyfoo 5y ago
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).

1vuio0pswjnm7 5y ago

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. 2. https://people.freebsd.org/~nik/advocacy/myths.html https://people.freebsd.org/~nik/advocacy/myths.html

linkdd 5y ago

I wrote a french translation to this article[0] without noticing I was in violation of their copyright (my bad). 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. [0] - https://linuxfr.org/users/linkdd/journaux/lwn-une-porte-de-sortie-pour-a-out-63380a9d-20e0-44de-979d-74afcb6f3910

rwiggins 5y ago
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/ https://lwn.net/Kernel/Index/
deleted 5y ago
[deleted]

donatj 5y ago

I'm curious how much overhead and developer-time keeping a.out support adds? I'm generally of the mindset to keep something until there's reason to remove it.

incompatible 5y ago
Perhaps it's potentially an attack vector for security holes, and removing it means no more worries?
- userbinator 5y ago
  ELF seems like a bigger attack surface due to its complexity.
manfre 5y ago
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.

genr8 5y ago

Kees Cook is a legend. Actually wrote a new ELF wrapper for a.out binaries !

rayiner 5y ago

Excellent and publicly available book on this subject if you find it interesting: https://www.iecc.com/linker/ https://www.iecc.com/linker/

malkia 5y ago

Wow... This level of backward compatibility + dedication to support (even if for that rare case) reminds me of the good old days of Windows!

viraptor 5y ago

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

CyberRabbi 5y ago
Because new kernels are better than old kernels.
- dxdm 5y ago
  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? :)
  - CyberRabbi 5y ago
    If your point is that a.out support makes kernels worse for everyone else, you can simply compile it out and it will not affect you. The issue is keeping the code in tree. Its inclusion doesn’t affect the quality of the kernel, its just a maintenance burden.
- viraptor 5y ago
  In what way specifically are they better for the use case of compiling Atari Jaguar software using decades old toolchain?
  - CyberRabbi 5y ago
    If I want to run these binaries on my daily driver, it’s much easier if I don’t have to start up a VM. I want the latest Linux kernel on my daily driver for hopefully self-evident reasons.

tomcam 5y ago

What… what’s bad about a.out? It seems to be the default executable produced by GCC? I read the article but I couldn’t quite understand what the problem is to begin with. Is it a seldom used or outmoded executable format that is used for nothing but the default output or what?

varajelle 5y ago
From the Wikipedia entry on a.out: > "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.
- tomcam 5y ago
  So you just rename the file, right? I honestly don’t understand why this is a big deal. Though in general I have always thought it was weird that UNIX defaults to that name instead of the name of the main source file.
  - HoppyHaus 5y ago
    GCC a.out is an ELF file (except in extremely rare circumstances). "a.out" as a executable format is like ELF, but different and practically no longer used. This is a proposal to remove the latter
    - tomcam 5y ago
      Ah! Thanks.

underdeserver 5y ago

I'm surprised nobody asked for the title to be changed from "A.out" to "a.out".

pjmlp 5y ago

> Still, Linux used a.out for some time, until support for the newfangled ELF format was first added to the 0.99.13 development kernel in 1993. When I got Slackware 2.0 as my first Linux distribution, the CD-ROM box had a sticker asserting "now with ELF support!" kind of statement.