Yet Another Linux Blog

While we all strive for maximal Uptime, one thing that often goes by the wayside is the ability to reboot the machine without wondering whether it will come back up correctly.

You do not want to find out that the machine has the wrong boot settings when it gets powered off unexpectedly and then doesn’t come back up.

“do a reboot” is a good checklist item when adding a new service to a machine. You’ll want to ensure that the service comes up correctly without intervention after a reboot. Of course, you’re installing the service during a maintenance period, so rebooting is not an issue, right?

In my day job, we learned this lesson the “medium hard” way when we had to move datacenters. The specialized movers that were hired had a full power cycle on their checklist of things to do to the machines before unracking them. You really want to make sure the machine comes up correctly before moving it to a different datacenter/network where you may have different unrelated problems.

If you ask around, you’ll hear lots of horror stories about machines that had been up and running with great uptimes (1 year! 2 years!) that no one was willing to touch lest some undocumented thing breaks on reboot.

Today, with many services living in small virtual machines (or VPSs), a reboot only takes a few seconds, so it’s much easier to do.

Add this “best practice” to your sysadmin toolkit. For more details on related topics, see “The Practice of System and Network Administration”.

There are a lot of writers who write about controversial topics not to add anything of value to the debate, but merely to stir up the flames. Today, that typically means attracting a lot of page views and lots of comments.

How Canonical Can Do Ubuntu Right: It Isn’t a Technical Problem by Caitlyn Martin is a perfect example.

We won’t focus on the fact that the sensationalist headline does not match what she says in the article, which is in fact mostly about technical problems she had with Ubuntu.

It’s the “trolling” sentences that are the signature of this type of article.

1. “Other distributions which target the desktop and the wider consumer market do a much better job from a technical standpoint. They produce a better product.”

Which “other distributions”? How are they better?

2. “Even considering all of that I still feel that the downloaded Ubuntu offerings more often than not have been substandard when compared to other distributions.”

Which “other distributions”? How is Ubuntu “substandard”?

And finally, after rambling about several unrelated topics, the conclusion: “At this point I recommend Mandriva 2010 for newcomers to Linux. No, it is not bug free. No distribution is. Mandriva’s developers are simply more responsive to bug reports and get issues fixed, usually in a timely manner. In addition, while Mandriva has had a few less than stellar releases they have, more often than not, done a pretty good job of getting things out that work. As always, your mileage may vary.”

My technical mind translates that to “Mandriva worked better for me than Ubuntu on the one box I tried it on.”

I’m not writing this to say that Ubuntu is awesome. I’ve had my share of problems with Ubuntu. I’m writing this to say that Caitlyn’s article is awful. She doesn’t say anything new and she makes vague complaints that only trick other people into trying to counter them. Well, I’m not feeding this troll.

Karanbir Sangh (one of the CentOS maintainers) asks “Why do you run CentOS?”

I’d say our indirect philosophical reasons are:

• We want to use Free Software
• We want to use the best tool for the job
• We want to hire smart people

For our application, we can use almost all Free Software, except this one commercial package (IBM’s GPFS), which is not Free, but is the best tool for the job. IBM only support GPFS on SuSE or Red Hat, so we choose Red Hat, mainly because it is more common. It is also much easier to find qualified people who are familiar with the RHisms of Linux. While I’m a Debian guy at heart, it’s easy to adjust between RH/Debian.

So that’s why we’re on CentOS.