Move to the Dark Side

I have officially moved my blog away from to my own website:, which eventually will host not only my blog, but also my teaching philosophy, CV and other professional- related tidbits. I hope that everyone will follow me over to the dark-side as I continue to write about education, technology and talking cows. I would especially like to hear feedback on my latest post (inspired by the likes of Janet Murray and Alfred Whitehead), but since I haven’t set up a commenting system yet, please respond via your own blog, a tweet, or an email directly to me!

And Now You’re an Anstronaut: Open Source Treks to The Final Frontier

There have been a couple of blog posts recently referencing the recent switch NASA made from Windows to Debian 6, a GNU/Linux distribution, as the OS running on the laptops abord the International Space Station. It’s worth noting that Linux is no stranger to the ISS, as it has been a part of ground control operations since the beginning.

The reasons for the space-side switch are quoted as

…we needed an operating system that was stable and reliable — one that would give us in-house control. So if we needed to patch, adjust, or adapt, we could.

This is satisfying to many Open Source/Linux fans in it’s own right: a collaborative open source project has once again proved itself more stable and reliable for the (relatively) extrodinary conditions of low Earth orbit than a product produced by a major software giant. Plus one for open source collaboration and peer networks!

But theres another reason to be excited. And it’s a reason that would not necessarily applied (mostly) to, say, Apple fanatics had NASA decided to switch to OS X instead of Debian. And that reason has to do with the collaborative nature of the open source movement, codified in many open source licenses under which the software is released. Linux, and the GNU tools, which together make up a fully functional operating system, are released under the GNU General Public License. Unlike many licenses used for commersial software, the GPL esures that software licenses under its terms remains free for users to use,modify and redistribute. There are certainly some strong criticisms and ongoing debate regarding some key aspects of the GPL, especially version 3, the point of contention mostly lies in what is popularly called the “viral” effect of the license: that modified and derived work must also be released under the same license. The GPL might not be appropriate for every developer and every project, but it codifies the spirit of open source software in a way that is agreeable with many developers and users.

So what does this all mean in terms of NASA’s move? We already know that they chose GNU/Linux for its reliability and stability over alternatives, but that doesn’t mean it’s completely bug free, or will always work perfectly with every piece of hardware, which after all is another reason for the switch: no OS will be completely bug free or always work with all hardware, but at least Debian gives NASA the flexibility of making improvements themselves. And there in lies the reason for excitement. While there is no requirement that NASA redistribute their own modified versions of the software, there is no reason to assume they wouldn’t in most cases, and if they do, it will be redistributed under the same license. It’s certainly realistic to expect they will be directing a lot of attention to making the Linux kernel, and the GNU tools packaged with Debian even more stable and more reliable, and those improvements will make their way back into the general distributions that we all use. This means better hardware support for all GNU/Linux users in the future!

And of course it works both ways. Any bug fixes you make and redistribute may make their way back to the ISS, transforming humanity’s thirst for exploring “the final frontier” into a truly collaborative and global endeavor.

Mac GNU/Linux install, i3-wm setup & usage, homebrew, iTerm 2, & other thoughts.

Hello everyone!

So, the semester has had a fair amount of time pass and I decided to finally get a post in about a good amount of things I’ve experienced so far in the class and what not. Alright, so let’s get this started:

Installing GNU/Linux on it’s own partition along side Mac OS X Mountain Lion 10.8.2. Goodness, all I have to say about this is that it was pretty terrible getting things worked out. All the blame is able to be aimed at the almost infinite amount of incorrect and outdated “documentation” there is in a google search. The first time, after a couple tries and trying to tweak various things to get the Linux boot to work or trying blah blah blah to make blah work, I had to ultimately completely restore my Mac from a Time Capsule backup. I upgraded the harddrive in my computer so it was basically going to have to restore around 400GB of stuff back from this time capsule back up so that took about 24 hours. Ha, good start right? This was after screwing around with this first set up terribleness for about 4 hours. This first round of terribleness was caused by something I totally knew about already but had forgotten about at the time making it much more terrible haha. And this was the fact that there is a “security” feature for Mac’s that doesn’t let you boot anything or install anything from bootable devices or CDs if they are connected via a USB port. Just use the CD drive you say? Well, I took out my CD drive to have another HDD installed. So, how did I get GNU/Linux installed? Yeah, you got it. I had to take out the extra HDD, put back in the CD drive, install it to the partition on my original HDD, take the CD drive back out, put back in the extra HDD, and then use my computer like normal. What a mess! But that isn’t the half of it! The first time I did this, I messed up the install. Basically, I think it came down to either you cannot have a /sda/boot partition because the installer will try and write the MBR there AND/OR you CANNOT let the GNU/Linux install write the MBR to Mac’s boot record whatever because it’s a different type of boot record that is called EFI so it will mess things up AND/OR you have to, for sure, write that GNU/Linux MBR to the ROOT ( / ) directory or your life will end instantly AND/OR the ROOT ( / ) has to be the first after all your Mac (and bootcamp Windows install if you were triple booting) so it can see that boot record you installed to that ROOT partition and load up GRUB (or LILO or whatever you decided to use) and load up your GNU/Linux install. Gee, that all seems really simple, doesn’t it? Yeah, not at all. I eventually got it all installed after at least 3 days total of screwing around. Brutally… fun…?

So, wow, that was great! I then had it going in class with mostly everything I needed installed and wanted to switch from the windows manager that came with my install and use i3 (which if you don’t know what i3 is, it’s the windows manager that Darren uses on his GNU/Linux install on his Mac so take a look at that in class). i3 is pretty much the definition of useful and productive. Pretty much very little to no mouse usage, relatively simple hot keys, window management made easy, great stuff. Well, after I first got it installed, I had no idea how to open a terminal window haha. The mouse does nothing on the desktop and there are no menus or anything available (which is fine because that’s the point) but I could not figure it out after 5 minutes so I eventually ended up having to google it from my iPhone haha. OKAY! Got it! mod-return. Mod is whatever key you decided to set it at when you first start and configure i3. Usually, it’s the windows / command key or the alt key. Those are the two most popular. I continue to play around with this and do the first homework assignment on this install. Only a few things that aren’t configured that I need like how to make the laptop go to sleep when I shut the lid, some things about the scroll pad that do some behavior that is goofy like scrolling really fast, things like that. But overall, I got it going nicely. It is still a little annoying having to reboot to do linux homework or what not.

This is where homebrew comes in. On the Mac side, there are a few popular community supported equivalents of yum, apt-get, emerge, etc aka package managers. There is Mac Ports but I’ve used that before and it’s the definition of pain. The more logical, popular, and less painful one is homebrew. Homebrew is awesome. Just like “apt-get install blah” you can do “brew install blah” and it will more than likely have a Mac ported version of the things we have in Unix class. And this allows me to do a few things I couldn’t on my other partition, namely listen to music (I could have configured a music player on my other install but iTunes has everything already together since I’ve been on my Mac side longer), not have to reboot, learn to navigate my computer with the terminal instead of the Finder, etc. So, I eventually got everything set up here all easy (an hour tops I think) and got connected to the IRC server with mosh / ssh and tmux with a little help from Darren after class and bam, I’m pretty much golden!

Darren suggested I check out iTerm 2 which is a better Terminal emulator than the Mac terminal because it adds some slick features. So I did. He wasn’t kidding. iTerm 2 is awesome. I love it. Better hot keys, better usage, plays better with weechat and IRC, just better. So now I leave iTerm 2 full screened and try and basically play in that window more than I do in my other desktop windows essentially making the iTerm 2 terminal my home stomping group over using my mouse to click around. I can’t live in there forever, of course. I have to write blog posts, check scholar, Skype, iTunes, etc, but that’s much less Finder usage which means I’m more efficient. Finder usage is equivalent to slow.

