Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux Software

Learning More About Linux? 184

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?"
This discussion has been archived. No new comments can be posted.

Learning More About Linux?

Comments Filter:
  • by fimbulvetr ( 598306 ) on Thursday April 19, 2007 @07:56PM (#18806447)
    Linux is files. The entire OS is based on files. Things to run on startup? Files. Opening hard drives? Files. Drivers? Files. (kernel mods)

    No magical black box registry, windows drivers, etc. Once you understand this, other things will come easier.
    • by Timesprout ( 579035 ) on Thursday April 19, 2007 @08:04PM (#18806513)
      Double cut flat files? Nail files? Diamond files? Needle files? Machine files?

      Can you be more specific about the files please.
    • by twenex27 ( 1004369 ) on Thursday April 19, 2007 @08:16PM (#18806615) Homepage

      Linux is files. The entire OS is based on files. Things to run on startup? Files. Opening hard drives? Files. Drivers? Files. (kernel mods)
      Not quite true, of course. Networking breaks the "everything is a file model". Arguably, device drivers do too (witness the hundred and one interfaces to control different devices).
    • by dpilot ( 134227 )
      Certainly better than being made of tubes...

      Are you sure Linux really isn't a series of tubes?

      On a slightly more serious note, many aspects of Linux are documented, perhaps a starting point for what you want is the "Filesystem Hierarchy Standard". The name has changed a time or two, and I don't exactly know the latest, or the acronym.
    • No magical black box registry

      Can you say, "sysconf?" Or the /proc filesystem? That's a "registry" if I ever saw one. Slightly more manageable than the one on Windows, but a registry nevertheless.
      • Can you say, "sysconf?" Or the /proc filesystem? That's a "registry" if I ever saw one. Slightly more manageable than the one on Windows, but a registry nevertheless.

        I can't think of many ways that /proc is similar to Windows Registry... would you care to enlighten me? I can think of many ways they are not similar... The fact that userland programs do not store persistent information in /proc is the first thing that comes to mind.

        Even /etc/* is more like Windows Registry than /proc is.

      • Re: (Score:3, Interesting)

        by schon ( 31600 )
        I would say that you made a nice example of selective quoting, but you couldn't even get that part right. You probably should have said "no [...] registry".

        No magical black box registry

        the /proc filesystem? That's a "registry" if I ever saw one.
        Could you explain how it's a "magical black box"?

        And you know what? Everything in it shows up as (wait for it..) files - which was kind of the point of the message you replied to.
        • Everything in it shows up as (wait for it..) files
          On what do you base that conclusion - that the expanding tree hierarchy looks a bit like windows explorer?
          • Since when did the output of ls look anything like Windows Explorer? And that's the point -- everything shows up as files in the sense that they can be operated on with normal utility programs that work on files, like ls, cat, grep, etc.

            • by harrkev ( 623093 )

              And that's the point -- everything shows up as files in the sense that they can be operated on with normal utility programs that work on files, like ls, cat, grep, etc.

              Does that mean that I can do a cp /proc /proc2 to turn my single-core processor into a dual-core? Somebody should tell Intel and AMD that it was that easy.

              Ohhh. The fun I could have copying the stuff in /dev. How many hard drives do I want...

              • by BobPaul ( 710574 ) *

                Does that mean that I can do a cp /proc /proc2 to turn my single-core processor into a dual-core?

                /# cp /proc /proc2
                cp: omitting directory `/proc'

                No. But /proc is a filesystem

                /# mount
                /dev/sda5 on / type ext3 (rw,errors=remount-ro)
                proc on /proc type proc (rw,noexec,nosuid,nodev) ...

                And I can get a snapshot of the contents of that filesystem

                /# cp -r /proc /proc2

                although a few files fail due to permissions, etc.

                Ohhh. The fun I could have copying the stuff in /dev. How many hard drives do I want...

                No, because the hardware does not exist because the file exists, rather the file is present because the hardware is present. cat /dev/random > /dev/hda is a good way to fill your dr

          • Windows registry is a heirarchical database. I guess we can call it one gigantic file if we want to.
      • Re: (Score:3, Insightful)

        by fimbulvetr ( 598306 )
        I can treat everything in proc like a file. Like cpuinfo, or net/arp or THM/temperature. I can echo things into them to change processor speeds, networking options, etc.

        Slightly more managable? You show me one time when proc corrupted simply by "being there" in a stable kernel and I'll give that assertion to you.
    • by Ant P. ( 974313 )
      Plan 9 is an OS based entirely on files. *nix is not. `ls /dev | grep eth0` for an example.
      • by Intron ( 870560 )
        That's because you can't open the ethernet device for reading/writing. If you could, it would have a /dev/node.

        The people trying to ruin Linux are the Gnome folks doing gconf, which is basically a rehashed Windows registry.
        • by init100 ( 915886 )

          The people trying to ruin Linux are the Gnome folks doing gconf, which is basically a rehashed Windows registry.

          Except that it is based on a set of XML files rather than a binary blob database.

    • by Anonymous Coward on Thursday April 19, 2007 @10:05PM (#18807529)
      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.
      • by init100 ( 915886 )

        You can just mv /home/dummy/program to /home//program. Everything will (should, really) continue to work.

        I doubt that they do if the program depends on its own shared libraries, i.e. shared libraries that resided in /home/dummy/program/lib. Paths to shared libraries are often (always?) hard-coded into the program binary. Thus, in such a case, just moving the program directory hierarchy would probably not work. There are of course workarounds, such as using LD_LIBRARY_PATH, but you may not want to use such a method to run all of your privately installed programs.

  • by 8-bitDesigner ( 980672 ) on Thursday April 19, 2007 @07:59PM (#18806483) Homepage
    I was in a similar situation about a year ago, and I found that the best way to learn about the guts of the system, so to speak, was to pick up Gentoo [gentoo.org], which is something of a "Roll your own" kind of Linux distribution.

    Now, by no means do I recommend this for day to day use. I love Gentoo, but it breaks. Frequently. And unless you know a fair bit about how the system works, you'll end up breaking it quite often yourself. This is a good thing, and introduces you to the various configuration files, locations of critical items, how everything slots together, and how to compile your own kernel. The Gentoo documentation is excellent, and if you go about it with a certain goal in mind (web server, router, media center) you'll end up learning a fair bit about Linux in the process.
    • by nschubach ( 922175 ) on Thursday April 19, 2007 @08:09PM (#18806557) Journal
      LFS [linuxfromscratch.org] (Linux From Scratch) is another way.

      Honestly though, like stated above, once you understand that Linux basically treats everything like a file... you can fix pretty much anything. As far as a good reference or tips site. Google [google.com]. 99% of the time, a quick cut and paste of an error will direct you to the right place. (That is if you don't understand it right away.)
    • by moexu ( 555075 )
      I would also recommend Gentoo. I used Mandrake for 2 years when I first started with Linux. It was a nice distro and everything just worked, but I didn't think I was really learning anything since I didn't have to mess with it. I tried Gentoo out and felt that I learned more in the first week trying to get it installed than I had in my previous 2 years of Mandrake. Another even more hardcore route to go would be installing Linux from Scratch [linuxfromscratch.org].

      Aside from distro forums and Google I've found a couple of books
      • Re: (Score:2, Interesting)

        Running Linux is one of the best books for learning the overall structure of systems. Matt even notes the basic exceptions between Slackware and most other core distros in terms of structure and processing.
        Indispensible.
      • My problem with Gentoo is that I could never get to a point where it was usable within a reasonable amount of time. I found it extremely frustrating going from Mandriva to Gentoo. In the end, they are all just as configurable. So I don't really see why I should go through the trouble of getting Gentoo to work. You can still mess around with the system just as much in Mandriva as you can in Gentoo. I don't really see the reason it should be hard to install a distro. They can't make it easy to customize
        • by moexu ( 555075 )
          If ease of install is high on your priority list then I wouldn't recommend Gentoo. Something like Mandriva or Ubuntu would be much better - with those you just stick in the disk, click Next a couple of times, wait about 20 minutes, and you're done.

          I liked Mandrake. It recognized more hardware than any other distro I'd used, and it was so easy to deal with that it was a nice gentle introduction to Linux. But after using it a while I wanted to try something else where I could learn a little bit more about
    • Re: (Score:3, Interesting)

      by bersl2 ( 689221 )
      While I agree that the Gentoo documentation is excellent, I can't say I liked the distribution. Maybe if I were to have installed it myself from scratch, instead of having inherited an installation, I might have understood why stuff broke as often as it does. But my one experience with Gentoo was on a production machine, and the first time I tried to update the system, the mailing system broke.

      My own advice to the submitter is to go between Gentoo and LFS with respect to automation and below both with respe
      • by mollymoo ( 202721 ) on Thursday April 19, 2007 @09:58PM (#18807483) Journal
        Gentoo breaks as often as it does because portage's handling of dependancies is a bad joke. Actually, I don't know if it's portage itself or poor quality ebuilds, but "emerge --update world" breaks for me about 40% of the time (no, I'm not running the unstable ~x86). I'm not shitting you when I say it took me three days to bring a box which hadn't been updated for four months up to date. That wasn't all compile time, the damn thing just kept stopping. Portage apparently didn't know it would break before it started, despite the problems all being related to dependancies.

        When it breaks, portage doesn't tell you why, you basically have to search the Gentoo forums for an answer. In the inevitable thread(s) related to the problem I often find a response from a dev which says that you need to update X and Y together, so both X and Y block each other. Having the package management system manage packages for you is evidently too much to ask.

        I do like Gentoo's arrangement of config files etc. though. It's nice to work with, just shitty to update.
        • by harryman100 ( 631145 ) on Friday April 20, 2007 @05:49AM (#18809723) Homepage

          I'm not shitting you when I say it took me three days to bring a box which hadn't been updated for four months up to date.
          In my experience, updating a gentoo box infrequently is a bad idea. You should either update every week/month or not at all. The way I look at it, you either want a system with the latest everything, or you want a system which works. If you want the first, you should expect to spend a bit of time working on it. If you want the second - why on earth are you updating every four months.

          If I wanted a system to be stable, but not that far behind current stuff. I'd probably be updating once a year - you have to do a bit of work to fix some of the updates, but at least you only have to do it once a year.

          On the other hand, if I wanted a system that's always up to date, I'd be updating every other week. This is what I currently do on my two gentoo boxes, and I've very rarely had problems. (The last problem I had was when it upgraded mysql from 4 to 5, some of the defaults changed - I spent ages trying to work out why I couldn't connect from other machines.)

          One thing to note, if you're having problems when updateing world add the --deep flag to emerge, it will update all libraries that need it as well. Then follow the emerge with a revdep-rebuild, to check for things that have been broken by updated libraries (and fix them)
          • In my experience, updating a gentoo box infrequently is a bad idea. You should either update every week/month or not at all. The way I look at it, you either want a system with the latest everything, or you want a system which works. If you want the first, you should expect to spend a bit of time working on it. If you want the second - why on earth are you updating every four months.

            The box was previously updated frequently precisely because falling behind causes grief, but had lain unused for four month

          • In my experience, updating a gentoo box infrequently is a bad idea. You should either update every week/month or not at all.

            Then the Gentoo people ought to make it easy to have that happen automatically, so that I don't have to manually log in and do it all the time!

            • Updateing without you knowing is a bad idea, on any operating system. But surely if you wanted to you could write a cron job which did it?

              What would be nice is if you could pass a flag to emerge to only compile packages, not fully merge them. (You can already tell it to do fetch only)

              That way, I could have an weekly script which downloaded and compiled all new packages, and then I could actually merge them when I was concentrating on what was happening (Ready to fix any issues). This would reduce the amount
              • Updateing without you knowing is a bad idea, on any operating system.

                I never said it couldn't notify me (e.g. by email), only that I shouldn't have to manually initiate it. The operating system is supposed to be "stable" (unless I was using ~, of course), so updating it shouldn't break anything.

                But surely if you wanted to you could write a cron job which did it?

                NO! See, that's the whole point of my post: as a user, I shouldn't have to write the thing myself! Instead, the Gentoo developers should write it

                • NO! See, that's the whole point of my post: as a user, I shouldn't have to write the thing myself! Instead, the Gentoo developers should write it and integrate it into Portage, so that it just gets emerged and added to the rc scripts during installation, like cron and ssh and whatnot.
                  Let me get this straight, you went through the entire gentoo installation process, and you're whinging about having to write a cron job?
                  • No, because it would have to be more than just a cron job. What it really needs to be is a script that would run emerge, dispatch-conf, revdep-rebuild, detect if the build failed and notify the user, etc. It wouldn't be a huge piece of software, but it wouldn't be trivial.

          • by jimicus ( 737525 )
            In my experience, updating a gentoo box infrequently is a bad idea. You should either update every week/month or not at all. The way I look at it, you either want a system with the latest everything, or you want a system which works. If you want the first, you should expect to spend a bit of time working on it. If you want the second - why on earth are you updating every four months.

            Not to sound too much like an AOL weenie, but you're absolutely right.

            I inherited a bunch of gentoo boxes, and I've kept every
    • by iabervon ( 1971 )
      I've actually had the opposite experience with Gentoo. I've done all sorts of wrong things with it, and had all sorts of things wrong, and the system has continued working perfectly despite that. (The main exception being qmail, which never fails to be running, but doesn't necessarily, you know, deliver mail.)

      It's often difficult to get things built and configured the way you want (what, I need the xml USE flag for php for this? Time to rebuild it... And I need to hand-edit an apache config file to have a h
  • Three letters (Score:3, Interesting)

    by i_should_be_working ( 720372 ) on Thursday April 19, 2007 @08:03PM (#18806511)
    LFS [linuxfromscratch.org]
  • Linux from Scratch (Score:4, Insightful)

    by jomas1 ( 696853 ) on Thursday April 19, 2007 @08:05PM (#18806521) Homepage
    Check out http://www.linuxfromscratch.org/livecd/ [linuxfromscratch.org] and http://www.linuxfromscratch.org/lfs/ [linuxfromscratch.org]

    Try creating a distro of your own and you should get a handle on the mysteries of the OS. If you don't have spare hardware check out virtualbox.org and try creating your lfs distro on a virtual x86 computer
    • Re: (Score:3, Insightful)

      by cyphercell ( 843398 )
      The first time I went through LFS I purchased the book. I think it probably saved me a week or two. Also, I use LFS primarily as a sandbox, if I want to test something I use LFS, when I need to get some work done I currently use Debian. I feel it is absolutely imperative for a desktop system to be somewhat dependable. Go ahead and break your LFS system, reiterate over your LFS system several times experiment with package management, configurations, bootscripts, break it, fix it, and customize it. Currently
      • P.S. OSS is usually a moving target, in that it actually gets updated and things change, avoid "new" unless you need it, stay in the package tree. Use OSS and I'm saying this from a pragmatic view. Review hardware against your kernel, version of X, desktop environment, and your distribution. Make sure there's accurate documentation if you get into trouble, prefer hardware that releases their specs. Ask questions and go to a Lug meeting every once in a while. Buy Crossover office, don't try messing with Wine
  • Break It. (Score:5, Informative)

    by Tragek ( 772040 ) on Thursday April 19, 2007 @08:05PM (#18806523) Journal
    I've learnt oodles about all OSs by breaking them. Delete something. see how it changes the behaviour of the system. If it was somethign really important, you'll learn about system recovery, otherwise, trouble shooting.

    I'm serious.
    • Amen (Score:3, Insightful)

      by matt me ( 850665 )
      If it ain't broke, break it. Fix it. Understand it.

      Here's some things to try:
      Compile mplayer. Build a firefox package for your distro. Download, patch and compile a kernel. Add a cronjob to delete some files at random. Forget about it. Try and restore them. (ext2 does not delete file pointers in inodes). Create an LVM group. Siphon disk space between disks and partition. Try a file system written by someone suspected of murder. Post on a linux-devel list and join Linus in slagging off Gnome. Try KDE and XFC
  • by PAPPP ( 546666 ) on Thursday April 19, 2007 @08:08PM (#18806551) Homepage
    Really. Just use it. Like many other things, the best way to become familiar with Linux is to use it for your daily tasks for a while, and find out how to fix any problems you run into. I've used a dual-booted machine for some time, and about 6 months ago I made the decision to switch my main OS over from WinXP to Linux, and relitively painlessly went from dabbling to a being well versed pro user in a few months.
    • Re:Use it. (Score:4, Funny)

      by DaveCar ( 189300 ) on Friday April 20, 2007 @05:29AM (#18809639)
      Err, he stated:

      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.

      Now I know it is de rigeur not to read the article, but there wasn't even an article to read here - did you even read the question?

      • by MadJo ( 674225 )
        You must be new here.

        The current MO is to read just the subject line and then skip right to the comments.
        • by DaveCar ( 189300 )

          Damnit, I've been wasting all that time reading the summary?

          No wonder I don't get any first posts :(
  • No one answer. (Score:4, Insightful)

    by normuser ( 1079315 ) * <normuser@whyisthishere.com> on Thursday April 19, 2007 @08:09PM (#18806553) Homepage Journal
    I dont have one magic answer.
    Forums are good for getting and sharing information on specific problems as long as the "google it yourself" crowd havent invaded. (how else would you have found the forum?). http://www.linuxquestions.org/ [linuxquestions.org] is a good start.
    There are varias wiki's specific to certian subjects.
    And I dont mean to sound rude with this, but please read the man page first. Weather or not you understand it at the time.

    On a side note the best way I have found to learn about something is to break it first. but maybe thats just me.
    • From time to time I'll visit http://librenix.com/ [librenix.com], a "linux tutorial" aggregator site where people collect various tips about Linux and its various applications. This is often how I will hear about various applications, methods to secure your computer, tricks for administering Linux, etc. For example, as of this writing, among the first page list of articles we have a tutorial on installing VirtualBox in Linux, emacs essentials, how to install dual monitors, etc. Most articles are good, although the styl
    • I agree, linuxquestions.org is a great resource, but first you have to be breaking stuff to find it useful. Sooo...

      Install Gnome, KDE, XFCE, Fluxbox, and a bunch of other desktop related apps, upgrade your nVidia drivers, add Beryl, and really start trashing your /etc directory to see stuff break. Then go to linuxquestions.org or another resource online by copy-pasting your various error messages to start learning more about how to troubleshoot and find out what's screwing things up in your system. I'm no
  • Wiki (Score:2, Informative)

    by Shinsei ( 120121 )
    I have found that http://gentoo-wiki.com/ [gentoo-wiki.com] is a great resource for knowledge about the basesystem itself of Linux. I do love my Gentoo of course, but you'll find resources on said wiki for Linux in general - and quite a few of them - and I've seen people from both the Debian and Ubuntu community also look to this Wiki from time to time.
  • SOme input (Score:3, Informative)

    by TheRealMindChild ( 743925 ) on Thursday April 19, 2007 @08:25PM (#18806693) Homepage Journal
    Here is what I got, take it for what it is worth.

    See 'man Linux Filesystem Hierarchy'. In case for some reason that doesn't work on your system, here is a link -> http://tldp.org/LDP/Linux-Filesystem-Hierarchy/htm l/ [tldp.org]
  • heres a few (Score:3, Interesting)

    by drfrog ( 145882 ) on Thursday April 19, 2007 @08:26PM (#18806703) Homepage
    http://tldp.org/ [tldp.org]

    this is the linux doc proj the one place i found indispensable while learning slackware back in the day

    lately http://www.debuntu.com/ [debuntu.com] is a god send as well

    and of course , unlike windows software, most linux software readme files are actually filled with useful information

    othjer than that either a quick google on a specific question or jump onto irc will usually get you some help

  • Do what I did (Score:4, Insightful)

    by stinerman ( 812158 ) on Thursday April 19, 2007 @08:31PM (#18806755)
    I fancied myself a Windows "power user" and then GNU/Linux was foisted upon me because of a hardware crash. My backup system wasn't good enough to run XP, so I tried Red Hat 9. It certainly was a bitch, but I leaned GNU/Linux by doing the same thing I did when I was learning Windows: poke and prod at the system and see what changed. Doing is the best way of learning.

    Don't really worry too much about a specific distro. I went from RH9 to Fedora Core to Ubuntu to Debian over the span of about 4 years. Once you learn enough, you can pick up any distro without too much hassle.

    My best advice is to pick a distro and dual boot with XP/Vista. Every day try to use your GNU/Linux distro a bit more each day. Be sure to try to fiddle with settings. Just make sure you have a backup ready for any important data. For awhile there, I was reinstalling the OS weekly. Don't be afraid to experiment.
  • by Ivan Raikov ( 521143 ) on Thursday April 19, 2007 @08:48PM (#18806909) Homepage
    First of all, you should have in mind that Linux is just a kernel, and what you are probably more interested in are all the userland programs that comprise your typical Linux distribution. I think it is best to start with a general Unix introductory text, because the fundamental principles have not changed in 25 years, and it is much better to understand the core Unix system utilities and how they plug together to accomplish complex tasks, rather than waste time with all the modern Windows-like interfaces that are fashionable in Linux distributions today.

    There is one "classic" Unix introduction book that I can strongly recommend, and that you can probably buy used for a dollar: Exploring the Unix System [amazon.ca] by Stephen Kochan and Patrick Wood. Make sure to get the paperback edition that is about 400 pages. Also, apparently the authors are going to release an updated version of that book -- check http://www.kochan-wood.com [kochan-wood.com] for updates.

    Once you learn the fundamentals of Unix systems, then you would be ready to learn the modern tools available in Linux distributions. Remember that is much more important to learn the principles and philosophy that Unix was built upon, rather than attempting to memorize arcane details.
  • by SadGeekHermit ( 1077125 ) on Thursday April 19, 2007 @09:07PM (#18807041)
    Your best bet is to start with Slackware 11, it's a manual distribution which will force you to actually get involved with it and learn how things work under the hood.

    For example, you have to write your own iptables firewall script. But by doing this, you'll be able to understand the output of "iptables --list" on any distro out there and see what it's doing behind the scenes (for instance, amusingly, what holes does it leave open if any?).

    You can download the distro here, for free:
    http://www.slackware.com/ [slackware.com]
    (my favorite mirror is: http://slackware.cs.utah.edu/pub/slackware/slackwa re-11.0-iso/ [utah.edu])

    There's a good book on it available here: http://www.slackbook.org/ [slackbook.org]

    Think of it this way (using a car analogy like the other guy, but more seriously):

    If you learn to drive in a car with a five speed stick and a clutch, you'll be able to drive almost any wheeled vehicle on Earth with very little futzing around. It's almost like having a superpower.

    But if you start out driving an automatic, you'll ONLY be able to drive automatic until somebody teaches you manual. And you won't have any reason to learn it, so you'll miss out on a potentially important skill.

    It's better to start out with something challenging and switch to the easy stuff later.

    Go Slackware, be a nerd like us! You'll thank me later.

  • by dru ( 4742 ) on Thursday April 19, 2007 @10:08PM (#18807555)

    When I was learning about Linux, back in the mid-90s, the most valuable resource I found was The Internals of the 4.3BSD Operating System by McKusick, Quarterman, Leffler and Karels. This book acquainted me with the design goals of unix-like operating systems, and the issues of implementing these patterns.

    Also, I'd pick either Aileen Frisch's Essential System Administration or UNIX System Administration Handbook by Evi Nemeth.

    Fast forward to the 21st century, I now spend the bulk of my time using FreeBSD.

    Linux is great, but remember that the thing that makes it great is that it's a unix-like OS. Learning the skills to be comfortable on Linux, Solaris, *BSD, HP-UX, AIX, or whatever the flavor of the day, will take you further than limiting yourself to just one.

    Good luck!

  • Linux From Scratch [linuxfromscratch.org]. This is a project which maintains and outlines the knowledge of how to manually compile a Linux system from source code. In other words, it's about as fundamental as you can get.

    The project is also run by some really awesome people...probably the most decent that I've come across in the Linux community.
  • Just read this (Score:3, Interesting)

    by swillden ( 191260 ) * <shawn-ds@willden.org> on Thursday April 19, 2007 @11:39PM (#18808261) Journal

    There are probably some good books out there, and I hope you get some recommendations for them, but there is one key thing that you should learn about Linux that will get you 99% of everything you'll ever need to know about how your system works: How it boots.

    If you understand how everything gets started you'll understand how it all fits together, and, even better, you'll have the starting point you need for tracking down anything else you need to figure out. And the great thing is that it's simple enough to described reasonably completely in one brief slashdot post.

    The boot process consists of the following steps:

    1. The boot loader loads the kernel
    2. The kernel mounts the root file system and finds and runs /sbin/init, the first userspace process
    3. /sbin/init finds and reads /etc/inittab, which tells /sbin/init what shell script to run to kick everything off (/etc/init.d/rc, usually).

    That's it. All you have to do is go read that shell script and you'll find out how absolutely everything running on your system gets started, from the file systems that are mounted to the network devices that are configured to the graphical user interface. Of course, along the way, you'll run across dozens of commands and hundreds of configuration files that you'll have to look up, but with 'man' and a little persistence you will gain an understanding of each major component, where it lives, what it does, how it gets started, restarted, killed and modified.

    Even better, you don't have to worry about understanding it all at once. Once you find the /etc/init.d/rc script, and see how it executes all of the other scripts in /etc/init.d, you'll be well equipped to track down the answer to any question you have about how your system works. Sometimes getting an answer will mean traipsing through a few levels of indirection, but all the information is there. No magic, nothing hidden, all there for your perusal and/or modification.

    • by Knuckles ( 8964 )
      Except that distros begin to migrate away from sysinit. Ubuntu uses upstart, which works differently: http://upstart.ubuntu.com/ [ubuntu.com]
      • by Knuckles ( 8964 )
        sysvinit
      • Except that distros begin to migrate away from sysinit. Ubuntu uses upstart, which works differently: http://upstart.ubuntu.com/ [ubuntu.com]

        But Ubuntu still uses init, and inittab, and /etc/init.d/rc to launch upstart, so the same starting point applies, and you can still follow the threads in the same way, it's just that they follow a different route.

        • by Knuckles ( 8964 )
          True, but that's just because they didn't get around to change it in Feisty. Originally the plan was to lose the sysvinit compatibility layer in Feisty and start to use upstart's features extensively. Sooner or later, sysvinit will go away, at least in some distros.
          • True, but that's just because they didn't get around to change it in Feisty. Originally the plan was to lose the sysvinit compatibility layer in Feisty and start to use upstart's features extensively. Sooner or later, sysvinit will go away, at least in some distros.

            None of which will eliminate init, or inittab, or the script that launches upstart. Take a look at how OS X launches launchd.

            • by Knuckles ( 8964 )
              Take a look at a Feisty install, which doesn't even have an inittab. What OSX does with launchd has little effect on what ubuntu does with upstart.
            • None of which will eliminate init, or inittab, or the script that launches upstart.

              I have to correct myself. upstart does indeed replace init. That doesn't invalidate my suggestion, though, it just changes it. On Ubuntu the thing to do is to dig through your upstart configuration file and the scripts that it runs. There's still no magic, and you can still use it as the starting point to understand how everything on your system fits together.

              • by Knuckles ( 8964 )
                That's why I implicitly agreed to your post, "except" for the fact that increasingly it isn't sysvinit :)
  • Well, for starters, never forget two things:
    • even if it's not documented, you _have_ access to the source
    • even if you do not have time to access/read the source, the problem are usually in the open, generally discussed by someone else you could easily locate. If you are the first one, someone is usually going to answer you.

    On linux, most of the configuration is done in _text_ files, and most of the system set-up is done by sh/bash shell script. Get familiar with shell scripting (it's a minimal requirem

  • Is to take a class at your local college or University. That's better than any book you could buy or forum you could visit. It really makes you process and apply what you learn, as well as making sure your education is well rounded. The UNIX classes at my college have no prereqs, and cater to career professionals in atmosphere, attitude, and availability and applicability. I'm sure you can do just as well if you take a look.
  • Books (Score:4, Insightful)

    by Knuckles ( 8964 ) <knuckles@@@dantian...org> on Friday April 20, 2007 @01:28AM (#18808851)
    BOOKS:
    Essential System Administration By Æleen Frisch
    http://www.oreilly.com/catalog/esa3/index.html [oreilly.com]

    Unix Power Tools By Shelley Powers, Jerry Peek, Tim O'Reilly, Mike
    Loukides
    http://www.oreilly.com/catalog/upt3/index.html [oreilly.com]

    Running Linux By Matthias Kalle Dalheimer, Matt Welsh
    http://www.oreilly.com/catalog/runlinux5/index.htm l [oreilly.com]

    The UNIX Systems Administration Handbook by Evi Nemeth, Garth Snyder,
    Scott Seebass, Trent R. Hein, et al.
    http://www.amazon.com/UNIX-System-Administration-H andbook-3rd/dp/0130206016/ref=pd_bxgy_b_text_b/104 -2587738-8696715?ie=UTF8&qid=1176522696&sr=1-1 [amazon.com]

    The Practice of System and Network Administration by Thomas A.
    Limoncelli, Christine Hogan
    http://www.amazon.com/Practice-System-Network-Admi nistration/dp/0201702711/ref=pd_sim_b_4/104-258773 8-8696715?ie=UTF8&qid=1176522696&sr=1-1 [amazon.com]

    Martin F. Krafft: The Debian System: Concepts and Techniques
    http://debiansystem.info/ [debiansystem.info]

    Benjamin Mako Hill, Jono Bacon, Corey Burger, Jonathan Jesse, Ivan
    Krstic: The Official Ubuntu Book
    http://www.amazon.com/Official-Ubuntu-Book-Benjami n-Mako/dp/0132435942 [amazon.com]
  • by Eggplant62 ( 120514 ) on Friday April 20, 2007 @01:38AM (#18808903)
    Find and join your local Linux Users Group. Start here on GNU.org's List of Linux User Groups and see what you can find. Most of everything I know from Linux is either: [gnu.org]

    1. What I learned from my local LUG
    2. What I learned from my best friend, the Linux Guru
    3. What I learned from reading a multitude of books and websites
    4. Through classwork at the local business college with a Linux-friendly IT program

    Interact with people who know about Linux. Ask questions. Read HOWTOs. Get reference books and read them.
  • Tools are the key (Score:5, Informative)

    by simm1701 ( 835424 ) on Friday April 20, 2007 @02:59AM (#18809155)
    The real key to unix (any unix) is knowing how to use the tools that you get installed with the OS to make your life easier.

    First things first is the terminal (xterm, kterm whichever it doesn't matter) use it. Forget the GUIs, use the shell.

    That brings us onto the shell itself. Pick one and stick with it for a while. On linux most people prefer bash, its a good choice as even though its not on all unixes by default its not difficult to obtain (just don't try to set the root users default shell to bash on solaris)

    Learn the language of the shell, pipes, redirects, command line interpretation of special characters, handy tricks like tab complete, loops, variables, tests and use these all on one liners - progress to script files and also learn about functions - shell scripts are usually going to be fairly primitive tasks but they are the key to an easy life as an admin.

    Man is your friend - and should always be the first place you turn for help, then google, then forums.

    Learn the basic commands, ls, mv, cp, rm, learn their options and understand the justifications for using them (-i? -f?)

    Pick an editor and learn to drive it - this is a long process but well worth it. Don't bother with a GUI one, consider that later. On a default linux install you will probably have vim and emacs - try them both, see which you like and use it. Check out guides on how to customise them until they behave just how you want them (I have a 10 line .vimrc file I can create from memory that makes vi behave just as I like) - ok yes vim != vi, but to shock vi purists I like to be able to use the cursor keys while in insert mode!

    learn atleast the basics of the other important tools - at the very least find and grep. Awk and sed should certainly be on the list as you will encounter many scripts that use them, atleast some basic knowlege of perl would be handy (I prefer to use perl instead of awk and sed but thats my preference not everyone would agree)

    Set up services and experiment, run a webserver, database server, mail server and learn as much as you can stand to about iptables to secure your box.

    Keep backups, don't be afraid to break things, fixing what you broke (after finding out what you did to break it) is some of the best education yuo can have

    All in all

    Have fun!!
    • Great advice by the parent post. In particular, learn the basics of vi/vim (or emacs) ASAP. Next (or concurrently), write some simple shell scripts. This will force you to learn some CLI tools. Use "man" extensively. Near the bottom of most man pages are lists of related commands, which is a good way to find new tools.

      In addition to the previously noted CLI tools, spend some time learning how to use the "find" command. The -exec option of the "find" command is a powerful way to perform a task on a lar
      • Ah yes almost forgot to mention screen - I take it far too much for granted these days.

        Also never under estimate the usefulness of screen -x

        (if you never tried it then do so, open up 2 xterms, start screen normall in on, and run screen -x in the other, 2 xterms, 1 set of shared screen sessions)
  • How Linux Works [nostarch.com] describes the inside of the Linux system for systems administrators,
    whether you maintain an extensive network in the office or one Linux box at home.

    Some books try to give you copy- and-paste instructions for how to deal with every
    single system issue that may arise, but How Linux Works actually shows you how the
    Linux system functions so that you can come up with your own solutions.

    After a guided tour of filesystems, the boot sequence, system management basics,
    and networking, author Br

  • Go back in time, and get a copy of the LFS howto/book when it was in its infancy - version 1.1 or so ought to do... Very well documented, but you do it and you learn it.
  • Your question is a bit vacuous .... what do you want to achieve?

    Anyhow, have you tried installing something like dvd::rip (or a LAMP environment or KDE) from scratch - ie download the source code, configure-make-and-compile and fix any problems along the way.

    You can consider with dvd::rip you've been successful when you rip a section of dvd with sub-titles and burn it to a CD that runs in your dvd player (or eg for LAMP, you're serving a DB driven site, like a CMS, from your own box).

    IIRC dvd::rip gave me p
  • And don't resort to any other operating system to do things unless it's a matter of life and death, or job and no job, or some other such decision which should be easy to make. And get some more machines and just play with the things you want to play with. Set up some competing types of VPN. Set up distcc, with cross compilers if you are on different architectures. Actually accomplishing real tasks will do more to teach you how to solve problems than anything else you can possibly do.
  • When I was first getting into Linux, I picked specific things that I wanted to learn to do, and focused on those. How do I setup a DNS server? RADIUS? DHCP? MySQL? I find it a bit easier if you have a goal set when trying to learn, rather than just trying to "learn more" about the system. During the course of working on these services, you'll learn more about the system. The secret is to not try to do the simplest installation/setup you can do, but the most interesting. Don't just setup RADIUS, setu
  • /etc contains all the settings /etc/init.d is like services

    In the bootmanager if you add s to the list of parameters this is like your Windows safe mode (Single user mode). /var/log contains all your logs about various things

    Running dmesg will show you what was happening at bootup.

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...