Hacking the Tux Droid

Rockhopper writes "Ars Technica has a combo review/hack guide for the Tux Droid, a programmable penguin. 'Tux is completely programmable at practically every level, and all of the source code of the firmware and software used by the droid is available from Kysoh's version control repository. There are several ways to program the droid's behavior, ranging from modifying the firmware to coding a gadget in Python.' There's a sample Python script that will cause Tux to speak IRC messages out loud when the user's name is mentioned."

Tux' voice

[Ethanol-fueled]

I wonder if any hacks include changing the Tux Driod's idiotic voice. Imagine how much cooler the Tux Droid would be if it sounded like Clint Eastwood or even Shaft!

Non Programmer

[Barkmullz]

Being a network and security kind of guy, the first thing that went through my head was:

- Finally, a fun way for me to really learn some Python

Re:Seriously?

[grumbel]

Th problem with rebooting to solve problems is that it doesn't solve the problem,

That depends on the problem, there are dozens of easy ways to mess Linux up in a way that a reboot will fix the problem.

Simple example, take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again. LVM thinks the thing is still at /dev/sde and reports read errors when you try to access it and even when you try to deactivate the volume group, plugin it in doesn't fix the problem because it is now /dev/sdf, sde is busy with being a dead zombie in the kernel internals. How to fix the issue? Simple, you reboot. Maybe there are other alternatives on how to fix the problem, but reboot is by far the most obvious one and it also works perfectly. Next time one should of course remember to vgchange -a n the volume group before unplugging, but if shit has already happened a reboot fixes it.

Other example, every few dozens reboots my computer tends reorder the USB device names what was event1 before now is event2 and vice a verse, this in turn causes Xorg to fail to startup properly because xorg.conf now points to the wrong devices. Fix? Again, reboot. USB just happens to be not 100% deterministic and when it does something different, reboot can fix it. Sure, I can still take the man page and start to configure udev to assign proper names to the devices so that I don't depend on the order they are detected, but that isn't something I expect average Joe to do, because the problem just happens to seldomly and reboot just fixes it.

Yet another example: Xorg freezes, locks up or otherwise becomes unresponsive, even to console switching. Now I can of course boot another computer and try to ssh into the machine to fix it, but reboot again is the easier alternative.

All that said, if something goes wrong in Linux repeatably it can be worth to investigate, but if the computer just started to craze out a reboot is often the easier alternative.

Re:Perfect cadget to connect to the integrationser

[linhux]

We might just do that. After all, we are already announcing broken builds on a LED sign and with sound effects [f-secure.com]. :-)