4 ms·

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 pro

by hansor 5y ago

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

nathell 5y ago
> .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).
- hansor 5y ago
  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.
1vuio0pswjnm7 5y ago
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/a.out.5 https://man.netbsd.org/NetBSD-9.0/compat_linux.8 https://man.netbsd.org/NetBSD-9.0/compat_linux.8
- hansor 5y ago
  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).
hulitu 5y ago
> 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.
- specialist 5y ago
  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.
  - jjtheblunt 5y ago
    > File systems dedupe now Huh? is there a citation to that assertion perhaps for a particular instance?
    - pvik 5y ago
      as far as I know zfs[1] and btrfs[2] support dedupe. 1 - https://constantin.glez.de/2010/03/16/opensolaris-zfs-deduplication-everything-you-need-know/ https://constantin.glez.de/2010/03/16/opensolaris-zfs-dedupl... 2 - https://btrfs.wiki.kernel.org/index.php/Deduplication https://btrfs.wiki.kernel.org/index.php/Deduplication
ok123456 5y ago
Slackware 3.0 is when they switched to ELF.

by hansor 5y ago

nathell 5y ago

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

hansor 5y ago
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.

1vuio0pswjnm7 5y ago

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/a.out.5 https://man.netbsd.org/NetBSD-9.0/compat_linux.8 https://man.netbsd.org/NetBSD-9.0/compat_linux.8

hansor 5y ago
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).

hulitu 5y ago

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

specialist 5y ago
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.
- jjtheblunt 5y ago
  > File systems dedupe now Huh? is there a citation to that assertion perhaps for a particular instance?
  - pvik 5y ago
    as far as I know zfs[1] and btrfs[2] support dedupe. 1 - https://constantin.glez.de/2010/03/16/opensolaris-zfs-deduplication-everything-you-need-know/ https://constantin.glez.de/2010/03/16/opensolaris-zfs-dedupl... 2 - https://btrfs.wiki.kernel.org/index.php/Deduplication https://btrfs.wiki.kernel.org/index.php/Deduplication

ok123456 5y ago

Slackware 3.0 is when they switched to ELF.