Nate, You make a good point. They are very handy, and becoming more and more practical as systems become more complex. At the same time, security is a *very* big deal to me, and I need to know exactly what is being done on my system. While debs may allow some customized install options, you still don't know if the binary is safe. For example, I believe Redhat 7 shipped with a broken MySQL package. I also usually require some different compilation options. Sometimes I prefer static vs. shared binaries, etc. When the source takes less than 5 minutes to ./configure and compile, it's hard to give up the functionality you get from source code. RPMs and DEBs are really only good for common configurations (say, Linux i686 with standard options, among others). My point is not being made for packages you make yourself. These are obviously customized already and you have good control over these. I guess it's just personal preference. Timothy On Thu, 26 Oct 2000, Nate Carlson wrote: > On Thu, 26 Oct 2000, Timothy Houck wrote: > > I couldn't help but grimace at your post. No offense. > > > > With such a system, I can see a whole new crop of cracker attacks as a > > result of such ever-user-friendly, "plug-and-play"ish packages. IMHO, > > there is a point at which a system automates itself beyond a safe point -- > > trying to be more friendly to inexperienced (lazy? maybe) users. This is > > the whole reason we have ridiculous things like macro viruses. > > Debian actually goes through and prompts you for configuration information > when you install deb's that require it. (eg, anything like exim, sendmail, > etc). And if you decline to configure it, the package will not start up > until you do. > > > In contrast, I would encourage the download and compilation of the > > sources. Aside from what's in the compiler itself, this is total > > control. As slick as debs or rpms are, I can't help but feel as though > > they're sloppy and a "lazy" method for running (supposedly) trusted > > executables. > > Why are they "sloppy" and "lazy"? For 99% of the programs, you end up with > the exact same binary that you would building it on your box. I agree that > you can run into problems (especially with RPM) of not having default > configurations that are insecure, but if you are a competant sysadmin, > only install the packages you need, and configure those packages properly, > you really end up with the same end result. > > Also, what about the issue of upgradability? Would you really want to go > around and compile everything on every box you admin? Would you really > want to have a compiler on, let's say, a production server? > > I occasionally get stuck doing routine upgrades for a large number of > (Redhat) boxes. Without RPM's, it would be a long and tedious > process. With RPM, I can just scp the RPM's over, and run rpm -Fvh > *.rpm.. of course, most of the RPM's I install are custom-rolled, to > guarantee that configuration will not be overwritten and such. --------------------------------------------------------------------- Timothy Houck thouck at thouck.com www.thouck.com --------------------------------------------------------------------- To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org For additional commands, e-mail: tclug-list-help at mn-linux.org