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."

Comments

Yet another...

[Anonymous Coward]

attempt of Linux to enter the porn toy market. Sqwuaak!

Re:Yet another...

[larry bagina]

no shit. How many other people thought about shoving a greased up tux droid up their ass? well, you're thinking about it now!

Re:Yet another...

[Anonymous Coward]

That's probably why they chose python.

Re:Yet another...

[utopianfiat]

Ah yes, whoever could forget the Debildo, with its demo video featuring famous porn stars moaning "apt-get INSTALL!"

on a more serious note, some of this tech is Very Real.

Re:Yet another...

[renegadesx]

Goatse 2.0... *shudders*

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!

Re:Tux' voice

[Tablizer]

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!

Wallll-Eeeeee

Re:Tux' voice

[antdude]

Probably, but with difficulties. See TTS Voices section in http://www.tuxisalive.com/downloads ...

Re:Tux' voice

[laejoh]

OMG, imagine:

Kaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahn!!!!

Re:Tux' voice

[soulfury]

I want Tux to have a sexy female voice, like my MacBook's Vicki. Isn't it nice to have a computer that will talk to you?

Has to be said...so lets get this one out of the w

[sznupi]

I, for one, welcome our robotic Tux overlords.

Yes but...

[Hatta]

Does it run Linux?

Re:Yes but...

[esocid]

Yes, but does it blend?

Re:Yes but...

[Sangui]

Think about a beowulf cluster of these!

Re:Yes but...

[jonaskoelker]

Wasn't that the plot of a batman movie? ;)

Re:Yes but...

[hitmark]

if so it most likely involved the guvernator on ice...

Re:Yes but...

[markswims2]

Does it play doom?

Re:Yes but...

[traveller.ct]

Yes, but will it float?

But Can It...

[Anonymous Coward]

But can it be programmed to teach a slashdot user to RTFA?

or better yet, can it be programmed to RTFA for the slashdot user?

Seriously?

[Romancer]

Dude, seriously?

FTA:
"After installing the packages, I had to reboot my computer to get the Tux software daemons to start."

Re:Seriously?

[socsoc]

I know people usually mock windows users for thinking a reboot is the first thing to do when things don't work, but when my freebsd and linux boxes act oddly, I reboot them. And guess what, it usually remedies the problem I was experiencing... So maybe the installation instructions didn't include manually starting the daemon, but it was added to the startup scripts... big deal.

Re:Seriously?

[sumdumass]

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.

Re:Seriously?

[Hatta]

So check your /etc/init.d for the startup scripts. Anyone who runs linux should be able to do that.

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:Seriously?

[sumdumass]

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.

The reboot could actually cause more damage depending on if it is listed as a mounted device in fstab or not. I hear some distros have done away with the fstab and use mtab directly, I can't verify that though but you could actually end up with a nonbooting system. It seems that devices for entries in the mtab and fstab have to be there when the system is coming in order to successfully boot.

I have never had that specific problem with a usb drive, but I have with a bad harddrive in which case I was able to kill the mount process, and keep on moving. I imagine you would only have to wait a few minutes so as the mount process would time out. That's usually what happens to me when I attempt to access a dead drive withing linux. And I use it quite often to DD the blocks of a dead drive to a new drive before attempting data recovery options. But as I said, I usually am using IDE or sata and not USB.

