Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Xfce bug: “default desktop screen causes damage to monitor” (xfce.org)
188 points by felipebueno on March 24, 2017 | hide | past | favorite | 48 comments


The bugtracker seems to be taking a nap, omgubuntu have a summary of the "bug" here: http://www.omgubuntu.co.uk/2017/03/xfce-wallpaper-cat-bug


Found an auto-archive screenshot here:

https://archive.li/s5HMf


>The bugtracker seems to be taking a nap

Sounds like it's a cat. No wonder the bug won't be fixed then.


Very strange. Neither of my cats have ever paid the slightest bit of attention to the contents of any screen on any device I own. Yet I know people whose cats like to watch television, so there's some thing going on where some cats see screen images as significant and others don't. I should go looking for info on that!

In any case, I don't see how this is XFCE's problem. Just change the wallpaper.


> I don't see how this is XFCE's problem. Just change the wallpaper.

While any user who notices they're affected by the issue can fix it on their own, this is only likely to happen after damage has already been inflicted. XFCE can help people preemptively by changing the default to something less likely to attract cats.


Cat eyes have a different refresh rate than human eyes. Some cats can see monitors just clearly enough to make out what's on the screen. Others see flicker. The color gamut is different too.


I can see this being a thing with CRTs (which basically 'flicker' constantly), but LCDs?


Some LCD displays use flicker to set backlight LED brightness.


Dang, TIL, I guess... but I don't see how that relates to the OPs hypothetis about cat vision. A phrase I never thought I'd be uttering here, or... anywhere, really.


Back in the day, if my cat was near my monitor (rare), I would move the mouse cursor around in front of him. He would see it, and maybe gently paw it, and move on within 20 seconds.


I remember my early days of computers (not as old as some folks here, I know) when there was an intense debate on whether a software could cause damage to some hardware.

I remember programing a small .asm that would move the head of a floppy to a farther point and it stoped working. Probably not all models would fail, but one particular brand did.

Then a intense debate followed that I was wrong. Never talked about it again.

Fast-forward, now we have news that nuclear programs had malfunctions caused by cyber-attacks. Ok, not exactly the same "software doesn't damage hardware" we talked back then, but...

I'm willing to consider that using software to make some catware cause damages to the hardware should be acceptable too :D


> "software doesn't damage hardware" [not parent's claim]

Isn't this trivially false?

Of course we can design hardware (+ firmware) that allows software to damage or irrevocably destroy it.

So even if we're not willing to accept that alone, it surely follows that some hardware (+ firmware) will (accidentally) be physically vulnerable to malicious software?


I think so. The point was that you couldn't make a hardware go beyond its limits (video cards, monitors, HDD, keyboards, CD-ROMs)... then I lost my patience and stopped arguing. Funny that at those times, "hardware guide" books were a thing, and one of my opponents was one big writer in my country. Never heard of him anymore, by the way.


(showing my age here)

I also recall that on early IBM PCs with a monochrome monitor and a Hercules graphics card, it was possible to set the refresh rate to zero and toast the monitor.


I remember trying to prove that this was impossible... Until I killed a floppy reader.

But now? When microcode can be patched? I'm waiting for tamperproof ransomware, that holds your hardware as well as your data as the hostage.


CPU microcode is volatile, for what it's worth. Patching it only lasts until the machine is powered off.

Firmware in other platform devices, however, may be vulnerable to modification -- BIOS, network adapter, video card, hard disk...


> there was an intense debate on whether a software could cause damage to some hardware.

Ever broken a monitor with a bad X config?


>when there was an intense debate on whether a software could cause damage to some hardware.

A more recent debate (TL;DR: yes, software can cause damage to hardware): https://superuser.com/questions/313850/


As the person who wrote the accepted answer to that question, I'm flattered to see it linked here. (I'm also a bit embarrassed at reading some of my older rambling-style writing, but nothing beats experience :)

While my forray into malicious floppy disks didn't end with physical damage, I did manage to make one similar to DBAN. If you booted the computer with the floppy inserted, all drives would be formatted instantly, without any user input.

Fortunately, even in highschool​ I realized they probably imaged the school machines anyways. Probably...


Mine answer is there too but with much less points, the kill FDD thing :)


Previous related discussion (about the new MacBooks having their speakers blown out when running Bootcamp) : https://news.ycombinator.com/item?id=13063325


This actually happened to me, but I was on i3 and using pactl to set audio volume. I'd given my laptop to someone and they increased the volume to 300% or so and my right speaker blew.


Linux has had a fair number of video drivers that damage monitors due to oddball timing issues.


> when there was an intense debate on whether a software could cause damage to some hardware.

In the days of C64 and Amiga you could safely say "No".

Once there was a basic rewritable input/output system (BIOS), the answer changed to "Yes". Remember the CIH virus?


> In the days of C64 and Amiga you could safely say "No".

Goes back even further than that. It's probably always been possible, but maybe it was harder on timeshared systems.

https://en.wikipedia.org/wiki/Killer_poke#Commodore_PET

https://en.wikipedia.org/wiki/Killer_poke#Commodore_1541_Dis...

https://en.wikipedia.org/wiki/Killer_poke#Commodore_Amiga


Never heard of those "killer pokes" before. Thank you.


Long story short: the so-called bug -> monitor damage is not caused by code but cat - obviously NOT `/usr/bin/cat` ;-)


even if it was, all is forgiven /usr/bin/cat is too cute to be angry with


Try Ratpoison (http://www.nongnu.org/ratpoison/) to get rid of the mice.


Archived, as the bugzilla seems to be overloaded right now: http://archive.is/s5HMf


I suggest the patch here: http://imgur.com/5s2hM0p


In my house, that would likely result in graphical distortion due to slobber


I think those cats need some upgrade. If they are not compatible with XFCE that's rather not XFCE's fault.


What's easier to change? Even a single cat or XFCE?


Slashdot effect on the Xfce bugtracker...


No one is viewing it due to irrelevance?


Gosh I use Xfce when on desktop mode, reminds me it's time to get a kitten again


Hacker News clearly knows how to DDoS websites.



Haha. Site's back up. Maybe all tech sites need a DDoS protection service not to protect against malicious attacks but rather hitting the 1st page of Hacker News and Reddit.


April 1st early this year?


Can't reproduce on modern hardware (4 Year Old Black Female Cat, 4 Year Old Black Male Cat).

status:Wont Fix


[flagged]


This is not Reddit. We don't zoom text, and we don't "check out" usernames.


Heh, it's not April yet ;)


Soon it will get a new licence: we are not responsible for cat damage.


And then ship a malicious /usr/bin/cat.


Just change the background? I don't think XFCE should change because cats are attacking monitors.


Really? Don't you think they have a responsibility to all thier cat owning users? It must be close to 100%!




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: