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."
attempt of Linux to enter the porn toy market. Sqwuaak!
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!
I, for one, welcome our robotic Tux overlords.
One that hath name thou can not otter
Does it run Linux?
Give me Classic Slashdot or give me death!
Can you make it speak swear words? That'd rock.
Why the hell would you wanna do something shitty like that, fucktard!
-1 Flamebait
Table-ized A.I.
When I told it to get the Gentoo wireless drivers to work properly on my old laptop, it ran across my desk, and flipped me off as it started humping my Opus doll.
__ Someday, but not this morning, I'll finally learn to use the preview button.
Maybe it can even be... a friend?
You plan to glue tits on it, don't you?
Table-ized A.I.
Th problem with rebooting to solve problems is that it doesn't solve the problem, it just lessens the symptoms. In the windows world, the problem was typically memory management. But just like in the linux/BSD world, it can be other things like programs having rogue functions with unintended consequences when other programs or services are running.
Anyways, Rebooting doesn't fix the problem, it only removes the symptom which mean you should still look for the cause whether your running windows or linux. In linux, or any *nix stile OS, there should be little reason to restart the system because of something your doing. It is just designed that way.
"Your plastic pal who's fun to be with!"
Guaranteed! This comment 100% Anthrax free!
Stop stealing my ideas.
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
Ronald said nothing. He flung himself from the room, flung himself upon his horse, and rode madly off in all directions.
I didn't know. http://www.thinkgeek.com/geektoys/rc/9df0/
I record my sleeptalking
I was curious so I looked up the embedded system inside the robot, it's an 8-bit Atmel AVR with supporting hardware. I figured that the Tux-shaped robot would at least be running Linux internally, for example they could have used a Gumstix board or the like. That said, AVR development is pretty fun (and you get to use gcc rather than some vendor tools) and this thing looks like a neat embedded toy.
"It's only a matter of time until some demented furrie uses tux's "talk" feature for the purpose of fellation."
Tuxjob?
oh my admin that feels so good
oh yeah, oh oh slow down, oh yeah
oohh yeah!
who's your data! who's your daataa!
oh my admin
oh now play with my tarball, play with my tarball
ohhh that feels so good
now just compress them into a gzip
ohhhh my admin I love it when you
uh-oh slow down
u.. u.. ooooooooohhhhhhhhhhh
don't mv
I'll go get you an fsck
To do something right, you often have to roll up your sleeves and get busy.
HAHAHAHHAAHAH! For those of you who don't get it, the parent's comment was an allusion to duckjob.
And, have it scream, while flapping its wings, "Dudes! broke the build with commit !", whenever appropriate.
:-)
:-)
I reckon it will be no problem getting the bosses to pay for that
Or, "its time for lunch", "remember the team meating in 5 minutes", and other stuff.
I am halfway serious, actually.
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
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.
We might just do that. After all, we are already announcing broken builds on a LED sign and with sound effects. :-)