Life is too short to depend on unstable software • Hacker News Board

Re: Life is too short to depend on unstable software

#131

Post by jrockway » Sat, Nov 13, 2021, 11:53 PM UTC

bxparks wrote: post #26

outsomnia wrote: post #10

Users of only "stable" FOSS releases almost never contribute, in code, or to its health or longevity. They are leeching it, sometimes over decades. They don't contribute to testing either, since they just consume releases and ignore development, then wonder loudly why there are bugs. Don't be that guy... if you want your dependencies to have a long life being maintained, find some time to contribute. Leeching is not…

I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report along with several possible solutions. I get a snarky response totally unrelated the proposed solutions. But I get it. Maintainers are overworked and jaded. I'm on the receiving end as well, with 95% of the issues like: "help, it's broken" (with no error message…

This is exactly the problem with an overadherance to "stability". If you submit a PR to fix a bug in a "stable" product, it will be a year before it ever becomes "stable", so the incentive to fix it is nearly zero, because you can't get the stability and your bug fix. (If they just ship every random PR to the stable build, well, now it's the "unstable" build.)

Re: Life is too short to depend on unstable software

#132

Post by the_af » Sun, Nov 14, 2021, 12:16 AM UTC

the_af wrote: post #6

the_af wrote: post #4

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…

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.

People focusing on nitpicking my Linux example: it's irrelevant. In general the principle stands true: sometimes, to get a feature you need, you must install unstable software. Nobody wants instability for its own sake; what they want is the feature.

I fear my Linux example may have led people down the wrong rabbit hole. Linux is irrelevant in this context.

I could have used Windows. Sometimes, in the history of videogames, you needed a newer version of Windows. If you wanted to play the game, you needed to install this version.

Or DirectX, or whatever lib. Pick your poison. Nitpicking particular examples is missing the point.

Re: Life is too short to depend on unstable software

#133

Post by the_af » Sun, Nov 14, 2021, 12:20 AM UTC

rodgerd wrote: post #111

jcelerier wrote: post #79

Earlier quoted context omitted.

Even on windows you generally have to install the very latest GPU drivers when an AAA game comes out though

Sure. But I don't have to upgrade my whole userland from Win 10 to Win 11 for hardware compatibility. I don't have to upgrade my core OS to run a new version of Lightroom.

Throughout the history of Windows I've had to upgrade the whole OS in order to run some software or play some videogame, so I'm not sure what you mean.

Re: Life is too short to depend on unstable software

#134

Post by the_af » Sun, Nov 14, 2021, 12:21 AM UTC

jcelerier wrote: post #79

the_af wrote: post #6

Earlier quoted context omitted.

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.

Even on windows you generally have to install the very latest GPU drivers when an AAA game comes out though

Exactly. People focused too much on my Linux example (in hindsight, I should have foreseen this), when it's a problem of all software.

Not just OSes, everything. You want a feature or bug fix that doesn't exist in the old stable version, you need the next one, so you upgrade.

Re: Life is too short to depend on unstable software

#135

Post by the_af » Sun, Nov 14, 2021, 12:24 AM UTC

md8z wrote: post #22

the_af wrote: post #6

Earlier quoted context omitted.

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.

I'm not sure what you mean, this is exactly what Flatpak and Snap were meant to solve. IIRC Steam should also bundle older copies of the libraries needed.

Flatpak didn't always exist.

If my Linux example misled you, let me rephrase: can you run modern AAA Windows games using good old Windows XP? If you can't, you've hit exactly the problem I describe.

It's a problem of software in general, and flatpak doesn't solve it. Flatpak itself may be subject to it!

Re: Life is too short to depend on unstable software

#136

Post by the_af » Sun, Nov 14, 2021, 12:27 AM UTC

winternett wrote: post #56

the_af wrote: post #4

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…

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…

> 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.

I haven't found this to be true. It's one of those things that gets repeated, but as a former COBOL programmer, let me tell you that's not where the money is.

I agree with the rest of your comment.

Re: Life is too short to depend on unstable software

#137

Post by the_af » Sun, Nov 14, 2021, 12:28 AM UTC

gmfawcett wrote: post #48

chias wrote: post #35

Earlier quoted context omitted.

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…

You could have just built IM yourself? No need to switch release channels for this. 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 syst…

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!

Re: Life is too short to depend on unstable software

#138

Post by the_af » Sun, Nov 14, 2021, 12:38 AM UTC

Wowfunhappy wrote: post #5

the_af wrote: post #4

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…

How badly do you really need that feature? Why did no one need it a couple of years 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.

Re: Life is too short to depend on unstable software

#139

Post by tomnipotent » Sun, Nov 14, 2021, 12:39 AM UTC

comex wrote: post #130

tomnipotent wrote: post #126

Earlier quoted context omitted.

The Linux kernel and many other big FOSS receive a non-trivial number of their contributions from professional programmers on the clock at their day job.

What does that have to do with anything?

It's not breaking because the contributions are from paid professional developers with commercial priorities and incentives, with internal or external customers often driving those changes. Not unlike Go.

Re: Life is too short to depend on unstable software

#140

Post by chias » Sun, Nov 14, 2021, 12:43 AM UTC

filmor wrote: post #55

chias wrote: post #52

Earlier quoted context omitted.

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 t…

You could backport the patch, that's exactly how Debian achieves stability.

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.