DROID coming Soon

Looks like my stubborn refusal to drop Verizon for cutesy phones with subpar networks has finally been rewarded. I'm getting out there early, and we'll see if this IS the droid I'm looking for. Look for a real review later, until then, try Engadget.

NFSv4 & Gigabit Ethernet: A Semi-Functional Combination

First: Dig up Old Box. Second: Off With its Head!

So I had an old P4 desktop that had served me well from 2003 until the beginning of 2008 when I built my current Core2 box. It had been sitting around collecting dust until a few days ago when I grabbed 2GB of DDR400 RAM and slapped Arch Linux on it. It's an old Northwood core P4 that came with one onboard Gigabit card, and I slapped a second one in to make it a dual-homed host. Finally, after the OS was installed and I could get networking automatically running at boot... I pulled the video card to save on power, and since I wanted to see how an normal desktop PC would behave with zero graphics capabilities.

So I'm running headless, which is fine for right now since I managed to get the installation right enough that it gets onto the network and runs SSH. One of the reasons behind why I have two network cards is that the (better) one is hooked directly to my main PC and has a static IP address. It's there for performance since I run my NFS over that interface, and also for reliability since assuming the headless box can boot, it can get that static interface configured with a minimum amount of hassle. Of course... that assumes the machine can boot....

Right now my main concern is that this headless box is fine as long as I'm able to get it on a network. That's fine for normal operations, and this thing has a very stripped-down set of software that does not have to be updated often, but you never know when an update will result in a system that does not want to reboot without manual intervention. Since this box does not have normal serial ports, my only current option is to slap a video card back in and reboot...but I've asked some other people if they have solutions for that problem... we'll see.

NFSv4: FTW?

The next step is to actually do something with this nifty headless box, and I choose to make an NFS server. While I've used NFS as a client in larger settings like school, this was the first time I had ever setup a box to serve NFS. I chose NFS more to experiment, and because I've heard it has better performance than something like SAMBA in a pure-Linux environment which is where I'm running it. This isn't some crazy storage array, right now I only have one disk in the server with about 150GB free for the actual NFS export. I'm doing this more to get experience for 4TB RAID array I intend to build at some undertermined future date when buying a bunch of 2TB disks is even cheaper than it is now ;-)

The setup was actually pretty easy, although I didn't bother with the actually complicated part which is setting up security. I did make it so the /usr/sbin/rpc.mountd server only listens on my dedicated network port, so that my desktop (client) is the only machine physically capable of trying to mount the server. So, when I say that NFSv4 is relatively "simple" to setup, I'm sort of skipping all the Kerberos stuff that is necessary but also a real PITA to setup in the real world. I'm not saying it's as easy as right-clicking a folder and selecting "share this", but the Arch Linux Wiki has pretty clear instructions, and it doesn't take too long to setup. In fact, the Arch Wiki is informative enough that I'm not going to bother repeating it... but I will share some of my own specific issues below.

Teething Issues

I'm not expecting the setup to be perfect, but I definitely know why some people really hate NFS now (even though I think it's OK). When it is working, it's just like the mounted partition is on your own machine, but when something goes wrong, you'll see a mounted partition that hangs every single application that even tries to list the NFS directory. Fortunately, umount -f was invented just for these situations, but the NFS client's default configuration means that if your server flakes out, expect your client machine to hang up pretty badly, without even a timeout. These problems seem to rear their heads the most when I reboot the client computer, and try to re-establish my NFS mount. Even if I cleanly unmounted before the reboot, I've noticed that my NFS share will often be in a semi-comatose state where I can mount it, but any writes to the share start to hang. See below for why I think some of the source of this may be hardware related, but it would be great if the NFS client was a little more cognizant that Bad Things Happen (TM) and to not assume that there is a perfect NFS server 100% of the time.

The underlying issue: Flaky Gigabit cards

I've noticed that most of my problems have boiled down to flaky gigabit ethernet cards. Now, these cards "work" in Linux in as much as there are drivers and you can configure the interfaces, but I need more than that for what I want to do. In order to get as close to real gigabit speeds as possible I went to enable jumbo frames... which causes all sorts of problems with low-grade hardware. The good news: My Marvell Yukon2 PCIe controllers on my new machine can jump to 9000 byte frames without any issues. Also, it appears that the old Intel Gigabit controller built into the motherboard on my old machine does 9000 byte frames too. However, before I got to this point I had to go through the process of dealing with cards that used both the r8169 and skge drivers...and it was not pretty. The r8169 card worked with jumbo frames up to 7200 bytes (it refused to use the more common 9000 byte size) but then after this worked for a few hours.. the card dropped off the face of the earth and could not be reached, even after I rebooted the machine. Even worse, the card with the skge driver would come up fine, allow you to set an MTU of 9000 bytes, but then any real packet operations immediately froze the card and any pending NFS operations.

The main moral of my story: be VERY selective with the ethernet cards you use if you want to do anything more intensive than a simple home network. In my case, the Intel ethernet controllers are outstanding (they may be $5 more on Newegg but you get what you pay for) and also the Marvell 88E8056 controllers built into my X38 motherboard are also quite good. Be warned: Just because cards accept Jumbo Frame MTU's does not mean they will actually work when put under real stress. By the way, the performance using Jumbo Frames is quite a bit better than without, especially because my P4 box is not exactly a heavy-weight in the CPU category and all that extra packet processing does slow things down. Just about anything made this century can handle a saturated 100Mbit connection, but once you get above that you need to make sure the parameters are tweaked in order to get the performance listed on the box.

How its Working Now:

