Compile FFmpeg on Ubuntu ¶

This guide supports Ubuntu 12.10 (Quantal Quetzal), Ubuntu 12.04 (Precise Pangolin), and Ubuntu 11.10 (Oneiric Ocelot). Separate guides are available for Ubuntu 10.04 (Lucid Lynx) and Ubuntu 8.04 (Hardy Heron). This guide will provide the latest FFmpeg code and enable several external encoding and decoding libraries:fdk-aac (AAC encoder), libfaac (AAC encoder), libmp3lame (MP3 encoder), libopencore-amr (AMR encoder/decoder), librtmp (for additional RTMP protocols), libtheora (Theora encoder), libvorbis (Vorbis encoder), libvpx (VP8 encoder/decoder), and libx264 (H.264 encoder). These are optional and may be omitted if desired. This guide will also install many filters, including the subtitles filter for hardcoding subtitles (see the filter list in the Filtering Guide).

Note: Copy and paste the whole code box for each step.

Preparation

Remove any existing packages:

sudo apt-get remove ffmpeg x264 libav-tools libvpx-dev libx264-dev yasm

Note: The multiverse repository must be enabled in order to install the libfaac-dev package. See  more details on adding repositories.

Get the dependencies (Ubuntu Desktop users):

sudo apt-get update
sudo apt-get -y install autoconf build-essential checkinstall git libass-dev libfaac-dev \
  libgpac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev \
  librtmp-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev \
  libx11-dev libxext-dev libxfixes-dev pkg-config texi2html zlib1g-dev

Get the dependencies (Ubuntu Server or headless users):

sudo apt-get update
sudo apt-get -y install autoconf build-essential checkinstall git libass-dev libfaac-dev \
  libgpac-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev librtmp-dev \
  libtheora-dev libtool libvorbis-dev pkg-config texi2html zlib1g-dev

Installation

Yasm

Yasm is an assembler and is recommended for x264 and FFmpeg.

cd
wget http://www.tortall.net/projects/yasm/releases/yasm-1.2.0.tar.gz
tar xzvf yasm-1.2.0.tar.gz
cd yasm-1.2.0
./configure
make
sudo checkinstall --pkgname=yasm --pkgversion="1.2.0" --backup=no \
  --deldoc=yes --fstrans=no --default

x264

H.264 video encoder. The following commands will get the current source files, compile, and install x264. See the x264 Encoding Guide for some usage examples.

cd
git clone --depth 1 git://git.videolan.org/x264
cd x264
./configure --enable-static
make
sudo checkinstall --pkgname=x264 --pkgversion="3:$(./version.sh | \
  awk -F'[" ]' '/POINT/{print $4"+git"$5}')" --backup=no --deldoc=yes \
  --fstrans=no --default

Note: You can download the nightly  x264 source snapshot as an alternative to using git.

fdk-aac

AAC audio encoder.

cd
git clone --depth 1 git://github.com/mstorsjo/fdk-aac.git
cd fdk-aac
autoreconf -fiv
./configure --disable-shared
make
sudo checkinstall --pkgname=fdk-aac --pkgversion="$(date +%Y%m%d%H%M)-git" --backup=no \
  --deldoc=yes --fstrans=no --default

Note: You can download a  fdk-aac source snapshot as an alternative to using git.

libvpx

VP8 video encoder and decoder.

cd
git clone --depth 1 http://git.chromium.org/webm/libvpx.git
cd libvpx
./configure --disable-examples --disable-unit-tests
make
sudo checkinstall --pkgname=libvpx --pkgversion="1:$(date +%Y%m%d%H%M)-git" --backup=no \
  --deldoc=yes --fstrans=no --default

Note: You can download a  libvpx source snapshot as an alternative to using git.

opus (optional)

Opus audio encoder and decoder. Add —enable-libopus to your ffmpeg ./configure line if you want to use this.

cd
git clone --depth 1 git://git.xiph.org/opus.git
cd opus
./autogen.sh
./configure --disable-shared
make
sudo checkinstall --pkgname=libopus --pkgversion="$(date +%Y%m%d%H%M)-git" --backup=no \
  --deldoc=yes --fstrans=no --default

FFmpeg

Note: Ubuntu Server users should remove —enable-x11grab from the following command:

cd
git clone --depth 1 git://source.ffmpeg.org/ffmpeg
cd ffmpeg
./configure --enable-gpl --enable-libass --enable-libfaac --enable-libfdk-aac --enable-libmp3lame \
  --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp --enable-libtheora \
  --enable-libvorbis --enable-libvpx --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3
make
sudo checkinstall --pkgname=ffmpeg --pkgversion="7:$(date +%Y%m%d%H%M)-git" --backup=no \
  --deldoc=yes --fstrans=no --default
hash -r

Note: You can download the nightly FFmpeg source snapshot as an alternative to using git.

Finish

Installation is now complete and FFmpeg is now ready for use. You can keep the x264, libvpx, and ffmpeg directories in your home directory if you plan on updating later. See Updating FFmpeg below for more details. Some optional steps are next followed by instructions on updating FFmpeg and finally instructions on reverting all changes made by this guide.

The cause for this is that the version of ffmpeg provided via the repos is out of date. To get the latest version, do the following:

Add an up-to-date repo:

sudo add-apt-repository ppa:jon-severinsson/ffmpeg

If you’re using Ubuntu 12.x, add the backports repo as well (substitute precise for your distro)

deb http://archive.ubuntu.com/ubuntu precise-backports main restricted universe multiverse

Replace the currently installed version with the one from the new repo

sudo apt-get remove ffmpeg 

sudo apt-get autoremove 

sudo apt-get update 

sudo apt-get install ffmpeg

(Source: kurennyy.blogspot.com)

Recently I’ve been working on a Rails application that supports subdomains. I’m using Devise for user authentication and need the user to choose a subdomain to use upon registration.

Similar to the 37signals applications, I want a single sign-on to be persistent across subdomains. Since I didn’t have a clue where to begin with subdomains, I followed this tutorial on my new Rails 3.1 beta 1 application. This tutorial worked like a charm and I omitted the friendly_id and tweaked a few things to my liking.

The gist of it is simple. Create a User model like you would normally do with Devise. You add a Subdomain model that is linked to the Users (in my case I only wanted a single subdomain per user). Configuring the routes is pretty simple as you can simply create a constraint that will match the root and fire it off to the right action and let the rest fall through.

The trick comes into sharing the session between domains. Browsers, of course, will separate out the cookies and store them by separated out by subdomain. What you want to do is edit your config/initializers/session_store.rb file to look like this

APPNAMEGOESHERE::Application.config.session_store :cookie_store, :key => '_tourlyapp_session', :domain => "lvh.me"

The trick here is the :domain option. What this does is sets the level of the TLD (top level domain) and tells Rails how long the domain is. The part you want to watch out for here is that if you set :domain => :all like is recommend in some places, it simply won’t work unless you’re using localhost. :all defaults to a TLD length of 1, which means if you’re testing with Pow (myapp.dev) it won’t work either because that is a TLD of length 2.

You might get weird things like halfway Devise sessions sharing, but only allowing you to create and destroy the session on the root domain. Using :all works great if you’re using localhost, but when I started using lvh.me:3000 for testing I had those problems (lvh.me stands for local vhost me and is a domain that simply points to localhost which makes for zero-config subdomain development. It’s super handy.).

The best option might be to comment out this line and put it into your individual environment configurations. This way you can keep things configured easily as the :all option. Once you’ve got your domain string added everything should work like a charm.

BONUS PROTIP: The normal route variables you see used end with _path. These don’t include the domain and therefore ignore the :subdomain option you pass into them. url_for, on the other hand, does support subdomains so you should get into the habit of using root_url instead of root_path and so on.

(Source: excid3.com)

Few days ago I was working on a fairly typical web application and I faced the challenge of implementing a fairly typical web application feature - file uploads. It was the first time I was implementing file uploads with Node (and Express) and I did what anyone else would do - I googled it.

Unfortunately all the articles / posts out there are either outdated, too complex or plain wrong. So I did the next most obvious thing - post a question on the mailing list. As always Mr. Holowaychuk was incredibly quick to respond. His answer lead me to do what I should have done in the first place - read the docs.

The upload form

This is the most obvious part of the challenge. You’re probably familiar with this already. Anyway, for the sake of completeness of this article, here it is.

You will need a form in your browser for the file upload. I use Jade to generate my HTML and here how it looks:

form(action="...", method="post", enctype="multipart/form-data")
  input(type="file", name="displayImage")

