Show HN: Endoflife.date – Site with EOL dates of everything | Hacker News Reader

Show HN: Endoflife.date – Site with EOL dates of everything

endoflife.date

248 pointscaptn3m080 comments

I recently did a rant on twitter[0] on how release/download pages of various languages/tools get it wrong, especially with respect to giving EoL Dates/policy and a list of supported releases.

This is my attempt at solving the problem. If you have to every check the EoL date of anything, or if you have to verify that the version you have is supported, just visit endoflife.date/toolname.

The website runs on Netlify, and is built with Jekyll. All the data is stored as Front Matter in Jekyll itself. Contributions are welcome on GitHub to add more languages/tools etc.

[0]: https://twitter.com/captn3m0/status/1110504412064239617

This looks pretty useful to me. It would be cool if it were possible to sign up for an account which would let you created "projects" which consist of a list of the tools that you are using for a given project. Extra cool if you could input the version you are currently using, and get it to alert you if you are getting close to EOL.

I plan to add support for calendars that you can subscribe to. So you'll get notified 1, 3, 6 months in advance of approaching doom.

iCal shares (or however they are calling that format which can be consumed by multiple clients) would be super useful.

.ICS files. That is what I was going for.

If I add Fedora, Ruby, and a few other things will you accept the PR (assuming it's good of course. I just don't want to waste my time if you are already happy with the current list and don't want any more)?

Happy to accept PRs. That is half of why I posted it here.

There is a CONTRIBUTING file that details all the fields you can use.

I like it!

It would be nice to have (you knew this was coming, yes?) an API, whereby one could programmatically request, say,

https://endoflife.date/api/os/ubuntu/16.04

(Haven't thought through the semantics.)

Digression alert. I've been thinking of a multi-OS package analysis database that I wish existed. The idea being, a database of information on packages to answer questions like:

- Which packages of what OSes include the file path /usr/share/whatever/some/file.name?

- Which packages of what OSes include the file with this hash, and where does it install?

- On what date was this revision of that file included in this package?

And so on. This idea doesn't quite fit in to that model, but it is along the lines I'm thinking - that conveniently organized metadata across distros could be very useful in a number of ways. In particular, I've had each of those questions above; they can be surprisingly time consuming to answer. More generally, there's interesting research to do there with security implications, and I suspect there's interesting stuff to do with it that I haven't thought of yet.

THat'd be great, though there are many issues to handle:

- packages don't have the same name across distributions: python or python2? python or python3?

- most binaries don't have the same checksum (except scripts that aren't compiled: not many files)

- paths tend to change across distriutions: usual Linux has /bin/bash, FreeBSD has /usr/local/bin/bash, NixOS has... something else.

The closest I can think of are the per-distro databases, along with security advisories:

- warning: huge page hxxps://packages.debian.org/stable/allpackages ; https://www.debian.org/security/dsa-long

- https://www.archlinux.org/feeds/packages/ https://security.archlinux.org/

- http://pkg.freebsd.org/FreeBSD:12:amd64/latest/ https://www.freebsd.org/security/advisories.html + http://vuxml.freebsd.org/

- etc.

There are a lot of fuzzy edges. One big one is managing different aspects of "sameness" for a file in different contexts that makes sense. You mentioned the problems with binary hashes; there are others, like comments in scripts and config files. If distro-X just spams boilerplate at the top of the config file, is that the "same" file? What if they add or rewrite informational comments in a config file?

I think the answer is that sometimes they are; it depends on the question.

I also noticed that it is really easy to end up wanting to pull data from source repos and bug trackers, but down that path lies madness.

Anyway, I don't have any plans to start building this. But it is an interesting project to think through.

I want to suggest a side-wide search feature. The site is now pretty small, but when it become bigger, this feature will be very useful.

Thanks to the new theme I switched to, this is now implemented

Suggestion: Relative dates are nice ("1 year and 7 months"), but I'd have an easier time reading it with absolute dates as well ("2019-12-34").

You get the abs date if you hover (it's set as the title attr)

It'd still be nice to not have this tied to hover, relative dates are more useful to get a gist of how long you've got - those absolute dates are usually what you need to sell it to management.

I started with absolute dates, but my primary use-case is “How much time do I have?”, for which relative dates work better.

I’ll see if I can do better.

It can be done as

   1 year 7 days (2020-06-03)

   2020-06-03 (1 year 7 days)

If/when you do absolute days, don’t use US format :) (I don’t know hiw it is right now, can’t hiver on mobile)

It is YYYY-MM-DD

The best and the only true format :)

Or write out months to make clear which format it is (03 June 2020). That way it's clear for everyone which format was used

Some pages have that, and some don't. The iPhone page doesn't have absolute dates as titles, for example.

iPhones don’t have EOL vs Support dates, so I had to hack around it for the release. Will fix soon.

That would be fine if I wasn't using my phone.

I wonder why they didn’t use the `<time>` element for this.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

As far as I know, no browser actually does anything special with `<time>` elements. Might be nice for screenreaders though, so I'll see if I can switch.

I don’t know if this has been done but I suppose a good use of the `<time>` element would be for browser addons to target it and use the `datetime` attribute for something like “add to calendar (ical)” or “translate the text content to my locale” or something similar.

Mobile phones don’t have hover.

It's an annoying UX antipattern. It doesn't work on mobile, and forces one to use the mouse instead of just seeing the information in its more useful form.

If anything, why not put the "N days from now" text in the title attr instead?

Not every pattern that is controversial is an anti-pattern. Relative time is useful for a different reason than absolute time. One use case is not worse than the other, they're just different.

It is already there on hover, but maybe a site-wide dropdown would help.

Absolute dates are better for printing out on paper too.

Missing: EOL for 32-bit time_t is Jan. 19, 2038.

https://en.m.wikipedia.org/wiki/Year_2038_problem

open a pull request?

This also assumes you are using the current epoch. You could always be using a different epoch for that 32bit time.

I think this would be quite redundant, until maybe 5-10 years from now. The 2038 is right there in the date, so not like anybody needs reminding.

Hey, this seems like a pretty useful website, one quick comment is that it does not seem to be easily usable by colorblind people. Almost 10% of males are red-green colorblind, so while normal people can quickly scan through the lists using color, colorblind people have to manually read each 'Ends in ...' or 'Ended ...'.

Not a huge issue in this case since generally you would lookup your product on the left side of the table and then look at a single cell on the right side, but it can't hurt to switch to an alternative color scheme - blue + olivegreen is one that I've seen pretty often.

I picked the colorscheme from https://flatuicolors.com/palette/ca, and assumed it would work.

Thanks for the feedback, I'll improve upon this.

Using some sort of patterned background as well as color would help. diagonal lines, zigzag lines, etc, like some patterns at https://www.transparenttextures.com

What's the sort order? It doesn't change on refresh, but e.g. Python has 4y, 2y, 7m, 1y, in that order, being 3.x, 3.x, 2.x, 3.x respectively.

Is it just random but cached?

I think best might be release version order - it's correlated to EOL, but also shows how far behind you are if you have to look down.

It is the same as the ordering in the metadata file. (Python.md).

I like the release date suggestion, will implement.

Potentially a very useful convenience. A couple of suggestions:

1. I would make it a bit more obvious when versions are not yet released. For instance nodejs v14 is listed with its planned support lifetime in the same colours as v12. While there is an indication that this is not a current release (no content in the release column for that row), it might be useful to also alter the colouring (perhaps fade or grey it out a bit?).

