Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Practical Manager's Guide to Linux

Posted by CmdrTaco on from the stuff-to-read dept.

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.

10 of 51 comments (clear)

  1. Some corrections by Anonymous Coward · · Score: 2

    1. Linus DID NOT name Linux
    2. The problem of moving applications from 32 to 64 bits is NOT the instruction set, but the high-level language used. Many nontrivial C and C++ programs cannot be just compiled in 64 bits w/o some modifications (and they are not so dirty).
    3. Does not address the issue of packaging incompatibility among distributions, and lack of means of verifying that an installation has not been modified from an approved setup (otherwise, it can become a tech support nightmare).

  2. One thing I noticed. by Anonymous Coward · · Score: 3

    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.

  3. PDF coming soon... by Jon+Abbott · · Score: 2

    I'm currently working on converting this to PDF format, so that it can be printed and bound. If you would like to know when I finish and where to find it, send me an email.

    If any of you want something changed in the PDF version of it, let me know.

    --
    Slashdot's first reaction to VMware
  4. Verification... by Suydam · · Score: 2
    A good executive summary would be great...but also, some admission that in some certain cases NT might be an "ok" choice seems to go a long way when trying to woo managers into setting up Linux.

    If you say "Linux is best for all things all the time" (as this article seems to say) you'll be labeled as a zealot, no matter how nicely you say it.

    We need some documents that are written in plain english, are concise, and depict Linux vs. NT for a SINGLE TASK. That way, when I go to my boss and say "our new webserver should run LInux." I can show him why for WEB SERVING Linux is better. Conversely, when you go to your boss (if you have one) and say "our office fileserver shoudl run LInux" you have a document that shows why linux is better for Fileserving in non-homogenous network environment.

    Is there a website out there right now that contains documents like these, in one centralized location? (or at least links to them with summaries?) I didn't think there was, so I threw something together that will hopefully evolve into what I've just described. You can upload documents (or link to them) HERE.

    Eventually my goal is to have an online resource of Linux Advocacy/Information documents about WHY people should choose Linux. This resource will be searchable so that you can find the best paper to suit your needs.

    If I'm wasting my time and this already exists, please let me know in a non-flame sort of way, I don't want to step on anyone's toes or anything like that.

    Thanks.

    --


    Werd.
  5. Please don't slashdot it... by Matts · · Score: 2

    I'm trying to get my managers to read this...

    It's a very well written article, with few deficiencies. It is a bit over the top in it's glowing recommendation of Linux - i.e. it's biased. What more should we expect. However I was supposed to be writing something like this myself this week in an ongoing persuasion process. Looks like I can have an easy week for once... Nah - they'll find something else for me to do ;-)

    Matt.


    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'

    --

    Matt. Want XML + Apache + Stylesheets? Get AxKit.
  6. On the same tune... by edgy · · Score: 3

    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

  7. Certainly not FUD... by reaper · · Score: 4

    ...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.

    --
    - Dan
    1. Re:Certainly not FUD... by remande · · Score: 2
      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.

      A macro virus has a limited blast radius in a Unix or Linux environment. If I let one go in my account, the virus runs with my permissions and can hose all of my files. It won't be able to do much more than trash my account; the programs, and everybody else's data (assuming good umasks) are safe. Those who run office software as root, of course, get what they deserve.

      --

      --The basis of all love is respect

  8. This will earn a big "who cares?" from managers by Zico · · Score: 2

    I've read only the first page so far, and I'd be annoyed if an employee gave me this and expected me to read this. This guy needs to have someone go over it to rewrite it for regular humans -- it's clear that it was written by a geek. Examples from the first page:

    • The whole GNU/GPL thing. Other than the fact that this is one of the last things on managers' minds, the author subjects us to things like:
      • "Free software programmers often display a wacky sense of humour." Wheeee.
      • "[Stallman] uses the word "hacker" in the positive sense of master programmer, reserving the word "cracker" for people who break into systems.
    • The disagreement that Stallman has with Linus about the name. Come on, please remember the audience.
    • The link to the audio file of Linus's pronunciation of Linux. *cringe* Again, while geeks eat this stuff up, it elicits "And I'm spending my time reading this why?" reactions from most others.

    When writing for humans, a good test is to run it past your girlfriend or mother (provided that they're non-geeks) and see if it can hold their interest.

    I'll leave some of the sillier pro-Linux claims that I noticed in this article for later discussion when I have a little free time. ;-)

    Cheers,
    ZicoKnows@hotmail.com

  9. Article needs improvement by maw · · Score: 3
    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.

    --
    You're a suburbanite.