The form.action will point to a route that handles the file upload. More below.

Accessing the uploaded file

If you’re using recents versions of Node and Express, file uploads are a piece of cake. And I’ll back this claim but before we go any further make sure you’re familiar with routes, requests and responses in Express.

Okay, now let’s justify the “piece of cake” claim. In our file upload route, the req parameter has req.filesavailable. Here’s an example of what the req.files would contain:

{
  displayImage: {
    size: 11885,
    path: '/tmp/1574bb60b4f7e0211fd9ab48f932f3ab',
    name: 'avatar.png',
    type: 'image/png',
    lastModifiedDate: Sun, 05 Feb 2012 05:31:09 GMT,
    _writeStream: {
      path: '/tmp/1574bb60b4f7e0211fd9ab48f932f3ab',
      fd: 14,
      writable: false,
      flags: 'w',
      encoding: 'binary',
      mode: 438,
      bytesWritten: 11885,
      busy: false,
      _queue: [],
      drainable: true
    },
    length: [Getter],
    filename: [Getter],
    mime: [Getter]
  }
}

In the req.files object above, the property displayImage is the name of the file field in your HTML form andreq.files will contain one property each for every valid HTML file form field.

The file object contains the type, size and name properties for your server side validations.

Saving the uploaded file

Assuming the file is valid, you use the path property for the next step. The path would typically contain a location in the tmp folder. Your application logic could either require you to access the contents of the file or simply move the uploaded file to another location.

fs.readFile(req.files.displayImage.path, function (err, data) {
  // ...
  var newPath = __dirname + "/uploads/uploadedFileName";
  fs.writeFile(newPath, data, function (err) {
    res.redirect("back");
  });
});

In the fs.readFile callback, we have the data parameter through which we can access the contents of the file. The example above is taken from an application that needed to modify the file and save it in a new location. Thus fs.writeFile is used to write data to the newPath.

If your app needs to simply move the uploaded file without modifying the contents fs.rename can be used as more simpler option.

That’s all there is to it. I’ve done file uploads in many server side languages including Python, Java, Scala and PHP and I don’t think its ever been this simple. So much for JavaScript being labeled as an inferior server side language.

(Source: howtonode.org)

So you like Node.js? You want to deploy it?

If I heard two “Yes“‘s, then you are in the some boat as me, and being in that boat feels really really vulnerable. Like the kind of vulnerable you would feel if you were trapped in a cage with lions. And here is why:

• If Node.js decides to crash, you are screwed.
• If the above isn’t enough for you, then you may need to reconsider.

There are two well-known technologies that can save us from this mess, and you’d better believe we’re going to use them!

Problems

The first problem we will get thrown by, is the fact that we cannot run Node.js as a daemon. A daemon, for the unaware, is a child process that spawns from a process, leaving the parent to die. Tragic story I know, but this allows things to run in the background. But why is this a problem? Well if Kevin’s blog post isn’t enough for you, it essentially allows one to separate node from any form of interface, meaning terminal doesn’t have stay open all day. I highly recommend you pause now and read Kevin’s material, as it will expand more on daemonizing the node process.

upstart

As Kevin stated in his blog, the first tool we are going to look at is upstart, which will allow us to:

• Run Node.js as a daemon
• Provide an easy set of commands for stop / starting our Node.js application

Most linux distributions that have a decent package manager which will allow you to install upstart the easy way. On debian systems this is usually:

#!sh
sudo apt-get install upstart

If you’re running the latest Ubuntu, you’ve got it built in already.

Otherwise you will need to configure and compile from source, and this blog post will not go off topic! So we resume…

We now will want to configure upstart, and I am shamelessly borrowing Kevin’s example:

#!upstart
description "node.js server"
author      "joe"

start on startup
stop on shutdown

script
    export HOME="/root"

    echo $$ > /var/run/yourprogram.pid
    exec sudo -u username /usr/local/bin/node /where/yourprogram.js >> /var/log/yourprogram.sys.log 2>&1
end script

pre-start script
    # Date format same as (new Date()).toISOString() for consistency
    echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/yourprogram.sys.log
end script

pre-stop script
    rm /var/run/yourprogram.pid
    echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/yourprogram.sys.log
end script

