There are a lot of cliches about how the only thing that remains constant is change. That statement definitely applies to the Linux industry. Last year and the beginning of this has brought us a lot of changes. There are new technologies and distributions to pick from.
Ubuntu was a relatively unknown name a few months ago but now is generating a lot of buzz. Personally, I have tried Ubuntu and don’t see anything technically special with it. The way Ubuntu is marketed (free CDs and an interesting release cycle) is what is making it so successful. But this article isn’t about Ubuntu but a very different distribution called Arch. Could Arch dethrone Ubuntu as the new kid on the block? Does it have what it takes? Read on and find out.
First of all, let me go ahead and say I’m not approaching Arch with a completely clean slate. I’ve heard things about Arch Linux before. I’ve heard that it resembles Slackware in the way it was lean and meant for "advanced users". I’ve heard about its package manager called Pacman which is supposed to be all the rage. I’ve heard it’s optimized for i686 by default which can arguably improve performance. I’ve heard it’s Gentoo without "all that compiling". So when Arch 0.7 got out a few days ago I simply had to try it out.
Installation
The Arch ISO comes in two flavors. There is a 560 MB full version and a smaller base version. Both can be downloaded normally or via Bittorrent. For the uninitiated, Bittorrent is a peer to peer protocol for downloading files. I hope to see more and more distributions use Bittorrent for downloading ISOs since it cuts down on expensive mirrors. Anyway, after my download was done I burned the ISO, put the CD in the drive, and rebooted.
Before I began the install, I glanced over the installation guide at
http://www.archlinux.org/docs/en/guide/install/arch-install-guide.html
Arch’s installation CD doubles as a rescue disk in case you may have a unbootable Arch installation in the future. The install CD boot up and dumps you into a command prompt. You have to invoke the installer using /arch/setup a la Slackware or Yoper.
What follows is a typical text based installed. One positive comment I have is right away you are given the option for an FTP or CD install at the beginning. In some distributions (such as Fedora) you have to issue special commands to perform an FTP install. It’s nice of the people at Arch to make FTP installation easy.
The strange thing about the installer is you are presented with a list of installation tasks but you can apparently jump around and do them in any order you like. This is quite interesting behavior but frankly this may confuse some people. I stuck with the norm and performed the steps in sequential order: disk partitioning, package selection, bootloader configuration. A comment about package selection: Arch actually recommends you install only the base packages.
In fact, the package selection screen only has base packages selected by default. I suppose I can understand the reason for this. Linux packages tend to get stale pretty quickly and it would be a wiser default to install the base and grab the latest packages off the web after installation (assuming you have a fast connection). I chose to install the base packages as recommended. I got a final chance to review my packages and then pick a kernel. The installer then went off and did its business and installed the packages and a kernel. I then moved on to bootloader configuration which was a pretty standard fare.
A curious menu item in the installer is the "Configure System" entry. Selecting this first asks you what editor you want to use (I selected vi) and then presents you with a list of configuration files you want to look at. I have done countless Linux installs and I can’t remember a single one where you have that level of control. It definitely promotes Arch’s image as a no hand-holding distribution. I decided not to edit any of my config files and accept the defaults. However, to my surprise (or shock) all the configuration files were empty. I’m not sure if this is a bug or a feature but there were no default values in the config files. I guess this meant I had to configure all of them by hand. I checked the installation guide which wasn’t clear on this. It did have some excellent documentation of what I should put in these configuration files. So I manually went through rc.conf, menu.lst (grub.conf), and many others using the installation guide to help me. I could configure grub without any help but I had no clue what to put in some of the files. The whole process was a bit frustrating.
I was brought back to the main installation menu from where I rebooted and awaited my new Arch installation. My hopes were dashed when I discovered Arch wouldn’t boot. So the only option I had was to re-do the installation. This time around when I came to the "Configure System" option all the configuration files weren’t empty! They had good sensible defaults in them which I could work with. I finished up the installation and rebooted again and to my relief Arch finally booted.
First Impressions
Arch booted in a fairly standard way. The startup seemed good but nothing too shocking. The first thing I realized after Arch booted was that the installation never asked me to set up any root password or user accounts. I was simply presented by a login prompt. I guessed that I could log in as root with no password. The Arch installation guide confirmed this. After logging in, I changed my password using the passwd command. As the manual suggested, I went ahead and added a normal user.
So I was all set to use Arch — or so I thought. I casually assumed my ethernet cable modem internet connection was working but I was mistaken. I tried pinging a few sites but there was no response. I ran the ifconfig command. It turned out although I did have a eth0 device the IP address it was using was a private address (i.e.: 192.168.xxx.xxx). This indicated to me that automatic network configuration with DHCP was disabled. I looked through the manual for help. Apparently to enable DHCP you have to edit the /etc/rc.conf file manually. I had foolishly accepted the config file defaults during the installation. I went ahead and changed rc.conf. To apply the changes, I just rebooted and now the network worked!
After the network fiasco I decided to read through the Installation Guide to make sure I didn’t miss anything else. The "installation guide" doesn’t just cover installation but also post installation tasks such as package management. In my opinion, the guide is very well written and well designed. However, the scope of the guide seems a bit limited. For example, the guide does not cover how to install Xorg (which is usually the first thing I do after any installation).
Pacman
Arch’s guide simply pointed me to the Arch Wiki (http://wiki2.archlinux.org/) from where I had to navigate to a "Howto install Xorg" article. First of all, I decided I better refresh my package list. I did so by issuing "pacman -Sy" as root.
This procedure is similar to Gentoo’s "emerge sync" and APT’s apt-get update". To my surprise, the command finished very quickly. My experience with Gentoo is refreshing the package list takes at least a two or three minutes. Debian’s probably takes about a minute or so on my computer, but Arch’s speed was impressive. After the package tree was refreshed, I installed xorg with:
pacman -S xorg
which proceeded to resulted in a bunch of things being downloaded. The speed of the download mirror was really nice. I didn’t pick a mirror manually. I’m not sure if pacman automatically gets the closest mirror or not but it was a nice touch. Maybe I was just lucky. Xorg installed and I came back to the command prompt. One reason I wanted to install xorg was to see if pacman is intelligent enough to launch xorgconfig for me or did I have to do it manually. As I expected, I had to configure Xorg myself. The process of configuring Xorg is one that is frustrating. I remember all the steps because I’ve done it so many times. I didn’t have a preconfigured xorg.conf lying around as I should have. To test out Xorg, I needed to install Gnome which was really easy to do using pacman. Even though Gnome did install, pacman wasn’t smart enough to install gdm with it. Yes I know there is a way to log in without using a graphical login manager but I would guess that the majority of people out there want to log in graphically. I had to install gdm manually.
I must say so far I am really getting into pacman. It seems to take the best from Debian and Gentoo’s package managers. For example, one thing that really bothered me about Debian’s APT is Debconf. Debconf is a way to configure packages as you install them in Debian. For example, if you install xorg in Debian, it will first ask you a bunch of configuration questions about xorg (and its dependencies) before installing it. While this behavior is useful in certain situations it can be really annoying when you have to install a lot of packages. You can’t just run the install command, go get a coffee and expect them to be installed. Thankfully, you can turn of Debconf. You can even set the question priority for Debconf but it is turned on by default. A lot of Debian documents recommended configuring through Debconf so even if you turn it off it doesn’t quite go away completely. Gentoo has nothing equivalent of Debconf and from my experience with Pacman it seems it doesn’t either. This goes along with Arch’s "do it yourself" philosophy.
Pacman’s speed seems fairly impressive also. One good thing about Debian’s APT is it’s pretty fast but from using Arch for a few days it seems Pacman’s speed edges out APT’s by just a just a little bit. Maybe it’s psychological for me but I do feel a difference. Of course this is totally subjective and depends on your system. Comparing Pacman to Gentoo’s portage is comparing apple’s and oranges (or Apples and PCs for that matter!) because portage compiles everything by source. However, we can still compare portage’s speed to Arch’s while (say) searching for a package. Gentoo just recently introduced a new version of portage which was supposed to be faster but I really didn’t see a difference. Searching for a particular package still takes a ad longer than it should. That said, after portage is up and running it’s very good. Pacman seems to do the same except faster and you really can say it’s like Gentoo "without all that compiling".
I’d also like to make a small note on packages that are a bit controversial in nature. There are packages such as mplayer and certain codecs, java, and some sundry items that are not available in the default Debian repository (due to licensing issues). This is a huge deal because this affects every distribution based on Debian (Ubuntu, MEPIS and others). Fedora is also another distribution that has very poor multimedia support for legal reasons. There is no acknowledgement of this problem from Debian or Fedora. Just imagine a new user who just tries a popular Linux such as Fedora. He soon finds that he can’t play any MP3 files. Yes as it turns out, MP3 is a licensed technology and is not open source (though some people believe that).
The Fedora documentation makes no comment on this. It doesn’t tell the user why the codec is not included and how they can add it if they don’t care about licensing issues. See
http://www.ubuntulinux.org/wiki/RestrictedFormats
for more information. Yes, you can install "controversial packages" on systems such as Debian using a third-party repository but this is not an elegant solution. I do not like installing applications this way because it always left me with a "unclean" feeling both of using unofficial packages that may not interact with my system as well as official packages may. Doing this also makes me as though I’m doing something so wrong that I have to do it in an underhanded way.
The story about codecs becomes more interesting when certain distributions do include them by default. For example, MEPIS has always (I’m pretty sure) included support for Java and multimedia codecs and flash. This is actually a big part of its appeal. Gentoo has always had all those packages and more in their repository. And coming back on subject, so does Arch. I was happy to. I’m not a lawyer. I just want to play MP3s and/or videos. The point of these packages is pretty simple: one distribution has them and one doesn’t. I’ll make my life easier and install one that does. Thankfully Arch seems to have a lot of good, bleeding edge packages.
Arch’s packages are not completely expansive though. For example, I wanted to install the ever popular Bittorrent application Azureus but there was no package for it. Of course I could install the package by downloading it from the Azurues site. Azureus is a Java application so before I did grab the latest Java Runtime from the repository and it worked fine. I also do Java development using Netbeans. I wasn’t surprised that Pacman didn’t have Netbeans in the repository as not a lot of people use this package. However, to use Netbeans you need the Java SDK which I did find in Pacman.
Overall I would say Arch’s package management is heading in the right direction. Obviously the distribution is a newer one and it will take a bit of time for them to create some of the more esoteric packages. Gentoo’s repository probably has the most depth but I have a feeling Arch’s is heading the same way. Also it would be nice if they could expose development packages like Gentoo does. Gentoo uses a masking system. For those who’ve never tried it, masking is basically a way of installing development (possibly unstable) packages on your system. This added power is really useful when you’re willing to risk a little instability to try the latest and greatest thing. From what I see of pacman, there is no equivalent of masked packages. However, the packages that do exist in Pacman are new enough to make up for the absence of this feature.
The Desktop
My desktop environment of choice is Gnome 2.8. When I logged into Gnome, I realized that the people over at Arch hadn’t customized it in any way at all. Everything is very "default looking". The wallpaper, splash screen are all stock. This is what reminds me of Slackware because I believe it is one of Slackware’s policies to not customize their packages in any way because doing that may introduce new bugs into them that didn’t exist before. While I agree with this philosophy to a certain extent I also feel that this shouldn’t be a black and white thing.
Branding a distribution with a custom KDE or Gnome wallpaper sounds pretty harmless to me and should be done to set one distribution from another. I know both Debian and Gentoo customize their packages to a certain degree. For example Gentoo includes extra applets for Gnome (that are not included in the default set). One of my favorite applets, the Network Monitor, was absent from the applets list. I tried searching Pacman for it, but I couldn’t find it. So I go on IRC to see if someone to help me with this. Some kind Arch user ("timmy") pointed that the package for the applet was netstatus. The absence of netstatus is a little confusing to me because if you read
http://www.gnome.org/start/2.8/notes/rnwhatsnew.html
it clearly shows the netstatus applet being a part of gnome.
Oh well, at least Arch has it in pacman. I was just about to open up Gnome Terminal and get pacman to install netstatus but I look through all the menus and a terminal application! Wow…no distribution I’ve ever tried didn’t have a terminal application. I was confused about this and then looking through the menus, I came to the conclusion that other basic applications such as the Gnome Calculator were missing. Was something wrong or was it supposed to be that way. I spoke with a few friendly Arch users on IRC and they understood my confusion. They explained that I didn’t have some zombie, disabled version of Gnome but that the minimal number of Gnome packages installed by default was a result of Arch’s philosophy. Basically, you install the base and you add exactly what you need and nothing else. But the neat thing about Arch is for those people (like me) who want a full blown Gnome (even with all the extra stuff we don’t really use) we can install a "gnome-extra" package which will install all the goodies for Gnome (including netstatus). I found this approach quite appealing. The solution is elegant because this way the minimalists are happy and others are not left out in the cold.
After install gnome-extra and a couple of other things I was finally ready to get my computing environment exactly the way I want. I have Windows on another drive and I edited /etc/fstab to add mount points for them. From installing applications to adding printers, configuring a Linux distribution like Arch can take a while. My usual procedure is to get some tunes going while I’m getting Linux configured which is a ironic because to do that I have to set up my sound card. The Arch Wiki page is very useful in this regard. I had sound working in no time. I installed XMMS and off I went.
For instant messaging, I installed gaim. For playing videos, I install the windows codecs and totem. As far as my printer is concerned (a HP Deskjet 932C), I check with the Arch Wiki again just to double check even though I know how to configure CUPS. As I began to get more into the Arch system, I really began to appreciate the simplicity of the whole thing. There are no weird config file locations, no weird commands or weird scripts. Everything is really standard and I think an advanced Linux user will definitely appreciate it. There is a sense of respect from the system to the user. In a sense the system is yielding to you. It doesn’t make decisions for you. It only helps to execute the ones you have. The more I used Arch, the more prevalent this became and I must give Arch developers high marks for being consistent. Configuring something like ALSA for my sound card was a good exposure to this philosophy and I was pleasantly surprised by it.
More Pacman
If you’ve kept awake this far, you’ll realize that Arch isn’t a "one size fits all" approach. There are no default applications to speak of (unless you consider the ls command an "application"). The minimal approach is not a new one of course. Slackware, Gentoo, and Debian are famous for using the minimal approach to Linux. What really sets Arch apart is pacman. There is no denying that Pacman is the heart of the Arch system. So I decided it would be fun to poke around Pacman and see how it really works. From the get-go, Arch users are introduced to the concept of building custom packages (in the Installation Guide) using the Arch Build System.
To get started, I followed the instructions from
http://www.archlinux.org/docs/en/guide/install/arch-install-guide.html#abs
But first I needed a package that I could build. While playing around with Pacman, I had noticed that the p7zip package was not to be found in the Pacman repository. 7zip is a new exciting compression technology while gives usually gives a higher compression ratios that some of the older formats such as zip and RAR. In fact, you may have noticed that the size of the installers for Firefox and Thunderbird has gone down (for Windows at least) because they are using 7zip compression. There is a Windows 7-zip unzipper you can find at www.7zip.org. Unfortunately, there was no Linux alternative for a while. That is until someone wrote p7zip (http://p7zip.sourceforge.net/). Since Arch didn’t have p7zip in its repository I decided to stop complaining about it and build the package myself. I also picked p7zip because it’s a very small program with virtually no dependencies and would be a good package to get my feet wet with Arch’s build system.
The first thing I did to get started with ABS was to run the "abs" command as root. This got a package tree from an Arch mirror. This process only took a few seconds. After this I had to edit a PKGBUILD file. Creating Arch packages is relatively simple. All you need is the PKGBUILD script. A utility called makepkg reads the PKGBUILD script file and generates an Arch package from that (which can be installed by pacman). The format of the PKGBUILD file is intuitive and simple. You can also define dependencies in your PKGBUILD script. It also has support for configuring a package after it has been installed and after it is uninstalled.
Overall, I found the format of PKGBUILD and makepkg quite elegant yet powerful. In a few minutes, I configured a PKGBUILD script for p7zip. The script was relatively simple since p7zip does not have any dependencies. I ran makepkg and then installed the generated package. And it worked! My first Arch package — fairly painless. Overall I think Arch Build System is well done and it encourages the community to build they own packages that they need.
Conclusion
It appears to me that invariably, almost every week or so, a new Debian-based distribution comes out. The reason for this is simple: APT. With Debian’s package manager and pre-existing packages, what new distribution developer could resist it as a base? Apparently, not many. One of my favorite sites, Distrowatch, claims that about a that there about 128 distributions based on Debian. Out of all total distributions, only 29 can be classified as "Independent". Arch Linux is one of them. By doing this, Arch has taken "the road not taken" and traveled on the unbeaten path. This in itself is commendable but independence for the sake of it is pointless.
By writing their own package manager and having their own packages (i686 optimized) Arch has really set itself apart. This combined with their KISS (Keep it Simple Silly) philosophy makes Arch a good distribution to consider. One thing to note is that Arch is still at 0.7, which means that all the bugs have not been ironed out from it. I got a few weird error with Gnome in Arch. I also ran into one or two minor problems with pacman. Overall, there is no big show stopping bugs that would prevent me from recommending Arch wholeheartedly to you. Also, from what I have seen of it, the Arch community seems very welcoming and sensible. I didn’t see many RTFM type replies to my queries. Perhaps this is only because of the newness of the distribution but currently the community is a good plus to Arch. The community feel is prevalent throughout Arch. For example, the install guide encourages you to build you own packages and share them with other Arch users ("Archers").
As I have mentioned before, Arch feels a bit like a modern version of Slackware. I wouldn’t be surprised if a few Slack users jumped ship to Arch. Arch also possibly threatens the user bases of Gentoo and Debian. This would be especially true if Arch decided to add the aforementioned features such as the ability to unmask unstable packages. Gentoo users who are a little tired of long compiles will probably seen Arch as a viable alternative minus the compiling. The packages are also optimized for speed and efficiency which will appeal to any Gentoo user. Arch has made a good first impression on me. All the developers need to do now is polish out the edges. In short, Arch has strong start to the long road to becoming a mainstream distribution.
Summary
Pros: Strong package management; Attention to simplicity and standards; Good documentation
Cons: Still needs some polish; Configuring everything by hand can be a pain; Installation can be confusing to some users
The Bottom Line: If you like Slackware but wish it had a good built in package manager, you’ll love Arch. If you like having ultimate control over your system and don’t mind configuring everything by editing text files, you’ll fall for Arch. If you want to learn the innards for Linux, Arch would seem like a good platform to do so. If you’re expecting sound coming out of your speakers at first boot and USB drives mounting automatically on the desktop then you’d best stick to something like MEPIS or Ubuntu.
Author: Tarun Agnani is a software developer who recently graduated from college. He uses Linux for both work at play and dabbles in all forms of computing entertainment including Linux (obviously), Macintosh, and yes even Windows.
以上摘自Linuxtimes.net，很好的文章，打算翻譯出來放上linuxsir，如果有空的話：）
