Is Linux Documentation Lacking?

eldavojohn writes "A number of blog posts are surfacing that are calling out the helpful open source community on their documentation. No, not the documentation for the highly skilled technical people, but the documentation from beginner to apprentice. A two-part series by Carla Schroeder lists bad documentation as 'Linux Bug #1' and advises users to use Google as the documentation. We've discussed before some of open source's documentation being out of date. Is it really as bad as these blogs paint it? Has it come down to using Google before a man page?"

Comments

Of course it is.

[Mongoose Disciple]

But on the flipside, I tend to use Google as the documentation for Windows/MacOS and most assorted non-free software that runs on them, too.

Re:Of course it is.

[ls671]

> Of course it is.

Agreed, first tip for the "beginner to apprentice":

Learning to use the "man" command is important, remember that you sometime have to add a number parameter to get the documentation that you want to get ;-)

Re:Of course it is.

[Penguinisto]

True - though something is lacking in TFA: there is a diff between hitting the docs for learning, and hitting them for troubleshooting.

The man pages are more for learning (you can troubleshoot with them too, but diagnostic info in them are going to be lacking, just like trying to rely on the Windows Help files to fix a busted Exchange connector). Odds are, a beginner/apprentice won't know what to do with 'em for fixing a problem unless he/she is a royal badass at general computing/programming practices.

For troubleshooting, you're gonna have to hit Google - you have better odds there that someone else had the same problem and posted it (and its solution). There was once a time when you could write up docs for troubleshooting and diagnostics, covering up to 80% or more of what most folks run up against.

It still boils down to upping your skills on the OS and on general practices, though.

Re:Of course it is.

[Goaway]

Ok, I want to burn a CD, what "man command" should I use?

Re:Of course it is.

[prgrmr]

man microwave

Re:Of course it is.

[d3m0nCr4t]

Try "apropos"!

Re:Of course it is.

[houghi]

You ask two differnt questions. The first is how to burn a CD. The second is what man command you could use. Using a man command will not burn the CD so has no relation to the first question.

I assume that the first question is more urgent.
http://www.google.com/search?hl=en&source=hp&q=man+linux+burn+cd&btnG=Google+Search&aq=f&oq=&aqi=

Or you start here: http://www.google.com/linux

Re:Of course it is.

[ls671]

man 1 cdrdao

Re:Of course it is.

[ls671]

> You've lost me already. I'm having to look up what "man" does.

try:
man man

Re:Of course it is.

[Anonymous Coward]

Well, what is he doing in the kitchen anyway? That is the job of the woman.

Re:Of course it is.

[eln]

man pages are written by techs for techs, and are intended more as a reference than as a how to. They're very useful for people who are already familiar with Linux and just need to know the syntax for particular commands, but are not particularly helpful for people just getting into Linux.

Most of the previous attempts to create beginner documentation for Linux and other Open Source projects have suffered from the same basic problems:

1.) Nobody likes writing documentations. Technical people in particular hate writing documentation. It's tedious, boring, and generally unrewarding work. So, documentation tends to be sparse at best.
2.) The people who do bite the bullet and decide to write some documentation misunderstand their audience. They write at their own level, and make it easy for themselves, and perhaps their other technically-minded peers, to understand. Documentation is either very sparse, assuming a level of background knowledge that doesn't exist among beginners, or extremely precise, dense, and difficult to understand.
3.) Nobody reads the documentation anyway. People hate reading documentation almost as much as they hate writing it. When's the last time you bought something and actually read the manual that came with it? Reading documentation is boring and tedious, especially when most of it is so poorly written. People would rather tinker, then ask someone else for help when they break something, rather than slogging through documentation.

The basic result of this is we have two alternating types of stories on a semi-annual basis on Slashdot: Stories about someone trying to start a new Linux documentation effort, and stories about how much Linux documentation sucks. Meanwhile, the state of Linux documentation stays essentially the same: a mix of outdated and difficult to follow documents interspersed with large gaps where no documentation exists at all.

Re:Of course it is.

[ais523]

$ man -k burn cd
brasero (1) - Simple and easy to use CD/DVD burning application for ...
k3b (1) - KDE CD burning program