You will need to replace username with the user you want to run node as, /where/yourprogram.js with the location of your application, /var/run/yourprogram.pid with your program’s pid file and/var/log/yourprogram.sys.log with the location of your log file. You can then save this file to/etc/init/yourprogram.conf for later use. (Dont’t forget to make it executable!) If you are using an older linux distribution, you may need to save the file to /etc/event.d/yourprogram

Using your program is now a cinch:

#!sh
start yourprogram
stop yourprogram

And now node will automatically start at boot and log output to /var/log/node.log. But I assumed you read all that on Kevin’s blog, right? Moving on…

The real problem

Turning your application into a daemon isn’t enough. A daemon can still crash, and those lions are getting awfully close. We need a tool that keeps an eye out for any falls our node instances may have. When something crashes our server, we need that tool to take evasive action. Also that tool should be capable of expanding its reach to any other services our app may need; such as databases and nginx instances. Thankfully this isn’t taken lightly by most, and several helpful tools that fit our description do exist.

monit

Now that we have our application in a easy to manage form, we need to look at the real issue we are facing. What happens when Node.js crashes? Fortunately for us mortals someone has done most of the hard work for us, and blessed us with the monit utility. Essentially monit is a monitoring tool, which you configure tests that will be evaluated at certain intervals. If one of the tests fails, then it will take action depending on the rules you assign to it.

I’m not going to tell you how to install it, their website has plenty on information for that, but here instead is an example config file designed for our upstart node daemon will made earlier:

#!monit
set logfile /var/log/monit.log

check process nodejs with pidfile "/var/run/yourprogram.pid"
    start program = "/sbin/start yourprogram"
    stop program  = "/sbin/stop yourprogram"
    if failed port 8000 protocol HTTP
        request /
        with timeout 10 seconds
        then restart

You can save this in /etc/monit/monitrc. Here is the break down:

set logfile /var/log/monit.log

check process nodejs with pidfile "/var/run/yourprogram.pid"

This will tell monit to log all output to /var/log/monit.log, and it also gives our node instance a name and location. I am assuming monit will be running on the same machine as your node app, so we will need to listen on 127.0.0.1 . If you wanted to run monit on another box, you most certainly can, in fact I recommend have multiple instances of monit running in different locations. You just have to ensure that monit is listening on the correct IP address, otherwise monit is rendered useless. The next part is the vital part, which defines how we will test for failures:

#!monit
start program = "/sbin/start yourprogram"
stop program  = "/sbin/stop yourprogram"
if failed port 8000 protocol HTTP
    request /
    with timeout 10 seconds
    then restart

The first two lines should be self-explanatory, this defines how monit will start and stop your application. You will need to specify an absolute path to upstart’s start and stop utilities, while suffixing your application name as an argument.

The third line is the crux of monit’s usefulness. If we were running our application on port 8000, serving through the HTTP protocol, then this would apply. Monit will perform an analysis on the specified port and protocol, and if its routines discover that something is not right, it will execute the next few lines. Monit has lots of different options for dealing with service failures, such as sending e-mails and restarting servers. In this case we are going to do a simple request to the root of the local domain, and if 10 seconds pass without the expected response, monit will restart the application.

Now all that is left, is to start your application, then set monit off to do its tedious task of saving the world from crashing servers.

#!monit
sudo start yourprogram
monit -d 60 -c /etc/monit/monitrc

Setting the -d 60 flag tells monit to check against your configuration every 60 seconds. I recommend setting this to the same time as any response timeouts you may have installed. You have now passed monit 101! Easy, huh?

Monit’s useful-ness doesn’t hit a brick wall there either, monit can be extended further to monitor the other services your web application relies upon. This may range from databases to nginx instances. Their website has many more examples and configurations, and even more again can be found littered over the internet.

(Source: howtonode.org)

I recently completed Michael Hartl’s excellent online book; a Ruby on Rails tutorial that allows you to learn via doing. I told one of my mates about it and convinced him to do the same.

I use OSX, so everything worked swimmingly for me. Unfortunately, I had a really tough time helping my mate deploy ruby and rails to a fresh Ubuntu installation, so I sent him on his way to try again another time.

Firing up a Virtual Machine later in the evening (ie now, whilst I’m typing this), I actually received the same issues as I did on his laptop – this was a fresh Ubuntu 12.04 LTS install!

And so, with that in mind, I sought to resolve the issue. If you’re also experiencing issues with zlib, openssl or other missing packages, here is my winning formula!

