Text

On switching to Arch Linux

So you’re thinking about switching to Arch. Here are some things you should probably know first.

(I’m assuming you already know all the great things about Arch — otherwise, you wouldn’t be thinking about switching — so I’ll skip that part).

Potential downsides to Arch

First of all, nothing works out of the box. You will have to manually set up the driver for your video card, support for your sound card (which can be a little difficult if you use USB headphones), wifi support, Xorg, your desktop environment and/or window manager of choice, etc. If this sounds horrible to you, then Arch probably isn’t for you.

You also have to make lots of choices yourself. You start with nothing and build your way up according to your own preferences, so if you’re the kind of person that doesn’t enjoy tweaking or researching and would rather just go with the flow and use whatever your distro installs for you, then Arch isn’t a good fit.

Finally, a downside of Arch pushing software updates to the repos so quickly is the potential for stability issues. I personally haven’t had any issues in the months that I’ve been running Arch, but you see some reports of issues related to running cutting edge software (often related to the wrong versions of dependencies). Note, however, that reading the Arch news on the homepage often gives you advanced warning of things to watch for.

Tips on installation

If you’ve finally decided you’re going to try it, then read on — there are some things to keep in mind when installing Arch.

Before the install

Before you start the install, make sure you’re installing it next to a 2nd computer with internet access. This way you can follow the install directions in the wiki and you can also Google any random issues that come up.

Also, go ahead and research/decide on which desktop environment and/or window manager you want to use. Arch supports pretty much all of them, so the choice is yours, and you want to have your mind made up before the install so you don’t have to stop in the middle of it to decide.

Note that the typical first-time Arch install takes somewhere around 2 hours to get everything working (maybe more if you run into issues) so make sure you have some free time.

Make sure that the computer you’re installing Arch on is hooked up to the internet via a wired connection, so you don’t have to mess with setting up wifi before the installer can begin.

Finally, Google your hardware to make sure there aren’t compatibility issues. This means everything — sound card, video card, headphones, printer, etc. There’s nothing worse than getting a working install and then realizing that your sound card isn’t supported.

During the install

Use the Beginner’s Guide like your life depends on it. It leads you through the install step by step and you do NOT want to try installing without it. Don’t skip any parts, and don’t do anything you’re unsure of; if the Beginner’s Guide doesn’t answer a question, then Google it before just guessing.

When the time comes in the install process where it asks you which packages you want installed, I recommend not installing anything at this point. Eventually, you’ll want to install and configure Xorg along with your DE or WM of choice, but that can easily be done after the install rather than during, and that way you’re taking it one step at a time. Save any apps you want installed for last.

After the install

Once the install is complete, you’ll first want to set up Xorg and make sure that’s working (the Beginner’s Guide also covers this). Then you’ll want to install your DE and WM of choice. Then you’ll want to get sound and wifi and other misc hardware working (there are usually wiki pages for whatever you’re working on). Finally, go ahead and install the apps you want and start tweaking.

Getting help

If at any point you run into issues, spend time researching and Googling before you resort to asking on the Arch forums or in IRC. The Arch community as a whole focuses on self-service and solving your own problems, and if it’s obvious that you haven’t tried, then they proably won’t be too friendly about helping you out.

Tags: Arch Linux
January 26, 2012
Comments
1 note
Video

Sal Khan from Khan Academy explains SOPA/PIPA. This is the best, most understandable explanation I’ve found, and is the kind of thing that most non-techies could probably grasp.

Source

January 19, 2012
Comments
Text

How to set up a Clojure/Noir website on WebFaction

Setting up a Noir site on WebFaction is surprisingly easy, thanks to Leiningen. Here’s how I did it. I’m assuming you already have the site built in Noir and you basically know your way around a Linux machine.

