Pitfalls

Notes:

This article might be seen as bias. Please skip reading if you find it offending.

Influence

The thing you can do best is the one you want to do, not the one others want you to do. By doing what others want you to do, you might end up doing something beyond your capability. If you are here to explore and to find out why people say Linux is better, that is fine. On the other hand, if you are here to learn how to put Athena on Linux because you were told it is a better way, stop now.

Preconception

Linux is difficult because you do not have much experience with it. This is true for a Windows user who are switching to Linux because features integral to Linux are either not found in Windows or hidden from Windows users. A Linux user can easily switch to Windows and make good use of its features (but will also complain about the lack of features).

Unproven Ideas

There are many people who are anxious to lend a helping hand or share their experience. There is no hard and fast rule for you to follow. You have to rely on common sense and intuition to separate freak occurrences from workable solutions. For example, if you were told to use bind_ip in Athena configuration and you have only one network interface, you should be alert enough not to implement it even if your benefactor undertakes that it will work.

Hasty Implementation

During the rush to implement a solution, especially one to a long standing problem, you might forget about precautions, such as backups and supportive actions. For example, you might forget about restarting the network after making changes to network settings. When the implementation does not work, you might implement more changes recommended by the author and get further into trouble.

Excessive Changes

When several changes are made, you might lose track of the actual effect of a change. For example, if you make change to hostname and IP, you might not know which one is or is not working. However, it does not mean that you can not make many changes at the same time. The rule of thumb is to implement those changes which will produce only one set of results or provide a clear audit trail. Changing dynamic IPs to static IPs is an example.

Unconventional Solutions

These solutions are built on sound principles but deviate from conventional or default settings. An example is hosting a server on a port different from the recommended one. It will work just like one hosted on the recommended port. When such solutions are implemented by inexperienced users, failure might occur. For example, a user might be forced to use the default port because of the lack of permission to access the router and firewall.

Impatience

You should always allow time for an implemented solution to work. Run some trials and take note of the results. If the results are not as intended, go through the implementation steps again and relate each setting to your system. Create some test data and run more trials. If you are eventually convinced that it does not work, get rid of the implementation quickly so that it will not complicate the next solution you might want to implement and restore your system to known working condition. It is quite common to read about people trying to implement customised items while they are still struggling to get a server off the ground. This is perhaps the worst of all enemies.