It seems to me that blocking real users *who are running these shady
> apps* is perfectly reasonable.
How do you detect them? From my experience at other hosting places,
those IPs, just make a few request per hours or per day, with a standard
User Agent. As such it's difficult to differentiate them from normal
users.
The problem is that you suddenly have hundreds of thousands of requests
per hours from just a slightly lower number of IPs. And in the middle
you also have legit users using IPs from the same net block.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
e patches if needed.
[1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
ke v9 and 64bit are tightly
> coupled in the configury. how can this be setup to build a biarch
> compiler which defaults to v9/32bit?
v9 means 64 bits. You probably want to use v8plus instead, which
corresponds to 32-bit instructions on an UltraSparc CPU.
--
.''`. Aurelien Ja
rnel. For other kernels:
4. signal handler is called
5. signal handler does string operation
The GCC used to compile the kernel doesn't matter. Using gcc 4.3 to
compile the user code triggers the bug.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
ers on x86/x86_64
>> platforms for both Linux and BSD systems will mysteriously (to the users)
>> fail, and it doesn't matter whose fault it is.
>
> We didn't yet run into this issue and build openSUSE with 4.3 since more than
> three month.
>
The problem can be ea
H. Peter Anvin a écrit :
> Michael Matz wrote:
>> Hi,
>>
>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>
>>>> So I think gcc at least needs an *option* to revert to the old
>>>> behavior,
>>>> and there's a good argument to mak
On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
>
> Aurelien Jarno wrote:
> > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> > >ABI and the direction flag, that is it now assumes that the direction
> > >flag is cleared
in() {
signal(SIGUSR1, handler);
while(1)
{
asm volatile("std\r\n");
}
return 0;
}
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `'
