But if you’re a The Office fan AND a bored student, now we’re cooking. In a lot of the IRC channels I hang around in, That’s What She Said (twss) jokes are extremely common. In fact, I even have a /twss alias for making them. So… I wonder, can I make a bot that recognizes innuendos? After 2 hours of Python coding, the results speak for themselves:


14:10 < jdong_> blah blah this isn't funny at all
14:11 < jdong_> I hope you aren't coming in here
14:11 < twssbot> jdong_: That's what she said!
14:11 < jdong_> can you make it straighter?
14:11 < jdong_> That's what she said!
14:11 < twssbot> Autolearning (cancel: 'twssbot: wrong'): can you make it
straighter?
14:12 < jdong_> this is easier to train than I thought
14:12 < jdong_> It just comes naturally
14:12 < twssbot> jdong_: That's what she said!


It still needs some training but already it’s showing great promise. You can play with it (twss) in ##friedcpu on irc.freenode.net. Its source is more or less available at bzr branch http://jdong.mit.edu/~jdong/pytwss/. Being a quick hackjob, don’t expect the code to be that clean or setup to be that intuitive. Sorry.

UPDATE: I was asked if this is how MIT students spend their free time. Well I can’t speak on their behalf, but… probably?

How does it work

I won’t cover how Bayesian classification works, as I trust if you remotely care you would have read the Wikipedia page. As it applies to the bot, it was given examples of “that’s what she said” jokes, and examples of ordinary nonsuggestive sentences as a starting point. Ok, fine, admittedly its initial examples were just the line before someone said TWSS in an IRC channel I log (which was 60MB last year…), so I expect 50% of that to be random noise.

In addition, the bot can:

1. Be commanded to learn a phrase as an innuendo or a normal sentence through a direct command
2. Be given feedback (yes or no) by others after it made a joke, so it train itself based on feedback.
3. Detect when someone in the channel says TWSS, and tries to find and learn the joke made.

With these capabilities, I expect it to be able to train and adapt and become better as people correct it more.

Command Reference

The bot has a pretty crappy command set that gets the job done. I will attempt to document it here. All commands MUST be directed at the bot using twssbot: command parameters.

• twssbot: learn this is long and hard –Train the bot that “this is long and hard” is an innuendo.
• twssbot: forget this is not funny — Train the bot that “this is not funny” is NOT an innuendo.
• twssbot: yes — If the bot recently said TWSS, reinforce that the joke it last made was funny.
• twssbot: no — Opposite of above. Tells the bot the last joke it made was not funny.
• twssbot: query some funny sentence — Dumps some debugging info about “some funny sentence” as a dictionary of conditional probabilities. For example, its reply {’twss’: 0.39338996689047478, ‘normal’: 0.7999888342822} tells you that it is 40% confident it is an innuendo and 80% confident it is a normal sentence.
• (not a command): Saying “That’s what she said”,”That’s what he said”, “twss!”, “twhs!”, “(twhs)”, “(twss)” in a channel causes the bot to take a best guess at the sentence someone found funny. The bot will then tell the channel it is auto-learning that expression.
  • If the trigger phrase was prefixed with a nick (i.e. “jdong: twss!”), the bot will ONLY consider things said by the nickname above
  • If it finds no candidate phrases it will tell the channel it didn’t get the joke. You should probably manually train it with the learn command.
• twssbot: wrong — Tells the bot that its auto-learn guess (see above) is NOT correct; this rolls back the training above.

In addition to commands, the bot also has some tunable parameters:

• twssbot: threshold 25 — Sets a confidence-margin percentage between 11 and 49 for triggering. In this example, the bot must be 25% MORE confident that a sentence is an innuendo than a normal sentence for it to trigger. If you don’t give a number, it will return the current threshold. Increase this number to reduce false alarms, decrease it for comic relief.
• twssbot: trigger_length 3 — Sets the minimum length (in words) of a line for it to be processed. Sometimes really short statements (a word or two) set off the bot even though it is not suggestive.

Practical Uses

