This is an operating systems post. If you don't care about computer operating systems, please read something else.

I've been using Linux (occasionally known as GNU/Linux) for about the last 13 years. I'm not really an expert, just an enthusiast. Along the way I've heard about these other, more niche UNIX-like operating systems operating somewhere in the Ether. The so-called BSD's, open source descendants of the Berkeley Software Distribution of UNIX. They have been a little less progressive as Linux, being mainly used in server situations. I just haven't spent the time. I still barely know enough about Linux to use it efficiently as a programmer.

But, you know, I here things. I heard that there's a distro of FreeBSD offering a graphical installer and a modern, KDE desktop by default. It's called PC-BSD, and the latest version, 8.1, matching the release of FreeBSD 8.1 is out. I thought, what the heck? I'll give it a try, see what it's like. Most Linux distros are a compilation of a recent Linux kernel, a bunch of standard GNU userland tools, X.Org (the Unix graphical interface), some desktop environment, usually Gnome or KDE, and a bunch of standard open-source software packages. In contrast, PC-BSD is the FreeBSD system (which includes the kernel and standard userland tools -- not GNU, for the most part) as well as X.Org, KDE and some of the same open source software packages you might see on a Linux distro, like Firefox, OpenOffice, Java, etc.

Truth be told, I spend most of my time with the higher-level tools. I don't care or think about kernel-level things like file system drivers or operating system memory management. So, I guess I don't know what I was looking to see. Honestly, the whole experience turned out to be slightly disappointing.

Installation was a bit of a nightmare. I had to use Linux tools to shrink my partition to make room for a new partition on my hard drive to install PC-BSD. The installer wasn't capable of this as it is on the installation disks of most modern Linux distros. The greatest little swiss-army knife of partition fiddling is Parted Magic. OK, so I get the think installed. Word to the wise, if you want to dual boot Linux, don't use the PC-BSD boot loader. It can't boot Ubuntu properly. Grub, the boot loader that comes with Ubuntu and many other fine Linux distros can boot FreeBSD / PC-BSD properly.

So, I got PC-BSD running on my laptop. It detected the Nvidia chipset handily and the modern KDE 4 desktop was quite stunning, as it is I'm sure in Linux. I tried to connect via the wireless chipset in my laptop. I found the Network configuration, selected the wlan0 device, had it scan for wireless connections, it found mine. I selected it, selected WPA encryption, entered the password, clicked OK. Everything seemed to be going fine, but right then my laptop rebooted. Just a nice, hard reboot for my troubles. OK, so PC-BSD isn't ready for my laptop. Ubuntu runs on my laptop fine, BTW, detects the wireless perfectly and just works.

Not to be defeated, I installed PC-BSD on my desktop computer at home, which also is running the latest Ubuntu distribution without issue on any of the hardware. I got it up and running, opting for a network install which involved running CAT-5 across the house to get it connected to the network. It took a long time to install. When it was done, I put away the CAT-5 cable and went to configure the wireless device on this machine. No reboots, but the signal strength was extremely low and the connection was cutting in and out constantly, making it completely unusable.

So, I guess I didn't get very far. I went into the terminal and poked around a bit. Some things are in different places on the file system, the shell, which I think was the C-shell by default, worked about as I expected it. Vim was there, too, so I think I could probably use FreeBSD fine, if I could only get any of my wireless devices working properly. KDE seems quite snappy. Much better than the last time I used it, actually.

In conclusion, I don't think the kernel and core operating system tools are of much concern to me, as a programmer. All the tools I use for productivity are available on FreeBSD / PC-BSD as far as I could tell. The wireless support, regarding breadth of hardware supported, seems to be limited, at least from my random sampling. I didn't really look too far into the FreeBSD ports system or PBI's but it seems maybe a little bit of extra work compared to the ease and ubiquity of Ubuntu/Debian software packages.

For now, I see no immediate benefit from using FreeBSD to outweigh the hardware support issues. I don't have anything against it, either, it seems like they maybe just need a bit of wider desktop/laptop support to be a viable alternative, to my already viable alternative to the closed Microsoft and Apple desktop operating systems. For now, I'll stick with Ubuntu, but I'll try each new release of PC-BSD as they appear. KDE is looking nice these days. Who knows, I may boot it up in Ubuntu (you can do that, you know) for fun.

Yeah, so you can't seem to initialize a Pylons application correctly in Ubuntu 10.04? Seeing an error like this?

IOError: No egg-info directory found

You must have forgotten to install python-setuptools. Try again. This time with more mind-reading.

