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

Software Rot

permacomputing.net

Post reply on HN
Print view View original

161–170 of 252 posts

Re: Software Rot

#161

Post by esafak »

integralid wrote: post #121
gbin wrote: post #63

Earlier quoted context omitted.

How many times the virtualenv/pipenv/pyenv/... changed though? The package management also between wheels and setup and all the breakages. Even for somebody that did not aim to have python programs for 20y, python is definitely not a good example of a "pdf for programs"

I used virtualenv for the past 15 years and I don't recall it changing significantly. I don't get why people use new fancy tools like pipenv/pyenv/poetry/uv and then complain that there are too many tools to learn. There is nothing wrong with just using virtualenv. It has its warts but it always worked for me and it's stable.

If you see a wart report it: https://github.com/pypa/virtualenv/issues/

Re: Software Rot

#162

Post by Vegenoid »

This is why I put so much effort into working with POSIX shell code, despite its painful syntax. I can be pretty damn sure my knowledge will still be relevant in 30 years.

LLMs have also made reading and writing shell code much easier.

Re: Software Rot

#163

Post by [deleted] »

prinny_ wrote: post #110

I don’t get the comparison to building a house. Houses have a ton of maintenance. You can’t build a house on steady ground and leave it unattended for 20 years either. And sometimes what you need to do is not even construction type of maintenance, it’s bills, legal paperwork, replacing old furnitures just because you grew tired of that 15 year old sofa etc.

[deleted]

Re: Software Rot

#164

Post by ectospheno »

azemetre wrote: post #144
asa400 wrote: post #136

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

Does SQLite talk about how they plan to exist beyond 2050 across multiple lifetimes? Not trying to be chide but it seems like with such a young industry we need better social tools to make sure this effort is preserved for future devs. Churn has been endemic in our industry and it has probably held us back a good 20 years.

I’m trying and failing to think of another free software product I honestly expect to still work on my current data past 2050. And this isn’t good enough?

Re: Software Rot

#165

Post by whizzter »

saurik wrote: post #64
whizzter wrote: post #48

Earlier quoted context omitted.

2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the ar…

> 2005 is already 25 years ago o_O

Brainfart, the DDraw based demos I wrote about were made from 1999 to 2002 so around 25 years ago but then wrote 2005 because iirc the enterprise stuff I also mentioned were probably made around then. Regardless, it's all of the win2k-XP era vintage before Mac's and phones started gaining marketshare and developing with deep Windows integrations was a totally rational choice.

Re: Software Rot

#166

Post by 9rx »

prinny_ wrote: post #110

I don’t get the comparison to building a house. Houses have a ton of maintenance. You can’t build a house on steady ground and leave it unattended for 20 years either. And sometimes what you need to do is not even construction type of maintenance, it’s bills, legal paperwork, replacing old furnitures just because you grew tired of that 15 year old sofa etc.

Houses do require a ton of maintenance, but typically within a stable environment. Yeah, laws might change every once in a blue moon, and over hundreds of years climate change may alter the patterns of wear and tear, but for all intents and purposes what you know today is likely to still hold for tomorrow.

But if you build on a bog, then you've unnecessarily introduced a whole lot of new variables to contend with.

Re: Software Rot

#167

Post by jerf »

azemetre wrote: post #144
asa400 wrote: post #136

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

Does SQLite talk about how they plan to exist beyond 2050 across multiple lifetimes? Not trying to be chide but it seems like with such a young industry we need better social tools to make sure this effort is preserved for future devs. Churn has been endemic in our industry and it has probably held us back a good 20 years.

As the time horizon increases, planning for the future is necessary, then prudent, then sensible, then optimistic, then aspirational, then foolish, then sheer arrogance. Claiming 25 years of support for something like SQLite is already on the farther end of the good set of those adjectives as it is. And I don't mean that as disrespect for that project; that's actually a statement of respect because for the vast majority of projects out there I'd put 25 years of support as already being at "sheer arrogance", so putting them down somewhere around "optimistic" is already high praise. Claiming they've got a 50 or 100 year plan might sound good but it wouldn't mean anything real.

What they can do is renew the promise going forward; if in 2030 they again commit to 25 years of support, that would mean something to me. Claiming they can promise to be supporting it in 2075 or something right now is just not a sensible thing to do.

Re: Software Rot

#168

Post by staticshock »

azemetre wrote: post #144
asa400 wrote: post #136

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

Does SQLite talk about how they plan to exist beyond 2050 across multiple lifetimes? Not trying to be chide but it seems like with such a young industry we need better social tools to make sure this effort is preserved for future devs. Churn has been endemic in our industry and it has probably held us back a good 20 years.

Some churn is fads, but some is legitimate (e.g. "we know how to do this better now".) Every living system is bound to churn, and that's a good thing, because it means we're learning how to do things better. I'm happy to have rust and typescript, for instance, even though they represent some amount of churn for c and javascript.

Re: Software Rot

#169

Post by codeguro »

gjsman-1000 wrote: post #141
skydhash wrote: post #133

Earlier quoted context omitted.

It’s all volunteer work, not some corporation with trillions laying around. If you want something easy, use Debian (or ubuntu). They pretty much have everything under the sun. What you want to have (download software from the net and run it) is what most distro have been trying to avoid. Instead, they vet your code, build it, and add it to a reputable repo. Because no one wants to download postgres from some random s…

Last time I checked, Ubuntu/Canonical is a multimillion dollar company, Red Hat is a multibillion dollar company, SuSE sold for $2.5B, and The Linux Foundation has over $250M in revenue to spend only 3% on development of Linux specifically. Enough of the BS of "we're just volunteers" - it's fundamentally broken and the powers that be don't care. If multiple multibillion dollar entities who already contribute don't se…

Get over yourself. Linus himself said Linux is just a hobby. It just happened to be the best because of the lack of red tape dragging development down. It got as big as it did BECAUSE it was a volunteer project with the right choice of license and remains the best DESPITE big corps pouring money all around it. https://www.reddit.com/r/linux/comments/mmmlh3/linux_has_a_i...

Re: Software Rot

#170

Post by stereolambda »

roda73 wrote: post #123

This is one of the reasons I absolutely hate Linux based development and operating systems built with it. We all know it now as dependency hell, but what it is in fact is just a lazy shortcut for the current development that will bite you down the path. The corporate software is not a problem, because the corporate users don't care as long as it works now, in the future they will still rely on paid solutions that wil…

I sympathize with what you're saying. In theory Docker and Snaps and such are supposed to more explicitly package Linux programs along with their dependencies. Though Docker especially depends heavily on being networked and servers being up.

I'm not a fan of bundling everything under the sun personally. But it could work if people had more discipline of adding a minimal number of dependencies that would be themselves lightweight. OR be big, common and maintain backwards compatibility so they can be deduplicated. So sort of the opposite of the culture of putting everything through HTTP APIs, deprecating stuff left and right every month, Electron (which puts the browser complexity into anything), and pulling whole trees of dependencies in dynamic languages.

This is probably one of the biggest pitfalls of Linux, saying this as someone to whom it's the sanest available OS despite this. But the root of the problem is wider, it's just the fact that we tend to dump the reduction of development costs onto all users in more resources usage. Unless some big corp cares to make stuff more economical, or the project is right for some mad hobbyist. As someone else said, corps don't really care about Linux desktop.

Post reply on HN