Since the release of Windows 7, I’ve heard plenty of good reviews about this latest Windows version and I decided to give it a try.  A month ago, I installed it on my MSI netbook so I could travel lightweight and give a paper presentation using PowerPoint.  Shortly thereafter, Ubuntu released its latest version into the wild and after using both Windows and Linux for about a month, I’ve been able to come up with some strong and weak points on both.  Some of my comments apply to Windows and Linux in general and not just to these latest versions or distributions.

Windows 7

Pros

• A solid UI.  I’m a real fan of the Aero theme, system fonts, and improved start menu.  The taskbar really takes the cake by using icons and clustering multiple instances of the same program.  Hovering over the taskbar gives a cool preview of each open window.
• Fast.  My netbook with Windows 7 feels just as responsive as it did when it ran Linux.  Boot times are a little slower, however.
• Robustness.  I had no difficulty with the Windows 7 install on my netbook and Microsoft even provides a Windows 7 CD to USB image utility for netbooks.  Unlike my Ubuntu experience, there aren’t any weird hacks to go through in order to get your display or wireless connection working correctly following a fresh install.  Furthermore, I haven’t encountered any system crashes and Windows seems to keep any malfunctioning program from taking down the whole system.
• Good hardware support.  I plug in a camera and it’s automatically recognized and drivers are installed from the internet.  I plug in an external monitor or projector and the correct model is detected and my desktop is extended on to it with the correct resolution.  It’s great for presentations since there isn’t much fiddling with the projector or Control Panel settings to get everything looking good.
• Software availability.  Everything has a Windows version, even most open source software.  I find that most developers put more effort into Windows versions since that’s what most people are running.  For example, I’ve had fewer crashes and slowdowns with the Windows versions of Firefox and Skype.  The Windows version of Skype is also much more polished than its Linux counterpart.  Furthermore, many software programs are only available on Windows.  MS Office, despite its incredible price tag, is still far superior to Open Office, and of course, only runs on Windows.
• Games.  Most of the latest AAA titles are available for Windows, a few might be available for Mac, and I’ve heard of only one or two released right off the bat for Linux.  If you’re into PC gaming, Windows is the only way to go.

Cons

• Lack of a centralized software repository.  This makes it a real pain to download and  install software since I have to go to a separate website for each program I want to install, find the download page, and click through a bunch of installation dialogs.  Even worse is that nearly every Windows program I install runs a background process on startup that constantly checks for updates and bogs down my system.  Also because of this lack of a centralized repository, programs inconsistently install themselves in many different places.
• Difficult to configure system settings.  The Control Panel is a real maze of links, buttons, and dialogs which are dumbed down at the highest level and utterly confusing once I drill down into specific settings.  Some settings can’t even be accessed with the Control Panel: for example, I still find myself using msconfig.exe to remove unwanted startup items.
• Windows Update is still very intrusive.  A large number of updates require me to reboot and will display a nag timer forcing me to do so.  I really don’t like the OS to get in the way and nag at me.  Some of the system updates take quite awhile to install and can bring my system to a crawl.
• Libraries.  This feature, which wasn’t in XP, is similar to Unix symlinks.  A library clusters together files and folders from several locations in the filesystem, making it unclear where the files are really located.  I would prefer that all my music, movies, or PowerPoint slideshows be stored in a single location in the directory structure such that I can easily back everything up or find something via Windows Explorer.  Windows seems to want you to not have any knowledge about its directory structure and instead rely on searches and libraries.
• Developer Tools.  This is the exception to the software availability and quality rule.  I’ve been using Eclipse for Linux and Windows and it works well enough on both platforms with plugins for Subversion and LaTeX editing.  However, other tools such as a basic text editor, LaTeX compiler, and command line tools such as make are either lacking or nonexistent.  I find it much easier to work with the command line than a GUI when creating plots with Gnuplot and documents with LaTeX.  I can quickly switch from one thing to the next without clicking through a whole pile of menus and dialogs.

Ubuntu 10.04

Pros

• A centralized software repository.  This is the main reason I like Debian and its variants so much. “apt-get install” will give me any program I want and provide automatic updates.  Removal is just as easy.
• Fast boot times.  On my 3 year old laptop, Ubuntu is up and running in 30 seconds or less from the moment I hit the power button.
• Easy to configure and control.  Adjusting a system setting is easily performed from a GUI tool or from the command line.  Configurations are stored in well documented text files as opposed to the nasty Windows Registry.  It’s really easy to track down where a program’s install directory is located and tweak something.
• A customizable UI.  The sheer number of themes available is astounding, with Compiz providing some really cool desktop visual effects that rivals anything Windows has to offer.
• Enthusiastic user base (support).  I’ve found that tons other Linux enthusiasts are more than willing to help with problems on message boards and websites.  For things I’ve had trouble with, a quick google search or message board post will return tons of answers with other people who had the exact same problem and had already solved it.  With Windows issues, answers seem a lot more difficult to come by and the user base isn’t nearly as friendly.
• Developer Tools.  Just about everything under the sun is readily available for developers in Linux, including a plethora of compilers, text editors, and command line tools.  Working from the command line makes things a snap compared to painstakingly navigating through different dialogs and menus.

