Slashdot Mirror


Comparison of Arch Linux & Slackware

PostThis writes "The so-called 'lean and mean' distros in the Linux land, Arch Linux and Slackware are being compared in this article. Their installation, configuration, usage, package management, stability, speed, support and future vision are among the qualities discussed."

9 of 19 comments (clear)

  1. Wow, It Almost Like Unix! by Goo.cc · · Score: 2, Interesting

    I enjoy distros like Arch, Debian, Slackware, and Gentoo, as well as NetBSD and OpenBSD. Why? Because the hold on to a true Unix feel, where you can have just a basic system with X Window (if you choose).

    Sadly, most people today seem to be too wrapped up in bloated interfaces and "beating Microsoft" to appreciate the eloquence of Unix.

    1. Re:Wow, It Almost Like Unix! by Calamormine · · Score: 2, Funny

      I'm a true linux user. I don't use anything as advanced as slackware, I just shoved a penguin in my case. The computer doesn't do anything, and the penguin keeps trying to eat my processor, but at least my linux is more complicated than everyone elses!

  2. How insightful is this comparison? by stromthurman · · Score: 3, Interesting

    The author examines slackware and arch in a number of categories, giving one distro an advantage here, and the other one an advantage there. His final conclusion is, "[so], overall, it's a tie. Depending on your needs, it's either Slack or Arch."
    So his advice is, depending on what you need, one distro might be better for you than another. That's hardly insight. It is akin to comparing and contrasting C# and Java at this point. They both have their advantages and disadvantages, ymmv, etc.

    The author then says: "[but] in no case --at least for me-- would I choose the bloatware that is in other distros."
    I have never used Arch Linux, but I have been running Slackware for quite a while now (dual booting in the past, stand-alone now), and if you do a total install, you eat up 2-3 gigs of space. It can be a lean install, but there's plenty of room for it to be bloated as well. Again, any distro with even the most primitive package management tools would have the same ability, though the difficulty involved may vary.

    If you have never looked into Arch or Slackware, this article is mildly informative as it conveys the design philosophies behind these two distros. However, knowing something about Slackware's reputation and reading this article's summary was enough to tell me the distros had similar goals, and that's really all that I took away from the article as well.

    --
    I have discovered a truly remarkable sig which this margin is too small to contain.
    1. Re:How insightful is this comparison? by BrokenHalo · · Score: 2, Insightful
      In answer to your header "How insightful is this comparison?", I would simply say "Not very".

      (Quick disclaimer here: I've been a fan of Slackware since it was SLS...)

      One point that I happen to agree with is that Pat uses some strange packaging quirks. A case in point is that he prefers Gnome built with "-prefix=/usr" while KDE goes in /opt. I'm sure he has legitimate reasons for doing so, but unless he elucidates them it just seems odd.

      However, the advocacy of swaret in TFA is irrelevant and somewhat silly in this context. Swaret is a 3rd-party package which has worked well (up to a point) for a number of people, but which has also something of a reputation for leaving systems unbootable.

      In actuality, the dependency issue is fairly much irrelevant in [probably the majority of] Slackware setups, since a large proportion of apps are hand-built from source, which necessarily implies that dependencies are resolved to start with.

    2. Re:How insightful is this comparison? by stromthurman · · Score: 2, Insightful

      I concur with your remarks. In particular the discussion of swaret. The author is discussing distros here, they should be weighed on their own, out of the box, merits. I personally have pretty mixed feelings on swaret (worked fine for me when upgrading from a cd, bombed on me when upgrading over a net connection), but including a discussion on it in a comparison of distros is a bit misleading. Especially without a discussion of some of swaret's problems. I don't know how many other people have experienced it, but when I tried to upgrade slack to current over a net connection, it bombed on me, when I did it via cd, it worked fine. Giving readers the impression that "slackware + swaret = strong package management," is probably very bad advice. Compare the distros based on their out-of-the-box merits, not by what you can do when third party apps are added.

      And to support your final claim, most of the apps I install, after initial slackware setup, are done via ./configure; make; make install, and it might have helped those who know little or nothing about slackware if they were told that this becomes a common procedure, even with .tgz packages.

      --
      I have discovered a truly remarkable sig which this margin is too small to contain.
    3. Re:How insightful is this comparison? by reclusivemonkey · · Score: 2, Interesting
      Erm not very! As a Slackware user of a couple of years now I have to point out a few things;
      Adding/removing daemons especially, is really easy, much easier than in Slackware, (the Slack book has... forgotten to mention those).
      How about pkgtool, Setup, services? A simple tick for each daemon? Can't get much easier than that.
      Arch also turns off my machine automatically too, while with Slackware I have to manually turn off using the power button. Little things like that make a difference.
      How about removing the # from #/sbin/modprobe apm in /etc/rc.d/rc.modules? Maybe this was something to do with it being tested on a laptop, but come on the guy had ten months...

      I also agree with the parent that it seems odd to talk about 'lean' distros. Your leaness (IMHO) is dictated by your requirements, not your distro. Any distro can be lean if you so wish.
  3. Re:Distros have no business in /opt! by atomic-penguin · · Score: 3, Informative

    opt is my area where I can install my big self-contained stuff and not worry about it getting changed or overwritten at the next upgrade or apt-get. If Arch puts half of /usr in /opt, where is non-distro related software supposed to go? ~/stuff?

    Could put your stuff in /usr/local.

    There is a filesystem hierarchy standard

    As defined by the fhs:
    "/opt : Add-on application software packages"
    "/usr/local : Local hierarchy"

    --
    /^([Ss]ame [Bb]at (time, |channel.)){2}$/
  4. I love Arch by DJayC · · Score: 2, Informative

    Arch has been amazing. I've run many different distros, but none have compared to Arch. First off, the speed is incredible. I thought my Gentoo system flew, but Arch felt a lot faster (don't forget: Arch is a binary dist.). The packages available are up to date, and very easy to install with pacman. Pacman is also resolves dependencies quickly, which I definitely like (compared to, say, 'yum').

    Within the first night I had Arch up and running I was already building my own packages using ABS. There is also a "trusted user repository" website where you can find packages that might not be in the official respository, though I usually just build the package myself.

    My favorite thing is the fact that you can download the "core" arch CD distro which is actually under 100megs. You install the core, and simply use pacman to install the stuff you want. I finally feel like my linux system has only the software I want/need, instead of tons of applications/utilities/libraries I will never use.

    If you haven't used Arch yet, give it a shot!

  5. Re:Distros have no business in /opt! by LeninZhiv · · Score: 3, Interesting

    Right (and thanks for the link since I was just looking for that yesterday and didn't find it), but that leads to a couple points:

    1. My original position is that "add-on" means "not part of the distribution". So both /opt and /usr/local ought to be empty following a default install, unless there is 'bonus' third party software in the equation.

    Arch obviously interprets "add-on" differently, but as their use of /opt is different from most, it raises the question of whether a non-standard interpretation of a standard is really standard. Or something.

    2. The standard itself says that apps in /opt are in their own /opt/provider directory, in other words basically self-contained. Whereas when Arch puts things like Gnome there, it's not in the least bit self-contained in that your gtk libraries affect how it functions and (more importantly) people compiling other applications need to use its development headers.
    If anything, Gnome should be in /usr/local since that implies an interrelated hierarchy rather than a "separate from everything" zone.

    In other words, IMVHO, nothing that you installed for /usr/local should depend on anything that's in /opt to compile or run. Big third-party binary applications go in /opt. Now, everybody has their own notion of what's counterintuitive, but all the same I don't think Arch's kind of usage is going to catch on--it's certainly counterintuitive to me.