4 ms·

Because sometimes "stable" software has bugs. A true story about one of my websites: It runs on Debian Stable, because I like stability and at the time, Debian

by chias 5y ago

Because sometimes "stable" software has bugs. A true story about one of my websites: It runs on Debian Stable, because I like stability and at the time, Debian was the OS I was most familiar with. It also does a lot of image manipulation, for which it uses ImageMagick. In March of 2018, I discover a bug in ImageMagick: if you perform various hue/saturation modulations, sometimes pixels just turn "black" for no reason -- essentially it looks like someone sprinkled sand on the image. Reported here [1]. Apparently some code ends up with a divide-by-zero error. The good news is that the bug is fixed within a day, and is released to the beta version one day after that. My website is quite literally built around image layering, manipulation, and generation. My users are experiencing what looks like sand thrown on their images every day. So what do I do? Do I assure my users that stable software is actually good and they should just sit tight for a year or two (or more?) until a version containing this patch hits the Debian Stable repos? Do I rewrite the core of my application to replace ImageMagick? Or do I update to run some unstable software? [1]: https://legacy.imagemagick.org/discourse-server/viewtopic.php?f=1&t=33727 https://legacy.imagemagick.org/discourse-server/viewtopic.ph...

gmfawcett 5y ago
You could have just built IM yourself? No need to switch release channels for this. https://imagemagick.org/script/install-source.php https://imagemagick.org/script/install-source.php I used to have a similar version-freshness issue with ffmpeg on Ubuntu, for a video-encoding system I was running. Turns out that building ffmpeg isn't actually that hard. :) Later, I switched to using Nix as a layer over the distro; then I could just build ffmpeg once on my build system, and push the "closure" (the app & all its dependencies) to the other nodes in my encoding farm.
- chias 5y ago
  Technically you're not wrong, though I will point out that it'd still be running the bleeding-edge unstable ImageMagick by definition. But even so, in practice, building ImageMagick it yourself, along with all configuration and integration into PHP (yes, it was a PHP site) on a production webserver is a much bigger lift than that. And then you have to maintain it manually. Arguably this is a much less stable result than running a bleeding edge Debian install where you just `apt-get install php-imagemagick`.
  - filmor 5y ago
    You could backport the patch, that's exactly how Debian achieves stability.
    - chias 5y ago
      Doing so myself is the antithesis of depending on stable software. As someone who maintains a PHP website in my spare time, no, I'm not going to go backport a patch to a C library -- a language I have a passing familiarity with -- which may depend on other updates that have occurred between now and the last Debian Stable release, and which may, if I do it wrong, compromise the security and stability of my entire system.
  - gmfawcett 5y ago
    Fair. Re: bleeding edge, my point was that you could keep the rest of your system stable -- building one component yourself lets you make that tradeoff.
    - chias 5y ago
      Yup. Both of those options were bad enough that I found a really janky [0] workaround to buy me the time in which to rewrite the entire image generation stack. I ended up writing it in Rust, and it's worked beautifully ever since. My implementation was approx 4x faster than the ImageMagick version, and afforded me flexibility and features not implemented in ImageMagick, so it's been great. [0] https://legacy.imagemagick.org/discourse-server/viewtopic.php?p=155229&sid=85b118f4f2e6ef3d0a7ae44c7726a18e#p155229 https://legacy.imagemagick.org/discourse-server/viewtopic.ph...
      - gmfawcett 5y ago
        That janky (but clever!) hack sounds like something I'd do... and then leave running in production for 10 years. :) Well done for writing your own solution!
- the_af 5y ago
  If you build IM yourself, then you are no longer using the old, stable IM version and you've hit the problem: you're on the cutting edge, and also running nonstandard software!
  - gmfawcett 5y ago
    You can choose what version of IM you want to build. There may be several releases more recent than Debian Stable! I'm not sure what your objection to "nonstandard" software is. I write software for a living -- all of my work is "nonstandard" by definition, but it runs just fine. :)
    - the_af 5y ago
      It's not an objection. It's an explanation of why people install unstable or newer versions of software; a counterpoint to the article. Applying your own patch to a piece of software makes it nonstandard and unstable (because it may introduce new bugs, like any change), the very thing the author of the article fears. See my initial comment here.

by chias 5y ago

gmfawcett 5y ago

You could have just built IM yourself? No need to switch release channels for this. https://imagemagick.org/script/install-source.php https://imagemagick.org/script/install-source.php I used to have a similar version-freshness issue with ffmpeg on Ubuntu, for a video-encoding system I was running. Turns out that building ffmpeg isn't actually that hard. :) Later, I switched to using Nix as a layer over the distro; then I could just build ffmpeg once on my build system, and push the "closure" (the app & all its dependencies) to the other nodes in my encoding farm.

chias 5y ago
Technically you're not wrong, though I will point out that it'd still be running the bleeding-edge unstable ImageMagick by definition. But even so, in practice, building ImageMagick it yourself, along with all configuration and integration into PHP (yes, it was a PHP site) on a production webserver is a much bigger lift than that. And then you have to maintain it manually. Arguably this is a much less stable result than running a bleeding edge Debian install where you just `apt-get install php-imagemagick`.
- filmor 5y ago
  You could backport the patch, that's exactly how Debian achieves stability.
  - chias 5y ago
    Doing so myself is the antithesis of depending on stable software. As someone who maintains a PHP website in my spare time, no, I'm not going to go backport a patch to a C library -- a language I have a passing familiarity with -- which may depend on other updates that have occurred between now and the last Debian Stable release, and which may, if I do it wrong, compromise the security and stability of my entire system.
- gmfawcett 5y ago
  Fair. Re: bleeding edge, my point was that you could keep the rest of your system stable -- building one component yourself lets you make that tradeoff.
  - chias 5y ago
    Yup. Both of those options were bad enough that I found a really janky [0] workaround to buy me the time in which to rewrite the entire image generation stack. I ended up writing it in Rust, and it's worked beautifully ever since. My implementation was approx 4x faster than the ImageMagick version, and afforded me flexibility and features not implemented in ImageMagick, so it's been great. [0] https://legacy.imagemagick.org/discourse-server/viewtopic.php?p=155229&sid=85b118f4f2e6ef3d0a7ae44c7726a18e#p155229 https://legacy.imagemagick.org/discourse-server/viewtopic.ph...
    - gmfawcett 5y ago
      That janky (but clever!) hack sounds like something I'd do... and then leave running in production for 10 years. :) Well done for writing your own solution!
the_af 5y ago
If you build IM yourself, then you are no longer using the old, stable IM version and you've hit the problem: you're on the cutting edge, and also running nonstandard software!
- gmfawcett 5y ago
  You can choose what version of IM you want to build. There may be several releases more recent than Debian Stable! I'm not sure what your objection to "nonstandard" software is. I write software for a living -- all of my work is "nonstandard" by definition, but it runs just fine. :)
  - the_af 5y ago
    It's not an objection. It's an explanation of why people install unstable or newer versions of software; a counterpoint to the article. Applying your own patch to a piece of software makes it nonstandard and unstable (because it may introduce new bugs, like any change), the very thing the author of the article fears. See my initial comment here.