Language Selection

English French German Italian Portuguese Spanish

Five common mistakes that Linux IT managers make

Filed under
OSS

After seeing the same mistakes repeated by different IT managers over the years, I've noticed a pattern of common errors. Here are the five common mistakes, along with tips for avoiding them.

Mistake #1: Reactive, not proactive

The number one mistake made by IT managers of all stripes is to carry out their duties by reacting to problems only as they come up, rather than looking ahead to potential problems and having a solution in place ahead of time. This trait isn't unique to IT managers, but it can be a fatal flaw when the head of an IT department fails to take a proactive approach.

For example, proactive IT managers make sure they have disaster plans in place rather than trying to implement a disaster plan on the fly. A good IT manager will have plans to deal with hardware failure, natural disaster, compromised systems, and any other problem that might crop up. If you spend most of your time putting out fires, you're probably not being proactive enough -- or you're still cleaning up the previous manager's messes.

A proactive manager plans for the future in terms of capacity planning, upgrades, and support. What happens when an application outgrows a single server, for example? How difficult will it be to deploy on multiple servers, and is this even possible? When deploying open source software, you'll want to assess the health of the community that supports it. If it's a project without a long history and an active developer community, it may not be the best choice. Projects like Samba and Apache are safe bets, while a project that made its SourceForge debut three weeks ago is risky business.

Many organizations experience costly growing pains because the IT infrastructure wasn't planned with an eye to the future. You may only need to support five or 50 users now, but what about three to five years down the road? If that seems like it's too far off to worry about, you've already failed.

When it comes to hardware, be picky and choose servers and equipment that will have a long life span and support. Be cautious about choosing non-standard hardware with binary-only kernel modules. The vendor may provide support and upgrades now, but what happens if it chooses to stop supporting a piece of hardware after a few years? That leaves you with the choice of ditching hardware or not being able to upgrade the kernel.

Mistake #2: Failing to emphasize documentation and training

Full Article.

More in Tux Machines

SolydX 201411 Is a Rolling Release Alternative to Linux Mint Debian Xfce

SolydX, a Debian-based distribution that features the Xfce desktop environment and uses a rolling release model, is now at version 201411 and is ready for download. Read more

Linux-Based Beautiful Jolla Tablet Registers Fantastic Success on Indigogo

Jolla is a new tablet developed by a team of people who used to work for Nokia and it's powered by a Linux-driver operating system called Sailfish OS. The recently launched crowdfunding campaign has surpassed any expectations. Read more

WordPress 4.0.1 Updates Millions of Sites for 8 Flaws

Millions of open-source WordPress site owners received email notifications over the last 24 hours advising them of a site update. The new WordPress 4.0.1 update provides multiple security fixes and data-hardening improvements to help secure WordPress sites. The WordPress 4.0.1 update is the first incremental update for WordPress since the 4.0 release in September. The 4.0.1 update provides 23 bug fixes and an additional 8 security vulnerability fixes. Read more

V2 Of KDBUS Published For Linux Kernel Review

The second revision to the Linux kernel based D-Bus implementation is now available for review. Greg Kroah-Hartman on Thursday night posted the "v2" revision of the KDBUS implementation for providing the kernel with a new IPC implementation that resembles the existing user-space D-Bus daemon while adding extra features. Among the changes in this revision to KDBUS are exposing its control files and other information via a new kdbusfs file-system, KDBUS expects to be mounted to /sys/fs/kdbus, a new KDBUS domain is created for each time kdbusfs is mounted, and various other low-level changes. More details via the patch-set series. It's not clear yet whether KDBUS will be ready for merging in the Linux 3.19 kernel or will be held off until Linux 3.20 or longer. Read more