* stan <[EMAIL PROTECTED]> [20030304 13:11 PST]: > My point is that the testing release ahs proven to be stable in a > production environemnt (for me at least), and has, for example, much more > current perl modules, than stable. This is required for our software to > work.
Okay, so even if you've never used apt's pinning features (apt_preferences(5)), I find it hard to believe you've never heard of CPAN. > > So, I would like to be able to beleove that a amchine running "testing" is > at least reasoably secure. This doesn't follow. Well, I do believe that a machine running "testing" is reasonably secure. I also think that running it on a production, Internet-accessible machine is unreasonable ;-) As to the question of what you believe is reasonably secure, you're going to have to assess your security needs. If testing + cron + apt-get isn't enough (and it probably isn't), then Don't Do That. Maybe testing + debian-security-announce + deb-src/unstable + apt-get source -b is the right mix for your needs. If you want a rock, run stable. It's never been the flashiest, but it's always been the best. If you need something that's not in stable, you've always got /usr/local and/or pinning from testing/unstable, but with either of those choices, you're on your own for security. Nobody should just rely on the security team and forget about security anyway; as they say, it's a process, not a product. good times, Vineet -- http://www.doorstop.net/ -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin
signature.asc
Description: Digital signature