The good news first: If I do a large continuous write to my network share I'm averaging a little over 70 megabytes per-second, and from the saw-tooth graph I get on gkrellm, the network itself is no longer the bottleneck since it can easily exceed 100 megabytes/sec in transfers, but then drops down since the old disk in the server can't keep up. By the way, for those of you who like SCP (and I do too) I get about 40 Megabytes a second accross the wire with Jumbo Frames, and 30 Megabytes with normal frames. With NFS, my P4 box is spending a bunch of time in the IOWAIT state since the disk is the bottleneck, but with SCP, the CPU overhead becomes dominant since all that cryptography takes its toll at high speeds.

So I've got a nifty NFS server setup, and a fun platform to mess around with too. I eventually intend to turn my current desktop machine into a RAID file server as well as a home-network server providing DHCP/DNS caching/Printer/Firewall/Routing services, so this is a good first step to try things out.

KDE 4.3: More ranting Review & Comment.

KDE turns 4.3

I've already ranted about how awesome KDE 4.2 was, so this is an update for what I'm currently doing with KDE 4.3RC2. So far I'm liking a lot of it, but I also want to share my own grievances. At this point I think KDE has the greatest potential of any desktop system I've seen (be it Linux/Mac/Windows) to really be dominant, and even make the jump from conventional desktops to mobile devices without having to be completely rewritten. However, I'm tempering all of this with some pleas on how KDE may be better off with fewer features, as long as those features are working 100%

How KDE 4.3 Customizes for my own Tastes:

Here's my basic desktop, note the lack of a standard panel:

A few words on how this desktop is laid out. I'm using the new AIR theme right now, which is the new default for KDE 4.3. A lot less black than the previous Oxygen, and I'm finally happy with a default KDE theme choice (although there are still plenty of additional themes available). I do not use any of the "normal" KDE program launchers, and I don't have a panel with a taskbar either. So how do I get anything done? That takes a little explanation.

For managing windows, since I don't have a taskbar, I re-mapped the "scale window" keyboard shortcuts to the F9 and F10 keys. F9 is for selecting all windows on my current desktop, and F10 for all available windows. These effects also restore minimized windows, so no need to worry about minimized windows disappearing forever. The ALT+TAB combo still works too and I can traverse windows in a list that way. I actually find that these tricks are a good bit faster than hunting for the right window on the taskbar. I need far less mouse interaction to jump between windows than using the conventional workflow. Once windows are presented, filtering can be done by typing in the window's title (a feature adapted from Compiz) EDIT:(a feature that was copied by Compiz, thanks to sebas for pointing this out).

To actually run applications I have two major methods I use from the GUI that have made things like the "K" launcher superflous. First, along the bottom you see my Daisy quicklauncher. Daisy is a very nice application launcher plasmoid that I've configured to act as a simple program launcher. It can be configured similarly to the OS X dock, but I only use it to quick-launch common applications.

So what do I do if an application is not on the quick-launch bar? I use the amazing krunner application that is my new Swiss-Army Chainsaw for running things from the desktop. Krunner does not require you to type the exact name of a command to run, it can look at any application with a .desktop file and use words to associate the application with what you want to run. Some of these features are already present in KDE 4.2, but krunner in 4.3 appears to be much more stable & versatile:

Krunner has a plethora of other functions that are too numerous to fully outline here, but it can also act as a calculator, currency converter, and even a shortcut to Google or Wikipedia searches:

Things That Need Attention

So, as with every release things are improved but not perfect. While a project like KDE can never truly be "finished" a few things could stand to use some polish. These requests are not really for new functionality, just to get the currently advertised functionality working properly.

First: Nepomuk needs a massive amount of attention. I won't lie, I turn the service off right now, but for experimentation, I turned it on and let the Strigi indexer churn through my harddrive for 15 minutes. After that was done, I opened up a simple Nepomuk search, and tried typing in a single word search ("Major") which, being a common word, should have turned up matches in several documents. Unfortunately, the search ran for 45 minutes at 100% CPU power and produced no results. I killed it at that point, and I'm hoping that my (rather modest) collection of files isn't too much for Nepomuk to handle. The theory behind Nepomuk is interesting, but if it is going to actually deserve to run on my desktop, it better work right, and not hog too much RAM in the process.

Second: While I don't use kmail or the KDE PIM suite, I've heard horror stories about Akonadi and the need to have a full-blown Mysql server running just to look at email addresses: Not cool guys, get the bloat out. Any address book so complex that it needs a Mysql database is going to be on a centralized LDAP server to begin with anyway.

Third: Work on the uncool stuff, even if it isn't as much fun as the latest plasmoid. Let me explain by example: the kio_http utility had a bug that would cause it to go to 100% CPU usage when invalid gzipped data came down the wire. This affected many higher level applications, including my favorite yAWP weather plasmoid, that I much prefer to the KDE default.

So what is the problem with this bug? Well... it was a basic coding oversight that failed to check for a well-known error condition that had a pretty obvious negative impact on the system. The bug was first reported on November 24, 2008... and the original bug report pointed out the SPECIFIC CODE that was broken! Here's the problem: the fix wasn't put in until July 5, 2009.. that's over seven months with a bug that was widely reported (see all the duplicates of the original) and that was a basic error in not checking return values. This is the type of programming that isn't necessarily "fun", but it is vital to making sure that people actually want to use KDE. See below for more on how I'm afraid people are too focused on the newest social-networking plasmoid and not enough on making stuff work.

