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

141–150 of 175 posts

Re: Life is too short to depend on unstable software

#141

Post by chias »

gmfawcett wrote: post #60
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…

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.

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

Re: Life is too short to depend on unstable software

#142

Post by doubleunplussed »

smoldesu wrote: post #103
Mikeb85 wrote: post #74

Honestly, I've had better luck on the bleeding edge. Newer Linux kernels almost always are better (and when they're not, it gets fixed quickly). Wayland is definitely better than X. Newer Gnome is better than old Gnome. Ruby 3 and 3.1 is definitely better than 2.7. Rails 7 is way better than 6, even in alpha state. Deno is nicer than Node (although the ecosystem needs to catch up). Hell, V8 and then Node led to a boo…

I agree with this mostly, but the new GNOME releases are almost universally a design regression IMO. Pretty much everything that they added was doable with extensions in 3.38 (most of which are now broken with GNOME 40), and the only substantial changes that I can discern is the shift to libadwaita and forcing people away from things like custom stylesheets and shell extentions, which were the only things that made G…

I still see GNOME as the most practical DE to run - but it's telling that absolutely nobody uses it as shipped: at minimum they install dash to dock or dash to panel, re-enable minimise buttons, and install a system tray extension.

The project seems to usually come around in the end, and it reminds me of some quote critical of the US's foreign policy I think, that "You can always count on the Americans to do the right thing - after they have tried everything else".

Perfectly practical solutions to problems are proposed on bug trackers, and dismissed with the demand of impossibly strict requirements of well-justified use cases, when the current behaviour was never subject to such a high bar. Then years later the obvious fix is quietly implemented after the sheen has worn off whatever sacred cow was considered "the right way to do it" that was blocking the obvious, impure, against-the-vision fix from being considered.

Of course nobody can rightfully expect work to be done on a FOSS project even if their suggestion is a brilliant one. So a response like "Patches welcome" or "Yes we'd like that too but this is on the backburner and not a priority" would be fine. Instead the response too often is along the lines of "that is not in our vision and there is no use case".

I've also infuriatingly gotten a "patches welcome" response before, and then simply faced the "that's not in our vision" response upon providing a patch. It's not that there was a problem with my patch (there may have been, but the conversation didn't get that far), and I got the feeling that "patches welcome" was just a way of kicking the can down the road to make me go away. Am now very hesitant to provide patches to GNOME projects unless I can see that the core developers are explicitly in favor of a change in advance.

Honestly, it's a few bad eggs in the project and not the majority - but it leaves an extremely sour taste in my mouth as someone who has been participating in FOSS for a long time.

And on the CoC discussion, I can't help but notice that the most abrasive participants seem to be the ones most likely to have rainbows and pronouns in their bio. Hypocrites.

Re: Life is too short to depend on unstable software

#143

Post by chespinoza »

revskill wrote: post #124
bitexploder wrote: post #118

Earlier quoted context omitted.

Genuinely curious, how is Ruby any better there? You can build usable front ends in either language. I care about delivering usable software. Interactive front ends for the sake of it is not a good use of effort. If your app and situation justify it, okay, but it isn’t a hard requirement like many other aspects of full stack. Just depends on what you need for good UX. A pile of Javascript isn’t a requirement there. I…

Without fullstack knowledge, in this case, if you don't care how the frontend will fetch data, how can you optimize the backend (just curious). Fullstack knowledge is nessessary for optimized backend code, seriously. Ruby has elegant syntax and structure for functional programming as well as OOP, not like broken Python (1-line lambda and broken OOP).

Your bias against Python is full of prejudices, I wonder where you got the idea that all Python devs lack knowledge about FE?

Re: Life is too short to depend on unstable software

#145

Post by bluGill »

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…

The C++ standard committee regularly has debates about breaking the ABI. They forced it for 11, who knows if they will again.

Re: Life is too short to depend on unstable software

#146

Post by roenxi »

Mikeb85 wrote: post #74

Honestly, I've had better luck on the bleeding edge. Newer Linux kernels almost always are better (and when they're not, it gets fixed quickly). Wayland is definitely better than X. Newer Gnome is better than old Gnome. Ruby 3 and 3.1 is definitely better than 2.7. Rails 7 is way better than 6, even in alpha state. Deno is nicer than Node (although the ecosystem needs to catch up). Hell, V8 and then Node led to a boo…

However keeping up with the bleeding edge is expensive, it requires continuous maintenance and a lot of effort to sift out fads. Python is a great example of where the beeling edge is stable, and Python projects decay really quickly. I've seen 2-year-old python projects in machine learning fields environment that just can't be run any more as a practical matter because the dependencies have changed too much.

Re: Life is too short to depend on unstable software

#147

Post by jart »

pornel wrote: post #117

People often conflate stability with stagnation. When you have poorly written software, then old versions of it are "stable" only because people have already learned how to live with and work around its obvious bugs. Updating means learning to live with new bugs, which is seen as instability, but it's just the same software again. OTOH if you're dealing with reliable software with a low defect rate, then all versions…

Would you call TeX or Bash stagnant? They have a few commits per year. Some projects are like Michelangelo's David where they arch toward completion. At which point the game usually becomes inventing new stuff on top of it, like LaTeX. It's a good model for a gift economy like open source and less disruptive than things like the Python 2 to 3 transition.

Re: Life is too short to depend on unstable software

#148

Post by xmcqdpt2 »

roenxi wrote: post #146
Mikeb85 wrote: post #74

Honestly, I've had better luck on the bleeding edge. Newer Linux kernels almost always are better (and when they're not, it gets fixed quickly). Wayland is definitely better than X. Newer Gnome is better than old Gnome. Ruby 3 and 3.1 is definitely better than 2.7. Rails 7 is way better than 6, even in alpha state. Deno is nicer than Node (although the ecosystem needs to catch up). Hell, V8 and then Node led to a boo…

However keeping up with the bleeding edge is expensive, it requires continuous maintenance and a lot of effort to sift out fads. Python is a great example of where the beeling edge is stable, and Python projects decay really quickly. I've seen 2-year-old python projects in machine learning fields environment that just can't be run any more as a practical matter because the dependencies have changed too much.

That's in large part due to the garbage fire that is the python ML ecosystem... Python projects that are not ML are pretty stable IME.

Re: Life is too short to depend on unstable software

#149

Post by matheusmoreira »

edwcross wrote: post #88
matheusmoreira wrote: post #81

Earlier quoted context omitted.

Same experience here. Everything is just better when I'm running the latest software. My system is not "unstable" either.

Counterpoint: when using a system with hybrid graphics which required me to use proprietary video drivers, switching to the latest Fedora version often brings issues with suspend, or random freezes, or lack of external HDMI output... After a few months, the release stabilizes and my issues disappear. But whenever I tried to be optimistic and jump to the latest release too soon, I got bitten by it and wasted hours try…

No argument from me there. Even on Arch it takes a while for the nvidia updates to arrive precisely because of these issues. Proprietary nvidia drivers have such a poor user experience.

Re: Life is too short to depend on unstable software

#150

Post by gmfawcett »

the_af wrote: post #137
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…

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!

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

Post reply on HN