Cons

• New software versions take time to be added to the repository.  For example, Firefox 3.6 has been out for months but was only recently included in the 10.04 Lucid Lynx release.  Prior to that, I had to compile and install Firefox 3.6 from source.
• Installation headaches still persist.  With every Ubuntu release, something doesn’t work post-install.  With 10.04, it was my video drivers.  During the upgrade process from 9.10, the installer whined about my video drivers and supposedly aborted the install.  Upon rebooting my computer, however, it was clear that the install had not aborted and my display was completely messed up.  After rebooting again, Ubuntu downloaded and installed the required video drivers automatically.  Also, Ubuntu now tries on boot to mount a remote drive in my /etc/fstab for which I don’t have a saved key, halting the boot process until I manually override the mounting process.
• Software quality and robustness.  Productivity software, such as Open Office, isn’t nearly as capable or as featureful as Microsoft Office.  I’ve had trouble with Flash causing browser crashes and other programs crashing all on their own which run stably in Windows.  I’ve had a heck of a time figuring out why some fonts are rendered terribly and look blurry in some programs, among other things.  More effort should be placed on creating polished products in order for open source software to really take off.
• Lacking hardware support.  This goes with the above bullet: I plug in an external monitor or projector and I still have to fidget with resolutions and positioning to get everything to work.  Suspending to disk often borks the external monitor configuration and then I have to do it all over again.

In all, I can’t say that either the latest Windows or Linux versions are better.  Windows provides a more robust and polished solution, while Linux gives more power and control to its users.  I find Linux to be a better choice for development, but Windows is the clear winner for gaming.  Both Windows 7 and Ubuntu 10.04 run reasonably fast — Windows 7 does quite well on my netbook, but Ubuntu clearly takes the cake with boot times.  Until open source software takes quality up a notch and Windows provides a better development environment, I’ll probably be dual booting, running virtual machines, or using multiple computers with both operating systems.

The TinyOS serial stack is designed to work with Active Messages so that packets received over the radio can be easily forwarded on to the PC.  To that end, the high-level serial and radio components provide the same interfaces.  The TinyOS serial stack has layers for packet formatting, error checking, and a read/write buffer.  However, for our project, we wanted to simplify the PC side so we didn’t have to use the TinyOS JNI libraries to receive TinyOS Active Message packets.  A simple program to read ASCII characters over the serial connection would suffice for our purposes — Minicom does this quite well and is easily installed on Ubuntu Linux and can be configured to read from attached USB devices.

The goal was to produce a TinyOS component that provided a command for transmitting ASCII character strings over the serial connection to a PC.  The  implementation is very similar to the Pulse Oximeter code I wrote for Atmel-based devices, however this time I targeted MSP430-based devices, such as the TelosB or Tmote Sky.  The implementation uses the Msp430Uart1C component for accessing the serial connection. This component provides the UartByte or UartStream interfaces for reading and writing and the Resource interface for gaining control of the UART. Msp430Uart1C also provides the Msp430UartConfigure interface for setting the baud rate.

The control flow for writing a character string is as follows: First, request the UART resource. Second, when the resource has been granted, call UartStream.send() to transmit the string. Lastly, when UartStream.sendDone() is signaled, signal the higher level application that the character string has been sent or an error message if something went wrong. In my SerialAscii module, I have the following command to send a character string:

  command error_t SerialAscii.sendAscii(char *str)
  {
    bufferLength = strlen(str);
    if(bufferLength > BUFFER_SIZE)
      return FAIL;
    memcpy(strBuffer,str,bufferLength);  // copy string into a buffer
    call Resource.request(); // request access to the UART
    return SUCCESS;
  }

I copy the string into a buffer to keep the application from modifying it before being transmitted. When the resource request is granted, I transmit the string:

  event void Resource.granted()
  {
    error_t result = call UartStream.send(strBuffer,bufferLength);
    if(result == FAIL)
      post sendDoneFailTask();  // return failure message to the user if something bad happened
  }

Lastly, when the string is sent, I release the resource and signal the higher level application:

  async event void UartStream.sendDone(uint8_t *buf, uint16_t len, error_t error)
  {
    // call Resource.release() in each of these tasks
    if(error == SUCCESS)
      post sendDoneSuccessTask(); // signal SerialAscii.sendAsciiDone(SUCCESS);
    else
      post sendDoneFailTask(); // signal SerialAscii.sendAsciiDone(FAIL);
  }

I’ve made my code available here. Let me know if you find any bugs or have any comments or suggestions.