The folks that brought us Stack Overflow, the ultimate addicting Q&A site for programmers, have dropped another bomb. They have started pumping out Stack Exchange sites based on community consensus and involvement. These are Q&A sites that use the Stack Overflow engine, but themed for completely different purposes. Well, I just found English Language and Usage. Seriously? I may be a software developer, but I was an English major, Scrabble player, and general language enthusiast. So, for my sanity, I will just pretend that the other Stack Exchange sites don't exist. Except that I'm already using the Ubuntu Stack Exchange site.

If you've got a VPS and you'd like to use it to host private git repositories, as a backup for your own work, it's pretty simple. First thing is you need to setup password-less ssh logins. That's covered in a lot of places, but I'll get to that too, if need be. From your own Linux machine you need to create a new keypair if you haven't already. Run this command:

$ ssh-keygen -t rsa

It may ask you for a passphrase, this is so you can protect the key itself on your personal computer. It's not necessary, but if your Linux distro is Ubuntu, it will only force you to enter that once per login to use the key. Just leave it empty if you aren't sure. Then you want to copy the public key to your server:

$ ssh-copy-id -i ~/ssh/id_rsa.pub username@yourserver.com

It will ask for your ssh password during this step. After you run this you'll want to test it out and see if you can log in to your ssh account without a password:

$ ssh username@yourserver.com

Assuming that is working, you can simplify logging into the server even further by creating a ~/.ssh/config file that looks like this:

host yourserver.com
user username
port 12345

You don't need the port setting if you are using port 22 or the user setting if the username is the same as the account on your machine. Having the host setting allows you to tab complete when ssh'ing from the terminal which is handy. Now for the good part, ssh into your server if you haven't already. Create a folder with a ".git" extension and initialize it:

$ mkdir myproject.git
$ cd myproject.git
$ git init --bare .

Log out of your server so you're back in the local terminal and clone the repository you just created:

$ git clone git+ssh://yourserver.com/home/username/myproject.git

That will create an empty folder called "myproject". Put some files in there, commit a revision and push that revision to the master server:

$ cd myproject
$ cp ../somefile.txt .
$ git add .
$ git commit -m "initial commit"
$ git push origin master

From now on, all you have to do to push local commits is "git push". Enjoy.

Some years ago, I fancied myself some sort of garage musician. I had a guitar, that's all you need, right? I wrote and home-recorded a few songs. I was going to school, so, I didn't know too much about the difficulties of doing music as a profession. Plenty of people involve themselves in creating music as a hobby or small part of their life. I have some friends who are composers for a living. Being a professional rock star is a bit unlikely for most people, regardless of talent. But, if you have musical talent and skill, you can be a composer. You just need a bunch of equipment (or really, just a computer, microphone(s), keyboard(s), and some instruments) and a nerdy drive to create music causing you to invest the thousands of hours necessary to become skilled enough to sell your work. As an aside, becoming a professional software developer is very similar, though in this case the equipment is just the computer and a reliable internet connection.

Back when I had some small musical aspirations of my own, if a genie had appeared and granted me 3 wishes, one of those would have been a drummer, right after world peace and right before a delicious taco. Y'know, just some guy who would come over and jam whenever I wanted to. I know, they invented drum machines, but, well, they suck for rock music. You need a living beat, to hang the rest of the music on. I experimented on occasion with programming my own beats, but they felt rigid and awkward. I just didn't have the skill or drive to program beats.

I've left all musical aspirations behind, and I'm fine with that. I was never as passionate as friends of mine who started bands, taught music lessons to support themselves and figured out how to be successful composers. I did find something to be passionate about. It was programming computers. Specifically, I wanted to become a video game developer. It took me a few years and thousands of hours of practice, but I became a software developer at a game studio.

Becoming a video game developer was a bit like successfully forming a touring rock band. Once you get there, you realize that the work is hard, not glamorous, and doesn't pay very well (at least not at first). After a year in the trenches, I realized that I staying in the game industry meant low pay, high stress, and less fun than I had hoped. I also realized that I was now qualified to work in other areas of software development. After doing some quick calculations, I realized that I would be happier in just about any other software field. Video games are a bit like hot dogs, delicious until you see the process required to make them.

Before I "made it" into the video game industry, I spent some time doing QA and software development for a company that made hardware and software products for saw mills. They didn't make saws, but the systems that controlled the saws to cut the maximum value out of the dead trees. I learned enough from QA to have an appreciation for good software development practices. These are not done within the video game industry as far as I could see.