Note, this assumes that you haven’t already installed Clojure or Leiningen, but that you already have the JRE, which I believe comes by default on all WebFaction servers.

  1. In the WebFaction panel, create a new “Custom” -> “Custom App (listening on port)” application and assign it to a website, just like you’re setting up any other site in the panel. Make a note of the port your app was assigned (it’s a column on the Apps List page).
  2. Download and install Leiningen according to the instructions on the GitHub readme. Basically, just wget the script, chmod it to 755, and put it in /home/yourusername/bin.
  3. Download your site’s code to the directory for the webapp you created in step 1, so that your project’s project.clj file is directly under /home/yourusername/webapps/yourappname.
  4. Change the port number in your codebase to the port you made a note of in step 1. To do this, edit Noir’s src/projectname/server.clj file and change 8080 to the new port.
  5. Now you’re ready to run it. From within the same directory as your project.clj file, run lein run prod and all of your dependencies should download and install. Once all that’s done, you should be able to pull the site up in a browser.

You should also probably set up a cron job to restart the process if it ever ends (like if the server restarts or the process is killed) using something like this.

January 03, 2012
Comments
Text

Ted Dziuba on Taco Bell programming vs. using what you enjoy

If you haven’t read Ted Dziuba’s post on Taco Bell programming, go do that now. It’s really a great post.

The gist is basically that we can and should be writing programs using the stuff that’s been available for tens of years, stuff like bash and xargs and find, and that using the latest and greatest tool or language simply adds complexity and bugs. He compares it to Taco Bell, which uses “roughly eight ingredients” in random combinations to make the entire menu.

This was like a smack in the face to me, a person who always gets excited about trying the new hotness. One thing about it concerned me though - a lot of that stuff just isn’t fun. Nobody wants to write stuff in bash, and there’s a reason people use modern tools: they’re often more fun and less annoying.

So I emailed him to ask him how he balances that. Here’s my email:

Hey Ted,

Feel free to ignore this question if you’d like. I’m sure you get a lot of emails from random devs, especially lately.

Straight to the point, just read your taco bell programming post and was intrigued by it, but it didn’t mention anything about dev preferences or the dev experience. For example, writing something in bash (like Hubot for example) might take less code to do it in Python or CoffeeScript or whatever and it might be the more solid solution but most devs will go way out of their way to avoid having to write something non-trivial in bash.

So the question is, how do you find a balance between simplicity/tried-and-tested-tools (taco bell ingredients) and ease or enjoyment of development (using a more modern language/tool just because it’s less annoying)?

Thanks. Big fan of your posts.

Here’s his response. I wasn’t planning on posting his response (if he even ended up responding) but it’s such a great answer, I’d feel like a chump if I didn’t share it.

Hey Mike.

I know a lot of devs will go out of their way to avoid shell scripting, and generally using the tools already available to them by their operating system. I know, I used to be one of them.

I got into letting Unix do as much as it can for me by the advice of a systems administrator I hired, who really swayed me toward that culture, and after the first project I wrote on Unix principles, I immediately saw the value of it (this one piece of functionality was the most rock solid thing I have ever written, it’s been running for 2 years now with zero maintenance).

On to your question. I guess it depends on what’s easy for you to do as a developer. Learning a new language like Bash isn’t something to take lightly. I still don’t know enough of it to be dangerous, but I hack things together. Once you understand the Unix Way, the process becomes much easier. I’d recommend reading “The Art of Unix Programming” for some great insights.

Generally, you’re never writing nontrivial code in Bash. You use a bash script to string together smaller utilities into something useful. All the real meat of execution happens in the programs your shell script calls. Nothing precludes you from writing bits of functionality in any language you want. One of the Unix Way principles is that “a program should do one thing, and do it well”.

When I try to find the balance between Unix tools and custom tools, I ask 3 questions:

1) What parts of this problem does the operating system solve for me?

2) Of the parts that the OS can’t solve, am I simply not aware of something my OS does that can solve the problem? (This happens a lot.)

3) What’s likely to be the most brittle part of the system?

I find that a lot of developers have gross misconceptions about how operating systems work, and will try to excuse themselves behind a veil of “scalability” or somesuch. For example, I had a good argument with a developer last week who was convinced that “starting processes was slow”, so he was cooking up some threaded catastrophe.

Fact was, it’s simply not true. Modern Linuxes can spawn processes very quickly, and actually use the same syscall to spawn a process that they do to spawn a thread (clone()).

At the end of the day, it’s really something that comes with experience. With any system you write, V2 is always way better, because you’re more aware of the things you don’t know :-)

