Background: I started out using Slackware back when Pentium Pros ruled and went from there to Red Hat and, lately, OpenSUSE.

There are some new features in newer Red Hat-based and SUSE-based distributions that strike me as too cumbersome and make Linux a little less UNIX-like than I'd like to see. I'm interested in a basic Linux system with a minimal windowing system/desktop. KDE is nice but it comes with baggage that I don't want to see on my systems any more (akonadi, nepomuk, and their ilk) and I won't even consider Gnome any more despite having used it for ten years or more. I'm looking to get back to the basics. (BTW, Debian, with the adoption of systemd, doesn't really count as a "basic" distribution any more. At least to me it doesn't.)

I tend to compile most of the major applications I use (Apache, PosgreSQL, PHP, etc.) or download binaries from Mozilla (Fiewfox and Thunderbird) after finding that it's just as easy for me to get newer versions directly from the application web sites, get them compiled, and schedule the minor downtime to move the new versions into place. So, to make a long story short, I'm not seeing the advantage of the "fancy" distributions as there might have been at one time.

What problems/surprises/gotchas/etc. do others see me encountering if I were to migrate back to Slackware?


TIA...

--
Rick

You can omit installing KDE and use xfce4 (I use LXDE, it is faster and smaller). And you can build packages of newer versions of software using Slackbuilds.

1 members found this post helpful.

Probably none; you might have many moments of pleasant surprise and a feeling of coming home/relief

Welcome back! :-)

I've tried both of those in the past. My gotta-have feature of a desktop is multiple workspaces and hardly anyone /doesn't/ have that nowadays. Being able to have different wallpapers on each workspace is nice -- gives me a quick reminder of what desktop I'm working on -- but not a showstopper if it's not there.

I'm not sure if Slackbuilds is anything that I'd make heavy use of; I'll need to find more information on it. I've been using tar archives of the sources of my main applications for so long and using simple scripts that remember all the configure options I want that I'm not sure how much simpler it could get.

Thanks for the reply...

--
Rick

Well, that just about describes SlackBuilds! It doesn't get any simpler, as you say!

SlackBuilds is just a repo of build scripts for a wide range of project sources which produce a tarred package suitable for use with Slackware's package system... in other words, it uses those tar archives of sources to build from a script which knows all those config options - I think you'll love it!

And welcome back to Slackware!

Slackware is not only the most Unix-like Linux, it may well turn out to be the LAST Unix-like Linux!

*** Forgot to mention - My DE/WM of choice is Fluxbox - as simple as you like, still as customizable as you want. If not familiar with it, give it a try - available on Slackware full install.

2 members found this post helpful.

What about OS upgrades?

I've pretty much always done fresh installs instead of upgrades, mainly due to the hassles I had trying to upgrade Slackware in the past. My practice of keeping my personal "stuff", application binaries, and application data on separate filesystems (/home, /opt/app, and /var/app, respectively) goes back, in part, to my first experiences with Slackware. Has that gotten better?

--
Rick

Not to preempt Loomx, but for myself I always maintain my own archives, usually keep home and a few other things on separate partitions and pretty much always went for a fresh install instead of trying upgrade paths which rarely worked...

There is a new tool now included in Slackware - slackpkg - which actually works very well and has gained my own confidence of late! I have always preferred to update things incrementally when needed, and never trust automated updates. Beginning with Slackware 14.0 I set up a production system for the purpose of trying to follow -current for the first time. I maintain a local repo (using Alien's mirror script) and use slackpkg to update the system from that repo... after a little config experimentation and 2+ years of updates - no screwed systems and no complaints! I have now extended that method to other machines using the same central updated repo.

Other than slackpkg (which is optional), the package management should be pretty much as you knew it - simple and solid!

Dunno. Try it, see if you hate it right away. slackware-current looked very nice in my last install (two weeks ago, on an i686 Pentium 4), a bit more polished to me than 14.0 or 14.1. Pat's doing a great job!

I keep my own archive, too, but it's more like using rsync to keep the contents of a USB stick fresh. It's a very handy way to keep up with changes.

Gotchas...it depends on how far you want to get away...

First, I love Xfce, but parts of it are temperamental towards source-code upgrades, so I tend to use Fluxbox or Windomaker when Xfce blows out. Sometimes, I leave Xfce out altogether.

On the first couple of reboots, you might check for a message like "/: device busy". Usually, I'll throw an extra sync or sleep command in the shutdown script, which is /etc/rc.d/rc.6 .

systemd will probably take over on Linux, and so non-systemd init may be living on borrowed time. If you're escaping that, it may be a temporary reprieve.

The installer is pretty much the same as when the Pentium Pro ruled. You'll know what to do, possibly to your chagrin. Don't be afraid to use the shell to format filesystems to your liking, then ask the installer to not format the filesystems.

AFAIK, there's still no PAM by default.

AFAIK, there's still no SELinux by default.

CUPS is old (1.5.4), and maybe Pat could make it newer. [I don't know either way if there is any security benefit by upgrading CUPS.] However, to make it newer takes a bit of jumping through hoops, especially since Apple broke off some of the Unix-only items to openprinting.org. There are also even more prerequisite libraries than what Ghostscript used to need. I've tried it, I've done it, I like it. However, at the end, I was like "Sheesh! That was ridiculous!" So if Pat wants to keep CUPS at 1.5.4, that's fine by me.

If there's a delay in boot because the mime and icon caches need to be updated, know that you can still put most of that in a separate script and run it as needed. It saves me about 100 MB of memory on boot and removes that "What happened to my nice efficient Slackware?" feeling.

If you run a filesystem that likes the Deadline I/O scheduler (like XFS and especially JFS), you might consider letting the kernel run Deadline. If you wanted to try it without building a new kernel, it looks like you can pass "elevator=deadline" as an argument to the kernel.

Permissions are a bit tighter than they used to be. You may need to add users to a printer or lp group to use the printer or to the video group in order to have hardware OpenGL. When combined with removable media, this might require some tinkering with udev scripts to get the permissions just perfect. But it's been a while, and I was ripping things out at the same time I was getting an Epson printer/scanner working.

There are many more gotchas, but the gotchas can be controlled to some degree. It's just all I could remember off-hand.

Or there's the *BSDs though that's a little farther than I want to tread at this time. Screwing around with the system logs was a crime (IMHO) and, perhaps, someone at RH will get it fixed when they hear about commercial installations that balk at running RHEL with a dodgy logging subsystem. I can just imagine what the auditors would have said if we'd been unable to present system logs because of a corruption. (Hint: it wouldn't have been good and could have serious repercussions on any future use of Linux. But those were pre-systemd days so corrupted logs were more likely to indicate a system management problem, a training problem, or a failure to follow procedure, etc.)

The only nasty thing I recall from my earlier experiences with installing Slack was the post-installation configuration of X. I think that'll be a non-issue nowadays. My personal and application filesystems aren't even mounted when I do upgrades. (If I'm feeling particularly paranoid, the cables to the drives/mirrors containing those filesystems are disconnected so the installer doesn't even know they exist.)

But an option, right?

Not a big deal as, if memory serves, I think OpenSUSE disables it as part of a typical installation. So I don't miss it.

I gave up on CUPS on our print server some years ago and kept that system on LPRng. CUPS clients printing to a CUPS server turned my 20ppm printer into a 2ppm printer.

Now that sounds like something I should watch out for, then. At times, my scanner is one of most heavily used tools.

Thanks for the information...

--
Rick

Installation-related question for Slackware users:

Does requesting certain X Window utilities during installation force the installation of a desktop environment?

On servers, it should not be a problem to install a number of X11 programs -- "xterm" is the first one that comes to mind -- without forcing the installation of the entire set of X Windows packages, a slew of window managers, desktop environments, etc. What I've found with some recent distributions is that telling the installer that I want "xterm" carries with it an assumption that I'll also want a crazy number of dependent packages that I don't want or need. I may be building a server with an old graphics card that is barely (or no longer) supported by X and my intent is to be doing things like
without having a system that has a lot of extraneous software packages installed just because I wanted to use xterms to remote systems. Yeah, I can override the installer's dependency determination but risk creating future headaches when something mysteriously doesn't work later.

Doable with Slackware?

(Apologies if this is a stupid question... it's been a good 15 years since I last installed Slackware.)

TIA...

--
Rick

It's automatic (no xorg.conf) until it's not automatic, then there will be work to do. In particular, were you to run `Xorg -configure` to generate an xorg.conf, and your console was in kernel modesetting (KMS) graphic mode, Xorg may not detect the monitor's capabilities. Then, the options become 1) run `Xorg -configure` under a text-mode VGA console; or 2) grab the docs that came with your monitor, and use the specs to specify HorizSync and VertRefresh in xorg.conf ("Monitor" section).

It's worth a try, and really, I've forgotten why I've generated an xorg.conf for every one of my PCs that has X11. I'm sure it was to solve a minor one-time glitch, and I just left the xorg.conf in place.

Regarding PAM, I thought it used to be there, but I'm not finding it right now. Years ago, my use for PAM was to follow the Samba instructions for using the pam_winbind.so module and using Slackware as a Samba client. What I did was open a bunch of prompts, grabbed PAM from Red Hat, and compiled and configured until problems went away. The trick is to set up PAM to work with shadow passwords and maybe compile shadow to work with PAM. Test all of this before you run out of login prompts. Other than that, I have memories of tuning Samba and xscreensaver and not much more to work with PAM.

Regarding printing and scanning: Again, try it first. Maybe I pared out too many udev rules. If nothing else, when the adduser script asks you if you want your user to be part of additional groups, consider its suggested list of groups carefully.

Your recollection is accurate.

http://www.linuxquestions.org/questi...8/#post5057171

No. Package installation in the default installation starts off exactly as you remember it. A program called "slackpkg" has been added. Many people here love slackbuilds.org and the SBo way of making packages.

In the initial install, you can still choose to install so little that something doesn't run.

I'm still using installpkg, upgradepkg, removepkg. If I'm really lazy and want graphical luxury, yes, pkgtool is still there as well. The old way still requires you to be the package manager. Good and bad, the old way will still never install a prerequisite package on your behalf.

My advice: just forget Slackware as it was, learn to use it as it is now and be happy.

There is really no point IMO in cherry-picking the packages you install. Making a full installation, including software that you don't want and won't ever use, actually won't do any harm. For instance, installing KDE won't slow down anything, as long as you don't use it. And nobody obliges you to use it, even if it is installed. Unless you have a very old machine, wasting 4 or 5 G of space on a hard disk can't be an issue. Security is not a concern either, as long as you don't start daemons uselessly. And even then, installing the patches as listed in the Slackware ChangeLogs and registering to the slackware-security mailing list will protect you.

Using slackpkg will help you with updates, as it downloads stuff for you and is somehow a front-end to other package tools included in the pkgtools package. I remind you that all these tools have handy man pages.

Forget about making a lot of different partitions: your system is not supposed to look like sliced bread. One partition for / and another one for swap is enough (add an EFI partition if you use UEFI firmware, of course). That will avoid you to get out of space on disk too soon.

Forget about ./configure && make && make install run manually: learn to use the SlackBuilds, then to write them. You'll save yourself a lot of hassle and time and it will make your system's administration way simpler.

To install extra software, preferably package it using the SlackBuilds available @ http://slackbuilds.org, very often it will be available there. First read the SlackBuild Usage HOWTO. You can even automate download, build & install using sbopkg, and generate queue files (that will help you install dependencies in the right order) using the associated sqg script.

A few repositories can be trusted in addition for pre-built packages, I recommend those provided by Alien Bob and Robby Workman.

Read the good documentation provided @ http://docs.slackware.org.

I think that's enough to get (re)started.

Good luck, and have fun :^)

Upgrades from one release to another tend to be unexciting affairs; I recommend following the instructions from here:
http://docs.slackware.com/howtos:sla...:systemupgrade

(More generally, docs.slackware.com is a great resource)

A great new(ish) tool is slackpkg+ which is a plugin for slackpkg with allows access to some extra repositories, e.g. AlienBOB's, with a range of extra packages like libreoffice, calibre, multimedia stuff...