News for hackers. Stuff that matters.
Re:The Slackware Way (2012) by hulitu on Friday April 30, 2021 @09:22AM (#26993094)
> 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.

Re:The Slackware Way (2012) by specialist on Friday April 30, 2021 @11:25AM (#26994644)
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.

Re:The Slackware Way (2012) by jjtheblunt on Friday April 30, 2021 @02:16PM (#26997208)
> File systems dedupe now

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

Re:The Slackware Way (2012) by pvik on Friday April 30, 2021 @05:10PM (#26999393)