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.

What is a kernel?

What is a kernel?

     A kernel is more or less a resource manager that manages things like processes, memory, and hardware devices. The kernel also allows access to resources in which multiple users compete for. 

There are seven sub systems of the kernel to manage the system and it's resources, these include

1. System call interface- The SCI allows a user space application to interface with a service the kernel provides.
2. Process management- Focuses on running processes and puts in place a scheduling algorithm so threads or processes can share the CPU.  
3. Memory management- Sets up and manages pages, keeping track of which ones are full, partly used or empty. When many users or processes eat up all the available RAM, then swapping takes place and less important files are relocated to the swap partition.
4. Virtual file system- The VFS specifies a standard interface that each file system must support and is a buffer for common functions like read, write, close, and open.  It also interfaces for device drivers.
5. Network stack- This sub system provides users with a variety of network protocols such as TCP and IP and makes connections allowing data to be moved from one node to another.
6. Device drivers- Device drivers are just that, device drivers. A peace of software or code that allows the OS and hardware to communicate.  In Linux the drivers are coded right into the kernel.  
7. Architecture-dependent code- Code that is dependent on the architecture of the CPU and available for other operations that may depend on the architecture.

     So that is my very basic overview of the Linux kernel, what it does, and the seven different sub systems involved.