jbovlaste

I ran Slackware for ~6 years, my first serious distro. It's kind of the perfect learning distro for Linux - a super stable base, but if you want more you need to learn how to do it yourself. You didn't need to compile your own kernel or set up tons of configuration just to boot, but if you wanted certain graphics drivers or other software, you quickly learned how to write shell scripts and manage builds and dependencies. I remember spending quite a few hours learning how to build my own media stack with mpv and all dependencies (Slackware only shipped with MPlayer in those days, and with no system ffmpeg). I found it to be a much better experience for that than other distros like Arch or Void, those are just too much at the beginning. Because of Slackware, for a good while my most comfortable programming language was bash!

I stopped using it when I had less time for tweaking my computer in my life (I moved to Debian), but it was a very formative experience. Good defaults, but with all the power to change whatever you want and the simplicity to make it manageable.

Happy birthday Slackware!

Got into Linux in 2008 with no knowledge and no help, Slackware was the first distro I successfully installed (after trying Debian).

I tried Slackware after hearing the phrase "If you use RedHat, you learn RedHat. If you use Debian, you learn Debian. If you use Slackware, you learn Linux." Also, I had an old computer and very poor internet, so the all-in-one DVD approach appealed to me. I downloaded the Slackbook and got to it, and it patiently taught me what a filesystem was, how boot works, what X was, how to use the terminal, and so on.

Other operating systems took a lot of that for granted! They assumed I had resources, and Slackware would work with pretty well nothing. If Slackware took more time to use, time was all I had! And if Slackware made me learn things to use it properly, it was well worth it! Even now, 14 years later, lots of skills I learned are still useful - bash, the boot process, compiling software, managing dependencies (I once wanted ffmpeg with all dependencies coming from subversion, so I coded up an updater/build manager in 100% shell! Slackware taught me to do that :)

I used it for many years, distro hopping in the background, before eventually migrating to Debian. Life moved on, and I had less time to deal with "how do I build THIS from source?" and I wanted something that would help me out a bit more.

Slackware has given me an appreciation for stability. There is really something big about lasting decades. I can use those things, and also the things I know today, rather than having half the things I knew two years ago going in the bin.

Bit of a ramble. I suppose I have a lot of affection for the distro, it was a formative environment for me.

Breaking over new warnings seems crazy, but that can be one of the prices of stability. C, Perl, JavaScript and others have similar problems and come to their own solutions.

(For instance, C has warnings under the -W flags and you could enable them all at compile time with -Wall, but then people depended on the specific flags under that option so there's also -Wextra now.)

Stability means sometimes you stay still when there are good reasons to move, though there's always a balance. Perhaps a larger solution is needed (more prevalent version pinning, or an ASDF 4.0), but this may be a tempest in a teapot. We'll see how this particular issue shakes out.

Ubuntu made the switch to dash back in 2006 to decrease boot times, as dash is much faster than bash. This was upstreamed to Debian. POSIX compatibility made the transition easier (as most scripts were made to run on many Unix systems, not just Linux), but was not the motivation for the switch.

https://wiki.ubuntu.com/DashAsBinSh

I'm probably late to the discussion, but if anybody finds this looking up macros later, I found the HOPL IV paper Hygienic Macro Technology[1] to be a thorough look at the subject that hardly gets mentioned. It turns out solving these sorts of problems elegantly isn't some technique that the author has missed, it's an active area of research. Newer Lisps compete by having new ways of constructing macros that avoid these problems (say, Racket's syntax-parse[2].)

[1] https://dl.acm.org/doi/10.1145/3386330

[2] https://docs.racket-lang.org/syntax/stxparse.html