Learning More About Linux?

teh moges asks: "From an administrator point of view, I know a lot about Microsoft Windows: where files are stored, where settings are, which registry keys to edit, how to change drivers, and so on. I made the initial switch to Linux a year ago. I now feel capable enough with using Linux, from an end user's point of view, so that when things go wrong, I can fix them. I now want to become even more familiar with Linux. Are there any great resources, such as websites, wikis or books for someone that wants to find out exactly how Linux works and how to fix and modify it?"

Comments

Re:Only thing to understand...

[Timesprout]

Double cut flat files? Nail files? Diamond files? Needle files? Machine files?

Can you be more specific about the files please.

Re:Only thing to understand...

[Anonymous Coward]

Not exactly, but it's a close enough first approximation.

For the Ask Slashdotter: /bin stores essential programs. These tend to be very low level programs. /dev stores file-like interfaces to device drivers. You can read and write to them, just as you would a file. (Using C. You probably won't need to touch anything in there unless you're programming drivers. /etc stores configuration files. They're supposed to be text files. The syntax varies across them, so Google is your friend here. /home stores user directories. Each user gets a /home/ directory. /lib stores essential, low level libraries.

There are a few others, but these guys are the important ones for what follows. There is also a /usr hierarchy, which has it's own bin, lib, (possibly etc). It's meant for "shareable, read only data". This is where globally installed programs usually go.

GCC is your compiler. You probably won't have to play around with it much, but I'll talk about some tricks to give you more insight into Linux. Suppose there's a program you want to try. You create a dummy account called "dummy" for it (so your data won't be in harm's way if it's buggy). Now, when you compile the program, you'll probably have to write ./configure. But that sets up the compile so that it gets installed in the main hierarchy. That's not what you want. So instead, you use ./configure --prefix=/home/dummy/program. Now, when the program is done compiling, you issue the install command (make install) and make automatically generates /home/dummy/program/bin, /home/dummy/program/lib, and so on. You've basically just made a private /usr hierarchy. This can be very handy.

Now, suppose you end up really liking the program, and you want to be able to use it from your account, but want to deny everyone else access. You can just mv /home/dummy/program to /home//program. Everything will (should, really) continue to work. Now you'll want to change the hierarchy's permissions so that only can run the program. You can do that with chmod -r 541 /home//program.

Of course, you don't want to have to keep typing /home//program/bin/ to run it, so you have to add /home//program/bin/ to your PATH environment variable. You do this by issuing an export command of the form export PATH="/home//program/bin:/home//program/lib:$PATH"

Now you can type the program's name from any location, and it will run. But only until you restart your shell. To make the change permanent, you'll have to edit your .bashrc or .bash_profile file. These are a lot like DOS batch files, but are written in "Bash", which is more flexible. Just stick the export command above in either of them, and the command will be run when you log in.

There are a lot of magic numbers and constructs in my post. Think of it as an invitation to learn about what you're interested in.