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

51–60 of 175 posts

Re: Life is too short to depend on unstable software

#51

Post by throwaway13337 »

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…

Well put.

A reputation/karma system for bug reports could be an interesting way to deal with this problem.

I wonder if it’s ever been tried.

Re: Life is too short to depend on unstable software

#52

Post by chias »

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…

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

Re: Life is too short to depend on unstable software

#53

Post by md8z »

ludocode wrote: post #50
md8z wrote: post #45

Earlier quoted context omitted.

I'm still not sure I understand, it sounds like a solution exists and both Steam and Flatpak are working towards it. I don't see why nvidia can't also do the same things. I hope you can see that "keep libraries backwards compatible forever" is not really a good option either and is probably orders of magnitude more work than just doing all the things you said. In some situations, it is also impossible: if there are b…

The "solutions" are hacks at best. This is not the way to build stable software. > I hope you can see that "keep libraries backwards compatible forever" is not really a good option ??? Why would I be able to see that? You've given zero explanation or evidence for why that would be the case. I see a whole lot of people in this thread in addition to the article explaining why backwards compatibility is good. Nobody is…

AFAIK the win32 API is kept backwards compatible by doing exactly as we describe, shipping older versions of the system libraries and automatically using them when it's detected that an application needs them. So it's the same thing you call a "hack". Please don't misunderstand, I'm not saying backwards compatibility is bad. But it does cost a non-trivial amount of money and time, it's not just a magic solution to reduce the maintenance cost of something down to zero. If you're doing a cost comparison, that always has to be taken into account.

Glibc isn't really a good example, that has a ton of unfortunate broken APIs that should probably be removed entirely (the most notorious example probably being gets) but never will be, and I suspect they will continue to be a source of bugs as long as applications use them and aren't patched. I mean the whole reason musl exists is to get away from some of these maintenance issues in glibc.

Re: Life is too short to depend on unstable software

#55

Post by filmor »

chias wrote: post #52
gmfawcett wrote: post #48

Earlier quoted context omitted.

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…

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.

Re: Life is too short to depend on unstable software

#56

Post by winternett »

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

Re: Life is too short to depend on unstable software

#57

Post by mkl95 »

Innovative tech companies are dominated by business analysts and product managers. Shoddy specs are commonplace, and it's crazy at work because big customers push hard deadlines that have to be met to prevent them from switching to That Competitor's app. They are not empty threats. Unstable software is just the reflection of an unstable industry.

Re: Life is too short to depend on unstable software

#59

Post by wildrhythms »

mkl95 wrote: post #57

Innovative tech companies are dominated by business analysts and product managers. Shoddy specs are commonplace, and it's crazy at work because big customers push hard deadlines that have to be met to prevent them from switching to That Competitor's app. They are not empty threats. Unstable software is just the reflection of an unstable industry.

Exactly. Look no further than promotional processes that value launches over maintenance.

Re: Life is too short to depend on unstable software

#60

Post by gmfawcett »

chias wrote: post #52
gmfawcett wrote: post #48

Earlier quoted context omitted.

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…

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…

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.
Post reply on HN