Craig Younkins' Blog

Asynchronous Communication

2010-07-03T21:55:00.008-04:00

What do text messaging, email, and voicemail have in common? They're all asynchronous forms of communication.

By asynchronous I mean that the stream of communication is intermittent and not constant. There may be minutes or hours in between messages in the conversation. When you email or leave someone a voicemail, you realize that the person you are contacting will likely take a while to get back to you. The very minimum most people expect someone to get back with one of these methods is around 5 minutes, and people typically estimate it will take around a day.

Contrast this with a synchronous method of communication such as the phone or instant messaging, where the stream of communication is expected to stay quick, with messages being passed back and forth within seconds. With phone calls or speaking with someone in person, there is usually the expectation that the other person will reply as soon as the speaker is finished their sentence.

I often harp on text messaging because text input on mobile devices is slow and because carriers really overcharge for texts. A bare-minimum voice connection on Verizon's EV-DO network uses 38.4 kbits/sec. In one second of voice communication, 38,400 bits (4,915 bytes) are transmitted over the air. Each SMS text message is 1120 bits (140 bytes), regardless of the character encoding. After doing the math, we can see that 1 second of voice communication is the data equivalent of 35 full-length text messages. If you don't have a text message plan, Verizon charges $0.25 per sent text message. For 35 text messages, that's $8.75. Imagine if your voice plan cost $8.75 per second, or $525 per minute!

But despite its slow conversation pace and high cost, text messaging remains a very popular method of communication in teens and young adults. After speaking with numerous people, I found that most do not disagree with my two biggest gripes. And yet they still text. Perhaps one reason why is because it is asynchronous. People can carry on multiple asynchronous conversations at the same time, or multiple asynchronous conversations and a synchronous one. People will text at the meal table or when hanging out with friends because they can maintain the synchronous conversation with the people they are physically with, and still chat with someone who isn't there.

Both asynchronous and synchronous communication methods have their benefits. Synchronous communication allows for a conversation to happen quickly with a lot of back and forth, so it's great for people to coordinate real-time events such as meeting places or to explain something clearly.

Asynchronous communication allows for fewer interruptions. A synchronous conversation generally derails the thought process of the recipient and tears them away from whatever they were doing. Your boss comes by, "Got a minute?" or your wife calls to check in. Either way, whatever you were working on gets put on hold and you shift focus to the conversation initiator. This also results in switching to a different context, which can impede your workflow. An asynchronous conversation on the other hand occurs on your time. You decide when to check your email and when to respond to your voicemail.

The next time you need something from your husband/wife, consider sending them an email instead of interrupting their work, assuming the need isn't urgent. Also consider that these are not cut and dry categories. If you keep your email open or have your email client pop up with a notification when you receive a new email, your email becomes more synchronous. Maybe you need it to be that way, or maybe you don't. If you don't, you could reduce interruptions by turning notifications off or closing your email, allowing you to focus on your current task.

What do you think? Is there a difference in these communication methods? Do you like to text? Why?

PyCon 2010 Highlights

2010-03-26T20:09:00.003-04:00

I recently attended the fantastic PyCon in Atlanta, GA. It was awesome to see what people were doing with Python and what improvements people were proposing; the Python community is really powerful, and everyone wants to see the language evolve. I learned a ton and had a *great* time.

Top three videos from PyCon that I highly recommend you watch:

Guido's Q&A - At 29:30, Guido makes some comments about functional languages saying he admires them from afar and is interested in what they can contribute to Python.

Relentlessly Pursuing Opportunities With Python, or why the AIs will Spare Us All

Understanding the Python GIL

JD Power Dependability Study Boxplots Per Automaker

2009-07-08T22:30:00.009-04:00

I'm currently searching for a new car, and one of the things that is most important to me is reliability. So I decided to write a little python script to scrape all the statistics from JD Power's website for my own analysis.

While the system is currently being revamped to include data from more sources and persist data in a SQLite database, it will be available here shortly. One of the more interesting things I've done already is create boxplots (also known as box-and-whisker plots) of all the data derived from the Vehicle Dependability Study for each automaker. Data was collected from the "Overall Dependability" score for every car of every year for each automaker and put into matplotlib to make boxplots.

Essentially, these plots show the ranges in dependability scores as well as their general distributions. Each whisker and side of the box is a quartile, with the red line in the middle representing the median. Outliers are marked by plus signs. Higher scores are better.

Because the study is about problems in the first three years of ownership, data includes cars as old as 2001 models and as new as 2006 models. The number of data points for each automaker varies. The data is not guaranteed accurate, though I have no reason to doubt it.

