This one time, at band camp, Fred Whipple said: > 1.) One of the biggest reasons we went with Red Hat many years ago was > RPM. Of course I know that Debian has a package system, and there're > constant arguments about which is better, if either. What I wonder, > though, is how they compare for the purposes of security checking. On a > Red Hat system, practically any file or directory outside of /home can > be found within the RPM database. We can check each and every file, its > MD5 hash, etc. It's like having a built-in Tripwire installation so > long as you trust the RPM database. We've modified the RPM installation > such that we can trust it more than we trust Tripwire. Do Debian > packages have similar security built-in? There is, for most packages, a file named /var/lib/dpkg/info/$package.md5sums, that contains exactly this. Some packagers do not like generating this file because they feel it wastes disk space or have other reasons. However, there is always an md5sum for the .deb itself in the corresponding Packages file, found at /var/lib/apt/lists/$url_Packages. > 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. I wouls say upwards of %90, roughly. The things I find not packaged for Debian are generally speaking proprietary software (like Realserver) or binary-only drivers for specialty hardware. Making your own .deb of these is usually trivial, however, so integrating them into the dpkg managed space is relatively painless. > 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? 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? At the moment, Debian seems to be releasing every couple of years, which is what I want at my job :) Many people complain that this is too far between, but I suspect they don't have to test upgrades of several hundred boxes, often located 100 miles or more away. The next release, code-named sarge, is expected relatively soon. It is difficult to tell exactly, but my perception is that we have presently basically frozen the toolchain, except for bugfixes. This means that the freeze for release is not far off, but this depends on many things, and so is notexactly predictable. Sorry that is not perfectly clear, but Debian being a volunteer organization means that a timeline is not always possible. > 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? 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. The last release (potato) was, IIRC, maintained by the security team for close to a year after the release of the current stable (woody). It may not always be that long, depending on their workload, but I would certainly count on 6 months or so. Debian stable releases, since they are usually years apart, do usually contain major version upgrades of lots of software. That being said, I have lived through several release cycles (and done several release upgrades at work, on strictly remote boxes), and it has been as minimally painful as possible. One of the usual tests maintainers are admonished to make is to make sure that their packages upgrade cleanly from the version in the current stable, and I have found that it mostly just works. There is always a release notes page on the website that details any extra steps that must be taken for the upgrade, for instance if libc6 or another package must be upgraded first, before upgrading everything else. The kernel itself will not be upgraded to a new version without your intervention, but it may be upgraded if a bugfix (for instance the do_brk fix) is backported into the _same_ kernel version that you are running. > 5.) Of course we'll be testing it extensively ourselves, but what would > you say the most significant differences, both from a user and an admin > perspective, are between Debian and <Brand X> Linux? Or, maybe better > stated, why Debian? I know that's a religeously charged question, but > at the moment our only position is "not RHL." We're open to being > converted ;-) Debian has three major things that drew me to it: It has the best FHS support of any of the distros I've found. On RedHat and other systems, applications are always installing themselves into strange places like /opt or /usr/local, while I expect distro programs to always be found in /bin or /usr/bin (and the corresponding /sbin's). Config files are always found in /etc (not /usr/local/etc or some strange place) and are carefully preserved across upgrades. The Bug Tracking System and the openness of the development model means that most bugs I have found are not only already reported by someone else, but usually already acknowledged and fixed by the time I have found them. The freeze before release also means that most bugs have a chance to be ironed out before the next stable is actually released, because they are found by people actually running the software. Then there is of course, the ideological part - Debian is about Free Software, and has a commitment to provide a quality distro to it's users. > 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. I guess the only thing I would add is that there are, of course, downsides to every project. Debian's downside for large companies is that it is a volunteer effort, and as such, there is no such thing as technical support available on a fee basis. There are the mailing lists, which are very helpful, and usually give me the answer I need faster than any technical has, but some companies may be turned off by that. On the other hand, since Debian is not for profit, it seems to me unlikely that it will dissappear out from under you because it is not making a profit, as RedHat has. So long as there are interested people, it will be around. HTH, and good luck, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
pgppvOtSEqHCR.pgp
Description: PGP signature