1. First, I imploded my existing RVM install, this gave me a fresh start rvm implode
2. I installed RVM (make sure you have git-core and curl installed before you do this [use apt-get]) curl -L get.rvm.io | bash -s stable and thensource ~/.rvm/scripts/rvm based on instructions at rvm.io
3. I installed zlib manually via rvm  rvm pkg install zlib
4. I installed openssl manually via rvm  rvm pkg install openssl
5. I installed ruby with the following args rvm reinstall 1.9.3 --with-openssl-dir=$rvm_path/usr
6. I installed some additional packages  sudo apt-get install libxslt-dev libxml2-dev libsqlite3-dev as per Michael’s recommendation
7. I installed rails gem install rails -v 3.2.3

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:chris-lea/node.js
sudo apt-get update
sudo apt-get install nodejs npm

(Source: jeremytennant.com)

Hello again!

This is more for my own knowledge than anything, but I figured others may be able to use it as well.

This post assumes you already have Homebrew and RVM installed (RVM has a native OS X GUI tool as well that can install RVM for you, and it can make things easier for those that are not so comfortable with the Terminal, called JewelryBox).

Once these two things are installed, we’re ready to move forward.

Some people may encounter issues with improper permissions and ownership on the /usr/local/include and /usr/local/lib directories when using Homebrew. To fix this, you can execute the following exactly as it is (DON’T replace $USER with anything):

sudo chgrp wheel /usr/local/

sudo chown -R $USER /usr/local/

As of Xcode 4.2, gcc is no longer installed, but it is required for compiling ruby when installing via RVM. As of Xcode 4.4 (released alongside Mountain Lion), UNIX command line tools are no longer installed with Xcode by default either. To remedy this, open Xcode, go to the Preferences Menu, click the Downloads tab, and press the Install button for the “Command Line Tools” item in the list. Any other option in the list is totally up to you to decide if you’d like to install it or not. (Screenshot below shows where the menu, tab, and button are.)

Next, according to Homebrew’s own wiki, you’ll need to install a binary gcc 4.2 formula made available via Homebrew-dupes by running the following:

brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb

Now you can install Ruby 1.9.2 via RVM:

rvm install 1.9.2

Make Ruby 1.9.2 your system default (optional):

rvm use 1.9.2 —default

Install the latest version of the Rails (Rails 3.2.7 at this time) and bundler gems:

RAILS:

A.) gem install rails

(or if you prefer without the docs to save some time do this instead):

B.) gem install rails —no-rdoc —no-ri

BUNDLER:

gem install bundler

Voila, ready to go! The only thing left is to install the gem of your choice for database usage.

The one thing people always seem to overlook, but should be the first thing anyone should do when setting up a new server is configure their firewall.

Ubuntu 10.10 comes bundled with UFW (Uncomplicated Firewall), which is a terminal-based firewall application. To manage the firewall and its configuration, you’ll need to understand a few basic terminal commands. However, if your server is also a development or personal machine with a Desktop GUI installed, like GNOME, the alternative (and my personal choice in that situation) is to manage the firewall using a graphical interface. You can do so by installing Gufw (Graphical Uncomplicated Firewall). Installation can be done the usual way with:

     sudo apt-get install gufw

NOTE: When installing Gufw, UFW is not enabled by default. You must explicitly enable it through the graphical control interface.

The graphical interface can be accessed by going to System -> Administration -> Firewall Configuration. From there, enable the firewall by checking the box labeled “Enabled”, under the “Actual Status” title, and adding/removing an exception to the firewall rules is pretty straight forward. It even provides you with presets when adding a new rule for common services, such as Samba, NFS, HTTP, FTP, SSH, VPN, etc.

Testing the Firewall

To test the firewall, you have two options:

1. You can utilize a popular application called nmap. This is best done from a second linux-based machine.
2. You can take advantage of online firewall testing services, such as https://www.securitymetrics.com/portscan.adp

If you choose to use nmap, installation on Ubuntu is straightforward with the command:

     sudo apt-get install nmap

Run nmap with the following command to view a list of currently open ports (view nmap’s options summary):

     nmap -vAPN 192.168.1.100

NOTE: Substitute 192.168.1.100 with the IP address of your server

Reference:  The Official Ubuntu Documentation

