Commands, Arguments, and The Cathedral and the Bazaar

1. What is an argument? Give several examples.
   

An argument or command line argument is extra data, like a file name or an option, that is added to the end of a command and is normally separated by a space and or a single hyphen. This argument is then used by the command as input when it is called on. Take the tree command which displays a directory listing in tree form. If one adds -a to the end of the command, tree -a, then the listing will show hidden files. To list only directories and no files then the command tree -d is used. Another example is cal command which displays a very basic calender. When typed cal -m, the calender is displayed with Monday being the first day of the week. If the command looked more like cal [month] [year] but you have the brackets filled with a real month and year then a calender for that date would then be displayed.

2. Use the man pages to tell me two options for the ls command and what they do.
   

The ls command will list the contents of a directory. When it is placed with some arguments that changes to a degree. Like ls -a will list all files including the hidden ones or ls -l will list the files and give details on each of them. If you don't want to read the size of files in bytes then you can use the ls -lh which will list the files with the sizes in a human readable format like mega or gigabytes.

3. Use the internet to look up "The Cathedral and the Bazaar" and tell me what it is and why it is important.
   

An essay written by Eric S Raymond, "The Cathedral and the Bazaar" is a document about open source software and the way it works. Raymond give credit for the metaphor to the book “The Mythical Man-Month” by Fred Brooks, where the cathedral represents the traditional commercial software development style, with tight management control, small teams, and long intervals between releases. The bazaar represents the whole releasing early and often style challenging Brook's Law and using a large team of developers and testers. Through out the essay Raymond shows many reasons why the bazaar open source style is more effective in producing high quality software and one of the main ideas behind this is that fact that the more widely spread source code is for testing, straining, and tweaking, the faster any and all bugs will be found and fixed. Or as Raymond coined the Linus' Law, “given enough eyeballs, all bugs are shallow.” Along with the story of an email application Raymond also give 19 guild lines in the essay which I'll list below. All in all this was a really good essay that brings about a lot of ideas in my own mind and also helps me connect a dot or two in the computer world and I can't wait to read it again.



Here are Raymond's 19 guidelines:

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. Plan to throw one away; you will, anyhow.
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.