En évitant la définition d'un opérateur ad-hoc qui rend, amha, la compréhension de la sémantique plus ardue. C'est un peu l'éternel débat des macros, quelles soient basiques comme en C ou puissante comme en LISP, ce qu'on gagne en lisibilité avec le sucre syntaxique, on le perd en compréhension de la sémantique…
Je conseillerais aussi rsync pour cela. De même, j'appuye le fait que le cache ne peut pas causer une pénurie de mémoire, donc vouloir le vider est une mauvaise idée (sinon c'est echo 3 > /proc/sys/vm/drop_caches…). Peut-être qu'ajouter de la swap pourrait résoudre ton problème ?
Concernant throttle, son utilisation est largement douteuse. Cela n'est pas parcequ'un process écrit à une certaine vitesse que le noyau va être plus ou moins chargé, va cacher plus ou moins, etc… Il faut garder en mémoire que pour ne pas exhiber des performances désastreuses, un FS combine les écritures de plusieurs activités en même temps.
Pour tester les conditions dans un pipe, apparemment bash possède l'option pipefail (set -o pipefail) qui fait l'affaire. Sinon, tu pourrais passer par un named-pipe, et tu lances tar en dernier. Genre mkfifo /tmp/fifo; gzip > out.gz < /tmp/fifo; tar cf - > /tmp/fifo.
De manière plus générale, je te conseillerais de rechercher la cause de l'erreur que tu rencontres, éventuellement en postant ici, au lieu de jouer à l'apprenti-sorcier. Car en prenant l'habitude d'essayer un truc au pif au lieu d'essayer de comprendre ce qui ne va pas, tu ne parviendras jamais à produire un système fiable.
edit: je m'adresse bien sûr à la deuxième personne à l'auteur de ce sujet.
1) Manifestement, les routes que route -n te sort ne correspond pas à ce que tu demandes. Peux-tu mettre la commande que tu as utilisée afin que nous te corrigions ?
2) il ne faut pas mettre de gateway pour le réseau local, cela n'a pas de sens.
Il faut sur pc1 et pc2 mettre pc3 comme gateway, soit comme route par défaut, soit pour le réseau 192.168.1. Idem pour pc4, sauf que l'on prendra évidemment l'ip/interface de pc3 qui est sur le bon subnet.
Je trouve son exemple est très pertinent au contraire. Si on applique ton raisonnement, la plupart des projets de logiciels libres mettent en place des DRM parce qu'ils mettent en place des "mesures de protection technique", le plus communément une clef ssh, pour limiter la modification de code (donc du fonctionnement) à des personnes approuvées. C'est complètement absurde comme idée, n'est-ce pas ?
Une distribution de type "live" n'est pas nécessaire. On peut utiliser une distribution ordinaire. Si cela n'était pas déjà le cas, il faudrait simplement mettre un maximum de drivers dans l'initrd et s'assurer que grub et fstab utilisent des identifiants stables de type label ou uuid pour référencer les disques ou les partitions.
Primo: ça n'est pas l'OS livré avec le téléphone, le "defaultOS", mais un autre, probablement pour les raisons évoquées par ariasuni.
Deusio: il y a un gros blob compressé de 60M qui contient tout un tas de trucs. "Ouvert", il faut le dire assez vite quand même…
Mais bon admettons, ça en fait un qui livre des instructions de compilation avec une partie des sources. Très certainement un exemple à suivre même s'il on peut faire mieux. Malheureusement, actuellement cela reste l'exception.
Android n'est pas libre dans l'immense majorité des cas. Montre moi ne fut-ce qu'un constructeur qui donne l'ensemble des sources accompagnées des recettes de compilation ? Bref vouloir positionner Mozilla, Android et Apple au même point sur la ligne qui va de plus à moins de libertés, c'est un peu fort de café.
Mode je peux aussi anticiper ton prochain argument: oui effectivement il n'y a aucun matériel libre pour le grand publique, et alors c'est pour cela que l'on doit accepter des restrictions supplémentaires (dit d'une manière polie) ?
-> Il est à off par défaut
-> L'utilisation de mod_authz_host le met à Double
Je copie ici le problème de perf de cette configuration, tel que décrit par la doc:
The default is Off in order to save the network traffic for those sites that don't truly need the reverse lookups done. It is also better for the end users because they don't have to suffer the extra latency that a lookup entails. Heavily loaded sites should leave this directive Off, since DNS lookups can take considerable amounts of time.
Ce document répond même à mon interrogation (plus bas) de faire le resolve de manière asynchrone uniquement pour le log.
The utility logresolve, compiled by default to the bin subdirectory of your installation directory, can be used to look up host names from logged IP addresses offline.
Donc bref, Use the Doc first, Luke! puis si ça ne répond pas à ta question change de programme ou "Use the source".
Posté par benja .
En réponse au message blockage plage d'ip.
Évalué à 1.
Dernière modification le 06 août 2016 à 04:17.
(enfin bon, à piori, il est concevable qu'apache fasse la résolution inverse pour et uniquement pour le log de manière asynchrone sans impacter le temps de réponse ni la qualité de service mais en ayant d'autres inconvénients, de part la nature asynchrone de cette opération; use the source, Luke).
Exemple, une adresse 10.1.2.3, par convention, est une adresse privée ("non routable" sur internet!) de classe A. La longueur de son préfixe vaut 8. Sont masque en binaire est 1111111.00000000.00000000.00000000, soit en décimal, 255.0.0.0. L'adresse 10.2.2.3 fait partie de ce réseau car lorsque le maque est appliqué, on obtient 10.0.0.0 qui est aussi l'adresse du réseau.
Oublié de dire dans ce paragraphe que l'adresse de "ce réseau" vaut 10.0.0.0/8.
Par rapport au logage (c'est comme cela qu'on dit en français ?) du nom d'hôte, c'est, bien vu, une très mauvaise idée de faire, pour les même raison que déjà exposées.
Sans répondre à cette question spécifiquement, laisse moi te dire que ça serait une mauvaise idée car pour chaque requête ton apache va devoir faire une résolution DNS inverse (c'est comme cela qu'on appelle trouver un nom qui correspond à une adresse IP) et donc tu ajoutes un délais avant de répondre au client (qu'il soit légitime ou non) dans les meilleures des cas, un très long délais (voire une erreur ? à confirmer…) dans le pire des cas où les serveurs DNS serait down ou inaccessibles.
Généralement, on fait un blocage avec un pare-feu, C'est plus facile à gèrer, on ne doit pas relancer apache à chaque modification. Et là, il est encore plus inconcevable de faire une résolution inverse !
Ensuite, une plage IP n'a aucune relation avec un domaine, je précise vu cette nouvelle question, au càs où…
Pour le reste, la doc apache doit répondre à ta question.
Un réseau au sens IP du terme est la plage d'adresse couverte par un masque, Lorsque ce masque est appliqué à une adresse, on obtient l'adresse du réseau, elle est identique pour chaque membre de ce réseau.
Un masque est une série de bit à 1, appelé le préfixe, suivi d'une série de zéros. En IPv4, la classe A correspond à une série de 8 bit à "1" suivit de 32-8 = 24 zéros, la classe B de 16 "1" et la classe C de 24 "1". La notation CIDR est la notation "sans classe". C'est à dire que la longueur du masque est choisie de fonction arbitraire et est dénotée avec un /XX; là ou avec les classes la longueur du préfixe était établie en fonction de l'adresse réseau par une convention RFC.
Exemple, une adresse 10.1.2.3, par convention, est une adresse privée ("non routable" sur internet!) de classe A. La longueur de son préfixe vaut 8. Sont masque en binaire est 1111111.00000000.00000000.00000000, soit en décimal, 255.0.0.0. L'adresse 10.2.2.3 fait partie de ce réseau car lorsque le maque est appliqué, on obtient 10.0.0.0 qui est aussi l'adresse du réseau.
Maintenant imagine que tu veuilles diviser ton réseau 10.x.x.x en deux, et mettre un routeur afin que chaque moitié doive passer par ce routeur pour dialoguer avec l'autre moitié. La solution est de passer en sans-classe et d'augmenter ton préfixe d'un bit. En d'autres mots, tu divises ta plage d'adresses entre le réseau réseau 10.0.0.0/9 et le réseau 10.128.0.0/9, Le masque devient en binaire 1111111.1000000.00000000.00000000, en décimal : 255.128.0.0 ou, plus simplement, /9.
10.1.2.3 appartient au premier réseau, 10.200.1.2 au deuxième.
Pour en revenir à ta config d'apache, en gros l'algorithme "j'applique le masque et je regarde si l'adresse est celle du réseau" est ré-utilisé pour le contrôle d'accès, il est logique donc d'utiliser cette notation bien établie.
Le problème est que avec sa méthodologie on sait rarement déterminer l'origine des différences car il change plusieurs paramètres en même temps. Genre il va faire un article sur le fait que mesa a regressé en performance depuis un an, mais le bench utilise un noyau différent, un compilo différent, une version de llvm différente, une libc différente, etc. Aussi il ne suit pas les bonnes pratiques, comme désactiver les mécanismes d'économie d'énergie, ce qui lui a déjà permis de titrer "grave régression dans le noyau x.y.z" lorsque celui-ci a changé l'algo par défaut du pilote cpufreq. Ses bench filesystems sont aussi souvent dénués de sens ou avec des paramètres totalement arbitraires: qui ferait tourner une bdd sur fs2fs ou btrfs par exemple ? Aussi faire tourner un bench hyper-spécifique sur une configuration "stock" ça n'a pas beaucoup de sens non plus, on sait difficilement avoir une configuration qui fonctionne bien partout; ce n'est pas pour rien que certaines personnes sont payées pour tuner des systèmes et faire des benchmarks.
Ensuite, ce que je trouve dommage, c'est qu'il n'essaye jamais de donner une hypothéthique explication. Évidemment ça demande plus de temps d'investigation, une meilleur méthodologie et plus de connaissances. Mais je trouverais cela beaucoup plus intéressant ! C'est juste un choix éditorial de produire plus d'article d'une qualité discutable, j'imagine qu'il s'y retrouve comme ça et tant mieux pour lui, mais perso il est très rare que ce soient ses benchmarks qui soulève mon intérêt.
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
Évalué à 3.
Dernière modification le 30 juillet 2016 à 22:52.
Tu fais bien ;-)
Sur un AMD A10 7800 16 GB ram (2.6G visible en mode 32).
Config 32 bits:
noyau: 4.6.4-un-def-alt1 (alt linux i586), scaling_governor=performance
x265 [info]: HEVC encoder version 1.9+200-gf25e958
x265 [info]: build info [Linux][GCC 5.4.0][32 bit] 8bit
ENABLE_SHARED=OFF
build type Release
march=i686 (défaut)
et march=bdver3
asm=x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
Config 64 bits:
noyau 4.6.4.-un-def-alt1 (alt linux amd64), scaling_governor=performance
x265 [info]: HEVC encoder version 1.9+200-gf25e958
x265 [info]: build info [Linux][GCC 5.4.0][64 bit] 8bit
ENABLE_SHARED=OFF
build type Release
pas de march et march=bdver3
asm=x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
Bon je trouve curieux que l'on aie autant—~35%—de différence en utilisant le code asm par rapport avec le code C où il n'y a "que" ~16% d'avantage au 64bits, peut-être un problème d'alignement ?? Fin bref, je suis légèrement étonné. Ça pourrait être intéressant de voir avec un cpu d'une autre génération aussi. J'ai pas de kernel 4.6.4 PAE sous la main non plus, sait-on jamais :p
Memory above the physical address of 896MB are temporarily mapped into kernel virtual memory whenever the kernel needs to access that memory.
Data which the kernel frequently needs to access is allocated in the lower 896MB of memory (ZONE_NORMAL) and can be immediately accessed by the kernel (see Temporary mapping).
Data which the kernel only needs to access occasionally, including page cache, process memory and page tables, are preferentially allocated from ZONE_HIGHMEM.
The system can have additional physical memory zones to deal with devices that can only perform DMA to a limited amount of physical memory, ZONE_DMA and ZONE_DMA32.
Ce qui a l'air de confirmer que CONFIG_HIGHMEM n'est pas nécessaire, et que de tout de façon pour accéder à la mémoire user qui se trouve au delà de l'adresse physique 896MB, le noyau doit d'office mapper/unmapper.
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
Évalué à 2.
Dernière modification le 30 juillet 2016 à 18:55.
Oui mais pas de façon "permanente". Il doit mapper l'adresse physique correspondante au mapping du process dans une kva. Ça il doit le faire de toute de façon. Juste qu'avec highmem il peut la mapper dans une KVA au dessus de 1GB (enfin en dessous de 4-1, bref…). Qu'est-ce qui m'échappe dans ce raisonnement ? Et d'ailleurs est-ce que dans ce cas là il faut qu'elle soit dans une kva ?
Aussi, je conçois que dans certains cas il peut sans doute éviter de devoir modifier le mapping pagetable en ayant un mapping fixe sur une partie de mémoire physique et simplement voir si l'UVA n'est pas swappée pour calculer son adresse physique et voir si elle tombe dans la partie d'office mappée, mais j'ai du mal à voir en quoi highmem facilite quoi que ce soit là dedans ?
personne n'a pour l'instant fait l'effort, dans x265, d'écrire du code spécifique x86-64
Il y a du code mmx. sse1-4, avx, avx2 mais il manquerait du code spécifique x86_64, vous êtes sérieux là ?
UNIX64 et WIN64, sont définies,
Bien sûr maintenant il y a du code différente en fonction de la plateforme qui n'est pas de l'ABI. Sérieusement ?
Et je ne parle même pas de PIC
Normal j'appelle ça de l'ABI. Mais bon en s'en fout, x265 ne passe pas son temps à appeler des fonctions, ce qui au passage est plus lent en PIC et peut être vu comme un inconvénient sur amd64.
gros malin
Encore heureux que nous n'ayons pas de relation professionnelle subordonnée !
Désolé pour ce commentaire fort peu pertinent finalement.
Posté par benja .
En réponse au journal x86 ou x86_64 ?.
Évalué à -1.
Dernière modification le 30 juillet 2016 à 16:48.
Je ne cherche à décrédibiliser personne et quand je le fais pour me défendre j'essaye de le faire avec des arguments objectifs. Par exemple tu admets que "Le code est moins différent que ce qu'on pourrait croire" (normal c'est le même, mmx,sse2,avx ça reste la même chose que le reste du code soit en 32bit ou en 64), mais tu écris quand même un paragraphe pour dire qu'un binaire i386 ne fonctionne pas de la même manière que amd64 : ben oui sinon on en discuterait pas /captain obvious/ !
x86 est supérieur. C'est ce qui semble être ton propos depuis le début
Non, juste de démonter des pseudo-vérités. Oui amd64 est mieux plus sympa etc mais 1) pas toujours 2) la perf c'est pas l'objectif recherché.
on ne m'a jamais servi d'argument solide pour dire qu'il vaut mieux développer en x86.
Normal c'est pas le genre d'argument que l'on peut développer dans un entretient d'embauche. Un argument serait un proof of concept + un bench, pour une problématique donnée. Tout le reste ça n'est que du blabla.
mais pour l'instant on ne m'a jamais servi d'argument solide pour dire qu'il vaut mieux développer en x86. Le seul qui tiendrait la route c'est celui de maximiser la compatibilité avec les anciennes machines.
Oui exactement, c'est à mon sens l'objectif que recherche le trésorier. Avec /peu/ d'inconvénient (voir aucun au niveau utilisation desktop) pour les machines actuelles. Maintenant c'est sûr que l'idéal serait de donner 2 cd à chacun en disant "essayer celui-là d'abord".
Au fait, gros malin, le jeu dont tu parles s'appelle Xonotic, pas Xonotix. Ça fait désordre pour ta crédibilité :)
Bravo. Tu aurais pu mettre s/TBL/TLB, voir mieux pagetable, ou bien que chromium != que chrome. mais bon là c'est sûr je me suis encore bien ridiculisé :p
c'est certainement pas en lui installant un Linux 32 bits sur son portable Haswell 8 Go…
1) Est-ce que cela fonctionnera pas de manière satisfaisante ?
2) Quelle est la proportion de personnes qui vont arriver à son lug avec un portable dernier cri par rapport à un portable un peu plus agé ? Ou qui vont repartir avec le cd chez eux pour essayer de donner une seconde vie à un ordi qu'on avait depuis longtemps déclassé ?
donc moins de bug.
Mwouais c'est vite dit hein, linux/i386 n'est pas réputé pour être plein de bug. Le contre-argument c'est que les bugs applicatifs en 32 bit sur votre machine dernier cri seront aussi moins pénibles: l'application va se faire killer beaucoup plus vite, sans swapper, alors que chez vous ça va se mettre à swapper jusqu'au moment où l'utilisateur va retirer la prise.
Sans vouloir avoir l'air d'insister, mais quand même êtes-vous sûr de ce que vous avancez ? Selon ma compréhension, highmem permet au noyau d'utiliser la mémoire entre 1 et 4 en gérant des mapping à faire et à défaire à chaque transition noyau vers/de userland. Comme vous l'avez dit, une autre solution c'est de modifier la proportion du split, avec comme inconvénient de réduire l'espace d'adressage utilisable par les applications. Néanmoins, le noyau n'est pas obligé d'utiliser la mémoire > 1GB, donc amha il n'est ni nécessaire d'activer highmem ni de changer le split kva/uva lorsque l'on fait tourner linux/i386 sur machine qui a entre 1 et 4GB.
[^] # Re: Dépêche actuelle et la suite
Posté par benja . En réponse à la dépêche Les coulisses du standard C++. Évalué à 2. Dernière modification le 27 août 2016 à 22:26.
En évitant la définition d'un opérateur ad-hoc qui rend, amha, la compréhension de la sémantique plus ardue. C'est un peu l'éternel débat des macros, quelles soient basiques comme en C ou puissante comme en LISP, ce qu'on gagne en lisibilité avec le sucre syntaxique, on le perd en compréhension de la sémantique…
Donc bref, voici ma solution simple et lisible :p
Voire encore:
[^] # Re: curieux
Posté par benja . En réponse au message purger le cache RAM après archivage et zippage de gros dossiers. Évalué à 1. Dernière modification le 27 août 2016 à 00:08.
Il manque un '&' dans l'appel à gzip, sinon il ne va pas se passer grand chose :p
mkfifo /tmp/fifo
gzip > out.gz < /tmp/fifo &
tar cf - > /tmp/fifo
[^] # Re: curieux
Posté par benja . En réponse au message purger le cache RAM après archivage et zippage de gros dossiers. Évalué à 1.
Pour l'astuce du fifo afin de tester le retour de toutes les commandes, on peut faire:
Sh étant ce qu'il est, il n'y a pas vraiment d'autre moyen que de passer par un fichier pour stocker les codes retours…
[^] # Re: curieux
Posté par benja . En réponse au message purger le cache RAM après archivage et zippage de gros dossiers. Évalué à 2. Dernière modification le 26 août 2016 à 23:47.
Je conseillerais aussi rsync pour cela. De même, j'appuye le fait que le cache ne peut pas causer une pénurie de mémoire, donc vouloir le vider est une mauvaise idée (sinon c'est echo 3 > /proc/sys/vm/drop_caches…). Peut-être qu'ajouter de la swap pourrait résoudre ton problème ?
Concernant throttle, son utilisation est largement douteuse. Cela n'est pas parcequ'un process écrit à une certaine vitesse que le noyau va être plus ou moins chargé, va cacher plus ou moins, etc… Il faut garder en mémoire que pour ne pas exhiber des performances désastreuses, un FS combine les écritures de plusieurs activités en même temps.
Pour tester les conditions dans un pipe, apparemment bash possède l'option pipefail (set -o pipefail) qui fait l'affaire. Sinon, tu pourrais passer par un named-pipe, et tu lances tar en dernier. Genre mkfifo /tmp/fifo; gzip > out.gz < /tmp/fifo; tar cf - > /tmp/fifo.
De manière plus générale, je te conseillerais de rechercher la cause de l'erreur que tu rencontres, éventuellement en postant ici, au lieu de jouer à l'apprenti-sorcier. Car en prenant l'habitude d'essayer un truc au pif au lieu d'essayer de comprendre ce qui ne va pas, tu ne parviendras jamais à produire un système fiable.
edit: je m'adresse bien sûr à la deuxième personne à l'auteur de ce sujet.
# trop de gateway
Posté par benja . En réponse au message Résolu : Problème de routage (débutant, 2 réseau 4 pc openSuse). Évalué à 2. Dernière modification le 26 août 2016 à 20:24.
1) Manifestement, les routes que route -n te sort ne correspond pas à ce que tu demandes. Peux-tu mettre la commande que tu as utilisée afin que nous te corrigions ?
2) il ne faut pas mettre de gateway pour le réseau local, cela n'a pas de sens.
Il faut sur pc1 et pc2 mettre pc3 comme gateway, soit comme route par défaut, soit pour le réseau 192.168.1. Idem pour pc4, sauf que l'on prendra évidemment l'ip/interface de pc3 qui est sur le bon subnet.
[^] # Re: Extensions
Posté par benja . En réponse à la dépêche Firefox 48 : API WebExtensions, Electrolysis et sécurité. Évalué à 3. Dernière modification le 24 août 2016 à 15:02.
Je trouve son exemple est très pertinent au contraire. Si on applique ton raisonnement, la plupart des projets de logiciels libres mettent en place des DRM parce qu'ils mettent en place des "mesures de protection technique", le plus communément une clef ssh, pour limiter la modification de code (donc du fonctionnement) à des personnes approuvées. C'est complètement absurde comme idée, n'est-ce pas ?
[^] # Re: persistent livecd
Posté par benja . En réponse au message Linux sur un disque dur externe compatible avec tout les ordinateurs. Évalué à 2. Dernière modification le 24 août 2016 à 09:47.
Une distribution de type "live" n'est pas nécessaire. On peut utiliser une distribution ordinaire. Si cela n'était pas déjà le cas, il faudrait simplement mettre un maximum de drivers dans l'initrd et s'assurer que grub et fstab utilisent des identifiants stables de type label ou uuid pour référencer les disques ou les partitions.
[^] # Re: Voici un lien
Posté par benja . En réponse au message Installer scratch sur debian. Évalué à 1.
"ar" fait partie des binutils, paquet éponyme.
[^] # Re: Extensions
Posté par benja . En réponse à la dépêche Firefox 48 : API WebExtensions, Electrolysis et sécurité. Évalué à 2.
Primo: ça n'est pas l'OS livré avec le téléphone, le "defaultOS", mais un autre, probablement pour les raisons évoquées par ariasuni.
Deusio: il y a un gros blob compressé de 60M qui contient tout un tas de trucs. "Ouvert", il faut le dire assez vite quand même…
Mais bon admettons, ça en fait un qui livre des instructions de compilation avec une partie des sources. Très certainement un exemple à suivre même s'il on peut faire mieux. Malheureusement, actuellement cela reste l'exception.
[^] # Re: Extensions
Posté par benja . En réponse à la dépêche Firefox 48 : API WebExtensions, Electrolysis et sécurité. Évalué à 3.
Android n'est pas libre dans l'immense majorité des cas. Montre moi ne fut-ce qu'un constructeur qui donne l'ensemble des sources accompagnées des recettes de compilation ? Bref vouloir positionner Mozilla, Android et Apple au même point sur la ligne qui va de plus à moins de libertés, c'est un peu fort de café.
Mode je peux aussi anticiper ton prochain argument: oui effectivement il n'y a aucun matériel libre pour le grand publique, et alors c'est pour cela que l'on doit accepter des restrictions supplémentaires (dit d'une manière polie) ?
[^] # Re: GNU/Linux timeline
Posté par benja . En réponse au journal Debian a 23 ans. Évalué à 1. Dernière modification le 18 août 2016 à 13:21.
edit: grillé
[^] # Re: outil en ligne
Posté par benja . En réponse au message blockage plage d'ip. Évalué à 1. Dernière modification le 06 août 2016 à 13:33.
http://httpd.apache.org/docs/2.4/mod/core.html#HostnameLookups
-> Il est à off par défaut
-> L'utilisation de mod_authz_host le met à Double
Je copie ici le problème de perf de cette configuration, tel que décrit par la doc:
Ce document répond même à mon interrogation (plus bas) de faire le resolve de manière asynchrone uniquement pour le log.
Donc bref, Use the Doc first, Luke! puis si ça ne répond pas à ta question change de programme ou "Use the source".
[^] # Re: Masques réseau et classes
Posté par benja . En réponse au message blockage plage d'ip. Évalué à 1. Dernière modification le 06 août 2016 à 04:17.
(enfin bon, à piori, il est concevable qu'apache fasse la résolution inverse pour et uniquement pour le log de manière asynchrone sans impacter le temps de réponse ni la qualité de service mais en ayant d'autres inconvénients, de part la nature asynchrone de cette opération; use the source, Luke).
[^] # Re: Masques réseau et classes
Posté par benja . En réponse au message blockage plage d'ip. Évalué à 1.
Oublié de dire dans ce paragraphe que l'adresse de "ce réseau" vaut 10.0.0.0/8.
Par rapport au logage (c'est comme cela qu'on dit en français ?) du nom d'hôte, c'est, bien vu, une très mauvaise idée de faire, pour les même raison que déjà exposées.
[^] # Re: outil en ligne
Posté par benja . En réponse au message blockage plage d'ip. Évalué à 1.
Sans répondre à cette question spécifiquement, laisse moi te dire que ça serait une mauvaise idée car pour chaque requête ton apache va devoir faire une résolution DNS inverse (c'est comme cela qu'on appelle trouver un nom qui correspond à une adresse IP) et donc tu ajoutes un délais avant de répondre au client (qu'il soit légitime ou non) dans les meilleures des cas, un très long délais (voire une erreur ? à confirmer…) dans le pire des cas où les serveurs DNS serait down ou inaccessibles.
Généralement, on fait un blocage avec un pare-feu, C'est plus facile à gèrer, on ne doit pas relancer apache à chaque modification. Et là, il est encore plus inconcevable de faire une résolution inverse !
Ensuite, une plage IP n'a aucune relation avec un domaine, je précise vu cette nouvelle question, au càs où…
Pour le reste, la doc apache doit répondre à ta question.
# Masques réseau et classes
Posté par benja . En réponse au message blockage plage d'ip. Évalué à 2.
Un réseau au sens IP du terme est la plage d'adresse couverte par un masque, Lorsque ce masque est appliqué à une adresse, on obtient l'adresse du réseau, elle est identique pour chaque membre de ce réseau.
Un masque est une série de bit à 1, appelé le préfixe, suivi d'une série de zéros. En IPv4, la classe A correspond à une série de 8 bit à "1" suivit de 32-8 = 24 zéros, la classe B de 16 "1" et la classe C de 24 "1". La notation CIDR est la notation "sans classe". C'est à dire que la longueur du masque est choisie de fonction arbitraire et est dénotée avec un /XX; là ou avec les classes la longueur du préfixe était établie en fonction de l'adresse réseau par une convention RFC.
Exemple, une adresse 10.1.2.3, par convention, est une adresse privée ("non routable" sur internet!) de classe A. La longueur de son préfixe vaut 8. Sont masque en binaire est 1111111.00000000.00000000.00000000, soit en décimal, 255.0.0.0. L'adresse 10.2.2.3 fait partie de ce réseau car lorsque le maque est appliqué, on obtient 10.0.0.0 qui est aussi l'adresse du réseau.
Maintenant imagine que tu veuilles diviser ton réseau 10.x.x.x en deux, et mettre un routeur afin que chaque moitié doive passer par ce routeur pour dialoguer avec l'autre moitié. La solution est de passer en sans-classe et d'augmenter ton préfixe d'un bit. En d'autres mots, tu divises ta plage d'adresses entre le réseau réseau 10.0.0.0/9 et le réseau 10.128.0.0/9, Le masque devient en binaire 1111111.1000000.00000000.00000000, en décimal : 255.128.0.0 ou, plus simplement, /9.
10.1.2.3 appartient au premier réseau, 10.200.1.2 au deuxième.
Pour en revenir à ta config d'apache, en gros l'algorithme "j'applique le masque et je regarde si l'adresse est celle du réseau" est ré-utilisé pour le contrôle d'accès, il est logique donc d'utiliser cette notation bien établie.
PS: la page wikipédia explique cela très bien
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 3.
Le problème est que avec sa méthodologie on sait rarement déterminer l'origine des différences car il change plusieurs paramètres en même temps. Genre il va faire un article sur le fait que mesa a regressé en performance depuis un an, mais le bench utilise un noyau différent, un compilo différent, une version de llvm différente, une libc différente, etc. Aussi il ne suit pas les bonnes pratiques, comme désactiver les mécanismes d'économie d'énergie, ce qui lui a déjà permis de titrer "grave régression dans le noyau x.y.z" lorsque celui-ci a changé l'algo par défaut du pilote cpufreq. Ses bench filesystems sont aussi souvent dénués de sens ou avec des paramètres totalement arbitraires: qui ferait tourner une bdd sur fs2fs ou btrfs par exemple ? Aussi faire tourner un bench hyper-spécifique sur une configuration "stock" ça n'a pas beaucoup de sens non plus, on sait difficilement avoir une configuration qui fonctionne bien partout; ce n'est pas pour rien que certaines personnes sont payées pour tuner des systèmes et faire des benchmarks.
Ensuite, ce que je trouve dommage, c'est qu'il n'essaye jamais de donner une hypothéthique explication. Évidemment ça demande plus de temps d'investigation, une meilleur méthodologie et plus de connaissances. Mais je trouverais cela beaucoup plus intéressant ! C'est juste un choix éditorial de produire plus d'article d'une qualité discutable, j'imagine qu'il s'y retrouve comme ça et tant mieux pour lui, mais perso il est très rare que ce soient ses benchmarks qui soulève mon intérêt.
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 3. Dernière modification le 30 juillet 2016 à 22:52.
Tu fais bien ;-)
Sur un AMD A10 7800 16 GB ram (2.6G visible en mode 32).
Config 32 bits:
Config 64 bits:
Résultats (2 runs, le meilleur):
Bon je trouve curieux que l'on aie autant—~35%—de différence en utilisant le code asm par rapport avec le code C où il n'y a "que" ~16% d'avantage au 64bits, peut-être un problème d'alignement ?? Fin bref, je suis légèrement étonné. Ça pourrait être intéressant de voir avec un cpu d'une autre génération aussi. J'ai pas de kernel 4.6.4 PAE sous la main non plus, sait-on jamais :p
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 1.
Effectivement, je vais retourner me cacher :p
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 0.
Bon alors selon https://linux-mm.org/HighMemory
Ce qui a l'air de confirmer que CONFIG_HIGHMEM n'est pas nécessaire, et que de tout de façon pour accéder à la mémoire user qui se trouve au delà de l'adresse physique 896MB, le noyau doit d'office mapper/unmapper.
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 2. Dernière modification le 30 juillet 2016 à 18:55.
Oui mais pas de façon "permanente". Il doit mapper l'adresse physique correspondante au mapping du process dans une kva. Ça il doit le faire de toute de façon. Juste qu'avec highmem il peut la mapper dans une KVA au dessus de 1GB (enfin en dessous de 4-1, bref…). Qu'est-ce qui m'échappe dans ce raisonnement ? Et d'ailleurs est-ce que dans ce cas là il faut qu'elle soit dans une kva ?
Aussi, je conçois que dans certains cas il peut sans doute éviter de devoir modifier le mapping pagetable en ayant un mapping fixe sur une partie de mémoire physique et simplement voir si l'UVA n'est pas swappée pour calculer son adresse physique et voir si elle tombe dans la partie d'office mappée, mais j'ai du mal à voir en quoi highmem facilite quoi que ce soit là dedans ?
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à -1.
Il y a du code mmx. sse1-4, avx, avx2 mais il manquerait du code spécifique x86_64, vous êtes sérieux là ?
Bien sûr maintenant il y a du code différente en fonction de la plateforme qui n'est pas de l'ABI. Sérieusement ?
Normal j'appelle ça de l'ABI. Mais bon en s'en fout, x265 ne passe pas son temps à appeler des fonctions, ce qui au passage est plus lent en PIC et peut être vu comme un inconvénient sur amd64.
Encore heureux que nous n'ayons pas de relation professionnelle subordonnée !
Désolé pour ce commentaire fort peu pertinent finalement.
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à -1. Dernière modification le 30 juillet 2016 à 16:48.
Je ne cherche à décrédibiliser personne et quand je le fais pour me défendre j'essaye de le faire avec des arguments objectifs. Par exemple tu admets que "Le code est moins différent que ce qu'on pourrait croire" (normal c'est le même, mmx,sse2,avx ça reste la même chose que le reste du code soit en 32bit ou en 64), mais tu écris quand même un paragraphe pour dire qu'un binaire i386 ne fonctionne pas de la même manière que amd64 : ben oui sinon on en discuterait pas /captain obvious/ !
Non, juste de démonter des pseudo-vérités. Oui amd64 est mieux plus sympa etc mais 1) pas toujours 2) la perf c'est pas l'objectif recherché.
Normal c'est pas le genre d'argument que l'on peut développer dans un entretient d'embauche. Un argument serait un proof of concept + un bench, pour une problématique donnée. Tout le reste ça n'est que du blabla.
Oui exactement, c'est à mon sens l'objectif que recherche le trésorier. Avec /peu/ d'inconvénient (voir aucun au niveau utilisation desktop) pour les machines actuelles. Maintenant c'est sûr que l'idéal serait de donner 2 cd à chacun en disant "essayer celui-là d'abord".
Bravo. Tu aurais pu mettre s/TBL/TLB, voir mieux pagetable, ou bien que chromium != que chrome. mais bon là c'est sûr je me suis encore bien ridiculisé :p
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à -1.
1) Est-ce que cela fonctionnera pas de manière satisfaisante ?
2) Quelle est la proportion de personnes qui vont arriver à son lug avec un portable dernier cri par rapport à un portable un peu plus agé ? Ou qui vont repartir avec le cd chez eux pour essayer de donner une seconde vie à un ordi qu'on avait depuis longtemps déclassé ?
Mwouais c'est vite dit hein, linux/i386 n'est pas réputé pour être plein de bug. Le contre-argument c'est que les bugs applicatifs en 32 bit sur votre machine dernier cri seront aussi moins pénibles: l'application va se faire killer beaucoup plus vite, sans swapper, alors que chez vous ça va se mettre à swapper jusqu'au moment où l'utilisateur va retirer la prise.
[^] # Re: Se tenir au courant ?
Posté par benja . En réponse au journal x86 ou x86_64 ?. Évalué à 1.
Sans vouloir avoir l'air d'insister, mais quand même êtes-vous sûr de ce que vous avancez ? Selon ma compréhension, highmem permet au noyau d'utiliser la mémoire entre 1 et 4 en gérant des mapping à faire et à défaire à chaque transition noyau vers/de userland. Comme vous l'avez dit, une autre solution c'est de modifier la proportion du split, avec comme inconvénient de réduire l'espace d'adressage utilisable par les applications. Néanmoins, le noyau n'est pas obligé d'utiliser la mémoire > 1GB, donc amha il n'est ni nécessaire d'activer highmem ni de changer le split kva/uva lorsque l'on fait tourner linux/i386 sur machine qui a entre 1 et 4GB.