Categories

Get Started Now

Linux for Mortals: What I’ve Learned So Far

Editor’s Note: This is the fifth in a series of posts about Linux written by CBT Nuggets’ Linux expert, Shawn Powers. Check the blog each week for his latest installment.

A while back on Twitter, I said, “The curse of brilliance is knowing you’re not.”

I attributed the quote to “Anonymous” because calling myself brilliant seemed a bit presumptuous, but there’s so much truth to the statement, I wanted to say it publicly. The more I learn about Linux (and technology in general), the more I realize how much I don’t know.FB-5

But that’s OK.

If you ever meet a system administrator who thinks he/she knows everything about his/her field, that system administrator is a dirty, dirty liar. More importantly, a sysadmin who doesn’t think he/she still has lots to learn will stagnate your entire company.

One of the awesome things about being a system administrator, specifically a Linux system administrator, is the incredible advancements that take place in the Open Source world. Advancements mean change, and if you’re afraid to change, you’re destined to fail. Working with Linux the past 18+ years has been tons of fun, and along the way, I’ve learned a few invaluable lessons:

1. You don’t have to know everything, but you have to be able to figure everything out.

As a Linux sysadmin, I write BASH scripts fairly often. In fact, any time I find myself doing a task more than once, I try to write a script to automate the process. I’ve probably written thousands of quick little scripts during my career. Every single time I need to create a FOR loop, however, I need to look up the syntax. I’m not exaggerating either. I’ve written literally thousands of scripts, and literally EVERY time I need to create a FOR loop, I have to look it up.

My point is that knowing the syntax for creating a particular type of loop isn’t what makes a person a good system administrator. The key is knowing *when* using the FOR loop is a good solution to a problem. Google can provide the syntax, that’s the easy part. You get paid to think.

2. Asking for help is a sign of maturity, not a sign of weakness.

This goes along with “surround yourself with people smarter than you,” which makes asking for help far more enjoyable and beneficial! I have a friend who lives in California, on the other side of the country from me. Thanks to IRC, if I’m stumped with a problem, I can quickly send him a message asking for help and insight. My friend Kyle is brilliant, and even if he doesn’t have an answer, he’s always willing to brainstorm with me. That’s the key, really. Asking for help isn’t always getting an answer from someone (again, Google can do that), it’s collaborating with your peers. Don’t be afraid to ask for help. We all need help from time to time.

3. Linux is an incredible solution, except when it’s not.

I’m a Linux trainer, I’m a columnist for a Linux magazine, and I’ve been a Linux system administrator for nearly two decades. It’s pretty safe to say I’m a zealot when it comes to Linux and Open Source. I learned pretty early on, however, that trying to force Linux in every situation is a disaster waiting to happen.

Last week, we talked about the pros and cons of leveraging Linux as a part of your infrastructure. Linux is an ideal solution for many problems, but be sure you explore the alternatives before insisting Linux is the best option. It often is, but sometimes it’s not.

4. Just because Linux is free doesn’t mean your IT budget is zero.

Another mistake I’ve made in the past is to talk over and over about Linux being free. It’s true, of course, but if you keep saying “free” over and over, the finance folks in your company will start to assume if it’s free, it won’t cost anything, and helpfully lower your budget to zero. That’s silly, but since you keep saying “free” all the time, it makes sense they might get confused. Be sure to focus on all the positive aspects of a Linux implementation, not just how free it is!

5. Under promise and over deliver.

This last thing I’ve learned isn’t specific to Linux, but since I’m a Linux guy, that’s where I’ve implemented it the most. I like to think of this as the “Scotty” principle. If you’ve ever watched Star Trek, at some point during the episode, Captain Kirk calls down to Scotty asking how long it will take to fix the warp conduits. Scotty says it will take five hours. The captain says the ship will explode in two hours. Scotty says he’ll do what he can, and sure enough, in just under two hours, Scotty fixes the warp conduits and saves the day.

If Scotty would have told Captain Kirk, “Capt’n, it’s gonna take me an hour and 45 minutes to realign the warp conduits,” you’d better believe that at one hour and 50 minutes, the captain would have been livid! But as Scotty under promised (five hours), and over delivered (just under two hours), he was a hero! I find it’s a valuable lesson to learn, and it will make you and those you work with far happier. Just don’t get silly about your estimates, or no one will believe you!

What have YOU learned?

Working in technology is such a diverse environment that everyone brings something unique to the table. I’ve shared a few things I’ve learned over the years, but what about you? What has your specific path taught you about technology, system administration, or even Linux itself?

If you’re just starting with Linux, I urge you to get over that initial hump. It’s an incredible operating system developed by an entire community of people honestly interested in working together to help one another. You can be part of that too. And your part will be different than anyone else’s, which makes the whole community stronger.

Editor’s Note, Part 2: Want to learn more about Linux? Check out Shawn’s free “Hosting Java Apps with Apache Tomcat” webinar on April 10. Register here

Comments are closed.