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

End of Life of Technologies and Devices

endoflife.date

Post reply on HN
Print view View original

51–60 of 81 posts

Re: End of Life of Technologies and Devices

#51

Post by robg »

robg wrote: post #50
captn3m0 wrote: post #2

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors or https://opencollective.com/endoflife-date We recently crossed 8M impressions via Google Search this month: https://github.com/endoflife-date/endoflife.date/discussions...

Great effort! As I’ve realized the folly of updating my phone every 2-3 years, have you considered a sign up to be notified that my device is reaching its end of life?

As an example, my cellular provider gives a discount assuming I’ll be BYOD for the next three years. I’m really curious if I can make it past those three years. It would mean my phone is 5 years old at that point.

Re: End of Life of Technologies and Devices

#53

Post by [deleted] »

captn3m0 wrote: post #2

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors or https://opencollective.com/endoflife-date We recently crossed 8M impressions via Google Search this month: https://github.com/endoflife-date/endoflife.date/discussions...

[deleted]

Re: End of Life of Technologies and Devices

#54

Post by nonrandomstring »

avgcorrection wrote: post #49
nonrandomstring wrote: post #23

Earlier quoted context omitted.

In the 80s Ian Sommerville wrote about the "long tail" of maintenance accounting for >75% of the lifecycle costs of a program. I remember being surprised at this, but my SE prof saying "all successful projects tend toward 100% maintenance." If developers want to put a time limit on how long they're willing to maintain a project that's all fine and useful. Coders have lives to get back to and new interests to look for…

Sure, you can maintain it if you want. And they ought to give you the means to. But that’s a bad comparison. I bought a perfect, will never deteriorate houseboat twenty years ago (it is now 2043) and moved it across the world. But now in the harbor of Hong Kong I won’t get a permit to stay there because there is (1) no onboard emergency manual in either Cantonese or Mandarin, and (2) it is not up to code for sustaine…

Love the hull eating creatures that must only be humanely killed. Yeah, things never stand still. And those best equipt and informed to make changes for changing times are end-users in whatever context they find themselves, post-apocalypse or otherwise :)

Re: End of Life of Technologies and Devices

#55

Post by scarface_74 »

nonrandomstring wrote: post #23
userbinator wrote: post #6

Should be called The Planned Obsolescence Shaming Site.

In the 80s Ian Sommerville wrote about the "long tail" of maintenance accounting for >75% of the lifecycle costs of a program. I remember being surprised at this, but my SE prof saying "all successful projects tend toward 100% maintenance." If developers want to put a time limit on how long they're willing to maintain a project that's all fine and useful. Coders have lives to get back to and new interests to look for…

Who is going to pay for development?

Re: End of Life of Technologies and Devices

#56

Post by trommlp »

jl6 wrote: post #8
captn3m0 wrote: post #2

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors or https://opencollective.com/endoflife-date We recently crossed 8M impressions via Google Search this month: https://github.com/endoflife-date/endoflife.date/discussions...

Can you create a Hall of Fame/Shame view which lists the top/bottom n products by longest support period? It would be nice if these projects competed to get on the leaderboard.

I think calling it the Hall of Fame/Shame is unjustified.

I certainly agree when we talk about hardware products, because having very short support periods for those just seems wasteful.

But it gets difficult when entering software, because it probably differs from user to user how fast they would like the software to evolve. I can think of software that I want to be boring and work forever the way it does now without changing (except security bug fixes ..). So support periods are long and consist only of patch releases. And then there is software where I am waiting eagerly for new features to be added and would like the maintainers/the company to focus their attention on it if possible, thus taking resources from the maintenance side of things and moving them to the feature-factory. So support periods may be short and major/minor release bumps happen frequently.

Having one of these products in the Hall of Fame and another rot in the Hall of Shame does not seem to add any informational value.

Re: End of Life of Technologies and Devices

#58

Post by squarefoot »

Very nice, I never heard of that site before. A possible addition, for hardware devices, could be a field reporting their environmental footprint, that is, how much waste is produced by simply marking a product as obsolete forcing users to ditch it instead of opening it so that it can be repurposed by the community by installing lighter OSes and apps, or reused in completely different contexts (example: old phone -> IoT terminal)

Re: End of Life of Technologies and Devices

#59

Post by sofixa »

nomercy400 wrote: post #40
captn3m0 wrote: post #2

Creator here, happy to answer any questions about what it takes to build a collaborative Wiki for tracking support life cycles. You can support our work on GitHub Sponsors or https://opencollective.com/endoflife-date We recently crossed 8M impressions via Google Search this month: https://github.com/endoflife-date/endoflife.date/discussions...

Thanks for the site. It answered a question I had in the back of my mind, but hadn't found the time to look up. One suggestion I hope you can look into: the Java world is a lot bigger than just Oracle Java, with multiple implementations where End-of-Life greatly differs. If possible, people avoid Oracle Java. Look up OpenJDK, Eclipse Temurin, Azul, IBM Semeru. There are some more, but I have never used them.

> One suggestion I hope you can look into: the Java world is a lot bigger than just Oracle Java, with multiple implementations where End-of-Life greatly differs. If possible, people avoid Oracle Java. Look up OpenJDK, Eclipse Temurin, Azul, IBM Semeru

https://endoflife.date/openjdk-builds-from-oracle

https://endoflife.date/microsoft-build-of-openjdk

https://endoflife.date/redhat-build-of-openjdk

https://endoflife.date/eclipse-temurin

https://endoflife.date/azul-zulu

https://endoflife.date/ibm-semeru-runtime

https://endoflife.date/amazon-corretto

Re: End of Life of Technologies and Devices

#60

Post by Qwertious »

nonrandomstring wrote: post #23
userbinator wrote: post #6

Should be called The Planned Obsolescence Shaming Site.

In the 80s Ian Sommerville wrote about the "long tail" of maintenance accounting for >75% of the lifecycle costs of a program. I remember being surprised at this, but my SE prof saying "all successful projects tend toward 100% maintenance." If developers want to put a time limit on how long they're willing to maintain a project that's all fine and useful. Coders have lives to get back to and new interests to look for…

>But the very idea of software having a pre-defined lifespan is not sensible. Do we put expiry dates on mathematical theorems?

IMO it made a lot of sense when the hardware was changing rapidly - when the speed of new hardware doubled every year or two, maintaining existing hardware for more than a decade or two was often just a bad idea. And new hardware usually means porting or rewriting the software.

Nowadays though, hardware has largely peaked - CPUs are getting faster, but not that much faster. We won't see five doublings of CPU speed (64x increase) in our lifetimes, let alone in a decade. Security issues and repairability aside, today's hardware and operating systems will be perfectly serviceable in, say, 30 years.

Post reply on HN