ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

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.

When I used PHP, MySQL, Apache and CakePHP, then something broke, I wouldn't know if it was PHP, MySQL, Apache or CakePHP that broke.

The source code of big projects is huge like nobody knows the whole code. Do you have to know PHP, MySQL, Apache or CakePHP's source code? CakePHP probably has the smallest source code, but even so it's big, because it's a full-stack framework. Do you have to know CakePHP's source code?

When something breaks and you look at the stack trace, you see lots of return statements. If you don't know the whole source code and how the functions interact, how come you know what went wrong?

Your post is quite confusing. I don't really understand what your question is. If you just use LAMP you do not need to understand the code of it's components. If your environment is configured properly then all errors you should see are result of the bugs in your code or bad configuration - which by the way is very well documented. Stack traces are sometimes long, but again, if your LAMP and framework are configured properly they will always point you to the error in your code, reporting entire function call stack - only for your debugging convenience! It's very rare event that application like Apache crashes on it's own. I don't know CakePHP but given it's popularity I doubt that it's unstable product.

You should almost always look first at your own code to determine where something went wrong. Most mature packages like PHP, Apache, etc have very few bugs, and those generally tend to be obscure and affect only unusual cases. Rarely does anything in software 'break' spontaneously. Something changes, usually for some kind of upgrade, which adds or exposes bugs in the code. Always look first at the body of code where change was introduced. Adding changes incrementally, and testing as you proceed is a good way to avoid the possibility of introducing problems whose origins are difficult to ascertain.

As either a programmer or system implementer, it is good strategy to create small modules which can be tested entirely or substantially in isolation (unit testing). When these are confirmed to work properly, they can be added to the larger body of work. Eventually, when all of the individual pieces are known to work, the probability of the whole working correctly should also be high. This is a sort of converse of the divide-and-conquer strategy.

As a system implementer, it is rarely required to look at source code (unless that is the only documentation).