On 12/03/2008, Carl Wilhelm Soderstrom <[EMAIL PROTECTED]> wrote: > - It allows you to easily know when a security patch is available, by using > one of the managers like apt, up2date, yum, etc.
Unless the package has been abandoned by the packager, and you found out that there should have been a security package a year ago. You try to upgrade your package and found that even old versions of your package have completely disappeared. The only way to apply the patch is to compile it yourself, but you have no idea how the package was compiled. > - It allows you to install the exact same software binary to all your > machines. (If you were to compile from source there's a good chance for > human error to creep in and compile things differently on different > machines, leading to subtle errors which are _really_ hard to track down). This is very valid, but when you compile your own software you save your commands in a file, don't you? =) > - It allows you to install software faster (this is a big consideration when > managing dozens or hundreds of machines). Very true. > - It allows you to roll back to a previous version easily, if the new one > breaks things. Provided that you have saved the previous package yourself. If you did not do it and the package has been pulled, you are on your own. > - It gives you more assurance that the software will be compatible with your > already-existing software (Debian's quality control is much better than > mine would be). Unless they get the dependencies wrong. Which is not impossible. I have seen it both ways (dependency too specific, e.g., specifying apache instead of a web server; and missing dependencies altogether). Then you get a false sense of compatibility until you file a bug, and get told that you have not upgraded the whole package. This is not even rare. > - The packages often come with features compiled in by people who really > know what they're doing with the software, which you might not have > otherwise known about or been able to take advantage of. The reverse is also true, i.e., it contains extra features that deviate from the unpatched version that the original devs refuse to support you. And when you file bugs, do you file a bug to the original dev (which might ignore you unless you can prove that it's not a bug in your package), or do you file a bug to your packager? Do you need to check what kind of patches they have applied every time you file a bug? Can you understand all the patches? My experience with filing bugs with Debian is that it is a generally useless exercise. > - The packages make configuration simpler; especially in the case of dpkg, > by asking you some questions or giving you some warnings during the course > of installation. I don't find this true. Often, when I am asked the questions, unless I have already used the software before, I have no idea what they are talking about. I end up having to skip all the questions and later read the config file myself to figure out what has been asked. But, that said, I know I am not a good administrator, but not for the cited reason, and I don't believe the cited reason is valid for labelling someone a bad admin. -- cheers, -ambrose Yahoo and Gmail must die. Yes, I use them, but they still must die. PS: Don't trust everything you read in Wikipedia. (Very Important) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
