You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

"Microsoft's Techniques for Developing Bug-Free C Programs" (publisher).
IMHO, applicable to most areas of program development providing a practical guide on how to write bug free code from day one and how to keep it bug free. i.e. how Microsoft should have done it, given sufficient incentive.

Remember how Microsoft got their bad name - bugs and late delivery, right? This book describes the views of one Microsoft author that saved their a$$es on a few occasions.
Asside from having "Microsoft" on it, the book is very good, very readable and contains illustrative examples to back up the commentry. It was the first book I read where they actually discussed "Software Quality".
It uses C as the example language but the concepts are easily portable. It also champions Hungarian notation that can cause arguments on the scale of the Discworld Mage Wars! That aspect you can take or leave.
The central theme is this:

Programs are written by people. They are maintained by people. People have to read the code, decipher the meaning and fix the bugs. Computers, on the other hand, don't read programs - Compilers do (and they are VERY good at it). So: Write your code for human readers!

The second "law":
If you think your obscure one-liner, using every trick in C, is faster than what the optimiser can do, dream on. Don't expect anyone (including yourself in a month's time) to be able to understand it or be able to fix it.
Use every compiler warning available and use the strictest type-checking you can. Imagine if your (paranoid) compiler could identify ALL of your bugs (off by one etc.) - help the compiler, don't hinder it.

The third "law":
Make a "debug" version using the pre-processor. No "debug" code should exist in a "release" binary. The debugging code will probably have bugs in it. You only put it in to see what was going wrong in the first place. Once the problem is fixed are you going to single-step through the debugging code?

As mentioned, I found this book very easy to read and the main points stood out as they should. If you have ever written code for MS MFC then you'll be right at home. As for Linux kernel hackers, why not take a peek over the wall? Ignore the bits about variable naming and everything else is just as relevent (`make debug` etc.).

An unreserved recommendation. Buy/borrow/steal a copy, read it and post your own review here. (I have no connection with the Author! I just like the book.)