191–200 of 252 posts
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.
Earlier quoted context omitted.
It certainly didn't help that they were annoying about it; like, they actively dropped some of the forward compatibility they had added (a key one being if you had already carefully used u and b prefixes on strings) in Python 3.0, and only added it back years later after they struggled to get adoption. If they had started their war with Python 3.5 instead of 3.0 it would be a lot less infuriating.
Not being a python dev, there must have been some huge superficial 'ick'. Back when, I was talking to a python guy and mentioned that Python 3 was coming out. He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. (or they really sobered-up and rewrote in Go or something.)
"It" was fixed long before the 2.7 official sunset date. Even before the original planned date before it got extended, frankly.
Earlier quoted context omitted.
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?
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…
Too young to remember Windows 3.1 and “DLL hell?” That was worse.
Earlier quoted context omitted.
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 major…
Having a plan for several hundred years is possible and we've seen such things happen in other facets of life. We as humans are clearly capable of building robust durable social organizations, religion and civics both being testaments. I'm curious how these plans would look and work in the context of software development. That was more what my question is about (also only being familiar with sqlite taking this seriou…
Earlier quoted context omitted.
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?
Thinking like this is how we ended up with a panic about Y2K. Programmers in the 1970s and 80s could not conceive that their code would still be running in 2000.
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…
static binaries will never stop working i was pointing out that you and OP are conflating a particular dev environment with the stability of linux itself. gui/games in particular on linux is not an area that shares this same stability yet
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…
static binaries will never stop working i was pointing out that you and OP are conflating a particular dev environment with the stability of linux itself. gui/games in particular on linux is not an area that shares this same stability yet
Yeah, if you compile all the dependencies and dependencies of dependencies and so on statically. Which is a fun experience I've tried several times (have fun trying to statically compile gfx drivers or crypto libraries for example), wasted a few evenings, and then had to repeat anyway because the as-static-as-possible binaries do stop working sometimes.
There's a reason linux distributions invented package managers.
> i was pointing out that you and OP are conflating a particular dev environment with the stability of linux itself.
We're talking software rot, not uptime? It's exactly about software stopping working on newer systems.
JS is hated but if you compile to browser JS that code will run in 2100. If you mainly deal with files / blobs not databases you will have these things in 2100 too. I think a lot of apps can be JS plus Dropbox integration to sync files. Dropbox may rot but make that a plugin (seperate .js file) and offer local read/write too and I think you'd be pretty future proof.
Things like E4X, sharp variables, and array comprehensions have already been removed; it's just that the mass of newer developers mean the average doesn't know about them. Unfortunately it's not like they never remove things.
There are some _very_ rare exceptions, but they're things like "support for subclassing TypedArrays", and even then this is only considered after careful analysis to ensure it's not breaking anyone.