First impressions with Arch Linux
I have been considering for some time trying some Linux distro that would be a little faster than [[Ubuntu (operating system)|Ubuntu]]. I made the switch from [[Debian]] to Ubuntu some time ago, and I must say that I am very pleased with it, despite it being a bit bloated and slow. Ubuntu is really user-friendly. This term is often despised among geeks, but it does have a huge value. Often times a distro will disguise poor dependency-handling, lack of package tuning and absence of wise defaults as not having “fallen” for user-friendliness and “allowing the user do whatever she feels like”.
However comfortable Ubuntu might be, my inner geek wanted to get his hands a little bit dirtier with configurations, and obtain a more responsive OS in return. And that’s where [[Arch Linux]] fits in. Arch Linux is regarded as one of the fastest Linux distros, at least among the ones based on [[executable|binary]] [[Software package (installation)|packages]], not [[source code]]. Is this fame deserved? Well, in my short experience, it seem to be.
First off, let us clarify what one means with a “faster” Linux distro. There are as I see it, broadly speaking, three things that can be faster or slower in the users’ interaction with a computer. The first one, and very often cited one, is the [[booting|boot]] (and shutdown) time. Any period of time between a user deciding to use the computer and being able to do so is wasted time (from the user’s point of view). Many computers stay on for long periods of time, but for a home user, short booting times are a must. A second speed-related item would be the startup time of applications. Booting would be a sub-section of this, if we consider the OS/[[kernel (computing)|kernel]] as an “app”, but I refer here to user apps such as an e-mail client or text editor. Granted, most start within seconds at most, many below one second or apparently “instantly”, but some others are renowned for their slugginess ([[OpenOffice.org]], [[Firefox]] and [[Amarok (software)|Amarok]] come to mind). Even the not-very-slow apps that take a few seconds can become irritating if used with some frequency. The third speed-related item would be the execution of long-running CPU-intensive software, such as audio/video coding or scientific computation.
Of the three issues mentioned, it should be made clear that the third one (execution of CPU-intensive tasks) is seldom affected at all by the “speed” of the OS. Or it shouldn’t be. Of course having the latest versions of the libraries used by the CPU-intensive software should make a difference, but I doubt that encoding a video with [[MEncoder]] is any faster in [[Gentoo Linux|Gentoo]] than Ubuntu (for the same version of mencoder and libraries). However, the first two (booting and start up of apps) are different from OS to OS.
Booting
I did some timings in Ubuntu and Arch, both in the same (dual boot) machine. I measured the time from [[GRUB]] to [[GNOME Display Manager|GDM]], and then the time from GDM to a working [[desktop environment]] ([[GNOME]] in both). The exact data might not be that meaningful, as some details could be different from one installation to the other (different choice of firewall, or (minimally) different autostarted apps in the DE). But the big numbers are significant: where Ubuntu takes slightly below 1 minute to GDM, and around half a minute to GNOME, Arch takes below 20 seconds and 10 seconds, respectively.
App start up
Of the three applications mentioned, OpenOffice.org and Firefox start faster in Arch than in Ubuntu. I wrote down the numbers, but don’t have them now. Amarok, on the other hand, took equally long to start (some infamous 35 seconds) in both OSs. It is worth mentioning that all of them start up faster the second and successive times, and that the Ubuntu/Arch differences between second starts is correspondingly smaller (because both are fast). Still Arch is a bit faster (except for Amarok).
ABS, or custom compilation
But the benefits of Arch don’t end in a faster boot, or a more responsive desktop (which it has). Arch Linux makes it really easy to compile and install any custom package the user wants, and I decided to take advantage of it. With Debian/Ubuntu, you can download the source code of a package quite easily, but the compilation is more or less left to you, and the installation is different from that of a “official” package. With Arch, generating a package from the source is quite easy, and then installing it with [[Pacman (package manager)|Pacman]] is trivial. For more info, refer to the Arch wiki entry for ABS.
I first compiled MEncoder (inside the mplayer package), and found out that the compiled version made no difference with respect to the stock binary package. I should have known that, because I say so in this very post, don’t I? However, one always thinks that he can compile a package “better”, so I tried it (and failed to get any improvement).
On the other hand, when I recompiled Amarok, I did get a huge boost in speed. A simple custom compilation produced an Amarok that took only 15 seconds to start up, less than half of the vanilla binary distributed with Arch (I measured the 15 seconds even after rebooting, which rules out any “second time is faster” effect).
Is it hard to use?
Leaving the speed issue aside, one of the possible drawbacks of a geekier Linux distro is that it could be harder to use. Arch is, indeed, but not much. A seasoned Linux user should hardly find any difficulty to install and configure Arch. It is certainly not for beginners, but it is not super-hard either.
One of the few gripes I have with it regards the installation of a graphical environment. As it turns out, installing a DE such as GNOME does not trigger the installation of any [[X Window System]], such as [[X.org Server]], as dependencies are set only for really vital things. Well, that’s not too bad, Arch is not assuming I want something until I tell it I do. Fine. Then, when I do install Xorg, the tools for configuring it are a bit lacking. I am so spoiled by the automagic configurations in Ubuntu, where you are presented a full-fledged desktop with almost no decision on your side, that I miss a magic script that will make X “just work”. Anyway, I can live with that. But some thing that made me feel like giving up was that after following all the instruction in the really nice Arch Wiki, I was unable to start X (it would start as a black screen, then freeze, and I could only get out by rebooting the computer). The problem was that I have a [[Nvidia]] graphics card, and I needed the (proprietary) drivers. OK, of course I need them, but the default vesa driver should work as well!! In Ubuntu one can get a lower resolution, non-3D effect, desktop with the default vesa driver. Then the proprietary Nvidia drivers allow for more eye-candy and fanciness. But not in Arch. When I decided to skip the test with vesa, and download the proprietary drivers, the X server started without any problem.
Conclusions
I am quite happy with Arch so far. Yes, one has to work around some rough edges, but it is a nice experience as well, because one learns more than with other too user-friendly distros. I think Arch Linux is a very nice distro that is worth using, and I recommend it to any Linux user willing to learn and “get hands dirty”.
Super Jamie said,
October 9, 2009 @ 14:20 pm
Arch is a great distro, I ditched Ubuntu and ran it as my primary OS sometime before the latest Arch distro CD was released (so sometime 6-12 months ago).
I absolutely love the BSD-style init, it’s so much simpler than the SysV-style mess of runlevel folders and scripts. The existence of yaourt is the best thing ever, a package manager that compiles from source, brilliant! I also really liked pacman, it was so simple and yet powerful. You can do almost all the same things with apt but the functions are spread over several binaries and convoluted unintuitive commands which I can never remember. In fact, the amount of control all the distro-specific tools give you over the PC is superb. The community is great too, very helpful and full of patient, creative and talented people who are happy to share their latest script/find/trick/theme with you.
Eventually, though, I got sick of two things. First that Arch is not overall as “polished” as some other distros. Lots of nice little settings I’d gotten used to in Ubuntu like Gnome’s default Places just aren’t there in Arch. And secondly, I realised I was spending a sizeable amount of time just maintaining the distro. Fixing broken things after updates, tweaking yet another module or config file or service when I wanted to do something which just works out of the box on Ubuntu. I use Linux because it lets me do my own “stuff” faster, not because I want to spend my life in a command prompt asking questions on forums.
My time with Arch was great and it was a good learning experience into more inner Linux workings, as well as seeing which things can be better/worse when trying different distros, but I’ll stick with Ubuntu for now.
isilanes said,
October 9, 2009 @ 15:35 pm
Thanks for the comment, Super Jamie!
Maybe I will go back to Ubuntu too, who knows? You are right about apt (apt-get or aptitude), but pacman also has many options, and not so easy to remember. In both cases, the man command is your friend :^) Besides, have you considered wajig? You should give it a try if you want an “all-in-one” substitute for aptitude, apt-cache and dpkg.
Super Jamie said,
October 10, 2009 @ 0:17 am
I found pacman’s options easier to remember, they’re mostly combinations of two upper/lowercase letters. Like you say, the apt suite is spread over apt-get, apt-cache, aptitude, dpkg and has options like –show –showpkg –policy which make no intrinsic sense. I have no problem reading man pages but it’s annoying to have to do every time I want something :)
Realitically, I use Synaptic most of the time anyway. I’ve not heard of wajig so I’ll look into it, thanks for the tip! I’ve heard it’s bad practice to mix package managers, as they can mess up your dependencies and other records? I do know if you pin something to a specific version in Synaptic, apt-get still wants to update it, even though there appears to be an apt standard for pinning packages.