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

141–150 of 252 posts

Re: Software Rot

#141

Post by gjsman-1000 »

skydhash wrote: post #133
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…

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 see the Linux desktop as having a future, if Linus Torvalds himself doesn't care enough to push the Foundation on it; honestly, you probably shouldn't care either. From their perspective, it's a toy, that's only maintained, to make it easier to develop the good stuff.

Re: Software Rot

#142

Post by skydhash »

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…

Those companies sell server OS support, not consumer desktop. And Linux is rock solid for that purpose.

Desktop Linux is OK. And I think it’s all volunteer work.

Re: Software Rot

#143

Post by ajuc »

count-delight wrote: post #140
ajuc wrote: post #35

Earlier quoted context omitted.

I also noticed this part of the article but for the oposite reason (I think 10-20 years is overly optimistic). I've written a small 2d game for Linux back in 00s. Using C++, SDL and a few other libraries (for example now-abandoned libparagui for GUI). Any time I tried to run it afterwards - I had to recompile it, and a few times I had to basically port it (because libparagui got abandoned and some stuff in libc chang…

Something I've been pondering recently: It is sometimes said that Apple is notorious on deprecating APIs and breaking backwards-compatibility at a rapid pace, but is it not fundamentally the same that is shared with Linux? Old developers lamenting that they have developed something useful in 2015-2015 that doesn't work in any more in 2025. And if Linux distributions do it and it can be thought to be a form of opinion…

Dunno I just never used Apple. It's not very popular over here.

Re: Software Rot

#144

Post by azemetre »

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.

Re: Software Rot

#145

Post by ozim »

immibis wrote: post #116
noduerme wrote: post #69

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL s…

Building on bedrock is one extreme; the other is to become extremely fluid - build on quicksand but do it efficiently every time the quicksand shifts. AS3 may stop being useful, but if you can use some tool to recompile AS3 code to web JavaScript, you suffer no loss.

Another example is people from EU making fun of US buildings.

Lasting centuries may or may not be preferable.

There are places where you want to cheaply rebuild from scratch. Your castle after tornado and flooding will be irreparably bad. Most castles suck badly by not taking advantage of new materials and I myself would not like to live in 100 yo building.

Same for software, there are pieces that should be build to last but there are applications that should be replaceable in short time.

As much as I am not fan of vibe coding I don’t believe all software should be built for decades to last.

Re: Software Rot

#146

Post by forgotmypw17 »

forgotmypw17 wrote: post #28
zeta0134 wrote: post #24

Earlier quoted context omitted.

Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine…

My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.

It's not just 2 to 3, either. Both 3.12 and 3.13 introduced breaking changes, that's once per year that you at minimum need to audit all your Python code to ensure it doesn't break.

Re: Software Rot

#147

Post by sbrkYourMmap »

This is the side effect of open source. And open source philosophy is at fault but rather developers themselves. We heavily rely upon code written by strangers and maintained by individual or a community without any obligation to any guarantees, including comparability and maintainability. At work when we are working with vendors that provide proprietary software we have contractual obligations, that amongst other things requires stable interfaces for long periods of time, and could be held liable for damages. Something modern model of open source can't offer

Re: Software Rot

#148

Post by begueradj »

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.

Maybe we could say something a bit similar about Express.js and other "boring technologies".

Re: Software Rot

#149

Post by ndriscoll »

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…

Use nixos. I install updates maybe every few months and it's fine. My desktop experience has been completely solid for almost a decade.

My work computer with Windows on the other hand requires restarts every day or two after WSL inevitably gets into a state where vscode can't connect to it for some reason (when it gets into such a state it also usually pegs the CPU at 100% so even unlocking takes a minute or more, and usually I just do a hard power off).

Re: Software Rot

#150

Post by BobaFloutist »

codeflo wrote: post #72
dgoldstein0 wrote: post #70

Earlier quoted context omitted.

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more ma…

That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.

If you're asking why software has more frequent rebuild cycles than, say, buildings, or roads, or plumbing, it's because it's way cheaper and easier, can be distributed at scale for ~free (compared to road designs which necessarily have to be backward compatible since you can't very well replace every intersection in a city simultaneously), and for all the computerification of the modern world, is largely less essential and less painful to get wrong than your average bridge or bus.
Post reply on HN