• gleemonk (unregistered)

    I don't really see where the WTF is except maybe that having a bigger budget would have allowed replacing the systems.

  • bvs23bkv33 (unregistered)

    wtf will be a non-global skynet

  • Uhm (unregistered)

    i've seen talks about railway equimpent which films the screen and compares that information with what's meant to be on the screen, to prevent issues where a "hacker" (or whatever) changes what's displayed.

  • Quite (unregistered)

    I've been following the steady progress towards a solution where sensors can read the will of a user by monitoring his or her brainwaves, with a view to designing truly bionic prosthetics that can be used as direct functional replacements for lost limbs. To my mind this is the most incredible and exciting "next big thing" (next to the possibility of asteroid mining and off-planet colonies).

    So now I am wondering: get the developer to have an inbuilt chip to monitor his or her brainwaves and detect when he is falling asleep out of boredom, and play a Harrison Bergeron style wake-up noise through his or her surgically-implanted headset. The jerk awake will alert the robot sitting at the developer's laptop to strike random keys, providing any manager with a penchant for snooping with evidence that yes, indeed, the developer actually is working at this moment in time.

  • Blarg (unregistered)

    Wonder how many people had to look up thin film transistor to work out its TFT seriously other than wikipedia's entry who would say that?, love the inconsistent use of almost right tech speak in the article, ssh renders correctly??? yeah not surprising its a terminal and rendered on your end, if you mean SSH tunneled to the VNC server running on said client fair enough, but even then woudn't prove a thing other than vnc is running, seeing as you can render a desktop without a graphics card present.... ;)

    Really wonder why anyone would bother to do this, rather than do the obvious thing of i dunno making sure that the VDI server had the right drivers installed and or a valid x.conf on the image being served, fixed enough of these things to bet that the VDI servers were configured in a HA manner, and the evil twin wasnt patched or pointed to an old share of desktop images or had an old x.conf but i expect budget cuts meant that the vdi caretaker used to be the VB6 legacy problem maker and couldnt fix it as it didnt have a gui....

  • whoever (unregistered)

    And in a few years TRWTF comes, when the problem of a computer (or server?) occasionally rebooting gets traced to a raspberry with a webcam in some hidden corner, and nobody can figure out, why it emits a scripted reboot to a fixed ip whenever the webcam detects bightness...

  • NotARobot (unregistered)

    when the helpdesk SSH'd into the system, the screen would of course render perfectly on their end.

    That's quite feast, considering SSH gives you text-based shell...

  • spaceman (unregistered) in reply to whoever

    For Remy!

    https://twitter.com/fun_stevehawkin/with_replies

  • thegoryone (unregistered)

    And the problem ended up being....

    Don't leave us hanging

  • grasshoppa (unregistered)

    In the mysterious future, humanity is losing the war against the robots. Then, in a climatic scene, the main AI gets rebooted because some robot peon jostled the ancient web cam just enough.

    I'd pay to see that.

  • I jsut want ot know what was wrong (unregistered)

    Well?

  • Decius (unregistered)

    Or... you could take one of the systems that went dark and boot it?

    Or did a reboot clear the failure condition?

  • (nodebb) in reply to Decius

    As I understood it, a reboot would usually but not always clear the failure condition. Thus, the wonky thin client is brought in, hooked up to the robot, which reboots it every X minutes until that doesn't clear the failure condition, then it would message the IT guys that the failure condition is currently in progress and they can try to figure out how to fix it without rebooting (e.g. identify and replace one specific faulty component).

  • Peter (unregistered) in reply to Decius

    ...just "boot it" right into the dumpster.

    Life's too short to have to work with crap hardware. Boss won't let you chuck it in the dumpster? Time for an "unfortunate accident". Whether it happens to the equipment, the boss, or both, is up to you.

  • spaceman (unregistered)

    Ms. Bailey:

    Please see: https://twitter.com/fun_stevehawkin/status/965656058021777408

  • MiserableOldGit (unregistered)

    Isn't TRWTF that this Raspberry PI abomination is a hopelessly over-engineered Heath-Robinson (Rube Goldberg) "solution"? I can't see what it's doing that wouldn't more adequately and easily be delivered with a light sensor, a timer, a transistor, a relay and a buzzer. Or something similar. It's also not very clear from the article how this will help them ... do they want to get one booted into "darkness" and then check the log files, or analyse it some way? They could do that already, no?

    Oh, and all that tiresome Skynet stuff. Computers independently controlling and monitoring other computers is far from original or new.

  • eric bloedow (unregistered) in reply to Quite

    reminds me of an old news story about a device that would sound an audible alarm if the wearer's head drooped too far. it was intended to prevent drivers from falling asleep at the wheel.

  • (nodebb)

    I take it that part 2, which describes the outcome of the project comes tomorrow.

  • Mark (unregistered)

    Reminds me of an issue I was trying to troubleshoot recently.

    Windows 10 occasionally boots showing only a black screen, except for a mouse cursor which moves as expected. Remoteing in the maachine, I can see the display as intended, and operate the machine normally - the attached display steadfastly only displays the mouse cursor movement. About the only way I could fix it was to momentarily disable, then re enable the graphics card.

  • Gerhard Visagie (google)

    Once worked on a solution for a demanding but clueless client. It was a rules based engine. But some of the rules spoke to intent, to the tune of "in the future if you want to be able to do this, then you must have this enabled" He was adamant that I was must somehow code this in. Exasperated I said "What we will do, is to use the radiation from the CRT screen and read it back through the VGA port and determine if you want to do this" The client said "Great. How long is THAT going to take?"

    Addendum 2018-02-20 00:12: *remove was

  • 🤷 (unregistered)

    The moderation should be held for comments for holding the comments for moderation.

  • FatherOfCousinOfITAPPMONROBOT (unregistered)

    Hi. Submitter here.

    @gleemonk: Those systems were bought new from "Hell Computers", together with the TFTs. They were bought as a replacement for aging models by the competitor "dy". You obviously don't want to replace hardware you just bought - Yet, "Hell Computers" couldn't be bothered to help. At least until now. Maybe the'll change their mind now that we have the issue narrowed down (see below).

    @Blarg: It was indeed a VNC connection that was tunneled via SSH, but one that mirrors the actual screen instead of creating a separate virtual screen. Look up x11vnc (formerly x0rfb, I think). Pretty handy piece of software for remote support on your company LAN, as long as you can live with VNC's speed. Also, you seem to have a completely different concept of how ThinClient computing works (not saying yours is wrong - just totally different from what is in use there). Config, boot files, everything alright. Checksums check out, signatures, everything. Yet, every once in a while, a random ThinClient will have a black screen. Yet when remoting in, everything looks fine. Power-cycling the TFT temporarily fixes the issue.

    @thegoryone: While we lack the special equipment required to finally prove it beyond reasonable doubt, we believe the TFTs "Hell Computers" shipped along with the ThinClients are at fault. Something dodgy in their firmware that causes them to report garbage values regarding their capabilities, which then sends the driver spinning freely until you "zap" one of the components involved.

    @Decius: Yes, exactly that was the problem. Power-cycling any component - ThinClient or TFT - would temporarily fix it.

    @Emurphy: Not quite. The entire fleet of ThinClients and TFTs would work normal most of the time. But at random intervals, one would go dark.

    @Peter: Sadly, your solution doesn't scale. See my above reply to gleemonk.

  • (nodebb)

    And that's the reason I don't fear Skynet. It'll be just as buggy and PHB idea festered as any piece of software.

  • FatherOfCousinOfITAPPMONROBOT (unregistered)

    @MiserableOldGit: Yes, that's what made it TDWTF-worthy. However - the webcam was available on the spot, while for the components you suggest, someone would have needed to order parts, wait for them to arrive, then start soldering ... thus burning precious roll-out time. And yes, we wanted hands-on experience with the black screen issue, as it happened in remote locations spreac across the country. So no "I'll just walk over real quick and take a look". As we had no way of reliably reproducing the issue, we needed a way to have a machine ready and waiting for us, in the error state, whenever one of us had a new idea as to what could be causing it.

    @Mark: Equally intriguing issue, but obviously unrelated, as you at least got a mouse cursor.

Leave a comment on “Cousin of ITAPPMONROBOT”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article