• SlackBuilds
• Slack-Kickstart

The more appropriate headline should be What I hate, because it became hatred and pain lately. I've decided to materialize this hate into list below. Perhaps in hope Pat and his “crew” stumble upon it and do something about it. Following lines are my opinions and my opinions only. You're free to disagree with anything written here. I understand I have no obligation to use Slackware if I don't like it.

After reading it, if you ever get that far, you might ask: Dude, why don't you do something about it instead of your silly complaints?. Because there were people before me whom tried and hit the wall. Because I've read(in 2012) interview with Pat that convinced me of former being true. Anyway, I already have a copy of # installpkg ; that works in Shell and not only in Bash. I didn't get that far to get rid of tar-1.13 dependency though(yet). I have a fork of init scripts as well. Again, because they work only in Bash. I have ideas how to make installer slightly better, or at least I do miss couple things there. And I already gave a thought to slackpkg-like tool. If any of these ideas sound like something you'd like to see or have, show your support. Showing your support actually means work will be done. Otherwise these will stay only on the paper.

installpkg - not only it is not written in portable way, but it depends on tar-1.13, because newer tar doesn't work or works differently. tar-1.13 release date is Apr/21/2003. -That's almost- That's more than 10 years ago!

init scripts - they do work in Slackware and in Bash and that's about it. Take them elsewhere and they'll break down. Couple bones to pick. The first one is about need to hack to add anything else that doesn't come with Slackware. However, this need of maintenance is, or can be, eased down with diffs. Diff your old init script to a new one, save to diff file, edit out relevant sections, patch it. The second is the use of . STARTUP_SCRIPT. This is fine and quite efficient way which saves some resources, but should you make one mistake and whole init process will come to halt. But Slackware init scripts don't come with syntax errors and you don't make mistakes, right? Right?!

I'm no Shell master, but I'm trying to get better every day. init scripts in Slackware on the other hand have the feeling like scripted in 1993 and haven't changed since. I'm sorry for being offensive, I really am. I won't even go on about coding style, because I became a zealot about coding style incoherency. And you can tell these scripts were written by different people and glued together. But that's nothing unusual in (F)OSS world.

You can argue all you want about scripts being written with Slackware specific environment in mind. It is a pure excuse and, in my opinion, you're wrong. There is no excuse for not writing shell scripts in portable way and it was pain to use/port them under Busybox for Slack-Kickstart.

Just look at any distribution and enough said. There is no need to re-invent the wheel. But then, having multiple network interfaces and using VLANs might be just very specific need that I encountered.

And please, cease the use of ifconfig!

We had Swaret, we had Slaptget, now we have Slackpkg. I don't know what made me to jump the Slackpkg train, but I'm ready to leave. Use of Slackpkg brought me nothing but pain and suffering. I admit it was mostly my own fault. I mean, Slackpkg didn't break my system in any way(at least I don't remember such event).

What I do miss in Slackpkg:

• series to which package belongs
• description of any kind for package
• package description must be in external .txt file. This is true for installer as well
• upgrade-all and install-new split. Given all above, it doubles the pain to use

This is not an easy topic and can be easily misunderstood. Having no package dependencies is Slackware's feature and policy. And it's great, because dependencies can be big pain. However, with more and more packages being added into “official” tree, with applications requiring more and more libraries as they get cluttered; I'm really wondering for how long is this bearable?

You usually don't have everything installed. And I mean everything. You usually don't want to have everything installed. Why would, or should, you? It doesn't make sense. Yet, you do regular update and find your favorite application doesn't work anymore. It's because you're missing this and then that. And another thing.

Would it be possible to get something like “suggested dependencies”? Package maintainer knows what dependencies are required, or does he? Perhaps writing lexical analyzer of ./configure –help or config.log or a SlackBuild for given application to ease manual labour.

Some numbers:

• number of packages doubled in past 11 years(2001-2012)
• actually the biggest growth was in 2005-2006(Slackware-11.0 → Slackware-12.0)
• ~ 70 new packages were added in ~ 2 years(Slackware-13.37 → Slackware-14.0)
• 83 new packages so far in Slackware64-14.0 → Slackware64-current

Just look under 'slackware64/l/'. Yes, you'd assume means you'll find libraries(libs) there. Wrong. What's hunspell doing here? And icon themes? And gtkspell? And so on. I can't find the packages I wanted to point out, but these will do as well.

But where to put them? Hm. I admit that's a tricky one. How about ap, xap and, I don't know, m for the mess? Seriously, days when I happily installed everything are gone. And I find going through clutter in something important like slackware64/l quite annoying and unnecessary.

Actually I seriously think I had it with Slackware. I often find myself thinking whether it would be possible to port this and that into Slackware to get rid of this and that problem. To me, it feels like Slackware is just trying to sail with the flow and stay afloat. I'm sorry, but adding more and more clutter won't cut it. Not even if you have a single router on Slackware. I wouldn't put it en masse anywhere else. It's still fine on workstation, it's still fine on Host(but only for so long). Have you noticed I'm using singular? Have you noticed I'm talking about one machine? Hacks are fine and cool, but they can become tiresome - they will sooner or later.