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."
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.
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.
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:
/opt and /usr/local ought to be empty following a default install, unless there is 'bonus' third party software in the equation.
/opt is different from most, it raises the question of whether a non-standard interpretation of a standard is really standard. Or something.
/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. /usr/local since that implies an interrelated hierarchy rather than a "separate from everything" zone.
/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.
1. My original position is that "add-on" means "not part of the distribution". So both
Arch obviously interprets "add-on" differently, but as their use of
2. The standard itself says that apps in
If anything, Gnome should be in
In other words, IMVHO, nothing that you installed for