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!).
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.
> 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.
> .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.
When I was around 14, some time in the 90s, I contacted a guy whose ad I had read in a paper magazine by calling him over the landline phone and I asked him to burn Slackware on CDs for me. I sent him something like ~$60 over the mail and a few weeks later I got a package with the CDs. He even printed the covers for them. Today I get mad when a web site says my free download will start in 10 seconds.
There were recent news about Patrick putting together a new version of Slackware, the most recent one being from 2016 according to http://www.slackware.com/. Does anyone have any info to share? I can definitely see the attraction of Slackware as a VLTS (very-long term support) Linux distro with taste ie no systemd, reasonable DE, no change to upstream packages unless absolutely necessary, etc. especially with the stagnation of Linux desktop apps, or desktop apps in general with the exception of Electron-based apps and Chromium-only webapps.
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 being a "beta" isn't really the same thing as most other distros being in beta. Beta here means that it's extremely stable but doesn't yet meet the (very high) standards of the team and what packages they want to have in a release called 'official'.
Slackware-current is a rolling distro that receives updates daily. That's where you go to find more information. The forum at linuxquestions.org or IRC sees some discussions, Slackware was never a mailing-list heavy project.
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.
Of course it is. It's just slow enough that you can take your time to get to know tge dependency graph and how to build everything to the point that it's not as big a deal if you don't have a legion of volunteers doing everything for you.
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.
I remember taking a c++ class back in highschool, and being really annoyed that I didn't have a copy of borland at home. My teacher told me about this system called 'unix', and I got a free shell account with the university of colorado, complete with a copy of g++. I could code from home! So I started really liking unix, and I emailed the admin to ask how I could get root (lol). He told me about linux. I bought a cd set copy of slackware because I was on 14.4 dailup at the time. I install it, and I remember being blown away at having so much software to compile basically any language I wanted! Still use linux as my daily driver ~ 25 years later.
When I first heard of Linux in the late 90's, one of the main selling points for Linux was that it came with a free compiler. It is strange to think there was a time when people had to buy a boxed copy of a compiler to code.
I used Slackware for 20 years. Finally gave up this year when I wanted to upgrade and no word on when 15.0 was coming out. Now I use a popular distro, so if I need something to work, somebody has already done it and I can just get it installed without development work. Definitely sucks compared to Slack, but I'm just too old to keep futzing around trying to make simple things work.
(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)
Yeah it has been frustrating, and the limitations of a small team and basically one man making all the major decisions and changes has been on display for a while now.. add to that the store falling apart and Pat's financial problems.
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.
Not OP, but I'll pitch in because I'm an old Slackware user (late 90s to late 2000s).
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.
If you want to understand how a distribution works, I can't think many better distributions. I have a lot of fond memories of slackware. I eventually switched to debian when, I think, I had troubles getting vmware to work. I'm happy with debian but I definitely feel I've swapped understanding and control for convenience. Linux is a lot less fun now but since I now want to spent my time elsewhere that's a decent tradeoff for me.
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.
Slackware was my alternative to Gentoo at the time. Gentoo was cool because it was all compiled, more efficient etc. That shit sounded good to me as a teenager. I remember one summer I had the Gentoo ISO all burnt on a CD-R and stayed up all night to watch it install and compile on my Athlon Thunderbird PC (My parents didn't spend money much on computers and I had to make do with stuff that I saved for with birthday money). I fell asleep on a bean bag and woke up finding that it failed to compile something. I had to resort to asking the main IRC channel and message board to help me fix it, but I didn't have time :) I was disappointed as a 14 year old. I then downloaded Slackware and printed off the installation guide at school. I followed it to the T and it worked. It was fun and awesome because it allowed me to understand how things worked under the hood and provided insights on how a linux system hung together. Those days in the 00s are gone but the memories are still there.
Gentoo on an IBM Thinkpad (IIRC a 900Mhz Celeron + 384MB memory) was my laptop in college. Aside from a few beasts (KDE or Gnome, for which you'd end up needing to have at least the libs to run much in X even if you didn't use those DEs, OpenOffice [holy crap, maybe the single longest compile?] and to a lesser extent Firefox) the compiling wasn't really that bad.
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.
Hah, I have similar memories about installing Gentoo for the first time. I remember printing out the installation handbook on a ton of pages because at the time the computer i was installing it on was my only access to the internet.
Slackware was the first Linux I managed to successfully setup on my home PC back in 2000, dial-up modem driver including, and was quite happy with it, it taught me everything I know about Linux.
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.
Readit News
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.
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.
https://man.netbsd.org/a.out.5
https://man.netbsd.org/NetBSD-9.0/compat_linux.8
From my memories NetBSD was very fast, but 1.3.1 did not have any pkgsrc yet (so no easy software compilation).
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.