Fast-forward to the present. Now I work as a developer of web applications or a web developer, or a senior software developer specializing in web technologies. Or whatever. I program the internets, OK? As a web developer, there are a minimum of two computers I have to worry about, the server and the client. In real life, there are proxies and load balancers, front-end and database machines, caching servers and all assortment of machines to deal with on the back-end.

The back-end is actually easy, though. The state of the art is plowing along nicely. I'm not much of a sysadmin, but I can manage Apache and Nginx configurations if necessary. I could probably configure a basic multi-server configuration given an afternoon and plenty of coffee. It's just a matter of researching best-practice configurations given the needs of the project at hand. Simple. I can spec out the work in terms of time and caffeine.

But there is this one little piece that bugs me. It's the part the user sees, if I'm building a web application. I haven't invested enough time and energy in developing a sense of how to build aesthetically pleasing interfaces. I can certainly build usable, functional interfaces, but they are not beautiful. I can tell you if an interface is ugly, but I can't tell you how to make a beautiful one, other than this: hire a designer.

Now, if the genie appeared with the wishes, you can bet I would wish for a designer, you know just some guy I could email and he'd supply me with blobs of HTML and CSS that were visually appealing interfaces for whatever I wanted to create. I can and do write oodles of HTML or code that generates it as needed. I also know how CSS works, but understanding how to use a paintbrush hardly qualifies you as a painter.

I created this blog's design on my own. And, well, it sucks. It's only saving grace is minimalism. I need a designer. I need a visual framework to hang the functionality on. Developing a skill in visual design is something I could probably do if I invested enough time in it. But, honestly, if it's anything like playing an instrument or programming computers, thousands of hours would be required to be any good at it. That would take time away from any other pursuits, especially programming itself.

Where I work we've switched our biggest project from Subversion revision control to Git. It is a large code base. I've been using Git for personal projects for awhile, but I've been keeping it pretty simple. For a large project with several contributors, Git is not only adequate, it's pure magic.

First of all, Git is fast. It's really, really, incredibly fast. On this particular code base, just running "svn status" could take 30 seconds. With Git, it never takes more than a second. Even "complex" actions, like merging large changesets, creating and merging branches take anywhere from 0 to 1 seconds. Really, you have to try it out to get a feel for how fast it is. Remember, this is a huge code base. The slowness of Subversion in comparison makes me think of the movie "Me and You and Everyone We Know." In it the foot store clerk, played by John Hawkes, tells the woman, played by Miranda July, when she tries to explain that her foot pain is due to her low ankles, "You think that you deserve that pain, but you don't." Eventually he tells her, "People think that foot pain is a fact of life, but life is actually better than that." If you think you have to wait for Subversion or whatever other source revision control because you have a large code base, you're wrong. You think that you deserve to wait, but you don't. People think that revision control system slowness is a fact of life, but life is actually better than that.

Branching is fast and relatively easy. First of all, everything happens locally. Git is really just a specialized database. Everything gets stored inside the single .git folder. You can create millions of branches with different changes and merge them every which way all without a functioning internet connection. If you have a central repository, just push your changes and pull other's changes at your leisure. So back to branching, I'm about to create a branch and switch to it. The branch I create will be a branch off of whatever branch I happen to be in. Hold your breath.

$ git checkout -b new_branch

Too easy? Just wait. Now let's assume that I changed some things and committed them to that branch, using "git commit". OK, now I want to switch back to the master branch.

$ git checkout master

Wait, that's it? What's in my working copy? The contents of the master branch, unchanged. The "new_branch" branch and it's change set are tucked away in that .git folder. You can then push that branch to the upstream repository like this:

$ git push origin new_branch

OK, so let's say someone wants to bring that branch into the master branch later. All they have to do is this:

$ git checkout master # make sure you are in the master branch
$ git pull origin new_branch # pulls in the branch to their repository
$ git merge new_branch # merges the changes into the master branch
$ git push origin master # pushes these changes to the master branch upstream

There are a lot of different workflows with Git. This is just assuming a "centralized" upstream repository. Even with the centralized model, there is a lot of flexibility. All of these operations are very, very fast.

With such prolific, easy branching, we now develop against reality not fantasy. With Subversion, we would just commit changes to the main branch, and our changesets would stack up on each other. Eventually, we had a backlog of changes that were all depending on each other, none of which had actually been merged into the production branch. It was a nightmare. Perhaps we could have had a better workflow with Subversion, but nothing seemed natural. With Git, the master branch is now in sync with the production site. We develop features against the site, as it exists, put them into a branch, and that branch gets merged with the master branch when the feature goes live.