1.1. Or instead perhaps leave out unreleased versions for consistency (you don't list Debian 10 for instance, though there is some info out there: expected release mid 2019, expected mainstream support to mid 2022, expected LTS (server only) to mid 2024: https://en.wikipedia.org/wiki/Debian_version_history#Release...

1.2: Or perhaps list future releases in a second table?

2. A couple of things that might be useful to add if you have time to add and maintain the info: MS SQL Server versions & their service packs and Firefox ESR versions.

3. A display bug: at any window size in current Chrome on Windows with default zoom, "Fedora Linux" wraps in a way that suggests "Linux" is a separate item in the list. Perhaps use a non-breaking space to help that?

An issue with the iPhone page: https://endoflife.date/iphone

It doesn't list 6s which is an entirely different model than the 6. AFAIK the 6s IS still in production.

Issue a pull request?

The RHEL page is mostly useless... it only has RHEL 8 which won't EOL for a while. What we really need are RHEL 6 and 7; 7 won't EOL for some time.

I don’t use RHEL so I wasn’t sure what to include and what to exclude. (And the Release Policy is like 5 pages long). So I just left the image without the versions being covered.

Now that I now, will give it a shot. Can I reach out to you for a review once the PR is up?

Probably doesn't matter, but with rhel eol is virtually nonexistent, you put enough money in their face and they will support you forever. We have a few machines running very old rhel versions because we put enough money in front of them and they couldn't say no.

Really great idea, thank you! I can't believe I hadn't thought of this before.

It would be awesome to have a simple API as well that can be curl'ed from a script. I think we could possibly make it work with the current Jekyll base by just rendering JSON in addition to HTML. I'm willing to give it a shot if that's something people would like (unless someone else wants to).

I do that for another one of my Jekyll projects: https://hackercouch.com which has a simple API.

Will add it soon.

The Ubuntu page is a little confusing. The "security support" on that page appears to be "Extended Security Maintenance" which is available for kernel security updates, and only if you have a subscription to the Ubuntu Advantage.

Normal security support is over for Ubuntu 14.04.

Agreed, for most users there's effectively no ongoing support for 14.04, which makes the way it appears in this table highly misleading. Based on this I wouldn't recommend this list.

For this kind of situation I would suggest marking the item in red with a footnote indicating that some limited support is still available.

You might want to add:

    white-space: nowrap;

To the CSS class 'page-link' to prevent the situation where a link is broken on a space, allowing it to simultaneously be at both the end of one line, and at the start of the next.

This made it even worse (everything was one line). I tried changing "Fedora Linux" to Fedora, and even that doesn't work.

CSS!

That might be because everything isn't one line for myself. It's a bit of a hack, because HTML usually thinks it's fine to break a text cell on a space, and this prevents it.

There's probably better solutions, like maybe converting spaces in title links to nbsp.

It was just a quick hack that seemed to work for me. I obviously didn't test it on bigger screens. Whoops.

Switched to a different theme, and this is now fixed.

Painless solution, I like it.

I repeatedly google this stuff en mass and thought a community-managed website would be a really great so thank you for saving me loads of effort! I'll be PR-ing a bunch of stuff to help out ;)

It may be worth adding a per-version EOL cell, and potential caveats. Windows operating systems, for example, can receive paid support if you happen to have a billion dollars laying around.

Edit: By per-version EOL cell, I mean to allow URL references on a per-version basis for websites that don't list them all on one page, or at all. While there a date-released may also be super useful in some situations when you're trying to figure out how long since it's been patched.

My pet peeve is Python specifically. They have a PEP per release which basically tells you what all will become EOL on this release, which is very confusing.

And they also list unsupported releases on the main download page.

Can you clarify on the “release cell” part? Not sure what you mean by that.

I get you on the Windows part. It took me quite some time to figure out what all is even possible. The Windows page definitely needs a disclaimer.

Sorry I'm not actually sure what they're called but for each release, list the date it was released in a <td>.

Is this information manually maintained? It might honestly be nicer to see if you can locate the primary source for these projects and just iframe in that authoritative document to avoid running the risk of being out of date.

The metadata isn’t hard to maintain (only the Latest Release field changes often). And I made this because the authoritative source are very often confusing with no clear dates.

PHP supported release page is great for eg, but Python is a mess.

As a dev working primarily in PHP I hear all you're saying, but am mostly just enjoying the PHP > Python moment ;P

That's good to hear, as I sort of said, my primary concern for EOLs is that they have been known to change over time and when they do I'd like to be sure the source I'm relying on is tracking those changes.

Yeah, if this was published in a API format upstream, might have been possible.

I don’t want to iframe it for sure (won’t even work for all sites).

I understand the pain point though. Maybe having a “Last Updated” date can provide a confidence estimate of sorts?

Absolutely, yea. That would help quite a bit - or even a "Last verified" date.

Big fan of this, excellent idea. EOL is always non-trivial to find for each project.

I think a good addition could be a feed of some sort available for each project e.g. https://endoflife.date/ruby/feed. You could then poll that from readers or Slack integrations and be notified when particular projects have entered EOL. Maybe an early warning for could be useful too, 3 months before EOL or something like that?

It's a shame, BDNA's Technopedia used to have an excellent, free online search engine that could be leveraged to search EOL information.

For context, Technopedia is a library that, for a yearly subscription, could supplement detailed supplier End of Life/Support/Extended details onto your CMDB/Asset Management System. It was a godsend when dealing with large software audits.

Flexera have since acquired BDNA, and from the looks of things, the public access to the system has been locked out: https://portal.technopedia.com/landing

Might be worth checking out for those who are in large orgs and have to deal with this problem en mass.

> More Information is available on the Python website.

but the link points back to the same page https://endoflife.date/python

There is a page on python.org for this, but I can never find it.

It was a bit of a pickle to find, but https://devguide.python.org/ has EOL dates under "Status of Python branches"

That is what I used as reference. Note how the table differentiates between Security and EOL but doesn’t provide dates for the first, since they are dependent on future releases.

I’ll fix the link.

Will it do the milk and cheese in my fridge?

Thanks for making this, I was actually wondering the version of node.js to use on a new project and this helped me decide on going with v12 :)

Wow, this is pretty handy! I feel I used to search a lot more fore these things than I should have. Good job!

Super cool idea, I regularly check the wikipedia pages of Debian and Ubuntu for this stuff.

Nice concept. As a suggestion, I think a single page with #bookmarks would be more easily read than individual pages selected from the menu bar. But I’d be curious to hear the pros of the current design choice.

Visited on safari / iPhone SE (small screen)

this is unfair because it, for a moment, got me excited that there was an end of life date for windows in general ;)

Lifecycles of the long term (LTSB/LTSC) versions of Windows 10 and Server would be a good addition to the list.

it's weird because LTS is in the "notes" section, but not mentioned elsewhere on the page.

I have it committed locally, will push.

I love it Please add Cisco

I would agree that hardware would be beneficial.

This is great! Thanks for building this!

Reply on news.ycombinator.com