There were more answers than those two, but either of the first two looks a sensible choice for burning CDs. (The results quickly drop off in quality, though; the fourth was the Perl module Language::INTERCAL::Charset::EBCDIC, which I strongly hope can't burn CDs...)

Re:Of course it is.

[gr8_phk]

I just put in a blank CD. Then a folder appears on the desktop with a button to burn the CD. I drag the file I want into there and hit that button. I'm not sure what this MAN thing is everyone keeps talking about.

Re:Of course it is.

[ciderVisor]

Welcome to Slashdot !

Re:Of course it is.

[Anonymous Coward]

Worse, it's responses like the GP's that compounds the problem.

Noob: I don't know how to use Linux! Won't someone help me?
BOFH: *grumble*grumble* Look, here's the "man" command, dumbass. It obviously means "MANual". Get it? Figured you looked too stupid to figure out how to use Linux...
Noob: Um... when I type that, all I get is "What manual page do you want?" How do-
BOFH: Why you rotten little... just how stupid ARE you? Were you born and raised with Windows or something? You type in the command, kernel function, or standard library call in after "man", just like we've done for the past TWENTY FUCKING YEARS OF UNIX. Hello? Have you been paying ANY attention at all, you worthless little Windows runt? If I hear you badmouthing one of the most hallowed and revered of Unix commands again, I'll-
Noob: So... er... what man command do I use to learn how to burn a CD?
BOFH: (eyes starting to turn red, veins now starting to pop out of head, teeth clenching almost to the point of shattering them by the pressure) You... were... asking... about... MANPAGES... YOU... STUPID... ASSHOLE! What the fuck is WRONG with you? You don't use man to burn a CD! Where the hell were you raised? In Redmond? I bet you don't even know what revision of the CD filesystem to use to optimize storage and retain symlinks! As everyone ALREADY KNOWS, ASSHAT, you have to build up an ISO image from on-filesystem objects using the proper options for your image of choice, make sure the appropriate kernel options are compiled in (or, of course, make and install the proper modules via modprobe or insmod, or via the autoloading mechanism which ONLY the uneducated scum use because they don't know the glories of "pure" Linux from ten or so years ago, the stupid "modern" bastards), THEN you can "burn a CD", as you so quaintly put it! WHAT PART OF THIS IS NOT OBVIOUS TO YOU?!?
Noob: I...
BOFH: (starting to shake from pure rage) You're clearly too much of a moron to truly enjoy Linux! GET OUT! GET OUT OF MY SIGHT, WINDOWS USER! OUT! AND TAKE YOUR GODDAMNED "PRETTY" GUI WITH YOU!
Noob: Hey, guess what? In the time it took you to rant about all that, I got my CD burned under Windows and didn't have a raving insular lunatic insult me. And I was able to do it without having to study the history of an operating system. Sounds like I'm using Windows from now on.
BOFH: *sniff* Why don't people like Linux? We're so superior!

Re:Of course it is.

[lattyware]

Protip: Find the software you want, then turn to your package manager. If you have to compile stuff by hand and don't want to, you are not running a suitible distro.

Re:Of course it is.

[gobbo]

The man pages are more for learning (you can troubleshoot with them too, but diagnostic info in them are going to be lacking, just like trying to rely on the Windows Help files to fix a busted Exchange connector). Odds are, a beginner/apprentice won't know what to do with 'em for fixing a problem unless he/she is a royal badass at general computing/programming practices.

The fascinating thing about man pages, for me, was how utterly obscure some of them are to beginners. Most of them assume an intermediate understanding of unixy concepts, and don't bother to explain the context of the command -- i.e. when and why you would want to use it in the first place!

The whole experience of learning to use the command line reeked of disdain for those who hadn't been to school (or endless sexless nights in the basement) to study the stuff, and myopia about the fact that someone may be coming at all this from a different angle.

Which I guess is just nerdly, right? what did I expect.

Re:Of course it is.

[Jason Earl]

Here's the thing. If you find yourself wanting to read the man pages, and you are confused by them. Go and purchase a copy of "Running Linux." Any edition will do. That's how most of us that *like* Linux learned to use it.

For most users, however, the man pages are just a waste of time. The have no desire to learn to use the various command line flags for "tar," nor do they want to understand the vagaries of cat.

For that matter, they don't want to learn how to create a partition for /home (which is the example used in the original article). The whole idea that the operating system should make this sort of activity accessible to newbies is simply ridiculous. By this standard Mac OSX is *more* difficult to use than Linux, and Windows is completely unusable.

Ubuntu's auto-partitioner gets this absolutely right (while still giving people that want a separate home partition the tools they need).

Re:Of course it is.

[mweather]

man apt-cache. That'll tell you how to search the repo for a CD burning program.

Re:Of course it is.

[Yvan256]

woman microwave

Re:Of course it is.

[machine321]

Can't emacs do it?

Re:Of course it is.

[SanityInAnarchy]

Well, back in the day, it would've been 'man cdrecord', which kind of makes sense. I honestly don't remember how I learned about cdrecord, or how I now know it's been renamed to wodim.

In all honesty, I suspect us Linux users have some sort of telepathic network...

However, trying some of the other questions gives some useful responses:

apropos burn

gives me k3b. Knowing that it's a KDE program, I might then look in the menus to see if it's a GUI program. It is, so I'm done.

houghi points the way to another possible answer. Personally, I'd Google for linux burn cd commandline -- the tutorials returned are out of date, but still work. 'man cdrecord' doesn't give me anything, but 'which cdrecord' tells me it exists, and 'ls -lh `which cdrecord`' tells me it's wodim. So, 'man wodim' gives me the most relevant, though least userfriendly, documentation.

Note, none of this is at the expense of the fact that when I pop in a blank CD, I do get a GUI popup that lets me point-and-click to burn a CD. Since I'm on KDE, this probably leads to k3b, though I haven't used it in awhile.

Re:Of course it is.

[tjstork]

And how the hell is some user sitting alone in his room soupposed to know this? Perhaps if there was a "readmefirst" file on the desktop to give new users this info, but there isn't.

The larger point is that the user cannot do this at all with Windows. How do you mind out what an exe in your process list does there? You Google it!

In my mind, I would expect documentation for Windows to be far superior to that for Linux, because Microsoft can pay technical writers, as can most commercial publishers. But, they don't. Instead, they ship the minimum docs they can and then sell books through MS Press. What's really the difference between that and buying a book through O'Reilly? Not much.

Bottom line is, the whole "Linux has no documentation" argument is a strawman, and I know what strawmen are, because, I myself have made enough of them to feed a thousand cows, for sure. Linux has rough documentation, but so does -everything- else.

Re:Of course it is.

[gobbo]

oh, don't get me started.... ALL OS's suck, they just incite different kinds of violent feelings!

MS has always had a central figurehead to vent spleen upon. Linux just gives one a feeling of antipathy towards nerd-dom... unless it's the urge to revenge that comes from a particularly bad man page.

Re:Of course it is.

[ClosedSource]

Believe it or not Wikipedia isn't the ultimate source of information.

Yes it is terrible!

[InsaneProcessor]

This is one of the key reasons Linux is not mainstream for users (not us geeks but real users). The user does not want to learn how to do anything more on his computer than get is work done or enjoy the entertainment. User level documentation simple does not exist.

Re:Yes it is terrible!

[Americium]

Exactly. Creating documentation for mainstream users is completely pointless. I personally think Ubuntuforums has great docs. I can just copy paste what they tell me, and voila, i have fakeraid setup, or whatever else is hard to install.

Re:Yes it is terrible!

[FTWinston]

I had several issues and tasks that I wished to perform on an ubuntu install on my now-deceased old machine.

Some were easy to find, but some involved wading through page after page of contradictory forum advice, or advice that seemed to completely disable my network adaptor. Things that I had expected to be possible through a GUI required pasting invalid forum syntax into system-critical files, sometimes with unpleasant results.

I was using linux only because I had to (producing dedicated server binaries for a source mod server), and my task was pretty non-trivial for a first-time user. I really did try to enjoy the experience... but I found it largely cumbersome, and haven't been back. Which is a shame, tbh, cos I'd like to like it.

The main problem, for me, was that it felt like for every task I wanted to perform, I had to find an expert person on a forum who already knew precisely how to achieve said task. There was usually little possibility of the self-discovery that is generally possible with an intuitive GUI, in the areas where a GUI was lacking.

With hindsight, it would have been more efficient to have just paid an expert to produce the binary for me. Or better yet, to set up my environment the way I wanted it.

Re:Yes it is terrible!

[mark-t]

Nope. Most users don't bother to even *READ* documentation, so the lack of it would not be a factor.

Re:Yes it is terrible!

[jellomizer]

You make it sound like a bad thing...

Yes people don't want to tweak config files to give it an extra 10% speed improvement. Or fuss around searching for "Pure" GNU drivers that work. They just want a system that boots up, allows them to go to their apps get their work done. When they are done with work they may want some entertainment out of the device.

Do you feel you have to know how every component in your car works.
All the technology and people who go is to flushing your toilet making sure that nasty stuff leaving your body doesn't come back to haunt you again.
Do you need to know what materials your desk is made out of, how they cut the wood etc...

There is a lot of stuff going on outside of our areas of interests. We use a lot of such products and services but don't even think about all the details that goes on, for the most part we don't care, even if it vitally important to us, but as long as it works we are happy.

Re:Yes it is terrible!

[smooth wombat]

If someone makes a good piece of software, it'd be great if someone else came along to document it, and everybody wins.

Here's an idea: how about the person who did the actual work do the documentation? That way, since they know all the ins and outs, someone else doesn't have to pester them to find out how to do something and document it.

Yeah, yeah. That would be too easy and make sense. Let someone else take care of the problem because I'm too lazy.

There is no reason in this day and age that the person/people creating these apps can't provide documentation at the same time. As others have already pointed out, until there is good documentation and yes, even a simple walk-through if it's warranted, it will NEVER be the year of Linux on the desktop.

Re:Yes it is terrible!

[Moryath]

My experiences (plural) with Ubuntu, MythTV, and MythBuntu (which was supposed to "streamline" the whole process) were similar in trying to set up a DVR.

Consumer-level HDTV card (ATi HDTV Wonder, PCI). ATi video board. ATi Remote Wonder II for my remote control.

Every time a new version of Ubuntu/MythTV/Mythbuntu would come out, I'd try to load it up and get it to work correctly. Multiple people insisting it would work fine, others insisting "no support" for the stuff. Back and forth. Most of the problem stems from the fact that in every stinking version, something gets changed, then it takes them a year or more to document the crap.

In the Ubuntu Hardy Heron attempt, every bit of documentation was either Gutsy Gibbon or Feisty Fawn. No help there. Tried again at Jaunty Jackalope's release WITH Hardy Heron, and still 90% of the damn documentation hadn't been updated. I'm stuck chasing around tidbits and forum posts with "well here's how you do it, LINK" only to find out that the link is either (A) for a version I'm not running, (B) assumes information I don't have, or (C) no longer available.

Tracking down how to set up a remote control reliably with Lirc is a pain beyond torture as well. I spend 99% of my time on Windows (hey, I have better things to do with my time than fight a damn OS. Windows does what I need it to do and runs what I want to run.) This is the "tutorial" for setting my remote control up under MythTV. And let me tell you right now, this thing is a shambles.

Linux people don't write clear-cut instructions for anything. This is true and I agree, it is Linux Bug #1.

Re:Yes it is terrible!

[clone53421]

Until Grandma or Grandpa can blindly install something without understanding exactly what they’re doing, Linux on the desktop will not be practical.

“Install this” is all the understanding your average user wants to have of the actual installation process.

Re:Yes it is terrible!

[misexistentialist]

Sounds like Windows. Every time I need to set up a system it requires searching forums for registry hacks, third-party utilities, and info on "advanced" settings hidden by the gui to make even basic changes. Windows just has the advantage of annoying and frustrating a larger user-base who take to the internet to complain and find solutions.

Re:Yes it is terrible!

[Tubal-Cain]

On Windows the question the users ask isn't "How can I do this?" but rather "What do I have to buy that will do this?"

Re:Yes it is terrible!

[Matheus]

I completely disagree. The person who created the application needs to be able to somehow convey the technical details and functionality of said application: True.. BUT everybody has their talents and I've found time and time again that writing great documentation that is clear, consistent, easy to use and understandable by a wide variety of user is very much a talent and usually one the developer doesn't posses. Even if the developer happens to have this talent, they rarely have the proper perspective on the product to document it for a third-party. The best documentation creator is someone with the talents to produce the document and direct access to the developer for the nitty-gritty specifics. They can then document the use of the program from a closer perspective to a outside new user because they at the start are that person BUT they have the access to the developer to fill out the documentation with the details that aren't readily apparent using the app.

This could be a great business model:
Customer: The people, companies, open source communities developing products / solutions.
Business: A group of talented documentors who work with these groups to create quality documentation.

Oh wait.. isn't that what O'Reilly is?

Documentation is very lacking

[genkael]

As a linux user since 1995, I have found the documentation to be little more than it was around 2000. It's easier to do a google search than try to find an answer in a man page. Not only that, the man page rarely has useful examples, one of the biggest problems.

Re:Documentation is very lacking

[Anonymous Coward]

Compare the Linux documentation to the FreeBSD Handbook and you will see that Linux has no documentation to speak of. Perhaps that's the price you pay for having no central management, I don't know.

Oh, and can we please get rid of that awful Gnu Info crap?

Re:Documentation is very lacking

[CasaDelGato]

The whole Linux Mindset to documentation can be summed up in the phrase "use the man page". Yeah, right. Man pages are only semi-useful if you ALREADY KNOW WHAT COMMAND YOU NEED. Trying to FIND the command to do something is nearly impossible. Almost as bad as trying to find out how to configure something. (just edit the twiddly.da config file in the googly.plex directory, note that the syntax is completely different from every other config file on the system.)

Re:Documentation is very lacking

[Bluesman]

>apropos [thing I want]

But Linux distros could learn a lesson from FreeBSD in this regard. The FreeBSD docs are nothing short of excellent, and standard for the entire system.

Re:Documentation is very lacking

[nomadic]

Well I've been using Linux since 1979, and the documentation has never been that great. I remember asking Linus and some of the other developers about it when I ran into them at Studio 54, but they were too stoned to answer. Man, it was crazy back then, you'd get high and write a program and you wouldn't even care about the documentation. You'd just copy over someone else's man pages, or paste in Beegees lyrics, or whatever you're drug-addled brain came up with at the time.

Re:Documentation is very lacking

[godrik]

Well, the man pages are only supposed to give the formal parameters of the command. The actual use of the command in a given context are given by HOW TOs.

Re:Documentation is very lacking

[Goaway]

> apropos burn a cd

drutil(1) - interact with CD/DVD burners
hdiutil(1) - manipulate disk images (attach, verify, burn, etc)
CONF_modules_free(3ssl), CONF_modules_finish(3ssl), CONF_modules_unload(3ssl) - OpenSSL configuration cleanup functions
CONF_modules_load_file(3ssl), CONF_modules_load(3ssl) - OpenSSL configuration functions
APR(3pm) - Perl Interface for Apache Portable Runtime (libapr and libaprutil Libraries)
APR::Base64(3pm) - Perl API for APR base64 encoding/decoding functionality
APR::Brigade(3pm) - Perl API for manipulating APR Bucket Brigades
APR::Bucket(3pm) - Perl API for manipulating APR Buckets
APR::BucketAlloc(3pm) - Perl API for Bucket Allocation
APR::BucketType(3pm) - Perl API for APR bucket types
APR::Const(3pm) - Perl Interface for APR Constants
APR::Date(3pm) - Perl API for APR date manipulating functions
APR::Error(3pm) - Perl API for APR/Apache/mod_perl exceptions
APR::Finfo(3pm) - Perl API for APR fileinfo structure
APR::IpSubnet(3pm) - Perl API for accessing APRs ip_subnet structures
APR::OS(3pm) - Perl API for Platform-specific APR API
APR::PerlIO(3pm) - -- Perl IO layer for APR
APR::Pool(3pm) - Perl API for APR pools
APR::SockAddr(3pm) - Perl API for APR socket address structure
APR::Socket(3pm) - Perl API for APR sockets
APR::Status(3pm) - Perl Interface to the APR_STATUS_IS_* macros
APR::String(3pm) - Perl API for manipulating APR UUIDs
APR::Table(3pm) - Perl API for manipulating APR opaque string-content tables
APR::ThreadMutex(3pm) - Perl API for APR thread mutexes
APR::ThreadRWLock(3pm) - Perl API for APR thread read/write locks
APR::URI(3pm) - Perl API for URI manipulations
APR::UUID(3pm) - Perl API for manipulating APR UUIDs
APR::Util(3pm) - Perl API for Various APR Utilities
ASN1_OBJECT_new(3ssl), ASN1_OBJECT_free(3ssl) - object allocation functions
ASN1_STRING_dup(3ssl), ASN1_STRING_cmp(3ssl), ASN1_STRING_set(3ssl), ASN1_STRING_length(3ssl), ASN1_STRING_length_set(3ssl), ASN1_STRING_type(3ssl), ASN1_STRING_data(3ssl) - ASN1_STRING utility functions
ASN1_STRING_new(3ssl), ASN1_STRING_type_new(3ssl), ASN1_STRING_free(3ssl) - ASN1_STRING allocation functions
ASN1_STRING_print_ex(3ssl), ASN1_STRING_print_ex_fp(3ssl) - ASN1_STRING output routines
ASN1_generate_nconf(3ssl), ASN1_generate_v3(3ssl) - ASN1 generation functions
Algorithm::Annotate(3pm) - represent a series of changes in annotate form
Algorithm::Diff(3pm) - Compute `intelligent' differences between two files / lists
Algorithm::DiffOld(3pm) - Compute `intelligent' differences between two files / lists but use the old (<=0.59) interface
Alien::wxWidgets(3pm) - building, finding and using wxWidgets binaries
Alien::wxWidgets::Utility(3pm) - INTERNAL: do not use
AnyDBM_File(3pm) - provide framework for multiple DBMs NDBM_File, DB_File, GDBM_File, SDBM_File, ODBM_File - various DBM implementations
Apache2::Access(3pm) - A Perl API for Apache request object: Access, Authentication and Authorization
Apache2::Build(3pm) -

Re:Documentation is very lacking

[BrentH]

I've been using Windows since 1954, and I've never needed a manual to open them!

Re:Documentation is very lacking

[raddan]

Seconded. Anyone whose ever used a BSD system can attest to the quality of the documentation. I think the reason for this is that BSD devs are often required to submit documentation with their patches. The more decentralized Linux development model tends to overlook this. It drives me nuts; fortunately, most of BSD userland and Linux userland are the same, so I can refer to BSD docs for Linux stuff. Don't try to use BSD docs for GNU make, though. Oh, and don't get me started on Info pages. WTF.

Oh, and Apple's documentation: HA! Sun writes some nice docs, though.

Re:Documentation is very lacking

[Vanders]

It's even worse if you do have GNU info installed and are naive to actually try to use it.

GNU info needs to just die. Preferably in a horrible, painful fashion, with lots of screaming and blood.

Re:Documentation is very lacking

[rochberg]

I call BS. Go to Google and try searching for "burn a cd" and "burn cd." The results are pretty similar because decent search engines do more than simple text parsing and regular expression matching. As long as the vast majority of people continue to use Google, Bing, Yahoo, etc., they will come to expect that the search tool is actually trying to be helpful.

As an academic researcher, I regularly copy and paste the title of a paper that I am looking for into Google. When I do that, I also find similar papers on the same topic because their titles share words with the original title. This is very helpful. If "basic search technique" required me to get rid of "a," "an," "the," etc., my job would be a whole lot more frustrating.

Re:Documentation is very lacking

[ThePhilips]

GNU info needs to just die

+1

The shell function makes "info" tad bit more usable to me:

info() { /usr/bin/info --subnodes --output=- "$@" | $PAGER; }

Re:Documentation is very lacking

[Rufty]

$ man ls
...
SEE ALSO The full documentation for ls is maintained as a Texinfo manual. If the info and ls programs are properly installed at your site, the command info coreutils ’ls invocation’ should give you access to the complete manual.

And now we're into a whole new world or "how the hell do I quit this???" Can info just die now, please?

Don't like man pages.

[theNetImp]

I find man pages to be poorly written, and difficult to understand most of the time. I tend to use google to find people who are discussing it in plain english...

Re:Don't like man pages.

[Anonymous Coward]

Perhaps that's because you have only seen Linux (or Gnu) manpages. Take a look at the (Free-)BSD manpages and you will be pleasantly surprised.

Re:Don't like man pages.

[daid303]

Manpages suck for the average programmer. You're above average (so I am) but lots of the people I work with struggle with manpages. They seriously lack examples.

And then there are the man pages that say "look in header file X for the rest", and of course the headerfiles don't contain comments. So you'll have to figure out on your own what "FBIOGET_VSCREENINFO" means. (The V stands for 'variable', which google could tell me)

Re:Don't like man pages.

[MpVpRb]

Man pages are great to remind you of the details, if you already know how something works.

Man pages are terrible for learning something new for the first time.

Re:Don't like man pages.

[dkf]

Manpages suck for the average programmer.

No. Most manpages suck, especially on Linux. Sorry, but it's true. BSD manpages are usually better because they've a legacy of being better (there's a history of them having had a good tech writer spruce them up sometime way back, and that's encouraged them to stay good) whereas too many Linux utils and syscalls are poorly documented (GNU utils because they think you should be using texinfo, Linux syscalls because there's a tendency to say RTFS).

They could be better. Making them better needs effort, and it needs someone other than the original developer to help (because the developer is usually too close to understand what needs to be documented, or at least that's how it is for me). I also advise not worrying about the format of the documentation; plain old text is hugely better than nothing...

And good luck with Google, too

[edraven]

As often as not, the only hits you get are posts in forums where someone is asking the exact same question you need answered... and getting no replies. Since 2005.

Re:And good luck with Google, too

[godrik]

And you are exposed to none compatible solutions. The number of doc out there that still use insmod/rmmod instead of modprobe is high. The number of solutions that tell to install software manually instead of using the one from your distro repository is high. Google is good to get a basic understanding of the concept and problem. Then read the manual (not only talking about man pages)

Re:And good luck with Google, too

[zwei2stein]

I can top that:

As often as not, the only hits you get are posts in forums where someone is asking the exact same question you need answered... and getting no replies. Since 2005. And that person is me.

Re:And good luck with Google, too

[Xadnem]

You forgot: if the 2005 post has replies they're insulting to the original poster or irrelevant to his question.

Re:And good luck with Google, too

[kimvette]

Standard responses to new user questions up to around 2005

"man $foo"/"RTFM" (nice reply. This is why it was SOOOO hard for Linux to gain ANY traction in the first 15 years it existed.)

"it's open source. Fix it yourself."

"it's open source. Document it yourself." (Um, if they don't know how the app works, they can't document it)

"Read the tutorials/howtos" (The tutorials/howtos might cover the very basics, but often don't even touch upon what the user is asking about. Even better is when the tutorial says "to be added later." Or, the howtos are written for sysadmin types by developers with asperger's syndrome, not written for typical users. They may a well have been written in hieroglyphics as far as end users are concerned)

Ubuntu Community Docs are pretty good

[mark0]

I have found the Ubuntu Community Documentation to be pretty good for cookbook procedures. Their forums pick up the slack for acute issues.

Yes.

[LWATCDR]

Writing documentation is hard work and is boring. It is also thankless.
The funny thing is that documentation for the most technical programs tends to be very good. PHP, Perl, Apache, Postgres, and MySql all do seem to have good documentation.
Gnome not so much. Many other apps also seem to lack good docs. X is just a disaster. It is documented but it is still a pain when things fail they are a huge mess to fix.

Re:Yes.

[eldavojohn]

Writing documentation is hard work and is boring. It is also thankless.

Amen. But, believe it or not there are people out there looking to assist open source by doing tech/doc writing for it. The comments in that thread have some really good resources if anyone out there is in total despair or is curious how they can help out open source documentation. I probably should have linked to that in the summary but my submissions have been way too link heavy lately.

Re:Yes.

[Vanderhoth]

If it wasn't well documented when it was being developed it falls on someone else to do it later. That someone has no real vested interest in documenting something they didn't write.

I'm a developer and have had to deal with several legacy applications that contractors had previously written. When I first started my job I was pretty much given one of these applications and told it needed some documentation updating. I feel extremely annoyed when I look back and realize that for pretty much the first year of my job I was writing developer, security and user doc's for someone else poorly coded system. The result is the documentation I wrote for the other systems is probably incomplete or doesn't make perfect sense in the grand scheme. It seems a little arrogant, but I no longer accept responsibility for applications written by other people, epically contractors that were hired to write an application, which should have taken one to two years to develop, in six months. If someone insist I take over a project I tell them I want to see to documentation and code first if it's good I'll accept, if it's bad I'll accept on the condition I get to redevelop the whole project because it takes less time then writing, rewriting or expanding existing documentation while fumbling through someone else hacked together code.

Sorry for the rant. I read this saying somewhere, "Document your code like the person who will maintain it after you is a psycho pathetic killer who knows where you live".

Yes

[DontBlameCanada]

In a word, yes, many/most linux docs suck.

Man is useful once you understand the basics of how a command works. However, if you're sufficiently green, decoding the language in many of the man pages is difficult. When executing certain system management tasks as root, a mistake can be catastrophic. Google will pull up the man page for you, but also the infinitely more educational blog and faq pages that decribe what a command does, when you use it and how to trouble shoot problems encountered with it.

The problem with Google, is the non-official blogs and faqs frequently reference older version of the command line tools bundled in the latest distros. Occasionally, the tool author radically alters the tools between releases rendering the non-official docs inaccurate... Then the neophyte/newbie hobbyist is up the creek with a paddle.

Google can be more specific

[Dr_Barnowl]

Getting the detail you want out of a man page is often harder than finding the relevant bits on Google. And of course, man pages don't help you at all if you don't know which command you want to be using ; and let's face it, for a given task, there might be three ways of doing it.

I'm still a relative Linux novice despite having used it for some time now, but I'm a programmer and prepared to slog through documentation and web pages to get things going.

Example - the prune argument of find. I'll give a limited-edition photon to the first person who figures out the way to use the prune argument to produce a list of files that _doesn't_ match a particular path pattern, solely limiting themselves to the man page, without using Google.

find . -path '*/not-these' -prune # This does basically the opposite of what you'd expect it to.

Yes, I know how to do it NOW. Well, Google remembers which page I found most relevant for the search terms that eventually found the right way.

Re:Documentation lacking?

[L4t3r4lu5]

Wireless Howto

Wireless Howto
Roberto Arcomano berto@fatamorgana.com
v1.6 - July 31, 2002

Well, No Shit

[bsDaemon]

That's because its really difficult to determine what's "Linux" when you're talking about Linux. What works on RHEL/CentOS won't necessarily work exactly the same on Fedora, and will probably be way different than on a Debian box.

Contrast this, however, to one of the BSDs, say FreeBSD, which I am the most familiar with. Let us take a look here: http://www.freebsd.org/docs.html. All of these documents ship with the OS, so if you don't have a network connection (for instance, you need the docs to help you set it up), then you have them there as well. The FreeBSD Handbook covers everything from installation to configuring BGP.

There is a separate Developer's Handbook (which even contains a primer on x86 asm), a Porter's Handbook, etc. The docs that ship with the OS include even The Design and Implementation of the 4.4BSD Operating System, which is somewhat dated at this time, but still a great help in theory.

Then, of course, there are the man pages that everyone always mentions, which are awesome, but don't really help make the point I'm putting forward. Of course, the fact that FreeBSD can ship such thorough documentation is because FreeBSD is FreeBSD anywhere, where "Linux" is not. So, perhaps the problem isn't with "Linux," but with certain distributions not taking documentation seriously enough for the various common tasks and interfaces.

What I'm really getting at is, I should not have to Google around for random blogs and wikis to find out how to do a common task that I may be getting to for the first time, hope that I can find an answer, and that the source can be trusted. Any of the distributions which have any sort of commercial or foundation backing at all, really should just bite the bullet and hire on a few technical writers to actually make proper documentation, and then keep it up-to-date. Hell, even Microsoft updates their online help files, and most tasks in Windows are straight forward enough that only 4th grades and 60 year olds need to ask about it.

Relying on GUI config tools, DHCP, and other magic to keep "newbies" from needing to actually learn anything is counter-productive and isn't going to help create new professionals. "RTFM" shouldn't be a put down or a dirty word, but TFM needs to actually contain TFInformation. Is that really so much to provide?

Re:Well, No Shit

[bsDaemon]

If you use a long-form BSD license (with the credit clause), then they can't take the all the credit -- they have to indicate that they borrowed your source as a starting point.

I don't do much coding, so I don't release a lot of code beyond some Perl or Shell stuff, but when I do, I prefer BSD licensing to GPL licensing. Maybe I just don't think my code is novel enough for anyone to want to hijack anyway.

Re:Well, No Shit

[value_added]

FreeBSD is indeed outstanding in the documentation area -- complete, thorough and consistent. And as an added bonus, most manpages are written to include examples and handholding (where applicable).

Linux, I'm afraid, suffers from, among other things, the man/info dilemma. Personally, I find info somewhere between retarded and useless, but to the extent anyone relies on using info as it was originally conceived, they'll discover soon enough that the info referenced in the manpage was never written.

As a workaround for the shoddy quality of Linux documentation, what I do is one of the following: (a) install the FreeBSD manpages into my home directory; (b) use a script to dump the on-line version into my terminal; or (c) simply write my own. Granted the FreeBSD manpages won't necessarily match up, but they're generally close enough to be adequate, and especially useful for unfamiliar concepts or commands.

As for writing one's own manpages, that does take a bit of knowledge, but it's far simpler than it appears. An alternative is to use Perl's immensely-readable and easy-to-learn POD format. Running 'perldoc /path/to/mypod' (or simply 'pod2man') gives you the same bold, overstriking and other formatting you'd typically expect from a manpage. Either way, writing your own seems to be increasingly necessary. Took me a while to document Firefox correctly, but I haven't had to waste any time since bouncing around dozens of Firefox sites to lookup the meaning of about:config settings. If you've got documentation, Google is *never* faster.

Manpages ideally should contain examples, but they shouldn't take the form of a tutorial. The web is littered with tutorials, so finding one is easy enough.

Re:It's better than Mac OS X documentation

[ThrowAwaySociety]

or help files for that matter. But I don't think this is really the problem. It's how often does the user feel compelled to consult the documentation or help files in their normal daily work that matters.

I'm guessing you're referring to the printed documentation only.

Apple's online knowledgebase is unsurpassed, since it covers both hardware and software, and since there are so few permutations of both that it's possible to actually have comprehensive documentation.

And the built-in, offline help system is pretty darned good for basic purposes. For other purposes, it searches the above mentioned online knowledgebase, so...yeah.

Documenting shitty software is futile

[gzipped_tar]

If a software solution is crappy enough, it is impossible to write document for it. If a program has to be *endured* rather than enjoyed, all its documentation can do is either reinforcing the shittiness experience by point out *how* and *why* it already sucks and un-amendable (if the doc is correct), or dumping more crap on top of that (if the doc is incorrect).

I'm looking at you, GNOME. I used to be a GNOME user but I gave up. The docs was barely useful for anything. I wanted to configure GDM and there's no explanation of those arcane XML shit and event hooks. The conf files were scattered here and there, and guess what, the infamous, incomprehensible gconf that actually brags about being modeled after MS registry! I finally got the idea that the devs simply gave up the idea of explaining their un-explainable clusterfuck already. I don't use a DE anymore.

Mod me however you want. I'm not a karma sink and I don't save it for an afterlife.

It's called engineering

[thethibs]

The resolution to the documentation problem is simple. I use it on my projects and when I managed programmers, I made them do it. Unfortunately, it needs discipline--the difference between programming and engineering--which is in short supply in the FOSS community.

The resolution is that you write the relevant section of the user manual first, have the client review it for clarity and sanity, and then make the software do exactly what the manual says.

Pause to recover composure

What could I be thinking?!

Not just beginner to apprentice.

[aussersterne]

I've been a Linux user since 1993 and the state of Linux documentation today is worse than ever before if you don't happen to be an actual coder on a specific project reading project documentation for it in order to facilitate your work and contributions.

Back in the day, there were manpages, info pages, comprehensive documentation at /usr/doc or /usr/share doc for specific packages, and documentation files in nearly every source directory that you compiled yourself. You could also pick up just about any book on UNIX (System V Bible for SysV-like distros, or various BSD books) and apply much of what was said to Linux as well.

Everything was well-understood and common to the general state of things in the UNIX world and if you didn't understand something, a quick apropos/man or info or visit to /usr/doc or /usr/share/doc would result in enlightenment.

I'm a Red Hat/Fedora user since Red Hat 4 (Slackware before that) and as a 25-year UNIX veteran, I often feel like I have no idea what's going on in (for example) the init process, X configuration, desktop management, app resources/configuration, etc. Where are the dotfiles located? Where are the /etc components? What are the command-line arguments? Where are the manual pages? What documentation does exist is generally in the awful "Help Tool" format (click Help -> Help Contents in an application window and get a lot of prose for beginners). This documentation typically offers NO INFORMATION beyond the navigation of the user interface for the application. Nothing on system resources, locations of configuration files, dependencies, APIs, command line arguments, or anything that would allow you to either troubleshoot or modularly re-use the software item in question.

The system-level stuff (PackageKit, PolicyKit, SELinux, Udev, HAL, Plymouth etc. etc.) does not offer any clear location for configuration and typing for example "man selinux" brings up a couple of paragraphs with no detail. It refers to a pile of other manual pages, none of them installed by default. There is no overview. And SELinux is probably the most transparent of all of these.

The desktop is completely unmanageable if something breaks; the dotfiles are not in any concise location. gconf-editor is not installed by default and even after you do install it, there's no documentation on the options that it contains. It's not clear how to cause a command to execute on startup. You can go to GNOME startup options in a menu through which you have to use a GUI program to "add" things to the startup process, but the environment that's being configured for the processes spawned this way is not documented and many attempts to execute commands using this method fail.

More and more it seems as though I am constantly using find and grep either in all dotfiles in a directory or as root through the entire /etc, /usr/share, and /usr/lib directories to identify through keywords or binary strings either binaries or text files relevant to tasks I want to accomplish, then paging through them or opening the binaries up in a hex editor to try to grok what I need to change through sheer intuition.

Yes, I suspect there is documentation "out there" somewhere, but spending an hour trying to Google where it is located in each instance is an hour that I already don't have and that now can't go toward actually reading and grokking the documentation in question. But it appears to be just too much to provide easy directions to the technical documentation that exists, if it exists, in each case.

There is a definite ethos of "try to hide the system from the user" that has emerged in Linux and it does not make me happy, as is obvious here. I now spend several days each Fedora upgrade trying to bang my personal system into the shape I want it to be in. It used to be really simple to upgrade, and it was one of the greatest things about Linux. Just tr

Re:Not just beginner to apprentice.

[aussersterne]

Exactly. There was a moment (between Red Hat 9 and say Fedora 2 or 3, in Red Hat land) when the best of both worlds was present... You COULD use perfectly useful GUI tools to manage things and it was great for end users to have them at that level of functionality, but you COULD also still manage your system with an xterm and vi, adding things to the .xinitrc/.xsession process, using xset to manage power saving, compiling your own kernels and assuming that in most cases it would work with the userland and installing these kernels from a root shell.

Now .xinitrc/.xsession are ignored unless you radically reconfigure things. The GNOME startup is (as you say) not only opaque but dispersed across hundreds of files not only in $HOME but also in /usr (just try to manage your menus without alacarte or change your icons in Do-Docky), the X resources system and classic arguments like -geometry are absolutely useless (you actually have to start apps one by one and hunt down configuration tools in order to affect their behavior).

On top of that, when you compile a kernel, virtually every systemic option threatens to fail to work with your userland. You have to trudge through documentation to see whether or not virtually every other option is necessary for some subsystem, and if you fail, you will not boot (or will not manage to get to your desktop). On top of that, installing a kernel now involves initrd management and questions about whether parts of the userland depend on vendor extensions to the kernel.

Yes, some of this is Red Hat, but it's also typical with ubuntu and SuSE, virtually all of the "leading" distributions.

Those who say "just switch to Slackware" or "just switch to Debian" miss the fact that full current hardware support (which these days is more and more in the userland) requires these updated userlands.

There is no essential reason why userlands these days have to ignore things like -geometry, -xrdb arguments (and the X Resource Database) .xinitrc/.xsession, etc.

It's a philosophical shift toward a monolithic SYSTEM (like Windows) and away from Unix modularity. People used to complain about the monolithic KERNEL. Now dispersed parts of the installation across all of userland are critical. There is virtually no modularity left in the most recent distros.

It's a shame, because I think the parallel mode of thinking (we'll honor old UNIX standards *and* build new user-friendly tools around them) was a much better way to go.

Re:The Culture needs a slight change.

[godrik]

It also saves programmers the time of having to answer needless questions.

Don't worry! I have scripts to answer RTFM to whole forums at once. I do not even have to read the post. Just to be undetected sometimes the scritps replies "Read the source Luke" instead.

Ironically,

[aussersterne]

man pages used to be great. They used to absolutely rule and tell you exactly how to use any part of the system. Now, most things are lacking a man page entirely (man openoffice, man gnome, man kde, man evolution) and the man pages that do exist either tell you nothing or tell you nothing useful.

And, even more ironically, there used to be dozens of desktop manpage viewers, most notably xman from the basic X applications toolset installed on all UNIX and Linux desktops with X. You could even type "man:command" into most Linux browsers and read the manpage. Now none of this exists; it has been TAKEN OUT under the theory that user access to documentation or utilities of this kind is bad for some reason.

Does the avg user actually require man pages?

[HockeyPuck]

I would assume that the average user doesn't use the CLI. Whether in windows or linux, so why should we assume that the average user would even look at man pages. Man firefox? Man calc/writer/impress? Doubt it. Take openoffice for example... let's say I want to create a textbox, so I go to the landing help page for openoffice.org and I'm presented with 4 textboxes,

-Complete Documentation Wiki
-OOo FAQ on the Wiki
-OOo Manuals on the Wiki
-Documentation Website

How is the avg user supposed to know which one to search in and the results are just a output of a google search. It would be nice if it OO.org provided more information or catagorized the output along the lines of tutorials/videos, manuals etc rather just whatever google spits out.

And OO.org is one of the better sites.

RTFM

[thijsh]

Yeah, but don't even try to ask for any help, you'll most likely get an RTFM response. XKCD said it best: http://xkcd.com/293/

I think it's safe to say the documentation isn't really lacking, but the support is... :)

Random Online Linux Doc Complaints

[happy_place]

My beefs with Unix docs:

1. Forums that are simply copies of other forums with no actual contributions.

2. Installation documentation as the only source for certain unix tools. I don't know how many times I've found Redhat's website insufficient, because it's about how to do an initial install.

3. Too many man pages lack useful examples of how commands options are used and their output. (How hard is it to simply create a few examples?)

4. Invariably someone has asked the question I want answered online, but often that's it. There's no posted answer for the question in many forums/newsgroups--the thread's just left dangling.

5. Stale links and really old revisions of a program clutter/obfuscate searching for solutions.

From the server side of things...

[DarkFencer]

From the server side of things, yes I use google for Linux and other OSS software info. But I find that much more reliable than some of the 'enterprise' software companies and their documentation (Sungard & Blackboard among the worst in my opinion).

Even worse is the fact that many of these enterprise software companies have their documentation & support information protected by login so you are unable to search them with google (and their own internal search software is god awful).

Bad documentation is not an open source/linux thing. Its pretty much everywhere.

Huh?

[BenEnglishAtHome]

Somebody modded this insightful? WTF?

Re:Huh?

[gzipped_tar]

I've been posting on Slashdot since World War II, and the silly trolls have always been modded +5 Insightful ;)

Documentation of open source is TERRIBLE.

[Anonymous Coward]

Let's be honest: Documentation of open source programs is generally TERRIBLE. Anything unusual you want to do usually requires a week of experimentation.

Re:Documentation of open source is TERRIBLE.

[digitig]

Let's be honest: Documentation of open source programs is generally TERRIBLE. Anything unusual you want to do usually requires a week of experimentation.

Absolutely agree, 100%. But it's worth adding that documentation of closed source programs is generally TERRIBLE too. I bet we all have some horror stories!

Re:Documentation of open source is TERRIBLE.

[toadlife]

Documentation of open source programs is generally TERRIBLE.

The FreeBSD handbook being a notable exception.

(IMO)

It's not actually lacking

[ehntoo]

It's just horrifically out of date. If you're talking about Linux as in things that are generally applicable to all Linuxes, the Linux Documentation Project (http://tldp.org/) is actually quite well written... but almost everything is uselessly out of date. Most of the articles I've needed in desperate hours of trouble are still written for the 2.4 kernel series. This was especially painful when I was looking into software RAID. There's some great stuff in TLDP, but it's all outdated. At this point, I think gentoo-wiki and ArchLinux's wiki are some of the most helpful places to go if you're using anything that's not .deb or .rpm based.

Re:Ok then..

[jimicus]

I'd insert a blank CD in the CD ROM drive.

Windows would then automatically pop up a dialog asking me what I want to do with this blank CD - such as write files to it.

Documentation Doesn't Matter..

[Jahava]

One thing the tech crowd needs to understand: A non-technically-minded person will never want to learn how to use a computer. It's not a matter of ignorance or stupidity. It's simply that a computer is, for them, just another appliance, and while (to you and I) it is a fascinating appliance with limitless potential, it is (for non-technical folks) a tool to get something done.

Except it's a really horrible appliance.

Compare it to a Microwave. A Microwave is obvious - it heats up things. There are sometimes lots of buttons, but they're not scary, and if something happens that you don't like, there's a big read "Cancel" button sitting right there. So you're not afraid to play around with it. You'll hit some buttons until it does what you want, and then you'll always hit those same buttons because you know they work. Every time you hit those buttons, your food gets warm in exactly the same manner.

Compare this to a computer. They take time to boot (that's not useful!) and crash. Moreso, when they crash, it's usually not fixed by just unplugging. If you push the wrong buttons on a computer, stuff breaks, and more often than not when stuff on a computer breaks, you can't solve it quickly. Best case you have to wait for it to boot again (it's not doing anything!) and worst-case you have to take it into a repair guy.

Even assuming things don't break, per se, look at all that can go wrong. A Microwave will never try to attack you, but if I miss one button my computer becomes hostile! On a computer I have so many options ... where to save a file? Who knows? I just want to put it somewhere and open it later. Organize? That's hard! What's a directory? Did I put it in "Pictures" or "Documents"? Or is it a Program File? I don't get it.

Now, my Microwave could have a dial on it that lets me control the fan speed. Another dial lets me control the microwave emitter's intensity. I could flip a switch and tune these dials just right, and cook my food just right. Cool! Or I could irradiate things lethally (or not, but it's a metaphor; suspend your imagination a little!) In fact, it's the very lack of options that makes the Microwave useful. I wouldn't judge a person for being too scared to change those dials, nor would I expect everyone to learn how.

To non-technical people, computers must be appliances, and they will prefer the OS and Software Suite that accomplishes this best. Right now that's Windows and Mac. Linux has too many dials. Things can go wrong. The end user cannot have anything go wrong ever. If you want Linux to reach the end-user, Linux has to be a better appliance than Windows or Mac. Some distros are better than others, but there are still way too many degrees of freedom. Software update sites, administrator accounts, audio not working, suspend issues, complex filesystems....

There are answers online for all of these questions. There is documentation for some, forums for others, and wikis for most. However, they all ignore the fact that these are problems that can not exist in a compelling appliance. Adding more documentation will make my job easier, but it will do nothing for a non-technical user.

Personally, the best appliance of all is looking like Chrome OS. And it's Linux!

Re:Documentation Doesn't Matter..

[bmearns]

Look, I know we like to joke around about it in computer circles, but computers are not toaster, nor are they microwaves. If someone's regarding it as something other than what it is (such as an appliance), then whose responsible for the fact that it doesn't work they way they expect?

At the risk of running counter to the Ubunutu philosphy, Linux isn't for everybody. That's why you don't just go to Walmart and pick up a Linux PC (oops...nevermind.). It's a hard lesson to learn: I'll be the first to admit that when I started with Linux I was a typical overzealous evangelist, constantly telling my dad all the reasons he should switch to Linux. It wasn't till one day when he saw me working in a full screen text terminal and said "Uh-oh, looks like you crashed!" that I realized it would be completely inappropriate for him to switch to Linux.

From it's humble Finnish beginnings, Linux has always been one thing: an operating system for the people who built it. The rest of us are opportunists.

I'll say something else that's needed

[jimicus]

Coming at this from the perspective of a professional Linux sysadmin with quite a few years experience, I find a lot of forums downright painful.

Not because they're difficult to use or search - Google does a perfectly good job of indexing them - but because they are frequently a case of the blind leading the blind. I really have lost count of the number of times I've looked on Google to solve a problem, found a few forums and discovered two things:

1. I'm at a much more advanced point in the process than the OP. (Not really a problem, more an annoyance)
2. The answers given are downright wrong, and demonstrate clearly that the person writing the answers has no understanding of what it is they're talking about. Which I wouldn't know were it not for (1), above. The forum software itself needs some way to mark replies as "helpful" or "unhelpful", much like /.'s moderation system. In an ideal world Google could pick up on this and show helpful replies above unhelpful ones.

Mailing lists for the specific thing you're having trouble with tend to be better - largely because the barrier to entry for posting on a mailing list is rather higher.

apropos burn

[aussersterne]

You've actually hit on one of the few examples that "sort of" works still in Linux (though it could be better).

On Fedora 12:

$ apropos burn
brasero (1) - Simple and easy to use CD/DVD burning application for the Gnome Desktop
$ man brasero

If only it actually worked this way (as it used to) for most of the rest of the Linux applications/tasks ecosystem.

GIMP Problem All Over Again

[mpapet]

One of the interminable flame wars when GIMP stories run is "If it just had feature XYZ... then I'd switch." Or, the flamebait, "GIMP isn't as good as Photoshop, therefore I'll never use it."

In this case, "If only a Linux distro had more XYZ... then I'd switch." People are stubborn. They will either switch and deal with the learning curve (warts and all) or they won't and they'll start flamebait threads like, "Docs suck..."

Like the GIMP, when some Photoshop feature makes it into the application, (ex. color management) the "If it just had feature XYZ..." comments don't decline and the new users don't come flooding in. Bottom line, there's no amount of documentation that would end the "Docs suck" post.

Do some specific applications need better documentation? Sure, but that's not a Linux-specific problem. Overall, it's a very well documented OS.

I don't know if anyone has mentioned the Gentoo pages, but those are pure gold when I don't know where to start.

Re:Ok then..

[rubycodez]

my Ubuntu 9.10 does that too. helpful when I plug in my usb camera too

Re:Yes, you're right, but you miss the point.

[BrokenHalo]

Openness implies access, understanding, knowledge, transparency. Without documentation, none of these exist.

No, you're conflating two completely different things. Open (as far as software is concerned) refers to access to, and freedom to use and re-use code. Documentation is (regarded as) a boring task required to make code accessible for newbies. Sure, it would be nice if the programmer could do both, but the simple fact is that it is common for competent programmers to lack the requisite communication skills for writing useful documentation.

Active v. Passive

[abulafia]

I think this illustrates the key point about Linux documentation.

Facts:

- Yes, documentation sucks. This is because there are very few people who are both knowledgeable about what "the code" (meaning currently packaged distributions; bleeding edge stuff is a different kettle of monkeys) does and also like writing documentation. (Put aside being good at tech writing for the time being.)

- Things constantly change. As an example, Ubuntu's 6 month window leaves non-techy people breathless at the rapid rate of change, but at least it sets expectations. The tech publishing industry simply isn't capable, right now, of releasing books that fast, even if you assume the can opener of someone competent, willing, and able to write a book targeting the next release. I'm as quick to joke about M$ or Apple's release schedule, but the Missing Manual types at least have a target to hang a book release cycle on.

- Googlicous search is hit or miss, and humans have a cognitive bias emphasizing miss. The seven times you find exactly what you need to know (score!) are mentally outweighed by the one time you couldn't get your new video card to work.

Which all leads me to: the best way to run Linux is to be involved in the community. Folks in the know are much more willing to help you on a message board, IRC or whatever than to spend a week or six writing documentation. The payoff is much greater: someone happy at your interactive investment of two hours of partial attention. Contrast with the investment of a couple of weeks writing docs to see email from someone with weird hardware and poor attention to detail flaming you for "causing" them to lose their term paper.

Not everyone who wishes to run Linux wants to engage geeks on IRC. There is a mismatch there. But I don't see that changing.

There may well be an opportunity emerging for knowledgeable communicators - a $10 service targeted at narrow niches for people like my grandmother's new boyfriend - a non-geek who runs Ubuntu and manages his own website, but is generally clueless about what to do in the face of a problem. The niche is narrow; it has to target the impedance between wanting a fix now and waiting for me to be able to provide family tech support, and it has to actually work for his particular problem. And I think it looks more like tech support than publishing. Anyone who's read Rainbow's End by Vernor Vinge might see the model of 411 service here.

Linux documentation is not Linux documentation

[julian67]

Because almost every application/tool is also found packaged for OS X, BSD, even for Windows....obvious likely exception: the Linux kernel docs. So the article is kind of stupid from that premise onwards. But anyway how about someone offer more than a single example, not just anecdotes, cliches and rants? While remembering tfa is about new(ish) users' experiences?

Assuming a new(ish) user is using a graphical environment means that man pages will not be the first place a user looks. So basically we're looking at the docs specific to the environment (Gnome/Xfce/KDE etc) and the docs of the individual applications. Almost every gui application I've seen has a 'help' button on the menu bar. Some of these launch a help doc in a doc browser, some a locally hosted html doc in the default web browser and some do the evil thing of offering only a web address and assume you are connected...grrrr. Most of the apps I use have very decent help docs. A few don't have anything useful and then again some are models of excellence. I notice the same situation when I use Windows. It's really dumb to say this is some endemic problem with Linux/free software.

If the issue is with stuff like 'how do I set up RAID' or 'how do I install with /home encrypted' then this is up to the distribution to get right. Some are better than others. In Debian there is the online Debian Reference, a reference guide aimed at *users* not developers. This can also be installed and so be accessible without a net connection. It covers all kinds of stuff from the introductory section on the UNIX filesystem hierarchy i.e. what are /etc /home /var and what is the root account, right through to setting up your own subversion repo or customising the kernel.

Occasionally a user might come across an application which is poorly documented, that is there is little documentation or the documentation is inaccurate/outdated/difficult to understand. But why should one or two particular/anecdotal experiences lead to a belief that 'omg linx has bad docs!' It's an overreaction, but I suppose it fills column inches for bloggers/journos and offers the casual blowhard the opportunity for a badly informed whinge post on a board.

Thinking back to the last thing I struggled with: wake on lan. I didn't have a clue what to do to set it up. Searched distro wiki for wake on lan, result being a page of good instructions about which tools to use, how to check my ethernet card supports it, how to enable it, a brief comparison of two different wol clients, lots of examples and other helpful stuff. A few minutes later had it all working. Shocking!

I have 3 real issues with manpages

[AlgorithMan]

although I like manpages and do consult them, I prefer googling stuff, because three problems you often have are

• no examples
• the parameters are sorted alphabetically - so you might have to scroll through 50 screenpages of obscure parameters that you most certainly never need until you find the one you're looking for (IF you are still reading at that point)
• bad descriptions like --fluxcompensator activates fluxcompensation

just put some real-world examples at the beginning of the manpage and you're good...

Not mutually exclusive.

[SanityInAnarchy]

I can access help files with a mouse click, too, where it makes sense.

For comparison, open up a Terminal in Mac OS X, and tell me what you find for documentation. In fact, I dare you -- try the same with start->run->cmd on Windows.

If you're already in a commandline environment, man makes sense, and Google makes sense as a way to find out about man. I know of no OS which provides point-and-click help for the commandline, nor can I think of a sane way to do it.

Re:Not mutually exclusive.

[SanityInAnarchy]

That's a bit like saying, if you need to write a program, someone has failed.

Now, if you need to be in the commandline to do something which an ordinary user should be able to do, for which there is a sane GUI equivalent, I agree -- that shouldn't happen.

However, there are and always will be things which are easier to do with a commandline, and things which can't really be expressed elsewhere. The use of pipes alone warrants that.

A fun example would be taking a disk image, checksumming it while compressing it lightly and sending it through an encrypted tunnel to a server, as with light enough encryption, this will actually be faster than sending it unencrypted -- especially if the destination drive is slower/busier than the source drive... then, when it's done, transfer the checksum to the server and have the server decompress the image while verifying the checksum, then immediately re-compressing it with much heavier compression, taking several hours...

You could argue that specific parts of this could be done better -- maybe I should checksum the compressed file so I know sooner. Then again, my way means I'm also checking the compression itself -- it means I absolutely am getting out of the other end the same thing that was on disk. You could also argue that I should bundle all of this into a piece of GUI software designed for taking disk images -- debatable, but I can go with that.

But the fact that I need the commandline to do that now isn't a bug, it's a missing feature. In this case, the commandline is almost acting as a kind of software development -- and it is, after all, Turing-complete.

I'd argue that if you need a GUI for something, that's also a failure. GUIs aren't reliably or easily scriptable, and the concept of pipes doesn't really apply. The above procedure would work, if the GUI had been developed with it in mind -- but it'd have to be a very specific GUI, whereas on the commandline, the compression tools, checksum tools, imaging tools, and encrypted tunnel, are all completely independent and generic -- the same compression tool that I might use to unpack a tarball will also handle a disk image. The same imaging tool which could create a file on an external hard drive can also stream the image over the Internet -- all without knowing anything at all about either of them.

Re:Not mutually exclusive.

[SanityInAnarchy]

I'd argue that sending the uncompressed file is faster, because you don't need to waste half an hour writing an elaborate program.

Try 2-5 minutes. And it's then reusable. By now, I know that sequence of commands well enough I could probably do it in 30 seconds to a minute.

And it is actually meaningful here. The sooner I can get that image taken, the sooner I can wipe the drive, and the sooner I can get the machine back in the hands of the customer -- or myself, for that matter. The server can then sit there crunching for days, if I want -- and lrzip will take days.

AND it's non-user friendly.

Yes, it is. It's a non-user-friendly way of doing something for which a user-friendly way doesn't exist, anywhere, that I know of. That's the point -- again, if there's a GUI that'll do the same job, that is better for the average user. But having a commandline available is better than nothing at all.

And again, you need the commandline version anyway. Another example -- suppose I'm responsible for maintaining a large network, so I need to be able to do things like this automatically. That is, walk up to a machine, have it boot from the network (or from a CD), into a system which automatically sends an image to the backup server, then wipes it with a clean image -- then the backup server can have a cron job to flush old images after a week or so, when we're reasonably sure the user doesn't need any files from them.

Now, how would I build a scheme like that from a GUI? You could argue that it'd be nice to have a GUI tool to configure the netboot server, or build a CD image for me, but ultimately, such a tool is easier to write if it can just add a few commands to a boot script -- and even if such a tool doesn't exist, a half hour of my time to build that system once will pay for itself many times over, when multiplied over a network.

Replacing the CLI with a mouse improves usability.

It improves discoverability, hands-down. That's what commandlines suck at. This is a good point, right here:

without memorizing the commands or digging through a manual.

But that is not about usability, it's about discoverability and learning curve, which is only part of usability. For example: I already know how to navigate my filesystem with the commandline, move files around, etc -- it took me longer to learn to do this, and things like 'cd' and 'ls' aren't right there in my face to find, I had to read some tutorials, etc. Tab-completion isn't obvious, either -- these are all things I had to be taught in some way or other.

The result is, I'm faster with the commandline than I am with the mouse. Really. Using cd and ls, with tab-completion, is faster than pointing and clicking on icons of folders. And once I've navigated to where my iso is, typing 'wodim foo.iso' is much faster than right-clicking on the image, looking for an option to burn, and clicking through a wizard.

And that's without even considering scripts. Taking the above example, I usually do something like 'wodim -dao -eject foo.iso' -- if this ever got annoying to type, I could easily make a new, shorter command which would do just that.

Now, that's not universally true. I've used lynx, and I wish I had better keyboard control in my browser, but a web browser is still much better in a GUI. I certainly wouldn't argue that photo editing or 3D modeling would be better done with a commandline. Each has its usefulness.

I also agree that if you're trying to do something simple, you shouldn't need a commandline. And this is mostly true on a modern Linux. Plug in your digital camera, and the appropriate software pops up -- that's even easier than on Windows, which makes you wait while it installs drivers, last I checked.

But to say that any need for the commandline is an indication of something broken is demonstrably wrong.

Re:Ok then..

[IICV]

And if you tell that dialog "I want to burn these files to the CD", you'll get a CD that only works on other Windows computers. By default, Windows does not burn CDs in a manner compatible with anything but Windows. That's so much more user friendly than Linux or OSX, because everyone loves the mystery of "why doesn't this CD work on my friend's mac?"

Is Windows any better? What's wrong with Google?

[SleepingWaterBear]

Ok, so I'll be the first to agree that Linux documentation is on the whole terrible. You can get some documentation with man, but unless you're pretty comfortable with a command line, the documentation is likely to be completely useless to the average user (I remember when I first started using Linux that figuring out how to make sense of man pages was often more challenging than just guessing how to do things). The contextual help in Ubuntu is slightly more readable, but usually useless when there's any available at all.

That said, is Windows documentation any better? I haven't really used Windows in a couple years now, but from what I recall, opening up one of the help files to figure out how to get something done was completely useless. I have generally found that I'm much more able to figure out how the program works by fiddling than by reading help pages. Less technical users (like my parents) generally can't figure out how to do things, it's true, but they also are completely incapable of finding the relevant help page - I suspect that the skills are related. I suppose what I'm trying to say is that for most end user applications documentation is pretty well irrelevant, and the real question is how intuitive the interface is. On this front I think that Windows and Linux are pretty well tied at this point, both lagging a ways behind the top to bottom uniformity you get from Mac OS.

Finally, is there really any problem with using Google as your documentation? I think that Google is the best sort available documentation on all the major OSes, and I'm not really sure I see the problem the summary is claiming exists. So, in summary, poor documentation isn't a linux problem, and I'm not even really sure it's a problem at all. This seems like a lot of fuss over nothing to me.