| ??? 04/18/12 17:59 Read: times |
#187210 - Still lots of assumptions and unbacked claims Responding to: ???'s previous message |
Richard said:
While there has been some time that's passed since then, I doubt there's much change in attitudes. So your view on the state of documentation of Linux or open source in general isn't a view on the state now, but the view of the state some unknown years ago. Since you refuse to give any explicit examples, I'll give a couple. What do you find wrong with the documentation available? http://wxwidgets.org/docs/ http://www.samba.org/samba/docs/ http://httpd.apache.org/docs/ http://www.gnu.org/software/...bison.html I've not "interviewed" such people, but I have had them under my supervision over the past few decades, and have gathered from their attitudes that those who write code don't like to have to document it. Please read more carefully. You often miss very important things when you read and then answer. I wondered about the people who have as a profession to write manuals and documentation. It is, after all, not a developer who should write end-user documentation for any serious piece of hardware/software. There's plenty of information about installation and configuration, but precious little about what to do and how to do it. So what about sites like: http://tldp.org/ http://www.faqs.org/faqs/ http://www.gnu.org/gnu/gnu-linux-faq.html I've looked at both code and doc's since then and seen little improvement in relative lag between doc and code. What doc? What code? There are never any explicit references given. Just because there's a LDP doesn't ensure that the last-released doc's are in any sense current. But then there isn't normally a need. The documentation telling you what you can do with a software can often be totally relevant even if several years old. Simply for the reason that the explicit list of command-line switches supported are often documented separately. So you have one type of documentation in book form, where an end-user learns the concepts and ideas and what type of problems a tool is intended for. Then a second set of documentation in form of manual pages, wiki pages or similar that contains explicit details, release history etc. Then there is a third set of documentation sent with the source code, supplying important technical information for a developer who wants to modify the application and needs to know some of the workings of otherwise black boxes - this is documentation that either doesn't exist or only exist in form of NDA-covered manuals for special partners when talking about commercial projects. When debating documentation - especially when complaining about state of documentation - it really is important to know what the goal/target/issue is and give relevant arguments together with the necessary references to allow someone else to check up on the state before answering. With GIMP, I found that there's more emphasis on what one can do than on how to do it. And this would differ from commercial software? Haven't you already noticed that the majority of commercial software do release documentation saying what you can do. Then third-party authors get their income from writing books explaining for the users how you use the tools for real-world problems? Try Amazon and check on books about different software. The main difference is that for commercial products, you are normally forced to buy commercial books. For open-source products, there are often people who write similar types of books but covered under an open license, where you can download it for free. In both cases, you have to get this extra information from a third party. The issue is that the printed book gets old - so you have to buy a new one when 2.0 becomes 3.0. The pdf book may get newer versions that you can still continue to download for free. "LINUX components originate, to some extent, from *NIX where people did things in such a way as to make their efforts impenetrable, thereby ensuring job security." Linux (why you use all capitals?) obviously originate from *NIX. But no - people did not do things to make their efforts impenetrable. On the contrary. Most unix programmers have a want to write code that a reader will find beautiful. People writing commercial software for Windows knows that no one outside the company will ever see the code. The incorrect idea about Unix and complexities or unreadability etc stems from the fact that the original Unix systems did solve very complex problems using very little hardware. They where the "embedded programmers" of their time - but solving corporate-level problems with hardware less powerful than the best 8051 chips. Think about writing a multiuser system for 10-100 concurrent users on a processor with 64kB RAM, and process the inventory for a company like AT&T... |