But something more important is that in the examples, you already know what the cause is until you get to the X freezes situation. In the first example, the cure is to make sure you cleanly mount and unmount file systems and that the devices are present. That is the fix, rebooting only clears the symptoms. In the second example, having the right usb devices plug in the correct order seems to be the fix, the symptom of Xorg not starting is resolved only after the device order is corrected. You might want to place a couple of second pause in your rc scripts after hotplugged is loaded so all the devices can be energized and reporting before mount attempts to mount them. I have seen problems with bad power supplies which delay in starting the drives erratically show the same situation. The pause worked for me until I could swap the power supply out. (and frankly, I originally thought I had a bad mainboard because the block devices would randomly not appear in the bios setting with random no video, But after swapping a power supply from another working system as a test, it solved the issue so I knew I need I needed a new supply. Of course rebooting until everything came up correctly was an option, but it done nothing to address the problem that would have only became worse if it didn't start taking other hardware with it.)

In the last example, X freezing is a "symptom". There is something causing it to freeze. The idea that you think a reboot solves it also suggests that you think it is fine for X to freeze. But your missing the problem and only removing the symptom with a reboot. The only thing that rebooting fixed was your ability to access X so you can let the problem create the freeze once again. Do you see where this is going? If you tracked the problem down and fixed it, you wouldn't be rebooting to get access to X. And this is all despite the idea that you can usually pop a terminal up and kill X then restart it without rebooting. If your thinking "how can I do that when X of frozen?", investigate pressing the control alt and f keys. But keep in mind, generally, X runs on F7 so when attempting to get your screen back, you won't have to reboot to "fix" it. I have seen a few distros that limit the terminals to something like 3 or 4 so it might not be f7, it could be f2 or something.

Anyways, I hope you can see the difference between fi

Re:Seriously?

[RiotingPacifist]

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. ctrl+alt+bkspace, restarts x
if that fails
alt+prnt scrn+r switches keyboard to raw mode, so you can get to consoles
if all else fails
alt+prnt scrn+k reboots the tty (although you probably shouldnt use that one as it can damage your system i think your supposed to use alt+prnt scrn+{S(ync your disk), I (kills some stuff) then K}

sure these are technically restarts, but they are quicker, safer, nicer to hardware and help give an indication of how far the problem goes.

Re:Seriously?

[lazyron]

Isn't that kind of how medical doctors work?

Re:Seriously?

[grumbel]

I imagine you would only have to wait a few minutes so as the mount process would time out. There was no mount process, because the drive was already unmounted long ago. It was LVM that still kept its old on the device and wouldn't want to let it go. And restarting that did to nothing to fix the problem. Might there be a way to fix it without the reboot? Maybe, but it simply wasn't worth to time to find out, because it was a clear problem with a clear solution: reboot.

rebooting only clears the symptoms No, it clears the *problem*. The problem is that Linux has gotten into a confused state, reboot puts things back into order. Sure, if you don't want to run into the problem again you have to shutdown the volume group properly, but that knowledge helps you nothing if you already messed up.

In the second example, having the right usb devices plug in the correct order seems to be the fix, And how exactly is crawling under the table easier then typing 'reboot'? Let alone that I would of course have to figure out the correct order first and I would have to restart Xorg anyway. It is just an example of Linux having gone into a wrong state, reboot clears that.

The idea that you think a reboot solves it also suggests that you think it is fine for X to freeze. I don't think it is fine, but there is nothing I can do to fix it without rebooting first. Software something screws up, some software more then other and restarting it helps, if it is some important piece of system software a reboot is required. Yeah, you might run into a similar lock situation again in some days/weeks/month, but so what? If it gets annoying enough I look into it, if it just happens once or twice I simply reboot and forget about it. Also there are plenty of ways on how Xorg can get unusable without letting you switch to a console and not always does one have a ssh at hand. And anyway, there really isn't much of a difference between restarting and rebooting anyway, both tasks will destroy all your unsaved work.

What you forget is that Linux isn't a static system and neither a bug free one. When you use it you change its state and sometimes things go wrong and get stuck, see for example processes hanging in 'uninterruptible sleep', you can't even 'kill -9' them and reboot fixes the issue.

Re:Seriously?

[sumdumass]

If we cold understand the human body like we do man made logic circits and software that runs on it, we would have no disease without a cure. The problem is two fold here, One is that the human body is intricately more complicated then a computer or software that runs on it, the second is that medical professionals make more money with you coming back instead of curing you and sending you on your way. How much of each is at play is subject to interpretation.

But on another note, Medical doctors only do this for what they can't find a cause for or for what the human body will repair on their own. Cancer is obviously more complicated then a cold. A computer won't mend itself unless some specific software is installed that fixes the problem, not the symptom.

Re:Seriously?

[sumdumass]

There was no mount process, because the drive was already unmounted long ago. It was LVM that still kept its old on the device and wouldn't want to let it go. And restarting that did to nothing to fix the problem. Might there be a way to fix it without the reboot? Maybe, but it simply wasn't worth to time to find out, because it was a clear problem with a clear solution: reboot.

Lol.. No rebooting isn't the solution. As soon as you recreate the situation, you have the problem again. So the problem is removing the device before you give the correct instructions to the OS. The reboot simply got you out of the symptoms.

No, it clears the *problem*. The problem is that Linux has gotten into a confused state, reboot puts things back into order. Sure, if you don't want to run into the problem again you have to shutdown the volume group properly, but that knowledge helps you nothing if you already messed up.

No, it clears the symptoms. You are incorrectly thinking that the symptom is the problem. It isn't, the problem is your not having the device in place or removing it incorrectly. If you do it again, you will get the symptom again. This is an important difference because otherwise you can't learn from your mistakes or stop it from happening in the future.

And how exactly is crawling under the table easier then typing 'reboot'? Let alone that I would of course have to figure out the correct order first and I would have to restart Xorg anyway. It is just an example of Linux having gone into a wrong state, reboot clears that.

Actually, I think I remember suggesting that you place a pause after the hotplugged script runs at startup so all the devices can be fired up and running properly before anything gets assigned and mounted. This is done differently on different distributions but usually it is somewhere in the rc scripts. You might have to simply change the order that something loads too.

Crawling under the desk isn't the issue, or it shouldn't be. You would have done that when you pluged the stuff in, in the first place. Now there are two reasons I know of why the device order goes awry, one is because the order of devices have actually changed, the other is because a device wasn't detected or skipped because it wasn't ready when the computer went to that process. Rebooting won't address the first unless another device is being skipped over. It is only a bandaid on the second. Do you really think it is acceptable to reboot a computer 2 or 3 times before you get a functional and productive desktop? I have a really hard time imagining the type of experience a person normally has if they think this is normal. It really is one of those where nothing goes right because your not doing the right things.

I don't think it is fine, but there is nothing I can do to fix it without rebooting first. Software something screws up, some software more then other and restarting it helps, if it is some important piece of system software a reboot is required. Yeah, you might run into a similar lock situation again in some days/weeks/month, but so what? If it gets annoying enough I look into it, if it just happens once or twice I simply reboot and forget about it. Also there are plenty of ways on how Xorg can get unusable without letting you switch to a console and not always does one have a ssh at hand. And anyway, there really isn't much of a difference between restarting and rebooting anyway, both tasks will destroy all your unsaved work.

This is what I am talking about. Your still insisting the rebooting fixes the problem when it only removes the symptoms. Software isn't inherently buggy, certainly not Xorg unless your using some release candidate instead of a stable revision. There are too many people using it without lockups or having to "reboot" to fix it. There is a setting wrong somewhere, a bad library, a program causing problems alongside X or

Re:Seriously?

[grumbel]

Your car analogy misses the point, so here another one:

Your car runs out of fuel because you forget to refuel it. You already know that you should have refueled it earlier and your fuel indicator pointed out the lack of fuel correctly, but you forgot to do so for some reason. Now you can think about what that made you forget it, but none of that thinking will make your car drive again. The problem isn't that you forgot it, but that you are stuck with a car without fuel. You fix that problem by filling new fuel in the tank (reboot), not by thinking about its cause.

Not all problems are systematic and reproducible, something things just get screwed up, it shouldn't happen, but it does happen in any complexer system. Back to my USB drive problem: Yeah, I screwed up, I know why the problem happened, but knowing so won't make by USB drive usable again, rebooting however will. Knowing the cause is nice, but something it helps you nothing to fix the problem, because you can't undo the cause, since it already happened.

Re:Seriously?

[sumdumass]

Your missing the forest for the trees. In the running out of fuel episode, lets say the problem is that some one is siphoning the gas from the car as you sleep. So you get up in the morning thinking you have a full tank and it runs out on your way to work. Sure putting gas back into the car will get you going but until you stop whoever from stealing your gas, you are going to constantly be running out. The problem isn't that you running out of gas, it is that something is causing you to run out of gas. it has made your car unreliable. You can be content with feeding more gas into it and walking the half mile or whatever to get some to restart it, but your only addressing the symptom.

Not all problems are systematic and reproducible, something things just get screwed up, it shouldn't happen, but it does happen in any complexer system. Back to my USB drive problem: Yeah, I screwed up, I know why the problem happened, but knowing so won't make by USB drive usable again, rebooting however will. Knowing the cause is nice, but something it helps you nothing to fix the problem, because you can't undo the cause, since it already happened.

With computers, all problems have a cause. Because you don't look doesn't mean they aren't there. It is really that simple.

And no, rebooting didn't fix the problem. It fixed the symptom. X causes the problem, Y is the symptom, Y is what you see to know there is something wrong. If you only address Y, X will always have a value and cause the problem. I don't know how else to explain it so I suggest that you keep on living with a computer that you need to constantly reboot and accept that as the norm. Be advised that most other people won't and you are a rare exception in the linux world. This idea of needing to reboot the thing is a hold over from older windows revisions where it was actually programing by microsoft and you couldn't do anything about it. It should be stricken from you head as soon as possible. If you don't have the time or expertise to track the problem down and are happy with just rebooting that is your another issue altogether. But addressing the symptom does nothing to fix the problem. X is still there.

By your logic of the USB drive, you should continue to pull the drive out and attempt to access the volume all the time because they problem isn't you removing the drive without telling the OS, it is the system going crazy after you did it right? I know a tech who after clicking enough buttons can sometimes get ailing windows machines to work better. When you ask him what the problem was or what he done to fix it, he doesn't know. It is really a matter of hoping he gets lucky with enough clicks but you have no history of what has been done to a box when you end up having to go fix it properly. He thinks he is really talented but I honestly don't understand how he can keep his job. I'm not saying that you are just as clueless, But you remind me an awful lot of him. He would do something to find ill results to a computer and when you tell him not to do it again, he would insist that the problem was the machine not booting, not him deleting a file or deleting random registry keys. It was always something stupid that he would do before leaving an inoperable machine behind or one that wasn't stable. After he done that, he would claim the OS needed reloaded anyways and proceed to format and reinstall the OS. Of course a reload often fixed the problem because it simply wasn't there anymore. But after time the problem cam back and the symptoms cam back around. God how I hate working after that ass.

Re:Seriously?

[grumbel]

You still completly miss my point.

And no, rebooting didn't fix the problem. Symptom: USB drive doesn't work after plugin it in
Problem: Linux device names got messed up and LVM got stuck
Cause: Me unpluging it without shuting down the VG
Fix: Reboot

Now of course a patch to prevent Linux getting into a confused state might be nice or me just remember to shutdown the VG, but none of that will make my USB drive work again. Reboot is the only that will bring Linux out of the confused state again. Reboot fixes the problem, not rebooting leaves Linux in an unusable state. For some problems I can of course get things back to live without rebooting, but for some I can't.

Re:Seriously?

[sumdumass]

Symptom C: USB drive doesn't work after plugin it in
Symptom B: Linux device names got messed up and LVM got stuck
Cause A: Me unpluging it without shuting down the VG
Fix: don't do A and Reboot to clear the symptoms B and C

There, fixed that for you.

Lol.. You are finally in agreement with me and fail to realize it. You incorectly listed a symptom as the problem though. You attempt to claim that rebooting fixes the problem when it fixes the symptom. That is the point. Now if you don't unplug the drive without shutting down the VG again, you will never have the symptoms again. Without the problem, you won't see the symptom. The reboot only addresses the symptom. The symptoms are what lets you know there was a problem.

I can see how you might think that a symptom is a problem because it stops you from working. That is only superficial though. You have a situation where A->B->->C. If you skip A, B and C aren't there. You can't skip B or C if you do A. Because B and C are dependent on A to be true in order to exist, A is the problem. The reboot only address B and C (the symptoms of A). And finally, every time A becomes true, B and C become true too.

You see, we know the cause of this. But it is important for when you don't know the cause. Suppose you never realized this behavior being associated with unpluging the USB drive? You would continue to do it incorectly and increase the amount of reboots you think you need to do.

Re:Seriously?

[grumbel]

How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.

Now you could of course argue that the fix with reboot isn't a true fix, but more workaround, and I could agree with that, since it only fixes the problem one has right now, but doesn't try to prevent future trouble. A true fix for this problem would be to fix the Linux kernel or LVM, because the issue at hand is a bug. A common human action shouldn't cause the Kernel to go into an 'confused' state.

Re:Seriously?

[sumdumass]

How do I execute your 'fix' without a time machine? 'A' already happened and there is nothing I can do to undo it, other then just accept that it happened and reboot. Even worse, there is also *nothing* I can do to make sure that 'A' never happens again. I can try to remember it, teach others about it, but as long as human do it, they will forget it sooner or later.

Lol.. You realize you are arguing something that has already been answered. Your reboot, as I originally stated only clears the symptoms, the fix is you not unpluging the device improperly. If you have to continually reboot to fix the symptom and don't care about the problem, it is because of your own stpidity. But if you realize that you have to take some steps when unpluging the device and follow through with those steps in the future, that last reboot because of this problem will be the last reboot you would need to do because of it. You don't need a time machine, you just need to look at the logic. You could probably write a script that monitors the hotpluged or whatever your system uses for USB and perform those actions yourself. You can probably place it in the /etc/hotplug script for your device itself and likely never have the problem again.

Now you could of course argue that the fix with reboot isn't a true fix, but more workaround, and I could agree with that, since it only fixes the problem one has right now, but doesn't try to prevent future trouble. A true fix for this problem would be to fix the Linux kernel or LVM, because the issue at hand is a bug. A common human action shouldn't cause the Kernel to go into an 'confused' state.

Lol.. That's essentially what I have been saying from the beginning. A work around is something that adresses the symptoms of a problem instead of the problem itself. Rebooting addresses the symptoms.

And I am not sure that the fix would be something with the kernel. It appears that you aren't using filesystems right from what I can gather. I wouldn't use LVM on a USB hardrive in the first place but I am sure you have your reasons. I don't know what they could be because it would escape me as to why you would do it for a removable device. It really does appear that you are doing something wrong from the start. That wouldn't neccesarily be a fault of the kernel, a limitation maybe not not realy a fault.

Re:Seriously?

[Comboman]

Other example, every few dozens reboots my computer tends reorder the USB device names . . . Fix? Again, reboot. USB just happens to be not 100% deterministic and when it does something different, reboot can fix it.

Wow, that's the worst example ever. A reboot is what caused the problem in the first place. Yes, another reboot may fix it (but as you say, USB is not 100% deterministic, so it may not fix or may even make it worse).

Re:Seriously?

[sukotto]

> take a USB harddrive, make LVM on it and then unplug it and then try to plug it in again.
[snip]
> Next time one should of course remember to vgchange -a n the volume group before unplugging

No. It should just work. The user shouldn't have to remember anything. Just pull the drive out, and later put it back... and the system should be smart enough to figure it out.

Re:Seriously?

[thousandinone]

Alright seriously. Yes, a reboot fixes it. Dictionary.com: Fix -verb (used with object) 1. to repair; mend. driving from that. dictionary.com: Repair -verb (used with object) 1. to restore to a good or sound condition after decay or damage; mend: to repair a motor. Not doing something in the first place is not a fix or repair. By the very definition of the word a fix or repair occurs after the damage has taken place. This is akin to telling someone that the best way to heal a wound is not to get one in the first place. Do you work for HR at my company by any chance?

Re:Seriously?

[sumdumass]

I have to ask, are you stupid or something? I didn't say nothing was fixed, I said the problem wasn't fixed. If you continue to remove the drive which is "the problem", the symptoms will continue to plegue you. While rebooting might fix the symptoms, You havn't fixed the problem. And when the problem is something you don't know about, you will be constantly rebooting to adress the symptoms- not the problem.

This is akin to telling someone that the best way to heal a wound is not to get one in the first place

If you know the person is getting a wound by cutting themselve on purpose, it makes all the sence in the world. Of course the wound is the symptoms of something being wrong.

Now with computers, it used to be a few keystrokes in a certain order could crash your system or cause it to reboot. Suppose you brought a computer in that continuously rebooted. And I found the problem to be that you continuously pressed control alt delete at the same time. Well, the reboot isn't going to fix anything. You not pressing control alt delete will. Now suppose your drive fails randomly and you don't know it but your system appears to lock up. Rebooting gets you acess to the computer by aleviating the symptom of a failing drive. But it will do nothing to fix the problem of the failing drive. Eventualy it won't come back on line and you will lose everything on it. Now use some logic and pay attention to whats going on. I am getting sick of this thread were the argument is basically comming at me as I don't care about the causes and problem, just the symtpoms it creates. Your not arguing the same thing I am so either stop or get on the same page. I feel like I'm being surounded by a bunch of MCSE windows techs fresh out of "I can do everything given enough clicks" school.

Re:Seriously?

[thousandinone]

I'd have to return your question, for the aforementioned reason- by definition, a fix occurs after the problem in question. Preventive measures are not, and never will be fixes.

As stated, a fix corrects a problem. Preventing a problem from occurring in the first place is a completely different topic. So no, not doing something in the first place is not a fix. Feigned intellectual superiority will not make you right. You are arguing semantics.

As stated, he knows what went wrong. Doing or not doing it in the first place wasn't really an issue- it was a mistake. They happen. The problem never was that he did it in the first place. We aren't talking about someone cutting themselves intentionally and repeatedly, we're talking about a knife slipping and cutting the victim. He knows not to cut himself, it happened accidentally, without thought. There is no underlying problem causing that to happen. The only problem is the effect of that accident, which is fixed by the reboot.

Re:Seriously?

[sumdumass]

I'd have to return your question, for the aforementioned reason- by definition, a fix occurs after the problem in question. Preventive measures are not, and never will be fixes.

Reboot your life away. It won't do you any good. I specifically said fix the problem not the symptoms. The problem wasn't the system locking up, that is a symptom. Rebooting doesn't fix the problem. I'm not sure how much more plain I can make that.

As stated, a fix corrects a problem. Preventing a problem from occurring in the first place is a completely different topic. So no, not doing something in the first place is not a fix. Feigned intellectual superiority will not make you right. You are arguing semantics.

You must really be a moron. A complete total moron. The problem is the cause of the symptom. A computer doen't need random reboots to operate. Rebooting does nothing to adress the problem. Now you can play word games all you want, but your not going to get past that fact. A symptom isn't the problem, even though lesser people might think it is. The problem has to be something that causes the symptom. Get away from your windows needs reloaded every 6 months and it's ok to reboot windows 2 or 3 times a day just to get a computer to do what it is supposed to do attituted. It is making you look silly.

As stated, he knows what went wrong. Doing or not doing it in the first place wasn't really an issue- it was a mistake. They happen. The problem never was that he did it in the first place. We aren't talking about someone cutting themselves intentionally and repeatedly, we're talking about a knife slipping and cutting the victim. He knows not to cut himself, it happened accidentally, without thought. There is no underlying problem causing that to happen. The only problem is the effect of that accident, which is fixed by the reboot.

Exactly, removing the disk is the problem. Rebooting the computer doesn't address removing the disk improperly at all now does it. It doesn't fix the problem. It addresses the symtoms of the problem which in this case is a locked up LVM.

And yes, according to your example, we are talking about someone cutting themselves repeatedly. Why don't you go back to the start of the thread and get some perspective on this. You will see that I said there is nothing inherent in having to reboot a computer. This is a hold over from sloppy windows programming in older operating systems where it was normal to experience crashes and blue screens that only a reboot could remove. However, the reboot didn't/doesn't address the problem and the computer will continue to need rebooted and you will continue to lose everything you where workiing on.

He brought back three examples in which he attempted to prove himelse wrong. I showed how those only adress the symptoms not the problem. Now here you come thinking that somehow, you and you infanite wisdom or lack of it can declare by playing word games with problems and fix and prove me wrong. I suggest you just stop now before some random dumbass shows how smart your not.

Re:Seriously?

[thousandinone]

Just stop, you're embarrassing yourself. You're getting so flustered that you can't even type correctly. There is a preview button for that exact reason, you know.
 
You're wrong, your analogies are inaccurate, and your standpoint is inherently flawed. It's ok- it happens to all of us. Just because you're an arrogant elitist doesn't mean you will always be right. Carrying on like this won't change any of that, and I'm beginning to think we need to take measures to keep you from cutting yourself; you don't need to go this far just to "prove" your point.
 
Take solace in the fact that the idea behind your statements isn't completely wrong and is very applicable in many situations, even if you didn't quite hit the mark in this case.

Re:Seriously?

[sumdumass]

Just stop, you're embarrassing yourself. You're getting so flustered that you can't even type correctly. There is a preview button for that exact reason, you know.

I only use the preview button for the posts I care about. And no, I'm not embarasing myself at all.

You're wrong, your analogies are inaccurate, and your standpoint is inherently flawed. It's ok- it happens to all of us. Just because you're an arrogant elitist doesn't mean you will always be right. Carrying on like this won't change any of that, and I'm beginning to think we need to take measures to keep you from cutting yourself; you don't need to go this far just to "prove" your point. Well, I guess I am left with just saying who the fuck cares. Go ahead and "Reboot1" your problems away. Eventually you will end up having to reboot so often that you will need to reload your system or pay someone like me to find the problem and fix it. I mean it is just a simple statement of logic and you are attempting to claim I am wrong and all. All I can really say is that I'm not the one with a computer that needs rebooted all the time to get work done. That is because I fix the problem, not just the symtpoms.

I'm betting it really is people like you that keep mom and pop shops open and buy a new computer from Dell or HP when the magic smoke escapes from the brain.

Take solace in the fact that the idea behind your statements isn't completely wrong and is very applicable in many situations, even if you didn't quite hit the mark in this case.

It's wholey aplicable in this case. By rebooting you are treating the symtpom, not the problem. If the problem continues, you will coninue to have to reboot. You can play word games all you want and call the symptom a problem, and a workaround a fix. But it doesn't address the fact that as long as the problem exists you will be rebooting until you get a proper fix. Rebooting a computer all the time isn't a normal operation that someone should have to do to get their work done on it.

Re:Seriously?

[thousandinone]

You do realize that the biggest problem in this industry would be thick-headed people, such as yourself, who think they know it all, right? Well, I apologize my good man, but you do not. I hope you're already well-settled into your career, because someone with your attitude couldn't land a minimum wage position, much less start a career. I don't think I want to know what's gotten you so jaded. Maybe you can track down the problem behind that symptom?
 
Still, you wouldn't be better than anyone else even if you WERE always right. The fact that you don't even understand what you are arguing or the terminology you are using doesn't help the illusion much. Are you even convincing yourself with the false superiority act? You can stop that anytime you like, by the way; if you're convincing yourself, that makes one person.
 
Meanwhile, I think I can manage to keep the magic smoke in on my own, good sir :)

Re:Seriously?

[sumdumass]

Actually, the biggest problem in the industry is people like you who think rebooting is a fix and want to use word game to avoid the real problems. I can imagine your billing accounts, customer called with problem, I told them to reboot again, 10 minutes at $85 and hours. happened 3 times yesterday and 3 times today. with a comment somewhere about how hard your job is.

Still, you wouldn't be better than anyone else even if you WERE always right. The fact that you don't even understand what you are arguing or the terminology you are using doesn't help the illusion much. Are you even convincing yourself with the false superiority act? You can stop that anytime you like, by the way; if you're convincing yourself, that makes one person.

It isn't about always being right. It is about knowing what the hell your doing. Anyone that know what they are doing will tell you that a reboot isn't a fix, it only addresses the symptom. I mean is there some MSCE or MSCA training that I don't know about that considers rebooting a valid fix and a requirement of running windows? It sue as hell isn't in Linux. And it wasn't there when I got my MSCE with windows.

As for me not understanding what I am doing, I think you got that backwards. Now I am only going to do this once so pay close attention. When you claimed the definition of fix included rebooting the computer, you were only addressing the symptoms of removing the drive improperly. You didn't adress adress the problem at all. It wasn't a fix for the problem, it was a fix for the symptom. You seem to think the symptom is the problem when it isn't. It is a reaction to another process.

I understand how you think your so smart by rebooting to get rid of the symptoms, but in the real world, as long as the problem remains, you are going to continuously see the symptoms. There for you will need to continue to reboot the computer so you can practice "fixing" the symptom. You aren't fixing the computer, just the symptom. Now, in the real world, If I have to reboot all the time because your too incompetent to fix the computer, then you won't be working for me anymore. The same can be said for about any other system in a production environment. And I would also think that people would have the right to sue you for any bill they paid of yours for failing to fix the computer and only addressing the symptom.

Re:Seriously?

[thousandinone]

Is THAT what your whole attitude problem is about? Then I think we do have a significant misunderstanding here.

I never meant to imply that a reboot was the preferred solution for every computer related problem, nor really the solution for any problem in general. I took issue with your attitude, arrogance, and how condescending you were being- I thought maybe that was evident in the tone of my posts, but I suppose a text medium internet doesn't portray that too well.

As far rebooting as a 'fix' goes, in most cases you are right, that its just a workaround or stopgap measure in lieu of a permanent fix- but in this particular case, there isn't really an underlying problem causing the drive to be disconnected. It's an accidental removal, or a lack of forethought, not a standing long-term issue that requires a permanent fix. In this case, so long as the user understands that its bad to just pull the drive out, a reboot is really all the fix thats needed. Regardless, I only recommend a reboot when I don't have the personnel to have someone on site immediately, primarily to get them back up and running now. That is a problem with my company that is simply above me; we really do not have the number of people we need, nor do our users receive enough training to avoid those exact situations where "reboot to cure the symptom, and don't do that again" is the 'fix' for the issue.

If you have the time, personnel, and user competence level to address every issue immediately and permanently without having to give somebody a temporary workaround, then I applaud your company.

I hope that clears things up a bit.

Re:Seriously?

[sumdumass]

Is THAT what your whole attitude problem is about? Then I think we do have a significant misunderstanding here.

I never meant to imply that a reboot was the preferred solution for every computer related problem, nor really the solution for any problem in general. I took issue with your attitude, arrogance, and how condescending you were being- I thought maybe that was evident in the tone of my posts, but I suppose a text medium internet doesn't portray that too well.

Dude, my only point was that rebooting doesn't adress the problem. In order to fix a computer you need to address the problem. and it isn't natural to have to always reboot a computer to get work done.

The reason I was being arrogant and condescending it because after five posts saying you have to look further then a reboot to find and fix the problem to another user, along comes you telling me I am crazy. And then you took a definition and applied it in a different context then what I was saying in the first place.

As far rebooting as a 'fix' goes, in most cases you are right, that its just a workaround or stopgap measure in lieu of a permanent fix- but in this particular case, there isn't really an underlying problem causing the drive to be disconnected. It's an accidental removal, or a lack of forethought, not a standing long-term issue that requires a permanent fix. In this case, so long as the user understands that its bad to just pull the drive out, a reboot is really all the fix thats needed. Regardless, I only recommend a reboot when I don't have the personnel to have someone on site immediately, primarily to get them back up and running now. That is a problem with my company that is simply above me; we really do not have the number of people we need, nor do our users receive enough training to avoid those exact situations where "reboot to cure the symptom

Well, actually, in this particular case, there might be more solutions then simply not unplugging the drive. Writing a script that issues the command necessary to remove the block deceive from the LVM group when it is unplugged can make sure that he never forgets to issue the proper commands again. Eventually, that will/could be built into the LVM mod or Hotplugged and the problem would be fixed for good. I'm thinking a simple routine to mark a device as removable and check if it is there before accessing the file system. That might be a little too slow so maybe placing a time out in the code where if a response isn't detected after a certain time period, it checks if the device is still present and then disables it if it isn't. Although My understand of block devices would mean that you could get a return code on almost ever read write function without suffering to much noticeable performance loss. You might have to turn the writ cache off but if your experiencing the problems on a regular basis, you wouldn't want that on anyways.

So you see, even if his particular skill set doesn't include any ability to modify things like that, knowing where the problem is, can get someone else moving on the fix too. I see people with windows machine that crash all the time and they don't send the error reports off to Microsoft for whatever reason. That's how MS knows when something is going wrong. One person I know had been putting up with problems like that for over a year. I finally convinced her to follow the links presented and it turns out that the problem has been known and a free fix from a third party app she used had been available to 6 months longer then she had the computer.

I understand that in some situations you have to reboot to clear the symptoms in order to get work done. You sometimes don't have the time to figure it out right off the bat. But eventually, things need to be fixed or else it makes you look bad.

If you have the time, personnel, and user competence level to address every issue immediately and permanently without having to give somebody a

Re:Seriously?

[thousandinone]

Alright, now we're getting somewhere and it's interesting to read. It seems like you're in a pretty good position as well, given that you can actually focus on addressing the issues without being swamped with the standard set of issues all day long. In a sense then, I suppose that the exact type of user that drives me nuts is the kind that makes up a good chunk of your livelihood.

Sometimes you need to do a workaround just to keep things rolling, but I agree that this type of customer does tend to just pile workaround after workaround onto a machine, which just doesn't work, and as you said ends up making it worse in the long run.

Not just that, a number of so-called 'technical' people love to reinstall programs or reimage machines to fix trivial issues. Case in point, one of our former techs would reinstall excel anytime someone botched his UI to the point of not being able to work with it. /regserver anyone? Still a band-aid, but certainly more time efficient. Eventually, we set it up to maintain a standard interface, preventing the issue from recurring, which is ideal. Of course we got complaints, as is always the case when users get restricted, but at least they weren't breaking it a dozen times a day or more. Unfortunately, office politics seemed to outweigh productivity concerns, but thats another story...

But

[christurkel]

Can you make it speak swear words? That'd rock.

Re:But

[Tablizer]

Can you make it speak swear words? That'd rock.

Why the hell would you wanna do something shitty like that, fucktard!

-1 Flamebait

Re:But

[Anonymous Coward]

If it ever talks about it's wireless dongle and calls it by name, it already knows one good swear word...

Mine's being ornery

[bobdotorg]

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.

Re:Droid!

[Tablizer]

Maybe it can even be... a friend?

You plan to glue tits on it, don't you?

Hmm....

[Tpl2000]

Anyone thinking what I'm thinking?

One more way to have phone sex.

Still in early development

[Shino]

I expect a tux druid to be armored with big weapons ready to kill everything that looks or smells m$-like.
But well someone had to make a first version...

Re:Still in early development

[hitmark]

nah, it just installs linux from scratch on any wintel or mac you plug it into ;)

