Let your tools inspire you: Editor elitism, bias, and myths that keep you from thinking outside the box.

In order to frame and set the context for the rest of the post, I’m going to start off with one of my favorite XKCD comics:

Why do those nerds care so much about the editor?

Having a good toolbox and being skilled with your tools is just as important to a developer as it is to a carpenter. Imagine trying to build a house, but you only had a rock for hammering your nails in. You’d be slower, more prone to mistakes, turn out lower-quality work, and probably frustrate the hell out of yourself in the process. For those of you out there who don’t code, the connection may not be intuitive, but for anyone who has spent thousands of hours composing and manipulating code, the thought of using something like Windows Notepad for any serious work is painful.

Ask anyone who’s been coding for a long time what they use and why, and I can almost guarantee you’ll get a well-reasoned, thought-out, and probably passionate answer. If the editor they use is either Emacs or Vi(m), you’ll probably experience something close to religious enthusiasm (and a possible conversion attempt).

There is a duality to the process of writing code. Almost always rigorous and mathematical, it is at the same time a personal artistic expression of the person writing it. Bad code is ugly and inefficient. Good code is like prose to those who understand the language; A beautiful expression of creativity and genius.

That being said, there is a lot of tedium and repetition in the process of coding. Any time you’re mechanically repeating a mindless action, you’re taking up time that you could be coding, understanding existing code, or brainstorming about the code. A good editor is needed so that it is easier for you to get the mechanical stuff out of the way, and get back to thinking and composing.

From humble beginnings: A little history about myself.

When I very first started programming, it was teaching myself GW-BASIC on a 1982 IBM PCjr. Development took place inside the GW-BASIC command line-based development environment, and was probably the furthest thing from an efficient editor. Lines of code had to be prefixed with a line number, otherwise the interpreter assumed that it was a direct command that should be executed immediately. This caused enormous difficulty when trying to insert new lines of code between existing lines. The convention was–as far as I could gather by reading existing programs written in GW-BASIC–that lines would increment by 10. This way, if you decided later to go back and insert a new line, you would give it some increment between the two existing line numbers. Viewing existing lines of code was done through the “LIST” command. There may have been better ways to optimize your workflow, and better tools to use, but this was back before the days of common household internet, Google, and Stack Overflow. I was a kid in his basement with nothing but existing code samples and a whole lot of free time on his hands.

Web design, WYSIWYG, and Dreamweaver, oh my!

In my teens, I became intrigued with web design, and started learning websites through the not-really-programming approach of Adobe Dreamweaver. This was good enough to get some rudimentary sites going, and since the big thing of the day was Yahoo GeoCities, there wasn’t much competition in the aesthetics department. However, I quickly ran into situations where I was bumping up against the limitations of the WYSIWYG editor. Whether it was adding advanced functionality to the visual layout I had, or trying to peek under the hood to figure out why something wasn’t working, I found myself more and more in the source code, rather than the visual pane. I began to notice that the code was always more complex than it had to be, and it wasn’t very nice-looking either. For a while I used the source code pane of Dreamweaver to write and edit code.

The need for a “real” editor.

Then I discovered Notepad++. This was the first time I had been wowed by an editor. It was lightweight, simple to understand and learn, but packed with powerful features in the dropdown menus. I learned of the amazing utility of macros, automatic source code re-indenting, and plugins. I used Notepad++ (and Gedit, when on an Ubuntu machine) as I taught myself Perl, HTML, CSS, Javascript, and PHP, and would continue to use it until and for the first year or so of formally studying Computer Science.

Completely unfamiliar territory: Discovering Emacs.

When I began the Computer Science program at the University of Virginia, I was quickly introduced to IDEs, and fell in love with how capable they were. Code-completion, function lookups, easy management of the file tree–the list of features went on and on. The IDE did so much for you! Click a button, and just like magic, your application is built and ready! I wondered why anyone would prefer not to use an IDE. As I progressed to the more difficult CS classes, I was required to become familiar with the terminal, building manually using tools like Make, and (for at least one class) was required to use Emacs. The professor even asked us questions on the test about how to do things in Emacs, just to make sure we were actually using it!

Oh, how I hated Emacs for the first few months. It was the most confusing editor I had ever used. What was up with those key bindings? None of the shortcut keys were what I was used to… Alt-w to copy? Ctrl-y to paste? How the heck do I exit this stupid program?? Well, thankfully I was forced to use it for a few months for that class, because I wouldn’t have made it even one day with Emacs on my own.

