Desktop OCD (Why I switched from a 17″ Macbook Pro, to an 11″ Macbook Air)

IMG_1527Recently my employer was extremely kind enough to spoil me yet again and replace a late 2010 17″ Macbook Pro I was using with an 11″ 2013 Haswell Macbook Air.  It’s taken some time for me to define what a laptop should be, and have recently come to the conclusion that a laptop should be light, with form factor conventions that make it wieldy, convenient to take from one location to the next, and facilitate your work and entertainment on the go.

Over the years it’s taken me some time to realize what I need out a workstation, and laptop.  My original school of thought for the past 12 years was that I needed an extremely high resolution for desktop real estate whether it be a workstation or laptop. This was partly because I was battling with what some may consider mild OCD with my workspace and workflow in relation to my desktop scheme, and because I still wanted to play Blizzard and Steam games.  I believed that my desktop application placement had to be perfect, ranging from e-mail client, to terminal, and various other applications.  I was also determined to cram every regularly used application in tight order onto one screen, which is why I originally thought that a 17″ Macbook Pro for my work on the go was a good idea.

By now it should be pretty apparent that I was very slow to adopt multiple virtual desktops with what OSX implemented in Spaces (something that I was already aware of for years with Linux GUI desktop managers) some revisions of Macintosh exotic cat named operating systems ago.  When I started dealing with more Windows administration and VMWare for my job, I found that using multiple virtual desktops was a far more efficient way to work.  Finally, realization set in that it’s okay to have a “messy” desktop and in a sense was relieved by this.  After this minor technical enlightenment, I became increasingly more frustrated lugging around a 17″ Macbook Pro (#firstworldproblems).  It got to the point where I didn’t want to use it in any situation other than sitting at a desk.  Enter the Macbook Air.

Since I’ve been using the Macbook Air for the past 2 weeks, I have realized how well this ultrabook works for me and how impractical the 17″ Macbook Pro was.  I actually enjoy taking the Air to work, and meetings now, where as before I preferred to keep the 17″ Macbook Pro on my dining table, or desk and rarely traveled with it.  As for games, I found that I was hardly gaming after a while.  The other thing that I’m really impressed with is battery life.  9 hours of usage is very impressive compared to what I was seeing before with the Pro.

I guess the lesson learned here on a somewhat deeper level is to practice sensibility more often.  This is something I think I’m still struggling with and striving to be better at in my mid-30’s.


Cleanly uninstalling Google Chrome in OSX

So being the big nerd I am, I enjoy playing Fantasy Football.  The other day I noticed that Chrome was having an issue rendering projections, scores, and notes from player card previews on

Since I wasn’t really in the mood to debug, I decided to just cleanly remove Chrome to resolve my issue.  If you do feel like debugging you can do so via command arguments:

In run the following:

open /Applications/Google\ --args --enable-logging --v=1

At any rate, after removing the following files in, I was back to Fantasy Football browsing insanity:

rm -r /Applications/Google\
rm -r ~/Library/Application\ Support/Google/Chrome/
rm ~/Library/Preferences/
rm ~/Library/Preferences/
rm ~/Library/Preferences/Google\ Chrome.plist
rm ~/Library/Preferences/Google\ Chrome.plist.lockfile
rm ~/Library/Saved Application State/
rm ~/Library/Application\ Support/CrashReporter/Google\ Chrome*.plist
rm ~/Library/Google/GoogleSoftwareUpdate/Actives/
rm -r ~/Library/Speech/Speakable\ Items/Application\ Speakable\ Items/Google\ Chrome/

OSX & Linux Disk Benchmarking

As a SysAdmin, you’ll need to benchmark disk performance from time to time, or rather just gloat that your system’s drive is better than your buddy’s. In my particular case, I have an existing need to quantify performance metrics on my work macbook pro’s disk speed with Symantec PGP (don’t get me started on this product), without it, and with Apple FileVault in place of it.

Perusing the web I came across a good article from that assisted me with my disk benchmark testing.  This can apply to OSX and most Linux systems as well.

To test a system’s write speed, I used the following command from a terminal window:

time dd if=/dev/zero bs=1024k of=speedtest count=1024

Output from my work iMac w/SSD:

1024+0 records in
1024+0 records out
1073741824 bytes transferred in 8.948791 secs (119987362 bytes/sec)

real 0m8.954s
user 0m0.001s
sys 0m0.413s

The bytes per seconds number when converted to Megabytes equates to 114.42887 Mb per second.

To test the read speed of my disk, I ran the following from

dd if=speedtest bs=1024k of=/dev/null count=1024


1024+0 records in
1024+0 records out
1073741824 bytes transferred in 0.145955 secs (7356659197 bytes/sec)

So this is around 7016 Mb (6.8 Gb) per second with some rounding.  Based on the above output results, my work iMac w/ SSD can write at 114 Mb/s, and read at 6.8Gb/s.

When I get around to testing on my work laptop, these commands should give me good data metrics.

As far as bytes to Mb/Gb/etc conversioning goes, you can use google conversion web tools, or the “units” command on a Linux host if available.  There are several alternatives you can use as well.

Units Linux command sample for reference:

units –terse “119987362 bytes” “MiB”



OSX :: CPU & Core Counting

A while back ago I blogged about  rudimentary Linux cpu and core lookups.  I figured I’d follow up with how you do this in OSX via “system_profiler SPHardwareDataType” as well.

zissou:~ jrad$ system_profiler SPHardwareDataType

Hardware Overview:
Model Name: iMac
 Model Identifier: iMac12,2
 Processor Name: Intel Core i7
 Processor Speed: 3.4 GHz
 Number of Processors: 1
 Total Number of Cores: 4
 L2 Cache (per Core): 256 KB
 L3 Cache: 8 MB
 Memory: 8 GB
 Boot ROM Version: IM121.0047.B1F
 SMC Version (system): 1.72f2
 Serial Number (system): D25J10LPDHJW
 Hardware UUID: 813A5897-1248-5460-84F6-062AE27929A7

Adding color to your bash prompt

As a big mac user, one of my long time complaints have always been about color in my bash shell not translating over to a Linux host I’m ssh’ing into (predominantly CentOS/RHEL hosts).  A work around I’ve found to address this was to edit my .bashrc on linux systems I use as follows:

export LS_OPTIONS=’–color=auto’
eval `dircolors`
alias ls=’ls $LS_OPTIONS’

If you want color in your mac terminal you can add the following lines to your .bash_profile under your home directory in /Users (e.g. /Users/jdoe).

For dark terminal theme users:

export CLICOLOR=1
export LSCOLORS=GxFxCxDxBxegedabagaced

For light terminal theme users:

export CLICOLOR=1
export LSCOLORS=ExFxBxDxCxegedabagacad

Special thanks and credit to OSX Daily for the color OSX Terminal tips.


So this above is all fine and dandy, but I’ve found that declaring terminal type as ‘terminal-color’ a better option for me.

SSH Tools :: Keychain

If you are a sysadmin that manages Linux systems, you’ve probably found that using ssh keys and keychain a must have.  If not, here are ways you can get setup.

CentOS/RHEL users can use rpmforge’s software repository to yum install keychain as opposed to building it themselves.  The CentOS wiki has very easy to follow documentation on how to do this.

For OSX, this is a pretty straight forward install from Funtoo’s keychain wiki page, with a .bash_profile update to make life easier for you.

After you leverage rpmforge’s software repo and install keychain, you will notice a .keychain directory in your home directory.  Generate a key for yourself via ssh-keygen.  You can specify key types as well (e.g. ssh-keygen -t dsa, the default generates rsa).

Next, you will need to copy your .ssh/ key values over to a host you want to leverage ssh keys, and keychain with.

Manual edit/OSX solution:

Edit .ssh/authorized_keys on the remote host with your key (e.g. rsync -av –progress remotehost.fqdn:/home/user/.ssh/, then cat >> authorized_keys in the your .ssh directory)

On Linux simply utilize ssh-copy-id remotehost.fqdn.

OSX users can edit as noted above, or can create their own ssh-copy-id script.  You can also try trusting bastardized OSX ssh-copy-id scripts from the web.  Be sure to scour the code at your own risk if you decide to go this route.

Once your keys are setup, we can go ahead and start utilizing keychain.

keychain -Q –ignore-missing –nogui –timeout  ~/.ssh/id_rsa

  • –ignore-missing doesn’t warn if some keys can’t be found.  This is useful if you have a shared .bash_profile and your keys aren’t available on every machine keychain is run against.  
  • –nogui doesn’t honor SSH_ASKPASS, if it is set, it will cause the ssh-add to prompt on the terminal instead of any graphical program.  
  • -Q/–quick will take any existing ssh-agent process and use it.  

You can explore additional options in the keychain man pages.

Personally, I prefer using an alias in my .bashrc/.bash_profile:

alias keychain=’keychain -Q –ignore-missing –nogui –timeout 86400 ~/.ssh/id_dsa ; . ~/.keychain/myhostname.fqdn-sh’.

The funtoo keychain wiki page suggests updating your .bashrc/.bash_profile with eval:

eval `keychain –eval –agents ssh id_dsa`

For OSX:

eval `keychain –eval –agents ssh –inherit any id_dsa`

Make sure to reference id_rsa if it is the key type you generated.

Now that you’re all setup, source your .bashrc or .bash_profile to finalize everything.  You can now start ssh’ing to hosts you have your keys setup on without a password or passphrase.