JD Power on the Vehicle Dependability Study:

"Overall Dependability: Taken from the Vehicle Dependability Study (VDS), which looks at owner-reported problems in the first 3 years of new-vehicle ownership, this score is based on problems that have caused a complete breakdown or malfunction of any component, feature, or item (i.e., components that stop working or trim pieces that break or come loose)."

I hope you find the plots as interesting as I did!

OpenSolaris and ZFS: Hardware

2009-04-11T22:03:00.008-04:00

Having heard that ZFS is the last word in filesystems, and after talking to a few people who have implemented it, I decided to take the plunge and set up a test system with intentions of replacing my current Linux fileserver with it.

Solaris (and OpenSolaris) is pretty picky about hardware, but at least there's a hardware compatibility database that is OK to navigate. Here's the hardware I ended up buying:

Intel S3200SHV motherboard - $200
Intel Core 2 Duo E7400 - $110
Hitachi Deskstar 1TB drives x 3 - $85 each
Corsair TX650 PSU - $80 after MIR
4GB Kingston ECC memory - $50
LG SATA DVD drive - $25

These, in combination with some hardware I already had, such as a Seagate OS drive and an Antec Three Hundred case, made up my system.

The biggest decision to make was the motherboard. The S3200SHV was a great choice because it incorporated Intel Gigabit LAN, the Core 2 Duo architecture, and 6 SATA ports. Onboard video was a good thought, but I came to find out it doesn't work in OpenSolaris 2008.11 (more on this later). Intel LAN is important because it's known to work well with OpenSolaris and be very fast. I know the ICH9R bus will be supported and is also very fast.

It has turned out to be pretty good hardware, and I also didn't spend too much.

Which brings us to the one big problem: OpenSolaris 2008.11 does not support the integrated graphics in the S3200SHV. Short version: Buy an Nvidia graphics card. On to the long version... So the graphical installation doesn't work? Well, I can just use the text mode installer right? Uh, no. There is no text mode installer. >_< OK. Intel's OS compatibility guide for the S3200SHV says there is a fix once you get it installed. Googling for a solution, I found you can install it using the GUI using X11 tunneling over SSH.

You can use the GUI installer over SSH by booting the text console, logging in (jack/jack) and assuming the root role (su, with password 'opensolaris'). After this you must start the SSH service and SSH from another *nix machine with the -X flag to forward X11. Then execute 'pfexec gui-install' to launch the installer. Sweet, it's installed to disk. On a side note, it's kind of cool that I can install an OS over SSH with X11 tunneling. But should I have to? NO!

Intel's OS compatibility guide states that for Solaris 10, one must:

"Edit /usr/bin/X11/Xserver and use the following arguments to make color depth not larger than 16 bit: SERVERARGS="-depth 16 -fbbpp 16""

So I rebooted, entered text mode, and followed that simple instruction to change the color depth. Still no luck after rebooting again, so I gave up and ordered a cheap PCIe graphics card from Newegg which was supported from the start.

Hoping that my compatibility issues have all been resolved, I pushed forward with configuration.

If you managed to get the integrated graphics working, please leave me a comment or shoot me an email!

Replacing The Battery In My MX1000

2009-02-27T16:50:00.008-05:00

The battery capacity of my beloved Logitech MX1000 mouse had deteriorated over time. It was lasting only 2-3 days tops before the charge level would turn red, its lowest level. So I decided to find out how I could replace the internal, "non-replaceable" battery.

As it turns out, doing so isn't too bad. There are multiple sites available with instructions. While they are OK instructions, I have a few comments.

I ordered an NP-120 camera battery to replace the one inside the MX1000. Before we put in the new battery, we decided to take apart the old one. Inside the blue casing of the original battery, the three wires are soldered to a small circuit board. It was easy to unsolder the wires, and this allowed us to use the full length of the wire. Having more wire to work with made things a lot easier, because there isn't a lot of room to play with.

It is generally not a good idea to expose batteries to heat, so why would you think to put a very hot soldering iron to it? We came up with a better idea. We cut small strips of brass which we bent into U shapes and soldered the battery wires to the brass plates. Then we put the bent brass plates up against the battery contacts, and held them in place using self-fusing silicon tape. This kind of tape may also be known as "self-vulcanizing tape" although I believe the use of that word is incorrect. The tape isn't sticky at all, but has a layer of plastic which you peel off, allowing the tape to fuse to itself. Before you try to put the battery in the mouse, it is a very good idea to check the contacts by connecting a voltmeter to the socketed end that plugs into the PCB. As usual, red is positive and black is negative.