I tried desperately to fix the fonts, summoning the help of the Ubuntu forums.  I tried editing font rendering settings in my local .fonts.conf.  I deleted the font cache and reconfigured fontconfig.  I tried adjusting a font quality parameter in Firefox’s about:config. For some forums posters, these solutions worked.  For me, nothing seemed to help.  Finally, I was able to get Firefox 3.6 installed with normal fonts by downloading and compiling the source code and installing the binaries compiled on my own system.

I’m not the only one who is frustrated by this.  This was probably the first time I’ve resorted to compiling a third party application from source since first using Ubuntu and Debian in 2006.  Normally, it’s just apt-get install whatever program you want.  The package manager automatically updates everything and keeps out of my way, rarely nagging to reboot unless the kernel was updated.  The package repository was one of the main reasons I switched to Linux in the first place: an easy, single step way to install anything and keep it up to date.  No hunting for a download website somewhere on the internet or clicking through a bunch of dialogs in an install wizard.

With such lag before new third party applications get added to the Ubuntu software repository, plenty argue that Linux isn’t ready for the mainstream.  I agree completely.  Most people will have to go through similar steps as I to get many of the latest third party applications installed, and it can be a real pain.  However, in Linux, I am free (as in speech) to customize or rewrite any part of the operating system and share my changes with others.  It also gives me a free (as in beer), top notch development environment for my work.  The problem is that such freedom comes at a cost: tinkering to get everything to work correctly.  Every time I’ve upgraded to the latest Ubuntu version, something doesn’t work and has to be fixed.  In another example, I recently installed the netbook remix version on my netbook and was rewarded by a flickering screen, which was fixed with a BIOS update.

Mainstream users just don’t want to be faced with flickering screens and BIOS updates, they want something that just works.  Consequently, they are willing to give up some of that freedom (as in speech and beer) to have a device that boots normally and doesn’t have font rendering issues when they install the latest version of a program.  Such users are better off with an Apple, and indeed Apple charges them a price in terms of money and control.

The iPad has launched a storm of controversy over its lack of user control.  Essentially, the device is a large iPhone, except there is no phone.  All applications must be purchased from the Apple-controlled App Store.  The real question is: do  mainstream users really need fine-grained control over their devices?  One comment on a Slashdot post really makes an interesting argument:

What has choice done? It’s given us the chaos of spam, malware, worms etc…  The average consumer should get a locked down device such as what Apple are proposing, a limited device with a closed market. And you do realise this is really no different to a games console.  Full blown computers should be reserved for those of us who know how to manage them responsibly…Computers as they are today are simply too complex and difficult to manage for the average consumer, so you either give them something simple or you take the management out of their hands.

Combined with the “Linux is not for mainstream” argument, this really makes the case that perhaps devices that work well but allow little user freedom may be the best for most people.  Most of the time, it’s the best choice for me.  I’ve got a phone, media player, GPS device, and others that I want to just work and perform a very specific function.  In these cases, I would rather they perform their jobs reliably than be extensively customizable.  However, I do think that the option to exercise greater control should be there for those who want it, no matter how few.  In the case of PCs, I’ll take that option, stick to Linux, and keep compiling from source when I have to.

Prior to writing the driver/interface code, I had to procure the pulseox hardware.  Detailed descriptions of hardware, software, and applications are found at the Harvard CodeBlue website.  I first ordered a Smiths Medical OEM Digital Micro Power Pulse Oximeter Board.  I was able to get in contact with sales staff by emailing Smiths Medical.  The pulseox board comes with a finger sensor and runs about $200.

Next, I needed an interface board to connect the BCI pulseox board to the 51 pin connector on the Crossbow IRIS.  The Harvard CodeBlue source code has documentation for a PCB layout and suggests that you order the PCB from an online manufacturer.  You also have to purchase some other components that must be soldered onto the interface board.  Fortunately, I was able to “skip” this step with the help of Leo Selavo, who graciously supplied me with two interface boards.  He emphasized that soldering the components onto the interface board requires a lot of skill and experience and if I were to try on my own that I would most likely break the PCB or components several times until I got it right.  The setup with pulseox board, interface board, IRIS mote, and finger sensor is illustrated below:

Pulse Oximeter on IRIS

With the pulseox board, interface board, and of course IRIS mote, I was ready to get my heart rate.  The biggest challenge still lay ahead: writing code to interface with the pulseox.  The CodeBlue pulseox code was written in 2005 for TinyOS 1.0.  All of the low level UART and mote hardware interfaces have changed drastically since then, so the old code wouldn’t just work right out of the box.  I had seen plenty of posts on the CodeBlue mailing list about implementations for the pulseox in TinyOS 2.x, but nobody had bitten the bullet and actually written anything.