Another basic problem that I fortunately have a work-around for is that the KDE Network manager plasmoid is STILL in a state of disarray. I know that the developers are working on some major updates for it, but in my own experience the plasmoid has actually regressed from the KDE 4.2 days. Using the current SVN tree, the plasmoid will run and detect wireless networks OK.. unfortunately it will absolutely refuse to accept my WPA passwords and actually connect to those networks. I have kwallet open, I have 74 prompt screens asking for the passphrase over & over again, and I have no working connections. I have to use the gnome nm-applet program right now, which works just fine and even allows for proper secure-caching of WPA passphrases so I can autoconnect. Getting on a wireless network is a basic task that anyone with a laptop needs to have working, and when it comes to priorities, this should be at the top of the list.

Finally: RESOURCES, RESOURCES, RESOURCES. I'm not exactly what you'd call a tree-hugging hippie, but when it comes to my system RAM, I'm all about conservation! Most of my problems are not directed at KDE itself, but with the combination of Qt and X.org which seem to enjoy frittering away memory and then never releasing it back (short of me killing the X server entirely). Unfortunately, since KDE is based on Qt, it inherits all of these problems. However, there are some things that the KDE developers could do to minimize resources:

• Kill off those annoying kio processes! I know that they are supposed to time-out on their own, but I suspect that when I suspend/resume my system, the timeouts fail and I have a bunch of kio_https lying around that are doing nothing. These things should open, do a specific task, and then bail. The same goes for kio_file, kio_thumbnail, and kio_trash processes... get the job done and then EXIT properly.


• Here's a minor but annoying one: Kwrited... a background daemon using 18MB of resident memory to catch and give a fancy gui to the old-school "write" command on the terminal. OK, I guess it's cute for the systems that still bother to use this stuff... but allow me to TURN IT OFF! As it stands I kill it and delete the executable every time I upgrade KDE now....


• Shared Memory Hogging: I use the (very common) binary Nvidia graphics drivers that are not compiled with -fPIC, meaning every Qt app that I run loads up roughly 10MB of non-shared code sucked in from the Nvidia drivers. Yes, I wish that Nvidia would fix this, and I'd even buy a faster card if it really hurt performance (Nvidia you're losing money)! However, since this is apparently not in the cards, I have heard that it could be possible to have a parent launch program that takes the memory hit one time, and then forks processes that can still share memory. This would be great for the little programs like klipper, kmix, etc. that are all very small, but are still sucking down 16-20MB each... that usage adds up quickly

My Personal Plea for KDE 4.4: Quality NOT Quantity with the Features!

When KDE 4 first appeared the two major criticisms were that it was different than the 3 series, and that it lacked features of the 3 series. KDE 4 is going to continue to be different than 3 in many ways, but more and more people have come around to realizing that its differences are mostly for the better. On the feature front, most of the important features from KDE 3 have already been brought over, and KDE 4.3 adds in a few more ones that people were missing. There might be a few features left out that some people find important, but at this stage all the basics seem to be implemented... however the quality of the implementation is another matter that I think needs addressing. I think that the developers have been in a headlong rush to develop new features, but that it is coming at a cost to system stability that is starting to take a toll.

I won't repeat my criticisms from above about specific bugs that are annoying me, and are long-standing issues that have not been fixed. The point here is that KDE 4 is actually ready from a feature perspective, it is just that the quality of what KDE has got needs to be honed to be faster and more reliable.

