Le fait que la mesure de protection est contournable n'en fait pas de la foutaise.
Un keylogger qui capture les touches saisies peut retrouver très facilement le code. Il y en a eu des paquets, et on voit encore pas mal ce genre d'attaque en circulation; surtout pour pirater les comptes webmail et balancer du spam.
Avec le clavier virtuel; c'est le navigateur qui fait l'association entre le clic et le chiffre; et ensuite envoi la requête chiffrée au site. Pour intercepter les chiffres, il faut aller lire dans le navigateur; ce qui n'est pas impossible, mais déjà plus difficile.
On pourrait encore améliorer le mécanisme, pour que le navigateur ignore le code, mais ce n'est pas une raison pour cracher bêtement sur les mesures qui sont mises en place.
Sur un portable, c'est probablement peu intéressant:
Tu n'en parles pas, mais je pense que c'était sous entendu, il faut retirer la batterie pour supprimer la consommation liée à la charge ou l'entretien de la charge de la batterie.
Selon s'ils sont branchés sur le secteur ou non, les portables activent ou désactivent tout un tas de chose. Si le but est d'augmenter l'autonomie de la machine, alors la mesure de la consommation lorsqu'il est branché est peu significative. Il faudrait être capable de faire croire à la machine qu'elle fonctionne sur batterie; et je ne suis pas certain que tout puisse se configurer de façon logiciel.
Les wattmètres du commerce que je connais n'ont pas de calibre adapté à d'aussi petites puissances. Celui que j'utilise pour les appareils ménagers courants a une sensibilité de 5 ou 6 watts, il sera bien incapable de distinguer une réduction de consommation de 1W. Sur un portable qui en consomme entre 10 et 15, il n'est pas possible de faire de mesure intéressante. Au contraire, la couche ACPI me remonte la consommation avec une sensibilité de 1W, permettant de voir plus facilement l'impact de chaque paramètre.
Tout le monde n'est pas un spécialiste de tous les logiciels open-source. Est-ce que ça serait trop demander de reprendre une saine habitude: donner au moins une phrase explicative de ce qu'est MongoDB au début de la dépêche ?
C'est indispensable pour permettre à un plus grand nombre de profiter de l'article. Là, c'est l'exemple typique de l'article imperméable.
Je ne comprends pas ce qui te dérange.
> Qui me ment ?
Personne, on a bien 2582904µs > 2578351µs > 1003254µs
Apache bufferise-t-il ce qui lui vient de plus loin avant de le renvoyer ou le renvoie-t-il au fil de l'eau ?
Il bufferise dans une certaine mesure. Le reverse-proxy n'est pas un switch ou un équipement réseau de niveau IP. Lorsqu'il reçoit une requête, il la traite, et il créer une NOUVELLE requête vers le serveur suivant. La bufferisation dépends de la version d'apache et du protocole HTTP utilisé pour chaque liaison (tu as 3 requêtes HTTP différentes). Regarde en particulier le mode chunked de HTTP/1.1. Si tu as un filtre de sortie, genre compression, ça augmente les besoins de bufferisation.
Le temps indiqué dans les logs indique-t-il :
- du début de la requête jusqu'à ce que le dernier octet soit renvoyé et la connexion clôturée ?
- du début de la requête jusqu'à ce que le premier octet soit renvoyé ?
Chaque serveur doit parser la requête qu'il reçoit, appliquer un certain nombre de règles, se connecter au serveur suivant, envoyer sa requête. Dans le pire des cas, il peut avoir un filtre sur la sortie, genre une compression, ou des entêtes à calculer, comme la taille de la réponse.
Si en amont de mes RPs le débit/latence est pourrave cela peut-il faire que le RP molassonne mon WS ?
Pas sur quelques Ko, parce que l'OS fait tampon, mais il est facile de montrer qu'a partir de quelques dizaines ou centaines de Ko, si le RP est bloqué sur une émission vers le navigateur, il ne va pas lire ce qui est arrivé du serveur (l'OS réduit la fenêtre TCP jusqu'à 0 si nécessaire), et toute la chaine ralentie.
Le test est facile à faire, gdb permet d'aller de syscall en syscall (commande "catch syscall" puis "continue" pour avancer) pour ralentir la lecture des paquets. Faire envoyer un gros fichier d'un nc à un autre sur le localhost. Un tcpdump montre bien que la fenêtre TCP tombe à 0, on constate aussi que l’émetteur est bloqué tant que le récepteur ne lit pas de données.
Si tu veux du sans-abonnement sur du DATA, j'ai vu que SFR a une offre de clef en pré-payé, la clef coute une trentaine d'euros, et tu peux acheter des recharges appelées "le Pass Internet 3G+". J'ai fais un tour chez quelques autres opérateurs sans trouvé d'équivalent.
La clef a l'air compatible Linux. Pour la voix, ça m'étonnerait que ça passe.
démarrer un service à la demande ? Y'avait pas un déjà truc qui s'appelait inetd ?
Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.
eviter de démarrer 1000 processus ? y'a qu'à utiliser un shell plus complet, comme un bon vieux lisp des familles.
On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.
suivre les processus? J'ai du mal avec ça, mais il y a pas un système de log sous linux?
Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.
contrôler le contexte du service ? je ne vois pas ce qui ne pourrait pas être fait sous un shell, avec quelques librairies.
A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.
Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.
A hierarchy is a set of cgroups arranged in a tree, such that every task in the system is in exactly one of the cgroups in the hierarchy, and a set of subsystems; each subsystem has system-specific state attached to each cgroup in the hierarchy. Each hierarchy has an instance of the cgroup virtual filesystem associated with it.
At any one time there may be multiple active hierarchies of task cgroups. Each hierarchy is a partition of all tasks in the system.
En résumé: On peut avoir plusieurs hiérarchies; dans chaque hiérarchie on peut mettre plusieurs cgroups. Les processus sont présent une et une seule fois dans chaque hiérarchie.
Cela permet, par exemple, de définir une hiérarchie pour isoler les services et les sessions; et de définir une seconde hiérarchie n'ayant rien à voir pour les I/O disque.
lancer le service au démarrage, au moment où il y a pleins d'I/O
attendre que la pression mémoire pousse a récupérer de la mémoire du service
virer les pages de texte (le binaire) de la mémoire puisqu'il est déjà sur disque
swapper sur disque les pages de données
a la première sollicitation remonter les pages de texte depuis le fichier
remonter les pages de données du swap
Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.
Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.
Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:
systemd est déjà dans testing.
un certain nombre de paquets dans testing sont déjà compatibles systemd
Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".
Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD
Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.
Ligne 167 dans la fonction alloc_pidmap(struct pid_namespace *pid_ns)
pid=last+1;if(pid>=pid_max)pid=RESERVED_PIDS;
La suite de la fonction détermine si pid est utilisé dans ce namespace pour chercher une autre valeur.
La fonction alloc_pid un peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisant alloc_pidmap
Donc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.
Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.
Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".
En shell ça donne ça:
$ time bash -eu -c 'N=0; for I in $(seq 2048); do N=$(echo "$N + 2" | bc); done; echo $N'
4096
real 0m3.352s
user 0m0.940s
sys 0m2.390s
J'ai l'impression que c'est un jouet et que dans 2 ans on nous dira "ah bien non, en fait on va utiliser le system42 qui est mieux". Il y a de plus en plus de nouveautés poussées dans les distributions sans but réel.
A la vue des gains que cela apporte, ce n'est pas un jouet pour moi, et je ne pense pas être le seul. Je ne conteste pas qu'il y ait un effet de mode, je me fiche pas mal du temps de démarrage sur mes serveurs; mais j'attends certaines choses avec impatience.
En particulier:
la récupération de stdout et stderr est un problème récurrent, ainsi que le code de retour lorsque quelque chose ne démarre pas. J'y suis confronté plusieurs fois par an et je me suis retrouvé plus d'une fois à trafiquer les scripts de démarrage.
modifier les paramètres d'un service; sous debian on peut ajouter un paramètre au lancement dans certains paquets via un fichier dans /etc/defaults; comme ce n'est pas le cas pour tous, je dois modifier un script de 300 lignes pour ajouter cette variable; qui est perdu à chaque mise à jour.
Pour l'avenir, j'ignore si une version 42 encore mieux sortira dans dix ans ou dans un an; mais je ne pense pas que ce soit une raison de se priver de ce que systemd apporte. systemd nous montrera peut-être qu'il faut aller dans une autre direction, ou que l'on peut encore améliorer certaines choses; mais cela ne se verra pas en restant dans l'état actuel.
Meilleure intégration avec PAM et SELinux -> je n'utilise pas
Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?
Je confirme. Lorsque la réinstallation n'est pas forcément possible, l'utilisation d'un kernel 64bits est une solution.
Par rapport à un kernel PAE, je vois deux avantages:
Le kernel peut adresser directement toute la mémoire de la machine sans jongler avec la MMU, opération pas très satisfaisante et couteuse en cache TLB.
En mode kernel, le système dispose de plus de registres, gain toutefois un peu contrebalancé par les adresses mémoires plus grosses qui diminuent l'efficacité du cache mémoire.
Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
On lit et on écrit des blocs de taille fixe, par exemple 4Ko, les systèmes de fichier aiment bien ça (Un rapide parcours de la norme SATA 1 semble dire que l'on pourrait échanger des paquets jusqu'à 8Ko). Pour l'écriture, les CRCs des SSD ne sont probablement pas fait sur de plus gros blocs vu qu'ils travaillent déjà comme cela.
On envoi une commande d'effacement de macro-bloc lorsqu'on veut faire du ménage. Un peu comme la commande TRIM mais avec une grosse granularité.
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).
Les firmwares de SSD sont compliqués parce qu'ils font beaucoup de chose.
Le SSD n'a pas grand chose à voir avec le disque dur; or afin de pouvoir l'utiliser en lieu et place d'un disque, il est muni d'une couche de compatibilité plutôt considérable destinée à le faire passer et dialoguer comme un disque dur ordinaire. Cette couche est destinée à faire croire que les secteurs font 512 octets, qu'on peut ré-écrire le même tant que l'on veut (surtout ceux situé là ou la FAT se trouve habituellement), que l'écriture peut se faire sur n'importe quel secteur sans surcoût, qu'il n'est pas nécessaire de recycler les secteurs inutilisés...
Les développeurs du kernel souhaitent avoir un accès plus réaliste au SSD et court-circuiter cette couche d'émulation qui fait son travail moins bien que l'OS ne pourrait le faire; mais ils n'ont pas obtenu gain de cause auprès des fabricants. Ceux-ci veulent vendre du matériel prêt à brancher sur les OS d'aujourd'hui, et pas un truc qui ne fonctionnera que dans 2 ans.
[^] # Re: hop
Posté par Sébastien Koechlin . En réponse au message Accès xdmcp. Évalué à 1.
Le plus simple est probablement de faire un 'ps' et de voir les options utilisées par X.
Un 'netstat' te montrera aussi si X est a l'écoute en TCP.
[^] # Re: hop
Posté par Sébastien Koechlin . En réponse au message Accès xdmcp. Évalué à 2.
Y'a aussi le
qui mériterait de creuser un peu la doc.
[^] # Re: Dépêche intéressante, mais imprécise
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie de MongoDB 2.0 RC. Évalué à 1.
Voila, c'est exactement le genre de paragraphe qu'il convient de mettre en introduction de la dépêche.
[^] # Re: weboob…
Posté par Sébastien Koechlin . En réponse au journal Les banques, et le téléchargement des données. Évalué à 0.
Le fait que la mesure de protection est contournable n'en fait pas de la foutaise.
Un keylogger qui capture les touches saisies peut retrouver très facilement le code. Il y en a eu des paquets, et on voit encore pas mal ce genre d'attaque en circulation; surtout pour pirater les comptes webmail et balancer du spam.
Avec le clavier virtuel; c'est le navigateur qui fait l'association entre le clic et le chiffre; et ensuite envoi la requête chiffrée au site. Pour intercepter les chiffres, il faut aller lire dans le navigateur; ce qui n'est pas impossible, mais déjà plus difficile.
On pourrait encore améliorer le mécanisme, pour que le navigateur ignore le code, mais ce n'est pas une raison pour cracher bêtement sur les mesures qui sont mises en place.
[^] # Re: Vous mesurez comment votre consommation ?
Posté par Sébastien Koechlin . En réponse au journal Trucs pour consommer moins et éteindre plus sur Intel. Évalué à 1.
Sur un portable, c'est probablement peu intéressant:
[^] # Re: Dépêche intéressante, mais imprécise
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie de MongoDB 2.0 RC. Évalué à 1.
Oui, merci, ce n'est pas vraiment ce que j'attendais.
[^] # Re: Dépêche intéressante, mais imprécise
Posté par Sébastien Koechlin . En réponse à la dépêche Sortie de MongoDB 2.0 RC. Évalué à -1.
Tant qu'à râler, je me joins à toi:
Tout le monde n'est pas un spécialiste de tous les logiciels open-source. Est-ce que ça serait trop demander de reprendre une saine habitude: donner au moins une phrase explicative de ce qu'est MongoDB au début de la dépêche ?
C'est indispensable pour permettre à un plus grand nombre de profiter de l'article. Là, c'est l'exemple typique de l'article imperméable.
# Très cohérent
Posté par Sébastien Koechlin . En réponse au message Apache et ses logs. Évalué à 3.
Je ne comprends pas ce qui te dérange.
> Qui me ment ?
Personne, on a bien 2582904µs > 2578351µs > 1003254µs
Il bufferise dans une certaine mesure. Le reverse-proxy n'est pas un switch ou un équipement réseau de niveau IP. Lorsqu'il reçoit une requête, il la traite, et il créer une NOUVELLE requête vers le serveur suivant. La bufferisation dépends de la version d'apache et du protocole HTTP utilisé pour chaque liaison (tu as 3 requêtes HTTP différentes). Regarde en particulier le mode chunked de HTTP/1.1. Si tu as un filtre de sortie, genre compression, ça augmente les besoins de bufferisation.
C'est le temps depuis l'arrivée de la requête jusqu'au moment où toute la réponse est partie dans la couche réseau et que Apache est en train de logger la ligne. Ça se passe ligne 650 de http://svn.apache.org/viewvc/httpd/httpd/tags/2.2.20/modules/loggers/mod_log_config.c?revision=1163057&view=markup
Chaque serveur doit parser la requête qu'il reçoit, appliquer un certain nombre de règles, se connecter au serveur suivant, envoyer sa requête. Dans le pire des cas, il peut avoir un filtre sur la sortie, genre une compression, ou des entêtes à calculer, comme la taille de la réponse.
Pas sur quelques Ko, parce que l'OS fait tampon, mais il est facile de montrer qu'a partir de quelques dizaines ou centaines de Ko, si le RP est bloqué sur une émission vers le navigateur, il ne va pas lire ce qui est arrivé du serveur (l'OS réduit la fenêtre TCP jusqu'à 0 si nécessaire), et toute la chaine ralentie.
Le test est facile à faire, gdb permet d'aller de syscall en syscall (commande "catch syscall" puis "continue" pour avancer) pour ralentir la lecture des paquets. Faire envoyer un gros fichier d'un nc à un autre sur le localhost. Un tcpdump montre bien que la fenêtre TCP tombe à 0, on constate aussi que l’émetteur est bloqué tant que le récepteur ne lit pas de données.
[^] # Re: Alternative ?
Posté par Sébastien Koechlin . En réponse à l’entrée du suivi Suivi personnel des publications et des commentaires.. Évalué à 1 (+0/-0).
Pas mal, cette notion de tags n'est pas très clair et je n'ai jamais réfléchi à quoi ça pouvait bien servir. Je vais essayer.
[^] # Re: Plus précisement ?
Posté par Sébastien Koechlin . En réponse au message Erreur de segmentation dans une machine virtuelle sous Xen. Évalué à 1.
Bon, je n'ai pas été clair; je voulais que tu fasses une stack-trace du plantage.
Est-ce que tu as au moins le nom du binaire qui plante dans dmesg ?
# Plus précisement ?
Posté par Sébastien Koechlin . En réponse au message Erreur de segmentation dans une machine virtuelle sous Xen. Évalué à 1.
Jamais constaté. As-tu une stack-trace du plantage ?
# SFR et clef 3G pré-payée
Posté par Sébastien Koechlin . En réponse au journal téléphone 3G linux et abonnement carte. Évalué à 1.
Si tu veux du sans-abonnement sur du DATA, j'ai vu que SFR a une offre de clef en pré-payé, la clef coute une trentaine d'euros, et tu peux acheter des recharges appelées "le Pass Internet 3G+". J'ai fais un tour chez quelques autres opérateurs sans trouvé d'équivalent.
La clef a l'air compatible Linux. Pour la voix, ça m'étonnerait que ça passe.
# man .ssh/config
Posté par Sébastien Koechlin . En réponse au message rsync via un tunnel ssh sur une tierce machine . Évalué à 1.
Je n'ai pas bien compris si tu lançais le rsync depuis PC2 ou depuis PC3, voici la solution depuis PC3, pour l'inverse il suffit d'inverser les noms:
A mettre dans le .ssh/config de PC3:
Ensuite tu pourras faire un ssh user@PC1 directement depuis PC3; il n'y a pas de raison que ça pose des problèmes pour rsync.
[^] # Re: Pourquoi faire simple quand on peut faire compliqué ?
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
On reprends:
Je parle justement de inetd dans la dépêche; pour t'éviter de tout lire: oui, inetd le fait pour les sockets Internet; mais n'est pas utilisé dans ce mode (généralement il lance une instance par requête). Il semblerait que certaines implémentations existe pour le faire sur les sockets de type fichier; mais je n'en ai jamais vu. Rien n'existe pour les messages SystemV à ma connaissance, ni sur la présence de fichiers dans un répertoire. systemd propose une solution qui généraliste le démarrage à la demande à un maximum de solutions techniques.
On pourrait utiliser emacs ? Le soucis c'est qu'à nouveau, on sort du normalisé. Les shells plus puissant sont généralement bien plus lourds parce qu'ils ont aussi beaucoup de développements liés à l'interactivité qui n'ont aucun intérêt dans un script.
Si, bien sur; mais je ne connais aucun système qui va rediriger les logs des services. Généralement la tache en est confiée au service.
A nouveau, rien n'est impossible; mais il n'existe pas de lanceur de service qui s'occupent à la fois de modifier l'user, les groupes, les cgroups, les capacités, le chroot, les logs, le contexte selinux, les limits, le umask et que sais-je encore. A chaque fois ça passe par l'écriture ou le bidouillage du script de démarrage qui n'a généralement pas été prévu pour. On se retrouve avec 150 scripts très semblables dans /etc/init.d dont aucun n'est complet.
Dans ce sens, systemd permet de passer en chroot un service qui n'avait pas été prévu pour, simplement en modifiant son fichier de configuration.
[^] # Re: utilisation des cgroups ?
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 3.
Le mieux est probablement de lire les premiers chapitres de la documentation du kernel: http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt
En résumé: On peut avoir plusieurs hiérarchies; dans chaque hiérarchie on peut mettre plusieurs cgroups. Les processus sont présent une et une seule fois dans chaque hiérarchie.
Cela permet, par exemple, de définir une hiérarchie pour isoler les services et les sessions; et de définir une seconde hiérarchie n'ayant rien à voir pour les I/O disque.
[^] # Re: Merci
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
Si j'essaye de résumer les deux solutions
Solution à la demande
Solution pré-chargement
Au final dans la seconde solution, on a chargé une fois de plus le binaire depuis le disque, on a lu et écrit une fois toutes les données, et on a fait le lancement à un moment ou le disque est très sollicité.
Le seul avantage qu'on a, c'est que le service réponds plus rapidement, puisqu'il a déjà été initialisé. Mais en général le temps d'initialisation est ridicule devant le temps de lecture.
[^] # Re: systemd / Debian
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 4.
Je n'ai pas vraiment plus d'informations que ce qui a été cité dans l'article et dans le thread que tu pointes. C'est une déduction de:
Il y a actuellement un problème qui touche également upstart: sysvinit est taggé comme "Essential".
Enfin je n'ai pas parlé d'avoir systemd comme système par défaut; pour la principale raison qu'il n'est pas compatible avec Debian GNU/Hurd ni avec Debian GNU/*BSD
[^] # Re: double fork
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 3.
Le terme double-fork dans son sens littéral est effectivement trompeur. Je n'ai pas voulu expliquer en détail le mécanisme qu'on entends par là pour éviter d'allonger un article déjà très long. Merci de l'avoir fait dans les commentaires.
[^] # Re: Petits PIDs
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 4.
Suite à une remarque d'un relecteur, j'ai vérifié en écrivant l'article.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.39.y.git;a=blob;f=kernel/pid.c;h=57a8346a270e07702e21d7bab15303427bf2fce0;hb=HEAD
Ligne 167 dans la fonction
alloc_pidmap(struct pid_namespace *pid_ns)La suite de la fonction détermine si
pidest utilisé dans ce namespace pour chercher une autre valeur.La fonction
alloc_pidun peu plus bas, fait une boucle dans la pile des namespaces pour affecter un pid dans chaque namespace défini en utilisantalloc_pidmapDonc le kernel à la vanille incrémente bien de 1 le PID pour chaque nouveau processus, en tout cas tant qu'on n'a pas dépassé pid_max qui vaut de mémoire 0x8000 en mode normal.
[^] # Re: Quoi ? Il faut créer plein de processus ?
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.
Ton test ne fait que le fork; il manque pas mal de travail. Il faudrait tester avec un exec qui va parcourir PATH pour trouver le bon fichier, qui va modifier le mappage mémoire, qui va faire la résolution dynamique des librairies, charger les locales, lire sur stdin, écrire sur stdout, sortir, enfin coté fils il faut encore lire le résultat.
Le test d'une série me semble pas mal, genre partir de n=0 et lancer 2048 fois "bc" en lui passant "n+2".
En shell ça donne ça:
Ce qui fait 3.3 secondes chez moi.
[^] # Re: Lapin compris
Posté par Sébastien Koechlin . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 10.
A la vue des gains que cela apporte, ce n'est pas un jouet pour moi, et je ne pense pas être le seul. Je ne conteste pas qu'il y ait un effet de mode, je me fiche pas mal du temps de démarrage sur mes serveurs; mais j'attends certaines choses avec impatience.
En particulier:
la récupération de stdout et stderr est un problème récurrent, ainsi que le code de retour lorsque quelque chose ne démarre pas. J'y suis confronté plusieurs fois par an et je me suis retrouvé plus d'une fois à trafiquer les scripts de démarrage.
modifier les paramètres d'un service; sous debian on peut ajouter un paramètre au lancement dans certains paquets via un fichier dans /etc/defaults; comme ce n'est pas le cas pour tous, je dois modifier un script de 300 lignes pour ajouter cette variable; qui est perdu à chaque mise à jour.
Pour l'avenir, j'ignore si une version 42 encore mieux sortira dans dix ans ou dans un an; mais je ne pense pas que ce soit une raison de se priver de ce que systemd apporte. systemd nous montrera peut-être qu'il faut aller dans une autre direction, ou que l'on peut encore améliorer certaines choses; mais cela ne se verra pas en restant dans l'état actuel.
Je suis curieux de savoir quelle distribution tu utilises pour te passer de PAM ?
[^] # Re: 4 GB
Posté par Sébastien Koechlin . En réponse au message Migre de Lenny 32bits à Squeeze 64bits. Évalué à 2.
Je confirme. Lorsque la réinstallation n'est pas forcément possible, l'utilisation d'un kernel 64bits est une solution.
Par rapport à un kernel PAE, je vois deux avantages:
Le kernel peut adresser directement toute la mémoire de la machine sans jongler avec la MMU, opération pas très satisfaisante et couteuse en cache TLB.
En mode kernel, le système dispose de plus de registres, gain toutefois un peu contrebalancé par les adresses mémoires plus grosses qui diminuent l'efficacité du cache mémoire.
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 4.
Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 2.
Pas certain, il y a déjà le Native Command Queuing. Par contre, je ne sais pas quelle est la taille maximale d'un bloc.
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 10.
Les firmwares de SSD sont compliqués parce qu'ils font beaucoup de chose.
Le SSD n'a pas grand chose à voir avec le disque dur; or afin de pouvoir l'utiliser en lieu et place d'un disque, il est muni d'une couche de compatibilité plutôt considérable destinée à le faire passer et dialoguer comme un disque dur ordinaire. Cette couche est destinée à faire croire que les secteurs font 512 octets, qu'on peut ré-écrire le même tant que l'on veut (surtout ceux situé là ou la FAT se trouve habituellement), que l'écriture peut se faire sur n'importe quel secteur sans surcoût, qu'il n'est pas nécessaire de recycler les secteurs inutilisés...
Les développeurs du kernel souhaitent avoir un accès plus réaliste au SSD et court-circuiter cette couche d'émulation qui fait son travail moins bien que l'OS ne pourrait le faire; mais ils n'ont pas obtenu gain de cause auprès des fabricants. Ceux-ci veulent vendre du matériel prêt à brancher sur les OS d'aujourd'hui, et pas un truc qui ne fonctionnera que dans 2 ans.