December 08, 2011
Comments
Text

My minimalist setup

I recently completely changed the setup on my main laptop to something much more minimal than what I was running before (vanilla Ubuntu). I decided to post this braindump here just as a way of telling myself “this is it” and acknowledging that it’s time to quit tweaking and be happy. I love this setup.

Hardware

My laptop is just a plain old Thinkpad W510 with a 15” screen running 1920x1080. I don’t have another monitor, I don’t have a desktop or a second laptop, this is it.

Operating System

I am now running Arch Linux. Arch is basically the complete opposite of Ubuntu, meaning that instead of everything working out of the box and giving you tons of starter apps, nothing works out of the box and you start with nothing but a command line, and build up from there.

If this sounds horrible to you, then Arch probably isn’t for you, but it sounded intriguing to me so I tried it out. I am now a full-fledged convert for a few reasons:

  1. Rolling release. Instead of locking package versions every 6 months and forcing you to do a full re-install when a new version releases like Ubuntu, Arch just sends you updates as they come in. This means that 1) you don’t have to start over every 6 months and 2) you always have the latest stable version of everything without having to mess with PPAs.
  2. The AUR. This little miracle is basically a repository of packages that are maintained by users rather than the core Arch team, and almost anything you can think of that isn’t in the core/community/extra Arch repos are in here, so you almost never have to go about manually installing stuff.
  3. Simplicity. You start from nothing and build your way up, so you know how everything works and you’re better prepared to fix something if it goes wrong. Also, you don’t have anything you didn’t specifically ask for, which keeps your system lean and easy to understand.
  4. Configuration. All Arch config is done by editing a couple text files as opposed to clicking around in a GUI, and any programmer can tell you the benefit of keeping stuff in text (easily backed up, can be stored in a VCS, can be reverted, can send it to other people, etc.).
  5. The Wiki. The Arch wiki is amazing. I’ve gotten to where I add “arch wiki” to the end of any Linux related Google search now because it just consistently has the most comprehensive and up to date info.
  6. The community. Lots of distros have big active communities, but few of them have people as knowledgeable and as helpful as Arch does. Look through the average quality of replies in a random Arch forums post vs. that of a random Ubuntu forums post for an example.

Desktop Environment

I’m not using a desktop environment (e.g. Gnome, KDE, Xfce, etc.) per se, and instead just using my window manager as my desktop environment.

Window Manager

I finally settled on scrotwm after trying out tons of tiling window managers and even spending a few weeks with XMonad.

Scrotwm is awesome. It’s basically XMonad (all the concepts and even the vast majority of the key bindings are the same), except it’s written in C rather than Haskell and it’s configured using regular old plaintext conf files rather than Haskell. I like the built in statusbar (I pipe info to it from conky), I like the vim-like key-bindings, I like the simplicity.

The one downside is that the built in status bar doesn’t include a systray, and I need one, even if just to use Parcellite, so I solved that by installing trayer, adding this quirk to my scrotwm.conf:

quirk[trayer:panel] = FLOAT + ANYWHERE

…and telling scrotwm to automatically run it on the 2nd workspace at startup using:

This sets trayer up in a nice little tiny floating window at the top right of my 2nd workspace. It’s small enough that it can’t really get in the way of anything, and if I really wanted to I could move it up so that it’s on top of the statusbar (i.e., where systrays usually are).

Browser

I just use Chromium. Quick, simple, and the web inspector has really caught up to Firebug in the last year or so (in fact, I like it better for some things).

Music

I don’t have a desktop music player. Between Grooveshark, Turntable.fm, Pandora, and Google Music (I have like 30GB of songs on there), I’m set.

Code Editor

I’m still using vim, and I still love it. Here’s my .vimrc which has a list of my plugins.

Shell

I recently switched from bash to zsh after listening to this podcast on The Changelog. It’s basically bash plus a few cool extras, such as really robust tab autocompletion (for example: type “kill <tab>” and see a list of running processes you can kill), spell checking and autocorrection (this has saved me more time than I’d like to admit), and, when used in combination with oh my zsh, a super awesome plugin and theming system (here’s an example of a particularly tricked out zsh prompt to give you a taste, even if it’s a little too verbose for my taste).

My zsh prompt is pretty simple, it just contains the directory name, the git branch, and a tiny yellow lightening rod if there are uncommitted changes. Here’s the theme file if you’re interested.

Terminal

I’m using XTerm with a Molokai color scheme. Here’s the config for that.

IM

I’m still just using Pidgin for everything since it handles everything in one place.

Wrap-Up

That’s pretty much it. My setup is nothing more than Arch + scrotwm + Chromium, XTerm, and Pidgin. It’s really rare that I need to open any apps besides those (and GIMP every now and then). It’s been a huge success so far and I’m really loving having such a simple setup.

If you’re feeling nerdy, feel free to check out all my config files, and if you have any questions I’ll be happy to answer them in the comments.

September 23, 2011
Comments
1 note
Video

The American Dollar - Anything You Synthesize

September 23, 2011
Comments
Text

Running custom Django commands via cron on WebFaction

Update: a much more detailed guide is right this way which might be easier to follow than my quick post below.

The typical way of running Django commands via cron is usually something like:

0 * * * * python /path/to/django/manage.py commandname

…but that won’t work on WebFaction. You have to tell it what your PYTHONPATH and DJANGO_SETTINGS_MODULE should be set to, as well as give it an absolute path to Python.

Here’s an example:

There’s some more info in this forum thread if you get stuck.

September 15, 2011
Comments
Text

How to kill a dead SSH session gracefully

I have a bad habit of leaving an open SSH session sitting there and then coming back to it to realize that it’s dead. In the past, I’ve just killed the terminal to end it. Here’s a better way:

<Enter>~.

That’s the enter key followed by the tilda character followed by a period.

To explain, SSH has a few different escape sequences. To see them, run ~? while in an open SSH session. Here they are:

mcrittenden@freshbox$ ~?
Supported escape sequences:
  ~.  - terminate connection (and any multiplexed sessions)
  ~B  - send a BREAK to the remote system
  ~C  - open a command line
  ~R  - Request rekey (SSH protocol 2 only)
  ~^Z - suspend ssh
  ~#  - list forwarded connections
  ~&  - background ssh (when waiting for connections to terminate)
  ~?  - this message
  ~~  - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

As you can see, ~. is the escape sequence to terminate the connection, and the note at the end says that they’re only recognized immediately following a newline, hence <Enter>~.

Tags: Bash Programming
August 30, 2011
Comments
16 notes
Text

My quest for a tiling window manager

I’ve never used a tiling window manager before, but lately I’ve been doing more and more with the command line, and I’ve been using vim-only for almost a year now, so it seems like a natural next step.

So I went through a few of them over the weekend looking for the right one. But first, some background.

What is a tiling WM?

Most computers have “floating window managers” that let windows overlap and let the user drag them around and resize them. In contrast to that, a tiling window manager stacks windows up side by side according to preset layouts and groups them into workspaces. That’s a huge oversimplification, but it’ll do for now.

Why the crap would you want that?

For one, they’re much easier to control using only the keyboard. Most of them have a “mod” key (usually either the left alt key or the windows/super key), and you control the WM doing stuff like mod+2 (switch to workspace 2), mod+j (focus on the window below the current one), mod+space (change layouts), etc.

Also, they save space since there are no window decorations and no space between windows.

Finally, lots of people like the automation this allows. You can say stuff like “open my IM client and windows in the third workspace using the three column layout” and you don’t have to arrange stuff manually or move anything around (although you can).

XMonad

I started with XMonad just because it had a really helpful page on using it as a drop in replacement for the default Gnome WM, so I could still use all the good stuff Gnome has to offer easily.

I had trouble with installation (on login, I kept getting “session not found” errors), and it turned out it was because I named one of the config files xnomad.desktop instead of xmonad.desktop without thinking. Once that was worked out, it was pretty smooth. It was basically Gnome 2 (including the panels) but with XMonad instead of Metacity.

I liked it, but I wanted to change a couple things (add a few non-core layouts and change the color of the red border on active windows, for example), and all configuration to XMonad is done in Haskell, and this threw me for a loop. Everyone said you could easily just copy and paste from sample configs on the net but I didn’t have any luck with that, and I didn’t want to have to learn Haskell just to configure my WM, so I moved on.

