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

by captn3m0 • 7 years ago

248 80 7 years ago

captn3m022• 7 years ago

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

nicoburns• 7 years ago

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.

captn3m022• 7 years ago

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.

freedomben2• 7 years ago

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

captn3m022• 7 years ago

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.

_jal2• 7 years ago

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.

moviuro• 7 years ago

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.

letientai299• 7 years ago

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.

captn3m022• 7 years ago

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

yjftsjthsd-h• 7 years ago

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• 7 years ago

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

munk-a4• 7 years ago

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.

ken• 7 years ago

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

choward• 7 years ago

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

runarberg2• 7 years ago

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

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

dmitriid3• 7 years ago

Mobile phones don’t have hover.

TeMPOraL• 7 years ago

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?

captn3m022• 7 years ago

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

xtagon• 7 years ago

Absolute dates are better for printing out on paper too.

aoeuidiue2• 7 years ago

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.

captn3m022• 7 years ago

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.

aoeuidiue2• 7 years ago

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

munk-a4• 7 years ago

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.

captn3m022• 7 years ago

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-a4• 7 years ago

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.

IAmLiterallyAB• 7 years ago

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.

captn3m022• 7 years ago

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• 7 years ago

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.

freedomben2• 7 years ago

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

captn3m022• 7 years ago

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

Will add it soon.

j88439h84• 7 years ago

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.

akovaski• 7 years ago

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

captn3m022• 7 years ago

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.

OJFord• 7 years ago

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.

captn3m022• 7 years ago

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

I like the release date suggestion, will implement.

shakna3• 7 years ago

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.

captn3m022• 7 years ago

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

CSS!

shakna3• 7 years ago

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.

xeeeeeeeeeeenu• 7 years ago

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

gruez• 7 years ago

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

captn3m022• 7 years ago

I have it committed locally, will push.

pathartl• 7 years ago

Will it do the milk and cheese in my fridge?

rladd• 7 years ago

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.

kiran-rao• 7 years ago

Issue a pull request?

nvr219• 7 years ago

I love it Please add Cisco

cya_1283• 7 years ago

I would agree that hardware would be beneficial.

cogburnd02• 7 years ago

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

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

Tepix• 7 years ago

open a pull request?

warmwaffles• 7 years ago

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

captn3m022• 7 years ago

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• 7 years ago

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.

captn3m022• 7 years ago

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

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

mgkimsal• 7 years ago

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

kissgyorgy• 7 years ago

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

ixtli• 7 years ago

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

muhammadusman• 7 years ago

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

wink• 7 years ago

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

craigds• 7 years ago

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• 7 years ago

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.

dspillett• 7 years ago

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?

haydenkshaw• 7 years ago

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?

mxuribe• 7 years ago

This is great! Thanks for building this!

rorychatt• 7 years ago

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.

philshem• 7 years ago

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)

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

Related Stories