What I wanted was to be able to use the pulseox like a sensor on the MTS300/310 sensorboard: call a Pulse.read() or Oxygen.read() command and get back a uint16_t with pulse or blood oxygen saturation.  This is fairly straightforward since I had experience modifying the MTS310 sensorboard code to power on the sensors manually.  I created configurations PulseC and OxygenC to provide SplitControl and Read interfaces to power on the sensor and read, respectively.  I then wired PulseC and OxygenC to a PulseoxP, which functioned as an intermediary between the application and the low-level pulseox driver code.  Like in the original CodeBlue source, I created a BciC configuration and BciP implementation to communicate with the pulseox directly through the UART and return data back to PulseoxP.

The key changes between the CodeBlue TinyOS 1.0 code and my implementation are all found in BciP (or BCIM.nc in the original CodeBlue source).  Two issues come to mind.  First, setting the mote hardware pins is done differently in TinyOS 2.1.  Calls like TOSH_SET_PW0_PIN() are replaced by abstractions.  I had to wire MicaBusC.PW0 to the GeneralIO interface in BciC and then call GeneralIO.set() in BciP.

The second difference is with the UART.  TinyOS 1.0 uses the HPLUART interface for low level UART communication, but this has been replaced by Atm128Uart0C for the Atmel 1281 architecture.  The CodeBlue source code initializes the low level UART to its default state, turns it off, and then sets the hardware registers to the desired UART configuration so that the mote can communicate with the pulseox board.  After figuring out what the CodeBlue UART configuration code did, I can’t believe that you can actually write to the registers directly!  Imagine if you could do that with user-level code on a PC!  To enable transmissions and reception along with interrupts for the UART in TinyOS 1.x, you had to do the following:

// Enable tx/rx interrupts and tx/rx
outp(((1 << RXCIE) | (1 << TXCIE) | (1 << RXEN) | (1 << TXEN)) ,UCSR0B);

TinyOS 1.0 uses the outp() macro to set bits of a given register, but this macro does not exist in TinyOS 2.x.  Instead, the UART register bits are configured in a struct with fields for each bit in the register.  For the above example in TinyOS 2.1, the following union represents the control register in Atm128Uart.h:

/* UART Control Register */
typedef union {
struct Atm128_UCSRB_t {
uint8_t txb8 : 1; //!< UART Transmit Data Bit 8
uint8_t rxb8 : 1; //!< UART Receive Data Bit 8
uint8_t ucsz2 : 1; //!< UART Character Size (Bit 2)
uint8_t txen : 1; //!< UART Transmitter Enable
uint8_t rxen : 1; //!< UART Receiver Enable
uint8_t udrie : 1; //!< USART Data Register Enable
uint8_t txcie : 1; //!< UART TX Complete Interrupt Enable
uint8_t rxcie : 1; //!< UART RX Complete Interrupt Enable
} bits;
uint8_t flat;
} Atm128UartControl_t;

The flat uint8_t is a real slick way to convert all the elements in the struct to a single word, which can then be written to the register. Following the code that initializes the UART in tos/chips/atm128/HplAtm128UartP.nc, I was able to configure the UART to run with the pulseox board requirements: 4800 baud, double rate, transmission and reception interrupts enabled, no parity checking, 1 stop bit, and 8 bit word size.  So, with the previous example to enable transmissions and reception, you do the following in TinyOS 2.x:

Atm128UartControl_t ctrl;
ctrl.bits = (struct Atm128_UCSRB_t) {rxcie:1, txcie:1, rxen:1, txen:1};
UCSR0B = ctrl.flat; // ctrl.flat

I ran my concerns by the CodeBlue mailing list, which elicited a reply from Prof. Matt Welsh that I was headed in the right direction.  I finished my implementation, worked out some compile errors, and loaded the new pulseox and general data collection code onto a mote to see what would happen.  Almost never does my TinyOS code run correctly on the first try — usually I spend hours or days debugging, but this time it was magic.  A number jumped onto the screen in the data column of my PC Java application, which was connected wirelessly though a base station mote to the pulseox mote.  The sensor readings seemed reasonable for a heart rate, for jumping up and down and breathing hard made it go up and laying down and trying to breathe slowly made it slow down.

Pulse Oximeter Reading

I have made my code available here and any feedback, suggestions, or questions are encouraged.  To use it, place the pulseox directory into the tos/sensorboards directory in TinyOS 2.x.  In the makefile for your application, add the line “SENSORBOARD=pulseox”.

I found that every time I called Read.read() for some of the sensors, that there would often be a delay in getting my data back with Read.readDone(). This delay was because each call to Read.read() would power on the sensor, requiring a warm-up time before a sample could be retrieved. While the warm-up time for the accelerometer is 17ms, the warm-up time for the light sensor is an excruciatingly long 1200ms! So, I would call Read.read() at 20ms intervals, but have to wait over a second to get data from the light sensor. When the data sample is returned at Read.readDone(), the sensor would power off again, thus requiring another warm-up the next time a sample is requested. Basically, the constant warm-up lag in the current TinyOS code prevents sampling at a reasonably fast rate using Read.

