On Sun, Oct 13, 2002 at 11:50:18AM -0700, Josh Rehman wrote: > I want to master Linux. I figure there are two ways to learn Linux > system administration and usage. The first is to install a distribution > and then explore it's nooks and crannies. The second is to begin with a > seed and *grow* the nooks and crannies as needed. The former method is > overwhelmingly used; I'd like to see more of the latter, because it's > the more effective approach for advanced studies.
I suspect that although the second is more effective, it is incredibly difficult to implement; especially with complex systems that have evolved instead of being designed. > I believe that the second approach is superior because complexity is > best understood when the student understands why the complexity was > introduced in the first place. And the best way to accomplish *that* is > to present the student with the problems that the complexity was > originally introduced to solve. Then when they are stumped, you can give > them the answer and they can say, "ah". Yes, that is an excellent way of teaching people. I use it upon myself, when I try to learn a new technology. I'll search around for an elegant pre-built solution to a problem; because I suspect that someone has encountered it before and solved it well. This typically works. > WRT GNU/Linux in general and the Debian distribution in particular, > there are several aspects of the OS that still baffle me, and frankly > intimidate me with their complexity. The boot process is one of these, > as is the nature of the filesystem, dev and proc in particular. Logging > is opaque to me. There are many aspects of the system where it is not > clear where the responsibilities of one program ends and the other > begins. I find the blurred distinction between shell scripts and > compiled programs to be confusing. Not to mention the dizzying array of > configuration files and their baroque syntax! Unfortunately, you have stumbled upon that fact that your computer is a general purpose calculator, and is ridiculously complex. I can tell you what you need to learn about before your confusion can completely disappear. The boot process on an i386 machine (which I assume you have) is the result of a design decision that IBM made in the 1980s. You will probably want to learn how the BIOS works, and about reserved sections of your hard disk. In the UNIX world, everything (well, almost) is a file. Thus, the /dev and /proc filesystems appear to be files to all your programs, and you can manipulate them in that way. To know more about the /dev filesystem, you will want to look at major/minor numbers from the original UNIX. The /proc filesystem controls various aspects of the kernel, and can be considered as pieces of the kernel exported to file. Logging is done through syslogd and klogd. Their documentation may explain things better; for they are quite simple programs. The quick difference between shell scripts and compiled programs is that shell scripts are human-readable, and need to be interpreted by other programs to turn them into executable machine code. Compiled programs are already executable machine code. Configuration files... well, they just evolved that way. There's not much you can do about their differing syntax, although there are many projects that try to unify them into a single interface. Typically, configuration files are designed to be easy to parse, and then they just grow as more features are added to the program they configure. > I am looking to understand and manipulate a Linux system with the > minimum number of tools to accomplish certain simple goals. The goals > increase in complexity. Tools should be introduced only as needed to > accomplish a goal that is simply impossible (or would require an > inordinate amount of shell or c work) with a current toolset. Doing this, you will be very far from the level a beginner would start at. UNIX was originally a toy operating system, made to test a new filesystem, to drive a video-display terminal, and to just much around with. One of the first uses of UNIX was to program (and program in) C, as well as typeset books for AT&T Labs. In this context, the base tools presume that you are an operating system hacker who likes to manipulate source files and documentation. Since this is UNIX in its purest and simplest form, you may wish to study Operating System theory and play with teaching operating systems. As well, studying compiler theory will help immensely, especially since you'll learn about regular expressions. With these, you can get by incredibly decently, with only the tools that Aho, Keringhan, Ritchie, Thompson and Bourne had kicking around. It won't be a pleasant situation, but you can get work done. Ever since then, we've really just been trying to make UNIX (and UNIX clones) more powerful and easier to use. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]