I'm not advocating that there should be no new features in KDE 4.4! I'm just saying that at this point, the marginal gains to KDE from improving speed, stability and bugfixing plasmoids to "just work" are going to make a more positive impact on the user experience than rushing off with some new plasmoid or huge database project that leaks memory. One good example I hate to point out is the new social-networking plasmoid that has gotten a good bit of attention lately. I'm not saying that it shouldn't be developed, but I am saying that when basic plasmoids like the weather forecast plasmoid have longstanding bugs and are lackluster compared to third-party plasmoids like yAWP (which can't seem to get included in the KDE default branch) then there is an issue with developer priorities. While making existing features work right is not as much fun, it is probably a better way to win new users than yet-another social network that happens to have a plasmoid.

Another one of these half-done features deals with plasma workspaces and how they do or do not map to virtual desktops. I (think) I get the notion that plasma workspaces are supposed to support independent plasmoids, while virtual desktops are for organizing regular windows. Unfortunately, I've never seen any value in using the cashew to (akwardly) zoom in and out of workspaces that often appear to pop into existence at random. I'm sure this is useful for developers that want to debug plasma, but from an end-user experience I don't want two separate and confusing paradigms for moving between workspaces, I want one that works right. I've messed around with the separate plasma workspace on each desktop option, but it's never really behaved correctly. This feature could be useful if it was done right but it's actually a hindrance to even have it at all if it is done wrong.

Incidentally, I'm not only criticizing KDE specifically here, as other projects have the same issues. Look at my screenshots and you'll note that I like music, which is why I'm using juk and not amarok. When amarok developers think it is more important to use 1GB of RAM to play music, while simultaneously not even having a basic equalizer plugin, I give up. I'm not saying that Juk couldn't use more features, but I'm willing to bet $100 that the vast majority of users want a feature like a solid and reliable equalizer plugin that could have custom profiles for individual tracks over the ability to add a facebook plugin any day of the week. KDE's Juk wins with me because it is easy to use and reliable at what it does.

I also want to point out that several new features are very helpful. KDE 4.3 has some nice improvements that DO focus on making the desktop experience better, and the folder-view plasmoid is an excellent example. A folder within a folderview can now be accessed without having to open the full file-manager, and executables on the desktop now come with a red exclamation mark and a warning before being run the first time. These types of features have a direct impact on making the desktop both more functional and more secure... this is exactly the type of innovation that directly helps the desktop experience, and KDE 4.4 really just needs more stuff like this to really shine.

KDE: The OS X of Open Source

For anybody who thinks I'm being too harsh, I want to pay KDE 4 a huge compliment: I think that the 4 series now has OS X like status... and no I don't mean it's overpriced for hipsters :-) What I really want to say is that OS X started in a similar situation to KDE 4 in that it had an entrenched userbase who loved its predecessor, but while the early versions of OS X had a lot of promise, they also lacked many things that the userbase were used to. As time went by, OS X's feature set filled in and as of 10.5 the biggest issue that most people have is that there are too many features that are not fully "just working" for many users. Hence, the Snow Leopard release that is not so much focused on the latest whiz-bang changes, but on getting the existing features refined, and doing it all faster.

I think KDE 4.4 can be a Snow Leopard-esque release for the K developers, that really works on refining things to be smoother for the end-user without having to focus on huge changes. KDE 4.3 is looking better (always a positive) and if 4.4 focuses on making KDE leaner, meaner, and more refined it will be the type of desktop that nobody will be able to say no to!

Jack Bauer Approved: KDE 4 on 24!

For those of you who are fans of 24 and watched the 4:00 AM - 5:00 AM episode this week, you got to see a little KDE 4 action on the screen. It turns out the terrorists are using a KDE 4 desktop to help further their evil plots. While I'd prefer to see Chloe doing some datamining using Nepomuk, any publicity is good publicity ;-)

This is not the first time that KDE has been seen on 24 or other shows like Alias, but this is the first time that I think I have seen a KDE 4 variant on TV. Also, look very carefully at the photos below, and you will see that it looks like the picture frame plasmoid and the SVG analog clock plasmoid are being used on the desktop. The analog clock is very appropriate for a show like 24! Please see this episode on Hulu to check out all the details.

First screenshot of KDE 4 in action with the terrorists

Another shot with KDE 4.2 on a nice widescreen monitor.. the terrorists know how to buy equipment

This is a screenshot of a different laptop that the terrorists had in their van. I'm not sure if it's KDE or a custom job done for the show. Sorry for the blur, the screen looks clearer when viewed in the video.

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!

Hand-cranked Nvidia drivers on (K)Ubuntu 9.04

This is a long-overdue blog post about how I install the latest & greatest Nvidia desktop drivers under Kubuntu (the same advice applies to Ubuntu too). The following guide has two major portions, the first is how to proceed at setting up your system to be able to compile & install the Nvidia drivers, which only needs to be done once, and the second section is how to complete the installation of a particular set of drivers. All instructions are run on a 64 bit version of Kubuntu 9.04, but there are no KDE specific ports, so the same basic steps should work on any flavor of Ubuntu.

Initial System Setup

To use restricted modules or not...

By default Kubuntu comes with restricted modules which actually have a proprietary Nvidia graphics driver. The problem is that this driver is generally the one that is current at the time the distro is released, but then will not be updated for another 6 months. Considering that I am writing this article on March 31st 2009 and Nvidia put out 5 driver updates this month alone, the default driver will become obsolete rather rapidly. If everything works great... hey, use the default, but you aren't reading this post because you like the defaults ;-)

The problem is in the linux-restricted-modules-generic and linux-restricted-modules-common and how Ubuntu packages third-party proprietary modules. On my desktop, the only proprietary kernel driver I need is the Nvidia driver... so I actually removed these packages and ALL of the proprietary modules went bye-bye, making it very easy to install my own version of Nvidia's drivers without Ubuntu interfering by trying to overwrite them.... if you are lucky enough to be in this situation where you don't need any other proprietary drivers, I suggest you apt-get remove linux-restricted-modules-common linux-restricted-modules-generic before proceeding with the rest of the process.

So why would it be a bad idea to remove the restricted modules? Well, it is the Ubuntu packager's all-or-nothing approach. Say you have a laptop and need to have a proprietary wireless network driver... you cannot simply remove the unwanted Nvidia driver and keep the wireless driver installed! It's either all the restricted drivers or none of them. Fortunately, there is a way to prevent the Ubuntu provided Nvidia driver from interfering with your own driver. This is an important step because if you do not follow it, you will end up with an installation of the new Nvidia driver that works perfectly fine... until you reboot and Ubuntu will automatically whomp your new driver with its own version and likely cause the X server to fail to load (I speak from personal experience here)

Here's the solution: edit (using sudo to get root permissions) the /etc/default/inux-restricted-modules-common file. We want to go to the bottom and edit the DISABLED_MODULES entry to look like this: DISABLED_MODULES="nv". Note: if you have other modules in that entry, leave them alone and simply add an additional "nv" to prevent Ubuntu from re-loading it's own Nvidia driver instead of the one you will be installing.

Setting up the build environment

Install Nvidia drivers does require some compiling, but don't worry, it is a (relatively) painless process. You do need to have a few packages installed so that the compilation process can succeed. The packages are:

• linux-headers-generic


• gcc


• make


• automake


• xserver-xorg-dev


• pkg-config

Some other packages may be installed to support these, but hopefully this should be sufficient (as I am an occasional developer, I have quite a few more development packages installed which sometimes means I don't know exact dependencies needed to make a package build).

Good news: Once you've made these updates, you have the basic system configuration needed to install the drivers, and you don't have to repeat the above steps to install new drivers!

Downloading & Installing a new Driver

Grabbing a New Driver

The best place I've found to check for new Nvidia drivers is not the Nvidia website (which is a pain to navigate) but instead the Linux forums at NVNews.net. They keep a sticky post to the most up to date drivers. For example, I have the (mostly) current 180.41 driver installed as of this writing. When you download a driver, especially for 64 bit users, it is important that you download the correct variant of the driver. For example, there are three distinct variants of the 180.41 driver: NVIDIA-Linux-x86_64-180.41-pkg0.run, NVIDIA-Linux-x86_64-180.41-pkg1.run, and NVIDIA-Linux-x86_64-180.41-pkg2.run. For my purposes I always download the largest available variant (usually the "2" package). Why? The other drivers will work OK, but come with fewer features, and on a 64 bit system the most important feature is that the "2" variant comes with 32-bit OpenGL compatibility libraries, while the other drivers do not. If you are like me and use WINE with games, the 32-bit compatibility libraries are a must-have or you won't be playing games. So, find the latest driver version & variant you want, and download the file to a safe place

Getting the driver installed

This is where the rubber meets the road.

• First, make sure the driver file is chmod'ed to be executable (for example): chmod 755 ./NVIDIA-Linux-x86_64-180.41-pkg2.run


• Next, we need to turn off the X-server and drop to a VT terminal command line. The drivers will not install if you try running from an X-term like Konsole, sorry. First, save any open files and logout to the KDM screen. Next, CTRL-ALT-F1 to the first VT (any one will do if you want to use another one). Finally, turning off X: sudo /etc/init.d/kdm stop Under normal situations this will kill X, but in case you have some straggling processes you may have to sudo pkill X manually.


• Finally: Run the package you downloaded as root: sudo ./NVIDIA-Linux-x86_64-180.41-pkg2.run The installer will walk you through the installation. When it prompts you to ftp down a kernel interface just say "no", otherwise it will (unsuccessfully) try to download an interface that takes some extra time. When it prompts you to compile a kernel module, make sure to say "yes" (this is why we installed the header files earlier). Finally, at the end the driver will ask to generate an xorg.conf file. The very first time you install the Nvidia driver, say YES since this file will be properly tweaked to use Nvidia's proprietary drivers instead of the open-source nv driver that you have likely been using already. On subsequent installations, you will generally not have to repeat this step and can safely say "no".


• At last! The only thing left to do is to restart X and see if it all worked. As an experiment, you can try sudo modprobe nvidia to make sure the module loads, although the module will auto-load when you restart the X server as well. Just type: sudo /etc/init.d/kdm start and the X desktop should reload with your shiny-new driver!
  

A few more caveats

There can still be the occasional hiccup, but the above process is how I've been updating Nvidia drivers for some time. Remember that the NVidia package comes with both a kernel driver, AND with user-level drivers that interface with x.org. So, sometimes (particularly when an Ubuntu distro is still in alpha/beta and is being updated frequently) the xorg server is upgraded in a way that whomps the Nvidia user-level drivers. You'll know it when it happens since Xorg will not come up cleanly and may either crash or put you into a 2D-only desktop. If this happens, just drop to a standard console VT, kill kdm/gdm if they are still running, and re-install the Nvidia drivers just as we did above. The Nvidia installer may warn you that drivers are already installed... just continue and let the drivers be re-installed to clean up any problems that the previous update caused. Once the distro becomes stable, these updates are very rare and should not be a big problem.

Conclusion

Well that's it! I hope this helps. As a KDE 4.2 user I've had to be on the cutting-edge of Nvidia drivers in order to get smooth graphics, and with the current drivers the problems of the past have been pretty much eliminated. I'm enjoying a very smooth, composited desktop with my 8800GT. If you have other issues with drivers, please leave a comment and I'll see what I can do.

KDE 4.2: I'm tired of Pundits, Here's MY Take

So I am writing this rant on the eve of the release of KDE 4.2, and in the face of interviews from Linus Torvalds stating that he abandoned KDE after the 4.0 release, and partially in response to Steven Vaugh-Nichols negatively equating 4.2 to Windows 7. My bottom line: I've been using KDE since around the time version 2 came out, and while KDE 4.2 is not perfection, it is better than the 3.5 series, and as of right now 4.2 is easily my favorite Linux desktop... and this rant will address some complaints I've seen and to dissect which complaints are warranted and which are not.

Before going any further, some nomenclature for those who have never dealt with KDE 4.2, please skip this paragraph if you are well versed in the KDE 4 series. The biggest new interface component of KDE 4 is the plasma display engine, and the new "plasmoids" that now compose the KDE 4 desktop. Everything you see on your desktop that is not a normal running program is a plasmoid. This includes the menu bar, the application launchers, the task bar, as well as anything occupying the background of the KDE desktop. For those familiar with Mac OS X widgets, plasmoids that exist on the desktop may serve the same purpose as OS X widgets (for example, see the weather plasmoids above). However, plasmoids go way beyond just widgets to encompass all the elements you interact with on a desktop other than actual windowed programs. Want to add a quicklauncher to the menu bar? That's a plasmoid. Want to run a program via alt+F2? Another plasmoid used to run programs. Plasma has replaced kicker, kmenu, superkaramba, and Kdesktop, but it has born the brunt of criticism about how KDE 4 is inferior to 3.5.

Let's see a picture of my KDE 4.2 RC 1 desktop that is running on Kubuntu 8.10 to give a baseline of what my desktop looks like:

The Usual Suspects

In rapid fire succession, here are the typical complaints I've seen trotted out against KDE 4. Some were never actually true, some were true in the early days of 4.0 but are no longer true today:

• There are no icons on the Desktop!!
  

  It is true that in most configurations KDE 4 does not put icons directly onto the desktop. However, even since the first betas of 4.0 came out it has been possible to do the exact same thing... simply put a folder view plasmoid onto the desktop, and resize it to take up all the space on the desktop, and BAM, icons on the desktop. In fact, this plasmoid is included in the default KDE 4.2 configuration, so you don't even have to do any work to activate it. As you can see in the picture above, I have icons on my desktop... along with a bunch of other useful stuff, which I'll address below.

  
  

  Vaughn-Nichols mentioned that he had to right-click in order to add icons to his desktop... I'm not sure what he meant by that. The folder view allows one to add a new file or folder via right-click menus, but I opened up Dolphin and did a drag & drop of an existing file just fine without any right-clicks... which makes me wonder a bit about what Mr. Vaughn-Nichols was doing with his desktop.




• The Cashew Haunts My Waking Nightmares!
  

  "The Cashew" is at the top-right of the screen by default, and serves as an access point for configuring plasmoids. If you really hate the cashew THAT much... there's a plasmoid that will get rid of it. I admit that I'm not convinced The Cashew is the optimal way to access plasmoid configuration, but at the same time it is pretty innocuous. If you move or maximize a desktop window, The Cashew will be covered over by it and life continues on as normal. I think The Cashew is symptomatic of some users who perceive any change as the apocalypse instead of realizing that while The Cashew might not be your favorite nut, it won't give you food poisoning.

  
  
  
  
  





• You can't hide the menu bar!
  

  True in the earlier releases of KDE 4, but as of 4.2 you can both set the menu bar to autohide, AND you can resize it to be thicker or thinner than the default. I personally thinned my taskbar out, but kept it visible on my desktop, but the option is there to hide it completely. See screenshots below:

  
  
  
  
  
  

  Hell, if you want to, you can COMPLETELY REMOVE the panel (the taskbar is simply one plasmoid sitting on that panel). The flexibility of plasmoids allows you to move the plasmoids that traditionally sit on the panel, and put them out on the desktop itself! KDE 4 allows for customization in ways that other Linux environments do not even imagine.

  
  
  
  
  



• The default window decorations are UGLY!
  

  While this is an aesthetic judgment, I actually agree with this complaint. So why is it in the section of invalid criticisms? Because you have plenty of choices when it comes to window decorations! For those of you who miss KDE 3, guess what: the Plastik theme is still there so you can get some KDE 3 look & feel back right away. For a more adventurous look I recommend Bespin (named after Lando's pad) which has a smooth look and a plethora of configuration options. If you think KDE's themes are bloated, there is the Skulpture theme that is very minimalistic, can be configured to use very little screen real estate, and is my personal choice for KDE on my laptop. Below is a screenshot of Konqueror doing file browsing with Bespin: (Note the tree view: yes, another complaint knocked out because there IS tree-view file browsing in KDE 4!!)
  

  
  
  

  If you want to argue that the defaults in KDE should be better chosen, be my guest, although there will be plenty of people who disagree with my choices too. The exact same argument can be made about 3.5 so don't hold it against the 4.X series. The bottom line is that KDE 4 can be made to look the way YOU want it to. I haven't even gotten into the plasma themes which give you a great deal of choice in how your plasmoids and taskbar appear. I a using the "Naked" theme because it is very clean & minimalistic in appearance (see desktop screenshot above).

  
  



• The compositing is slow & bloated! It isn't Compiz!!
  

  OK, this is subjective, but the compositing is smooth enough for me even on the crappy Intel x4500 integrated graphics on my laptop... not as smooth as I'd like, but definitely useable. I can say from my experiences with Compiz + XFCE on the exact same notebook that Kwin is the smoother of the two. If you think compositing is useless bloat... turn it off (easy: ALT+F12 if you don't like using the GUI configuration). For all of you about to complain about Nvidia + KDE 4: Get an updated driver, preferably one in the 180 series like 180.22, the bugs with plasma and Nvidia cards have largely been solved. I know because the desktop I'm writing this from has an 8800GT and is extremely smooth & stable.

  
  
  

  For all of you addicted to compiz bling, well: kwin4 does NOT have all the "features" of compiz, although it has the ones I personally care about most like the desktop wall for managing virtual desktops (yes the cube and even a sphere are options too). The scale plugins for Mac OS X expose-like functions also work fine. If that is STILL not enough for you guess what... KDE 4 allows you to use compiz instead of Kwin (although I don't guarantee everything being bug free) Just go to: System Settings -> Default Applications -> Window Manager. Personally I think Kwin is better because it is smoothly integrated with KDE, and is actually quite fast at doing a few things right instead of being obsessed with bling, but the choice is yours.

  
  
  
  
  

• Application X is broken!!!

  Everybody is a little bit different, but I'll go through some major applications at this stage. Konqueror is probably better in 4.2 that it is in the 3.5 series, both as a web browser and as a file manager. The KIO components still exist, I personally love using the sftp:// component which is fully operational, as is browsing of samba shares, and regular file management. Konqueror as a web browser will REALLY move forward in KDE 4.3 as the Webkit integration in Qt 4.5 will make for a major improvement... but then again, I've used Firefox in both KDE 3 and KDE 4 as my primary browser anyway. Konsole is working fine with the only features I'd like to see reintroduced being the "send input of this terminal to all terminals" option, but that's not an absolute must-have. Amarok: The betas for 2.0 were not so great, but I will say that 2.0.1 is both stable and has the core features I need to manage my music... having said that extra work on equalizers and bling plugins is still to come. Koffice: Well, I hate to say this but I didn't use Koffice with KDE 3, but I've heard the next version of Koffice is in the late-beta stage right now and is apparently shaping up well. The biggest "missing-link" right now is definitely K3B which is still currently a KDE 3 app right now (although they are developing the next major release for KDE 4).

  
  

  Of course, just because you are running a KDE 4 desktop this does NOT mean you can no longer run KDE3 applications... in fact as proof I have a screen shot of K3B running on my KDE 4 desktop for all of you who might not believe. Additionally, KDE 4 can be configured to use Firefox as the default web browser, so the RSS plasmoid you see on my desktop will open up a new tab in Firefox when I click on a story... KDE 4.2 is playing nice with non-KDE 4 applications!

  
  
  


• I HATE THE NEW LAUNCHER THINGAMAJIGGY!
  

  OK THEN CHANGE IT! Sorry for yelling, but seriously. Look, I'm more of a power user, I either put commonly used programs in the quicklaunch plasmoid on the dock (see my screenshot above at the lower left) or I just use the ALT+F2 combo to run a program (BTW the krunner in KDE 4 is badass and gives quicksilver a run for its money, try it out!) However, I will concede that the new "K" program launcher is different and this may cause consternation to some users. Well guess what... there are two alternative program launchers for you to choose from. First, is the "traditional" launcher that keeps the same app structure from KDE 3.5, and the other is the Lancelot launcher that many people are very positive on (Lancelot may become the default in future releases). The bottom line is this: If you don't want to take the 5 minutes it takes to learn a new launcher, you can restore the functionality of the old one. You ARE missing out on the new advanced search features that make using the new launcher much easier, but don't accuse the KDE 4 developers of depriving you of your old techniques either.

  
  
  
  



• You can't configure anything anymore!

  Uh... see above for all different choices you have in configuring KDE. If anything, the old complaint about KDE having too many configuration options is still true in KDE 4.2, although that is one reason I've always liked KDE. As you've seen from my screenshots, my KDE desktop ain't looking like a fresh outta da box KDE 4 install your distro will give you by a long shot... and that's (mostly) due to me configuring it using the standard KDE System Settings panel.

  
  

  Here's a quick fire list of things you can still do even if some anonymous poster said you couldn't:
  

  
  
  • Configure window behavior (focus on click, focus follows mouse, auto raise, etc.)
  
  
  • Configure background wallpaper (duh.. but if you are adventurous you can manually configure per-desktop wallpaper, a feature that will be fully supported in 4.3)
  
  
  • Configure keyboard shortcuts for applications & for the desktop in general. I use it to tweak keyboard shortcuts for compositing functions
  
  
  • Install fonts easily & tweak all the fonts on your desktop
  
  
  • Use a special style to make GTK apps blend in better with the rest of the desktop
  
  
  • Install new color themes, and have minutely detailed configuration options to change widget colors to your own liking. (I personally stick with the preconfigured themes)
  
  
  • Adjust the default applications that will open given file types. For those of you who passionately hate Dolphin: You can set Konqueror as the default file browser too! I will give Dolphin credit as an app that has vastly improved since 4.0, but I still prefer Konqueror for heavy-duty work.
  
  
  • Notifications: The "feature" here is that you can turn off the bouncy icons & other annoyances... KDE 3 == KDE 4 in that respect.
  
  
  • Ripping from audio CDs: the kio slave for that works too, although MP3 support is still an option (just like it was in KDE 3, no better no worse)
    
    
  
  
  • LOTS of other stuff... if you think you can't configure it in KDE 4.2, please post how you would configure it in 3.5 below and I'll try to figure out if the option is actually missing from 4.2, or if it is just done in a slightly different way.
  
  
  
  

OK so there are features.. how is it BETTER than KDE 3.5?

Vaughn-Nichols seems to think that all the new features in KDE 4.2 are getting in the way of actually getting work done. I could not disagree more with this assessment, both because KDE 4.2 is still using the basic KDE paradigms, but also because it adds new & better ways to access information. The following is an incomplete list of ways that KDE 4.2 actually makes it easier to get work done.

First, the plasmoids I have configured give me quick and condensed information at a glance that would require much more work to achieve via a normal web browser or file browser interface. The fact that plasmoids are now first-class citizens in KDE 4 means that they will gain much more functionality than what superkaramba applets ever had in 3.5. Secondly, the "bling" of kwin's composite puts every window on my desktop a mere keystroke away at any time, much faster than even the ALT+TAB switching of older KDE versions. Third is the new krun interface. As a power user, I find krunner's powerful search & complete options to be a big improvement over KDE 3.5. However, krunner does not stop there, it can act as a simple calculator, unit converter, and spell checker as well. Fourth, the data indexing and semantic services Nepomuk and PIM database Akonadi are just now starting to come into their own as powerful tools that make it easy to search both the desktop and web for information. These data engines are integrated into KDE 4 in ways that are much more organic than any search options for 3.5. Finally, KDE4's newer applications like Okular and Gwenview are excellent programs for dealing with PDF files and viewing raster and SVG images. The new and improved KDE4 and Qt4 frameworks are just now being exploited to provide new and exciting software applications that improve productivity beyond what KDE 3.5 could offer.

So what are MY complaints about KDE 4.2?

I like KDE 4.2 a lot, but like anything else, there's room for improvement, and I'm not afraid
to point out where there is an actual need to improve things.

First, I'd like to see some third-party code integrated into the more "official" releases of KDE. I know that some of this work is actually the responsibility of the distro and that after KDE 4.2 is out the distros can smooth this process, but here are a few suggestions. First, my favorite plasmoid of all time is the Yet Another Weather Plasmoid which does an excellent job of showing weather predictions, including smooth-scaling radar maps. I'd like to see the main KDE developers show more interest in including popular third-party plasmoids into the main distribution. The Bespin & Skulpture themes could also be brought into the main tree as well. This would also encourage more third-party activity, as it would be a great way to gain some fame by getting your plasmoid into the official KDE build tree. Additionally, good plasmoids would make for great Google Summer of Code projects assuming Google doshes out the cash this year.

Second, yeah: KDE 4.2 still has bugs (but then so does GNOME, XFCE, KDE 3.5, etc. etc.). The system tray needs some work. It is functional, but the icons don't scale & refresh properly as of RC 1. This is mostly polish, but needs to be done. Amarok 2 is not bug free, but at least it doesn't crash on me in normal operation, keep at it! Finally, things are relatively smooth, but can be made faster. My personal vote is for making Konsole as fast to display & scroll as an old-school xterm is, which would be a great way to show off how a KDE environment does not have to be "bloated".

Third: There are still some things to get ported to KDE 4. Aside from K3B mentioned above, the big one for laptop users is the network manager applet. THe KDE 3 version does work (I'm using it now) but my wireless will be much happier with a proper KDE 4 network plasmoid. Fortunately, work is already underway on a KDE 4 plasmoid that will deliver this needed functionality.

Fourth: Artwork! KDE 4.2 has a surprising number of themes already, but more wallpapers, color schemes, and artwork are always welcome. High resolution wallpapers at 1920x1200 or 2560x1600 would help, as would nice SVG wallpapers. Slick looking SVG icons don't hurt either!

Finally, the whole issue of what went wrong with the earlier releases of KDE 4 needs to be put to rest... everybody involved deserves a little blame. Was KDE 4.0 ready for general consumption? Clearly no. The developers did try to warn us that 4.0 was really only in place to provide infrastructure to get application developers to migrate over, but no disclaimer is going to stop the lemmings from being attracted to a nice round number. The distros are also partially to blame in that some of them pushed KDE 4 way too early, and made the problem worse by dumping 3.5 too quickly (WHY can't you have a .kde3 and .kde4 directory coexisting??!?!). Finally, the users themselves are partially to blame. We got used to a very mature platform in 3.5, and expected a major re-write to be feature complete and bug free almost immediately. Instead of properly filing bug reports and feature requests (or even trying to help out with actual code) far too many users started venting about how KDE 4 was a "disaster" and that KDE was dying etc. etc. None of this was helping the actual developers to improve KDE 4 any faster.

To all You Playa Haters Out There

First of all, to all you Gnome guys: I got nuthin' but love for ya. If you hated what KDE was before KDE 4 came out, I'm not on some religious mission to convert you. However, I hope this rant and attached screenshots did help to dispel some of the things you may have heard second-hand about what a "disaster" KDE 4 is. Just remember that the talk about what will go into Gnome 3.0 is bordering on the same level as what KDE 4 has already gone through. As Aaron Seigo pointed out in his blog, there was pain, but in my not so humble opinion, I think the pain of creating KDE 4 is already starting to pay dividends and that KDE 4's development is ready for rapid expansion. If the Gnome team is prepared to endure what the KDE devs have, they can make some big improvements to Gnome too. Also, I did note that the KDE 4 dev process has not been flawless, and the Gnome devs can learn from what the KDE guys have been through too. After all, we're just one big happy family bound together by D-Bus interfaces right?

Now on to the rest of you who either jumped on KDE 4 too early without having the right expectations, are trying out Beta KDE 4.2 builds right now with an expectation that everything will be just like 3.5, or haven't even tried KDE 4.2 at all but have "heard it on the street" that KDE 4 was hopelessly broken. KDE 4.2 is not "broken" and has reached a state where it is a solid replacement for KDE 3.5 for me at least. If you are not as adventurous as I am, then PLEASE do not use KDE 4.2 before it has been officially added to your distro of choice. For example, even though my version is from Kubuntu's repositories, the support is not 100% and that could be the source of some bugs that might not even be KDE's fault.

Finally, some people REALLY hate change. Oh they say they love change, they wear "Change We Can Believe In" buttons, but deep down they don't want to have to change their ways. To you guys, especially the ones who constantly post useless flames about KDE 4, I say: put up or shut up. I've been using computers since I had a Trash-80 back when I was a kid. I remember screwing with my autoexec.bat and config.sys files to squeeze out extra low memory in DOS, and I started in with Linux in 2000 right when the 2.4 kernel & KDE 2.0 were both bleeding edge... so get off my lawn!! No seriously, the point is that things change, and as I've pointed out above, many things have seriously changed for the better in KDE 4.2. If you don't want to learn something new that's great, but you lose your right to complain when people with more vision than you see that the old ways are not cutting it anymore and that change is necessary. This is doubly true in the world of FOSS. I've seen plenty of ignorant forum posters bitch about "forking" KDE 3.5 based on Qt4, but I haven't seen a single line of new code. In the meantime, I've seen the KDE 4 devs bring KDE 4 from a toy project to a desktop that I'm happy to use fulltime. Was it always pretty? No. Is it perfect right now? No. BUT: KDE 3.5 wasn't perfect either, and it took both bravery and perseverance to get KDE 4.2 to where it is today.

For those who say that they cannot deal with a new desktop, get over yourselves. KDE 4 is not really that radically different in the big picture. I mean, you run programs on a desktop! Sure things are being done a little differently than KDE 3.5, but get a grip for a second, the KDE 4 series is definitely still KDE at its core. It is not rocket science to learn KDE 4.2 if you really knew what you were doing in 3.5, and the payoff will be a very refined desktop that is both visually pleasing as well as very functional.

So as of today I say: Viva la KDE! I think 4.2 is a major milestone, and I'm already looking forward to screwing around with the 4.3 betas in a few months. The real innovators in FOSS software are not making stupid rants like this one, but are making SVN and git commits even as I type this. To them I say thank you, and only listen to the critics if they file properly documented bug reports!