9 ms·

In theory we all mostly agree with this: stable, well understood software is to be preferred. In practice, it's not true most businesses or teams want newer so

by the_af 5y ago

In theory we all mostly agree with this: stable, well understood software is to be preferred. In practice, it's not true most businesses or teams want newer software just to be "on the bleeding edge". The bleeding edge is not a goal on its own. What usually happens is that you need a feature (for actual business reasons) that is not available in the older version of the software you are using; or there is a serious bug that is only fixed on the "bleeding edge" version and is nontrivial to backport. So you often have two choices: make the change yourself in the stable version (risky, time consuming, and can it be considered "stable" anymore once you mess with it?) or move to an unstable version (risky, new bugs). And that's assuming the software is open source; if it's proprietary you have even fewer choices...

Wowfunhappy 5y ago
How badly do you really need that feature? Why did no one need it a couple of years ago?
- Zababa 5y ago
  Most of the time people that need the feature are not the same as people that will be in charge of developing the feature. I doubt most people also have the leverage to conving the business that they don't need the feature.
  - Wowfunhappy 5y ago
    But what did they do about it a year ago? They didn’t have the option of using an unstable version (because the feature still wouldn’t have been there), so what happened? Did they go out of business? IMO, the “bleeding edge” is just overly tempting and people need to learn to resist it. It’s hard to know for sure when we’re speaking in hypotheticals, but I think that in most cases, the trade-offs aren’t being weighed accurately.
    - powersnail 5y ago
      They endured it. People didn't have personal computers or cell phones a century ago. What happened? Did businesses go extinct? The entire digital empire that we enjoy today is built on people's wants. Some things are wanted so badly, that we are willing to get our hands dirty and actually create new things. It's not hard to imagine that people can want things badly enough to try out those new things.
    - jodrellblank 5y ago
      Seems like you're arguing that if they didn't go out of business last year from lack of $feature, then they never will. Imagine you run a company selling things and can't offer next-day shipping and none of your competitors does either. The company you use for deliveries announces they support next day shipping now but you have to add a priority flag to requests so they can schedule it differently, and they released a new API client to support that. Your competitors all start offering next-day shipping and you don't. You ask your employees why. The development team says the new API client is unproven and the one you have is stable and you didn't go out of business last year so you probably just have no self control and are demanding the latest shiny and are weak and impulsive. Would you be OK with that reasoning? Or with literally any reason that ended "so we're not offering next day shipping and will definitely lose customers to our competitors because of it."? Or would you start looking for a way you can take the change and isolate it? "We'll run next-day shipping requests through a different queue and watch it more closely", etc.
- exyi 5y ago
  Maybe they needed it, but the devs only had time for it last month
- 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`.
- the_af 5y ago
  > How badly do you really need that feature? Very badly. New regulations require this feature or we risk fines. Also we need to support some new hardware. Also we finally discovered a longstanding bug that was losing us money. Also, the business opened a new branch that needs this. > Why did no one need it a couple of years ago? The regulation didn't exist. We didn't understand the bug. The new hardware didn't exist. The new business opportunity hadn't been thought of yet.
the_af 5y ago
For personal use, here's the same thing again. Say a Linux user wants to play a game. The stable old version of their distro doesn't play well with the libs/drivers needed to play the game. So the user must install a newer, less tested, distro. But the goal was not to be "on the bleeding edge" for its own sake; it's playing the game, and there's no other (easy) way.
- AnIdiotOnTheNet 5y ago
  This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.
  - torstenvl 5y ago
    Agreed whole-heartedly, and one of the reasons I love the FreeBSD model. My ideal Linux distro would be the inverse of Debian k/FreeBSD – a Linux kernel with FreeBSD kernel interfaces provided by loadable module and a FreeBSD-style userland. Might be possible soon, now that building Linux with clang is supported.
    - yjftsjthsd-h 5y ago
      Huh. There are already others implementing the Linux ABI, but I can only think of NetBSD rump kernels and some Plan 9 thing...vx9? going the other way. No reason it shouldn't work. Edit: Oh, and Darling runs Darwin binaries on Linux, which isn't quite a BSD but is non-Linux
  - ludocode 5y ago
    It's not just possible and reasonable. It's how literally every other platform works. It's also how the Linux Standard Base worked. It was intended to be a stable well-defined backwards-compatible set of libraries common across distributions. Of course the LSB had its share of problems but they had the right idea to bring stability to Linux as a platform for binary apps.
winternett 5y ago
A huge dimension concerning the decision on using "unvetted" and/or "cutting edge" technology is how MISSION CRITICAL the system you are creating is... Building a new social media app as a startup? _Depends on the data you're storing for users and how you market the stability of the system to your user base. Building a new Government healthcare system? _You better use properly vetted technologies. This includes using cloud service providers as well. Some systems simply need to be old school. Old school tech relies on structured data that can prove better for security and for testing. Methods that have been in place over years are not only more reliable, the ways of fixing problems when they occur are well documented as well. Countermeasures to security threats are also well documented for older solutions, yet we also have to acknowledge, the Internet in itself is still a relatively new thing for business and commerce, so things these days are really declared as "Legacy" by companies and individuals who are selling alternative solutions as a part of the "new money marketing" pipeline, not because they are truly "out of date" or "no longer viable"... I am not defending nor advocating COBOL or mainframe systems with that statement though... (Just to be clear). With newer concepts/solutions like blockchain, using unstructured data, and even cloud hosting, they are vetted to an extent, but they introduce very new threats into the stability of mission critical systems, and they are not perfect solutions. These newer solutions also by nature dictate costly refactoring for many that locks buyers into platform-specific situations that they can't easily migrate back if the ideas don't work out well, and compromise of data integrity or security for mission critical systems is more costly than ever as data builds... Not every solution should enlist "cutting edge" solutions as their backbone. Even a gradual approach may be a more reasonable option (like introducing new technology in "siloed" and/or "smaller" aspects as a part or feature of a traditional system before a complete refactor (for example). There are some really good reasons why COBOL programmers still get paid a lot of money to this day, even though I am not one mind you. Choose wisely my friends.
- tomnipotent 5y ago
  > Building a new Government healthcare system? _You better use properly vetted technologies. Is there any evidence these systems are more stable and dependable?
- the_af 5y ago
agumonkey 5y ago
one needs bleeding edge + some form of retrocompatibility people deployed new machines with new stacks at the building I'm, most things are better except for a few conflicts which turn some tasks 3x slower people don't mind about things unless they cost them too much

by the_af 5y ago

Wowfunhappy 5y ago

How badly do you really need that feature? Why did no one need it a couple of years ago?

Zababa 5y ago
Most of the time people that need the feature are not the same as people that will be in charge of developing the feature. I doubt most people also have the leverage to conving the business that they don't need the feature.
- Wowfunhappy 5y ago
  But what did they do about it a year ago? They didn’t have the option of using an unstable version (because the feature still wouldn’t have been there), so what happened? Did they go out of business? IMO, the “bleeding edge” is just overly tempting and people need to learn to resist it. It’s hard to know for sure when we’re speaking in hypotheticals, but I think that in most cases, the trade-offs aren’t being weighed accurately.
  - powersnail 5y ago
    They endured it. People didn't have personal computers or cell phones a century ago. What happened? Did businesses go extinct? The entire digital empire that we enjoy today is built on people's wants. Some things are wanted so badly, that we are willing to get our hands dirty and actually create new things. It's not hard to imagine that people can want things badly enough to try out those new things.
  - jodrellblank 5y ago
    Seems like you're arguing that if they didn't go out of business last year from lack of $feature, then they never will. Imagine you run a company selling things and can't offer next-day shipping and none of your competitors does either. The company you use for deliveries announces they support next day shipping now but you have to add a priority flag to requests so they can schedule it differently, and they released a new API client to support that. Your competitors all start offering next-day shipping and you don't. You ask your employees why. The development team says the new API client is unproven and the one you have is stable and you didn't go out of business last year so you probably just have no self control and are demanding the latest shiny and are weak and impulsive. Would you be OK with that reasoning? Or with literally any reason that ended "so we're not offering next day shipping and will definitely lose customers to our competitors because of it."? Or would you start looking for a way you can take the change and isolate it? "We'll run next-day shipping requests through a different queue and watch it more closely", etc.
exyi 5y ago
Maybe they needed it, but the devs only had time for it last month
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`.
the_af 5y ago
> How badly do you really need that feature? Very badly. New regulations require this feature or we risk fines. Also we need to support some new hardware. Also we finally discovered a longstanding bug that was losing us money. Also, the business opened a new branch that needs this. > Why did no one need it a couple of years ago? The regulation didn't exist. We didn't understand the bug. The new hardware didn't exist. The new business opportunity hadn't been thought of yet.