I was going to have another section on “other thoughts” but I think I’ve written more than enough and tortured anyone actually reading this long enough! I will say this though: bash programming is rough. Until next time everyone, stay awesome.

-Mattie (pengii23)
Currently listening to: “Gravel (Original Mix)” by Feed Me

What a great class, amirite!?

Ok, so some of you may not agree (yet) but if you know what’s good for you, you will soon enough! There is nothing better than Unix class, and honest to goodness, there has not been a better version of this class than the one we are currently receiving! I’ve taken this class years ago and dropped it due to too many credits and needing to relieve some stress. So what, you say? A legitimate response. Well, had I been in your position and learning all of which we have already learning as a sophomore or hell, anyone younger than my age and class, I would’ve been much better off in almost all my classes in the future. I can say that for a fact. I love this class right now. I know a lot of what we are learning, but that makes me excited for you all! I love seeing that the things I learned all during my co-op experiences are being taught in classes! I love that so much because you all will be able to take more advantage of your co-op and internship experiences and not learn things like git or GNU/Linux generics, but rather, learn all the specialties the company has to over you. I cannot wait to see what you all do in the future. But hey, I will also be the guy keeping you on your toes because I still know some things you don’t. If you want to know more, you now know where to find me.

Well. until next time everyone, stay awesome.

Mattie, out.

Current Tune (Song by Artist): “Wait (The Killabits Remix)” by Adventure Club && Father Said (ft. Skrillex)” by 12th Planet
Current Preferred Language: Python
Current Fun: Making some fun tunes with Ableton Suite 8 :D and blogging with

Semester in Review

Well, as I’m about 6 hours in* into a 14 hour bus+train journey to Massachusetts I figured this would be a good time to reflect and respond to the past semester which seems to have flown bye.

The Blogs

I really enjoyed the blog assignment. Even though I wasn’t able to write a reply to every post I felt a lot more in sync with how the class as a whole was progressing. When there was confusion or frustration regarding a particular assignment, or just towards the class in general, I was able to respond quickly (I hope!). I feel I learned much more about how the material in ECE2524 was connected both to other courses and to events that interested you outside of coursework (open source gaming, personal server setups, commentary on Ubuntu as a general purpose OS).

There are a couple things I plan to change with the blog assignment with the end goal of adding a little more structure to the syndicated class blog, and hopefully encouraging more of a discussion.

  • enforce “category” and “tag” rules. If you look down the right sidebar of the mother blogyou will see a list of all the categories posts have been made under. The current list is too long and not focused enough to be of any amount of use to someone trying to sift through the many posts for a particular topic. Most of the words used for “categories” should have been “tags” instead, so spending a little time up front talking about the difference I think would be helpful in the long-term organization and usefulness as an archival tool of the blog. Some categories I’ve thought of are:
    • Introspective: reflect on the course itself, whether it be assignments, discussions or structure.
    • Extrospective: explore connections between course material and using *nix systems or applying Unix design philosophy to other courses or events.
    • Social Network: comment on and continue the discussion taking place at VTLUUG and VTCSEC meetings.
    • Instructional: Discussing personal setups and/or workflows. Posts here will have sort of a “tutorial” or “howto” feel.

    There are a couple optional assignments I want to offer that would be linked to blog posts:

    • Learn a Language: There are many benefits to learning a new programming language. From The Pragmatic Programmer, Tip #8 “Invest Regularly in Your Knowledge Portfolio”:
    • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet

      Throughout the semester those opting to do this assignment would document their progress with their language of choice and share any new ways of thinking or problem solving gained by thinking outside their language comfort zone.

    • Explore an Environment: An assignment suggested (I need to go through the list to recall who made it) has participants try out an alternative desktop environment and/or window manager. Learners participating in this assignment would make regular blog posts documenting their experience with a particular DE.
    • VTLUUG/VTCSEC: There were some issues with the attendance implementation at VTLUUG (in particular) and VTCSEC meetings that frustrated a lot of people and made my life a little more difficult. In addition, an attendance count isn’t really a good metric for the success of this assignment since the purpose isn’t simply to sit in a room for an hour, but to engage with a larger community. Next semester credit will be counted towards the VTLUUG/VTCSEC assignment for blog posts containing targeted discussion and thoughts of the specific topics covered at each meeting.