The summer following the semester in which I was forced to use Emacs was a transformative time for me, with regards to coding. I began doing GPGPU research with a professor at UVa, and began taking my coding (both professionally as well as hobby-based) a lot more seriously. I began doing a lot with CUDA and OpenCL, and doing development on remote Ubuntu boxes. This meant I spend a lot of time working over SSH. By now, I had used Emacs enough in class to be decently familiar with it, and the ability to use it in the terminal after I had SSHed into a box gave it a lot more value. I started using it almost exclusively at this point, and that began a journey of extreme attachment and customization.

Anyone who’s used Emacs for any significant length of time can tell you about the .emacs file, and they probably have a large set of personal customizations to it. For me, this was one of the best parts about the editor. Once I got the basic built-in behavior down, I discovered that Emacs was an editor that would evolve along with you. If I found myself missing or desiring a particular piece of functionality, a quick trip to the .emacs file, along with a few lines of elisp, and I was on my way. At this point, I was a die-hard emacs fan.

Doing it all over again with Vim.

It wasn’t until November 2011 that I became curious enough about Vim to give it a try. I ended up trying and dropping Vim about 8 or 9 times out of frustration before it finally stuck. Once I got over the hump of learning the concept of modal editing (in addition to key bindings that were, once again, completely different from anything I had ever used), I was actually able to become very productive in the editor. I discovered all kinds of amazing features. One of my favorites to this day is the “change inside” feature. I’ll leave it to you to learn about this, but do a Google search for “Vim change inside parentheses” (or do the fantastic and well-done Vim tutorial, built in to the editor) if you want to learn about it. Vim, like Emacs, was a highly-extensible, customizable editor that would grow and evolve with the programmer. At this point, I’ve added so many helpful bindings, settings, and functions to my .vimrc file (similar to the .emacs file) that have taken Vim from a fantastic editor, to my own custom and personalized tool. It has become something I don’t even think about when I use it, which allows me to focus on the task, and not the tool.

Back to the Future with Sublime Text 2

It sounds like I’m pretty happy with Vim at this point, so why the step back in time to the days of a gui-based editor and try Sublime Text 2? To be honest, I was suffering from a bit of mouse envy at this point, seeing one of the guys on our iOS team at work move so proficiently about his code. I was starting to wonder why I was still mired in the days of a 30-year old text editor when so many modern alternatives were just waiting to be used. Plus, I was fairly enamored with the beautiful ST2 interface (the Monokai theme is one of my favorite themes to date, for any editor). I decided to give it a shot, just to see what it was like, and immediately discovered how useful the features were. The “go to anything” functionality was fantastic, as was project-wide search-in-files. It was fast and accurate, and made it incredibly easy to jump around massive code bases. Furthermore, the multiple cursors functionality was incredible. Far from being a gimmick, it was much more useful than I had initially thought it would be. The fact that each of the cursors has its own copy/paste buffer was a mind-blowingly awesome discovery. The minimap (a 30,000-foot view of your code) is a great way to get a visual overview of the “shape” of your code, something that is especially helpful for orienting yourself and getting a feel for where things are in larger source files:

Sublime Text 2 in action

As a backend developer who spends most of his time working either on remote servers, or remoting into a headless VirtualBox instance (via the fantastic and wonderful Vagrant), Sublime Text 2 posed some challenges at first. Then I discovered the SFTP plugin for Sublime Text 2. This allowed me to ssh into a box, navigate around, and then edit a file. The SFTP plugin would bring a temporary working copy of the remote file to my local machine, and then upload it back to the remote box any time I saved it. This happened seamlessly behind the scenes, allowing the user to interact with the file as though they were working entirely on their local machine. The folder mirroring feature worked in a similar manner, mirroring an entire project tree to your local machine. You could then use “go to anything” or find-in-files within the project tree. With the right options enabled, ST2 would ensure that you had the most recent copy from the remote box each time you opened the file on your local machine, and would then upload any changes in your mirrored folder to the remote box as they were saved.

Why I came back to Vim.

Vim in the terminal!