I also found that if I wished to get both axes of the accelerometer or magnetometer simultaneously, that only one axis would ever return data. The accelerometer, magnetometer, and light/photo sensors use the ArbitratedResource interface to block all other sensors that use the same resource when one sensor has a lock on the resource. If the x-axis accelerometer was sampling with Read.read(), it would have a lock on a UQ_ACCEL_RESOURCE identifier, preventing the y-axis from sampling simultaneously, since its resource is also identified by UQ_ACCEL_RESOURCE. I wasn’t the only one with these problems, as illustrated by this TinyOS mailing list post. The mailing list poster also points out that the ReadStream interface blocks data sampling for all sensors but the first one that calls it: if you try using ReadStream to get streaming data for the accelerometer x-axis and the magnetometer x-axis, the call to ReadStream.read() for the accelerometer would block the sampling of the magnetometer if it was called first. With ReadStream, all sensors use the same resource identifier, so when one is sampling, it has the lock, and all others must wait. The resource arbitration effectively prevents multiple sensors from sampling data simultaneously using ReadStream.

This automated power control for Read as well as the blocking for Read and ReadStream really limits the functionality of the sensorboard. Initially, I thought it was a hardware constraint. You would think that since the board has all those sensors on it, the manufacturers would have designed it such that you can use all the sensors at the same time. It turns out, that it isn’t a hardware problem — it’s just that the MTS300/310 sensorboard code is written so you can only effectively use one sensor at a time. I managed to change this by modifiying the behavior of the Read.read() of every MTS sensor.

The current TinyOS code uses SplitControlPowerManagerC to power on the sensor when you call Read.read(). Read.read() triggers the power manager to call the sensor’s SplitControl interface. Supposedly, when Read.readDone() is signaled and the sensor data is ready, the power manager will keep the sensor powered on for some amount of time in case the sensor is needed again — this is from the comments in PowerManagerP.nc. However, from my testing, there is no evidence that the sensor stays on after Read.readDone() is signaled. The warm-up routine starts all over again the next time Read.read() is called. It’s possible that 20ms is too much time between samples, but it appears from the power manager code that the sensor is turned off immediately if no resource requests for that sensor are pending. Currently, I can’t find anywhere in the MTS310 sensorboard code or in the power manager code where some kind of backoff timer is set before powering down the sensor.

To that end, I eliminated this automated power control through the power manager. I altered each sensor’s interface in the mts300 code library so that each sensor provided a SplitControl interface. This now allows me to manually power on each sensor I want to use before I start sampling. I then have a timer call Read.read() at regular intervals for each sensor I want, which returns the data with Read.readDone(). When I’m done sampling, I can turn the sensors off.

The current code is more a less a hack and has a weird side effect. For example, since the x and y-axis accelerometers use the same AccelP module with the same SplitControl power interface, only one accelerometer has to call SplitControl.start() to turn the sensor on. The same goes for the magnetometer and the light/photo sensors, as well as for calling SplitControl.stop() to power down the sensors. Otherwise, the warm-up/power on sequence is triggered twice for the same sensor if you want to use both axes of the accelerometer or magnetometer, or wish to use both light and temperature sensors. Edit: this issue has been fixed in the code.  Calling SplitControl.start() for both axes of the accelerometer/magnetometer will only run the power on sequence once, but both calls will return SplitControl.startDone().  The same applies for SplitControl.stop().

The modified sensorboard code can be downloaded here, which is a zipped directory of all the mts300 sensor code, but changed to mts310. Just unzip it into the tos/sensorboards directory. The configurations AccelXC, AccelYC, MagXC, MagYC, MicC, PhotoC, and TempC have all been modified to provide the SplitControl interface, so for example you can call AccelXC.start() to power on the accelerometer, then AccelXC.read() to get data, and then AccelXC.stop() to power the accelerometer off. I’ve used this extensively with the accelerometers, magnetometers, acoustic, and light sensors and it seems to work without any issues.

To solve it, you can do the same thing I did: disassemble the binary and use the debugger.  Be sure to set a breakpoint so that you won’t set off the bomb accidentally.  As long as you’ve got that breakpoint set, you’ll never lose any points.  Step through the assembly code line by line and try to figure out how the input is manipulated.

But now, it’s almost worse. I started working on my current project in September, right after my knee surgery. It’s been going for nine months and now I am finally cramming all of those nine months into ten pages or less, double column.

To put this in perspective for an undergrad: take all the papers, all the projects, all the homework assignments, and all the exams, tests, and quizzes in the last two semesters and make them all due next week. That is the weight of what I am working on. It nags at me every day that I have been working for so long and have nothing to show for it. I think about it in bed before I go to sleep, I think about it when I wake up, I think about it when I’m in the shower, and I think about it when I’m on the bike. As an undergrad and even for the first part of grad school, I got closure incrementally: with periodic assignments and tests and at the finish of each semester when classes end. Closure is now when I get a paper out, and the time span for that seems indefinite.

