[HN Gopher] End of Life of Technologies and Devices
___________________________________________________________________
End of Life of Technologies and Devices
Author : pbshgthm
Score : 303 points
Date : 2023-12-10 07:10 UTC (3 days ago)
(HTM) web link (endoflife.date)
(TXT) w3m dump (endoflife.date)
| captn3m0 wrote:
| 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...
| jl6 wrote:
| 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.
| captn3m0 wrote:
| I'm not sure if that's a good idea. Maintaining long-term-
| support, especially for open-source projects with volunteers
| is a unacknowledged (and often unpaid) work.
|
| It might make sense for certain categories (Mobiles, tablets)
| but it is so hard to get good data for those.
| trommlp wrote:
| 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.
| hosteur wrote:
| Thanks for making this. I really like it.
|
| 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.
| KronisLV wrote:
| > Do you have plans to monetize it? I hope not.
|
| 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.
| 0x000042 wrote:
| > 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.
|
| What are the operational costs of running such a site?
| captn3m0 wrote:
| Currently none, but that's mostly because we've worked
| hard to keep it that way. I publish finance updates on a
| GitHub Discussion (https://github.com/endoflife-
| date/endoflife.date/discussions...). We used to pay $9/mo
| for Netlify Analytics but didn't find it helpful.
|
| 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).
| yjftsjthsd-h wrote:
| > We want to make an API that does SBOM->EOL alerts for
| eg
|
| You could consider making more expensive features paid
| options? Definitely tradeoffs there but it is an option,
| especially for business-useful features
| teepo wrote:
| This is a great idea. Hopefully this gets more attention
| and resources. You're really well positioned to fill a
| gap in the ecosystem.
| midasuni wrote:
| Setting aside a HN spike, $100 a year should be fine for
| hosting. Or use someone else's hosting platform like
| GitHub, cloudflare etc for the cost of a domain name.
| samzscott wrote:
| Have you considered offering a subscription-based service?
| (e.g. for timely notifications / compliance reporting / etc.)
| captn3m0 wrote:
| 1. We already have a calendar feed that you can subscribe to,
| for every product that will warn you accordingly.
|
| 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.
| moffkalast wrote:
| I take it Samsung doesn't typically announce their products'
| support times, given that most of them just have a "Yes"
| instead of a date?
| captn3m0 wrote:
| Yes. we sometimes track such times using web archive, but
| it's not perfect and its easier to just use yes/no (See
| https://github.com/endoflife-date/endoflife.date/pull/4235
| for eg).
| vkaku wrote:
| Thank you for making it.
|
| - 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.
| captn3m0 wrote:
| We have an open issue for a timeline view:
| https://github.com/endoflife-date/endoflife.date/issues/2148
|
| 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.
| cookiengineer wrote:
| This is an amazing project!
|
| 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.
| captn3m0 wrote:
| > where you can see overlapped timelines when support ended
|
| 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.
| dspillett wrote:
| Could be a very useful resource. There have been a couple of
| occasions when I've found it harder than it should be to find
| EOL information.
|
| 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).
| captn3m0 wrote:
| Yes, we have an open issue for such timelines
| (https://github.com/endoflife-
| date/endoflife.date/issues/2148). Your comment has given me
| the idea to implement it on our "tag" pages, so you could see
| the timeline for all java-runtimes in one place for eg.
|
| 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.
| trommlp wrote:
| In the case of commercial products it is especially
| frustrating if you need to log in to some customer portal in
| order to find such basic product information. And even if you
| create an account and log in it is not guaranteed to find
| this information. I can relate to a certain extend as some
| companies might not even know when they plan to end support
| for a product, but even this is information that is worth
| sharing with their customers.
| captn3m0 wrote:
| Fortigate is one such vendor we already cover, such
| information deserves to be free not behind login or
| paywalls.
| trommlp wrote:
| Thank you for creating this.
|
| 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).
| nomercy400 wrote:
| 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.
| layer8 wrote:
| Seconding this. As it stands, the Java page is only of very
| limited use.
| captn3m0 wrote:
| Does this help: https://endoflife.date/tags/java-
| distribution
| layer8 wrote:
| Yes, though it would be more helpful to have a comparison
| chart of the various (Open)JDK distributions, because for
| most purposes they are exchangeable, apart from the
| support terms.
| bcx5k15 wrote:
| Amazon Corretto 8 is widely used in the Finance industry for
| example
| sofixa wrote:
| > 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
| captn3m0 wrote:
| We already track almost all of them.
| https://endoflife.date/tags/java-distribution
|
| We have to redirect the /java page here, but stalled by some
| housekeeping of separating the 2 Oracle JRE pages.
| pjmlp wrote:
| Great website, note that .NET doesn't show .NET Framework
| content, with latest being .NET Framework 4.8.1.
|
| .NET Framework support is tied to Windows itself.
|
| https://learn.microsoft.com/en-GB/lifecycle/faq/dotnet-frame...
| robg wrote:
| 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?
| robg wrote:
| 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.
| seeingnature wrote:
| I just want to say that I love this and have it bookmarked!
| I've moved into my 30s and am now thinking about life
| "maintenance first" and this will be a helpful resource for
| planning.
|
| I imagine the only help y'all need is for us to update EOL info
| when we see it?
| dang wrote:
| Related:
|
| _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)
| globalnode wrote:
| i read this literally, was going to look up some stuff for an
| ageing parent
| iseanstevens wrote:
| Same! English can be so tricky!
| unwind wrote:
| Also not a native speaker, but the second "of" makes that
| interpretation impossible (in theory, obviously not for you in
| practice).
| tjpnz wrote:
| I thought it would be about Sarco pods and exit bags.
| userbinator wrote:
| Should be called The Planned Obsolescence Shaming Site.
| kemotep wrote:
| In the case of operating systems, do you think 10 or so years
| of support is not enough?
|
| 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".
| jacquesm wrote:
| > In the case of operating systems, do you think 10 or so
| years of support is not enough?
|
| 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.
| kemotep wrote:
| In a way, rolling release linux distros meet your
| requirements.
| jacquesm wrote:
| Still reboots though, doesn't it?
| kemotep wrote:
| I know there are features to hotpatch the kernel, don't
| know if that's limited to Red Hat or Ubuntu or if
| something like Arch can do it too.
|
| 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.
| pierrelf wrote:
| Huh never knew that was their plan, such a shame Hurd isn't
| completed! I wonder if such a vision could be possible with a
| simpler os like FreeRTOS or similar
| kemotep wrote:
| That's not the actual plan for GNU Hurd that was Brian
| wishcasting.
| avgcorrection wrote:
| Thankfully it's a practical informational website and not
| something frivolous like that.
| blackoil wrote:
| Most of stuff there still works just not supported. You are
| free to run Java 2 or Windows 95, just you won't get any free
| support for it forever. Check with MS for right money they may
| even support it.
| nonrandomstring wrote:
| 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
| 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.
| qiine wrote:
| great metaphor
| avgcorrection wrote:
| 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 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.
| nonrandomstring wrote:
| 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 :)
| scarface_74 wrote:
| Who is going to pay for development?
| Qwertious wrote:
| >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.
| nektro wrote:
| why is the sidebar not on the side, so frustrating to use
| captn3m0 wrote:
| Sorry, can you clarify - you'd like the site to take full-width
| and the sidebar to be left-aligned?
|
| Something like this? https://imgur.com/E0Wkxrt
| cheschire wrote:
| I'm not GP but my problem with the sidebar is, at least on
| iPadOS, it does not scroll to match the page on the screen.
| Most times it scrolls the sidebar way too far and I can't
| quickly flip through two or three similarly named pages. For
| example, I was trying to look at both Microsoft .NET pages.
| brutal_chaos_ wrote:
| Crowd sourced EOL docs. I like it!
| pvorb wrote:
| This nicely shows how insane the world is that we live in. There
| are many core pieces of technology on that site and almost all of
| them go EOL within 2 or 3 years. Anything that builds upon these
| pieces of technology will take some time to support the new
| version, so the time frame is actually even shorter.
| Culonavirus wrote:
| Yea, some of these (e.g. PHP) have dozens of minor/bug fix
| releases which then just suddenly stop which just shows that
| you're vulnerable all the time... either because the release
| isn't "mature yet" or because it's "already eol" :)
| kijin wrote:
| Nothing ever gets "mature" in today's web development
| environment. As soon as something becomes stable, people
| don't find it exciting anymore so the devs need to introduce
| new features, create new bugs, and make backward-incompatible
| changes.
|
| 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.
| gku wrote:
| I've recently updated the Lambda functions to Amazon Linux 2023,
| only to find that its standard support apparently expires earlier
| than that of the older Amazon Linux 2.
| captn3m0 wrote:
| The lambda runtimes are separately documented:
| https://endoflife.date/aws-lambda
| robg wrote:
| Maybe also smartwatches as features increasingly include health
| algorithms based on the sensors involved? You could also get
| grants in that direction.
| dcchambers wrote:
| I love this site. Has been my go to for years for quickly looking
| up EOL info for literally every major piece of software in our
| tech/infra/platform stack. Props to the maintainers.
| squarefoot wrote:
| 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)
| captn3m0 wrote:
| PRs welcome, although I think this is more suited to something
| like Wikidata. As I noted elsewhere, the lack of standard
| identifiers for devices makes this especially hard. Companies
| will often release the same hardware with different model
| numbers at different timelines and support cycles across
| different geographies.
|
| 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(?)
| DeathArrow wrote:
| A Thinkpad doesn't have an End of Life. It just passes down from
| generation to generation.
| aaronax wrote:
| Pretty nice to have this level of openness on a data set. In my
| dreamworld all the data would be in Wikidata.
| ChrisArchitect wrote:
| Show HN: from 2019
|
| https://news.ycombinator.com/item?id=20033728
___________________________________________________________________
(page generated 2023-12-13 23:02 UTC)