Differences

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

--- linux:slackware:start [2012/08/29 04:47] – Slackware rant rewritten stybla
+++ linux:slackware:start [2013/07/14 04:07] (current) – add Actually stybla
@@ Line 9: / Line 9: @@
 ===== 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
+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 uppon it and do something about it. Following lines are
+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 former
+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
+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
+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 could stay only on the paper.
+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 10 years ago.
+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 break. Couple bones to
+''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. But Slackware init scripts don't come with syntax errors and you're error free, right?
+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 do try to get better. init scripts in Slackware on the other hand have the feeling like being scripted in 1993
+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
-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
+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 non-portable way and it was pain to use/port them under Busybox for
+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.
+[[linux::slackware::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
+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.
@@ Line 58: / Line 59: @@
   * 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.
+  * 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.
+  * ''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 topic that can be easilly misunderstood. Having no package dependencies is Slackware's feature and policy.
+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 how long is this bearable?
+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,
@@ Line 78: / Line 79: @@
   * 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.
+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 ... =====
+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.