the_af 5y ago

For personal use, here's the same thing again. Say a Linux user wants to play a game. The stable old version of their distro doesn't play well with the libs/drivers needed to play the game. So the user must install a newer, less tested, distro. But the goal was not to be "on the bleeding edge" for its own sake; it's playing the game, and there's no other (easy) way.

AnIdiotOnTheNet 5y ago
This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.
- torstenvl 5y ago
  Agreed whole-heartedly, and one of the reasons I love the FreeBSD model. My ideal Linux distro would be the inverse of Debian k/FreeBSD – a Linux kernel with FreeBSD kernel interfaces provided by loadable module and a FreeBSD-style userland. Might be possible soon, now that building Linux with clang is supported.
  - yjftsjthsd-h 5y ago
    Huh. There are already others implementing the Linux ABI, but I can only think of NetBSD rump kernels and some Plan 9 thing...vx9? going the other way. No reason it shouldn't work. Edit: Oh, and Darling runs Darwin binaries on Linux, which isn't quite a BSD but is non-Linux
- ludocode 5y ago
  It's not just possible and reasonable. It's how literally every other platform works. It's also how the Linux Standard Base worked. It was intended to be a stable well-defined backwards-compatible set of libraries common across distributions. Of course the LSB had its share of problems but they had the right idea to bring stability to Linux as a platform for binary apps.

winternett 5y ago

A huge dimension concerning the decision on using "unvetted" and/or "cutting edge" technology is how MISSION CRITICAL the system you are creating is... Building a new social media app as a startup? _Depends on the data you're storing for users and how you market the stability of the system to your user base. Building a new Government healthcare system? _You better use properly vetted technologies. This includes using cloud service providers as well. Some systems simply need to be old school. Old school tech relies on structured data that can prove better for security and for testing. Methods that have been in place over years are not only more reliable, the ways of fixing problems when they occur are well documented as well. Countermeasures to security threats are also well documented for older solutions, yet we also have to acknowledge, the Internet in itself is still a relatively new thing for business and commerce, so things these days are really declared as "Legacy" by companies and individuals who are selling alternative solutions as a part of the "new money marketing" pipeline, not because they are truly "out of date" or "no longer viable"... I am not defending nor advocating COBOL or mainframe systems with that statement though... (Just to be clear). With newer concepts/solutions like blockchain, using unstructured data, and even cloud hosting, they are vetted to an extent, but they introduce very new threats into the stability of mission critical systems, and they are not perfect solutions. These newer solutions also by nature dictate costly refactoring for many that locks buyers into platform-specific situations that they can't easily migrate back if the ideas don't work out well, and compromise of data integrity or security for mission critical systems is more costly than ever as data builds... Not every solution should enlist "cutting edge" solutions as their backbone. Even a gradual approach may be a more reasonable option (like introducing new technology in "siloed" and/or "smaller" aspects as a part or feature of a traditional system before a complete refactor (for example). There are some really good reasons why COBOL programmers still get paid a lot of money to this day, even though I am not one mind you. Choose wisely my friends.

tomnipotent 5y ago
> Building a new Government healthcare system? _You better use properly vetted technologies. Is there any evidence these systems are more stable and dependable?
the_af 5y ago

agumonkey 5y ago

one needs bleeding edge + some form of retrocompatibility people deployed new machines with new stacks at the building I'm, most things are better except for a few conflicts which turn some tasks 3x slower people don't mind about things unless they cost them too much