Arch Linux: For Good or For Awesome?

Back to the Future with Arch Linux

Back in the day when I was an actual engineer getting my Master's degree from Carnegie Mellon, I had some decent development skills. My thesis was based around a 3Kloc project that got into the internals of the Linux Kernel involving a mandatory access control scheme using the Linux Security Modules infrastructure. At the time (in 2004), the 2.6 kernel was just being released and I was on the bleeding edge of development using the (at the time) new & trendy Gentoo distro. As a source based distro, Gentoo was excellent for my development purposes since I never had to worry about installing "dev" packages that were always missing with other distros, and it was generally easier for me to integrate my own source code since everything had to be compiled anyway. Having a full-blown development environment and all the dependencies was a big help when your day job involves poking with the kernel ad nauseum.

Well.. all good things come to an end. I got out of grad school, still use Linux exclusively, but Gentoo got to be a bit tedious. I didn't have the time to put into maintaining the system, and Gentoo went from being an excellent and dynamic distro to one with community infighting and all sorts of problems with the portage system that broke the distro. I started Law School three years ago, and that meant my free time to mess with a misbehaving Linux machine dropped greatly. So... I went over to the "dark side" and started using Kubuntu, which is the Ubuntu flavor supporting my KDE desktop.

Kubuntu worked well enough, and I've used it throughout Law School with mostly positive results. The Ubuntu guys do make it pretty stupidly simple to get a working machine, and when you want need to concentrate on reading cases, a system that is easy to maintain is ideal. However, as many others have pointed out, despite efforts to the contrary, Ubuntu tends to treat KDE as a second-class citizen compared to GNOME.

On to Arch

I own two PCs, a Lenovo notebook and a custom-built desktop PC. The notebook is mostly for school, and I don't want to make any changes to it until after I graduate in May. The desktop on the other hand is more open to experimentation. I blew away my current Beta of Jaunty Jackalope and replaced it with the current 64 bit Arch release (2009.02). Here are a few thoughts about my experiences....

Installation

Arch's installation is not cutesy and graphical like Ubuntu, but it is straightforward. I particularly enjoyed the fact that the Arch site has images for flash media like SD-cards or USB sticks so on modern systems that can boot from these drives an install does not require a burned CD. Arch also uses a "rolling release" system that updates packages incrementally. Thus, even though I downloaded the 2009.02 release from the Arch download page that download is just a (minimal) snapshot of the basic kernel, networking, and command line utilities that are needed in order to pull & install the rest of the system. Individual packages get updated when they are ready, so there is not a huge point where the entire system is radically upgraded all at once.

My recommendation: If doing things like running cfdisk and editing several files in the /etc directory are old hat to you, or if you want to learn and can follow directions, then you too can install Arch. I REALLY like the /etc/rc.conf file which consolidates a bunch of different system settings into one (well documented) file.

The default system

In 2.5 words: Lean & Mean. After the initial installer runs, you get a system that will boot up to a command prompt with networking support... and that is about it. If you are afraid of the command line, Arch is probably not for you. However, if you are either experienced with the command line, or want to learn how to setup a custom distro, Arch's configuration is not particularly complicated, and there is excellent documentation to help you along.

Things that Rock!

Customization

I REALLY appreciate the customizability that Arch gives you that was missing with Ubuntu. I will use the Networkmanager package as an example of how much better Arch makes things for those of us who like to be able to get the details right. Networkmanager is the popular package for managing network connections on a Linux system. Originally developed by RedHat and used in Fedora, it has spread to become the default way that most distros configure networking, especially on notebooks with wireless connections. I use Networkmanager on my laptop and I'd probably never be able to get onto a wireless network without it, and I do remember the bad-old days of trying to get the Orinoco 802.11b drivers working. Linux wireless networking has come a very long way in a few years and Networkmanager is great. BUT... I really have no need of it on my desktop which has a normal gigabit ethernet connection that just uses DHCP to access my LAN.

