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.

Linuxifying my PC ‘scope, Part 1: Exposition

This summer, while interning at IBM, I thought it would be a really capital idea to take a class online from Virginia Tech. I was mostly wrong. First, the material that usually fills a semester of ECE 2004 and 2074 (Electric Circuit Analysis lecture and lab, respectively) was crammed into only a couple of months. Second, I was also working 40 hours per week, and otherwise living a pretty full life.

The lecture component sucked: Every week there would appear a new video lecture, with slides and audio, in a proprietary format that could not be sped up. It would be about an hour and a half long. There would then be a homework assignment based on this lecture. Exams, though, were the worst. I needed to have one of my superiors at work proctor my exam during work hours. Anyway, I ended up doing quite poorly in this section. At the time, the C+ I received was the worst grade I had ever received in any class. I simply didn’t have time to devote to it.

This post, however, is actually about the lab component. This bit was much more enjoyable than the lecture, but I didn’t perform any better. It was equally time consuming, despite being worth only a third of the credit. Our work was validated via skype, and there was a very strict format for each of the lab reports, which I wasn’t very good at following.

Worse, though, we were not allowed to choose our own tools. We were required to use PSPICE (ridiculously buggy and user-unfriendly circuit design and analysis software), which is windows-only, and the Velleman PCSGU250 PC oscilloscope. This oscilloscope, as with many such PC ‘scopes, has drivers and software for only Windows. I needed to use Linux for work, so I had to run PSPICE and the oscilloscope software in a virtual machine. Long story told in short, I swore vengeance on the ‘scope.

I never really got the time to exact this vengeance, though. Until today, that is…

[Continued in the next post]

How to tuple-boot

So, I need Windows for various classes, and I need Ubuntu for a couple of classes as well as the simulation work I’m doing at RoMeLa. Unfortunately, I don’t really like either of these operating systems, and prefer Arch Linux. The required steps for booting all three are something like this. I actually set this up a while ago, so I may accidentally leave some things out.

1. Install Windows.

2. Use a GParted LiveCD to repartition your hard drive.

2. (a) You’ll need to resize the larger NTFS partition to the size you’d like Windows to occupy

2. (b) Add at least two partitions for your linux root directories. Because this will be more than three partitions (disallowed by DOS partition tables), you’ll want to have an “extended" partition as the third one, and then the remaining partitions logically inside this extended partition.

2. (c) It is *possible* to share a home partition between the two linux distributions. I’m not sure whether I recommend this. It’s safe to assume that this isn’t going to work 100% perfectly. Different versions of software (for instance, different versions of GNOME) have different expectations about their config files. I especially had problems between Unity, Ubuntu’s desktop environment based on GNOME, and GNOME Shell in Arch. I solved this problem by using the tiling window manager wmii, and ensuring that both copies were the same version. However, there’s a lot of potential for mismatched versions across distributions, and you’ll have to solve these problems on a case-by-case basis.

2. (d) You might want a swap partition.

3. Install your first Linux distribution. In this case, I’d go with Ubuntu first, because the way it sets up booting is a little opaque, whereas it’s possible in Arch to really understand what’s going on under the hood.

4. Install the second Linux distribution.

5. Set up the bootloader. You can do this with a standalone tool like supergrub2disk, or with your operating system’s tools. I’d recommend GRUB2 and os-prober (be careful to mount all partitions beforehand. os-prober will see bootable Windows partitions that aren’t mounted, but not Linux partitions).

6. Hooray! Now go about complaining to everyone you meet about the idiotic n-boot setup you’re forced to use.

Linux! It’s fun!

Except when it isn’t. And even then it’s fun!

I got a replacement CPU, motherboard, and RAM (also an SSD!) for my 4-year-old desktop. Still no news of my Thinkpad’s ongoing repairs, but I’m pretty sure having a desktop will suit my needs for now.

I went ahead and set up a dual-boot environment with Windows 7 and Arch Linux. There was a time when this would have been easy for me, but I’m a little out of touch with computer-building, and the Arch setup process has gotten slightly more complex than it once was. So I initially forgot to set the RAM timing properly, which caused a bunch of problems with Windows.

Once I’d spent a day or so figuring that out, I decided to set up the linux side. I had used the SSD for my base Windows install, and it’s crazy-fast. So I plugged in the Arch install disk, which used to come with the Arch Installation Framework (basically an install wizard). They’ve recently removed it from the install media, so I was a little confused. I didn’t want to screw anything up, and I didn’t have a ton of time to spend learning to manually partition my hard drives using cfdisk or parted, so I burned a Gparted disk image and did it a nice, safe GUI. Oh, except that one of my older hard drives started screeching at me like a tiny metal banshee. I suppose it’s what I get for using several-year-old hardware.

So I install Arch and GRUB2, and finally everything is going swimmingly. I’ve set up internet printing using CUPS for the first time, so no more messing with my printer’s USB cable when I want to print from a laptop. I’ve also set up my desktop as a dynamic dns client using, so I can hopefully remote-access it even when CNS changes my IP (which they’ve started doing in the past couple years. Gross).

Oh, another thing: Somewhere along the line, I tried installing Ubuntu via Wubi, and was weirded out at the output of `df -lh`. What exactly is a loop-mounted partition? This requires further study.

Blogging for UNIX!

I need a blog to replace my posterous (given their seemingly imminent demise), and in particular I’d like to write about Unix for a class I’m taking, in which blogging is an optional assignment. All posts on this new blog with the tag ‘ece2524’ will pertain to my experience with this class. The laptop I’ll be using is currently on its way to IBM for repairs, so in this post I’ll just outline my experience with Unix-like operating systems.

I first installed Linux in freshman year of high school (2006) at the urging of Clark Gaylord, father of my co-boyscout and friend Carter, when I took over the troop’s newly-created webmastership. I used SUSE9, because he happened to have a book and liveDVD to lend me. None of the laptop’s networking hardware, USB mass storage, windows partitions, or optical drives were recognized. Needless to say, I gave up pretty quickly and Clark showed me how to use PuTTY and WinSCP to connect to the server instead.

During this time I was an avid reader of the site LifeHacker, which was enamored of the up-and-coming Ubuntu Linux distribution. This distribution’s goal was to make desktop linux as easy as other operating systems. On booting the liveCD, everything seemed to work! I was soon spending most of my time playing in the linux side of my dual-boot setup.

By the summer I was very comfortable using Linux as a desktop operating system, and I got a job as a help desk technician and IT drudge at the Virginia Tech Transportation Institute, where Clark was the CTO. This job involved a lot of waiting for progress bars—time that I used (encouraged, of course, by my boss’s boss) to learn about linux culture and programming, and gain comfort with the command line. By the next summer I knew enough to be hired back at VTTI, this time as a junior system administrator.

Since those two summers I’ve used Unixen for nearly everything. I’ve used Ubuntu, CentOS, Fedora, Debian, and Arch Linuces; Free, Open, and NetBSDs; and, of course, OS X. I’m no longer comfortable on a system without a bash or zsh prompt.

In summary: Linux has been a major part of my adolescence, and will probably continue to be a major part of my adulthood.