Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Life is too short to depend on unstable software

blog.sidebits.tech

Post reply on HN
Print view View original

21–30 of 175 posts

Re: Life is too short to depend on unstable software

#21

Post by assbuttbuttass »

AnIdiotOnTheNet wrote: post #18
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.

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.

NixOS manages this, it's entirely possible to use the stable channel for system packages but subscribe to the unstable channel for packages installed per-user.

Of course, NixOS also has atomic upgrades and rollback, so there's not much risk just running unstable everywhere

Re: Life is too short to depend on unstable software

#22

Post by md8z »

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.

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.

Re: Life is too short to depend on unstable software

#23

Post by exyi »

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?

Maybe they needed it, but the devs only had time for it last month

Re: Life is too short to depend on unstable software

#24

Post by exyi »

hsn915 wrote: post #19
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…

Thank you for confirmin that "Free and Open Source" does not value stability or quality. I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.

Often times you can get a support for a stable OSS, and then you actually help the ecosystem by giving it resources

Re: Life is too short to depend on unstable software

#25

Post by ludocode »

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.

No, you misunderstand. You need new libraries to make your new hardware work. You can't use versions of driver libraries like Mesa that are older than your hardware, and Mesa has a ton of dependencies like libstdc++ and LLVM so you can't use old versions of those either. This is a major problem for Flatpak.

Re: Life is too short to depend on unstable software

#26

Post by bxparks »

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), "please teach me git", "please debug my application code", "please implement this massive feature for me" (for free), "how do I do xxx?" (obviously didn't read the README.md), "your library is buggy" (no it's not, your pointer has run off the end of your array, causing Undefined Behavior).

With all of that noise, it is difficult to figure out which bug reports or PRs are in the 5% that are actually well-researched and valid.

Re: Life is too short to depend on unstable software

#27

Post by md8z »

ludocode wrote: post #25
md8z wrote: post #22

Earlier quoted context omitted.

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.

No, you misunderstand. You need new libraries to make your new hardware work. You can't use versions of driver libraries like Mesa that are older than your hardware, and Mesa has a ton of dependencies like libstdc++ and LLVM so you can't use old versions of those either. This is a major problem for Flatpak.

I don't see why that's any bigger problem than anything else, flatpak includes mesa as part of the SDK: https://docs.flatpak.org/en/latest/available-runtimes.html#f...

If there ends up being a problem with libstdc++ and LLVM, it's not hard to statically link those, if it's not being done already.

Re: Life is too short to depend on unstable software

#28

Post by hsn915 »

exyi wrote: post #24
hsn915 wrote: post #19

Earlier quoted context omitted.

Thank you for confirmin that "Free and Open Source" does not value stability or quality. I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.

Often times you can get a support for a stable OSS, and then you actually help the ecosystem by giving it resources

Unfortunately, the "pay for support" business model means the incentive is to make a system that needs support but pretends on the surface to be stable and high quality.

One way to make a system so incomprehensible that your customers absolutely need support is to make it configurable in a million different ways, and make the configuration invisible / opaque.

Example:

"Why is this program doing this when I told it to do that?"

Answer: Because this file in that directory configure service A to do X, and this other file in that other directory configures the program to behave like Y if it detects that service A is doing X.

But the program does not tell you that via its UI; you have to read obscure documentation.

Re: Life is too short to depend on unstable software

#29

Post by Zababa »

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?

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.

Re: Life is too short to depend on unstable software

#30

Post by yoyohello13 »

hsn915 wrote: post #19
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…

Thank you for confirmin that "Free and Open Source" does not value stability or quality. I'd rather pay for a closed program that comes with guarantees of stability and quality than participate in a community that considers these concerns tertiarty or off the menu entirely.

This is an absurd sweeping generalization. There are many FOSS projects that value stability and quality. Just like there are many closed source projects that don’t.
Post reply on HN