4 ms·

I'm actually less interested in how much RAM the desktop uses in normal usage, and more interested in how gracefully it handles curveballs. For instance, some

I'm actually less interested in how much RAM the desktop uses in normal usage, and more interested in how gracefully it handles curveballs. For instance, some time ago I accidentally pointed a file manager at a directory containing a massive JPEG image (I think it was a photo of decapped chip, or something of that nature). The file manager immediately decided to generate a thumbnail, ate all the physical RAM, and triggered a swapstorm that made it next to impossible to find and kill the offending process. It took best part of five minutes to regain control of the computer.

eptcyka 4y ago
In the Xorg version of gnome-shell, it was possible to crash the user session by just requesting a drawable surface that's _too big_. I managed to do so with a textbox from seemingly safe python code.
eric__cartman 4y ago
Oh boy I remember when Gnome's file manager ate all my ram trying to generate thumbnails for a folder with millions of images. And when Dolphin crashed and refused to work again when the nfs shares that were mounted got unexpectedly disconnected from the network. I had to unmount everything from the terminal before Dolphin decided to work again.
kitsunesoba 4y ago
In my experience Linux DEs are notoriously bad at handling edge cases like this. Probably one of the more frustrating parts of the Linux desktop experience. It’s not a constant pain but on the odd occasion that you hit these edge cases it tends to really suck.
bityard 4y ago
In KDE, Dolphin has a setting to never generate thumbnails for files above a certain size. Unfortunately, it's set to "unlimited" by default...
- nyanpasu64 4y ago
  And worse, if Dolphin misinterprets a pseudo-random random binary file as a Targa image, even the tinest of files can be interpreted as an image with millions of pixels and gigabytes in size (even though only the first few pixels are actually present in the file). And malicious binary files can be small but decompress to gigabytes of pixel data as well. So a source filesize limit is insufficient to prevent pathological files from eating RAM.

eptcyka 4y ago

In the Xorg version of gnome-shell, it was possible to crash the user session by just requesting a drawable surface that's _too big_. I managed to do so with a textbox from seemingly safe python code.

eric__cartman 4y ago

Oh boy I remember when Gnome's file manager ate all my ram trying to generate thumbnails for a folder with millions of images. And when Dolphin crashed and refused to work again when the nfs shares that were mounted got unexpectedly disconnected from the network. I had to unmount everything from the terminal before Dolphin decided to work again.

kitsunesoba 4y ago

In my experience Linux DEs are notoriously bad at handling edge cases like this. Probably one of the more frustrating parts of the Linux desktop experience. It’s not a constant pain but on the odd occasion that you hit these edge cases it tends to really suck.

bityard 4y ago

In KDE, Dolphin has a setting to never generate thumbnails for files above a certain size. Unfortunately, it's set to "unlimited" by default...

nyanpasu64 4y ago
And worse, if Dolphin misinterprets a pseudo-random random binary file as a Targa image, even the tinest of files can be interpreted as an image with millions of pixels and gigabytes in size (even though only the first few pixels are actually present in the file). And malicious binary files can be small but decompress to gigabytes of pixel data as well. So a source filesize limit is insufficient to prevent pathological files from eating RAM.