I was comfortable with Slackware the first day I used it. Debian, which I had been using before that, was incomprehensibly byzantine, by comparison.

Slackware is not what I would call "a lot more difficult to maintain by default than Debian." I find it is actually easier, with much better control over everything. I used Debian for years before I made the switch to Slackware, and this was way before the switch to systemd. I definitely would not go back now.

I have nothing to add, really, others have already covered your questions. You should do fine.

Salix is pretty nice, but I don't see this as being necessary for the OP. It would be akin to using Ubuntu instead of just going with Debian. Just dig into Slackware and forget the hand-holding. You already have enough Linux experience to get yourself on the way.

1 members found this post helpful.

https://www.linuxquestions.org/quest...o-next-644746/

then see how far down the rabbit hole you wish to go.
https://www.youtube.com/watch?v=TbYirSi08m4

Welcome!
There are some large fundamental differences between the two...

The biggest difference is that all of Slackware is on the installation media. You can easily add 3rd party packages, but beware that sites like SlackBuilds.org are not official repos.

Another fundamental difference is that there are no "devel" packages. Packages aren't split into binary/library/development. A complete installation of Slackware will give you the environment which was used to build it, which leads me to the next fundamental difference:

You should choose to install everything. There are people who may tell you otherwise, but a complete installation will mean that there is nothing missing, and everything will work as it should. Once you're more familiar with how it all works, you can choose to remove the packages you don't want or need.
My experience is that the simplest way to add packages from SB.o is to install sbopkg which is a neat script with an eay-to-use TUI. It allows you to sync and easily check for updates to packages which you've added.
As mentioned by a prior poster, I'd avoid using 3rd party tools like slapt-get or slackpkg. Use "upgradepkg --install-new" or installpkg to install new packages. sbopkg will ask if you want it to install the packages for you.

One nifty feature of slackware is that the package database is comprised of text files located under /var/adm/packages. There will be a file for each package installed on your machine.

In fact, the whole packaging "mechanism" is more transparent than it is in Debian. It is trivially easy to create your own packages in Slackware. They're just compressed tar files. They don't need to be checked, reviewed, audited or blessed by the Pope...

You will need to change your thinking with certain things, but it looks like you're on the right track. Remember to relax and enjoy it.

1 members found this post helpful.

Maybe I'm confused but slackpkg is core Slackware. It moved from slackware/extra to slackware/ap since v12.2.

this is a good place to start:
https://docs.slackware.com/slackware:beginners_guide

follow the instructions for whatever you need (for example, you may not need a multilib system, so skip 'Mixing 64-bit with 32-bit').

For SlackBuilds, seriously, read:
http://slackbuilds.org/howto/
learn how slackbuilds work, install some of them manually (well, pick some hat do not have a bunch of dependencies, to spare yourself the hassle). Once you know the principle, there are two tools you can check out:

sbopkg
https://sbopkg.org/
read what queue files are and how you can use them for semi-automatic dependency resolution:
https://sbopkg.org/queues.php
you can install the tool from here:
https://sbopkg.org/downloads.php

sbotools
https://pink-mist.github.io/sbotools/
read its documentation:
https://pink-mist.github.io/sbotools/documentation/
you can install it from slackbuilds.org:
http://slackbuilds.org/repository/14.2/system/sbotools/

both of the above tools are nice and do the same job: installing software from SlackBuilds.org. They take a different approach and it is a mater of personal preference, really, which one you choose.

ok, there's also slpkg, you can install it from slackbuilds:
http://slackbuilds.org/repository/14.2/system/slpkg/
i have not worked with it, so i cannot really say much

or, there's another, alternative approach, which will feel very debian-like :P

install slapt-get and it's gui gslapt from here:
https://software.jaos.org/

pay attention to the version of Slackware and architecture, for example, for Slackware 14.2 x86_64, these are what you need:
https://software.jaos.org/slackpacks...t-x86_64-1.tgz
https://software.jaos.org/slackpacks...c-x86_64-1.tgz

Now you need a repository of prebuilt packages. There is a repository of packages built from the scripts at SlackBuilds.org. It is called SlackOnly (https://slackonly.com/) and it is not officially affiliated with SlackBuilds.org or Slackware. So, for a Slackware64 14.2, you tell slapt-get to use this:
https://slackonly.com/pub/packages/14.2-x86_64/

it is up to you, really, how you manage your system.

Please, read for yourself and decide how you want to do it. I do advise you to learn how to use SlackBuilds manually first. SlackOnly lags behind the updates at SlackBuilds.org and often the repo is very slow. Also, I am obliged to say that, some users are suspicious of the quality of the packages provided there. I, myself, use the SlackOnly packages on my laptop, and have not had issues.

First off, welcome to the community, kr4k3n and I hope you find Slackware a thoroughly boring experience LOL. That's actually a worthy and proper wish since it is my opinion that the underlying operating system, once in place and configured to suit your needs and desires, should become utterly transparent and ubiquitous and Slackware most definitely can do exactly that. In that process hopefully you may learn what took me nearly a decade to discover - that there is little to be gained by trying to make one distro be another. It is substantially more effective to learn what each has to offer on it's own terms. This is especially true with Slackware because it aims to be as Vanilla as possible and in Patrick's own words "not presume what users wish to do with it". There is, for this reason considerable diversity among Slackers, more than is even possible in most other distros, and being an early arrival (v7) my approach is perhaps more austere than most.

Slackware is, IMHO, the distro requiring the very least maintenance of any assuming the Admin, you, doesn't fall into the situation of assuming you need constant updating especially in the base system. This may be difficult to discover, coming from Debian, since it installs a rather light base by default and when desiring to install one simple app it is routine that many more must be installed, removed, or altered to feed the auto dependency resolving Octopus. This engenders a complacency at letting others decide what you have and how it operates resulting in considerable acquiescence which evolves into a state of numb acceptance from my POV.

It is very important to realize that convenience creates dependence and ultimately can make one weak, unobservant, and unknowing as well as unable to get along on one's own. This of course takes place in degrees since only a distro perhaps like LFS leaves everything up to you. In any case if you eschew automated updates you can create a distro that requires extremely low maintenance because so little actually needs to be changed or "updated" So the key is determining just what you require, or think you require, to be updated. Very few Admins require the very latest in all software and those people possibly do better with a Rolling Release where up-to-the-minute versions (usually of development software) actually have a value beyond the knee-jerk habit created largely by Windows of assuming "New == Improved" which likely you have experienced isn't always the case.

If one does the Recommended Full Install of Slackware there is very little extra that is needed by most Users especially for the more common casual user. It isn't even a requirement to patch for security updates though that is a good practice in Slackware's case since most people consider Patrick's judgment quite prudent and conservative in this area. We have a history of "wait and see" that has proven very wise more than most. For example Slackware dropped Gnome when it threatened to cause difficulty and even damage to the process of staying Vanilla, was slow to update to v4 from v3 KDE which turned out to be exactly what KDE expected but was blindsided by eager distro devs creating massive blowback, and certain updates to gcc that turned out to be quite buggy.

Pkgtool is an example of perfect simplicity and choice and Slackbuilds are a logical extension of that since it builds from vanilla source and makes no changes you don't initiate. It compiles from source in a manner that is completely controllable by you since Slackbuilds are a text-based script you can edit as you see fit to allow or deny any aspect of it's reach or location and it installs nothing, building the package in /tmp for you to decide whether or not to install.

So my recommendation is to avoid trying to recast Slackware into Debian since Debian already does Debian so why change? Make any decision that offers convenience carefully and deliberately so Slackware doesn't become that maintenance burden that other distros actually are and I think you will be shoicked and pleased at how little needs to be done to the base system on a daily, weekly and even a monthly basis AND the big payoff is the System is never at risk. The worst that can happen is a build fail or possibly complete and either not run (if you ignored a dependency) or lacks a function if you ignored the option and all of those conditions are trivial to repair because you were there every step of the way and know exactly what was or was not done. There is a clarity and peace of mind that comes with this that is empowering and almost entirely a Slackware experience.

Welcome to the KISS distro.

6 members found this post helpful.

Replace every instance of Morpheus with Patrick Volkerding and every instance of Neo with kr4k3n. Ha ha.

For myself, I like to setup sudo such that it requires no password. Saves me from having to type it every time I run a command which requires root privileges. Seems to me that a one-time setup of /etc/sudoers is easier than having to type my root password every time I su. But that's just my opinion.

I like to use Alien BOB's SlackBuild Toolkit for packages which don't already have a SlackBuild, and edit the resulting SlackBuild to match the build instructions on the project's website (after copying and pasting into a directory, along with slack-desc and source package, of course). That way, it's like easing into the water instead of just diving headlong into waters you're not familiar with, which in my experience usually ends in disaster. Having said that, I haven't run across too many programs which I want to run for which there isn't a SlackBuild already available.

Also, there's rpm2txz/rpm2tgz which can convert an rpm package if available to a Slackware package, and it works very well. I used it for the doomsday engine (DOOM front-end), and that worked well for me.

And then, if the OP is comfortable with that and feels like he can handle writing his own SlackBuild, more power to him!

1 members found this post helpful.

I prefer mkslack. Then just touch up the SlackBuild, .info, slack-desc and add a README.

Well this means nothing without the "real life" soundtrack:
https://www.youtube.com/watch?v=WANNqr-vcx0

kr4k3n --

Lots of good advice about package managers already posted and I can't help much at all because I still do it the old way ( installpkg, upgradepkg, removepkg ).

But this is because I 'grew up' in the dark ages before SBo existed and where extra packages were added to Linux and UNIX alike via ( configure && make && make install ).

For me a SlackBuild is a wonderfully advanced shell script wrapper for that ancient software build-and-install paradigm.

And even better, the Official Slackware SlackBuilds in the source/ directory and the SBo SlackBuilds are much alike -- once you underestand one SlackBuild script, they all follow about the same 'formula'.

Note that I do keep local mirrors of an official Slackware Mirror and the SlackBuilds.org git Tree on my LAN.

If you decide to go that route and you clone the SBo git tree ( ~300 MB ) on your local LAN, one tool I HIGHLY recommend is Christoph Willing's hoorex Script.

LQ User chris.willing's hoorex script does a very good job of resolving SBo SlackBuild dependencies. I've used it a couple years now and it's never failed me ( knock, knock, knock on wood ).

But my best recommendation of all is if you can afford it, to subscribe to the Slackware DVD at: The Slackware Store

HTH and welcome and Good Luck !

-- kjh

1 members found this post helpful.

Yes, nice pop-media reference by OP, except the Slackware pill is the blue one, so that doesn't quite fit.

"Everyone falls the first time", and "There is no spoon", both seem to fit Slackware quite well too.