search for: summarily

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! -- ---- Fred Smith -- fredex a...

...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 proposal for using Cyclone instead, starting here:http://gcc.gnu.org/ml/gcc/2008-06/msg00502.html But it is summarily tossed out, without examination: http://gcc.gnu.org/ml/gcc/2008-06/msg00644.html If all we can ever use are languages that everyone knows, there will be no progress. -- hendrik

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

...ut don't have valid IPs / hostnames as far as the outside world is concerned. The problem is the hostnames of these machines don't exist in real DNS anywhere, so when they try to send mail to the outside world, other mail servers are seeing an invalid domain in the from address and summarily rejecting the messages (which makes sense). I need to figure out how to tell sendmail, when sending outbound messages, to use the domain name "example.com", instead of "subdomain.example.com". It would seem simple in /etc/mail/sendmail.mc: MASQUERADE_AS(`example.com')...

...t; 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 tossed out, without examination: > http://gcc.gnu.org/ml/gcc/2008-06/msg00644.html As it should be. > > If all we can ever use are languages that everyone knows, there will be > no progress. Who is we? I haven't seen any patches from you to GCC. I grepped all the Changelogs. In an...

...ng is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers. This post from another newsgroup I frequent is somewhat related and may give y...

...auses an out-of-memory condition? The JIT doesn't even load unreferenced functions from the disk, so this shouldn't be the case... (thanks to Misha for implementing this :) Also, the globaldce pass deletes functions which can never be called by the program, so large hunks of libraries get summarily removed from the program after static linking. > > There are multiple different ways to approach these questions depending on > > what we want to do and what the priorities are. There are several good > > solutions, but for now, everything needs to be statically linked. I >...

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

...rk. Granted, the "419" scammers usually have a proper return address so that they can get a response. What you should do in these cases (if you want to do something) is simultaneously report them to the FBI and to their ISP/email provider (eg. Hotmail), at which time their account will be summarily terminated, and if you're really lucky they will be prosecuted. 419 scams aren't just spam, they are illegal. Hopefully all unsolicited email will become illegal in enough states in the US to result in a massive legal attack against spammers shortly. This, coupled with the eventual fixing...

...t; 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 tossed out, without examination: > http://gcc.gnu.org/ml/gcc/2008-06/msg00644.html > > If all we can ever use are languages that everyone knows, there will be > no progress. Another perspective on this sort of issue, if you haven't seen it: http://weblogs.mozillazine.org/roc/archi...

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

..., status c0000135 So I went looking and while I have several d3dx9_*.dll files up to 42 but not 43. Is this because I should be using the "devel" version of wine? I've read that some people claim to have used winetricks to fix directx issues but I also saw someone's thread get summarily executed for using the program. So this is as far as I've gone. Any input on what I should do here?

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

...ails we'd want to see in a bug would be just as missing as if we had no XFAIL-to-PR link at all. Conversely, requiring short-term XFAILs to have their own PR means that if somebody fixed the test and forgot to close the PR, that dangling PR would be easy to recognize as something that could be summarily closed if anybody decided to go look at all the XFAIL-linked PRs. This scenario leaves an open PR kicking around, O the horror, but we have not lost any useful information. Now, I think it would be a great and useful thing for somebody to take on the role of PR Czar, to do that kind of sanitizati...

...licitly async-signal-safe". A laxer approach is "avoid calling anything that might interfere with particular resources". Unfortunately, this laxer approach, while it may require some "further caution" in case we want to call further functions in the affected context, quite summarily obviates this particular execvp() replacement. Plus, regarding said "further caution" in general, I'm getting the impression (from RHBZ#906468) that glibc's intent is actually the opposite -- i.e., the intent seems to be that any particular API should opt out of, rather than opt...

...e the proper path with a carrot, not a stick. If you file a bug (as per current community practices), and link your commits to it with a "fixes PR" message (as per current commit policy), we'll track your commit and make it a candidate for back-ports. If you don't, you'll be summarily ignored. Have a nice day. After all, we can't baby sit everyone that doesn't want to follow the rules that already exist. We could then use Bugzilla to mark to which release we'd like back-ported. We can use the "Version" field, or "Keywords". All of that easily aut...

...n expert is at your company, so be it. If not, that's fine too - I see lots of reviews by people at the same company that generally look pretty good & I don't think their the exception. I'd personally leave this part out - maybe some caveat about not doing internal review & then summarily approving externally? But that I think is more the exception than the rule & perhaps not worth including in the general practices document. But if you've seen several instances of this sort of issue that seem worth addressing through this mechanism - yeah, I'd be OK with an encouragemen...

...application the watch filtering effect could cause lost xenstore watch events. Luckily I think the only thing that is likely to pass this flag is the xenstore utilities in the Debian Xen packages and those are not complicated enough to be affected. I propose to resolve this situation in Debian by summarily dropping this patch in the next Debian stable release. (We will leave well enough alone in the previous two Debian releases.) I think the only user of XS_OPEN_DOMAINONLY is probably in src:xen itself. I also observe that, upstream, these flag values are not enclosed in ( ) as they clearly should...

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