We ran into more problems when we tried to put the battery back in. It appeared that our tape arrangement had added too much thickness to the battery, and it wouldn't fit very well in the casing. Putting it back together might go well for a bit, but we found it was simply too much when we tried to fit the whole mouse back together. Since we didn't want to change our arrangement of the battery contact, we decided to get rid of the entire battery holder and hot glue the battery to the inside top of the mouse. This ended up working quite well, and the mouse fit together with a snap.

The result is a much better performing MX1000. The battery now lasts a solid 7 days before needing a recharge, and I'm quite happy with that. If I ever need to, I can replace the battery again for $10 and get more life out of a great mouse.

Like hardware hacking? You might try hacking your toner drums to get more life out of them.

Brasero Or: How I Learned To Stop Burning Coasters And Love K3B

2009-02-12T21:08:00.007-05:00

Whenever I burn a CD from an ISO, I md5sum the CD to confirm the data was written correctly. Using the beauty of Linux, I can md5sum the cdrom device directly using "md5sum /dev/cdrom".

One day I was trying to burn OpenSolaris 2008.11 to check out the awesomeness of ZFS. After I burned the disk using Brasero, I tried to md5sum it. I was greeted with a rather strange error: "md5sum: /dev/cdrom: Input/output error". Input/output error? Is my drive going bad? I presumed it was the media. I put in another CD of the same brand and tried again. Nope. The batch of media was pretty old, so I decided to try another brand/batch. Maybe it's my drive? Five coasters later...

At this point I'm starting to think this is a software issue. Was there an update in 8.10 that made this not work? No, it worked on other disks. Googling, I came to this page at BigAdmin which describes the symptoms perfectly.

As it turns out, Brasero was burning the ISO using track-at-once. The problem with this is, as quoted from BigAdmin:

"the last block may be confused with the lead out area, and some drives will not read it properly. Thus your MD5 checksums will fail. You can pad the last blocks using the -pad option of cdrecord, but your checksums still might not match as you have added additional data to the CD that was not present in the original ISO image."

The solution? Make sure to set the record mode to disc-at-once (session-at-once may also work) in your CD burning software. I simply could not find this setting in Brasero, so I installed K3B and found it easily under "Writing Mode". Lesson learned.

Has this ever happened to you? Leave a comment!

Hacking Toner Drums To Get Your Money's Worth

2009-02-11T23:00:00.016-05:00

There has been a recent trend in consumer printers that really annoys me: Printers that lie to the user and report that they are out of ink or toner when they are not.

A couple days ago the toner light started flashing on my relatively new Brother HL-2140 laser printer. It had printed less than 500 pages since I bought it, and I really wasn't too impressed with the starter drum. In addition, the last pages I printed left no indication that the toner was running out. I had heard rumors that there was a way to trick the printer into thinking that the toner drum was full, thus enabling me to continue to print. I pulled information from multiple sites, so I will summarize here:

Turn off printer, unplug
Take out the drum
Find the holes / areas used for detecting how much toner is left.
Cover found holes with something opaque. A small piece of paper and transparent tape works well, as does black electrical tape.
Put the drum back in
Plug in and turn on printer

The holes I reference are probably symmetrical across the drum and may have an optical lens visible. I believe that with my printer, a light or laser is shown through these two holes, sensing if the toner level is below the hole alignment. It is for this reason, and the assumption that this worked on my printer, that I believe the color of whatever used to cover the holes is irrelevant so long as it is opaque.

After doing this to my own printer, the toner light went off, I continued to print about 30 some pages just fine, and everything seems to be working. I've heard of people getting quite a bit more life out of their toner drums using this method, but I'm ordering a new drum to be on the safe side.

Photos of what I did on both ends of the drum:

Did this work for you? Do you know more about how the printer senses the ink level? Leave a comment!

Hackett and Bankwell: A Comic About Linux

2009-02-04T22:41:00.005-05:00

Quite a while ago at the Ubuntu MD Team's release party for Intrepid Ibex, Ron Swift showed the group something really cool: The first issue of an educational comic about Linux called "Hackett and Bankwell." The first issue covers the adventures of characters Woody Hackett (tux) and Jerome Bankwell as they help a documentary production studio install and use Ubuntu. The thing is... it's really not dorky. No, seriously! Check out the first issue in PDF form here.

Hackett and Bankwell Worldwide, related characters, names, and all related indicia are trademarks and copyrights of Intarcorp LTD, licensed by Intarcorp LTD. Image copyright Intarcorp LTD.

Supposed Ubuntu Speedups - Concurrency=shell, readahead profile