This bot is silly, pointless, though entertaining. However, I think this same framework for Bayesian classification is really easy to use (see Reverend library link in acknowledgments) and can be  applied in a variety of daily uses:

• Detecting the language of an article
•  Detect if something said is on-topic or off-topic for a channel
• Label incoming e-mails or RSS feeds
• In IRC, detect trolling users or unusual behavior patterns
• Making a That’s What He Said bot (kidding!)

Acknowledgements

I’d like to thank the authors of the Reverend library, without whom it would have taken me several more hours to write a (crappier) Bayesian inference library. I’d also like to thank pyircalib for making such an easy to use IRC library. Both of these were ridiculosuly simple to set up and if you ever want to use Bayesian classifiers or a simple python IRC app, I highly recommend these!

This first part is an introduction to the big-picture idea of what we are trying to do. I’ll explain in simple terms the problem with traditional privilege models used in most OS’es today, along with a solution. I will then close off with a simple real-world example to show how simple this can be in practice.

The Problem

Exactly what threat are we up against? Well, allow me to describe a recent real-world example that has happened too many times in the past:

VLC media player contains an unchecked buffer which allowed an attacker to craft a malicious video file. An attacker sends the victim a video file. The user opens it up and the video file exploits this hole in VLC to read the user’s SSH private key and send it to the attacker. With this in hand, the attacker is able to log into many of the victim’s SSH machines.

What is wrong with this picture?

The astute reader should be asking in outrage: What the HELL is VLC media player doing reading private SSH keys? How could the operating system allow this to happen? Well, let’s use UNIX 101 to see why. This is what VLC looks like running on my system:

jdong     7603  3.0  0.5 378660 23040 pts/1    Sl+  09:24   0:00 vlc

The first column says that I, jdong, own the VLC process. What do the permissions on my SSH key say?

-rw——- 1 jdong jdong 1264 2007-10-01 12:50 /home/jdong/.ssh/id_dsa

Again, I own my SSH key. Note the tight  -rw——- permissions that are required and default on a SSH key: only the owner is allowed to have any access to it. Let’s read that again:  only the owner is allowed to have any access to it. But, VLC’s process is owned by me, jdong, the same person as the SSH key. The OS puts 2 and 2 together and says that VLC has access to my SSH key.

What this example shows is that the UNIX permissions scheme is not fine-grained enough to allow me to specify the minimum amount of access VLC has to my system. Ideally, I’d like to tell VLC it can read my Videos directory, but NOT my Documents/Tax Forms directory

The Solution: AntiVirus edition

What is the AV solution to this problem? Write an AV signature to recognize the malicious video file that caused this exploit. While that sounds good in theory, it should be clear to see why this idea is ridiculous. Do we stop terrorists by compiling a big list of pictures of known terrorists, distribute the list to the TSA and if a person at the security checkpoint doesn’t look like anyone in the list, he’s not a terrorist? Ok fine, we do, but how well is THAT working out?

While this approach can be useful for blacklisting individual types of exploits, what if tomorrow a different hole is found in VLC? You’d have no protection against that exploit until your AV vendor figures out.

The Solution: AppArmor Edition:

The solution I’d like to propose is to be able to define finer grained permissions that I hinted to earlier. I want to tell Linux: VLC Media Player can access ~/Videos and its own data. It can write to its preferences directory. It CANNOT touch anything else, launch any other processes, su to root, etc. A rule like this would universally stop a wide class of exploits against VLC.

Quick Intro to AppArmor:

I’ve used the name of the product but I haven’t really said what it is. AppArmor is known as a Mandatory Access Control mechanism for Linux. What that means is basically it allows you to specify finer grained permissions on stuff running on your system than the traditional ownership-permissions model. It is Open Source software, and installed by default on Ubuntu and OpenSUSE. It’s known for being relatively simple to configure for restricting a select set of at-risk services and applications.

AppArmor works inside the kernel based on configuration files known as AppArmor Profiles stored in /etc/apparmor.d. The tricky part of configuring AppArmor is writing a profile that gives the right level of access that allows your program to do its work, but not pose a security threat to the rest of your system.