As good as Sublime Text 2 is, I didn’t stay with it. Oh, sure, I went back and forth, much like I did when switching to Vim. I even thought for a while that I had moved to ST2 for good. In the end, though, I came back to Vim. Here’s why.

  • I value my pinky. On OSX, my OS of choice, Sublime Text 2 benefits from the basic Emacs movement bindings that are built into the operating system. (Side note: This was one of the downsides to using Sublime Text 2 on Windows–no Emacs bindings. I know I can install the sublemacspro package in Package Control, but it’s not the same as using Sublime Text 2 on OSX.) Although I’m very fluent with this binding, it results in me holding down the control key for a large portion of the time I’m using the editor. I even have my control key swapped, which helps immensely. There’s just no way around having to hold down control, no matter where you swap it. Some people prefer the Emacs-style key chords as opposed to modal editing (and I did too, for a while), and that’s fine. Personally, I like the modal editing method.
  • Getting around the text is precise. This is where Vim excels. Emacs is a do-everything tool, and a damn good one, at that. It excels at being not only extensible, but having just about every feature you could need (and many that you don’t even realize you need yet) all wrapped up into one package. For me, however, I spend most of my time interacting with, and composing text, and this is where I like my editor to excel.
  • While working on remote files with an editor on your local machine is cool (and Sublime Text 2 with the SFTP plugin is the best workflow I have experienced doing so), I need to interact very frequently with the command line. Emacs gives me this option with the ability to open an embedded terminal, but my preferred method is to open a tmux session on the remote machine. With nested windows and split panes, tmux becomes something of an IDE. It has the additional bonus of allowing me to detach, move to another computer, and reattach, picking up exactly where I left off.
  • Vim (and Emacs, for that matter) doesn’t have a notion of a “Super” key (Windows logo key, or Command key on a Mac). I thought that, since Sublime Text 2 was available on Linux/OSX/Windows, that I could invest in this editor wholeheartedly (like I did with Emacs and Vim), and have a portable and coherent coding experience when I jumped between platforms. What I didn’t realize until trying to use Sublime Text 2 on Windows instead of my usual OSX was how much I had the Command+[some key] shortcuts ingrained in me. A vast majority of my experience on Windows was different from the experience on OSX, and this caused my productivity to grind to a halt as my focus shifted from the task at hand, to trying to figure out how to use the tool.
  • High portability of skills. Vim’s motions and key bindings port well to other development environments, like Eclipse and Visual Studio, via the use of plugins. I’ve tried a couple of platforms with various plugins, and have been very pleased with them. While they don’t fully execute every last bit of Vim functionality (some come very close!), the important bits–namely anything to do with moving around and interacting with the code–are easy enough to implement, and are well represented in the various plugins I’ve tried. All this to say, by investing my time in learning Vim, I have a skill set that I can use anywhere that I can find Vim (which is pretty much anywhere) and, should I be required to use another development environment, my skills won’t go to waste due to the ability to bring the Vim control scheme to other platforms.

Inspired by my editor: What using Sublime Text 2 taught me.

While I did spend a fair amount of time learning and switching back and forth from using Sublime Text 2, it certainly was not a waste, by any means. Using Sublime Text 2 introduced me to a number of awesome features that I had not even thought about searching out or trying to implement in Vim. For example, I found the ability to instantly jump to a file in my project directory in Sublime Text 2 incredibly useful, so I wrote the following, and added it to my .vimrc file:

nnoremap <F2> :tabnew <bar> :r!find . \| grep -i ''<left>

This allows you to press F2, type any portion of a file name, and it will open a new buffer with any files matching that search that are within the current working folder, or any nested folder. To make this more sane, I also told Vim to keep whatever directory it was opened from as the working directory, rather than the directory of the file you’re currently editing:

set noautochdir

This is just one example of how I would discover a feature I liked in a different editor, and then look for a way to implement in my editor of choice. I wouldn’t have thought about it if I hadn’t been exposed the feature in Sublime Text 2. The same thing happened when switching to Vim from Emacs; Either by trying to replicate the ability to perform some task in Vim that I was able to do in Emacs, or by discovering a new feature in Vim, and then attempting to see if I could do it in Emacs, I learned a great deal about both editors, and came away more experienced and more knowledgeable. I am not, by a long shot, the most experienced Vim user at my job, but I have had numerous occasions where others have asked if I knew how to do something in Vim. Even though I’ve only used Vim for about a year so far, I still had plenty of experience to offer, thanks to feature exploration and trying to take things I liked from the world of editors at large, and implement it in Vim.

Myths, bias, and other terrible reasons to stick with X.

One surprising hurdle I faced when attempting to switch from Vim to Sublime Text 2 was editor bias. Or maybe it was editor elitism? I felt that going to a GUI-based editor somehow made me less of a hacker, and a less-impressive coder. It sounds incredibly stupid, but somewhere, nestled away in the depths of my psyche was the notion that all real hackers used text-only terminals for everything they do, never touched a mouse, and when they stepped away from their computer for more than a few minutes, they all had matrix screensavers that would cascade cryptic symbols down the three or more monitors they were coding on at all times.

I’m not downplaying the usefulness or legitimacy of the command line in any way. As previously mentioned, I spend almost 100% of my time in the terminal for development. But to have something like “how will others view me”, “will I seem impressive to others”, or “Hollywood does it this way” become metrics for choosing the tool you will use for coding is just plain stupid. If you’re coding so that people will look at you and be impressed, you’re doing it wrong. You shouldn’t be doing it at all. And yet, that mindset was part of what was holding me back from really jumping in and going all out with Sublime Text 2.

Here are some other reasons not to use editor X that really suck:

  • MYTH: You’re always faster when you don’t have to touch the mouse.
    While it’s incredibly productive to be able to perform all of your actions from muscle memory, without having to leave the home row of your keyboard, there is the occasional advantage that using a mouse can provide. Scrolling with the mouse wheel to peruse and learn code is actually quite nice. And when you’re taking a visual overview of your code, it’s quite nice to have the ability to swing the mouse arrow right up to where your eyes are already looking, click an exact spot on an exact line, and begin editing. In addition, dragging a rectangle region of the code with the mouse is wonderful. People may claim that it’s inaccurate and a waste of time to be pointing and and clicking, but I (and anyone who’s ever played in Counter Strike tournaments) will disagree, at least that you can’t be fast or accurate with a mouse. Even though it might be faster to perform a majority of editing actions using the keyboard only, it is by no means a blanket fact that mouse is always slower. If you’re picking an editor simply because it’s cool to not have to touch the mouse, you should probably spend a little more time in thought about which editor is actually right for you.
  • MYTH: Editor X is better because it’s everywhere.
    It can definitely be an advantage to have your editor be available (and even installed by default) on all of the major computing platforms, but it should not be the reason you decide to invest in that editor. While you may not be able to just remote into a server at a moment’s notice and use your editor of choice, that shouldn’t dictate what you use when you actually sit down and spend any serious amount of time in your development environment. If you’re settling in for the long haul on a project, take some time and set up a good dev environment. Set up an SFTP connection in Sublime Text 2 to the machine your code resides on. Install Emacs. Pull down your Vim configuration files on the machine. If you are so restricted that you don’t even have permissions to install on that machine, you should probably set up an intermediate development and testing environment, pushing your code to the restricted server only when necessary. I can’t think of a good reason that you would need to worry about such restrictive constraints for anything other than quick maintenance or on-the-spot fixes and tweaks on someone else’s machine.
  • MYTH: Real programmers use X.
    I’ve already covered this above, but it’s worth reiterating. I’ve seen some of the most brilliant programmers I’ve met use everything from Vim to TextMate. It doesn’t matter what you use, as long as it’s customizable, extensible, and can evolve with you. Don’t try to impress people with your editor, impress them with your work. That goes a lot farther, and people will actually remember you for it.

Summary, and lessons learned.

Don’t just take your editing experience at face value, and write off functionality that doesn’t exist (or that you don’t know exists). Let your experiences inspire you to build and evolve your editor of choice. Just because you should pick one editor and learn the hell out of it (see also) doesn’t mean you have to be satisfied with only what that editor has to offer (and especially not with what you think that editor only offers)! Explore, expand, and make sure you have a powerful, configurable, and extensible editor that will grow with you.


Fixing font smoothing on OSX

While I was experimenting with themes in GNU Emacs for OSX, the font smoothing somehow got messed up for the entire OS. A quick Google search didn’t exactly yield a helpful answer, as they just directed me to the System Preferences, in the “General” section, and told me to make sure that the “LCD font smoothing” box was checked. This didn’t help me because it was already checked, and toggling it didn’t actually make a difference.

What actually ended up fixing it for me was to set font smoothing at the command line. Open up a terminal, and type the following to see if the value is currently set:

defaults -currentHost read -globalDomain AppleFontSmoothing

This command will show the current value, or alert you if there is no value currently set. If you want to delete the value (thereby restoring the default), do the following:

defaults -currentHost delete -globalDomain AppleFontSmoothing

You can set the value with the following command, replacing with level of smoothing:

defaults -currentHost write -globalDomain AppleFontSmoothing -int <value>

0 – No smoothing
1 – Light smoothing
2 – Medium smoothing
3 – Strong smoothing

Getting things done: Practical advice, hard-earned through failing miserably at it.

Determine never to be idle. No person will have occasion to complain of the want of time who never loses any. It is wonderful how much may be done if we are always doing.
    –Thomas Jefferson

For as long as I can remember, I have been a procrastinator. Like most bad habits we have in life, I learned the art of procrastination at an early age, and spent the following years of my life perfecting it. As I entered college, I slowly began to learn that procrastination would end up being the death of any hopes I had of doing well, and I set about trying to change it. Procrastination was a part of my life philosophy, whether or not I realized it, and putting a stop to it is easier said than done.

Change does come, though, with determination and perseverance. I’m certainly not perfect, and I am, by no means, a productivity master, but I have learned a few things the hard way (I’m pretty damn stubborn). Here are some of the things I would do differently if I had to go back.

Pick a method to stay organized.

Having the right method is not the silver bullet to becoming a procrastination-free productivity powerhouse. There is no magic method to take the work and effort out of overcoming laziness or changing bad habits that have been ingrained in you for years. Having a crappy method–or worse, no method at all!–can definitely hamper or even cripple your productivity. The Pomodoro Technique is a great place to start if you’re not sure. See this LifeHacker article for some more ideas.

A key feature that these methods must have is simplicity. It’s hard enough already to accomplish the tasks before you, and you don’t need another layer of complexity or difficulty standing between you and the task at hand. What you need is something that helps you stay focused, and gets out of your way when it’s time to get to work.

Plan your course of action.

This is where some of you can get stuck. Either you don’t know how to plan, or you over plan. This planning process should involve breaking your individual tasks into chunks, spacing those chunks out in reasonable intervals between now and the deadline, and making sure that all of the chunks fit together in your schedule as you do this for all of your tasks. If you can’t think of the steps to take, you don’t know the task/problem well enough to begin with, and you need to familiarize yourself with it. Make sure that you are at least at the point where you understand it well enough to summarize your problem and goal to a stranger in your own words. If you can’t do that, you probably don’t even know enough about it to begin researching an efficient set of steps to take.

You should also make sure to be reasonable and realistic with your schedule. It’s easy to carelessly make assumptions about the task early on, when you have not yet begun the actual work and the pressure of the deadline is far away. Do this step thoughtfully, for you will need to trust and rely on it later! This is the point at which you should be looking at the big picture, at everything you need to do, and how it all fits together.

Sprints, not marathons.

Don’t plan to sit down and do the task in one sitting. Not only is this usually completely unreasonable, but it is almost always the least efficient and most stressful way to do the task. Planning to get anything but a small or trivial task done in one sitting does two things:

  1. It makes the task seem big and scary.
  2. It makes us want to procrastinate doing the task because it seems big and scary.

Breaking a task up into smaller chunks requires more planning and discipline for sure, but it offers lower stress, guaranteed completion on time (assuming you respect, trust, and adhere to your plan), and the habit of starting early.

Trust the plan.

This is where the rubber meets the road. A plan is of no use unless it is obeyed and executed as devised. You already broke the task into chunks in the first step, and spread them out between then and the deadline date; trust yourself, focus only on the chunk at hand, and don’t get mired in the big picture! That’s what the planning phase was for, remember?

Be disciplined with your “work sprints” as well as with your breaks!

Obviously you plan to work, but do you plan to not work? Planning to work for 25 minutes straight is a lot easier to swallow when you know you have a guaranteed break after. You’ll also be a lot more focused if you know that, at the end of that 25 minutes, you better have something done, because it’s “pencils down” and no more work is allowed for the duration of the break. Be disciplined, firm, and consistent with your breaks, and you’ll find that your motivation and focus during work periods will increase as well.

Like any change in habits, there is no way to sidestep the effort and sheer willpower needed to make the change. There will be times when you simply just do not want to care, and when you don’t want adhere to the plan. One thought I commonly encounter when doing this is “man, this chunk is so small, I can easily do this later, when it won’t be interrupting my flow of free time!” That’s how it starts! Don’t give yourself any wiggle room! By adhering tightly to the plan, you will ensure that your task is always completed by the deadline, and without the crazy spike in stress of putting the whole thing off until the last minute, and that is definitely worth losing a little fun time right now.

Learn to delay gratification, and to do the little chunks when they need to be done. You’ll thank yourself later. I promise.

OSX Scrolling: How Apple gets UI right

It is important with any interface to have feedback for actions performed. In mechanical interfaces, that comes through physical motion and tactile feedback. With electronic devices, almost all interaction takes place through the manipulation of some on-screen rendered image of an interface which represents something that is easy for us to navigate. When we’re using a keyboard and mouse or trackpad to navigate an OS, we don’t get that tactile feedback. Sure, the keyboard and mouse in and of themselves are physical devices, but they click or “press” just the same, regardless of whether the action you performed on-screen was successful or not. Because of this, it is crucial that the interface provide feedback of some sort. This is exactly what Apple does with the elastic stretching when trying to scroll past the end of the page.

My previous laptop, a Samsung 7-series, uses the Elan smartpad. Unfortunately, it doesn’t pick up finger touches as well as other trackpads, and so sometimes I have to repeat my attempt to scroll in order for it to register. Since Windows doesn’t perform any action when trying to scroll past the end of the page, there are certain times when I’ll be looking through a page, reach the end of it, and when it fails to do anything, I think that the touchpad simply failed to register my action. Windows doesn’t provide any feedback when I am unable to scroll anymore, and so I have no distinction between “end of the page” and “didn’t register scrolling attempt”.

When you reach the top or bottom of the page and you can’t scroll any more, OSX does this little elastic-stretchy thing where it’s as though you’re trying to pull the end of the page up or down, but it’s stuck. This elastic stretching provides the user with feedback. It’s a way of saying, “hey, I know what you’re trying to do, but you can’t do it.” Even if my MacBook Pro had this problem with the trackpad not reliable picking up gestures, I would be able to differentiate between a failed scroll attempt and the inability to scroll down any further.

Emaximus Ep 1: Creative use of query-replace

When it comes to writing code, having the right tool for the job can enhance your productivity many times over. This is the first episode in a series on improving your fluency with the Emacs editor. This is NOT a post/series on why you should use Emacs over VIM, or why you should use Emacs over Eclipse / Visual Studio / Notepad / [your favorite editor].

This is also not a “Getting Started” guide for emacs. There are plenty of those already, so I’m not going to reinvent the wheel. Rather, this draws on my own personal experience with Emacs over the past 2 years of using it. I don’t claim to be an expert, and I’m always open for suggestions/alternatives/improvements regarding the material I post! That having been said, let’s dive in!

Today’s topic: Creative use of search and replace!

You already know M-% will invoke search and replace. You also know that C-q C-[some key representing a non-ascii character or control character] will insert characters that correspond to special keys/character codes (this is called “quoted-insert”).

Now, let’s say you are editing an HTML file, and it looks like the following:

<html><head><title>This is a web page!</title></head><body>Lorem ipsum text goes here!</body></html>

This is ugly, and furthermore, we can’t do automatic indenting (C-M-\) because the code is all on one line! What to do? Let’s combine our knowledge of search and replace with quoted-insert!

  1. Use M-< to go to the beginning of the file.
  2. M-% to enter search and replace.
  3. Use the < symbol for the search string.
  4. For the replace string, type C-q C-j (newline character), and then the < symbol.
  5. Now Emacs will step through each occurrence of < and ask you to replace. Press y or n where needed to put the appropriate tags on a new line!

Now we can run C-M-\ on the file, and (depending on your indentation settings) get the following result:

    <title>This is a web page!</title>
    Lorem ipsum text goes here!

Deleting all partitions on a USB drive using fdisk

Due to my rampant experimentation with many different Linux distros, I often times have to wipe a USB drive completely after making it a bootable live USB for something like OpenSUSE. If you used the Imagewriter.exe program used to create the drive, you’ll have a hard time later on if you try to use uNetBootin to make a live USB for a different distro. You can use bootice.exe in Windows to restore the drive. Here’s how to do it with fdisk in Linux (courtesy of PenDriveLinux.com)Restoring your USB key to it’s original state using Linux:

First we need to delete the old partitions that remain on the USB key.

  1. Open a terminal and type sudo su
  2. Type fdisk -l and note your USB drive letter.
  3. Type fdisk /dev/sdx (replacing x with your drive letter)
  4. Type d to proceed to delete a partition
  5. Type 1 to select the 1st partition and press enter
  6. Type d to proceed to delete another partition (fdisk should automatically select the second partition)

Next we need to create the new partition.

  1. Type n to make a new partition
  2. Type p to make this partition primary and press enter
  3. Type 1 to make this the first partition and then press enter
  4. Press enter to accept the default first cylinder
  5. Press enter again to accept the default last cylinder
  6. Type w to write the new partition information to the USB key
  7. Type umount /dev/sdx (replacing x with your drive letter)

The last step is to create the fat filesystem.

  1. Type mkfs.vfat -F 32 /dev/sdx1 (replacing x with your USB key drive letter)

That’s it, you should now have a restored USB key with a single fat 32 partition that can be read from any computer.

Finally solved: Touchpad x/y sensitivity differs with screen aspect ratio!

For the longest time, one of my biggest gripes about Linux in general is that my Synaptics touchpad was more sensitive in the x direction than the y direction. I figured that this was due to having a 16:9 laptop screen, and assumed that the driver scaled to screen aspect ratio by default. This was confirmed when I plugged in an external monitor, and (when the monitors were arranged side-by-side), the cumulative x-dimension was used to calculate the touchpad aspect ratio. This resulted in a much higher sensitivity in the horizontal direction than the vertical direction.

After finding zero helpful information on almost every website, I finally stumbled across a solution here (note that the first answer idiotically suggests that you check the mouse panel under system settings):

Solution for Ubuntu 11.04:
Add the options

Option "VertResolution" "75"
Option "HorizResolution" "75"

To the file /usr/share/X11/xorg.conf.d/50-synaptics.conf

After doing that, mine looks like:

Section "InputClass"
     Identifier "touchpad catchall"
     Driver "synaptics"
     MatchIsTouchpad "on"
     MatchDevicePath "/dev/input/event*"
     Option "VertResolution" "75"
     Option "HorizResolution" "75"

Now log off and log back in, and it should be fine! 🙂

I’m running Linux Mint 11, and it works just fine for me.

Gnome 3 via PPA with Ubuntu 11.04

If you have Ubuntu 11.04, you can install Gnome 3 using the following commands from the terminal (thanks to AskUbuntu.com for the info):

sudo add-apt-repository ppa:gnome3-team/gnome3
sudo apt-get update
sudo apt-get dist-upgrade

Now, every time I’ve tried this, Gnome 3 is already installed after these 3 lines. However, AskUbuntu.com’s post lists a 4th line, which you can try if the above 3 don’t do the trick:

sudo apt-get install gnome-shell

Some other tweaks
Here are some things I had to do to get it working right on my laptop (Compaq Presario CQ-56 115DX w/ ATi Radeon Mobility 4200). I was getting graphical corruption when using the fglrx drivers, so in order to revert back to the open source drivers, I did this:

sudo apt-get remove fglrx
sudo rm -f /etc/X11/xorg.conf

Also, when I installed via PPA, the theme didn’t look right… Looked like something straight out of Windows 95. To fix things, I did the following:

Install Half-Left’s Gnome 3 Shell theme, “Elementary”:

Install Half-Left’s “Adwaita Improved” window theme:

I also made some tweaks to the gnome-shell.css file that comes with the Elementary theme. I did that by typing the following into the terminal:

sudo gedit /usr/share/gnome-shell/theme/gnome-shell.css

I’m not a big fan of large or bold fonts for a UI, so I just set all bold fonts to normal font-weight, and set the sizes to 8pt.

Installing Flash Player 64-bit for Chrome in Linux

Download the 64-bit Linux version of the plugin. The version I used was here, in tar.gz format.

Next, extract the file into your home directory. It should extract one file, libflashplayer.so.

Finally, open a terminal, and type the following:

sudo mkdir /opt/google/chrome/plugins


sudo mv ~/libflashplayer.so /opt/google/chrome/plugins/

Restart Chrome, and type


into the address bar. You should see the flash player plugin you just installed!