Reading manuals and wikis might sound tedious, but it's something I like about Linux. It might sound strange, but the way Linux and Unix docs are designed, it's much less of a chore than with other software.

Linux Documentation Is Actually Informative

The best thing that Linux documentation has is that you can read it and have some idea of what you're doing. The documentation for most commercial programs are aimed at ordinary users, while Linux docs tend to assume a more technical audience, such as the Arch Wiki. This means that a lot of the help files or knowledge base articles tend to skimp on detail.

Linux documentation tends to actually inform you about a program, what it does, and how you might fix things if they go wrong. I think this reflects the different audiences of Linux vs. other operating systems. The vast majority of Linux users tend to be technical, or at least people wanting to become more technical.

Since the people reading the docs will tend to lean more on the technical side, plus the authors wouldn't risk divulging trade secrets, they can explain how the software actually works in their code. This means that your time spent reading manuals, when you have to, will be well spent.

Documentation Is Refreshingly Honest

I find that there's a lot of "happy talk" in the documentation for proprietary and web-based software, at least when I can get it in the first place. They seem to deny that there's any possible problem with their software at all. Any acknowledgment of a problem is likely only to come from a customer service support ticket. The answer I tend to get from these people is usually as informative as their documentation. That is, not very much.

By contrast, Linux docs will let you know if something is broken. There's usually some message at the top of an official wiki page or documentation page. This might seem frustrating if you're not used to it, but all software has bugs. Open-source developers don't have a reason to hide them.

This self-criticism even extends to the documentation itself. As related by the 1989 book Life With Unix by Don Libes and Sandy Ressler, one bugs section in a BSD utility read, "This manual page is confusing." On the next version, this message was updated to "This manual page is still confusing."

Docs Are Often Written By Developers

Another key difference of Linux documentation from proprietary software is who writes the documentation. For most proprietary programs, the manuals are written by technical writers who are removed from the development process and may not be trained on software development.

Linux documentation, by contrast, tends to be written by the developers themselves. This is a tradition that goes back to the original Unix manual pages. This explains a lot about their dense, terse style that's become infamous in the Linux world. They still offer some of the best traits of Linux documentation: actually useful information that you can skim or use the search function in your pager to find, then get on with what you want to do. The "Bugs" section will also list the program's faults, where other programs will try to downplay any problems with their software.

The ultimate form of documentation might be the source code, if you happen to know the programming language being used.

Linux Documentation Style Seems Less Formal Than With Other Systems

One thing I like about reading Linux documentation is that the style tends to be a lot less formal than with other software. Even in the manual pages, there's a relaxed style where the developers are telling you what you need to know. In longer-form documentation like books or Wiki pages, they also tend to write in a conversational style.

Going on what they've written on the web and in O'Reilly books, a lot of them seem surprisingly good at it.

Thomas Scoville, in his essay "The Elements of Style: UNIX As Literature," posits that Unix developers seem more comfortable with words than users of other systems:

The common thread was wordsmithing; a suspiciously high proportion of my UNIX colleagues had already developed, in some prior career, a comfort and fluency with text and printed words. They were adept readers and writers, and UNIX played handily to those strengths. UNIX was, in some sense, literature to them. Suddenly the overrepresentation of polyglots, liberal-arts types, and voracious readers in the UNIX community didn't seem so mysterious, and pointed the way to a deeper issue: in a world increasingly dominated by image culture (TV, movies, .jpg files), UNIX remains rooted in the culture of the word.

As a "liberal-arts type" who also enjoys reading, I guess I shouldn't be surprised that I gravitated toward Linux and other Unix-like systems, since so much of my thinking is text-oriented the way Linux is.

Old Books Are Still Useful

Speaking of literature, a lot of old Unix and Linux books are still useful, despite their age. As my colleague Corbin Davenport pointed out lately, a vintage book on MS-DOS or Windows would be more of a novelty than something useful because of how much the systems have changed since the book was written.

By contrast, I have books in my personal collection that date back to the 1980s. While some of the utilities and environments have changed, most of the books are still useful for learning about Unix-like systems today. When I attended California State University, East Bay in the 2000s, the computer science section of the library was well-stocked with books on Unix. They probably never felt the need to cull this section for the same reason: a lot of the books were still useful even as some volumes dated back to the 1980s and earlier. They even had the first edition of The C Programming Language by Dennis Ritche and Brian Kernighan from 1978.

Manuals Are Actually Fun to Read

A consequence of the traits of Linux documentation, such as containing actual information, being written by the developers, being honest about the software's flaws, a less formal style, and the continuing usefulness of documentation, means that reading it is actually a pleasurable experience.

When I read Linux and Unix documentation, it feels like having a one-on-one conversation with the developer. Even in historical documentation, I'm learning something about the history of computing by encountering primary sources. I can read about how the software was or is being used and what kinds of problems it was meant to solve. I'm a fan of computer history, and it can be fun to go back in time, even for a while.

Linux Documentation Seems Unlikely to Disappear

When a proprietary program releases a new version, the older documentation tends to conveniently disappear, or at least when they bother to create documentation at all. If you need to refer to docs from an earlier version, you might be able to trawl through the Wayback Machine if you're lucky.

Linux and other open-source programs will usually keep documentation referring to earlier versions up. A good example of this would be Python documentation, which lets you select which version you want the docs to refer to from a drop-down menu. This is helpful as the Python versions supplied with many Linux versions tend to be behind the latest Python release.

Online or on paper, Linux documentation will likely be around for a long time to examine. This is one reason that I'll keep coming back to it in some form. I can rely on the documentation to be there when I need it.

---

One reason I like to explore Linux is that it's easy to get information on the system in text form. There will be new things to learn and new manuals and books to read to keep me busy for years.