The Slackware Way (2012)
docs.slackware.com
docs.slackware.com
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.
> 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.
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.
Huh? is there a citation to that assertion perhaps for a particular instance?
1 - https://constantin.glez.de/2010/03/16/opensolaris-zfs-dedupl...
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).
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.
From my memories NetBSD was very fast, but 1.3.1 did not have any pkgsrc yet (so no easy software compilation).
Mon Apr 12 20:07:12 UTC 2021
I'm going to go ahead and call this a beta […]
Mon Feb 15 19:23:44 UTC 2021
Here we go again... upgraded to glibc-2.33 and one last mass rebuild for Slackware 15.0.Slackware stable (and the home page) has several years between new releases. Security updates mostly follows upstream projects, just don't expect the same commitment as fully staffed projects like Fedora or Ubuntu, everything is in there but may lag a day or two sometimes.
Patches: https://mirrors.slackware.com/slackware/slackware64-14.2/pat...
Last changed yesterday. Seems supported to me.
I use it for my personal servers. Keeps things nice and stable so I can learn the quirks of individual packages. Like the differences between the various terminal emulators.
(That said, now my CPU fan is blowing basically all the time even if I change CPUfreq settings to minimum, which is very annoying. Also, modern desktop/windowing environments are trash, and everything runs slower on this machine now)
You going to go back when 15 drops or has that ship sailed? I don't blame anyone for dropping even -current with it taking so long for KDE5/XFCE 14.6 to get added to the main tree. ktown was nice but it just more hassle to maintain it, I don't like doing anything beyond multilib for additional management.
Slack was as close as you got to the system you would get if you compiled everything from scratch. Basically, you just had Pat do the package selection and compiling for you. Even the package manager was really just a script to compile the source package. That made for a really clean, simple setup and made it easier to get support for software directly from project forums or mailing lists. If you had an idea of the dependency graph, it was dead easy to troubleshoot because there was no package maintainer making choices that you (or the developer) didn't know about, which cannot be said for Debian.
I really liked it, but Linux got more complicated and I got more busy and eventually I just wanted a system with sane defaults and a choice of DE. Slackware is very opinionated about its package selection and developers have shifted to the reality of systemd so now it's sometimes more of a hassle to get a package working out of the box. As apt improved, I also had fewer issues with Debian, though its sometimes out-of-date repos are frustrating because apt makes compiling from source more complicated than it was on Slack.
If you want the Slack philosophy of close to upstream but the convenience of a modern distro, I think Fedora is the good choice, but I have a soft spot for Slack.
https://www.techradar.com/news/software/operating-systems/th...
Quote:
Give a man Ubuntu, and he'll learn Ubuntu. Give a man SUSE, and he'll learn SUSE. But give a man Slackware, and he'll learn Linux. Well, so the old internet maxim goes, but while it's normally used with a touch of humour, there's a great deal of truth in it too.
Only non-Apple laptop I've had where suspend-to-disk worked every time. I don't know exactly what the deal was, but the IBM firmware had some feature that took care of it for you if you added a correctly-typed, sufficiently-large partition at the right spot on the disk. It just worked.
Things are 10x more complex now, it seems you need Docker or a browser to run most software, I miss the simplicity of just configure && make && make install.
I installed it from a CD that I bought at MicroCenter.
Slackware showed you the internals and I learned so much about compiling and systems architecture during the few years I was using Slackware.
When Ubuntu came around it was the first time I was able to plug in a USB stick and have it recognized immediately and I had to do some paid work to put food on the table.
Slackware is an excellent distribution for learning and I'm glad I used it in my early days.
Glad to see it continues to survive so many years later.
Thanks for a great life, Patrick.