This is an old revision of the document!
Table of Contents
Slackware
Related projects
What I don't like
The more appropriate headline should be What I hate, because it became hatred, pain, lately. I've decided to materialize this hate into list below, perhaps in hope Pat and his “crew” stumble uppon 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 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 being done. Otherwise
these could stay only on the paper.
messy and non-portable shell scripts
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 10 years ago.
init scripts
- they do work in Slackware and in Bash and that's about it. Take them elsewhere and they break. 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. But Slackware init scripts don't come with syntax errors and you're error free, right?
I'm no Shell master, but I do try to get better. init scripts in Slackware on the other hand have the feeling like being scripted in 1993 and haven't changed since. I'm sorry for being offensive, I really am. I won't even go 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 non-portable way and it was pain to use/port them under Busybox for Slack-Kickstart.
network start up script
Just look at any distribution and that's it. 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
!
slackpkg
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
- not being able to with full package description if it is available in .txt file. This is true for installer as well.
upgrade-all
andinstall-new
split. Given all above, it doubles the pain to use.
no package dependencies
This is not an easy topic and topic that can be easilly 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 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)