4 ms·

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 an

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

nicoburns 7y 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.
- captn3m0 7y 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.
  - rzzzt 7y ago
    iCal shares (or however they are calling that format which can be consumed by multiple clients) would be super useful.
    - captn3m0 7y ago
      .ICS files. That is what I was going for.
freedomben 7y 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)?
- captn3m0 7y 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.
deleted 7y ago
[deleted]
_jal 7y 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 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 7y 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.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 7y ago
    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.
letientai299 7y 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.
- captn3m0 7y ago
  Thanks to the new theme I switched to, this is now implemented

nicoburns 7y 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.

captn3m0 7y 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.
- rzzzt 7y ago
  iCal shares (or however they are calling that format which can be consumed by multiple clients) would be super useful.
  - captn3m0 7y ago
    .ICS files. That is what I was going for.

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

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

deleted 7y ago

[deleted]

_jal 7y 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 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 7y 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.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 7y ago
  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.

letientai299 7y 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.

captn3m0 7y ago
Thanks to the new theme I switched to, this is now implemented