The problem with Kubuntu was that it was very difficult to either remove, or just customize Networkmanager: You get the kitchen-sink, or a bunch of broken dependencies. One thing that drove me nuts was that the wpa_supplicant process was running on my desktop machine... the one that does not even have a wireless card installed. I actually manually deleted the wpa_supplicant binary, and then tweaked my logging options so that my log files were not being filled with "error could not run wpa_supplicant" messages from Networkmanager, but this was not an optimal solution.

The Arch solution? Well Arch certainly allows you to install Networkmanager if necessary, but the default is a much simpler setup that allows you to configure an ethernet interface and set it up statically or with dhcp.... done & done! Arch gives me extra flexibility that Ubuntu hides in the name of ease of use.

One bonus to all of the customization I've mentioned is that the boot time on my desktop is... fast. After the BIOS finally clears out of the way, it about 14 seconds to having a KDM prompt running for login. The boot time is now spending more time running the BIOS checks than actually loading the OS... not too bad.

Pacman System for Package Management

While it isn't perfect (see below) the Pacman system is the fastest & leanest package management system I've found. Pacman does the standard dependency tracking and even has some features I haven't seen in other package systems, even apt-get. For example, installing a larger "meta package" like pacman -S kde where "kde" is just an alias for many sub-packages is a very common thing across many Linux distros and package management systems. Where Pacman improves upon the others is that it will actually allow you to pick & choose which elements of the meta-build you actually want to install, and then only install those elements (along with necessary dependencies). For example, when I installed KDE after I got to my initial command line, I was able to avoid installing certain parts of KDE that I don't use, like kdeedu, while still getting a fully-functional KDE desktop.

Pacman gets even better with the AUR system that allows you to build packages from source. As somebody who has installed compiled packages on Ubuntu, I am a real fan of this process. The reason is that you still have the flexibility of compiling software from source, but the end result is a package that pacman will install, check dependencies for, and also allow you to remove easily. This process is usually pretty easy, and it has already allowed me to (for example) get the newest versions of WINE running on my x86-64 box even though Arch does not officially package wine for 64 bit machines.

Pacman is also comparable to apt-get and other package management systems in that you can add extra package repositories to your system. For example, there are separate repositories for the specialized Kdemod4 packages that tweak KDE4. The repositories can be added to /etc/pacman.conf to use the new repositories:

[kdemod-core]
Server = http://chakra-project.org/repo/core/x86_64

[kdemod-extragear]
Server = http://chakra-project.org/repo/extragear/x86_64

[kdemod-playground]
Server = http://chakra-project.org/repo/playground/x86_64

Things that Lack Rock:

You can have my .vimrc when you pry it from my cold, dead hands!

So nothing is perfect, and Arch is no exception. While I think I like the ability to tweak items, this comes at the expense of having some packages not simply "just work" as you might expect them to. The worst offender here was the vi package. Yes kids, I fight for truth, justice, and lean & mean text editors, so I'm a vi (specifically vim) guy. Like many other distros, the arch-linux default install includes what I call a "quasi-vim" editor that looks like vim, but doesn't have all the features. The real vim needs to be installed later, which is not my major problem. Instead, the major problem was that my carefully crafted .vimrc files were not respected when I ran vi. Instead, the system default files in /etc/virc and /etc/vimrc were used, and they did not allow my personal ~/.vimrc settings to take precedence (as had been done on earlier distros from Ubuntu and Gentoo). This led to bad highlighting, no autowrap, and (even worse) the middle mouse button could no longer be used to paste text into a vim session in insert mode!!! OK, that rant may sound a little over the top to outsiders, but you vim users out there know what I'm talkin' bout: you don't mess with a man's vimrc! Fortunately I was able to fix the problem by completely removing the system files and then all of the sudden my normal .vimrc was respected.... I'm glad I figured out a solution or Arch might have had a short shelf-life.

SSH-Agent: Double Oh Configuration