I noticed several people commented that the Inventory Management assignment was about the time when python and the motivation behind assignments started to “click”. I don’t mind that it takes a few assignments in before connections start clicking, but I would like to try and provide more motivation up front about where each assignment is headed, so that earlier along there is at least a notion of “this is going somewhere”. So I’ve been penciling out a clear, focused progression of assignments that goes from basic text parsing up to something like Inventory Management. That project in particular I am also going to make into a group project so that there is some exposure to using git as a collaborative tool before the final project. It also easily breaks up into sub-modules:

  • Data Parser
  • Command Parser
  • Controller

As the name implies the two parsers make use of text parsing concepts, while the controller is more of an exercise in logical program flow. I think with clear enough specs on what the internal data structures should look like, the three parts should be able to be written mostly independently and then combined into one project.

I would also like to start C/C++ development earlier in the semester. I am going to try and restructure exercises and lecture slides so that C/C++ and Python assignments are interwoven throughout the semester. I hope that this will prevent the feeling that I got that the semester was split into two distinct phases, the “python” phase and “C++” phase. That way the content can follow a logical flow and touching on the merits of each language. A brief example of what I’m thinking about:

  • simple line parsing (one primitive type, e.g. double/int per line)
    • in python
    • in bash
    • in C++
  • processing command line arguments
    • in python
    • in bash
    • in C++
  • parsing text lines into an array structure
    • you get the picture
  • parsing text lines into a hierarchical structure (e.g. command parser)
    • probably drop bash for this case
  • manipulating lists
    • python list comprehension
    • C++ stl algorithms
  • Inventory Management (python)

And I am toying with the idea creating a similar progression (overlapping mostly) that will cover fork/exec, basic IPC with pipe and lead to a simple shell. As I mentioned in the “Think about it” of the pipeline assignment, all were missing to create a basic shell program was a string parser that would parse something like “generator | consumer” into an array. Along those lines, I may adjust example code in the “Make a Makefile” assignment to use flex/bison to generate a simple command parser instead of an arithmetic parser.

As those of you familiar with bash are aware, as the complexity of the algorithms and data structures we work with increase, at some point bash will become overly cumbersome. At this point, it will be relegated to the task of writing unit tests of sorts for each assignment (Thanks to George for the suggested assignment.) This will make bash a more integral part of the course material, there was a notable lack of bash this past semester, which I regret.

Classroom Time

I’ve been doing a lot of thinking about how to use the classroom time effectively in a way that makes everyone want to come. I think it’s really important that everyone shows up regularly, not just those that feel they need some extra guidance, but also those who have been programming in a *nix environment for 10 years. It’s really important because both the novice and expert can learn a lot from each other if they’re in the same room. It also makes my job easier. There are 60 people enrolled in the class in the Spring: it will be nearly impossible for me to check with everyone individually every time there is a typo in an entered command. Getting a second set of eyes looking at everyone’s commands and code will help people avoid extended debugging sessions and make people more aware of common typos and bugs. To that end I would like to do more collaborative discussions in the classroom, and less of me talking. Regarding assignments, I’d like them due and committed to a network accessible git repo at the beginning of class. Then, in class people will pair up, fork each others’ assignment, review, make edits, and initiate a pull request so that the original author can merge in any bug fixes. The grade for the assignment will be determined by a combination of the functionality of the original commit and the merged changes. This probably won’t take place after every assignment, but at least a view of them.