We could have done something similar with Subversion but you have to merge changesets manually by revision number, and Subversion doesn't track these merges for you, so you have to be very careful not to reapply patches more than once. It's a big mess. Basically Subversion fails dramatically. Git. Just. Works.

One reason that Git does branch merging so much better is that branches aren't different folders with shared ancestry. Branches are just pointers to nodes in a directed acyclic graph of commits. Changes in one branch don't have to be recreated to be merged in another branch. Those changes have the same identification (a SHA1 hash), so they will not be applied twice. Here's a situation: you have three branches, A B and C. You make changes in all three branches. In branch A you merge in changes from branch B ("git merge B") and in branch C you merge in branch A, well you get branch B for free. If you try to merge in branch B into C at this point, Git already sees that each of the commits in that branch have already propagated to branch C, so nothing happens. That's what you want.

Commits are cheap, and have an identity. Every commit has a hashed id. If you want a single commit from a different branch, just cherry-pick it by id. If you merge that branch later, it already knows you've gotten that one part, so it won't re-add it. Smart, huh?

OK, Git isn't really magic. It's just computer science--which is nice. People in the subversion crowd are trying to keep it going, but I don't see the point. Continuing to use Subversion and other outdated revision control systems is masochism. Oh yeah, I've used a few others like CVS, Perforce, and Visual SourceSafe. Same crap, different name. If you haven't, do yourself a favor and try Git. Your whole life could be better. Just starting today.

Not only does LinuxQuestions.org spam users relentlessly, force you to log in to stop the spam, and generally have the crappiest forum software coded by lower primates, unchecking the "Receive Community Bulletins" checkbox in the account options page does not remove their spam from your inbox. Here is an open letter to the idiots who run LinuxQuestions.org:

You suck. Please read The CAN-SPAM Act.

I'm currently teaching a sort of introduction to programming class using Python. It's a fantastic beginner's programming language because it is very approachable. There is no minimum boilerplate code, like having to create a class in Java just to print "hello, world". There are no projects and IDE's to learn. There's just the interactive shell that lets you try things out without consequence. In any event I've been trying to come up with a simple enough program that the students could understand that seems, at least, potentially useful. The limitations are that the program has to run on Windows or OS X machines with the default Python install and it can't involve any advanced topics. Since I'll be discussing Python dictionaries in the next class, I thought a small shell-like program that allows the user to enter arbitrary data (build a dictionary), save it to a file (using pickle) or load from a file would be a good starting point. Here is the code: (Python 3)

import io
import pickle

data = {}

while True:
    command = input("Command: ")
    if command == "" or command == "help":
        print("Valid commands are: show, add, save, load, quit")
    elif command == "show":
        print(data)
    elif command == "add":
        key = input("Key: ")
        value = input("Value: ")
        if(key != ""):
            data[key] = value
            print("Assigned %s to key %s" % (value, key))
        else:
            print("Error: empty key.")
    elif command == "save":
        filename = input("Filename: ")
        f = io.open(filename, "wb")
        pickle.dump(data, f)
        f.close()
        print("Saved data to %s" % filename)
    elif command == "load":
        filename = input("Filename: ")
        f = io.open(filename, "rb")
        data = pickle.load(f)
        f.close()
        print("Loaded data from %s" % filename)
    elif command == "quit":
        break
    else:
        print("Unknown command.")

print("Goodbye.")

So, the program is only 30+ lines long but it usable, for some value of usable. Everything the program is missing are things that could be added by students. Maybe we will not add exception handling right away. But we could add a few "commands" to the list, like "new" or "remove". It could check if a file already exists and ask permission to overwrite it. It could remember the last file saved and have a "save" and a "save as" command.

OK, I wrote an anti-IDE rant some days ago, dissing NetBeans and its ilk and extolling the virtues of Vim as my primary code editor. Read that here, if you are curious. I took some liberties with the English language, for which I sincerely apologize to the queen of England. Somebody posted it on Reddit and it got tweeted and linked on Code Project. I found a bunch of comments needing moderation. Some were thoughtful, some vitriolic. However, one comment was absolutely hilarious:

Writing code in vim makes me hate life. I've written a large perl/bash/php system in it and wanted to kill myself nightly. Your article, while very accurate for some people, makes other developers throw up in their mouth. IDE's features like code-folding and boilerplate generation are there to help developers develop more rapidly, which is something that is very valuable in todays market. Sure, Java sucks, but when you don't have a choice, what are you gonna do? Write C# in notepad? I dont think so. If I had to write all my code in vim, and meet deadlines, I would blow my brains out. I love my Visual Studio. And for the record, no crashes, no instability, no hate. You may call me names, and say I'm not a real developer, but for RAD theres nothing like a well balanced IDE. That being said, Netbeans sucks donkey dong. Im a VS user.