Another issue I had was with the ssh-agent program, which is a nifty service that allows you to cache the keys used for authenticating with other systems if you have RSA keys configured. Ubuntu has a nifty system that starts one (and only one) ssh-agent instance running when you login, and from there is was easy for me to add startup scripts that added in my ssh keys so I could login to my backup system (provided by rsync.net) without needing passwords.

Arch does not have the same feature, but fortunately I was able to add a small shellscript to ~/.kde/env/ that runs ssh-agent in a way where all programs in my KDE startup will be able to use it. See here for more details. It would be nice if more stuff worked "out of the box", but Arch's support forums helped me fix the problem without too much trouble.

I'm liking Arch Right Now

I've been running Arch for just under a month, and so far I think I'm sold. The distro itself is well put together and I've enjoyed having a system that conforms to what I want. I really appreciate the Arch user community which is friendly and also shares knowledge well, particularly through the Arch wiki.

Over the years I've used Mandrake, Suse, Debian, Gentoo, Ubuntu/Kubuntu, and now Arch. I'm getting good at figuring out what I want and I'm still amazed at how much better Linux is today than it was when I started on it back in 2000. There's always more to learn, which is where all the fun is. For right now Arch is where I'm most comfortable, so Arch is for AWESOME.

KDE 4.2.2: Suggestions for Improvements

KDE 4.2 After a Few Months

Since I wrote my previous rant KDE 4.2 has gotten two bugfix updates, and I'm currently running it quite well on the (often maligned) beta of Kubuntu 9.04. I'm now definitely at a point where I could not go back to KDE 3.5 without complaining, which is a milestone in itself. I'm not alone, as the tide of negative opinions about KDE4 have begun to turn with 4.2..... so much that some pundits are saying GNOME is behind ... gotta love those crazy pundits ;-)

As an experiment, I've been pushing KDE's configurability to the limits, including using a desktop that does not have a panel, task manager, or Kmenu (yes it is still fully functional). I will detail more about how you can live (and even excel) without things like a task manager in a future post, but in the interim, here are some screenshots showing my desktop and the widget layer in action:

My Brief Wish-List of Minor Features

So here's my list of improvement suggestions. I will be submitting these to the KDE Brainstorm site and hopefully some or all of these improvements can be made in time for KDE 4.3.

Shortcuts: Mouse + Keyboard Support Needed!

This is already a feature that Compiz supports, and should be added to KDE. I can think of three instances where letting the mouse be used in conjunction with the keyboard will improve the desktop experience, and I'm sure there are others I haven't come across. First, desktop zoom: Instead of requiring only keyboard shortcuts like META+= or META+-, allow for the mousewheel to be used in conjunction with a modifier key, just like how many apps allow CTRL+WHEEL to zoom in & out. Second, the Mouse Mark effect is a nice feature that is unfortunately way too awkward to use right now since it is only activated from the keyboard. Instead, allow for a combination like CTRL+ALT+Left Click to turn on the marking, and then drag the mouse to draw, releasing the button to stop drawing. Last, window transparency. While it is possible to set this by right-clicking the title bar, it would be much easier to use a key combo + mouse wheel to increase/decrease the transparency rapidly. This can be very useful for quickly making a window transparent to see what's underneath, then restoring its opacity.

KWin functionality: Gimme a Shortcut to Restore All Minimized Windows

This recommendation is partially due to the fact that I am not using a task manager at all.. which I know is a little unusual, but actually gives me a unique perspective on how to manage windows without going down to the task manager to click on programs. The biggest issue I've encountered is with minimized windows. With a task manager, you still see the program icon, but without one, do those windows disappear forever? Fortunately, the answer is no. Right now the Present Windows effects will bring up all windows, even minimized ones, giving the chance to restore windows. There are a couple of problems with this solution though. First, if I am on a desktop with only one window that is minimized, the "present windows only on this desktop" effect will not actually engage (see below for my request on that), requiring me to either present windows from all dektops, or to open up a second window so I can get access to the first window... annoying. The second way that this is annoying is that while Present Windows is a great effect, it was never designed to indicate which windows were minimized, so a function designed specifically to restore windows would be useful for its own sake.

Instead, it would be great if a "restore all windows" keyboard shortcut could be added to the "Global Keyboard Shortcuts" under the "Kwin" keyboard shortcuts setting. It may already be possible to make a quick & dirty dbus command that would tell Kwin to restore all the windows on a desktop, but I'm not familiar enough with the Kwin D-Bus interface to pull that off right now.. anyone with more knowledge is welcome to chime in.

Present Windows Effect: Have it activate even when there is only 1 window available

So this is probably done intentionally in KDE right now, but if you run the Present Windows effect and there is only one window to present... nothing happens. Is this the most efficient action to take? Yes. However, from a usability perspective, it might not work too well, since the user may very well be expecting something to happen.. and then nothing does. Even slightly scaling the one window on the desktop to show the effect is working is less disruptive when the user makes a command. Additionally, this is actually inconsistent behavior from how other effects plugins are already operating. For example, the Cover-Switch and other ALT-TAB switch effects will engage when there is only one window on the desktop. See Here:

Re-enabling, or making an option to show only one window when Present Windows is engaged will help give a more consistent experience, and (in my case) is also helpful since it will help in restoring windows when there is only one window on the desktop and that window has been minimized.

Alt-Tab Switching: Option to Show Windows from All Desktops

This is pretty self-explanatory, and unless my memory is failing me I'm pretty sure it used to be an option that has disappeared from the settings in my Jaunty Jackalope build using KDE 4.2.2. Basically, just add an option to "show windows from all desktops" so that the ALT-TAB window switcher is capable of going through all the windows, not just those from the current desktop. You could even have slightly different keyboard shortcuts to have window switching from the current desktop and from all desktops, just like how the Present Windows effect already works.

The Lock/Logout Plasmoid: Improve the Interface!

This is another complaint that comes from the fact that I am not using the regular KMenu or Lancelot at all, but instead tried to just put the Lock/Logout plasmoid directly on my desktop. My system is a desktop system, and in order to save power I like to suspend it to RAM, which allows me to restart it in just a few seconds. Unfortunately, the default lock/logout plasmoid has some major ergonomic issues when it comes to suspending the computer, as seen below:

The pictures don't fully capture how easy it is to accidentally shut the system down entirely instead of doing the action you actually want done. I got frustrated enough that I actually came up with my own hack to put a "suspend to RAM" button on the lower left hand corner. You can see the button in the screenshots posted above. While this solution works for me, it is a real hack: it is not a plasmoid, but instead an app linked to a shell script that invokes the pm-suspend command line, that in turned required me to edit the sudoers file so I don't need to put in a password to suspend the machine... not a long term solution.

Instead, the suspend and hibernate options should be clearly displayed such that it is easy to invoke the correct choice, and the following picture is a (very poorly done) mockup of what it might look like:

A final option might just be to add new plasmoids for each option: shutdown/restart/suspend/hibernate/logout, and then let the user lay out those functions in different ways.

Test Widgets Both in & out of a Panel

Certain widgets do not do well put into a panel and vice-versa. For example, in my case I am not using the Device Notifier because when placed on the desktop it does not go into its normal iconified mode that it takes when added to a panel. I know that some plasmoids are really not designed to operate in a panel, while others don't know what to do outside of a panel. If a plasmoid can only really work in or out of a panel, then it might be smart to alter how the "Add Widgets..." interface operates so that it is contextually aware of where a widget will be added, in order to prevent misbehaving widgets from going in the wrong place.

Final Thoughts

Well so far so good with KDE 4.2. Nothing is perfect, but KDE 4 has reached the point of maturity where the problems I am noting are minor, and the development community has gotten to a point where many problems can be fixed relatively quickly. I will post an in-depth discussion of the heavily-modified KDE 4.2 desktop I'm running right now, and how you can get something similar using the extensive customization support that is already built into KDE!