My first project and paper was faster — it took a semester and a summer. However, I’m still dealing with that project now — I’m going to present it at SECON and when I do, it will almost be a year since the first version of the paper went out.

It seems most undergrads treat papers lightly: “Oh, I can crank out a ten page paper in a few hours and still get an A…” I was the same way — it was spit something out as fast as possible to get it over with, but put enough effort into it to get a decent grade. Now, papers are everything. The paper is how everyone else sees your work. I may have spent the past nine months creating something that could have huge implications for the future of wireless sensor networks, but nobody but my adviser would know about it unless I tell them in a paper. The reviewers will lay the smack down on you if you try to whip out a paper in a matter of hours. Yesterday, I spent six hours writing and got out about five paragraphs. They were five critical paragraphs about the core of what I did, and they had better be comprehensive and understandable from the perspective of an outsider.

I find it hard to tell the story of my project, but I think the difficulty is from inexperience. There are key things that reviewers look for that I must give special attention in addressing. Because of this, there is a pretty rigid way to write a research paper, but even then I find it difficult. It is hard to convey specific algorithmic details, yet be concise and easy to understand. I have to remember the main selling points of my work and refer back to them throughout the paper. For these projects, I find the initial problem discovery, solution design, and implementation to be interesting and sometimes even fun. Enough experience programming and thinking about solutions to problems has helped with that, but I haven’t done much writing.

With time, I imagine writing will get easier. I will know exactly what to do. With my current paper, I’m almost there. I’m almost to the point where I feel good about what I have written and know that everything will turn out okay. I just have to keep working and get it done. Then there will be some closure.

Over the past week or two I had been getting really restless.  The hour on the trainer every day gave me a workout, but the weather was starting to turn.  Spending nearly 95% of my time indoors over the past seven months was starting to really get to me.  As goes the quote from “Office Space,” “Human beings were not meant to sit in little cubicles staring at computer screens all day,” which was pretty much what I have been doing.  I would walk back and forth from the Computer Science office and that was about it in terms of getting outside.  Something was about to give.

It gave this weekend.  The Colonial Relays was this weekend, and on Friday I walked over from the office and watched some of the distance races.  The hour or so that I was out there had been the longest I’d been outside in quite a long time.  That night, I went back and talked to a few of my teammates and alumni that had come back to watch.  It was a great change of pace and was good to see everyone run.  I talked to a lot of people that I hadn’t talked to in months, some even longer than that.  A lot of people asked me when I would try running again, since the doctors have given me the okay to start.  I replied that I wasn’t sure, but it would be soon.  In talking to my old teammates, I had forgotten what I had left behind.  For quite awhile, I’ve been in my own really tiny world, working on my projects.

Until now, the only times I would be shocked back into reality was when I would be having a discussion with my adviser in the late afternoon.  We would be having a discussion on the whiteboard in his office and I would happen to glance out the window and see all my teammates run by in a blur.  It’s a real kick in the butt to see that and remember what I used to do.  In the world of computer science, the atmosphere is mellow, but determined.  In the world that I came from, it’s about getting on the track and suffering.  Unfortunately, in the context in which I live now, I don’t think anyone says, “I really dominated in that conference paper.”  You don’t sweat and breathe hard while thinking up and coding a slick algorithm.

On Saturday, I got up, ate breakfast and prepared to do what I had done since before Thanksgiving: get on the trainer and pound away for about an hour.  I would open the window, turn on the fan, and listen to music while I looked outside at the law students coming and going from the library.  But on Saturday, the sun was shining and it was getting warm.  I couldn’t take it any longer: it was time to go out.

It was about the best feeling I’ve ever had.  I was uncaged, released into the wild, my natural habitat.  I hauled it out past the state park at York River.  The weather said the wind was blowing 30 mph gusts from the west, but I didn’t notice a thing.  I powered up hills where over the summer I remember being exhausted and downshifting into the lowest gear.  I remember trying to upshift, only to look down and see there were no more gears to use.  A dog bolted out from its house and chased after me for nearly a quarter mile, but I kept it at bay.  I turned around right before the road ended at the river.  As I got closer to home, I never got tired.  I looped around campus and got to the track just in time to watch the 4×800.

Yesterday was the first day in months that I didn’t do any work before dinner.  I still did a little before I went to bed, so I couldn’t call it a complete day off.  I was outside at the meet all day and got a nasty sunburn.  I guess that happens when you don’t have a built up tolerance from running or biking outside every day.  I watched all the distance relays and hung out with everyone some more.  By the end of the day, I was exhausted.  On the bike, I’d gone 45 minutes over an hour, and despite feeling much easier than the trainer, was enough to make me not want to move for most of the afternoon.

Today I went out again, but took it easier.  I was definitely more tired today and felt more normal as compared with pre-surgery rides.

