Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

>And, I've been working in the Linux world for a couple

>decades...where docs are copious but wrong about 50% of the

>time.

Nice summary of the status of Linux documentation. Not sure if it's really 50% wrong, especially the man pages make an impression of over-corrected but the usefulness depends on the tool and is completely random. But yeah, online documentation, classical tutorials are usually useless. When I see a tutorial, I close the tab. They just lead to dirty installations. If a tool needs a documentation, there might be an alternative that needs none. ;) But seriously, a lot of stuff on Github is obvious to use.

Not sure about the macOS. Having changed from Linux to macOS as my main (laptop) OS, I first noticed the unusual BSD tools. So I installed GNU tools on my first year OS X. Now I just use the BSD tools, some I even prefer over the GNU versions. But I guess the stuff that has been developed by Apple has no docs at all..



> But yeah, online documentation, classical tutorials are usually useless.

How long ago was this? Checkout the arch linux wiki. It's a pretty great resource for all things GNU/linux.


The Arch wiki is great for dealing with common problems in popular software. Other stuff tends to be about as outdated and incomplete as the average "how to" blog post. It's a good resource to have, but it's not the same thing as having well-documented software.


I would argue that when you're talking about free software, having documentation for common problems in popular software is the only reasonable expectation. Also that many/most of the most popular Linux tools have extensive documentation of their own.


Yes, setting up Linux to book as an EFI stub is a common problem. /s

I used Arch wiki to finally get it figured out, iirc.


I wonder how much this has to do with the code, and coder, churns in the Linux ecosystem.

Seems to me that there is a new weekend plumbing project popping up and being replaced almost monthly, if not even more often.

And it if gets an toehold in the ecosystem, the initial developer will quickly move on as he runs out of features to graft on and thus lose interest.

Then whoever takes over invariably decides the codebase in shit, and start over from scratch. And the cycle repeats.


Well, that might be true of some random special-interest packages; but for base system components like the kernel (linux) and the init system (systemd), you see the opposite of that description. The maintainers of core GNU/Linux infrastructure are, for the most part, permanent and devoted.


Watch systemd get passed off soon enough.

Never mind that calling it a init is a mislabeling at best...


  # man pdftohtml
This manual page documents briefly the pdftohtml command. This manual page was written for the Debian GNU/Linux distribution because the original program does not have a manual page.


That is outdated though, at least my current release version of poppler (0.57.0) has a manpage for pdftohtml which says at the end "This manual page was written by Søren Boll Overgaard <boll@debian.org>, for the Debian GNU/Linux system (but may be used by others).". According to the current poppler PKGBUILD in Extra[0], there are no patches applied.

Edit: Actually, poppler has had the pdftohtml manpage upstream since version 0.5.0, which was released 2006-01-11. The last release of poppler without a pdftohtml manpage was 0.4.0, released on 2005-08-07. How on earth are you running a twelve year old version of poppler? Or does Debian/Ubuntu still overwrite the upstream version of that manpage?

[0]: https://git.archlinux.org/svntogit/packages.git/tree/trunk/P...


Maybe Debian forgot to remove their patch when the manpage was upstreamed?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: