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

Feral Interactive Ports Life Is Strange to Linux and Mac, Episode 1 Is Now Free

Feral Interactive has recently announced that they have managed to successfully port the popular, award-winning Life Is Strange game to GNU/Linux and Mac OS X operating systems. Read more

Introduction to Modularity

Modularity is an exciting, new initiative aimed at resolving the issue of diverging (and occasionally conflicting) lifecycles of different “components” within Fedora. A great example of a diverging and conflicting lifecycle is the Ruby on Rails (RoR) lifecycle, whereby Fedora stipulates that itself can only have one version of RoR at any point in time – but that doesn’t mean Fedora’s version of RoR won’t conflict with another version of RoR used in an application. Therefore, we want to avoid having “components”, like RoR, conflict with other existing components within Fedora. Read more

Our First Look at Linux Mint 18 Cinnamon

Now that I’ve had about a week to play around in Mint 18, I find a lot to like and have no major complaints. While Cinnamon probably isn’t destined to become my desktop of choice, I don’t dislike it and find it, hands down, the best of the GNOME based desktops I’ve tried so far. Anybody looking for a powerful, all purpose distro that’s designed to work smoothly and which can be mastered with ease would be hard pressed to find anything better. Read more

The subtle art of the Desktop

The history of the Gnome and KDE desktops go a long way back and their competition, for the lack of a better term, is almost as famous in some circles as the religious divide between Emacs and Vi. But is that competition stil relevant in 2016? Are there notable differences between Gnome and KDE that would position each other on a specific segment of users? Having both desktops running on my systems (workstation + laptop) but using really only one of them at all times, I wanted to find out by myself. My workstation and laptop both run ArchLinux, which means I tend to run the latest stable versions of pretty much any desktop software. I will thus be considering the latest stable versions from Gnome and KDE in this post. Historically, the two environments stem from different technical platforms: Gnome relies on the GTK framework while KDE, or more exactly the Plasma desktop environment, relies on Qt. For a long time, that is until well into the development of the Gnome 3.x platform, the major difference was not just technical, it was one of style and experience. KDE used to offer a desktop experience that was built along the lines of Windows, with a start center on the bottom left, a customizable side bar, and desktop widgets. Gnome had its two bars on the top and bottom of the screen, and was seemingly used as the basis for the first design of Mac OS X, with the top bar offering features that were later found in the Apple operating system. Read more