LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Blogs > hazel
User Name
Password

Notices


Rating: 4 votes, 5.00 average.

Why Slackware is not like Debian: a guide for new slackers

Posted 02-09-2022 at 12:12 PM by hazel
Updated 01-30-2024 at 12:29 AM by hazel

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. There are a lot of posts in the Slackware forum on this site which amount to "I did A in my new Slackware system and the result was B when most distros would have given me C. Why does Slackware behave like this?" If they then get the answer, "That illustrates the Slackware philosophy. If you don't like it, go elsewhere.", they may well do precisely that.

Now I am not going to say that Slackware is the best Linux distro around because I think that kind of talk is silly. The best Linux distro for anyone is the distro they feel most comfortable using, the one that chimes best with their individual way of using their computer. Linux has always been about choice. But to choose well, you need to know why a distro is the way it is, and why it perhaps does not do things in the same way as some other distro. None of the things that distinguish Slackware from other distros is there by chance.

To begin with, Slackware is very much the dream child of one man, Patrick Volkerding. Nowadays, he has a devoted team to assist him but he remains the BDFL (Benevolent Dictator For Life) and all final decisions rest with him, including what software to include and when to release a new version. This gives Slackware a personal stamp which some confuse with eccentricity. For example, many distros have a fixed release cycle: Debian releases come out every two years and Ubuntu releases every six months. A Slackware release comes out when it is ready and not before.

The same is true about Patrick's choice of software, especially those core packages which have many applications dependent on them, creating potential security implications. Here the Slackware choice is to use only tried and tested software, which has been around for long enough to have had most of the bugs knocked out of it. For example, Slackware has adopted PAM and elogind for release 15.0, which has just come out; they were not part of Slackware before, although most other distros have been using PAM for authentication for a long time. A recent review of Slackware 15 described it disparagingly as a "drafty old castle" rather than a modern home. But you can actually make yourself very snug and comfy using Slackware precisely because it has never confused fashionable novelty with good practice.

One of the chief aims of Slackware is simplicity, but it is worth pointing out that the word "simple" (like the word "free") has two different meanings. Very often people use "simple" to mean "easy" or "novice-friendly". Slackware is not particularly easy for the novice Linux user, but it is internally simple by deliberate design. Simplicity in this sense is the opposite of complexity. It means the avoidance of unnecessary things that might go wrong. In practice simple means robust and good-tempered. People who habitually use Slackware often say that it "just works".

One way of looking at this is to say that someone or something has to do the work. If the user doesn't want to do it, the system has to. And such a system cannot possibly be simple in the sense described above. For example, most modern Linux distros have package managers that explicitly handle the dependency relationships between packages, usually by means of a central dependency database. If you install an application, the libraries and other dependencies that it requires will be downloaded and installed first. The package manager does all that so that you don't have to. When this works, it's brilliant, but there is an awful lot that can go wrong. If the central database becomes corrupt, it is very difficult to fix. And sometimes removing a program can trigger the cascading removal of large parts of the system simply because of dependency relationships. This is the main reason why Slackware hasn't gone in for dependency tracking. Instead it provides the full system as an installation image. Install everything and all dependencies will automatically be met.

But there's a lot more to Slackware package management than just not handling dependencies. Everything is directed to making things simple and foolproof. For example, all the packaging tools are simple bash scripts and not binary programs dependent on various libraries. If you use the low-level pkgtools programs, the only real dependencies are glibc, bash and coreutils (plus tar and xz for unpacking). And the packages themselves are simple x-zipped tarballs rather than the complex structures used by some other distros. All that the tools really need to do is to unpack the files to their final destinations, run the included post-install script, and update the plain text records in /lib/pkgtools/packages. There is not a lot that can go wrong! A higher-level update manager, slackpkg (comparable with Debian's apt), also takes the form of a bash script.

Package management in a more general sense is easy in Slackware because the installation tools provide as a by-product a huge amount of information about installed and removed packages. Each installed package has a text file in /lib/pkgtools/packages which lists its size (both compressed and expanded) and a list of the files it contained with full pathnames. If there was a separate installation script, which is usually the case, that goes into the /var/lib/pkgtools/scripts directory so that it can be examined at any time. /var/lib/pkgtools/removed_packages and /var/lib/pkgtools/removed_scripts allow you to backtrack where necessary. It is easy to determine what package a file belongs to just by using standard utilities.