Many months ago, last summer to be exact, I set out to build a home server for myself. As the owner of a small development company, having servers is nothing new for me. I build, upgrade, downgrade, resize, and dismantle them all the time, both on dedicated boxes and the cloud. My last server was a small Early 2009 Mac Mini I had upgraded. Now, don’t get me wrong, I love my Macs as much as the next guy, and OS X Server ran beautifully without a hitch, but it was just a bit underpowered at times for my needs. It seemed more suited for development work than anything else. However, when it comes to development, I’m usually tied to my 2009 Macbook Pro (purchased it just before the Arrandale update for the 2010 lineup..dammit).

My MBP easily beats out my Mac Mini in compile times and just overall smoothness, not to mention I’m a trackpad junkie ever since I got the thing. As a result, my year old Mac Mini just sat there by the wayside, not really being used for anything except streaming video to my TV (via the DVI to HDMI adapter). That held true, until I got my 2nd gen Apple TV to replace it and traded it for a friend’s laptop. Earlier in the year, knowing that the Mini would eventually be gone, I set out to build a custom rig with a sub-$1,000 budget to meet and exceed my required server specifications, which led to the following build:

• ASUS P7P55 LX Motherboard
• Intel Core i5-760 Quad Core
• G. Skill 4GB DDR3 1333MHz Ram
• 50GB OCZ Vertex 2 SSD as OS Boot Drive (285MB/s Read, 275MB/s Write)
• 1TB WD Caviar Black SATA 6Gb/s as Storage Drive (117MB/s Read, 118 MB/s Write)
• nVidia GeForce GT220 w/1GB DDR3 Memory
• Samsung DVD Burner Combo-Drive
• ASUS U3S6 SATA 6 and USB 3 Add-on Card
• Rosewill Challenger Case

I know, I know, the wiring is not pretty at all. Blame it on the failure of the original modular power supply unit…and laziness.

I was super happy with my build, and in my infinite wisdom decided to install Windows 7 x64 Ultimate (I have no personal Windows machines of my own, only my immediate family does) and install VMWare Player to have a few virtual servers running Ubuntu 10.04. So, I did exactly that, thinking Windows was the only way I could take full advantage of the machine’s power. This was my first mistake. I should have known that when I decided on Windows, that only bad things would happen. It did not take long for me to realize how quickly this would become true.

After a short while of promising myself that I would not congest the already measly 50GB of SSD space with unnecessary apps, tons of programs from my pre-Mac days began to slowly creep onto my machine. They were installed one by one while my virtual servers slowly took a pounding, being deprived of resources and sometimes even being shut down completely just to free up resources for my superfluous programs.

The first to show up was Steam; my beloved Steam from my high school and early college days. Ah, what fond memories..fond, space-hungry memories. Once Steam was installed, that was the beginning of the end. Counterstrike, Counterstrike: Source, Team Fortress 2, and quite a few others made their way into my Library of purchased and downloaded games. Pretty soon, my virtual servers were constantly nowhere to be found, completely shut down, with my video card running at full steam playing Source with almost all graphic settings maxed out. With all of these games came the unfortunate consequence of my poor SSD getting bogged down to 1GB of free space very quickly. The second issue was that a lot of the tools I use for development are Linux/Mac-based.

WTF! If my tools are all non-Windows based..why the hell am I running Windows?

The answer is simple, I had fooled myself into thinking that Windows was the better option for a server, but in reality, I knew from the second I made that decision that it would end up becoming a web-surfing, game-playing personal rig, rather than the web development machine and web/file/print/VPN/git server it was built to be. This all leads up to today, when I was in the middle of a KICK-ASS Counterstrike Source match on Dust 2 as a CT and was switched out of my window by a Windows alert, letting me know that I had less than 1GB of free disk space on my hard drive. I was completely not expecting that, and as a result..I just downloaded Ubuntu 10.10 to completely wipe my drive and start with a clean slate.

The Final Result

I am now typing this post on my newly formatted Home Server/Development Machine. The solid state drive is screaming with 39GB free, apps are flying opened and closed without so much as a pause, Ubuntu boots in less than 20 seconds, and I’m using 1/4 of the ram I was under Windows. To top it all off, I went with a fully clean install, so now I have a shit load of servers and libraries to reinstall and configure..gee, my favorite part (/sarcasm). Fuck…okay, who wants to play some Counterstrike?