The Practical Manager's Guide to Linux

An anonymous reader wrote in to send us The Practical Manager's Guide to Linux. With a title like that, how much explanation do you need? It refutes all the usual FUD- hopefully it does what it says.

Comments

Certainly not FUD...

[reaper]

...but certainly not completely accurate. If this article was any cheerier, I'd have to puke.

First off, the 2038 problem is glazed over rather quickly, and then passed off as easily fixable. While it is true that fixing the problem with OpenSource software is rather simple, there are still binary-only programs out there that require fixing.

The size of the date field is defined in only one place in any Unix system. This is a variable called time_t. Moving from a 32-bit chip to a 64-bit chip involves, among other unrelated things, merely changing the definition of time_t in this one place from 32 bits to 64 bits. When the operating system is then recompiled, it will use the new definition and store all dates in 64 bits from then on.

The author neglects to mention that you will then need to recompile anything that ever used that constant for that architechture. This is fine for new architechtures, but has the distinct possibility of killing off any 32-bit hardware. Anyone can change the definition of time_t to 'long long time_t', recompile the kernel, and then watch as your programs seg fault.

In the 'Virus-Proof' discussion the author does make a good point that viruses are significantly more difficult to write for UNIX than they are for DOS/Windows. They are not impossible to write though. The Macro Virus argument is not even an OS issue; it is an issue of poor software implementation. You can bet if MS ported Word to Linux, that the macro viruses would come with it.

In dismissing the Mindcraft study (the first one), the author overlooks a good point that came out of that experiance. Linux is not a magic bullet for instant performance, and stability. Like other OSes it will require careful set-up, and tuning. It is important not to over look that fact when explaining why it typically takes about 2 days to get a Linux box working well at high server loads.

In the server discussion the author neglects (quite glaringly) to mention that Linux cannot handle large files. If your corporation will require files over 2GB in size, you can forget about it. Instantly remove Linux from the list of acceptable OSes.

The was only a quick mention of FreeBSD in the article saying how Linux is almost as fast now. I thought this was an interesting oversight. FreeBSD is more stable than Linux, and more refined. It is also faster on some operations. It is a viable OS for organizations that need a fast, dedicated server, and have no intention on using Gee-Whizz-Bang New Peripheral of the Minute type hardware. Ignoring it makes it look like a completely biased report.

All in all it is a good summary fo Linux's features, but I think the style is a little too glowing for some people to swallow the article as a whole.