NOTE: Before Slackware-15, these directories were under /var/log, not /var/lib/pkgtools and there are still symbolic links from those locations for the benefit of old-timers.

Another feature of Slackware is that it does not constantly fiddle with the internal structure of software. You get vanilla builds, made from the source code that the developer created, and containing precisely the files that the developer intended it to contain. For example, libraries come complete with their headers and documentation, just as if you had built them yourself from source. This makes it relatively easy to build additional software locally: you don't need to install any separate "library-dev" packages. Distros like Debian often separate out not only library headers but other bits and pieces too, to help deal with dependencies. If a certain package contains a library that several other packages make use of, it gets filleted out and turned into an independent package, which then becomes an additional dependency for the parent package. You do not get that kind of fragmentation in Slackware.

What if you don't want to do a full install? A lot of people prefer to start small and build up. Some indeed may need to do so because of limited download bandwidth, especially now when it is no longer possible to simply order an installation DVD by post. For that kind of thing, a Debian-style net install is ideal. Built-in dependency tracking should ensure that all the additional packages that you request work from the get-go. Slackware is not designed to be installed that way, but that doesn't mean that it can't be done! It just needs some degree of understanding of how Linux systems are put together and the ability to use error messages reported to a terminal and tools like ldd to track down missing dependencies by hand. Some helpful people have also written scripts to automate the process; I use one called brokenpkg.sh by orbea.

If simplicity is one guiding principle of Slackware, another is that the system administrator is in charge and not the distro developer! No other distro gives you so much freedom to change things. The key to Slackware packages is Pat's invention of the slackbuild. Every package in standard Slackware is built using a slackbuild, which is available for download alongside the source code. A slackbuild is simply a small tarball containing everything you need to build a Slackware package except the actual source code. You unpack it, copy the source tarball into the resultant directory, and then edit the ancillary files where necessary before launching the build. The product is a binary package ready for installation.

The most important file in a slackbuild is the .Slackbuild shell script. This contains the actual build instructions, including the chosen configuration options. If you don't like these, you can easily change them before running the script. This makes Slackware infinitely customisable. You could not safely do anything like this in Debian because everything has to dovetail exactly to avoid spooking the dependency tracking.

In addition to official Slackware, large numbers of additional slackbuilds are available to download from www.slackbuilds.org. This is somewhat similar in feel to Arch's AUR repository. All the slackbuilds in it are provided by members of the Slackware user community. They all assume that you have a full Slackware installation, as recommended, but they will tell you about any additional dependencies that you need to install. You download the source tarball using the link provided. Alternatively there are some useful binary packages available from community repositories such as Alien Bob's.

Slackware takes the same traditional Unix attitude to system administration in general. You are expected to know what the main system configuration files in /etc are and how to edit them. It is usually safe to do so precisely because there is no complex intermediate layer of management software depending on them. That is one reason why I cannot imagine Slackware ever moving to systemd.

Of course all of this assumes that you do actually know what you are doing! That is why I do not usually recommend Slackware for novices, and it may be why Slackware does not provide its users with a glitzy graphical installer. You need to be fairly comfortable with the command line interface to really enjoy using Slackware, so having to use CLI to install the distro makes a lot of sense. It's not intellectual snobbery as some people suppose, but simply a way of ensuring a good match between distro and users. In short: if you are the kind of person who likes this kind of thing, then this is the kind of thing you will like.
Posted in Slackware
Views 6136 Comments 12
« Prev     Main     Next »
Total Comments 12

