Re: Patched sendmail? testing?
* stan [EMAIL PROTECTED] [20030305 03:54 PST]: On Tue, Mar 04, 2003 at 02:44:41PM -0800, Vineet Kumar wrote: * 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. I have, and I use it to update my HP-UX machines. I;m able to use FreeBSD's ports system to update those machines. I prefer to keep everything on the Debian machines handled by Debians excelent package management sytem. I have found thta when I go outside this mechanisim, I pay for it in the long run. Right, but another great thing about debian is that you can install your own stuff under /usr/local and not have to worry about getting it stomped on, or stomping on any of dpkg's toes. It's up to you whether running the cost you pay in the long run is greater with the stable + self-compiled perl modules vs testing/unstable. For most people adminning production systems, I think the answer is generally stable + some custom stuff, or stable + select packages pinned from testing/unstable. Of course, the decision is up to you. BTW, thanks for using proper attribution, quoting, and reply placement =) -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin And nice sig =) good times, Vineet -- http://www.doorstop.net/ -- http://www.anti-dmca.org/ signature.asc Description: Digital signature
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 07:53:16AM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. For example? What more recent Perl modules do you want, and why is dh-make-perl unacceptable? Is it possible that some mechanisim could be set up such that a package which has recieved a security related update in stable, could become the latest package for testing? You can point apt at security.debian.org/stable, and give it a high priority, then pull updates from there...Of course, this won't work either, as was nicely demonstrated by the number of people who tried, and then found that gnome was uninstallable on Sarge because they had a security-fixed version of perl from security.d.o. You need *people* to handle the security updates for Sarge. I'm not volunteering, are you? If you really, really want it, you could start backporting fixes from sid just like the security team does, and distribute fixes from your own server. You can even take the patches that the patches that the security team come up with and use them as the base for your work! It's a fucking huge amount of work though, which is why no one is doing it yet. -- Rob Weir [EMAIL PROTECTED]http://ertius.org/ pgp0.pgp Description: PGP signature
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 06:50:40AM -0500, stan wrote: On Tue, Mar 04, 2003 at 02:44:41PM -0800, Vineet Kumar wrote: * 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. I have, and I use it to update my HP-UX machines. I;m able to use FreeBSD's ports system to update those machines. I prefer to keep everything on the Debian machines handled by Debians excelent package management sytem. I have found thta when I go outside this mechanisim, I pay for it in the long run. apt-get install dh-make-perl, RTFM. Enjoy. PS: ispell is a spell checker. Use 'i' to call it from mutt. Your frequent spelling errors (to me) make your emails appear even more frenetic than you presumably intend them to be. -- Nathan Norman - Incanus Networking mailto:[EMAIL PROTECTED] What's needed is a certification system that separates those who can barely regurgitate what they crammed over the last few weeks from those who command secret ninja networking powers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 07:58:37AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:04:49PM -0600, Dave Sherohman wrote: On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. Heh... I never can quite figure out why people keep asserting that stable is too old for production systems. My servers are all running either woody (the current stable) or potato (the old stable (Oh my god! The software is three years old!)). Desktops are mostly RedHat 6 or so, with some potato, a very little woody, or X terminals connected to a potato server. I have yet to receive a single complaint from any of my users about the software being too old. While I can accept that there are some people who need the latest whiz-bang software to do their work, the vast majority of us don't. You may have made my point for me :-) Is the reason that you have RedHat dekstops to have more modern Gnome or KDE packages? Redhat 6 has the latest whiz-bang Gnome and KDE, or did you just forget to read? -- Nathan Norman - Incanus Networking mailto:[EMAIL PROTECTED] Great minds discuss ideas, average minds discuss events, small minds discuss people. -- Laurence J. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 08:20:16PM -0600, Jamin W. Collins wrote: On Tue, Mar 04, 2003 at 06:47:33PM -0500, Hall Stevenson wrote: * Jamin W. Collins ([EMAIL PROTECTED]) [030304 18:30]: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. In the MS Windows world, it is. Irrelevant. The discussion up to this point had little to nothing to do with MS Windows. It was a complaint about the lack of security support in testing, and an argument for the proven stability of testing was the uptime of a system. Then a conclusion was drawn from this uptime that the release was stable and therefore in dire need of support from the security team. I'm simply pointing out that uptime is a by product of stability, but not necessarily a valid (or even useful) indicator of it presence. Especially since uptime is 99% kernel; the rest of the distribution doesn't matter unless you *really* screw it up. We could release any old pile of rubbish if this was the only criterion. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Wed, 2003-03-05 at 03:11, Colin Watson wrote: On Tue, Mar 04, 2003 at 08:20:16PM -0600, Jamin W. Collins wrote: On Tue, Mar 04, 2003 at 06:47:33PM -0500, Hall Stevenson wrote: * Jamin W. Collins ([EMAIL PROTECTED]) [030304 18:30]: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. In the MS Windows world, it is. Irrelevant. The discussion up to this point had little to nothing to do with MS Windows. It was a complaint about the lack of security support in testing, and an argument for the proven stability of testing was the uptime of a system. Then a conclusion was drawn from this uptime that the release was stable and therefore in dire need of support from the security team. I'm simply pointing out that uptime is a by product of stability, but not necessarily a valid (or even useful) indicator of it presence. Especially since uptime is 99% kernel; the rest of the distribution doesn't matter unless you *really* screw it up. We could release any old pile of rubbish if this was the only criterion. Cheers, -- Colin Watson [EMAIL PROTECTED] A point not raised in this thread is that this lack of an update to Testing at this point between releases is primarily the effect of the lack of packages being able to move from Unstable due to dependency problems - normally the differences between the two would be sufficiently nominal that those running testing that were sufficiently concerned could pull the package from Unstable with at worst only a couple of dependencies. This presently is more akin to the latter part of an extended freeze, although even there, security patches would be entered into Testing as necessary. All that said, this software is offered for use under NO warranty of its performance, completeness or security, under any release or pool - only the endeavour that the security problems in the stable pool will be addressed where solutions can be applied, as discovered and addressed. I accept that for the huge price I pay to license all of this software for my use (nada) and do what I can in terms of communications with the BTS to help in the massaging involved in polishing and completing software for the next release. A reasonable trade-off thus far. -- Mark L. Kahnt, FLMI/M, ALHC, HIA, AIAA, ACS, MHP ML Kahnt New Markets Consulting Tel: (613) 531-8684 / (613) 539-0935 Email: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 08:11:29AM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 08:20:16PM -0600, Jamin W. Collins wrote: On Tue, Mar 04, 2003 at 06:47:33PM -0500, Hall Stevenson wrote: * Jamin W. Collins ([EMAIL PROTECTED]) [030304 18:30]: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. In the MS Windows world, it is. Irrelevant. The discussion up to this point had little to nothing to do with MS Windows. It was a complaint about the lack of security support in testing, and an argument for the proven stability of testing was the uptime of a system. Then a conclusion was drawn from this uptime that the release was stable and therefore in dire need of support from the security team. I'm simply pointing out that uptime is a by product of stability, but not necessarily a valid (or even useful) indicator of it presence. Especially since uptime is 99% kernel; the rest of the distribution doesn't matter unless you *really* screw it up. We could release any old pile of rubbish if this was the only criterion. I agree thta it is not -the only_ measuer of stability. However in this case, the stated uptime includes all apps (including X). So I think it's still a valid indication of the stability of the entire release (as used in this particular application). -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 03:31:57PM -0800, Osamu Aoki wrote: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Therfore it appears to me to be the best choice for a production machine, assumng that you need anything like current software packages (such as perl modules). Therefore it _should_ be scure! Stan, who are you and why you make such a demand? Did you donated $100,000,000 to SPI or Debian to dedicate 100 full time workers employed for you to be satisfied? I'm not making a demand. I _am_ making a sugestiuon as to what I beleive would improve Debian. I've been a happy user for years (and continue to be). I think on balance it's the best way to go for may of my machines, I run freeBSD on some of them, and the rest are Debian. Since I like this distribution, I would like to see it get even better. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 02:44:41PM -0800, Vineet Kumar wrote: * 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. I have, and I use it to update my HP-UX machines. I;m able to use FreeBSD's ports system to update those machines. I prefer to keep everything on the Debian machines handled by Debians excelent package management sytem. I have found thta when I go outside this mechanisim, I pay for it in the long run. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 09:53:18PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: On Tue, Mar 04, 2003 at 07:30:05PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 02:04:48PM -0500, stan wrote: Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. No it doesn't. It's designed to help developers get an idea of how close we are to having something releasable, and to make the release process itself easier. If some users find it useful, that's great - an added bonus. But you should still take care when using it on machines connected directly to the net (which, remember, is not anywhere close to all Debian systems). Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. We're trying, damnit. Excuse me if I implied anything but hat! I'm _extremely_ happy with all the good things that are being done _on a volunter_ basis_ within the Debian developer community. I have never meant to imply otherwise. If I hacve, the I herby retract such a stament,and apologize for it! That's nice. When resources (i.e. developers) come along who have the time and skill to start performing testing security updates, it'll be done: this came up on -devel fairly recently, and all the technical facilities to allow such updates to happen are there. Until then we can but admit once again that it's not ideal and shrug. I'm curious as to why it can't be done in conhunction with the stable security fixes? The fact that most of the developers working on stable security are already working completely flat out, perhaps? Is it possible that some mechanisim could be set up such that a package which has recieved a security related update in stable, could become the latest package for testing? I'm trying to think of a way to leverage the fact the security issues _are_ being addressed in stable into the testing regim. Perhpas someone who understands the Debian packagin system better than I could comment on whether this makes sense or not? -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 11:08:21PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 09:53:18PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. We're trying, damnit. Oh, also, it is far from obvious to me that perl 5.8.0 is yet stable enough for production use. For instance, its behaviour of interpreting input streams as UTF-8 in UTF-8 locales is being changed upstream in response to many bug reports (particularly from Red Hat 8.0 users, since that shipped with a UTF-8 locale as the default), and the new safe signals implementation has caused some problems which mean that the next upstream release will allow them to be turned off. I'm avoiding shipping anything later than perl 5.6.1 with our products at work, perl 5.6.1 is still formally supported, and it's a rare module that can't be built for it. OK, I've not had any problems whatsover with the version of perk that's in testing. Now I don't stress the internationalization issues, or the threading issues. I was actully more refering to the latest perl modules, which tend to have enhancements, and bug fixes failry often, rather than per itslef. So I think your example nicely demonstrates that current is not stable, and that lightning-fast integration of brand new upstream releases into Debian stable is not necessarily what people using Debian in production actually need. Version numbers are not everything. If you want something newer for some specific case, then you've always got the source. Perhpas not. But examples are just that. A means to point out a basic issue. They are never perfect. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 06:04:49PM -0600, Dave Sherohman wrote: On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. Heh... I never can quite figure out why people keep asserting that stable is too old for production systems. My servers are all running either woody (the current stable) or potato (the old stable (Oh my god! The software is three years old!)). Desktops are mostly RedHat 6 or so, with some potato, a very little woody, or X terminals connected to a potato server. I have yet to receive a single complaint from any of my users about the software being too old. While I can accept that there are some people who need the latest whiz-bang software to do their work, the vast majority of us don't. You may have made my point for me :-) Is the reason that you have RedHat dekstops to have more modern Gnome or KDE packages? I really don't want to get nto the rpm *^LL biz! -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 04:17:50PM -0500, Travis Crump wrote: stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: sigh Someone else running testing in a production environment. And my choices are? As I see them. 2. Run stable and have 1970's versions of software/ woody has the exact same versions[except with security updates] of software that testing had 8 months ago. 8 months ago you were running testing and were happy. Have your needs changed since then? No. But if you go back one major release, how old were the stable packages at the end of that cycle? Old, as I recall! -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 07:58:37AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:04:49PM -0600, Dave Sherohman wrote: Desktops are mostly RedHat 6 or so, with some potato, a very little woody, or X terminals connected to a potato server. I have yet to receive a single complaint from any of my users about the software being too old. You may have made my point for me :-) Is the reason that you have RedHat dekstops to have more modern Gnome or KDE packages? Nope. They're Red Hat because that's what they were running two years ago[1] when I took over this network and I can't be bothered to wipe them and install Debian. They work, the users don't care how old the software is, so why try to fix what's not (visibly) broken? I really don't want to get nto the rpm *^LL biz! Me neither. That's why I tend to ignore them and just wait for the hardware to fail so I can replace them with Debian boxes or X terminals. [1] Or would that make them 5.x rather than 6.x? My inability to recall which version of RH they're running says a bit about how often I need to deal with them... -- The freedoms that we enjoy presently are the most important victories of the White Hats over the past several millennia, and it is vitally important that we don't give them up now, only because we are frightened. - Eolake Stobblehouse (http://stobblehouse.com/text/battle.html) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 07:53:16AM -0500, stan wrote: Is it possible that some mechanisim could be set up such that a package which has recieved a security related update in stable, could become the latest package for testing? I'm trying to think of a way to leverage the fact the security issues _are_ being addressed in stable into the testing regim. Perhpas someone who understands the Debian packagin system better than I could comment on whether this makes sense or not? Wouldn't work, for reasons not particularly related to the packaging system itself. Consider: Right now, the current stable version of exim is 3.35. The current testing version of exim is 3.36. exim 3.36 may or may not incorporate features which are not present in version 3.35. If it does and if the packaging system were to declare a security-patched 3.35 to be more current than testing's 3.36, any sites which run testing and use those features will break. Your idea could probably work if stable and testing are both based on the same upstream revision (although I wouldn't be terribly surprised to find that there are cases where it still wouldn't), but it would definitely be likely to cause problems when testing has a more recent upstream version than stable. -- The freedoms that we enjoy presently are the most important victories of the White Hats over the past several millennia, and it is vitally important that we don't give them up now, only because we are frightened. - Eolake Stobblehouse (http://stobblehouse.com/text/battle.html) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
Colin Watson wrote: the new safe signals implementation has caused some problems which mean that the next upstream release will allow them to be turned off. Argh. Do you know if that is a compile-time switch or a run-time switch? I've had some very fun debugging sessions based on perl's signal handling changes and the only thing worse than having to deal with the current safe signals would be making my programs have to deal with both sorts. -- see shy jo pgp0.pgp Description: PGP signature
Re: Patched sendmail? testing?
On Wed, Mar 05, 2003 at 05:05:05PM -0500, Joey Hess wrote:
Colin Watson wrote:
the new safe signals implementation has caused some problems which mean
that the next upstream release will allow them to be turned off.
Argh.
Do you know if that is a compile-time switch or a run-time switch? I've
had some very fun debugging sessions based on perl's signal handling
changes and the only thing worse than having to deal with the current
safe signals would be making my programs have to deal with both sorts.
Fear not; I believe that it'll be controlled by $ENV{PERL_SIGNALS} being
'unsafe' or 'safe'. All the other syntactic tricks that were proposed
seemed to blow up on older versions of perl, which would have defeated
the point.
(The signature was the implementor's frustrated summary on trying to get
anyone to agree on what the switch should be ...)
--
Colin Watson [EMAIL PROTECTED]
My suggestion is that we create a new programming language for the
purpose, written completely in Akkadian cuneiform, Nepalese, and
backwards. -- Jarkko Hietaniemi, perl5-porters
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. What's the story? http://www.debian.org/security/faq#testing -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. -- Marc Wilson | When God saw how faulty was man He tried again and [EMAIL PROTECTED] | made woman. As to why he then stopped there are | two opinions. One of them is woman's. -- DeGourmont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ 3. Run something besidse Debian. Am I missing a choice here? -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. Look: 13:58:15 up 249 days, 5:48, 1 user, load average: 0.35, 0.32, 0.36 [EMAIL PROTECTED]:~# cat /etc/debian_version testing/unstable This is a amchien providing production related process control information in a paper mill. The uptime would be longer, but I had a bug in my software that was generating zombies, and ahd to reboot to clean up that mess. That's certainly stab;eenough for em. And it gets apt-get dist-upgraded pretty much every weekday morning. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? Sounds like bad allocation of resources to me! -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 02:04:48PM -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. How does a lack of security update support make the testing release useless? IIRC, the purpose of the testing release was to ensure that pacakges interoperated properly help prepare for the next stable release. In other words it's for testing. That seems pretty clear to me that it's not intended for production use. Per the Debian releases page: The ``testing'' distribution contains packages that haven't been accepted into a ``stable'' release yet, but they are in the queue for that. The main advantage of using this distribution is that it has more recent versions of software, and the main disadvantage is that it's not completely tested and has no official support from Debian security team. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? You make it sound like it was taken away. TMK, it's never been there. Sounds like bad allocation of resources to me! Testing is almost always a moving target. Stable on the other hand is not. Ideally, at some point security support for testing would be a good thing to have. However, I'd hardly call the lack of security support for it to be bad allocation of resources. -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
At 02:04 PM 3/4/2003 -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. Look: 13:58:15 up 249 days, 5:48, 1 user, load average: 0.35, 0.32, 0.36 [EMAIL PROTECTED]:~# cat /etc/debian_version testing/unstable This is a amchien providing production related process control information in a paper mill. The uptime would be longer, but I had a bug in my software that was generating zombies, and ahd to reboot to clean up that mess. That's certainly stab;eenough for em. And it gets apt-get dist-upgraded pretty much every weekday morning. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? Sounds like bad allocation of resources to me! Sounds like that machine could function without internet access and therefore probably not need to be concerned about this sendmail vulnerability. If it does need outside access, say for allowing you to remotely reach it, does it need to run sendmail also ?? Couldn't a smaller, simpler SMTP app work okay ?? I guess this particular issue with sendmail patches being available in testing isn't your real complaint though... Hall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 02:04:48PM -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. No it doesn't. It's designed to help developers get an idea of how close we are to having something releasable, and to make the release process itself easier. If some users find it useful, that's great - an added bonus. But you should still take care when using it on machines connected directly to the net (which, remember, is not anywhere close to all Debian systems). So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? Sounds like bad allocation of resources to me! That's nice. When resources (i.e. developers) come along who have the time and skill to start performing testing security updates, it'll be done: this came up on -devel fairly recently, and all the technical facilities to allow such updates to happen are there. Until then we can but admit once again that it's not ideal and shrug. (BTW, allocation of resources? How on earth do people think this works in a volunteer project? People allocate *themselves*.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, 4 Mar 2003, stan wrote: [snip] 13:58:15 up 249 days, 5:48, 1 user, load average: 0.35, 0.32, 0.36 [EMAIL PROTECTED]:~# cat /etc/debian_version testing/unstable [snip] That's certainly stab;eenough for em. And it gets apt-get dist-upgraded pretty much every weekday morning. To my understanding, this is the wrong way to think about stability. It's not a question of whether the OS is stable as in not-crashing. It's a question of whether the versions of software included in the release will be changing or not. That is, whether the collection of packages is stable or not. Running the unstable distribution, AFAIK, just suggests that the versions may change on you, not that it's likely to crash. ap -- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 01:18:27PM -0600, Jamin W. Collins wrote: On Tue, Mar 04, 2003 at 02:04:48PM -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. How does a lack of security update support make the testing release useless? IIRC, the purpose of the testing release was to ensure that pacakges interoperated properly help prepare for the next stable release. In other words it's for testing. That seems pretty clear to me that it's not intended for production use. Per the Debian releases page: The ``testing'' distribution contains packages that haven't been accepted into a ``stable'' release yet, but they are in the queue for that. The main advantage of using this distribution is that it has more recent versions of software, and the main disadvantage is that it's not completely tested and has no official support from Debian security team. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? You make it sound like it was taken away. TMK, it's never been there. Sounds like bad allocation of resources to me! Testing is almost always a moving target. Stable on the other hand is not. Ideally, at some point security support for testing would be a good thing to have. However, I'd hardly call the lack of security support for it to be bad allocation of resources. Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Therfore it appears to me to be the best choice for a production machine, assumng that you need anything like current software packages (such as perl modules). Therefore it _should_ be scure! -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 02:25:38PM -0500, Hall Stevenson wrote: At 02:04 PM 3/4/2003 -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. Look: 13:58:15 up 249 days, 5:48, 1 user, load average: 0.35, 0.32, 0.36 [EMAIL PROTECTED]:~# cat /etc/debian_version testing/unstable This is a amchien providing production related process control information in a paper mill. The uptime would be longer, but I had a bug in my software that was generating zombies, and ahd to reboot to clean up that mess. That's certainly stab;eenough for em. And it gets apt-get dist-upgraded pretty much every weekday morning. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? Sounds like bad allocation of resources to me! Sounds like that machine could function without internet access and therefore probably not need to be concerned about this sendmail vulnerability. If it does need outside access, say for allowing you to remotely reach it, does it need to run sendmail also ?? Couldn't a smaller, simpler SMTP app work okay ?? Ture on both counts. I guess this particular issue with sendmail patches being available in testing isn't your real complaint though... Exaclty. 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. So, I would like to be able to beleove that a amchine running testing is at least reasoably secure. -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 07:30:05PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 02:04:48PM -0500, stan wrote: On Tue, Mar 04, 2003 at 05:02:10PM +, Colin Watson wrote: That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. (It's not an ideal situation, true. However, it's reality.) Not idael at all. As a matter of fact, it makes the whole concept of a testing release pretty useless. No it doesn't. It's designed to help developers get an idea of how close we are to having something releasable, and to make the release process itself easier. If some users find it useful, that's great - an added bonus. But you should still take care when using it on machines connected directly to the net (which, remember, is not anywhere close to all Debian systems). Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. So, we have a pretty stable release good enough IMHO for real production work. But we choose to cripple it by not providing security updtaes? Sounds like bad allocation of resources to me! That's nice. When resources (i.e. developers) come along who have the time and skill to start performing testing security updates, it'll be done: this came up on -devel fairly recently, and all the technical facilities to allow such updates to happen are there. Until then we can but admit once again that it's not ideal and shrug. I'm curious as to why it can't be done in conhunction with the stable security fixes? -- They that would give up essential liberty for temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: sigh Someone else running testing in a production environment. And my choices are? As I see them. 2. Run stable and have 1970's versions of software/ woody has the exact same versions[except with security updates] of software that testing had 8 months ago. 8 months ago you were running testing and were happy. Have your needs changed since then? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, 04 Mar 2003, Colin Watson wrote: On Tue, Mar 04, 2003 at 11:32:34AM -0500, stan wrote: On Tue, Mar 04, 2003 at 06:15:02AM -0800, Marc Wilson wrote: On Tue, Mar 04, 2003 at 08:37:02AM -0500, stan wrote: I did apt-get update and apt-get dist-upgrade on some of my machines running testing, and I was surprised to not [pull patched sendmail binaries, based upon the announcement of a vulnerability in it yesterday. Testing doesn't have security updates, and has never been advertised as having security updates. Are you volunteering? sigh Someone else running testing in a production environment. And my choices are? As I see them. 1. Run unstable, and have a broken system more often than not. 2. Run stable and have 1970's versions of software/ That's a hopeless exaggeration; I run stable happily on my home server. Anyway, if you run testing you need to manage the security yourself by backporting patches. I don't believe anyone will ever have told you otherwise. Just to join in... I'm typing this on a hopelessly crufty old IBM ThinkPad 570, running unstable. I happen to admin several machines running Stable, doing such things as application servers, database servers, development sandoxes, firewalls, and difficult-to-identify needed machines. Unstable is sometimes screwed up. Not for long, but it happens. My fonts under X are still fucked; when I have time, I'll make Gnome apps and mozilla happy. Stable environments are that. Security patches are there when needed. The latest version of YAWebSearchEnginePHP aren't. And I don't care that they aren't. For my desktop, Unstable is great. Sure, it is buggy sometimes. I've run Windows when it was buggy sometimes. For servers, Stable is great. I sometimes build daemons more current, and it still is a lot more pleasant than doing so under Solaris, AIX or, honestly, under FBSD (this from a serious FreeBSD fan.) If you broke your box running unstable, ask around and you can get answers to fix it. There's a reason why it is called unstable. Sorry, I'm in a bad mood. -j -- Jamie Lawrence[EMAIL PROTECTED] You're young, you're drunk, you're in bed, you have knives - shit happens. - Angelina Jolie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Therfore it appears to me to be the best choice for a production machine, assumng that you need anything like current software packages (such as perl modules). Therefore it _should_ be scure! Stan, who are you and why you make such a demand? Did you donated $100,000,000 to SPI or Debian to dedicate 100 full time workers employed for you to be satisfied? Instead of flaming us, would you like to send a patch for it? Really, if fixed version is available in unstable, just compile it yourself. testing are for testing. I think once GCC issues get resolved, things will move. Priorities of testing security fixes are low and there are much more things to fix before warring it. So relax. Use stable or take care them by your self. No one get paid by you to maintain your box the way you want it. Osamu PS: I am anxious to see testing getting new softwares from unstable. And I think flavor discussion in debian-vote seems very exciting thing for me. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED] Cupertino CA USA, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' Our Priorities are Our Users and Free Software --- Social Contract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
* 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
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: On Tue, Mar 04, 2003 at 01:18:27PM -0600, Jamin W. Collins wrote: Testing is almost always a moving target. Stable on the other hand is not. Ideally, at some point security support for testing would be a good thing to have. However, I'd hardly call the lack of security support for it to be bad allocation of resources. Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. Therfore it appears to me to be the best choice for a production machine, The testing release is not, TMK, intended for use in any production environment. To do so, is do it at your own risk. This is clearly stated in several places. assumng that you need anything like current software packages (such as perl modules). I can't say that I'd move a system to the testing release just for updated perl packages. Therefore it _should_ be scure! No, if you want provided security updates, run stable. -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 09:53:18PM +, Colin Watson wrote: On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. We're trying, damnit. Oh, also, it is far from obvious to me that perl 5.8.0 is yet stable enough for production use. For instance, its behaviour of interpreting input streams as UTF-8 in UTF-8 locales is being changed upstream in response to many bug reports (particularly from Red Hat 8.0 users, since that shipped with a UTF-8 locale as the default), and the new safe signals implementation has caused some problems which mean that the next upstream release will allow them to be turned off. I'm avoiding shipping anything later than perl 5.6.1 with our products at work, perl 5.6.1 is still formally supported, and it's a rare module that can't be built for it. So I think your example nicely demonstrates that current is not stable, and that lightning-fast integration of brand new upstream releases into Debian stable is not necessarily what people using Debian in production actually need. Version numbers are not everything. If you want something newer for some specific case, then you've always got the source. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
* Jamin W. Collins ([EMAIL PROTECTED]) [030304 18:30]: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: On Tue, Mar 04, 2003 at 01:18:27PM -0600, Jamin W. Collins wrote: Testing is almost always a moving target. Stable on the other hand is not. Ideally, at some point security support for testing would be a good thing to have. However, I'd hardly call the lack of security support for it to be bad allocation of resources. Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. In the MS Windows world, it is. There, all too often a process will cause the entire machine to lock up requiring a reboot, and losing your uptime. In the *nix world, you're often lucky enough to be able to kill the specific process that's hung up and not have to reboot the machine. I use Windows every day and I *wish* that the little End Task button was enough, but it's usually not. :-( Hall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 04:11:02PM -0500, stan wrote: Well, then shouldn't it allow stable to be released often enough that it acn be used in production For instance how old are the prel modules, and devlopment environment in it? Ancinet by modern standards. Heh... I never can quite figure out why people keep asserting that stable is too old for production systems. My servers are all running either woody (the current stable) or potato (the old stable (Oh my god! The software is three years old!)). Desktops are mostly RedHat 6 or so, with some potato, a very little woody, or X terminals connected to a potato server. I have yet to receive a single complaint from any of my users about the software being too old. While I can accept that there are some people who need the latest whiz-bang software to do their work, the vast majority of us don't. -- The freedoms that we enjoy presently are the most important victories of the White Hats over the past several millennia, and it is vitally important that we don't give them up now, only because we are frightened. - Eolake Stobblehouse (http://stobblehouse.com/text/battle.html) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patched sendmail? testing?
On Tue, Mar 04, 2003 at 06:47:33PM -0500, Hall Stevenson wrote: * Jamin W. Collins ([EMAIL PROTECTED]) [030304 18:30]: On Tue, Mar 04, 2003 at 04:05:37PM -0500, stan wrote: Moving target or not, I think 200+ day uptimes ina 24x7 production environment say something about teh :stability of the testing release. Stability isn't just a matter of uptime. In the MS Windows world, it is. Irrelevant. The discussion up to this point had little to nothing to do with MS Windows. It was a complaint about the lack of security support in testing, and an argument for the proven stability of testing was the uptime of a system. Then a conclusion was drawn from this uptime that the release was stable and therefore in dire need of support from the security team. I'm simply pointing out that uptime is a by product of stability, but not necessarily a valid (or even useful) indicator of it presence. -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