As for my knee, I was out of the saddle several times and really hammered up some hills without any real discomfort.  I might have felt something this afternoon walking around, but I can’t be sure.  I do know, that if my knee could handle what I did today and yesterday, I’m pretty sure I’ll be able to do at least some running.  Sometime soon, the same thing will happen with biking outdoors and I’ll just start running on a whim.  It won’t take much to push me over the edge.

I finally broke down and got a new bike.  For awhile, I’ve been worried that the rear cogs are so worn that someday I’ll go up a hill and the chain will just rip off.  I tried a few new bikes out at the bike shop, the first one being a Specialized aluminum frame.  It felt like my old one, nothing really special about it.  But, I tried a Giant TCR-0 with a carbon frame and it felt like a rocket.  It was an unused 2006 and I think I got a pretty good deal on it since equivalent new models of just about every manufacturer go for about $1000 more.  I’d been to bike shops quite a bit in the past few years and I don’t often see anything older or discounted.  It seems most owners keep a limited stock.  The components had been switched up and have a combination of Shimano Ultegra and 105.  I really don’t need the way high end components since I don’t care too much about saving some fraction of an ounce of weight.  As it is, the bike feels like a feather compared to the steel Bianchi.  Since my shoes and pedals were a mess, I went ahead and replaced those.  Hopefully I’ll be able to try out the bike before the weather crashes this week.

If I can bike or even run outside more often it will provide more of a balance to my life.  I really can’t just hole up and work all day — there’s got to be a balance to the equation.  The recent discussion about goofing off boosting productivity probably has some merit in it.  Biking or running isn’t really goofing off, but it provides the same release.

As I see it, the ultimate goal in the computer science community is to provide systems that improve our lives without us even being aware of it. Stuff should just happen in the background that we don’t even know about to provide drastic improvements in general areas like productivity, entertainment, and communication. All the background noise should be filtered out by these hidden systems so that we only see things that are important to us. For now, it seems, nothing is being filtered out and we are subjected to an increasing amount of information, almost all of which we really don’t care about. For example, this morning I searched Google for “mp3 players” (as in the physical devices) and only got hits for software programs. Problems like this shouldn’t happen, and I shouldn’t have to type in some weird query to specifically exclude certain results from my search. Some serious work has to be done to limit the scope of what we see to only the things that matter, and do it in such a way that isn’t annoying. Basically, operating systems and software should just work and not require any hacks to get solutions we want.

The first issue that comes to mind is with today’s operating systems. Gigabytes of patches and updates are released each month and harass the living daylights out of the end users to install them. This is one of the best examples of the Nag Factor. An operating system should not endlessly nag the user about installing updates and allowing administrative privileges. Ideally, the user shouldn’t even be aware that he or she is using a computer at all. Updates should be automatic and occur in the background without the user even knowing. Nothing is more annoying than to be deep into writing a paper or watching a movie when up comes a nag balloon demanding that some updates be installed and the machine rebooted.

Windows is far and away the worst when it comes to the nag factor. I’m almost completely off Windows at this point, with the exception that I use a partition on my laptop for my USB TV tuner, which unfortunately doesn’t have Linux drivers. It seems every time I start up the machine, about five nag balloons pop up telling me what wireless network I’ve connected to. About once a week another torrent of nag balloons pop up telling me to install software updates. When I finally install the updates, Windows forcefully reboots my machine. Nothing, I mean absolutely nothing, should ever forcefully reboot your machine. It’s a complete disruption of anything resembling the mantra of ubiquitous computing. A professor I had for a software engineering class once told me that it takes about eight minutes for someone to become completely engaged in a task. When some moron at Microsoft thinks it’s a good time to make your machine reboot, that’s about five minutes of lost productivity due to the reboot, and another eight to get back to where you were. Even Bill Gates complains about the forced reboots in Windows. Since I’ve never used Vista, I’ve heard another annoying “feature” is the User Account Control system, which ceaselessly has you type in your administrative password for stuff as simple as connecting to a wireless network.

Next up is OS X. Two years ago, I started the shift away from Windows with a Macbook. My Windows desktop began rusting from disuse almost immediately. Unfortunately, OS X suffers from the update nag almost as badly as Windows. Nearly every update is hundreds of megabytes and requires a reboot. iTunes updates even require reboots — what were they thinking? And when you install the stuff, it takes forever. Sometimes on an OS X update, my machine has rebooted two or three times over about ten minutes before the login screen comes up again. The updates first make their way to you through the extremely aggravating dock icon jumping out at you. While the dock is a good feature, the jumping icons are not. I can’t describe how irritating it is to be doing something and have a dock icon start leaping out into the center of my vision, ceaselessly pushing my buttons until I deal with it. There is probably a way to disable the icon jumping, but I’ve moved on from OS X, so it doesn’t matter at this point. UAC is also present in OS X but the designers did a decent job of only prompting you when changing administrative settings or installing software.

