Archive for September, 2008

Linux sucks – Directory/Folder Pickers

Thursday, September 4th, 2008

One of the frustrations I’ve run into while using Linux has been with saving screenshots.  At first glance, the interface is much better than Windows’, because pressing the Print Screen key brings up a dialog that lets you save your screenshot to a file easily:

The GNOME Screenshot application

The GNOME Screenshot application

At this point, you’re much better off that you’d be on Windows (which either requires extra steps, or requires you to install 3rd-party applications).  However, you’re also a lot worse off than you realize.  This screenshot application sucks!

  1. When picking which folder to save a screenshot in, you’re presented with a list of directories – your “Places” (Home directory, Desktop, USB sticks, etc) and the directory you most recently saved to (in the example below, “filepicker”).  This looks good until you realize you might have multiple directories called “filepicker” and have no way of telling which one you’re looking at.  “filepicker” is reasonably unique, but I have multiple directories named “tmp” (/tmp, /var/www/tmp, /home/chris/tmp) and I usually dump a screenshot into one of these directories until I have a chance to edit it (e.g crop it in an image editing application). There is no way to tell what directory you’re really saving to.

    The GNOME Screenshot application; list of directories

    The GNOME Screenshot application: list of directories to save pictures in

  2. It gets worse.  If you choose “Other…” you’re presented with a directory picker:
    The GNOME Screenshot application: directory chooser

    The GNOME Screenshot application: directory chooser

    This doesn’t look too bad until you try using it.  In this screenshot, it looks like pressing “Open” would save the screenshot to /tmp/guest/tmp: note the “Location” bar and the highlighted item.  Despite this, it actually would save to /tmp/guest.  The “Location” bar just exists to trick you.  If, given the situation in the picture above, I typed a path into it (e.g. /home/guest/Desktop/tmp) and pressed Enter, the screenshot would still be saved to /tmp/guest!  This dialog lies to you if you type a path manually, and lies to you if you select a directory and choose “Open”. The only way to get it to do what you want is to actually navigate into the directory you want to use, then press “Open” (and ignore any text in the “Location” bar and any selected directories in the list).

  3. It still gets worse.  If, after navigating to the right folder, you try to type a filename into the “Location” bar (e.g. Picture.png), it creates a directory (in this case, it would create a directory called “Picture.png”) and uses that directory to save the screenshot.  You still have to type the filename when you’re back to the main Screenshot application window.
  4. It gets even worse.  If you want to save time and just type a full path into the “Name” field on the main screen, it appears to work, but doesn’t actually save the screenshot!  It fails silently!

This is some of the worst usability I’ve ever seen.  There are plenty of applications that aren’t very intuitive and are hard to use, but the deception here is in a league of its own.  I created a brief video that highlights some of these issues – you can watch it after the jump.


Linux sucks – Binary Compatibility

Tuesday, September 2nd, 2008

Using Linux in the real world can be exceedingly frustrating if your employer allows VPN access (or you use VMware).  Every time your kernel is updated, you have to recompile the Cisco VPN modules; frequently, kernel updates consist entirely of changes that are irrelevant to any given installation.  Occasionally they don’t actually change anything (“no-change rebuild“) but for some reason Ubuntu still needs to update.

Linux isn’t like Windows either.  On Windows, if you need to update a driver, you update that driver.  On Linux, if you need to update a driver, you usually* have to update your whole kernel (unless you want to play risky games with back-porting, which isn’t realistic anyway unless you’re a developer or know one).  My point here is that you’re going to be updating your kernel more frequently than someone coming from Windows might expect, so any consequences of kernel updates are magnified.

*The exception to this is a driver for esoteric or new hardware that hasn’t become part of the kernel yet; in those situations you usually have to use a manual process to update and recompile the driver.  Of course, you also get to recompile these drivers when you update your kernel.

It gets worse – not only do you frequently have to recompile the Cisco VPN module, but sometimes it breaks entirely.  When a kernel API used by the VPN module changes, you have to hack the VPN module’s code to get it working again (usually this involves extensive googling to find a patch someone else has already written).  Sometimes you just have to wait for Cisco to release updated software that supports the new kernel release.  This is really obnoxious.  Is it Ciscos’ fault?  Sure.  Is it a problem under other operating systems?  No.  Is putting some of the blame on Linux reasonable?  Yes.

Some might suggest not using VPN (a ridiculous solution that precludes working remotely) or using different VPN software, but if the IT support staff you deal with only supports Cisco VPN, those aren’t good options.

It occurred to me that I could work around this problem by running the VPN client with in a VMware virtual machine – and use a specific kernel release inside the virtual machine.  This almost works, but unfortunately VMware has its own kernel modules which also need to be recompiled when the kernel is updated.  Just to add to the fun, if you try to launch VMware Player after updating your kernel, it fails silently!  The only way to tell what went wrong is to launch it from a text console, in which case it tells you to rerun the setup scripts (which recompile the modules for you).

The whole philosophy that everything should be GPL-licensed and included in the kernel doesn’t acknowledge the real world.  Some companies do write proprietary software, and having a real job in the real world sometimes means using that proprietary software.

(I’m not even going to get started on the glibc version incompatibility issues… maybe in a future post).

Linux sucks – Keyboard Shortcuts

Monday, September 1st, 2008

The default keyboard shortcuts in Linux suck*. The shortcut for locking the screen is ctrl+alt+L, which sounds reasonable until you load up emacs and try to use the “previous buffer” shortcut (which happens to be ctrl+alt+L). There are other shortcuts that use ctrl+alt+[letter] too.  All of these shortcuts should use the “Windows” key by default.  It’s been years since I’ve seen a keyboard that didn’t have a Windows key, and on Windows many shortcuts do use the Windows key.  It also seems pretty stupid that the Windows key doesn’t bring up my Applications menu by default.

You’d think the solution would be simple: System->Preferences->Keyboard Shortcuts, but you’d be wrong.  The Windows key can’t be treated as a modifier key – you can’t set a shortcut to be “Super+L” (the Windows key is called Super for some reason).  If you try to set a shortcut to e.g. the Windows key and D, you’ll just end up with just the Windows key as your shortcut.  I’ve found that for Compiz shortcuts, the Windows key is correctly treated as a modifier, but all the GNOME stuff (in particular, locking the screen) treats it incorrectly.

Punishing users because you don’t like a logo sucks.

*in this particular case, my complaint may very be specific to Ubuntu + GNOME, but see my statement in my original post explaining why I still blame “Linux”