ObDouglasAdamsQuote

[Chris Tucker]

"Your plastic pal who's fun to be with!"

Re:ObDouglasAdamsQuote

[MichaelSmith]

And he needs a "fish dongle" to be able to communicate.

Re:Droid!

[dreamchaser]

Stop stealing my ideas.

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:Non Programmer

[hitmark]

and have it scream "code red" whenever a windows laptop is connected on the inside of the firewall?

Re:Droid!

[Ethanol-fueled]

It's only a matter of time until some demented furrie uses tux's "talk" feature for the purpose of fellation.

Link for those who don't actually know what it is

[sleeponthemic]

I didn't know. http://www.thinkgeek.com/geektoys/rc/9df0/

you'd think it runs Linux

[gradedcheese]

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.

Re:you'd think it runs Linux

[jbpro]

Gumstix boards are expensive. Their online store sells the cheapest barebones one for $99. ThinkGeek sells the Tux Droid for $99. The goal of an embedded system is to use the resources as efficiently as possible, with the smallest footprint possible. Embedded linux for this application would certainly have the *WOW* factor, but would be overkill and the additional hardware requirements would raise the price of the Tux Droid.

We've seen this before.

[Animats]

Looks like the open source world's answer to Microsoft Barney for Windows.

We need to do better than this.

Aww.

[Artuir]

What, no Tux Racer overlords? You programmers need to get your acts together. We could turn this great game into reality! :D

Re:Droid!

[hack slash]

"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

Re:Droid!

[Ethanol-fueled]

HAHAHAHHAAHAH! For those of you who don't get it, the parent's comment was an allusion to duckjob.

Robot?

[SpacePunk]

The damn thing doesn't even move around. It just pivots in place, etc... There's absolutely no way you can mount a megawatt laser to this thing, and get the respect of your enemies.

Re:Robot?

[triso]

The damn thing doesn't even move around. It just pivots in place, etc... There's absolutely no way you can mount a megawatt laser to this thing, and get the respect of your enemies. You could attach a mini cattle-prod to one of those flapping wings. Ouch!

but does it...

[mathfeel]

sing? That's something cool to do. All they have to do is make the lip also a moving part since it already has a speaker. One can then analyze the spectrum of the mp3 file or something and program the lip to moving in sync.

Perfect cadget to connect to the integrationserver

[madsdyd]

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. :-)

Ugh

[Anonymous Coward]

This is beyond geeky. Great for Halloween setups though.

Re:Perfect cadget to connect to the integrationser

[Jens Egon]

Japanese scientist have been saying for years that robots will be the new mass media,

I reckon 2009 will be the year of linux next to the desktop.

Seriously though, tux badly needs eyebrows for better emotional communication.

Tux vs. Cat

[andmalc]

I need something to entertain my very energetic cat. Something like:

#!/usr/bin/python

fakemouse = Tux()
fakemouse.speak(TUXSOUNDS.squeak)
fakemouse.runAway()
fakemouse.hideBehindCouch()

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. :-)

Cleanup on aisle four!

[GDI Lord]

What would happen if you instruct it to core dump?

Re:Perfect cadget to connect to the integrationser

[Warbothong]

I'd think that would be cheaper to do in software really.

1) Software can be created in any way desired and deployed easily to existing computer systems for very low cost

2) The cost of clicking "delete" is less than the cost of a descending hammer

Re:Perfect cadget to connect to the integrationser

[madsdyd]

Yes, but the pingvin is way more fun!

We have all the software to notify from our integrationserver. This would just be fun.

And, its only 99 anyway. (Sold out though :-( )

Re:Perfect cadget to connect to the integrationser

[MarginalWatcher]

Uhuhuhu, you said "meating"...