For the past year, I’ve almost exclusively used Ubuntu Linux for all of my computing. Finally, a group of developers has the right idea. It works almost seamlessly. An operating system should do its best to get out of the way and let the user do what he or she wants. Ubuntu is really close to doing this. The package manager is excellent — you can install anything under the sun (for free) and it updates automatically. You can’t even do this with the Mac by default, unless you install something like DarwinPorts, and even that is a real hassle to set up. The downside is that since every program you install is controlled by the package manager, there are frequent updates that require your authorization to install. Nearly every day something has a patch, but the package manager does its best to be minimally invasive. Nag balloons are infrequent, and a small icon appears in the task bar indicating that an update is available. Reboots are almost never required except for things that affect the kernel and nothing is ever forced on you. For now, I’m extremely satisfied with my Linux experience and will probably not switch back to Windows or Mac unless some serious revamping occurs.

The nag factor isn’t present in operating systems alone. The devices that are beginning to make ubiquitous computing a reality are providing irritations of their own. Whenever I miss a call, get a voicemail, or receive a text message, my cell phone beeps and hums to no end until I touch the screen acknowledging its nags. I’ve had two phones, and they both did this. Neither has the option to turn it off. I can check manually to see if anything came in while I was away from my phone and would prefer to do so instead of being constantly annoyed. I’ve also noticed that late model cars now beep at you if you start the engine and have your seatbelt off. Apparently, this is mandated by the federal government, but it’s just another irritating nag. Some cars will nag at you after the mileage counter gets beyond a certain amount since your last service.

It isn’t just the nagging that’s a problem, though. Some poor design decisions really limit the usability of computing systems and ubiquitous computing devices. The worst of this is proprietary software and hardware, with Apple really standing out as the worst culprit. The iPod that’s starting to die on me has a proprietary USB jack to plug it into my computer. What makes me mad is that it didn’t come with a wall plug to charge it — I’ve got to use the proprietary adapter to charge it via USB or for over $40 for a wall adapter. Since I don’t need to sync my iPod every day and would like to be able to travel with it without bringing my computer, a wall plug would be great. Thanks to the wall plug adapter scam, I don’t think I’ll be getting another iPod if I can help it. Apple’s computers also make use of proprietary headphone jacks and video outputs such as mini-DVI and mini-DisplayPort. I had to fork over $20 to get a mini-DVI to DVI adapter so I could use an external monitor with my Macbook. Universal hardware standards would make ubiquitous computing much more of a reality, with devices seamlessly integrating with each other and providing minimal headaches to the end user.

With respect to proprietary software, the iPod/iTunes combination also takes the cake. When I first got my iPod, I was using Windows, and installed iTunes on Windows to keep my music and iPod in order. After I got my Mac, I tried plugging the iPod into the Mac and using the Mac to keep everything synced. Did this work? Of course not. iTunes on the Mac whined that my iPod was formatted for Windows and that it couldn’t write anything to it unless it was reformatted. I don’t see why the geniuses at Apple could have written some drivers so that the iPod’s file system could be accessed from any operating system. It all seems to be about control. Downloading songs from iTunes only allows you to have those songs installed on three machines simultaneously and you can only load them onto an iPod in a proprietary format.

Cell phones are another example of this walled garden approach. You not only pay for the access to a cell network, but you have to get a proprietary operating system running on a proprietary phone to go along with it. You can’t just build your own cell phone out of spare parts, install your own operating system, and expect to connect to Verizon’s network even if you’ve paid for it. Google’s Android seems to be a step forward to breaking down this situation by permitting custom applications, but there’s a long way to go. Without all this proprietary junk to get in the way, you could see some seriously interesting applications, such as P2P file sharing on cell networks, refinement of video and text messaging, and the eventual integration of portable gaming, media, and communication into one device (the iPhone still sucks). For now, I’ve got to carry around my laptop for web browsing and programming, my cell phone for telephone calls, my iPod for music, and my PSP for gaming. Oh, and maybe a watch to tell time.

Finally, coming back to my dying iPod, battery technology needs significant improvements in order to further the goals of ubiquitous computing. Reducing I/O and computational complexity on the software side can only help but so much. The typical Ni-Cd battery, regardless of the device, lasts about two to three years and only runs for a few hours under full load. This is crap. Until batteries last for a week under full load and hold a full charge for nearly ten years, we’re just going to be throwing away perfectly good equipment. My iPod, which is perfectly fine with the exception of the battery, could last an indefinite amount of time. It seems really wasteful to toss cell phones and other mobile devices every few years just because a battery died. Reduced reliance on proprietary hardware and software could help this problem as well, for parts could be easily interchanged or upgraded if new features become available.

If the tech industry would focus on reducing the nag factor and increasing the openness of design standards, the shift to ubiquitous computing could be faster and more seamless. Until then, we’ve got to deal with the endless OS nag balloons, proprietary devices, and terrible battery life.