walt <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 20 Jan 2007 00:59:44 +0000:
> On Sat, 20 Jan 2007 00:00:09 +0000, Charlie Wilkes wrote: > >> I am new to Linux (Ubuntu) > > Welcome to the un-Windows world. Continuing this subthread. Probably the single most helpful recommendation I asked for and got when I got serious about Linux, and consequently one I pass on as often as possible, is to pick up a copy of the following two books. Together they run $70-80 USD, but the one saved me literally a minimum of 500 hours screwing around unproductively on my own trying to figure things out, and the other I've bought an updated version of and likely will by another pretty soon as well, so you tell me whether it was worth it. =8^) Both books are published by O'Reilly. Running Linux is a 600-ish page tome in tutorial or textbook format, designed to be read more or less front to back, generally simple stuff (like Linux file permissions and the basic commands for working with files and directories in Linux) at the front, more complex stuff at the back. Until I read this book I was more or less lost on Linux, tho I had played around with it some. When I got serious, I asked for book recommendations, and this and the following one came up repeatedly, so I got them, and it made a world of difference. =8^) Linux in a Nutshell is as are all the O'Reilly "Nutshell" series books, intended as a reference for someone already familiar with the basic concepts, but needing help with specific commands and their options from time to time. The best description I've seen for it was an excerpt from a review that was included on the back cover of the third edition, something to the effect of "Like a stack of manpages but far easier to carry around." However, it's more helpful than some manpages, listing options and what they do in somewhat less obtuse language, while omitting detailed descriptions of the "expert" options especially, that only confuse the ordinary user. This is the one I bought an updated edition of, and plan on buying another soon, as it's one book I keep within reach at the computer and continue to use (as it's more convenient than the manpages, as well as clearer and more concise in many cases) even several years later. Both books take a generally distribution agnostic approach, preferring the mostly universal command line tools and text editor config file editing, to distribution specific tools that are often somewhat limited in their flexibility in addition to being parochial. However, don't less this scare you as particularly Running Linux does do a really good job of teaching you exactly what you need to know to do what you want and need to do. Still, for things like printing, you may want to use your desktop or distribution specific configuration tools and just skip or skim that part of the book, knowing its there if/when you do decide to learn how to /really/ configure that part of the system. Anyway, if there's one thing I could point to to say this is what helped me succeed in becoming a Linux power user, it's those books. Just as it was passed to me, I'm happy to pass it on, if it can help someone else begin to appreciate just all Linux has to offer, while providing some sort of map or guide in what can otherwise be a very strange and bewildering world, at first. If others find the books even a tenth as helpful as I did, they'll still be thanking me for passing on the recommendation. FWIW, when I originally bought them, both books were new in their third edition. I bought the fourth edition of Linux in a Nutshell as my upgrade copy, and now I believe both are in their fifth editions. As for finding stuff, file system layout, here's a brief overview of the way /most/ Linux (and indeed, with some minor variation, Unix in general) distributions lay things out: /etc system basic/boot services configuration Basically, anything that you run "one" of, for the entire system, normally has its config here. /etc is assumed to be on the root partition, thus making its configuration files and scripts available from early startup. /usr the "guts" of the system The majority of a system's executables and libraries live in /usr, along with the /default/ configuration for per-user run or configured apps and services, such as your desktop of choice (KDE, GNOME, whatever). It should be noted that on a multi-partition system, /usr may live on a partition other than /, and extra partitions aren't normally mounted until about the middle of the startup process. Thus, anything necessary to the boot process /before/ the mounting of most partitions can't live on /usr, as it's often not available early in the startup process. Thus we have... /bin, /sbin, /usr/bin, /usr/sbin executables live here The "s" is short for "superuser", so sbin contains system administration tools not normally executable by or of interest to ordinary users. As mentioned above, the /usr location can't be assumed to be available early in the boot process, so anything that's necessary for early boot, and system recovery tools that may be used to fix a /usr that won't mount, live in the /bin and /sbin dirs, located on the root partition. /lib, /usr/lib, /lib64, /usr/lib64 shared libraries and executables normally called from other executables, not directly, live here. On biarch installations such as amd64, 64-bit libraries usually go in the lib64 location, while "legacy" 32-bit libraries and stuff like python scripts that are independent of arch normally find themselves in lib. (Some distributions have a lib32 for 32-bit specific stuff. This is also common on archs such as ia64 where 64-bit is the primary arch and 32-bit may be emulated or otherwise is considerably de-emphasized. In such cases, lib may symlink lib64, or lib64 may symlink lib.) /usr/local packages installed manually usually live here By "manually", I mean not using the distribution's package manager system. If you get the pan tarball and install it, it'll install pan to /usr/local/bin by default, for instance. This is also a good place to store any sysadmin utility scripts you come up with on your own, as it is what it says, the domain of "local". /usr/local therefore normally contains the usual subdirs, (s)bin, lib(64), sometimes games, whatever else you put there. Many installations make it a separate partition, making it easier to backup on its own and to keep around during system reinstalls. /usr/share documentation and the default config for user apps /var service data (mail, news, ftp, web, print servers, logs) The various service spools and data dirs live here. /var/log virtually all system logs live here Both /var and /var/log are often kept on separate partitions. Among other things, that limits the damage if for some reason a log or spool suddenly sees a lot of activity and gets very large, taking all available room, since "bad things" (TM) happen if there's suddenly /no/ room left on partitions such as root, for instance. /tmp, /var/tmp system temporary file locations Sometimes, /var/tmp may be a symlink to /tmp, but there's often a distinction in how they are used. However, that's rather more distribution specific than the rest of this, and hard to explain in a coherent fashion, so I'll leave it alone. These are frequently their own partitions (one reason for the symlink, when the admin doesn't want two partitions when one will do), since they can be quite active and open files at the time of a crash are frequently corrupted. Since it's all throw-away data anyway, it can be easier to just wipe it and start over. In fact, as I've 8 gigs of memory here, I keep /tmp (symlinked from /var/tmp so they are both on it) on a tmpfs in RAM, thus keeping it both super-fast and eliminating any need to worry about cleaning it up at boot, since it's wiped clean. =8^) /opt "optional" packages. Many binary-only or larger packages install to /opt by default. This is sort of the equivalent of /usr/local but for binary only stuff like games and large stuff like KDE by default, when it's installed on its own, that is, not using your distributions regular packages of it. (Most distributions install KDE to /usr if the package manager does it.) Since I won't install binary-only software, aka "slaveryware" as opposed to Linux's "Free software" or "freedomware", and I use my distribution's version of KDE, /opt is empty, here. /mnt, /media mountpoints for dynamically mounted filesystems mnt is older, media is newer and not used everywhere. Some usages mount new filesystems on /mnt directly, therefore making it inconvenient/impossible to properly mount several different ones at once, thus the /media location. Others use mountpoints such as /mnt/cd, /mnt/dvd, /mnt/floppy, /mnt/usb, /mnt/usb2, etc, instead of having the same mountpoints under /media, and never mount anything directly on /mnt itself. These generally won't have a /media. /home, /root user's personal configurations and data lives here. /root is the home dir for the root user, thus giving it access to its personalized config before the other partitions are mounted. Since /home contains all that valuable personal data that's hard to replace if it gets list, it's often kept on its own partition, making backup and restore that much easier. Some further notes, mostly on the organization of home dirs: A shortcut notation for an individual's home dir is ~/ . As someone already mentioned, just as MSWindows has the hidden file attribute available to keep files from being displayed by default, Linux (well, Unix in general) uses a leading dot to indicate a hidden file. Since there's often a lot of config files and subdirs in a user's home dir, and these would clutter things up when a user is looking for that jpeg or whatever they just saved, by tradition, all the config files and directories in a user's home dir are hidden. If you turn on display of hidden files, you'll see them all and probably understand why they are usually kept hidden -- there can be a LOT of them. pan is no exception, thus its config and data dir is by default ~/.pan2. It's quite common for a user to have either a ~/bin or ~/.bin directory, in which he keeps his own little scripts and executables, and add that to his $PATH (set or added to from the default in ~/.bashrc or the like), so he can run them without typing out the full path, only the name. If you run KDE, you'll notice that it keeps most of its personal configuration under ~/.kde/share (there may be a version number after kde, as in .kde3.5, or not). This mimics the location under /usr/share where the system-wide config is stored. That should provide at least /some/ sort of orientation and idea of where to look for stuff on your disk, now. =8^) However, get Running Linux. Really. It's /full/ of practical information like this! As I said, I figure it save me literally hundreds of hours of feeling dumb poking around not being able to do much but make mistakes, so it was easily worth the money many times over! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
