How can I become a unix super-geek?
February 10, 2005 10:13 AM Subscribe
How can I become a unix super-geek?
The internet seems full of grade-school kids who write shell scripts in their sleep and who throw
I'm probably too old for skillz, but I'd like to learn some skills.
The internet seems full of grade-school kids who write shell scripts in their sleep and who throw
grep and chown and dev/null into casual conversations. I, on the hand, can't seems to follow step-by-step instructions without getting into some kind of trouble I can't debug without help.I'm probably too old for skillz, but I'd like to learn some skills.
do you have a unix machine? do you have any programming projects? what work do you do with computers?
(there used to be a good book, with a red cover, called something like unix sysadmin handbook, that a friend of mine found useful, but personally, i just google).
posted by andrew cooke at 10:21 AM on February 10, 2005
(there used to be a good book, with a red cover, called something like unix sysadmin handbook, that a friend of mine found useful, but personally, i just google).
posted by andrew cooke at 10:21 AM on February 10, 2005
I'd just get an old box out of the closet, install linux, and start to come up with kooky projects to see if you can make 'em work. Eventually, it'll all start to make sense... at least that was my experience. (Not that I'm unix super-geek or anything, but I do alright...)
posted by ph00dz at 10:31 AM on February 10, 2005
posted by ph00dz at 10:31 AM on February 10, 2005
Similarly, I do not have skillz, but I do have some skills. It was a pretty straightforward process: I had some work to do that had to get done asap and so someone recommended UNIX for the Impatient. I did the work and now, I mostly use this unix cheat sheet from sloppycode when I forget something.
posted by safetyfork at 10:33 AM on February 10, 2005
posted by safetyfork at 10:33 AM on February 10, 2005
The best way to get better is to learn how to debug properly. Being a Unix uber-geek with the shell is really equivelent to learning how to program with shell scripting. So read the bash manuals, read the documents on the programs you are using.
If a script or command doesn't perform the way you expected, the first step is to always decompose it into simplier statements. For example, suppose I want to reset the permission on all my directories, but leave the files alone. My first attempt might look something like: "find . -exec chmod u=rwx,g=,o= {} \;" but that doesn't work. So next I try "find . -exec echo {} \;" and I see that I'm listing files along with the directories! Opps, forgot the "-type d" option. Now this works: "find . -type d -exec chmod u=rwx,g=,o= {} \;". And if all else fails, Google for the error message. Trust me, at least one person out there has had a similar problem.
Alright, that was a silly example. But you get the idea. You can't learn this stuff quickly; it requires a lot of effort and reading of boring docs. But if you stick with it, you too can be an uber-geek.
<rant>
As an aside, I'm surprised at the number of people who call themselves "programmers" but can't debug worth shit. They get some error messages and they throw their hands up in disgust. Next thing you know they're randomly changing lines in their programs until they find a combination that works. For the love of God, stop doing that. The first step is to understand what is wrong, and only then do you try to fix it.
</rant>
posted by sbutler at 10:38 AM on February 10, 2005
If a script or command doesn't perform the way you expected, the first step is to always decompose it into simplier statements. For example, suppose I want to reset the permission on all my directories, but leave the files alone. My first attempt might look something like: "find . -exec chmod u=rwx,g=,o= {} \;" but that doesn't work. So next I try "find . -exec echo {} \;" and I see that I'm listing files along with the directories! Opps, forgot the "-type d" option. Now this works: "find . -type d -exec chmod u=rwx,g=,o= {} \;". And if all else fails, Google for the error message. Trust me, at least one person out there has had a similar problem.
Alright, that was a silly example. But you get the idea. You can't learn this stuff quickly; it requires a lot of effort and reading of boring docs. But if you stick with it, you too can be an uber-geek.
<rant>
As an aside, I'm surprised at the number of people who call themselves "programmers" but can't debug worth shit. They get some error messages and they throw their hands up in disgust. Next thing you know they're randomly changing lines in their programs until they find a combination that works. For the love of God, stop doing that. The first step is to understand what is wrong, and only then do you try to fix it.
</rant>
posted by sbutler at 10:38 AM on February 10, 2005
UNIX for the Impatient is supposed to be pretty helpful... of course, that's what the co-author, my girlfriend's dad, said. So don't take my word for it, take his.
posted by piro at 10:39 AM on February 10, 2005
posted by piro at 10:39 AM on February 10, 2005
i dont know how you could force yourself to become a unix super geek. i know my unix geek status grew out of being the only person at my work to have the initiative to try to tackle our unix webserver and having to deal with all sorts of problems with no help.
you should get yourself a sandbox environment for sure, something like vmware that gives you easily destructable restorable virtual machines within another OS, another option is knoppix-like boot from CD linux distros.
you can also run cygwin to get some unix tools available to you on the windows command line to get used to the syntax.
posted by yeahyeahyeahwhoo at 10:40 AM on February 10, 2005
you should get yourself a sandbox environment for sure, something like vmware that gives you easily destructable restorable virtual machines within another OS, another option is knoppix-like boot from CD linux distros.
you can also run cygwin to get some unix tools available to you on the windows command line to get used to the syntax.
posted by yeahyeahyeahwhoo at 10:40 AM on February 10, 2005
If you have Windows and don't want to set up an old box for Linux, cygwin is basically Unix within Windows. Note that the default install doesn't include a lot of the tools considered essential to Unix, like the gcc compiler, make, etc. You have to specify that you want to install them in the setup process. To add them or others later, just run the setup.exe over and pick what you want.
posted by zsazsa at 10:40 AM on February 10, 2005
posted by zsazsa at 10:40 AM on February 10, 2005
This is simple. Just simulate the environment those kids are in.
Set yourself a $0 hardware and software budget and get rid of all of your electronics. Hit your parents or some friends up for a computer; if you're lucky you'll get something nice, but you'll probably end up with something a couple years old with some quirks. Leech some CD-Rs. Get a broadband connection. If you want the real experience, hit a local community college for some compsci courses.
Within 3 months, you will know UNIX. It's simply the best economic choice for your situation, because it's free and stable on older, crappy hardware. Because you don't have a better option (Macs are expensive, copying Windows is not only illegal but will also thrust you back into the realm of spyware and instability), you'll be forced into playing with different distros and apps to get the computer to work the way you want it to, and while you do that, you'll find your skillz increasing as you get stuff to work. Stuff won't work, you'll get into trouble, you'll wonder "how do I do this?", you'll ask for help, you'll find out, you'll start to see the patterns, and it'll be a good learning experience.
The alternative to this is to get a job that requires you use UNIX; operator and support jobs are a good place to start if you're not a coder.
People with those UNIX skills don't develop them overnight. No, wait, they *do* develop them overnight. They develop them because they're up all night excitedly trying to get a device to work, or, perhaps, troubleshooting a server farm at work. That may sound dismissive, but it's really not -- people get to know the low-level command line stuff because they're driven to get something to work that wouldn't without that kind of intervention. It's one of the the main reasons open-source programmers code. Other people are in it for the money. (All the IT workers on AskMe suddenly ask "What money?")
Ignore the Mac OS X comment. Ignore the people saying to set up a second box. Mac OS X has a UNIX back-end, but unless you're a developer, you never really *need* to touch it -- so you won't *learn* it, unless you're atypically curious. You're discouraged from tweaking the system in Mac OS (even with the presence of X11 and Terminal.app), and you spend more time with the apps -- and I don't think that's quite what you're looking for. If you set up a second box, again, unless you're really curious or have some other sort of economic motivation, you'll just use what you're familiar with.
Also, hanging around UNIX fans. Also, O'Reilly books.
posted by eschatfische at 10:43 AM on February 10, 2005
Set yourself a $0 hardware and software budget and get rid of all of your electronics. Hit your parents or some friends up for a computer; if you're lucky you'll get something nice, but you'll probably end up with something a couple years old with some quirks. Leech some CD-Rs. Get a broadband connection. If you want the real experience, hit a local community college for some compsci courses.
Within 3 months, you will know UNIX. It's simply the best economic choice for your situation, because it's free and stable on older, crappy hardware. Because you don't have a better option (Macs are expensive, copying Windows is not only illegal but will also thrust you back into the realm of spyware and instability), you'll be forced into playing with different distros and apps to get the computer to work the way you want it to, and while you do that, you'll find your skillz increasing as you get stuff to work. Stuff won't work, you'll get into trouble, you'll wonder "how do I do this?", you'll ask for help, you'll find out, you'll start to see the patterns, and it'll be a good learning experience.
The alternative to this is to get a job that requires you use UNIX; operator and support jobs are a good place to start if you're not a coder.
People with those UNIX skills don't develop them overnight. No, wait, they *do* develop them overnight. They develop them because they're up all night excitedly trying to get a device to work, or, perhaps, troubleshooting a server farm at work. That may sound dismissive, but it's really not -- people get to know the low-level command line stuff because they're driven to get something to work that wouldn't without that kind of intervention. It's one of the the main reasons open-source programmers code. Other people are in it for the money. (All the IT workers on AskMe suddenly ask "What money?")
Ignore the Mac OS X comment. Ignore the people saying to set up a second box. Mac OS X has a UNIX back-end, but unless you're a developer, you never really *need* to touch it -- so you won't *learn* it, unless you're atypically curious. You're discouraged from tweaking the system in Mac OS (even with the presence of X11 and Terminal.app), and you spend more time with the apps -- and I don't think that's quite what you're looking for. If you set up a second box, again, unless you're really curious or have some other sort of economic motivation, you'll just use what you're familiar with.
Also, hanging around UNIX fans. Also, O'Reilly books.
posted by eschatfische at 10:43 AM on February 10, 2005
1) Find a Solaris box.
2) Type "man man".
3) Enjoy.
*****************
Or check your local university's extension offerings. The UNIX classes are usually solid.
Also, there are Unix Users Associations and Linux User Groups comprised of people who will often not act with complete derision toward those new to *nix.
posted by gramschmidt at 10:45 AM on February 10, 2005
2) Type "man man".
3) Enjoy.
*****************
Or check your local university's extension offerings. The UNIX classes are usually solid.
Also, there are Unix Users Associations and Linux User Groups comprised of people who will often not act with complete derision toward those new to *nix.
posted by gramschmidt at 10:45 AM on February 10, 2005
Best answer: I see that you're a Mac guy. That's good. As Alex pointed out, it's much easier to approach UNIX from the Mac side than Windows.
UNIX in a Nutshell is a great, great book. If you can understand installing Ruby, you're tech enough for it. Here's some general advice:
- Learn Pico first, then vi. Don't let anyone convince you to try vi first. Both are installed on your Mac.
- Learn how UNIX permissions work, and how to change them. Ditto groups.
- Install XCode, which gives you gcc and make, among other things. You've probably already done this in your Ruby quest, but understanding how to "configure" and "make" a project from source are key.
- Read MacOSXHints. A lot of stuff there involves UNIX-y stuff on the Mac.
Remember: UNIX is completely logical, but very exacting. So, the bad news is that you'll fail often. The good news is that you can always figure out why.
posted by mkultra at 10:45 AM on February 10, 2005
UNIX in a Nutshell is a great, great book. If you can understand installing Ruby, you're tech enough for it. Here's some general advice:
- Learn Pico first, then vi. Don't let anyone convince you to try vi first. Both are installed on your Mac.
- Learn how UNIX permissions work, and how to change them. Ditto groups.
- Install XCode, which gives you gcc and make, among other things. You've probably already done this in your Ruby quest, but understanding how to "configure" and "make" a project from source are key.
- Read MacOSXHints. A lot of stuff there involves UNIX-y stuff on the Mac.
Remember: UNIX is completely logical, but very exacting. So, the bad news is that you'll fail often. The good news is that you can always figure out why.
posted by mkultra at 10:45 AM on February 10, 2005
Best answer: ph00dz got the right idea. There's a slew of Unix/Linux geek milestones that you can reach simply by trying it out: installing it (natch), getting XWindows running, compiling a kernel, configuring a network interface, connecting to a Windows network via SAMBA, rm -rf * from /, you gotta try em all.
For scripting, I've found the Advanced Bash-Scripting Guide to be the only reference I've ever needed. I taught myself from that page.
As for other Unix adminstrivia, take a look at the files in /usr/bin/ and /usr/sbin/ on any Unix box and read at least the first two paragraphs of the `man` descriptions for each of them. Small pieces loosely joined as they say, know the pieces.
Alternatively, grow a beard, wear suspenders, wait. Our agents will contact you.
posted by Loser at 10:54 AM on February 10, 2005
For scripting, I've found the Advanced Bash-Scripting Guide to be the only reference I've ever needed. I taught myself from that page.
As for other Unix adminstrivia, take a look at the files in /usr/bin/ and /usr/sbin/ on any Unix box and read at least the first two paragraphs of the `man` descriptions for each of them. Small pieces loosely joined as they say, know the pieces.
Alternatively, grow a beard, wear suspenders, wait. Our agents will contact you.
posted by Loser at 10:54 AM on February 10, 2005
Try to get Unix to solve a problem for you. Get it to reliably back up all your files on other systems. Or to process all your e-mail in some complicated way to organize it for you. Or host a website locally. I find that if you actually get something useful back from learning a new technology it keeps you motivated.
posted by Voivod at 11:08 AM on February 10, 2005
posted by Voivod at 11:08 AM on February 10, 2005
Response by poster: Wow! Thanks everyone. Lots to look at.
I should have provided more background. I have pretty good access to various unix flavours: OS X on my main home computer, FreeBSD at my web host and whatever I can get to run on an old thinkpad 390E (currently Fedora). I've got some good OS X books, including Learning Unix for Mac OS X. I've written "Hello World" programs in more languages than I can remember. I'm learning to hate Bill Gates and I already have a beard.
I guess I'll just have to roll up my sleeves and sweat.
posted by timeistight at 11:17 AM on February 10, 2005
I should have provided more background. I have pretty good access to various unix flavours: OS X on my main home computer, FreeBSD at my web host and whatever I can get to run on an old thinkpad 390E (currently Fedora). I've got some good OS X books, including Learning Unix for Mac OS X. I've written "Hello World" programs in more languages than I can remember. I'm learning to hate Bill Gates and I already have a beard.
I guess I'll just have to roll up my sleeves and sweat.
posted by timeistight at 11:17 AM on February 10, 2005
Like others, my linux/unix skills came from just wanting to do something, or having to do something, and going at it with a chainsaw. Breaking all sorts of crap along the way. Pulling hair, hating it, then loving it.
Aftera few years of this, I became pretty capable.
posted by xmutex at 11:20 AM on February 10, 2005
Aftera few years of this, I became pretty capable.
posted by xmutex at 11:20 AM on February 10, 2005
Within 3 months, you will know UNIX.
This is overstating things a bit. It took me ~2 years to get the hang of it, and I still consult man all the time.
1, Read a good book: Think Unix is excellent, and gives you an overview, a way to approach Unix.
2, Learn permissions, octal not symbolic.
3, Most processes are called from /etc/init.d.
4, Use vim instead of vi.
5, Install a bunch of stuff.
6, The GUI is not your friend. Command line or die.
posted by Mean Mr. Bucket at 11:20 AM on February 10, 2005 [1 favorite]
This is overstating things a bit. It took me ~2 years to get the hang of it, and I still consult man all the time.
1, Read a good book: Think Unix is excellent, and gives you an overview, a way to approach Unix.
2, Learn permissions, octal not symbolic.
3, Most processes are called from /etc/init.d.
4, Use vim instead of vi.
5, Install a bunch of stuff.
6, The GUI is not your friend. Command line or die.
posted by Mean Mr. Bucket at 11:20 AM on February 10, 2005 [1 favorite]
The best learn-by-doing linux distro is Gentoo (if you follow the advice above and do this on old hardware, don't compile everything from source; just install binaries.)
Andrew Cooke was talking about the Unix System Administration Handbook; the current (3d) edition has a purple cover and it is a good book (but expensive.)
You can have access to pretty much all the books you'll ever need if you get a Safari subscription.
Something I've found useful while playing with my Gentoo box is to have another box on my desk with a KVM switch so that no matter how badly I screw things up, I still have access to the Net so I can look up solutions.
posted by Zed_Lopez at 11:22 AM on February 10, 2005
Andrew Cooke was talking about the Unix System Administration Handbook; the current (3d) edition has a purple cover and it is a good book (but expensive.)
You can have access to pretty much all the books you'll ever need if you get a Safari subscription.
Something I've found useful while playing with my Gentoo box is to have another box on my desk with a KVM switch so that no matter how badly I screw things up, I still have access to the Net so I can look up solutions.
posted by Zed_Lopez at 11:22 AM on February 10, 2005
The best learn-by-doing linux distro is Gentoo
I appreciate the Gentoo zealots, but it is really a lot harder than Suse, RedHat, and Mandrake.
posted by Mean Mr. Bucket at 11:23 AM on February 10, 2005
I appreciate the Gentoo zealots, but it is really a lot harder than Suse, RedHat, and Mandrake.
posted by Mean Mr. Bucket at 11:23 AM on February 10, 2005
IMHO.
posted by Mean Mr. Bucket at 11:25 AM on February 10, 2005
posted by Mean Mr. Bucket at 11:25 AM on February 10, 2005
I know it's harder. That's why I'm recommending it as "the best learn-by-doing distro" and not, say, the easiest to install.
posted by Zed_Lopez at 11:37 AM on February 10, 2005
posted by Zed_Lopez at 11:37 AM on February 10, 2005
Gentoo is quite a bit harder to use, but it's pretty valuable to learn, because it makes you do most steps manually, and doesn't install anything by default.
That being said, Gentoo quite different from other Unices, so the stuff you learn by installing and using it may not transfer.
posted by sid at 12:01 PM on February 10, 2005
That being said, Gentoo quite different from other Unices, so the stuff you learn by installing and using it may not transfer.
posted by sid at 12:01 PM on February 10, 2005
I know it's a touchy subject, but I would recommend a non-modal editor, like, for example, emacs.
The alternative to this is to get a job that requires you use UNIX; operator and support jobs are a good place to start if you're not a coder.
I happen to be looking for such jobs even now; I haven't found them easy to come by if you don't already have gonzo experience with all sorts of different things. (Though if anyone has any tips on where to search ....)
posted by kenko at 12:06 PM on February 10, 2005
The alternative to this is to get a job that requires you use UNIX; operator and support jobs are a good place to start if you're not a coder.
I happen to be looking for such jobs even now; I haven't found them easy to come by if you don't already have gonzo experience with all sorts of different things. (Though if anyone has any tips on where to search ....)
posted by kenko at 12:06 PM on February 10, 2005
Do you want to just be a competent UNIX user, or an actual super-geek? Most of the suggestions floating around seem to center around using UNIX, which I agree is a handy skill to have, but will leave you a great distance from geekhood.
True enlightenment comes not from understanding how -- any buffoon can learn to type commands from a book -- but from understanding why. Start by reading the original BSTJ paper, which is an excellent introduction along with the Kernighan introduction paper (also from BSTJ), and the Ritchie history paper. Read some of the other early history papers. True understanding of UNIX comes from learning the genius of some of the early design decisions, many of which were taken directly from MULTICS, and the cleverness of the original implementations.
Try learning a little about the UNIX filesystem, which is a major component of the system. Try to grasp the earthshaking significance of pipes as magical file descriptors.
Oh, and Gentoo isn't very good for learning by doing, since the (rather good) ebuild system does everything for you and hides a lot of the nitty-gritty detail. Yes, you get to look at a bunch of configure and make output, and play with some configuration files, but that's just system administration procedure, not UNIX itself.
Slackware's a pretty good way to go if you want to monkey around with learning to be a system administrator, and LFS might be a good learning exercise. For that matter, installing and make world-ing FreeBSD isn't such a bad idea if you want a glimpse into ancient history.
Playing with stuff is good for learning procedures and implementation, but UNIX is a collection of concepts more than a given /usr/bin full of commands. If you know why it is the way it is, you can generally guess at how to use it.
posted by majick at 12:08 PM on February 10, 2005
True enlightenment comes not from understanding how -- any buffoon can learn to type commands from a book -- but from understanding why. Start by reading the original BSTJ paper, which is an excellent introduction along with the Kernighan introduction paper (also from BSTJ), and the Ritchie history paper. Read some of the other early history papers. True understanding of UNIX comes from learning the genius of some of the early design decisions, many of which were taken directly from MULTICS, and the cleverness of the original implementations.
Try learning a little about the UNIX filesystem, which is a major component of the system. Try to grasp the earthshaking significance of pipes as magical file descriptors.
Oh, and Gentoo isn't very good for learning by doing, since the (rather good) ebuild system does everything for you and hides a lot of the nitty-gritty detail. Yes, you get to look at a bunch of configure and make output, and play with some configuration files, but that's just system administration procedure, not UNIX itself.
Slackware's a pretty good way to go if you want to monkey around with learning to be a system administrator, and LFS might be a good learning exercise. For that matter, installing and make world-ing FreeBSD isn't such a bad idea if you want a glimpse into ancient history.
Playing with stuff is good for learning procedures and implementation, but UNIX is a collection of concepts more than a given /usr/bin full of commands. If you know why it is the way it is, you can generally guess at how to use it.
posted by majick at 12:08 PM on February 10, 2005
if you want to head off down the path majick describes, you might try hunting down a copy of lion's "commentary on unix" too... (i know it only by reputation).
posted by andrew cooke at 1:39 PM on February 10, 2005
posted by andrew cooke at 1:39 PM on February 10, 2005
and i seem to be hearing lots of bad things about esr at the moment, but this book is also a good (free) read to get a handle on unix.
posted by andrew cooke at 1:42 PM on February 10, 2005
posted by andrew cooke at 1:42 PM on February 10, 2005
Best answer: Late, but:
There are some good recommendations here for sysadmin tasks. However, if you just want to learn how to get the most out of Unix as a user, I have always recommended Unix Power Tools by O'Reilly.
There's a newer edition than the one I have, and I haven't looked at it. However, I think this book is a great overview of useful things you can do as a Unix user, without bogging down into administration tasks that are interesting but not vital at the moment.
Of course, if you're a Unix system administrator, you'll become a much better one if you read every page of Unix Power Tools.
It made a big difference for me when going from knowing a few things to developing a true understanding how Unixish systems work. Expensive, but worth it.
Try really hard to do everything you want to do as a non-root user. You'll be protected from yourself, and you'll be forced to think about things that matter, like permissions and accounts. You can keep a root window open for convenience while you're playing around, but don't use it unless you have to.
posted by jmcmurry at 5:34 PM on February 10, 2005
There are some good recommendations here for sysadmin tasks. However, if you just want to learn how to get the most out of Unix as a user, I have always recommended Unix Power Tools by O'Reilly.
There's a newer edition than the one I have, and I haven't looked at it. However, I think this book is a great overview of useful things you can do as a Unix user, without bogging down into administration tasks that are interesting but not vital at the moment.
Of course, if you're a Unix system administrator, you'll become a much better one if you read every page of Unix Power Tools.
It made a big difference for me when going from knowing a few things to developing a true understanding how Unixish systems work. Expensive, but worth it.
Try really hard to do everything you want to do as a non-root user. You'll be protected from yourself, and you'll be forced to think about things that matter, like permissions and accounts. You can keep a root window open for convenience while you're playing around, but don't use it unless you have to.
posted by jmcmurry at 5:34 PM on February 10, 2005
lots of good suggestions here. majick is right that if you really want to understand what's going on, reading up on the history of the concepts is extremely helpful. In a random, entertaining way, browsing the jargon file can be pretty illuminating.
But like other people have said, forcing the machine to do stuff is important. Pick a project (even an absurd one, like: "i want to set up a web server that only runs between 4am and 8am local time") and figure out what parts of the system need to be involved in getting that working. Try to do this first with a non-crucial project, though. You won't get it "right" the first time around, and you need to give yourself room for experimentation.
I also really strongly recommend having a spare machine to play with. If you just work with emulators, you end up learning a lot about emulators and how they work (or don't work) which is interesting, but not what you're looking for. There's a wonderful sense of freedom that comes with working with a dedicated machine that you know you are able to completely tear down and rebuild.
So seriously: set up a spare machine (you can get them very cheaply), get practice with the installation process of some UNIX OS or other, and set about breaking things. Figure out what the consequences are for each particular breakage, even if it means you end up starting over again with that machine. Figuring out why something doesn't work will help you immensely in the future.
posted by dkg at 5:38 PM on February 10, 2005
But like other people have said, forcing the machine to do stuff is important. Pick a project (even an absurd one, like: "i want to set up a web server that only runs between 4am and 8am local time") and figure out what parts of the system need to be involved in getting that working. Try to do this first with a non-crucial project, though. You won't get it "right" the first time around, and you need to give yourself room for experimentation.
I also really strongly recommend having a spare machine to play with. If you just work with emulators, you end up learning a lot about emulators and how they work (or don't work) which is interesting, but not what you're looking for. There's a wonderful sense of freedom that comes with working with a dedicated machine that you know you are able to completely tear down and rebuild.
So seriously: set up a spare machine (you can get them very cheaply), get practice with the installation process of some UNIX OS or other, and set about breaking things. Figure out what the consequences are for each particular breakage, even if it means you end up starting over again with that machine. Figuring out why something doesn't work will help you immensely in the future.
posted by dkg at 5:38 PM on February 10, 2005
"UNIX Power Tools" seconded. I brought my copy to work, accidentally loaned it to our (damned good) system administrator who occasionally consults me on knotty problems, and haven't seen it in years. It's good enough to steal from honest, hardworking colleagues.
Yes, 90% of the content of the book is recycled Usenet posts, but it's better than just about anything you'll find in a bookstore these days.
posted by majick at 7:41 PM on February 10, 2005
Yes, 90% of the content of the book is recycled Usenet posts, but it's better than just about anything you'll find in a bookstore these days.
posted by majick at 7:41 PM on February 10, 2005
Best answer: Always remember what my friend told me: "Unix assumes you are a grown up and know what you are doing". Or alternatively "Unix is userfriendly; it's just particular about who its friends are".
Which is to say: until you're there, be particular about backups or keep mission-critical stuff on another box. There are no confirmation dialogs in Unix. If you are root, there is no safety net. If you want to delete every goddamn file on the system, Unix will cheerfully commit suicide for you. Remember that, and think about how you would test things before you do them.
If you are really interested in Unix, as opposed to Linux, take a look at the various BSDs. x86 Solaris, even. If you are doing Linux, Debian or Slackware feel more unixy to me than Red Hat based Linuxes.
I learned everything I know from:
- the older and wiser (they *did* all have beards)
- Aeileen Frisch's System Administrator's Handbook (O'Reilly)
- The Magic Garden Explained
- The Lions Book that andrew cooke referred to, now freely available
- innumerable Linux HOW-TOs
One thing I do know is that studies have shown that Unix guruness is highly localised - at any particular site, the Unix guru has a skillset that overlaps very little with the skill of the guru at another site. So don't feel bad when others seem to be wise to a bunch of stuff you never knew was important. As long as you know how to do what you want to do, that's enough.
Lastly, it's almost always a permissions problem. Seriously.
Kid, here's a nickel. Get yourself a better computer.
posted by i_am_joe's_spleen at 12:10 AM on February 11, 2005
Which is to say: until you're there, be particular about backups or keep mission-critical stuff on another box. There are no confirmation dialogs in Unix. If you are root, there is no safety net. If you want to delete every goddamn file on the system, Unix will cheerfully commit suicide for you. Remember that, and think about how you would test things before you do them.
If you are really interested in Unix, as opposed to Linux, take a look at the various BSDs. x86 Solaris, even. If you are doing Linux, Debian or Slackware feel more unixy to me than Red Hat based Linuxes.
I learned everything I know from:
- the older and wiser (they *did* all have beards)
- Aeileen Frisch's System Administrator's Handbook (O'Reilly)
- The Magic Garden Explained
- The Lions Book that andrew cooke referred to, now freely available
- innumerable Linux HOW-TOs
One thing I do know is that studies have shown that Unix guruness is highly localised - at any particular site, the Unix guru has a skillset that overlaps very little with the skill of the guru at another site. So don't feel bad when others seem to be wise to a bunch of stuff you never knew was important. As long as you know how to do what you want to do, that's enough.
Lastly, it's almost always a permissions problem. Seriously.
Kid, here's a nickel. Get yourself a better computer.
posted by i_am_joe's_spleen at 12:10 AM on February 11, 2005
I can't believe nobody mentioned this... RUTE helped me immesurably.
posted by Thoth at 5:01 AM on February 11, 2005
posted by Thoth at 5:01 AM on February 11, 2005
This thread is closed to new comments.
posted by AlexReynolds at 10:17 AM on February 10, 2005