On Wed, 14 Jan 2004 09:56:35 EST, Fred Whipple writes: I'll answer just the points I have opinions/knowledge on. >2.) A related reason we used Red Hat was that practically anything you >could want to use was pre-packaged in a simple to install RPM. And they >were typically pretty high quality RPM's, and very often well >maintained. Do admins typically find that they're able to find Debian >packages for most software they're typically interested in using? I >realise this varries greatly between markets, but I guess what I'm >asking is do you usually find 70% of the packages you're interested in >in Debian package format, and well maintained? 80%? Just a general idea. Debian uses the .deb package format. I'd guess that well over 90 % of the software we need can be found pre-packaged (and well-maintained) as .deb's. >3.) I read quite a bit of the Web site, and see that in general, >releases seem to be very far and few between. This is advantageous to >ISP's, of course, because we want things to just "work". Is my >perception correct in that releases are far apart? "Stable" releases are quite far apart, yes. > When is the next >release expected? How significant is the difference from, say, 3.0 and >3.1. Can you just install a bunch of packages and call it an upgrade, >or do you have to go through a whole ordeal as you do between Red Hat .X >versions? Upgrading to a new release is just an `apt-get dist-upgrade` away. I've personally upgraded a box through every release from 1.mumble to 3.0 . >4.) How long are previous versions maintainaned with patches and such? >Or to restate this, how long after a new version is released are you >FORCED to upgrade in order to maintain security? A couple months at least, usually about half a year. >How drastic are the >changes in between minor version increments (say, 3.0 to 3.1)? For >example, Red Hat has tended to make significant kernel upgrades and >glibc upgrades in minor version changes, and has caused significant >incompatibilities that have caught us by surprise. Debian focuses on security and stability in the "stable" branch, so there never should be any problems with that as long as you track "stable" (the "testing" and "unstable" releases are another matter, just as their names suggest). The trade-off, of course, is that new software (resp. new versions of software) takes its time to make it into the "stable" branch. >6.) And finally, if you care to toss in any ideas or info, I'm very >glad and excited to hear it. For instance, if you were going to switch >all your systems within the next year, would you choose something else? >A BSD port? Go back to Solaris? Novell? SCO? Just kidding. IMHO Debians main advantage is the packaging. You can track security-updates of _all_ installed packages with a simple `apt-get upgrade`, and there should never be any surprising side-effect to it. Re-installs of the system for upgrading purposes are unknown for Debian (unless you're upgrading _to_ Debian ;) ). Another advantage is that there's no "integrated" admin-tool which will destroy your precious hand-crafted config files, no "yast" or "suseconfig" or somesuch. The downside to that is that you have to know how to use an editor, of course, and there's mostly no "setup wizards" to guide you. Packages do, of course, come with mostly sensible (and secure) default configs, though. Should an upgrade have the necessity to change a config-file, it'll ask you if you want it to (it can also show you a diff first) or not. Plus. according to policy, there's at least a man-page for everything in *bin and /etc, and some documentation for _each&every_ installed package in /usr/share/doc/<package>. cheers, &rw -- / Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \ \ <rw@coretec.at> | T +43 1 503 72 73 | F +43 1 503 72 73 x99 /
Attachment:
pgpjQf_7Y8z4Q.pgp
Description: PGP signature