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

One thing I noticed.

[Anonymous Coward]

Quite glaringly. It mentioned lack of plug n play support. Where'd this come from?

I'm running 2 PNP cards in PNP mode in one machine at home, a sound card and a lan card. In another box I have a pnp sound card. (All are ISA PNP cards). They work fine with an out of the box RedHat 5.2 install.

On the same tune...

[edgy]

Very good read. :-) I like the language it was written in. It doesn't look like some zealot wrote it, and that's an important thing to remember when trying to counter FUD by Microsoft.

On a slightly related note, I ran into an article on LinuxToday, in case some others haven't seen it yet, that show that NT on a Quad Pentium Xeon is a "Weak Value Proposition" as compaired to Linux/FreeBSD. Now, where have we heard the phrase, "Weak Value Proposition" before? :-)

This might be useful to those of you trying to fight those that blindly trumpet the Mindcraft results:

http://linuxtoday.com/stories/5688.html

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.

Article needs improvement

[maw]

I love Linux as much or more than the next guy, and positive press about it is great, but this article was, at best, mediocre. The writing was poor, there were plenty of dubious facts and assertions, and didn't seem to have any single clear message.

It's difficult to describe the writing's weaknesses (that is, the deficiencies in the writing and presentation per se) without quoting at length; in a nutshell, though, the piece seems to follow this (unfortunate) pattern throughout: "Linux has this, that, and the other thing. It also has foo. (Bar, baz, and bozo.)" It makes for very disjointed, stilted reading. It doesn't flow.

The inaccessability could be overcome by some solid evidence, but even when there is solid evidence, the author blows it. An example: "There are many stories of security fixes for Linux being made available within hours of an attack being known (the FTP bounce attack, the teardrop or IP fragmentation attack, and the 'ping of death')." Those are only several examples, not many as he stated. There are many other instances similar to this. While they would stand up in their own right (if they were properly explained: teardrop exploited a Linux bug; an FTP related exploit would not, on the other hand, be Linux-specific. This needs to be more clear.), the poor treatment they were given detracts from the paper and its credibility.

Because of already explained weaknesses, this article boils down to something along the lines of "Linux is good, and you should use it, or something." That's not a message I'd want PHBs to be seeing.

It's really too bad, because there were lots of good pieces of information there, and the author obviously did a lot of research. I would *love* to see the information in the article (there was a lot of it!) distilled and re-presented by a better writer, because as it is now, I was saying to myself "yeah, so what, this sounds like crap" -- and I'm not a hostile audience. There's no way I would show this to a manager (or anyone else, except perhaps a good writer who I'd be trying to convince to rewrite the thing) in its present form.