Corrections
A reference site with no corrections page is either perfect or not looking. This is the policy and the log.
How do I report an error on Tech Digest?
Email editor@techdigest.site with the page address and what is wrong. A link to the primary source that contradicts us, the project's documentation, its LICENSE file or its release notes, gets it fixed fastest. Substantive errors are corrected and logged publicly on this page with the date, the original claim and the correction. Typos and formatting are fixed without a log entry.
The policy#
Errors are fixed, and the ones that mattered are recorded here in public.
Logged on this page: anything that could have led a reader to a worse decision. A wrong licence, a wrong version number, a wrong memory figure, a wrong claim about what a project supports, a broken or unsafe command, a verdict resting on a fact that turned out to be false.
Fixed without a log entry: typos, grammar, formatting, broken links, and clarifications that do not change the meaning.
Handled as an update rather than a correction: a verdict that changes because the software changed. Those are noted in the page itself, with what changed and why, and the review date moves. A page that has been quietly rewritten is worth less than one that admits it used to say something else.
Treated as urgent: anything that could cause data loss. A wrong backup command, a wrong restore step, an unsafe upgrade instruction. Those are fixed as soon as they are confirmed, not on the next review pass.
How to report something#
Email editor@techdigest.site with the page address and what is wrong.
The single most useful thing you can include is a link to the primary source that contradicts us: the project's documentation, its LICENSE file, its release notes, its sample configuration. That turns a report into a fix in one step.
We also want to hear about:
- A tool in the index that has been archived, renamed, relicensed or forked.
- A command or configuration snippet on this site that does not work as written.
- A number in the published dataset that your own measurement contradicts.
- A recommendation that turned out badly for you, and what happened.
The log#
This site published on 7 September 2026. There are no logged corrections yet.
That is a statement about the site's age, not its accuracy. Any reference work of this size contains errors at launch, and the useful ones tend to surface when somebody tries to follow an instruction on real hardware and it does not work. When those arrive, they will be listed here with the date, the page, what was wrong and what it should have said.
Entries will use this format:
| Date | Page | What was wrong | What it should have said |
|---|
A note on the known soft spots, since it is more useful to name them than to wait:
- Memory figures are the least certain numbers on the site. They describe small single-household installs and are labelled as observations rather than benchmarks. If yours differs materially on comparable hardware, tell us.
- Version-specific facts go stale fastest, particularly current major versions and anything that recently moved behind a paid edition.
- Derived backup shapes come from the declared datastore, not from the project. The derivation is mechanical and documented, and it will occasionally be wrong for a project that does something unusual with its storage.
- First-release years for older projects are sometimes the earliest date we could source rather than the true first release, and the profile says so where that is the case.
Questions#
What counts as a substantive correction?
Anything that could have led a reader to a worse decision. A wrong licence, a wrong version, a wrong memory figure, a wrong claim about what a project supports, a wrong backup instruction, a broken command, or a verdict based on a fact that turned out to be false. Those get a dated entry on this page describing what was wrong and what it should have said.
What gets fixed without a log entry?
Typos, grammar, broken links, formatting, and clarifications that do not change the meaning. Logging those would bury the corrections that matter under noise, which defeats the purpose of having a log.
What if you change a recommendation?
That is not a correction, it is an update, and it is handled differently. When a verdict reverses because the software changed, the page says what changed and why, and its review date moves. When a verdict reverses because we were wrong, that is a correction and it is logged here as one. The distinction matters and we will not blur it to look more consistent than we are.
I maintain a project you cover and the page is wrong.
Send the primary source. Maintainers are usually the best available source for facts about their own project, and a link to documentation, a release note or a LICENSE file gets a factual error fixed quickly. A disagreement with a verdict is different: we will read the argument and reply, and we will change the page if the argument is good, but a verdict is not corrected simply because the subject dislikes it.
How quickly are errors fixed?
Anything that could cause data loss, a broken command, an unsafe backup instruction, a wrong restore step, is treated as urgent and fixed as soon as it is confirmed. Everything else is fixed in the normal course of maintaining the page. The corrections log records when the fix was made, not when the report arrived.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.