You can kill the background for speed, if you wish.[x]

Thursday, March 7, 2013

Thoughts on Slackware

When I got my new laptop (a Lenovo Thinkpad T530), I decided to do a distro switch at the same time. I had been running Ubuntu 11.something, was wary of the direction Ubuntu seems to be going these days, and also wanted to try my hand at a distro that's a little less hands-off now that I've been running Linux for several years.

So here was my plan: partition my drive as usual (small Windows partition, large home partition, large data partition, swap) and then two Linux root partitions: one 80GB partition for Linux Mint Debian Edition for my daily driver and a 40GB partition for Slackware64 14.0 as my experimental distro.

Well, as it turns out, LMDE had issues on my Thinkpad - it had some pretty severe video issues, the screen as far as X was concerned didn't seem to map to the physical screen, things were wrapping around, the cursor wasn't clicking where it appeared to be - just weird stuff was happening. So I decided to just give Slackware a try. After some reading up, I installed it, threw a startx at the login prompt, and off I went. I never ended up looking back - that sad abandoned LMDE install is still languishing on its 80GB partition, unused and unwanted. One of these days I'll blow it away and add the space to my Slackware partition, but I haven't needed to yet. I negotiated through many travails with UEFI completely within Slackware, and now have everything set up very nicely, with Linux as an equal in the UEFI loader and default-booting. I'm sure I could have wrestled LMDE into submission, but it turns out I haven't had to - I've been loving Slackware so much I've rarely missed it at all.

It's certainly been a learning experience - which is exactly what I was looking for. I really like Slackware's philosophy - there are very few distributed binary packages available for Slackware. Instead, the community maintains and distributes BuildScripts - semi-standardized scripts that automate the building of Slackware packages, setting all the necessary ./configure flags and such. It took some getting used to - it's a far cry from Synaptic to be sure - but as I got the hang of it, I've appreciated it quite a bit. I was pointed at sbopkg by a helpful IRC member, which is something of a package manager for Slackware - it searches and downloads BuildScripts and further automates the process of building the package and installing it. It does no dependency resolution beyond showing you the .info file that lists required packages and providing a basic queue to fill yourself with dependencies before it installs the actual package. Again, this requires a more hands-on and somewhat tedious approach, but it also gives you full control over the process, which is excellent - and you avoid the dreaded dependency hell.

Basically, I love it. I've come across a couple SlackBuilds that were outdated, so I went in, tweaked a few things, upgraded the BuildScript to the latest version, and then contacted the maintainer with my patches. Two of those three (xmonad 0.11 and Clementine 1.1.1) were gladly accepted, integrated, and updated to the SlackBuilds site, with personal and helpful responses from their maintainers to my Slackware-noob self. I love the community, and how close Slackware keeps you to the source, which is what makes Linux (and Open Source in general) special. In fact, I don't think it's entirely coincidental that I also took the initiative to investigate, submit, and eventually fix a bug in the aforementioned Clementine, a fix that was quickly merged into the codebase, ready to be included in the next release.

This kind of thing is what FOSS is all about, and Slackware has done a lot to get me a lot closer to it, and it has also forced me to learn more about Linux and how things work. I wrestled with NetworkManager (which I had formerly used for wifi control) for a while before realizing it was a bit bullheaded and ignored most other common configuration, which caused problems with my dnsmasq configuration, so I dumped it for wicd, and everyone is much happier. And I learned a little more about how network support in Linux works.

On that note, the impetus for this post, which was, like all of my posts, intended to be much shorter: PulseAudio. Tonight I was wishing I had the ability to turn down individual applications, and from my experience with Ubuntu I knew that PulseAudio was able to do that. So I decided to see if I could install PulseAudio on Slackware. Sure enough, there were BuildScripts available, so I built and installed PulseAudio and its dependencies. I did the same for pavucontrol and paprefs, and then headed over to the PulseAudio wiki to see how to get it going. I added the necessary config files, added everyone to the audio group as recommended, but was having problems with a missing library:

Cannot open shared library /usr/lib64/alsa-lib/
Sure enough, that file didn't exist on my computer, so I did some further digging and found out I needed to build and install the alsa-plugins package. A quick trip back to sbopkg, and I had PulseAudio up and running, complete with individual application control. Success! And I learned a little bit about how the sound system works in Linux, and in case things go wrong, I know where the config files are - all things that were hidden behind the configuration and packaging of Ubuntu. I call that a success.

1 comment:

Ben said...


Thanks for your blog, I have to say I found it thoroughly interesting. I actually stumbled upon it looking for Slackware help, and was hoping you may have run into the same problem: I have pulseaudio installed through sbopkg, but cannot install pavucontrol because it depends on libglademm-2.4.0 The problem is that the current SlackBuild is 2.6.7 I've tried finding the old source code for 2.4.0 and manually compiling it with no luck. Any thoughts would be helpful, and thanks for your time.