Depending on how efficient we become at fork/review/merge, I’d like to have more discussions like the one we had about the Process Object assignment. I will try to come up with 3 or 4 “make you think” type questions for each assignment and then in class break up into groups, each discussing one question in depth, then come together as a full class and share the response each group had.


I think this post turned into more of a “What I plan to do next semester” more than the reflection I had intended. Because it’s probably already too long I’ll try and come to a close. The first semester I taught this course I pretty much followed the supplied lecture slides and exercises that were given to me. The second semester suffered from “all this stuff should be changed but I don’t have any rhyme or reason to it” syndrome (not unlike second system syndrome that Raymond talks about with regard to Multix). The next couple semesters, ending on the most recent, I have been tweaking and polishing and streamlining. There were still some bumps this past semester that I would like to eliminate (issues with VTLUUG attendance, problems submitting the midterm, lack of clarity on some of the assignments, much too long a delay on returning some of the graded assignments, to name a few), but I’m optimistic that the next revision will address many of them and hopefully provide a smoother and more enjoyable experience for all. Remind me to write another post about my vision for the class :)

*and now I’m 10 hours in… only 4 more to go!

Recap plus Final Project

What a semester.  Finally done with all finals and I finally have free time.  This semester in Into to Unix was quite interesting.  I expected the class to be somewhat like ECE1574 or 2574 where we simply just code in a unix environment.  It turned out to be somewhat of a surprise as I learned much more than that.  I didn’t even know what piping was before coming into class.  I’m also much more knowledgeable on many aspects of the Ubuntu.  I might be using bash commands a good number of times in the future.  Learning python was also a good refresher.  I had only known about simple python programming beforehand.  Learning about the history of unix and its impact on the world today was also a big eye opener.

I also realized that c++ on unix is very different from a windows environment.  I had only used visual studio before on windows.  The coding itself is the same, but using g++, gdb, makefiles, etc, makes it a completely different process.  Very enlightening.

With regards to the Final Project, we will be fixing it up soon.  We’ve read the comments and appreciate the feedback.  All of us had many finals so there hasn’t really been much time to edit the project. We will be getting to that soon.  Don’t think we were ignoring comments. =)

Hope everyone has a good break.  I’m out.

Project Idea: Dorm automation using an IRC network

I happen to have a lot of hackable wireless and networking equipment in my room at the moment: My desktop (of course), my phone, an unused wireless router, an arduino with an ethernet shield, a raspberry pi, Cerebot PIC trainer board with an ethernet port, and three laptops, in various states of repair.

I’ve been thinking about automating various aspects of my dorm. There are a bunch of related items in my room that I think could benefit by controlling each other:

  • Electric kettle
  • Lamps/overhead lights
  • Door lock
  • Window blinds
  • Alarm clock
  • stereo
  • smartphone

Having written an IRC bot for ECE2524, I’m now aware of how easy it would be to connect all of these things using nothing but an IRC network, with servers on the RPi and my desktop computer. I may need to start connecting things together in new and interesting ways :D

Project Idea: Roguelike game based on university tunnel systems

I’ve been playing the roguelike game known as “Stone Soup" since sophomore year of high school. I’m only now beginning to tire of it; I recommend it highly. If you’re unfamiliar with roguelike games, there’s a good writeup here. I was thinking one day about the steam tunnels beneath VT (which I have absolutely not ever been inside), and I think they would make a really excellent backdrop for a roguelike game. Especially if you found maps of other schools’ tunnels and made it a collaborative thing. There could even be an online component, where you could leave messages for other crawlers to find as they played. I’m thinking that, where other roguelikes have levels of the dungeon, this might be arranged more like the Pokemon Gameboy games: Each tunnel system culminates in some kind of boss battle, perhaps against the school’s mascot? You would go around collecting victories over each of the other schools’ dungeons, and then come home to your own dungeon and adventure for a while. These are all just ideas floating around in my head; if you have suggestions you should share them.

Programming languages I like

Since I began programming in 7th grade, I’ve used dozens of languages to do many different things. Some of these languages I liked, and some I did not.

The languages I like seem to have some basic things in common. The most obvious one is that they’re simple. Simple can mean one of many things, though, in a programming language. Maybe it would help if I used examples (in approximate order of increasing level of abstraction):

  • C
  • Scheme
  • Python
  • Ruby

These are all languages that I consider “simple." There are many aspects to the simplicity of a programming language, but I think the primary one is this: It is easy, once you know a few simple rules about how the language works, to write non-trivial projects. This holds for the above four languages. There aren’t too many special cases for a programmer to remember.

In C, the only thing you need to hold in your mind is the basic abstraction of how the computer is actually doing computation. Once you have that, and a few syntax rules, you can write C effectively.

In Scheme, you need only one syntactic structure: The S-expression. You also need to understand the difference between functions and macros, but beyond that there are literally no special cases whatsoever. Function application is easy to wrap your head around, too, if you have a decent guide (Say it with me: “Thanks, Abelson and Sussman!").

Python and Ruby have objects at the center of their designs. In Ruby, everything you do is some combination of objects, methods, and blocks. In Python there are more special things to remember (list comprehensions, for loops, and iterators, to enumerate one category), but you mostly don’t *need* to remember them. And you can look them up when you do need them.

Compare these to a couple other languages I’ve been forced to use recently: C++ and PHP.

C++ is the antithesis of “simple." There are a million things to remember when writing C++ code. What exactly does “const static virtual string& my_method(void);" mean about that method? And why does the compiler freak out about the string reference being a const when I try to use it later? I have never written more than 30 lines of C++ without making some stupid mistake, and I’ve probably written more C++ than I have any other language. I get the impression that you would need to write C++ for years and years to ever even approach “proficiency."

PHP is the other antithesis of “simple." It’s the least consistent language imaginable. How anyone can write PHP without a reference manual in their lap is totally beyond me. Should functions be camelCased or under_scored? The language “designers" couldn’t figure it out, either! What gets cast automatically and what doesn’t? I guess we’ll find out! Objects? Yeah, we have those!

I guess the conclusion of all of this is that one should write interfaces that are consistent, that stay out of the way, and that require very little figurative disk-space in the user’s mind.

Linuxifying my PC ‘scope, Part 2: Beginning

Today I started the process of creating a third-party driver for my USB oscilloscope, the Velleman PCSGU250. I began reading up on Linux device drivers in general (in Linux Device Drivers, 3rd Edition). It doesn’t seem all that difficult, to be honest. Of course, I’m only on chapter two, so we’ll see.

More importantly for this project, I figured out a method of actually determining what data gets sent to and from the oscilloscope during normal operation. At first, I thought the simplest thing would be to reboot into Windows and find some USB introspection tools that work in Windows. So I did that, but I couldn’t actually find anything that seemed to work for examining USB packets. Did a bit of research, and found that it’s actually easier to sniff Windows USB packets in Linux than in Windows.

It’s pretty simple to set up. I have Windows running inside a KVM instance (I assume VirtualBox would work, too), with the USB device forwarded to the virtualized machine. It’s then possible to use what’s known as the “usbmon” kernel module to monitor the USB traffic on the port.

"But that’s a bit gross to wade through using the standard interfaces, isn’t it?" you ask. Yes, it is. But never fear! Turns out, libpcap, everyone’s favorite network packet analysis library, also supports USB packets! And as we all know, libpcap has an extremely user-friendly frontend known as Wireshark!

So here is a screenshot of my current setup:

You can download a couple of the captures I created, and read a little more about the project, here.

I hope that, over this break, I’ll be able to actually get a driver written for this device. By doing this I expect to learn how to actually write Linux device drivers, and hopefully also save myself some money when I would otherwise need to buy a new DSO or a better PC scope that would work with Linux.