Differences

This shows you the differences between two versions of the page.

--- linux:slackware:start [2012/08/28 23:41] – stybla
+++ linux:slackware:start [2013/07/14 04:07] (current) – add Actually stybla
@@ Line 5: / Line 5: @@
   * [[SlackBuilds]]
   * [[Slack-Kickstart]]
 ===== What I don't like =====
-Headline ``What I hate about/in Slackware'' would be more appropriate. I've decided to put down this list with which feel free to disagree.
+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.
+=== 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- 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
+[[linux::slackware::Slack-Kickstart]].
+=== network start up script ===
+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''!
+=== 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
+  * 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
+=== no package dependencies ===
+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
+=== more and more clutter ===
+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.
-  * messy and non-portable shell scripts that come with/are core of Slackware - RC scripts, installpkg, ...
+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
-  * network RC script that's way old for today - yeah, other distributions got it right
+happily installed everything are gone. And I find going through clutter in something important like ''slackware64/l'' quite annoying and unnecessary.
-  * slackpkg - what a terrible tool and your doom
-  * suggested package dependencies
-Let's talk about dependencies a bit more, because no package dependencies is Slackware's feature and policy. And it would be all great and cool only
-if things didn't get more and more complicated over the time - new libraries added, new software added, package count doubled in 11 years(actually it
-was in one year between versions 11.0 and 12.0), 100 new packages added in ~ 2 years. Anyway, how long is this manageable? Or do you have everything,
-every single package that comes from "official" tree, installed? Really? I don't believe it.
-I'm not saying Slackware should get package dependency like, eg. RPM based distributions have, but it should get "suggested" dependency. In other words
+===== Actually ... =====
-suggest what packages might be required in order to get some application running.
+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.