What about SELinux?

RedHat/Fedora users are probably thinking at this point: Wait a minute, isn’t that what SELinux is? Yes, you’re right! SELinux is another framework that’s in the vanilla kernel and default in RedHat Enterprise Linux and Fedora which accomplishes similar goals to AppArmor. It’s much more powerful and allows even more fine-grained permissions control, and even offers other neat features like Role-Based Access Control which allows you to have a different set of permissions depending on what you’re doing at the moment. I plan to cover SELinux in detail at a later time, too.

Our Example: myscript

Ok, now that we know what AppArmor is, and why we’d want to use it, I figure it’s better to explain the rest in practice instead of all this hypothetical talk. Let’s try a simple example to illustrate how AppArmor can work to save our rear. Suppose I have a simple Python script called myscript

#!/usr/bin/python
import os
print "Welcome to MyScript!"
foo=raw_input("Please give me the name of a file to md5sum:")
os.system("md5sum "+foo)


Ok, so it’s supposed to do something useful (calculate md5sums) but is poorly written. Perfect recipe for disaster! Let’s see what it does when it works:


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:12)
Welcome to MyScript!
Please give me the name of a file to md5sum:myscript
9149480416db480c99f4f95b79fda227 myscript


Cool! It works! Or does it work TOO well:


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:16)
Welcome to MyScript!
Please give me the name of a file to md5sum: /dev/null;bash
d41d8cd98f00b204e9800998ecf8427e /dev/null
jdong@droptop:~/code/myscript$ whoami
jdong

Ahh, when foo; bar gets passed to os.system, bar is executed as if it were a separate command. Yikes, we spawned an arbitrary shell!

The Solution: AV Style

Luckily for me, I am the author of award-winning jdong Antivirus ™, so I incorporate my advanced AV engine in myscript:


#!/usr/bin/python
import os

print “Welcome to MyScript!”
foo=raw_input(”Please give me the name of a file to md5sum:”)
if “;” in foo:
print “BZZ! JDONG ANTIVIRUS FOUND MyScript.ShellEscapeExploit!”
else:
os.system(”md5sum “+foo)
Does that work? Let’s see:


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:22)
Welcome to MyScript!
Please give me the name of a file to md5sum:/dev/null; bash
BZZ! JDONG ANTIVIRUS FOUND MyScript.ShellEscapeExploit!

[jdong@droptop:code/myscript]$ ./myscript (12-05 10:27)
Welcome to MyScript!
Please give me the name of a file to md5sum:/dev/null && bash
d41d8cd98f00b204e9800998ecf8427e /dev/null
fjdong@droptop:~/code/myscript$ id
uid=1000(jdong) gid=1000(jdong) groups=4(adm),20(dialout),24(cdrom),44(video),46(plugdev),108(lpadmin),116(pulse-access),117(pulse-rt),123(admin),124(sambashare),127(libvirtd),1000(jdong)


Well, the typical problem with AV signature based approaches — I slightly changed my attack and the signature no longer matches. Note that myscript is doing the same thing wrong, executing bash when it shouldn’t have the ability to, but a different way. Again, an AV doesn’t care what is being done, just the exact way how it is doing it. Even worse,it gets REAL hair when I start talking about files with ; or & in the filename — at some point the AV will have to trade off between false-positives and completeness of detection.

The solution, AppArmor style

Since this is a motivational introduction to Apparmor, I’ll just present the solution without gory details on how I did it. I’ll link to some resources for those who want to know NOW but next week’s installment will go through step-by-step a more useful example.

So, instead of blocking bad input, I will use an AppArmor profile to rigorously define what myscript should do. We make the following observations:

1. MyScript uses Python. So, it probably needs access to the Python interpreter and the Python libraries.
2. MyScript executes md5sum. So, it probably needs access to /usr/bin/md5sum and perhaps /bin/sh because of the way os.system works (not intuitively obvious). It shouldn’t have to execute anything else.
3. MyScript NEVER has to write anything but to the screen.
4. Suppose MyScript is for checksumming my media collection and itself.  Hence, it should only be able to read ~/Videos and ~/code/myscript.

