End of Life of Technologies and Devices
endoflife.date
endoflife.date
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...
It would be nice if these projects competed to get on the leaderboard.
It might make sense for certain categories (Mobiles, tablets) but it is so hard to get good data for those.
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.
Do you have plans to monetize it? I hope not. Because this is a thing that should exist in the world. I would much rather support this via donations than ads or anything else.
OpenCollective says that the total donations are $1,107.75 USD with 6 contributors. I threw another 20 bucks at them after reading that, but it seems like at least ads or something would make sense purely from a financial perspective, since even with 8M impressions, not that many are interested in donating sadly.
I do really enjoy the site, it has lots of technologies listed and looks very pleasant. Actually used it just this week, since I started building an API with the previous .NET LTS version but a new one came out, so I suddenly started having to install older package versions for compatibility reasons hah.
What are the operational costs of running such a site?
We're looking to join OpenEoX.org to standardize EoL information publication, but that requires a lot more funds (https://github.com/endoflife-date/endoflife.date/discussions...).
We also have a pretty long roadmap (https://github.com/endoflife-date/endoflife.date/issues/2108) that focuses on integrating better with the sbom ecosystem (We want to make an API that does SBOM->EOL alerts for eg). Such projects require a lot of development effort, and we'd like to be able to sponsor it on our own (via grants/donations).
You could consider making more expensive features paid options? Definitely tradeoffs there but it is an option, especially for business-useful features
2. We have an API (endoflife.date/api) and a upcoming v1 API (https://github.com/endoflife-date/endoflife.date/pull/2080) to let everyone use our data.
3. there's already a ton of companies/products that use the api/dataset (https://github.com/endoflife-date/endoflife.date/wiki/Known-...)
We plan to launch some services (https://github.com/endoflife-date/endoflife.date/issues/2108), but it will still be free.
We treat it as a community-built-semantic-wiki. Feedback is welcome.
- Would like a time line view: as of the next few months, what are expiring.
- Would like to see a stability score for a Product / Stack, you define the metrics for what is considered stable vs obsolete. How it compares with other similar categories.
Second is very subjective. If there's onething that I've learnt over the years working on this - it is that the definition of "support" is very fuzzy. You can't even compare what "LTS" means between different stacks/products, so it is hard to objectively rate anything. It still might be worth doing some analysis and publishing as a blog post though, but i'm not sure if it can be automatically calculated.
Could there also be something like a comparison view of devices and models where you can see overlapped timelines when support ended (e.g. in the past vs now?)
Also, something like repairability scores from e.g. ifixit would be amazing to integrate.
Whenever I am looking for devices, I am also on the lookout for whether or not a third party OS has upstream support for it at the time of buying (e.g. LineageOS or postmarketOS wiki) because the device isn't "just a dead thing" when there's an OS available that you can flash on it.
I tried to generate a visual timeline for a given page (https://github.com/endoflife-date/endoflife.date/pull/2859, has some screenshots), but it was limited to a single page (so you'd only see nokia devices at once for eg).
It turned out that it is too hard to generate clear charts with vague data. We often only know whether is device is supported or not (true/false, see comments about samsung below in this thread), and don't have clear release dates.
I'll get to it someday (PRs welcome), but it might not work for the usecase we want (picking phones) because data on mobiles is very vague.
repairability score -> sounds interesting, will file an issue and see. The hard part is that there's no clear identifiers for devices (SWID/CPE are just not good enough) for us to track this kind of data from elsewhere easily.
Of course sometimes there isn't any because many small projects have no official support cycle, but sometimes projects of significance, and even some commercial products, don't either. But sometimes there is and it isn't well documented (or sufficiently linked so it is hard to find).
Would you consider adding a timeline-like view, for instance pages listing everything due to go EOL or move between support categories (current, still under standard support, extended (full LTS), extended (limited, i.e. security only or common packages only)) this/next month/quarter/year? Those pages could be static and refreshed daily rather than needing resource to generate on each visit (filtering could be done client-side to allow more flexibility without extra server resource for dynamic generation). This could be done by a 3rd-party, but that might involve scraping the API/site in a way that imparts an unfriendly amount of load (unless I'm missing something, the data in the release-data repo doesn't contain everything that would be needed for this).
Generating pages isn't hard for us. We maintain it in our frontmatter/yaml (See https://github.com/endoflife-date/endoflife.date/blob/master... for example). The release-data repo is for tracking new releases of upstream products so we can patch the latest version automatically, and get notified of new major releases that are missing in our tables. release-data is a much smaller subset of our data, and doesn't include the critical EOL data.
We keep track of EOL dates in our internal wiki with links to various websites. Would be nice to reduce the scatter and just link to this site!
Would you accept Pull Requests that add server hardware EOS and EOL dates? They are especially hard to find and it would be great to have them in there as well!
Edit: I should have taken a look at open issues first, it seems there is tracking issue for network equipment so I guess adding server hardware is certainly not off the table (https://github.com/endoflife-date/endoflife.date/issues/1387).
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.
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
We have to redirect the /java page here, but stalled by some housekeeping of separating the 2 Oracle JRE pages.
.NET Framework support is tied to Windows itself.
https://learn.microsoft.com/en-GB/lifecycle/faq/dotnet-frame...
> On operating systems prior to Windows 10 version 1809 and Windows Server 2019, .NET 3.5 SP1 assumes the same lifecycle policy as the underlying OS on which it is installed.
I imagine the only help y'all need is for us to update EOL info when we see it?
Stock RSS feeds don’t work for future events, so they aren’t perfect for our usecase (warn users in advance of an upcoming date), so we offer ICS feeds instead.
RSS feed of just date changes might work, but ‘s hard to differentiate between a change that creates a feed notification vs one that doesn’t (new release, typo fix, date change by 2 days, and so on…)
If you want to keep your sanity and focus on building an actual business on a solid foundation, ignore all the upstream EOLs and just use a major stable Linux distro that promises to backport security fixes for 5+ years. The peace of mind is totally worth the larger container size.
Brian Lunduke once talked about GNU/Hurd and said they should do the following release cycle:
1. Spend a few months working on it and then declare that the 1.0 release.
2. Spend 2-3 years getting Hurd to work on as many architectures and systems as possible. Get all graphics cards types that you can working. Release 2.0.
3. Spend the next 10-15 years squashing as many bugs as possible. Continue working on getting as many drivers as necessary to get it working on as many platforms as possible. Then release 3.0.
4. At this point be done. For the next 100 years GNU/Hurd 3.0 is it. Just do security and driver updates.
I thought the idea of a “forever” OS was interesting. It would then never become “obsolete”.
Yes, I do think that is not enough. An OS should be thought of as scaffolding where parts of it are replaced but never the whole. And preferably while it is running, including all of the core.
If individual packages or services have to restart does not qualify for your requirements then I don’t think any system could truly provide that without having it run multiple instances of each service/itself.
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 forward to.
But the very idea of software having a pre-defined lifespan is not sensible. Do we put expiry dates on mathematical theorems?
Indeed it's a good argument for why all software should be FOSS, because it's ultimately the users of a program, not the developers that decide whether code has continuing utility.
As soon as money comes into development people start noticing the long tail is a precipice of diminishing returns, We act like landlords who can't be bothered to decorate crumbling buildings we rent out. Easier to knock it down and build anew, regardless the disruption for the tenants.
When software is built and maintained by the community that use it, they're more like homeowners, for whom maintenance is adding value to an asset.
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 sustained quarantine due to the novel airborne virus that became a pandemic some years ago, and (3) there is no mounted non-lethal (because animal welfare) protection against a hull-eating[1] marina pest that migrated from the Equator ten years ago because of climate change.
Software obsolescence is all about the world changing around the software.
[1] The boat might be perfect but apparently creatures can still eat it if determined enough.
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.
The metric to track is probably “lifetime emissions”, which a few vendors report. The majority of these are actually from manufacturing and not lifetime, resulting in every upgrade becoming an emission spike(?)
End-of-life dates - https://news.ycombinator.com/item?id=30499023 - Feb 2022 (54 comments)
Show HN: Endoflife.date – Site with EOL dates of everything - https://news.ycombinator.com/item?id=20033728 - May 2019 (80 comments)
Something like this? https://imgur.com/E0Wkxrt