This is often presented as one of the strengths of OpenBSD. I find it hard to believe that Linux man pages are so far behind (why would they not be copied from BSD?), but do of course not claim that it would be impossible.
Could someone please point to an example, so that the difference in quality becomes apparent?
The Linux one doesn't have an example anywhere of how to assign an IP address to an interface. Which is probably the most basic thing that you would be looking for.
which says "This program is obsolete! For replacement check ip addr and ip link" and references ip(8) in the See Also section. Neither page refers to ip-address. In fact that entry doesn't exist on die.net which seems to be what Google considers to be the authoritative source for Linux man pages.
I know these are dist-specific issues, but it seems far easier on linux dists to end up with an installed program (from rmp/debs) and still don't have the manpages, OR, getting a dud manpage that tells you to run "info gnufrotzomatic" and then you run that and since there were no info pages, info will very helpfully tell you to run itself again, since it shows a manpage if the info page is missing.
Semi-recent Centos7:
$ which find
/usr/bin/find
$ rpm -q --whatprovides '/usr/bin/find'
findutils-4.5.11-6.el7.x86_64
$ man find
No manual entry for find
$ more /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
So it claims to have the findutils rpm installed, which comes with manpages (especially since there is no find-man rpm) but I didn't get them for reasons. You just don't get that kind of experience on BSDs unless you very deliberately unmark manpages for installations. (which could be some kind of usecase, sure)
That's very strange. Probably centos is stripping "docfiles" from the installation (maybe a "container-optimized" install?). You can see which files are marked as documentation with "rpm -qd findutils". On my rhel 7, the man page is packaged along with findutils and I do see it.
One thing that annoys me is excess verbosity (that doesn't make the manual any more readable or easier to skim through). Man page for find(1) is a typical example.
I usually read man pages on OpenBSD, even when I'm working on Linux. I also often link people on IRC OpenBSD man pages when they're struggling with their tools (or their manuals) on Linux. The reception is generally positive.
Yeah, the difference here is very stark. I do sometimes wish that info had won as I always found it more accessible (compared to Linux man pages at least), but I suppose the vast majority of people just google now and almost all of these things are redundant.
Info is even worse IMHO. Navigating a hierarchy makes it harder to skim and search through, as well as easier to get lost. And when you have such hierarchy, manual writers can use that as an excuse to write even longer (sigh) manuals.
To me, much like code and math, the art of writing good documentation is all about finding a way to make it short and simple (but still correct and complete).
You can search a whole info file just as quickly as a man page, and using the index you can jump to the canonical docs for any argument or command in one go (ever spent time trying to find the hyphen-character section of a man page but struggled because it's referenced in 10 places?). I'll admit that whenever in man or info, I will generally go straight to the examples section because that's just how my brain works, but at that point I appreciate that info files aren't stingy with detail.
> You can search a whole info file just as quickly as a man page
It's possible that I just don't know how to use info. I always end up in the wrong place. That does not happen with man.
> and using the index you can jump to the canonical docs for any argument or command in one go
How?
> (ever spent time trying to find the hyphen-character section of a man page but struggled because it's referenced in 10 places?)
No, because the options are indented and inserting a few spaces before the hyphen in search string eliminates virtually all in-text references. Conventionally, the options are alpha-sorted too. In info pages, I end up wondering which section the option I want might be covered in.
Info is great for people who live and breathe Emacs, and terrible for non-Emacs users who are just trying to figure out how to get something done. If it's been a while since you last used it, you probably have to refresh yourself on the navigation commands, and the really useful features (the index[1] and incremental search[2]) are buried in different sub-nodes of the Info info manual.
As sibling commenters have mentioned, the Info tooling and format encourages people to split up their content into a bunch of nodes. In my experience, ~80% of Info manuals would be better if they were just concatenated into a single node, which the user could quickly Ctrl-F through with the tool of their choice.
You can use arrow keys and enter to navigate if you want, or tab like in every other hypertext system in the world. The search key is exactly the same as man, as well as supporting the same ones as readline, and they work across the whole file. I mean, it's 2019, it's a lost argument, but it'd be a shame to think it was lost on this basis.
Fwiw I used Emacs as my go-to editor & IRC client for a few years but I just could not bring myself to like info much at all. The format feels more suitable for something that wants to be a book. I don't want manuals to read like books.
Info is kind of cool but as others have stated requires learning yet another command line user interface. It's nice to hear that in recent years it's been made more user friendly by respecting arrow keys, etc but IMHO nothing can touch man foo | col -b > /tmp/foo.1 && vi /tmp/foo.1 for simplicity. It's not a vi vs emacs thing as much as I just want to get to the data and get the tool out of my way kind of thing.
Particularly when taking a certain vendor's certification tests, it was the work of seconds to write a man page example to disk and turn that into a script.
For GNU tools such as find (part of GNU Findutils), the official documentation is almost always not the man pages (which are therefore not as good as they could be), but the Info documentation. In this case:
For a different take, consider audio APIs. I've yet to find a man page that tells me how to use ALSA. There's a clutterfuck of doxygen docs if you want to get lost.. https://www.alsa-project.org/alsa-doc/alsa-lib/
Or you can buy a nice little library from OpenBSD where the PCM part is sufficiently described in one short man page: http://man.openbsd.org/sio_open.3
(With enough detail so that you can use it to write e.g. a latency-aware rhythm game that manages to keep audio and video in sync...)
I love sndio. I was able to write a little synthesizer for it using nothing more than the man pages. It's weird to think that I'm using OpenBSD rather than macOS for music-making, but the latter is just too complex and unpleasant to work with.
GNU long ago decided man pages were bad and quit writing good ones, preferring to use their info system instead. Debian has been trying to get good man pages with some success. BSD never agreed with GNU on this and so they tended to write good documentation in man pages.
