Hacker News Reader

Comment by jepler | Hacker News Reader

I thought we didn't break userspace

Linux does break userspace. It's inevitable. But everyone takes care it doesn't happen and if you report the regression immediately it will be fixed.

But if it's broken for 3 years and you didn't say anything, nobody will make a fix for it. Or it's unlikely.

A.out isn't used anymore. Like, not even the most ancient linux machines are likely to use a.out format. It's atm going to be hidden behind a flag, default off, if nobody complains then it'll be completely removed in a few releases.

What userspace applications will it break? I suppose that there may be some setups using a.out yet, but I have a hard time imagining that operators of such systems are holding their breath for the next version of the kernel.

Sure. But is there an a.out userspace? How do you make a.out binaries on linux today?

Isn't a.out the default output format of gcc? I think if you type "gcc myfile.c" you get an a.out executable.

It's named a.out, but that's just a legacy convention. It's still an ELF file.

No, you get a file named a.out by default, but it's not in that format.

No it's just the file name. If you run `file` on it, it'll tell you it's an ELF image.

The name has stuck for some reason, but actually the output format is ELF.

Here it refers to the binary executable file format not the default file name gcc uses after compilation.

a.out is a very old format superseded by ELF.

https://en.wikipedia.org/wiki/A.out

As others have pointed out it's an elf file called a.out.

I would like to ask who's idea it was to name GCCs default output after a completely different file format ?!

The format was named for the file, not the file for the format. By the time this became incongruous, it was too late to fix.

gcc copied most of its command-line arguments from older compilers, including -o, and the default value if -o isn't set was also copied.

So the command-line arguments and defaults are older than the ELF format. When ELF support was added, the question was: Should the default value for -o depend on other arguments? There didn't seem to be good reason to have a complicated default, and keeping the simple default provided compatibility with old scripts and makefiles.

cd tests ; for a in *.c ; do gcc $a && ./a.out ; done

“Don’t break userspace” also means that I should be able to run a binary that I recover from a tape backup made in 1992.

I assume that binary used shared libraries?

I still have the file system from a linux host I installed in 1999 or 2000. Debian; I made a VM copy when I retired the iron. It doesn't have a.out shared libraries, so even if the kernel's support worked in 2000, I could't run that binary for lack of shared libraries.

If the kernel's support hasn't really been tested for 19-20 years and the shared libraries haven't even been built, then I think running that binary has very poor chances of working.

I'm not trying to weigh in on the debate here, but it's perfectly reasonable to imagine having a statically linked binary that you wanted to run..

Absolutely.

Now, if you agree that shared libraries haven't been available for a long time and that coredumps haven't worked for a long time, that doesn't mean that nothing works. That doesn't mean that every case has been broken. But I think it means that the support has been very lightly tested for a long time now, or not tested at all. And assuming that something works when it hasn't been tested for a long time is ugh.

I think the reason I care about this is dogmatic. I believe, dogmatically, that untested code is broken. If you accept that dogma and do not test a.out support now, then the coming change does not break a.out. If you do test, fine. If you disagree that untested code is broken, fine. If you say it "might imaginably work" or somesuch, fine.

We are speaking of userspace generated between 1992 and 1995. At that time, linux was installed from floppy disks. Do you think there is someone who still has a floppy drive, who needs recent versions of linux and who has so old programms still working ?

Linus has a policy: Don't break userspace. See https://felipec.wordpress.com/2013/10/07/the-linux-way/

That's a great blog post; it's not just about the policy, but talks about some people who disagree, provides a lot of links, and is just generally better than anything I could hope to write here. I'll only observe that I'm not endorsing anything except that that's a pretty good post. I'm just pointing out the context, not arguing for or against "don't break userspace" personally.

>Linus has a policy: Don't break userspace

He's also pragmatic. He will break userspace in 100 ways if it's needed.

Linus has somewhat recently clarified that position regarding old stuff; they break userspace if the break has happened years ago and nobody said anything in the meantime about it. If you notice upgrading from 2.5 to 4.20 breaks your app, nobody at the LKML or any subsystem maintainer is likely to fix it.

A.out is so positively ancient that it's likely been broken for years, nobody is testing or using it in live systems anymore.

Well they are not. Yet. It is a deprecation notice and at some point they will break userspace. You're quote is a matter of context.

When Linus say never break userspace, I understand it as : never break userspace without warning and consensus over an alternative. Don't break the userspace to force it to evolve or fix things. Fix it there first and then deprecate.

It is not the same thing.

They could reimplement it using the kernel's general binfmt support. It's really just getting rid of some legacy code.

Reply on news.ycombinator.com