Awesome WM

Awesome and XMonad seem to be the two most popular nowadays, so it seemed logical to try them first. I apt-get’ted awesome and set it up to run inside of Gnome according to the instructions on the awesome wiki. This worked fine on the first try.

I didn’t really “get” awesome though. For example, awesome lets you tag windows rather than just stick them on workspaces, and each “workspace” is a tag, which means that windows can appear on multiple workspaces. I didn’t see the appeal of that. Also, I wasn’t a fan of the launcher because you couldn’t see what the remaining options are as you type like you can in dmenu and installing dmenu didn’t seem to work (hitting the key binding for it just redrew the screen). I also kept seeing weird gaps in between windows that I wasn’t able to fix. Finally, I tried switching the mod key from mod4 (windows key) to mod1, and it didn’t seem to change anything and I couldn’t figure out why. So I moved on out of frustration.

Scrot WM

Scrot WM came recommended on a couple of random forum threads so I tried it out. I apt-get’ted it and just ran it outside of Gnome since it was quicker to try out that way. I really really like Scrot WM for the most part. The default key bindings are vim-like which is great for me and it runs dmenu by default.

Unfortunately, the integrated panel doesn’t support any type of tray (I’d have to install something external like dzen2 which looked like a headache judging from the how-to’s I found), and when I tried integrating with Gnome, I couldn’t get the Gnome panel/tray to show up correctly. I’m not quite ready to leave a tray behind altogether (for stuff like chat notifications, the networking applet, etc.), so I moved on hoping to find perfection although I was sad to leave Scrot behind.

Stump WM

I didn’t try Stump WM out because the default key bindings are all very emacs-like which immediately put me off. Call it judging a book by its cover, but I wasn’t desperate yet.

dwm

I also didn’t try out dwm. It seems like the kind of thing that’s just a little too hardcore for me (you configure it by hacking the source code and recompiling), and I was looking for more of a beginner’s tiling wm for now.

Subtle WM

Subtle WM was an easy install (manually using Ruby/Rake) and it looks great by default. But it’s a manual tiling window manager, which means that you’re responsible for placing your windows where you want them, and they don’t just pop into the current layout on their own, and that wasn’t what I was after. I also had trouble figuring out how to use the thing - at first, I couldn’t do anything because the default terminal is urxvt which I didn’t have installed, and if you don’t have it, you basically can’t launch any programs. Once I installed it, the idea of clients and gravities didn’t click with me, so I gave up.

wmii, ion3, i3

All of these came recommended in a few places, but they’re all manual TWMs like subtle, so I moved on quickly, making a note to come back if/when I got desperate.

Back to XMonad

At this point, the tiny quirks I had with XMonad weren’t looking so bad, so I decided to log back into it and just give it a shot for a few days and see what I thought. That’s what I’m doing now, and so far, things are still going great. The default key bindings are vim-like (mod+j and mod+k to switch to the previous or next window, mod+h and mod+l to change the size of the master window) so it was easy to get used to quickly. There are tons of other layouts and goodies in the xmonad-contrib package but I haven’t opened that can of worms yet.

I really wanted to get xmobar and trayer going to get the full experience rather than using a Gnome panel, but for now, this’ll do. I’m really enjoying it so far.

If you have any questions or suggestions, feel free to stick ‘em in the comments.

Tags: Linux
August 22, 2011
Comments
2 notes
Text

Custom Lookit panel icon to match Faenza icon set

i’m a big fan of Lookit, a really simple screenshot app that runs as an indicator applet in your panel. Only problem is that its default icon is flat black and looks terrible with most icon sets, including Faenza, which I use.

So I made a new one to match. Here’s the end result (it’s the camera icon):

If you want to download it, here’s the link. To install it, just replace the default lookit.svg with that one in /usr/share/icons/hicolor/scalable/apps/ and restart Lookit.

Also, note that the author told me that the next version would change the way that icons are handled as well as come with new default icons, so this info might not be current for very long.

August 13, 2011
Comments