search for: summarili

I know I'm slightly OT here, asking about RHEL, but since Centos is now a part of RH, I'm hoping I won't be summarily ejected. I've seen several articles that listed Centos 6.x as vulnerable, but DID NOT LIST RHEL 6. I'd think that if Centos 6.x is vulnerable, then so would RHEL 6.x, since Centos is made from RHEL sources. Does anyone know for sure either way? thanks! --

On Thu, 19 Jun 2008 09:44:46 +0300, Török Edwin wrote: > Hi, > > Have you seen this: http://gcc.gnu.org/ml/gcc/2008-06/msg00385.html > There is a new branch for converting gcc to C++. > > Best regards, > --Edwin The sad thing is that they seem to be replacing one unsafe language with another, presumably with enormous effort. The only hopeful sign in that thread is the

Hi, Have you seen this: http://gcc.gnu.org/ml/gcc/2008-06/msg00385.html There is a new branch for converting gcc to C++. Best regards, --Edwin

Hi List, I have a dumb sendmail question, and I'm wondering if anyone can point me in the right direction (besides "sendmail list is two doors down on the left" ;-). One of our clients has a bunch of servers -- CentOS 5 -- that are on only a private network that's NATted to the outside world -- that is, those servers can initiate outbound connections fine, but don't

On Wed, Jul 2, 2008 at 2:13 PM, Hendrik Boom <hendrik at topoi.pooq.com> wrote: > On Thu, 19 Jun 2008 09:44:46 +0300, Török Edwin wrote: > >> Hi, >> >> Have you seen this: http://gcc.gnu.org/ml/gcc/2008-06/msg00385.html >> There is a new branch for converting gcc to C++. >> >> Best regards, >> --Edwin > > The sad thing is that they seem

On Fri, Sep 17, 2010 at 4:44 PM, David Chisnall <csdavec at swan.ac.uk> wrote: > On 17 Sep 2010, at 23:24, Chris Lattner wrote: >> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them. > > Because the major negative comment that is raised when I suggest people adopt clang is that they don't

On Sun, 16 Nov 2003, Reid Spencer wrote: > On Sun, 2003-11-16 at 11:17, Chris Lattner wrote: > > > No, it's all or nothing. Once linked, they cannot be seperated (easily). > > However, especially when using the JIT, there is little overhead for > > running a gigantic program that only has 1% of the functions in it ever > > executed... > > Perhaps in the

Gostaria de instalar o Centos 6.4 em um dl380e g8 com uma smart array b320i, na instala??o n?o possui drives por isso aparece que n?o h? discos dispon?veis, baixei os drives para red hat .dd do site da HP, como poderia carregar esses drives durante a instala??o? gravei eles em um pen drive. Obrigado. -- Sergio.Alex

Joel Hammer wrote on Friday, 6 June 2003 8:46 a.m.: > Which, BTW, is how we could easily stop all spamming. If we all > respond to the spammers, that would but them out of business in one > day. So, all of us on this list should agree to respond to the > spammer hitting us, telling him we are interested. That would make > these guys stop spamming this list. The problem with

On Wed, Jul 2, 2008 at 11:13 AM, Hendrik Boom <hendrik at topoi.pooq.com> wrote: > The sad thing is that they seem to be replacing one unsafe language with > another, presumably with enormous effort. > > The only hopeful sign in that thread is the proposal for using Cyclone > instead, starting here:http://gcc.gnu.org/ml/gcc/2008-06/msg00502.html > > But it is summarily

On Sun, 2003-11-16 at 11:17, Chris Lattner wrote: > No, it's all or nothing. Once linked, they cannot be seperated (easily). > However, especially when using the JIT, there is little overhead for > running a gigantic program that only has 1% of the functions in it ever > executed... Perhaps in the general case, but what if its running on an embedded system and the "gigantic

Hi, We would like to use openssh in fips mode. It looks it is not provided as a configurable option through sshd_config, Are there plans to do incorporate such change. Do we have to change openssh code for now until the option is provided. If sshd is operating in fipsmode, does it provide additional errors/audits to indicate failures such as pair wise consistency failed during on of the sshd

I've been working for a few hours to get RIFT running on my Mac Pro. I really don't want to have to get a full windows license to play the game so it seemed like a good alternative. So I pulled wine via macports (I did this today so I got wine-1.2.2). Then downloaded the game and got it patched (my wife has a Windows machine and a Rift account). This is where progress stopped. I find that

On 12/4/18 3:21 PM, John McCall wrote: > > On 4 Dec 2018, at 17:50, Philip Reames wrote: > > Skimming along, apologies if I'm repeating something which already > got said. > > If I understand this correctly, the basic problem we're trying to > solve is to use a local hint (the invariant.group) to make a > global assumption about other code

> -----Original Message----- > From: Alex Bradbury [mailto:asb at asbradbury.org] > Sent: Saturday, October 01, 2016 1:06 PM > To: Robinson, Paul > Cc: Renato Golin; Chris Bieneman; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] Require PRs for XFAILing tests > > On 28 September 2016 at 19:58, Robinson, Paul via llvm-dev > <llvm-dev at lists.llvm.org>

On 2/21/23 20:32, Eric Blake wrote: > On Tue, Feb 21, 2023 at 07:07:38PM +0100, Laszlo Ersek wrote: >> Well, given Daniel's comments meanwhile, it seems like the original >> execvp() is something we shouldn't fret about. :/ > > glibc marks execvp() and exevpe() as 'MT-Safe env', which means it > does not modify 'environ' and presumably does not use

On 17 May 2016 at 02:07, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Basically, the high-level status is: > 1. Commits should state when they are fixes. > 2. Bugs should be tracked in a PR. Yup. > None of these is a hard requirement but instead, best practices that we > should remind to the contributors. > For #1, I propose the attached patch for

On Mon, Dec 2, 2019 at 12:52 PM Philip Reames <listmail at philipreames.com> wrote: > Mehdi, David, > > I think you're both pointing out exceptions rather than the general rule. > I tried to indicate their might be reasonable exceptions (see the second > sentence past Mehdi's quote), but in general, particularly for new > contributors, I think it is important we

tl;dr The Debian Xen packages have had a very bad patch which I propose to simply drop, with minor compatibility implications, unless someone can explain what it is for and why it is still needed, and/or has a better plan. I have been going through delta queue in the Debian Xen package. I found a commit (patch) describing itself only this way:

https://bugzilla.samba.org/show_bug.cgi?id=3845 Summary: Add --remove-source-files Product: rsync Version: 2.6.9 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: hashproduct+rsync@gmail.com