Hacker News Reader

Comment by hansor | Hacker News Reader

I love Slackware. Best distribution to learn. I had to learn it all - without internet, just man pages and "HOW-TO" manuals (it is a shame that we no longer produce them!).

https://tldp.org/HOWTO/HOWTO-INDEX/howtos.html

Started with 7.0 and 8.1 in ~2003, but soon I discovered that older versions were using a.out binary format instead of modern ELF. A.out binary format was amazing - binaries used MUCH less memory, and were faster in general in comparison to modern "ELF".

For example system with ELF could not run at 4MB of ram without extreme swapping, but a.out (like Slackware 3.9 AFIK) could without much problems.

I never understood why a.out binaries went out of fashion :(

Fun fact: older versions of Slackware were using EGCS instead of GCC compilers.

View on HN

> For example system with ELF could not run at 4MB of ram without extreme swapping, but a.out (like Slackware 3.9 AFIK) could without much problems.

> I never understood why a.out binaries went out of fashion :(

Storage was expensive. The promise of ELF was shared libraries. The idea was that a lot of libraries are used by a lot of programs so splitting the code between the main program and the shared library is a good thing.

The idea has not lived to its promise. Shared libraries in OSS are tending to became a DLL hell. There are also a lot of libraries with duplicated functionality which makes things even worse.

> Fun fact: older versions of Slackware were using EGCS instead of GCC compilers.

This was a good thing. Just like today with llvm. GCC was resting in its 7 day and nobody bothered to update it for the new stuff. Then EGCS came out and gave GCC a kick in the butt, helping to continue.

I just had a stupid, weird notion:

File systems dedupe now, right? IIRC, per storage block.

What if linkers aligned dependencies to the storage block boundaries?

Then let the file system find and dedupe those libraries.

A bit like applying the alignment of data structures in memory (to optimize performance) at the expense of size inefficiency.

> File systems dedupe now

Huh? is there a citation to that assertion perhaps for a particular instance?

as far as I know zfs[1] and btrfs[2] support dedupe.

1 - https://constantin.glez.de/2010/03/16/opensolaris-zfs-dedupl...

2 - https://btrfs.wiki.kernel.org/index.php/Deduplication

> .out binary format was amazing - binaries used MUCH less memory, and were faster in general in comparison to modern "ELF".

I'd be interested in seeing this claim backed by some data. I remember running Monkey Linux (ELF-based, libc5; it might have been a Slackware derivative) on a 4-meg 486SX/33; it ran quite smoothly (until you tried to run X).

You might be right that it was not due the a.out format alone. Now I remember that at the same time there was some huge migration from libc5 to glibc!

Maybe it was composition of libc5 + a.out + egcs that gave us speed(no swappng) back then.

I might do some benchmark on "PCEM" emulator (only proper emulator for old hardware as it retains original speed of cpu, memory and hard drives) in my spare time.

Unless things have changed, NetBSD kernels can still run a.out binaries, including Linux a.out binaries.

https://man.netbsd.org/a.out.5

https://man.netbsd.org/NetBSD-9.0/compat_linux.8

I remember dualbooting NetBSD 1.3.1(and 1.6) and Slackware 7(and 3.x) at 386SX 33Mhz with 4MB of RAM :)

From my memories NetBSD was very fast, but 1.3.1 did not have any pkgsrc yet (so no easy software compilation).

Slackware 3.0 is when they switched to ELF.

Reply on news.ycombinator.com