Comments

  1. Old Comment
    "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
    Posted 02-09-2022 at 12:26 PM by zeebra zeebra is offline
  2. Old Comment
    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).
    Posted 02-09-2022 at 04:39 PM by Didier Spaier Didier Spaier is offline
    Updated 02-09-2022 at 05:26 PM by Didier Spaier
  3. Old Comment
    Thanks for spotting the nits! I've corrected them.

    If you look at my original post (no.31 in the "sticky" thread) you will see that what I envisaged was from the beginning a more philosophical introduction and not an installation guide because I'm not qualified to write that. I have never done a proper Slackware installation! But I was getting rather tired of all the misunderstandings between slackers and non-slackers; the forum is clogged up with threads of that kind.

    If there was a proper up-to-date installation guide, someone else would have to write it and imho it should be a sticky in the Slackware Installation subforum, not the main Slackware forum.
    Posted 02-10-2022 at 06:05 AM by hazel hazel is offline
  4. Old Comment
    I have nothing to add or complain about, but I've been finding your journals quite informative.
    Posted 02-16-2022 at 04:58 PM by Reziac Reziac is offline
  5. Old Comment
    Quote:
    Originally Posted by Didier Spaier View Comment

    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.
    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.
    Posted 02-24-2022 at 12:09 PM by MightyBaba MightyBaba is offline
    Updated 02-20-2023 at 10:00 AM by MightyBaba
  6. Old Comment
    Hi,

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

    Quote:
    Debian releases come out every two years
    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.
    Quote:
    A Slackware release comes out when it is ready
    This is also true for Debian.

    Quote:
    For example, most modern Linux distros have package managers that explicitly handle the dependency relationships between packages, usually by means of a central dependency database.
    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.

    Quote:
    If a certain package contains a library that several other packages make use of, it gets filleted out and turned into an independent package, which then becomes an additional dependency for the parent package. You do not get that kind of fragmentation in Slackware.
    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.
    Posted 02-26-2022 at 03:31 AM by evo2 evo2 is offline
  7. Old Comment
    Thanks for updating me about Debian. I was not aware that the Debian database was distributed in this way.

    With regard to the "filleting out" of libraries, what I had in mind was the Debian practice of extracting a library such as libcups from the package to which it properly belongs so that it rather than the whole package becomes a dependency for the other packages that make use of it. It also of course then becomes a dependency for its mother package.

    And it's not just libraries. For example findutils has been split up so that locate is now a separate package. All this just complicates the package management system and provides further points at which something can go wrong.

    I don't know how Slackware deals with genuine overlap such as those utility programs which are found in both shadow and util-linux. I assume the same way that LFS does: by simply not building the duplicate programs.
    Posted 02-26-2022 at 05:42 AM by hazel hazel is offline
  8. Old Comment
    Hi,

    thanks for your relpy.
    Quote:
    Originally Posted by hazel View Comment
    With regard to the "filleting out" of libraries, what I had in mind was the Debian practice of extracting a library such as libcups from the package to which it properly belongs so that it rather than the whole package becomes a dependency for the other packages that make use of it. It also of course then becomes a dependency for its mother package.
    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.

    Quote:
    Originally Posted by hazel View Comment
    And it's not just libraries. For example findutils has been split up so that locate is now a separate package. All this just complicates the package management system and provides further points at which something can go wrong.
    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".

    Quote:
    Originally Posted by hazel View Comment
    I don't know how Slackware deals with genuine overlap such as those utility programs which are found in both shadow and util-linux. I assume the same way that LFS does: by simply not building the duplicate programs.
    Ok.

    Cheers,

    Evo2.
    Posted 02-27-2022 at 06:45 PM by evo2 evo2 is offline
  9. Old Comment
    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.
    Posted 07-15-2022 at 07:54 AM by SlackWar SlackWar is offline
  10. Old Comment
    Maybe, but there is one enormous difference between Slackware and any kind of BSD. All BSD variants that I know of are made up of a fully integrated binary core plus additional ports and packages. Gentoo is constructed in this way but Slackware is not. The Slackware "full install" philosophy seems to me to be the antithesis of BSD.
    Posted 07-15-2022 at 02:26 PM by hazel hazel is offline
  11. Old Comment
    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?
    Posted 07-15-2022 at 02:36 PM by SlackWar SlackWar is offline
  12. Old Comment
    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
    Code:
     tar
    ,
    Code:
     chmod +x
    ,
    Code:
    ./
    , and
    Code:
    installpkg
    or compilation from source code, it makes for a sleeker OS, at the expense of taking few more steps than installation from binary via
    Code:
    sudo apt-get install
    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
    Quote:
    "UNIX-like" Linux distribution out there. Slackware complies with the published Linux standards, such as the Linux File System Standard. [Slackware has] always considered simplicity and stability paramount, and as a result Slackware has become one of the most popular, stable, and friendly distributions available.
    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
    Quote:
    a free operating system, freely available for everyone. Now, when [Debian uses] the word "free", [Debian is] not talking about money, instead, we are referring to software freedom.
    .

    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.
    Posted 01-29-2024 at 02:47 PM by Linuxant Linuxant is offline
 

  



All times are GMT -5. The time now is 06:26 PM.

Main Menu
Advertisement
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration