I have used multiple distros including descendants of Debian (Knoppix, lubuntu, edubuntu, ubuntu, Mint), as well as Debian. I have been using Slackware for the last 12 years. My experience is that:
1. Slackware uses ncurses for installation, while Debian uses GUI. Slackware offers more granular control over partioning, package installation (including whether one wants a GUI or not), and it uses less memory during the installation. Debian installation does not offer the same degree of control, but it could be perceived as more convenient (depending on the user's perception)
2. Slackware uses SysVinit while Debian relies on SystemD. While, it could take ages to break the differences down. I find that I could manage and edit files in SysVinit a lot more than I can manage SystemD. The whole operating system requirements are far less in Slackware than Debian
3. By default Debian does not install firm-ware unless explicitly instructed, so, if one has a Wi-Fi card which is proprietary, one needs to make sure to take note.
4. Package Management: this has been covered earlier, but, once one gets to grip with installation from Slackbuilds , , , and or compilation from source code, it makes for a sleeker OS, at the expense of taking few more steps than installation from binary via in Debian. Yet, if the library dependencies are available one can install from binary on Slackware.
5. CLI: With Slackware the shell has all the commands and software one could imaging, with Debian a lot of command line based software would have to be installed manually. So, if one is more reliant on CLI Slackware packages makes it easier to have a head start
6. GUI: Slackware comes bundled with KDE, Xfce, WindowMaker, Blackbox, Fluxbox, etc. With Debian, GNOME, MATE, Cinnamon, LXDE could be installed. Both could be tweaked to install almost any Desktop Environment or Window Manager
7. Stability: both are stable in general, but, I has way-less system freeze with Slackware than Debian.

To sum up, Slackware and Debian are different in multiple aspects, I guess it comes down to the philosophy that binds each distro. For Slackware it is the most I dare add that Slackware is all about empowering the user, having a simple transparent distro, where the user is in full control of the distro, which makes for a sleek, stable operating system. It may be perceived as difficult if some one is coming from a background where every decision is ready made for the user with only buttons to click are OK or Cancel, or an operating system that is centered on GUI point and click.

For Debian the main philosophy is to create .

I would add that Debian is about ease of use (GUI based - point and click), convenience in the sense that the user does not have to think much about how the system works, and strict adherence to FOSS principles esp with respect to firm-ware, at the expense that if one wants to do certain customisations eg custom keyboard layout, or dual input method etc. It becomes a lot trickier manage that.

Yes, I learned about that „integration” in the BSD world long ago, and... I realized it actually doesn't that matter! As long, as everything works as intended — who cares?

Slackware is the oldest surviving Linux distribution and also one of the most distinctive. People who come freshly to it, after perhaps having used another Linux distribution for a couple of years, often experience a degree of culture shock

To put it another way: Slackware is „the most BSD-ish” Linux distribution. Slackers can find themselves „at home” when having a need to use FreeBSD or any other xBSD.

Hi,

thanks for your relpy.
Ok, I missunderstood that part of your blog. Thanks for clarifying. What you are describing is that there is not a necessarily a 1-to-1, but often a 1-to-many mapping between a source (upstream) package and binary package(s). This is a feature that I really like, it gives more fine-grained control over what is installed.

For sure. There are many of these sorts of packages. One that springs to mind is a very simple terminal emulator called foot which is split up into three separate packages in Debian.

However, I think a strength of Debian is the amount of effort that is put into making sure that packages meet a certain level of quality to minimise the chance that things are broken. As I see it, the problems occur with poorly crafted packages, and when packaging low quality or unstable software. I think this is what is seen in many Debian derivatives. Almost a sort of cargo cult way of doing things. Just copy what they think Debian is doing... but pull packages from the unstable repositories and add their own "secret sauce".

Ok.

Cheers,

Evo2.

Hi,

this provides an interesting insight to Slackware for me. However, there seem to be some misconceptions about how other distros do things. Eg

While this has been approximately true for the last 10 years or so, there is not a fixed release schedule like there is for Ubuntu.
This is also true for Debian.

I'm not sure if this is accurate. In debian packages the dependencies are declared in the "control" file of each package. Not in a central database. apt reads the dependency information for the package control file and acts accordingly.

Interesting. So when a security issue is found in a library that is replicated across multiple Slackware packages, how is it addressed? Is it patched by Slackware developers in each package? And if so, the "You get vanilla builds" idea seems to not be really the case. I'm genuinely curious about this. Sorry if this information is readily available online - if so, I'd appreciate being pointed to it.

Thanks for the enlightening reading.

Cheers,

Evo2.

I think hazel's style is too different from the style of the philosophy page for her to have a good time editing it. I am not sure the end-result of that "frankenpage" would be very good either. I do find this blog to be very good though and imho, would deserve its own entry in the wiki.

I have nothing to add or complain about, but I've been finding your journals quite informative.

To me this blog post looks more like "what makes Slackware special" (which distinct it not only from Debian but also from other distributions) than a guide for new slackers.

If I were a new slacker I would rather look first for practical information to quickly find my way: how to install, what are the main tools, what main packages are included, where is the documentation... As partially found in the links listed in https://docs.slackware.com/ under the title "Getting Started" with Slackware but all in a single page.

As an aside I have tried to provide something like that long ago in https://docs.slackware.com/howtos:mi...with_slackware but the editors refused to put a link to it on the front page so probably few people came across it).

This being said, as-is its content is interesting: maybe you could use it to expand https://docs.slackware.com/slackwarehilosophy so that it gets the exposure it deserves.

Small nitpicks:
1. The sentence "all the packaging tools are simple POSIX-compliant Bourne shell scripts" is inaccurate, as they contain many "bashisms" (constructs available in bash but not defined by POSIX sh) so running them in other shells than bash will often fail.
2. Maybe it is worth mentioning that in Slackware 15.0 the packages database is in /var/lib/pkgtools (notwithstanding the handy symlinks to the previous locations).

"Linux has always been about choice", yes, at least in the past, but less so these days sadly. Corporatism and "easyism" has affected GNU, whom is the principal behind choice and freedom. I'm not complaining that you say Linux, marely stating the driver behind freedom and choice, which some or many corporate sponsors want to suppress or get rid of (thus the attacks on GNU in various forms, but not attacks on Linux). Thus the corporate sponsored "open source" movement etc etc.

Great post by the way! Thanks

I just now noticed you're doing the blog thing... my goodness, these are excellent articles. Carry on!

(I also see there's an RSS feed for my convenience!)

Not to mention meson/ninja. Seems there's another new build system almost every other week.

Personally, I stick with simple, hand crafted makefiles. I have held the belief for a while now that GNU autotools is a case of "cure is worse than the disease", primarily owing to the additional complexity it introduces.

Unfortunately, you have to use whatever the upstream developers decided when you're building other folk's software.

You forgot to mention CMake. It's being used a lot now instead of configure.

Hi Hazel,

I enjoyed reading this.

Thanks!

Thank you, Hazel. This is a good start at shining a light on the man pages.

Thank you for making the Man Page more understandable.