[FRsAG] Re: Toc toc un support de chez Gandi ?
On Thu, Mar 14, 2024 at 11:10 AM Laurent Barme <2...@barme.fr> wrote: > > Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit : > > Laurent Barme <2...@barme.fr> wrote on 14/03/2024 at 15:19:04+0100: > >> Cela dit, je suis d'accord sur le fait que la vente de certifs est un > >> ignoble racket, d'autant plus que ggl a réussi à imposer https tout > >> azimut, y compris pour des blogs diffusant des informations totalement > >> publiques, ce qui est une infamie rien qu'au niveau écologique ! > > Je suis ravi qu'on sécurise les connexions et la confidentialité des > > accès contre un overhead de quelques % (qui baisse avec le temps), > > quitte à ce que pour satisfaire les exigences écologiques des autres on > > essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les > > pages web et d'autres qui balourdent tout autant de volumes en > > publicités. > > > > Le gain écologique serait une dizaine de fois supérieur et notre confort > > en serait renforcé. > > > > Mais bon, YMMV > Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter > qu'il > est complètement inutile de "sécuriser" toutes les connexions ni de > protéger la > confidentialité des accès aux messages publicitaires. > Est-ce que ce n'est pas une protection contre une attaque MITM qui pourrait injecter n'importe quel JS dans un site en remplaçant une pub? En termes de confidentialité, les pubs qui me sont montrées dépendent de mes centres d'intérêt, intercepter toutes les pubs pourrait permettre de faire un profil de l'utilisateur potentiellement. -- Mehdi ___ Liste de diffusion du %(real_name)s http://www.frsag.org/
Re: [FRsaG] Ubuntu et Grub2
Salut, Le 21/07/2010 00:14, Olivier Bonvalet a écrit : Enfin ça, c'est la soupe Debian le coup du /etc/grub.d/ non ? En pratique rien ne t'empêche de trifouiller ton fichier de conf à la mano. Oui bien sur mais gare aux maj : le fichier de conf sera regénéré depuis /etc sans prévenir.. Mehdi ___ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Re: [FRsAG] Apache > restriction de traffic
Salut, > Pour moi, mod_evasive fait mal son travail puisqu'il agit trop tard > pour rejeter les bourrins : mod_evasive agit au niveau d'Apache, > autrement dit trop tard pour empêcher qu'Apache, l'élement actif, ne > se prenne de la charge. > > La solution pour moi réside dans Iptables avec le module limit. mod_evasive peut se coupler avec iptables et le blocage est alors réaliser en amont d'apache. L'intérêt que je vois par rapport à iptables+limit c'est que la détection se fait de manière plus fine :-) Mehdi ___ FRsAG mailing list FRsAG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
Re: [FRsAG] Long vie au 2.6.35 !
Hi, Le 18/10/2010 16:21, Greg a écrit : Un peu plus tard, on a passer ce frontal en 2.6.35, et vous pouvez constater le gain sur le load, qui est vraiment plus impressionnant que l'ajout de 12 cœurs X5680 !! A savoir quand même que les patchs de Google RPS et RFS ont été activés. Ce serait surtout intéressant de savoir "pourquoi" et quelle est la part seule du nouveau noyaux et des patchs :-) Mehdi ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Quel serveur choisir ?
Bonsoir, Celà dit sur un serveur 24 coeurs, on commence à voir d'autre limites : ce serveur bien qu'équipé de processeurs X5680 @3GHz, n'encaisse pas 4x la charge d'un serveur 6 coeurs cadencés @2.66GHz ... A voir ce qu'on appelle "charge"... Y a des IOs ? Des accès mémoire ? De la concurrence sur des lignes de cache ? etc. Par contre, certaines applications comme MySQL gèrent très mal plus de 4 coeurs, les performances se dégradent même ! Les choses s'améliorent considérablement avec MySQL à partir de la version 5.5 voir 5.1 patchée. En même temps on a tendance à plus considérer les IOs que le CPU pour les SGDBs non ? PS: ça existe encore les serveurs mono-core ? Quand même les smartphones commencent à être double-coeur ;-) Mehdi ___ Liste de diffusion du FRsAG http://www.frsag.org/