> I think everyone agrees that Debians package and security update systems > are better. Red Hats installation procedure is userfriendlier, but that > doesn't explain why professionals use it.
I can think of some reasons... - Even being professionals, they want everything to be detected and configured automatically (and if not automatically, quite quickly and easily), because time == money. They can tell some unexperienced guy to install the system without worrying too much (the only time I tried this with Debian, the guy partitioned the disk exactly as I said. Then put all mount points under / -- which had 80Mb). Of course, after it's configured and running, Debian requires little attention... But then, the same is true for Red Hat (except for the security updates, of course!) - Easy-to-use graphical configuration toole. Instead of managing all possible machines, they can just help the user who asks for help on the phone. ("Yes, click here, click there, now type this number") The professional may not have a problem with using vi/emacs/awhtever editor, but the usre who will need to actually have his hands on the keyboard would probably not be able to use them. - Other similar features. "Allows me to focus on my work and forget as much as posible about the system internals", etc. Unfortunately, many professionals can't afford to take into consideration if the system is well-organized internally, or if it follows some strict policy, or if it is tested for a long time... They feel ok if it's "tested enough", and just wait for the security updates. - Marketing & related stuff. It's a big brand, and famous for being easy to use for people who don't want to know a lot about scripts & system internals. - The psychological effect of having new versions of their software every 6 months. Even professionals are affected, believe me! Also, (and this is my personal experience), the professional may not care, but there'll be a lot of pressure from the users to get new versions of things... I installed Debian on several boxes where I worked. In the beginning, all was fine (we even had a local mirror, and a repository for our own debs). After a while, some of the users (and those were developers -- really not the "clueless" type) wanted to move to Red Hat or Conectiva. Easier to manage (so they'd focus more on developing the applications they had to develop) and with newer software (docbook-xml, spamassassin, which needs new Perl, ssh [1], and other packages -- one guy even complained about the version of Apache in potato). > I question the claim that Red > Hat provides better support (average helpdesk personel couldn't have > helped me like (the archives of) this list have). I think there's also some psychological thing that goes on here. People think that with the help desk, they'll get an answer within a certain time, while nobody guatrantees that they'll get an answer on a mailing list. Also, you need to be careful when posting to a mailing list.. You're talking to volunteers who may just not help at all if you forget about etiquette. On the oher hand, help desk people already know that their customers may be quite angry when they call (well, the system isn't working!) Some people will of course prefer support from a mailing list, and all characteristics of Debian. Other just don't (or can't). > I can't > judge the system configuration system though. Consequently, I can't > think of any reason for using Red Hat other than not knowing > Debian (or fellow employees not knowing Debian). Well, as I said above, my experience is the opposite... Diversity is good. :-) J. [1] Although the version of ssh v1 in Debian is secure (with lots of patches), it would require other systems that talk to our system to use protocol version 1. And we can't guarantee that the Red Hat sshv1 is secure... But they needed to use it to access our network from home (or from other networks there), where the distro wasn't Debian. So I had to backport the version from Woody -- and keep following the security announces, and compiling it again every now and then. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]