With these rules, we can concoct an AppArmor profile, like the one I prepared. This is /etc/apparmor.d/home.jdong.code.myscript.myscript after about 10 minutes of work:


# Last Modified: Fri Dec  5 10:41:50 2008
#include <tunables/global>


/home/jdong/code/myscript/myscript {
#include <abstractions/base>
/usr/bin/python2.5 ixmr,
/home/jdong/code/myscript/* mr,
/home/jdong/Videos/*/ mr,
/home/jdong/Videos/** mr,
/usr/share/pyshared/** mr,
/usr/local/lib/python2.5/** mr,
/usr/local/lib/python2.5/*/ mr,
/usr/lib/python2.5/** mr,
/usr/lib/python2.5/*/ mr,
/var/lib/python-support/*/ mr,
/var/lib/python-support/** mr,
/bin/dash ixmr,
/lib/* mr,
/usr/bin/md5sum ixmr,
/etc/python2.5/** mr,
}

Now, what does it do? Let’s try our normal workflow:


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:50)
Welcome to MyScript!
Please give me the name of a file to md5sum:myscript
9149480416db480c99f4f95b79fda227 myscript

Well, that still works. Shall we try an exploit?


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:53)
Welcome to MyScript!
Please give me the name of a file to md5sum:myscript; bash
9149480416db480c99f4f95b79fda227 myscript
sh: bash: Permission denied

What the heck? Permission denied? /bin/bash is chmodded 755, everyone can access it, right? Not according to AppArmor and dmesg:


[ 7487.802336] type=1503 audit(1228492429.848:201): operation="inode_permission" requested_mask="::x" denied_mask="::x" fsuid=1000 name="/bin/bash" pid=9671 profile="/home/jdong/code/myscript/myscript"


So, AppArmor is telling us that myscript has no access to /bin/bash. Attack averted. The observant reader will ask: But you allowed access to /bin/dash, can’t we still exploit that? Good question, let’s try!


[jdong@droptop:code/myscript]$ ./myscript (12-05 10:54)
Welcome to MyScript!
Please give me the name of a file to md5sum:myscript;/bin/dash
9149480416db480c99f4f95b79fda227 myscript

ls
^C
^C^C^C^C^C^C^C^Z^Z^Z^Z^C^C


Well… that did something different. What exactly happened? Let’s ask dmesg again:


[ 7651.571036] type=1503 audit(1228492593.617:202): operation="inode_permission" requested_mask="::rw" denied_mask="::rw" fsuid=1000 name="/dev/tty" pid=9712 profile="/home/jdong/code/myscript/myscript"
[ 7655.969245] type=1503 audit(1228492598.017:203): operation="inode_permission" requested_mask="::x" denied_mask="::x" fsuid=1000 name="/bin/ls" pid=9714 profile="/home/jdong/code/myscript/myscript"

In English:

• dash was started, no error generated of course.
• However, apparmor denied its right to open the terminal at /dev/tty to output to the screen, and accept special terminal input such as CTRL-C.
• It did hear me say ls,  but AppArmor said it has no access to ls.

Well that’s effective, but no fun! For amusement’s sake, I’ve allowed access to /dev/tty so it’s easier to see what an attacker of myscript has the access to do:


[jdong@droptop:code/myscript]$ ./myscript (12-05 11:19)
Welcome to MyScript!
Please give me the name of a file to md5sum:/dev/null;/bin/dash
d41d8cd98f00b204e9800998ecf8427e /dev/null
[%{%}%n%{%}@%{%}%U%m%u%{%}:%{%}%2c%{%}]%(!.#.$) export PS1="#"
#ls
/bin/dash: ls: Permission denied
#echo foo
foo
#echo "foo" > myscript
/bin/dash: cannot create myscript: Permission denied


Well, now that we can see the shell’s output, we can see that this is really an anticlimactic end to an exploit. From this shell, we can only run dash again or execute shell built-ins like echo or redirections. Since we don’t have write access anywhere, we can’t even overwrite myscript with redirection. Now we’re having fun, aren’t we? Let’s ramp it up: I’m going to add rmix permissions /bin/* and /usr/bin/*, which will allow us to execute the standard UNIX commands , as an ultimate demonstration of AppArmor’s power:


[jdong@droptop:code/myscript]$ ./myscript (12-05 11:24)
Welcome to MyScript!
Please give me the name of a file to md5sum:/dev/null;/bin/bash
d41d8cd98f00b204e9800998ecf8427e /dev/null
bash: /etc/bash.bashrc: Permission denied
bash: /home/jdong/.bashrc: Permission denied
<2m%}%U%m%u%{%}:%{%}%2c%{%}]%(!.#.$) export PS1="$"
$ $ls -al
ls: cannot open directory .: Permission denied
$ls -al myscript
-rwxr-xr-x 1 1000 1000 235 2008-12-05 10:50 myscript
$rm myscript
rm: remove write-protected regular file `myscript'? y
rm: cannot remove `myscript': Permission denied
$echo "foo" > myscript
bash: myscript: Permission denied
$ls /
ls: cannot open directory /: Permission denied
$find /
/
find: `/': Permission denied
$ping google.com
ping: unknown host google.com
$wget http://localhost/
wget: Cannot read /etc/wgetrc (Permission denied).
--2008-12-05 11:26:27-- http://localhost/
Resolving localhost... failed: Name or service not known.
wget: unable to resolve host address `localhost'
$wget http://127.0.0.1/
wget: Cannot read /etc/wgetrc (Permission denied).
--2008-12-05 11:26:35-- http://127.0.0.1/
Connecting to 127.0.0.1:80... failed: Permission denied.
Retrying.
...
$sudo
sudo: uid 1000 does not exist in the passwd file!
$su root
$id
uid=1000 gid=1000 groups=4,20,24,44,46,108,116,117,123,124,127,1000

As you can see, even with the ability to execute every command on the system, you STILL can’t do anything useful. Note that wget and ping don’t work and su seems to fail silently. dmesg is interesting for those cases:


[ 9438.556736] type=1503 audit(1228494380.604:256): operation="socket_create" family="inet" sock_type="dgram" protocol=0 pid=10298 profile="/home/jdong/code/myscript/myscript"

[ 9453.934059] type=1503 audit(1228494395.980:263): operation="socket_create" family="inet" sock_type="stream" protocol=0 pid=10304 profile="/home/jdong/code/myscript/myscript"


[ 9512.316953] type=1503 audit(1228494454.364:291): operation="capable" name="setuid" pid=10317 profile="/home/jdong/code/myscript/myscript"
[ 9512.316958] type=1503 audit(1228494454.364:292): operation="capable" name="setgid" pid=10317 profile="/home/jdong/code/myscript/myscript"

In English these 4 errors are showing:

1. socket_create is a POSIX capability to create network sockets. I never granted this privilege in AppArmor to myscript, so MyScript is actually incapable of any network access period.
2. setuid and setgid are also POSIX capabilties that MyScript doesn’t have. Therefore, it can’t even use a freebie su-to-root to elevate its access.

Ready to see something even cooler?


[jdong@droptop:code/myscript]$ sudo ./myscript (12-05 11:28)
Welcome to MyScript!
Please give me the name of a file to md5sum:/dev/null;/bin/bash
d41d8cd98f00b204e9800998ecf8427e /dev/null
bash: /etc/bash.bashrc: Permission denied
bash: /home/jdong/.bashrc: Permission denied
<2m%}%U%m%u%{%}:%{%}%2c%{%}]%(!.#.$) export PS1="# "
# ls
ls: cannot open directory .: Permission denied
# whoami
whoami: cannot find name for user ID 0
# id
uid=0 gid=0 groups=0
# ls -al myscript
-rwxr-xr-x 1 1000 1000 235 2008-12-05 10:50 myscript
# rm myscript
rm: cannot remove `myscript': Permission denied
# su
# su jdong
# id
uid=0 gid=0 groups=0
# ping google.com
ping: unknown host google.com

Yes, you are reading that correctly: even with free root access, myscript still can’t do anything. Not even root is immune to AppArmor. And without write access to /sys, root can’t even disable AppArmor.

In conclusion, and coming soon…

I hope this introduction has shown why technologies such as AppArmor and SELinux can provide a robust level of protection against a wide range of threats, better than an AntiVirus program can. I hope it also shows that the general concept and process of doing so is simple. Next time, I will provide a step-by-step walkthrough of a lengthier, more useful example: Bodhi-Zazen recently posted a HOWTO on using rbash to restrict shell users to a safe set of commands. I will show how I broke free of the jail in 10 seconds and was snooping around the rest of the system, and how AppArmor can be used to robustly provide users restricted SSH access.

In the meantime, if you really want to get started writing some AppArmor profiles, OpenSuse and Ubuntu both have great step-by-step guides.

What do I protect with AppArmor? I have rigorous profiles defined for:

• Skype
• Firefox
• my fetchmail script
• my script-rich irssi client
• Apache
• dnsmasq

These are the services I’ve identified to be at the greatest risk on my system for this class of exploits.

What I wonder is how many other distros:

(1) Use a FIPS 140-2  hardware crypto signing key to protect key material from compromise

(2) Have as big  of an attacker base as Fedora/RHEL

(3) Would’ve caught the breach so quickly

(4) Would’ve restored services so quickly

If there’s one thing to criticize about this whole incident, it’s the lack of details from RedHat. I’d be interested in learning more about the technical details behind this attack, but I bet RedHat is planning legal action that prevents these details from coming out at the moment.

In any case, I’d like to just say that I’ve not lost any trust in RedHat’s information security procedures. If anything, the way this incident was detected and handled has bolstered my trust in those talented folks. Good luck to the team on restoring their services smoothly and bringing justice to the attackers.

I choose the $199 black 8GB model, which took about a week for them to order and ship to the store. It’s almost my first full week with the phone and I’d just like to talk a bit about my experience with the phone. I know everyone is sick and tired of iPhone 3G reviews so I’ll keep it short and crisp.

(more…)

Spoiler Alert: The next post from me may contain some Linux rants and Apple fanboyism. Or not.

According to a post on the Chumby forums by a Chumby employee, “the device has a 266MHz Freescale ARM9 with 133MHz bus, 32MB SDRAM and 64MB of NAND Flash.” It also has two external powered USB ports and a headphone jack on the rear of the unit, along with the power connector and a power button (be careful grabbing it by the back when moving it; I’ve turned it off accidentally once). Another interesting thing to note is that the unit’s wifi is actually a USB 802.11g dongle on the inside of the device, which means you can replace it if need be. There is also a second powered USB port on the inside which is not in use. Lots of room for expansion on this thing.

The other great thing about the Chumby, before we go into my personal experience with it, is that 100% of the software running the thing is either GPLv2 or LGPLv2.

Inside the shipping carton was a plastic sleeve sealed with a Chumby logo sticker, and inside that was the burlap or canvas bag that contained the Chumby and all its accessories. The entire package has a “recycled materials” feel to it, from the coarse fabric bags that contain the product to the recycled paper manual. If you’re the sort of person who uses the phrase “carbon footprint” in normal conversation, you will likely be pleased at the packaging in which the Chumby arrives.

Being the type of person I am, I immediately discovered a velcro-sealed pouch in the bottom of the unit that contained a connector for a 9V battery, one of which I happened to have laying on my desk. The Chumby powered up right away and I set about watching the introductory video that plays on first boot. Shortly thereafter the problems set in.

Now to be fair, I should say up front that I wasn’t thinking about some things. Like how a puny 9V battery isn’t going to power something with an LCD display for very long…and it didn’t. However, going back to my bedroom and plugging it in near the night stand that is now its permanent home, I was having a lot of trouble getting a wireless signal.

My wireless router is probably 30′ in a straight line from the Chumby and the signal has to go through one or two internal walls to reach the Chumby if my door is closed, which it usually is (roommates). It grabbed a signal and an IP address early on, but then would fail to reboot properly. Upon trying to regain connectivity, it would fail — over and over and over. I took the unit out to my work area and plugged it in so it was within a couple feet of the WAP, where it proceeded to function flawlessly (except when I had it on rapidly-draining 9V power only, when it would make awful stuttering static noises and shut down).

Eventually I got it to grab a signal from my bedroom and it hasn’t lost it again (about 25 hours now). So just be aware that you may experience some issues when you first get it out of the box. Not sure if it just needs burn-in time or what, but it’s run beautifully since.

After you activate the Chumby, a process which consists of tapping the screen to replicate a pattern shown on the Chumby site, you can begin to have fun with it. There are several hundred widgets available already, including 67 clocks, and you can have multiple “channels” containing unique widgets. I currently have a “Clocks” channel with about 10 of my favorite clock designs (a bunch of BBC TV clocks from the 80s, a Nixie tube clock and some other retro stuff), a “Productivity” channel with a Google calendar applet and a mail checker, and the stock “Default” channel where I literally dump anything and everything that looks remotely interesting.

“Neat, it’s a $179 clock. Big deal,” I hear you saying. It’s a bit more than that. Admittedly, I don’t use the news and RSS widgets as much as most people probably will. Why not? Well I usually have my MacBook sitting right here next to me, so I prefer to read news on the Mac’s larger screen. But I’ve been able to offload 100% of my internet radio needs to the Chumby. It has a built-in SHOUTcast browser, Mediafly podcasts, “Radio Free Chumby” which has a load of FM stations that broadcast via web and you can even plug your iPod directly into one of its two USB ports and play songs from it.

All of the widgets are Flash 7 movies, so it’s possible to author a widget with anything that can produce Flash, not just Macromedia’s proprietary (and usually Linux-hating) tools. This is good news, and I can’t congratulate the Chumby team enough for making such good choices when it came to licensing and implementation of widgets.

The unit can be converted to use wired ethernet with very little work and at least two particular models of 10/100 dongles, a Linksys and a Trendnet, are known to work with it. You can ssh into the unit easily enough, by activating what amounts to an easter egg, as well as perform all sorts of other hacks. These are detailed on Chumby’s own wiki. It runs its own webserver which can be accessed by entering its IP into a web browser, but the only content is a summary of wifi information.

Now, to delve into some of my complaints with Chumby:

The touch screen is a bit “meh.” It works, and it works well enough, but sometimes I find myself having to press a button five or six times before it finally registers, and this occurs whether I use my thumb or my forefinger, pad or fingernail. This seems to be exacerbated when I’m laying down (start using one, you’ll see what I mean) but sometimes even if I’m sitting up and holding it directly in front of me it still gets iffy. It works for the most part and you can recalibrate the touchscreen as and when necessary.

Centralized widget control is the other issue. All widgets for general consumption have to be approved by Chumby and placed on the Chumby Network. This isn’t so bad, but it smacks of Apple’s “all your iPhone applications are belong to us” nonsense they tried to pull (looks like they can’t really enforce this, however, which is good news). I like quality control, but I like choice, too.

“Seeing extra widgets on your chumby that aren’t shown in your channel above? These are added by Chumby Industries and content partners. Sharing these promotional widgets with you is how the Chumby Network stays FREE.” That was a message that gave me some cause for concern. I understand that bandwidth isn’t free, but I did pay $180 for this thing. Having seen some of these nefarious widgets, I have to say that they’re really not so bad. The ad content disappears in under 30 seconds and you’re not forced to watch the advertisment videos…this is a good compromise and I’m certainly not begrudging Chumby Industries their meal ticket.

As you can see, my complaints with the device are minor. I was pleasantly surprised by how little about the thing irked me at all. Instead of having to grumble about ads, centralized control and a flaky touchscreen, I’ve just been enjoying the hell out of it instead. I think you will, too, if you get one. The only way to really experience it is to use one. I’m glad I bought mine. (4.5/5 rating)

You can find a bunch of videos of Chumby unboxings and other things that are probably way better than the one I tried to shoot on, where else, YouTube.

You can read the nuts and bolts of its usage on the Debian page, but it’s quite easy. I’ll use an example based on what I originally wanted it for (being able to paste file listings of various directories into a pastebin or document):

ls -al /media/storage2/Comedy/* | xclip

You can retrieve what went into the “clipboard” by running xclip -o, which will paste back into the terminal whatever you copied using the example above.

Unfortunately what it did not do was save the output to the regular “X” clipboard (where items normally go when you highlight and do a Ctrl+v or Ctrl+x in the GUI or Ctrl+Shift+c/x in the console), which is what I was expecting, but this is easily remedied. In order to do that, we must run the following:

ls -al /media/storage2/Comedy/* | xclip -selection c.
(To paste from the X clipboard it’s simply a matter of running xclip -selection o, but you can also just use Ctrl+Shift+v)

xclip supports a lot of extended features such as split clipboards (which I’m still not quite sure what those are), but I mainly wanted to use it for grabbing file listings. So all I did was make an alias by running:

alias xclip='xclip -selection c'

Now when I pipe output to xclip I can quickly switch to my web browser or document, hit Ctrl+v and my console output appears in a pastebin or whatever else i’m working on. It’s quite handy for both writing technical documents and for troubleshooting. Pastebin is the darling of IRC idlers, and this just made it easier.

I didn’t bother with aliasing “xclip -selection o” simply because I can just use Ctrl+Shift+v and paste back into the console from the X clipboard as mentioned above.

Hopefully that wasn’t too confusing. Use it a few times and it becomes a lot more intuitive. I certainly like it, especially for large outputs that would exceed the scrollback buffer (I use the Awn Terminal Applet constantly, which has a small buffer).

However, in many cases, the console is much, much faster if you know what you’re doing. A friend of mine said to me just tonight, “you have a tendency to insist CLI is better just because you’ve spent the time learning how to use it.” He’s exactly right. I’ve spent countless hours reading man pages, howtos, tutorials and change logs because I realized early on in my UNIX-like OS “career,” that the console could open up some very powerful opportunities for me if I only took the time to learn how to use it effectively.

Older hardware can also benefit immensely from a console-heavy environment, although it need not be entirely text-based. But when you have a 300MHz Pentium II with 128MB RAM you probably don’t want to run a full GNOME desktop, Azureus and Amarok. But with command line utilities and a bit of know-how you can still use that machine very effectively (I even had good success selling PII 300MHz with 128MB RAM and Windows XP as “web/email laptops” in 2004, so imagine what you can do with a bit of Linux console magic!) .

Some of my favorite console applications, both old and new, include irssi, the IRC client I absolutely cannot live without, rtorrent, mplayer, screen (which is incredibly powerful and useful when combined with other CLI apps), finch and, of course, ssh. We’ll explore these and others in a series of article I intended to write and I’ll do my best to provide links to the wealth of other sites that provide much better articles than I ever could. I hope to learn a lot more myself during the process, so you won’t  be going it alone!

I am not a console expert. I’ve only been using Ubuntu for just over 16 months, although I did mess around with several versions of Red Hat in the late 1990s, when Linux did not support internal modems much at all, and I didn’t own an external serial modem. Somewhat ironically, I became reintroduced to the console courtesy of Mac OS X which I began using in 2005 and by the time I began using Linux again in earnest I was hooked. Now I know enough to get around in the console of most Linux distribution, BSD and Solaris. But I have much, much more to learn.

So stay tuned for several updates per week in which I investigate new console applications and utilities. You’ll be a “console snob” in no time!

If you’re likin’ my more web2.0 posts though, you can continue to read them here.

EDIT:

If you’re interested in more Apple posts from me, try The Brainchip.