Live data from Hacker News

Life is too short to depend on unstable software

blog.sidebits.tech

71–80 of 175 posts

Re: Life is too short to depend on unstable software

#71
post #29

Earlier quoted context omitted.

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.

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…

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.

Re: Life is too short to depend on unstable software

#72
post #29

Earlier quoted context omitted.

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.

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…

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.

Re: Life is too short to depend on unstable software

#73
post #41

Earlier quoted context omitted.

I keep hearing people say that, but how do you propose we write software that has no bugs and does everything perfectly right the first time? That seems impossible.

The first time? Sure, nothing ever gets it right the first time, but over time software should converge on being bug free and not requiring any support at all. Free-with-paid-support has a perverse incentive against this.

"over time software should converge on being bug free"

Yeah, and the way that's done is by refactoring things, removing buggy/deprecated things, and not adding any more new features/requirements... So, pick your poison, I guess? I'd love to go move on to the next job as much as the next person, but somebody still has to be paid to do those things. I don't see what the significant difference is there with free-with-paid-support, if you pay for it up front you're still paying the same cost.

Re: Life is too short to depend on unstable software

#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 boom in web technologies. In fact, I think with every language newer compilers and interpreters just keep getting better, never seen enough regressions to make me not want to upgrade.

With games, newer kernels and drivers are better. Proton Experimental has Age of Empires 4 working perfectly on Linux what, a week after release?

I really can't think of a time I wanted older technology. I just upgraded to Fedora 35, it's the best laptop experience I've ever had. Ubuntu and others have been stable and good enough, but Fedora 35 is snappy and everything works in a way that's just better. No more slow software centre. No weirdness with snaps. Quicker suspend and awake. Fingerprint sensor works out of the box. Etc...

Re: Life is too short to depend on unstable software

#76
post #27

Earlier quoted context omitted.

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.

It is nowhere near as simple as you make it out to be. Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespace…

> NVidia client-side library must exactly match the version of the loaded kernel module

Sure about that? I was sure I’ve run Docker containers with GPU stuff compiled for different versions than my driver. Like their nbody container image runs every time I set up the nv container runtime with Docker, regardless of driver version.

Re: Life is too short to depend on unstable software

#77

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'd love to! Did you make sure your FOSS project is easy to build from source? I don't have to spend hours nagging the dev team for mysterious compilation bugs and dependencies? Projects that make this easy are the extreme exception, so if you actually get it right, then yes, I completely sympathize.

Re: Life is too short to depend on unstable software

#78

The most unstable software that I experienced was the original Mac. I'm sure that it cost me a non-trivial drop in my GPA.

Do you have nay more details on this? I am very curious.

I still have the Mac. It's now over 35 years old! Remember that the computer only had 128K of memory. There were like three applications. MacWrite, MacPaint, MacDraw. MacDraw was the most crash-prone.

What else might you like to know? I'll have to dust off some old neurons.

Re: Life is too short to depend on unstable software

#79
post #6
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.

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

Re: Life is too short to depend on unstable software

#80
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 have the same experience, my linux experience (as an user) improved by an order of magnitude when switching to Arch which has the same bleeding edge philosophy.
Post reply on HN