Firstly, I took no offense at this comment. In fact, I loved it. Now, I think the commenter missed a couple points. I'm not suggesting people write C# in notepad. To be fair, I've spent years using Visual Studio as my professional, get-things-done IDE. It is pretty stable, and useful if you are developing Windows apps. I'm not developing Windows apps. Thank God. That would make me want to blow my brains out.

Admittedly, Vim just ain't for every developer. I've flirted with using it for all my work, but usually went crawling back to the big IDE's because of something I couldn't do without. Usually, I just didn't know how to do it right in Vim. But this time, the conversion is permanent. Yeah, it kind of sucks at first, but I just stuck with it until my proficiency surpassed what I could do in any pointy-clicky IDE. It didn't take as long as you might think.

All I am arguing for is choice and exploration. There are reasons that I don't develop in Java or C#, I don't want to. I work in a non-corporate setting and I don't write enterprisey code. I like it that way. It's not for everyone. Some folks like the grey cubicles, memos, meetings, harassment prevention classes, ID cards, office politics, etc. I've been there, done that. Life is too short. Pick the tools you want. However, know that a good number of software developers in the world use Vim or Emacs, not because they don't know about big, fancy IDE's, but because they can do more, faster with those tools. You can be a fantastic developer writing C# in Visual Studio or Java in Eclipse. You can also be a fantastic developer writing R on napkins or Fortran on punch cards for all I care.

Just know this, I close tickets. I write unit tests. I ship good, clean, unit-tested code. Yeah, I know, unit tests aren't perfect. If you have to pick a religion, you could do worse. I don't pair-program. God help me, I'll never understand how two people and one keyboard are more productive than two people and two keyboards, unless you can't motivate either of them to work otherwise. But, hey, if that's what you need to get through the day, find a consenting partner and pair-program to your heart's content.

5 days ago, I ordered a replacement LCD screen for Megan's netbook, a run-of-the-mill Gateway LT2032u machine. The screen had cracked due to an unfortunate fall. I was able to install the replacement in less than an hour, and it works perfectly. The netbook originally cost about $300 and the replacement screen was only $50. Small victories.

In other news, Opera 10.60 was released officially today. Opera is truly an awesome engineering feat. The supported operating system list is impressive: Windows, OS X, Linux (i386, x86-64, and PowerPC), FreeBSD (i386 and x86-64), and Solaris (SPARC and Intel). The FreeBSD'ers must be rejoicing. Not only is basically every modern operating system supported, but it is the fastest browser, even faster than Google's Chrome. I didn't believe it either, until I ran some benchmarks myself. It's got WebM video. Now that Firefox is getting beaten badly by 3 browsers in the speed category, the folks at Mozilla need to do some soul-searching. If the current Mozilla JavaScript engine (SpiderMonkey), which is descended directly from the first ever JavaScript interpreter created by Brendan Eich at Netscape, can't keep up, it should be replaced. Heck, Mozilla could grab V8, it's open source. It certainly wouldn't be a trivial task, maybe infeasible due to how deeply embedded in the code the current one is. But they have to do something.

The release of yet another super-fast browser is a big win for everyone. Internet Explorer is losing market share fast enough to make Microsoft actually want to compete, though IE 8 was such a spectacular failure that I have little faith in IE 9. The web is everything. Windows is still the dominant desktop OS, because that's what you get when you buy a computer. It doesn't much matter now, though. You could put someone in front of an Ubuntu desktop, they'll click the Firefox icon and be off and surfing in no time. The web is the great equalizer. Between Firefox, Chrome, and Opera, the operating system has become a commodity. Add Open Office and Google Docs into the mix and there is no reason that anyone couldn't use any operating system. Now, I prefer Linux as the perfect balance between usability and power. If I was a hardcore gamer, I would probably use Windows since it is the PC gaming operating system. I've even dabbled with Windows 7. It's not that bad--much better than Vista and finally an evolutionary step past XP.

Some people love OS X and I understand why. It is the smoothest, sexiest operating system with enough Unix cred to be cool for the developer crowd. I'm willing to trade in that sexiness for paying 1/3 as much for a computer and having a slightly more powerful, configurable operating system. OS X is also a bit too mouse-oriented for my taste.

Enough about operating systems. I want my Arm-powered Linux netbook already. When do I get that? Lenovo's got one in the works, called the Skylight, but it looks to be a bit pricey.