
Show HN: Endoflife.date – Site with EOL dates of everything - captn3m0
https://endoflife.date/
======
captn3m0
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](https://twitter.com/captn3m0/status/1110504412064239617)

~~~
_jal
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](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.

~~~
moviuro
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.debian.org/security/dsa-long)

\-
[https://www.archlinux.org/feeds/packages/](https://www.archlinux.org/feeds/packages/)
[https://security.archlinux.org/](https://security.archlinux.org/)

\-
[http://pkg.freebsd.org/FreeBSD:12:amd64/latest/](http://pkg.freebsd.org/FreeBSD:12:amd64/latest/)
[https://www.freebsd.org/security/advisories.html](https://www.freebsd.org/security/advisories.html)
\+ [http://vuxml.freebsd.org/](http://vuxml.freebsd.org/)

\- etc.

~~~
_jal
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.

------
yjftsjthsd-h
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").

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

~~~
munk-a
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.

~~~
captn3m0
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.

~~~
dmitriid
It can be done as

    
    
       1 year 7 days (2020-06-03)
    

or

    
    
       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)

~~~
captn3m0
It is YYYY-MM-DD

~~~
dmitriid
The best and the only true format :)

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

[https://en.m.wikipedia.org/wiki/Year_2038_problem](https://en.m.wikipedia.org/wiki/Year_2038_problem)

~~~
captn3m0
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.

------
the_pwner224
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.

~~~
captn3m0
I picked the colorscheme from
[https://flatuicolors.com/palette/ca](https://flatuicolors.com/palette/ca),
and assumed it would work.

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

~~~
mgkimsal
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](https://www.transparenttextures.com)

------
OJFord
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.

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

I like the release date suggestion, will implement.

------
dspillett
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...](https://en.wikipedia.org/wiki/Debian_version_history#Release_table)

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?

------
rladd
An issue with the iPhone page:
[https://endoflife.date/iphone](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.

~~~
kiran-rao
Issue a pull request?

------
IAmLiterallyAB
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.

~~~
captn3m0
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?

~~~
pard68
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.

------
freedomben
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).

~~~
captn3m0
I do that for another one of my Jekyll projects:
[https://hackercouch.com](https://hackercouch.com) which has a simple API.

Will add it soon.

------
craigds
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.

~~~
JeremyNT
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.

------
shakna
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.

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

CSS!

~~~
shakna
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.

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

~~~
shakna
Painless solution, I like it.

------
aoeuidiue
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.

~~~
captn3m0
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.

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

------
munk-a
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.

~~~
captn3m0
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.

~~~
munk-a
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.

~~~
captn3m0
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?

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

------
haydenkshaw
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](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?

------
rorychatt
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](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.

------
j88439h84
> More Information is available on the Python website.

but the link points back to the same page
[https://endoflife.date/python](https://endoflife.date/python)

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

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

~~~
captn3m0
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.

------
pathartl
Will it do the milk and cheese in my fridge?

------
muhammadusman
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 :)

------
philshem
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)

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

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

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

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

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

~~~
captn3m0
I have it committed locally, will push.

------
nvr219
I love it Please add Cisco

~~~
cya_1283
I would agree that hardware would be beneficial.

------
mxuribe
This is great! Thanks for building this!

