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.
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?
/usr/local.
Could put your stuff in
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}$/
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!
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