2008-12-31T12:07:00.005-05:00

After seeing Lifehacker blog about a number of Ubuntu speedups, I decided to test some of them to see their actual effectiveness.

The test machine was a Lenovo T61 with a Core 2 Duo T7500 @ 2.2 ghz and 3GB RAM. All boot times are from the grub menu (started when I pressed enter to start the boot) to the appearance of the login screen. I started with a completely fresh installation of Ubuntu 8.10 which I updated and rebooted 3 times. The default settings are "concurrency=none" in /etc/init.d/rc, but I'm unsure of the default readahead settings. It's possible Ubuntu tries to create a profile after installation, but I have no proof of that, so I assume there is no profile.

The results:

No modifications (concurrency=none, no readahead profile) - 29.8 sec
Concurrency=shell, no readahead profile - 29.2 sec
Concurrency=shell, readahead profile - 28.7 sec
Concurrency=none, rebuilt readahead profile - 29.2 sec

Also keep in mind all timings are subject to human error. My conclusion is that there are no notable improvements from implementing these tweaks, even with a dual core processor.

Here is my full action log:

Install 8.10
Update
Restart x 2
Restart, timed boot - 30.0 sec
Restart, timed boot - 29.6 sec
Set concurrency=shell in /etc/init.d/rc
Restart, timed boot - 29.9 sec
Restart, timed boot - 29.1 sec
Restart, added "profile" to end of grub line
Timed boot for profile creation - 1 min, 27.7 sec (This is normal)
Restart, timed boot - 28.7 sec
Restart, timed boot - 27.9 sec
Restart, timed boot - 29.6 sec
Set concurrency=none in /etc/init.d/rc
Restart, added "profile" to end of grub line
Timed boot for profile creation - 1 min, 29.1 sec (This is normal)
Restart, timed boot - 29.3 sec
Restart, timed boot - 29.1 sec

Ubuntu boot times - CD vs USB flash drive

2008-11-01T22:08:00.006-04:00

New with Ubuntu 8.10 "Intrepid Ibex" is the ability to create a bootable USB flash drive with a persistent filesystem.

I compared the time to start from when I pressed enter for "Try Ubuntu" until the desktop had loaded with the panel, icons, and wallpaper. Here's what I found:

USB flash drive: 1:44
CD: 2:40

That's a pretty significant improvement in speed! Also, since there's no CD to spin up, anything requiring data off the drive occurs with much less lag. Of course, your results may vary. Transfer speeds on flash drives do vary. I found that my Cruzer Micro 2GB was much faster than a PNY Attache 1GB.

This is so great, one of my flash drives will probably be dedicated to it. :-)

Amazon S3 upload script

2008-10-09T18:34:00.010-04:00

I want to share with you a script I've been hacking on to quickly and easily upload files to Amazon's S3 service. upload_to_s3.py takes the name of the bucket as a parameter, and a list of files to upload from standard in. It is intended to run in the background, and communicates to the user by libnotify/pynotify. When it's done uploading, the clipboard is set with the url(s) to the file(s).

Please note that before using upload_to_s3.py, you must enter your S3 access key and secret access key in the script.

Example usage:

cd /directory/with/media/files/
find | grep -v ".svn" | python /path/to/update_s3.py

The script requires Amazon's S3 Library for REST in Python. As of version 2007-11-05, I had to follow user uuorld's suggestion to modify line 295:

"I found that changing the line
headers['Date'] = time.strftime("%a, %d %b %Y %X GMT", time.gmtime())
to
headers['Date'] = time.strftime("%a, %d %b %Y %H:%M:%S GMT", time.gmtime())
resolved some issues I was having with different locales using 24 or 12-hour clocks."

Big thanks go out to Adrian Holovaty for his script that I hacked on quite a bit. See his blog post here.

As always, please feel free to email me comments or suggestions about the code.

I'm using this script to incorporate right click uploading into Thunar. Here's how I'm doing it:

* Edit -> Configure Custom Action - > New
* Name: "Upload to S3 random"
* Command: `echo %f | python "/path/to/upload_to_s3.py" bucket` (You need to change the path and the bucket. Do not include the backticks.)
* Icon -> Action Icons -> gtk-go-up
* Appearance conditions -> All except directories

Unfortunately, I don't believe you can use a custom action to upload multiple files using this script because Thunar space delimits the paths. When your paths have spaces, you can no longer separate each file.

Enjoy!

UPDATE:
It seems S3 has become more strict about the headers required in file upload, so this script needs a minor patch to add the Content-Length header. In the conn.put call, add

'Content-Length': len(filedata)

to the data dictionary.