Ne pas utiliser le nodejs de Debian qui est visiblement répudié par les dev nodejs (j'imagine que nodejs embarque des libs trafiquées), prendre celui qui est packagé sur https://github.com/nodesource/distributions (on n'est pas obligé d'exécuter un script en root, on peut ajouter la clef PGP à la main et les lignes qui vont bien dans le sources.list, j'ai pris nodejs 0.12
Installer python3-virtualenv et virtualenv également.
Si vous voulez une petite idée de la place que ça occupe:
J'ai la vieille version du serveur de synchro qui tourne et hélas, c'est fragile et tout aussi opaque, et je désespérais de pouvoir mettre à jour vu que le serveur est abandonné ainsi que la partie client.
Deux remarques après une lecture rapide:
Ca serait bien de décrire sommairement les différentes briques qui tournent sur le serveur et à quoi elles servent.
Quid de la maintenance ? C'est bien beau d'ouvrir un service mais cela ne peut fonctionner que s'il est maintenu. Comme il ne s'agit pas de paquets de la distribution, cela demande de faire des actions manuelles pour vérifier les corrections et les installer.
J'ai aussi installé clamav sur quelques serveurs de messageries, mais il ne trouve jamais rien.
La base est pourtant bien mise à jour quotidiennement; mais je n'ai jamais de rapport de mail bloqué dans les logs (sauf mes tests avec EICAR) et lorsque j'ai le courage de lui faire tester manuellement un fichier manifestement vérole, il ne trouve jamais rien à lui reprocher.
J'ai déjà soumis des fichiers sur leur interface de signalement, mais ça n'a semble-t'il pas eu le moindre effet.
Pour l'instant, je l'ai laissé configuré, mais je suis plutôt déçu.
Quand il y a un événement physique, c'est bien de dire où ça se trouve, tout le monde ne sais pas ce qu'est le Numa, ni dans quelle ville ou quel pays il se trouve.
La méthode de vérification me semble un peu limité. Est-ce qu'il est prévu d'autres mécanismes pour les autres cas ?
Si je veux un certificat pour un annuaire LDAP, ou pour un serveur de mail ? Pour un protocole quelconque (et nouveau) ? Ca va être difficile de déposer un fichier à la racine d'un annuaire LDAP.
C'est d'ailleurs une question à laquelle je n'ai jamais trouvé de réponse très claire.
Si j'utilise un certificat auto-signé sur mon serveur de messagerie, est-ce que ça va générer des erreurs chez les serveurs qui tentent de m'envoyer un mail ?
Sérieusement, quasiment 300 lignes pour lire un fichier ini, traiter les quotes à la main, tripoter IFS et shopt; il n'y a vraiment pas de quoi être fier.
C'est un bel exemple de code complètement non maintenable. En prime chacun y va de sa copie sans jamais faire la moindre mise à jour histoire de variés les bugs d'un code à l'autre.
KSM permet a ma connaissance de merger rétrospectivement deux pages identiques. C'est utile lorsqu'on utilise plusieurs fichiers identiques (par exemple lorsqu'on a n VM du même OS qui vont chacune avoir la même copie des binaires et des librairies). Ça demande de parcourir la mémoire à la recherche de pages identiques.
Le gestionnaire de mémoire de Linux est capable au moment du mappage mémoire, de voir qu'une page en lecture seule est déjà présente en mémoire dans le système, et de l'utiliser. Cela est possible parce pour ce type de mémoire, le système garde une référence sur le fichier et l'offset qui ont servi à son chargement. Ça évite de dupliquer la mémoire utilisée par les librairies (tel que la libc ou le chargeur dynamique utilisée par tout le monde); en cas de saturation mémoire, ça évite d'avoir à écrire ces pages dans le swap (on pourra les recharger depuis le fichier), et ça permet de ne faire le chargement effectif en mémoire que lorsque (et si) la page est utilisée. Tu trouveras toutes les informations sur la correspondance entre les adresses mémoire et les fichiers dans /proc//maps
L'effet de bord un peu déroutant est qu'il est impossible d'avoir la mémoire occupée par un processus donné. Une partie de la mémoire étant partagée avec d'autres processus, il est difficile de déterminer comment elle doit être comptabilisée.
En prime, les pages en écriture peuvent également être partagées jusqu'à la première écriture par un mécanisme appelé copy-on-write, très utilisé lorsqu'on lance un nouveau processus (fork).
C'est dommage, parce que se farcir toute la couche des drivers nécessaire pour utiliser une machine moderne nécessite un travail considérable et peu intéressant.
Hurd a les mêmes problèmes, les BSD également dans une moindre mesure.
Pour se démocratiser, gagner en visibilité, en parc d'utilisateurs, le système doit être très utilisable. Ca ne plait à personne d'être obligé de rebooter sur un autre OS pour pouvoir utiliser sa carte son son scanner, sa webcam… Ca tue un peu l'intérêt. On comprends que quelques passionnés fassent vivre le projet selon leurs besoins, avec leur matériel; mais est-ce que la base des utilisateurs grossis ? Si ça n'est pas le cas, le projet est condamné à mon avis.
Et pour avoir ce support matériel varié:
1. soit on l'écrit soit même et c'est lourd et pénible (et ça n'intéresse pas les développeurs),
2. soit on se base sur l'existant comme Linux; c'est moins efficace, le compromis fait hurler les puristes; mais ça permet de donner une visibilité sans commune mesure.
Le problème se pose également pour les cartes graphiques…
Je suis très intéressé par tout ce qui touche à Wayland et le réseau (j'ai pas mal de terminaux X sur des serveurs LTSP), mais je suis un peu largué par le journal.
Si je devine entre les lignes, Weston propose maintenant un export en RDP ? Est-ce qu'il est fonctionnellement similaire à ce que l'on fait avec X ? Est-ce que je vais pouvoir connecter plusieurs terminaux sur un même serveur, chacun (chaque utilisateur) ayant son propre bureau ?
Les questions bonus: Est-ce que l'audio est pris en charge ? Est-ce que le stockage local est pris en charge ?
Si la solution de backup est un peu intelligente, elle ne relit pas l'intégralité de tous les fichiers à chaque fois. Surtout les fichiers qui ne changent pas ou quasiment jamais.
Le shell est très permissif avec les variables, et je demande toujours que les scripts soient développés avec:
set -u: Write a message to standard error when attempting to expand a variable that is not set, and if the shell is not interactive, exit immediately.
set -e: If not interactive, exit immediately if any untested command fails. The exit status of a command is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an “&&” or “||” operator.
C'est pénible au début; mais on évite pas mal de bugs bien compliqués, parce que lorsqu'on a un soucis et que le script continue a exécuter 20 lignes de codes derrière avec des mauvaises valeurs; on peut faire de beaux feux d'artifices.
Le montage semble être un bête convertisseur numérique analogique (DAC en anglais) qui produit un signal RVB sur 6 bits. Cette partie là consomme donc 18 ports de sortie.
En réduisant à 1 bit par couleur (soit 8 couleurs), on libère 15 pins supplémentaires.
Sans avoir d'expérience particulière en crypto, le matériel n'est pas parfait et on a rarement accès aux données brutes.
L'ordinateur ou le matériel se contente d'échantillonner périodiquement une valeur analogique pour en faire une valeur numérique. Et on retrouve dans ses données finales pas mal de choses:
Dans le temps, le bruit généré par le secteur (à 50Hz) est tout à fait prévisible. Le bruit généré par tout autre équipement utilisant un signal périodique doit s'y retrouver: écran, bus de l'ordi, GSM, alimentation à découpage, disque dur… Dans le cas du son, on peut avoir une musique qui microscopiquement donne un signal très périodique et très prévisible.
Dans l'espace, la qualité du signal initial est souvent déformé; le micro n'a pas la même capacité à capter toute la gamme de fréquences, la webcam donne une qualité d'image souvent exécrable parce que la plage de mesure est très réduite.
Ensuite le matériel fait souvent une normalisation. Si toutes les mesures de signal se font entre 0% et 5% des valeurs possibles; pour avoir quelque chose d'intéressant, on va multiplier tout par 20, ce qui donnera des valeurs entre 0 et 100%. Parfois cette normalisation se fait partiellement ou totalement en analogique (et de façon plus ou moins réactive), ce qui revient à modifier la sensibilité; parfois elle est bêtement faite en numérique, ça coûte nettement moins cher; et au final on a une large plage de valeurs, mais en n'utilisant qu'une fraction des valeurs possibles. Le cas inverse existe également, on mesure le signal sur 10 ou 12 bits, et on réduit à 8 en sortie. Cette normalisation va faire disparaitre les petits signaux comme un petit bruit à coté d'un bruit fort.
Je ne connais pas les personnes responsables du maintient des patchs noyau pour Ubuntu, mais je doute de leur capacité à réaliser ce fastidieux travail alors qu'aucune autre distribution ne le fera pour ce noyau.
Pur procès d'intention. Pourquoi est-ce que tu doutes ? Tu as des raisons objectives ou bien est-ce juste du FUD ?
En quoi est-ce différent de la situation de Debian Wheezy ? C'est bien Ben Hutchings qui maintient le noyau 3.2 dans ce cas, alors pourquoi reprocher par avance à Ubuntu de maintenir le 3.13 ?
Je pense que cette partie fait référence au fait que le kernel 3.2 a été choisi pour faire de la maintenance sur le long terme, on voit sur https://www.kernel.org/ qu'elle est taggée longterm et que la dernière version est sortie le 9 avril. En plus du mainteneur chargée de produire la version, beaucoup de monde envoi des correctifs.
Le kernel 3.13 n'est plus maintenu depuis le 22 avril par l'équipe kernel. Cela veut dire qu'en plus de tout le travail propre a la distribution, le mainteneur doit aller à la pêche pour récupérer tous les patchs correctifs qui passent pour les intégrer. En prime ces patchs ne seront pas prévus pour le kernel 3.13 et ne lui seront pas spécialement adressés.
J'imagine qu'il va tenter d'intégrer tous les patchs de la 3.12 et probablement de toutes les autres longterm qui sortiront ensuite. Ça représente quand même un gros boulot, les patchs ayant tendance à toucher le code qui vient d'être modifié.
Ça serait sympa que lorsqu'une news concerne quelque chose de géographique; on trouve systématiquement dans le sujet ou dans le premier paragraphe l'emplacement. Là il faut lire quasiment tout l'article pour découvrir que ça se passe pas au centre de l'univers (lieu par défaut).
Pour la fonction distance() basée sur cette formule, sur la terre c'est rappé puisque ce n'est pas une surface euclidienne. Ça limite un peu plus l'intérêt.
Si DNSSEC améliore bien la sécurité, la contrepartie c'est qu'en cas de gag, on a vite fait de rendre toute la zone indisponible, parfois pour une semaine.
Le gros soucis avec UDP, c'est qu'au niveau congestion, il a un effet amplificateur contrairement à TCP.
En TCP, lorsqu'on commence a saturer, on ralenti la transmission. Il y a une fenêtre d'envoi de données qui augmente pour s'adapter à la capacité du lien (même si l'envoi de documents de 2Ko ne suffit pas pour qu'elle fonctionne pleinement).
En UDP, lorsqu'on arrive en timeout, on retransmets la requête; et plus il y a de saturation, plus il y a de pertes, et donc plus de retransmissions.
Google a peut-être les moyens de gérer ça, ça ne risque pas d'être le cas de tous les autres acteurs.
[^] # Re: commande erronée
Posté par Sébastien Koechlin . En réponse au journal Installer un serveur Firefox Accounts et Firefox Sync. Évalué à 1.
Chez moi, sur debian Jessie:
Ne pas utiliser le nodejs de Debian qui est visiblement répudié par les dev nodejs (j'imagine que nodejs embarque des libs trafiquées), prendre celui qui est packagé sur https://github.com/nodesource/distributions (on n'est pas obligé d'exécuter un script en root, on peut ajouter la clef PGP à la main et les lignes qui vont bien dans le sources.list, j'ai pris nodejs 0.12
Installer python3-virtualenv et virtualenv également.
Si vous voulez une petite idée de la place que ça occupe:
Auquel il faut ajouter le paquet nodejs qui consomme 34 Mo en version 0.12
# Super !
Posté par Sébastien Koechlin . En réponse au journal Installer un serveur Firefox Accounts et Firefox Sync. Évalué à 2.
Super idée de partager ça.
J'ai la vieille version du serveur de synchro qui tourne et hélas, c'est fragile et tout aussi opaque, et je désespérais de pouvoir mettre à jour vu que le serveur est abandonné ainsi que la partie client.
Deux remarques après une lecture rapide:
Ca serait bien de décrire sommairement les différentes briques qui tournent sur le serveur et à quoi elles servent.
Quid de la maintenance ? C'est bien beau d'ouvrir un service mais cela ne peut fonctionner que s'il est maintenu. Comme il ne s'agit pas de paquets de la distribution, cela demande de faire des actions manuelles pour vérifier les corrections et les installer.
# clamav
Posté par Sébastien Koechlin . En réponse à la dépêche Recette de cuisine : serveur de messagerie collaborative, inter‐opérant et sans extensions. Évalué à 3.
J'ai aussi installé clamav sur quelques serveurs de messageries, mais il ne trouve jamais rien.
La base est pourtant bien mise à jour quotidiennement; mais je n'ai jamais de rapport de mail bloqué dans les logs (sauf mes tests avec EICAR) et lorsque j'ai le courage de lui faire tester manuellement un fichier manifestement vérole, il ne trouve jamais rien à lui reprocher.
J'ai déjà soumis des fichiers sur leur interface de signalement, mais ça n'a semble-t'il pas eu le moindre effet.
Pour l'instant, je l'ai laissé configuré, mais je suis plutôt déçu.
# C'est où ?
Posté par Sébastien Koechlin . En réponse à la dépêche Hackathon Open Democracy Now! au Numa (Paris) les 22 et 23 janvier 2016. Évalué à 1.
Quand il y a un événement physique, c'est bien de dire où ça se trouve, tout le monde ne sais pas ce qu'est le Numa, ni dans quelle ville ou quel pays il se trouve.
# Certificat pour un usage autre que le web
Posté par Sébastien Koechlin . En réponse au journal Let’s Encrypt en bêta : petit retour d’expérience. Évalué à 3.
Bonjour,
La méthode de vérification me semble un peu limité. Est-ce qu'il est prévu d'autres mécanismes pour les autres cas ?
Si je veux un certificat pour un annuaire LDAP, ou pour un serveur de mail ? Pour un protocole quelconque (et nouveau) ? Ca va être difficile de déposer un fichier à la racine d'un annuaire LDAP.
[^] # Re: Chiffrement opportuniste
Posté par Sébastien Koechlin . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1.
Hélas, ce n'est pas parce que ça n'a pas de sens que ce n'est pas fait; d'ou ma question initiale.
[^] # Re: Chiffrement opportuniste
Posté par Sébastien Koechlin . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 1.
C'est d'ailleurs une question à laquelle je n'ai jamais trouvé de réponse très claire.
Si j'utilise un certificat auto-signé sur mon serveur de messagerie, est-ce que ça va générer des erreurs chez les serveurs qui tentent de m'envoyer un mail ?
[^] # Re: pure bash et un peu long
Posté par Sébastien Koechlin . En réponse au journal Lire de fichiers de configuration depuis un script shell. Évalué à 10.
Sérieusement, quasiment 300 lignes pour lire un fichier ini, traiter les quotes à la main, tripoter IFS et shopt; il n'y a vraiment pas de quoi être fier.
C'est un bel exemple de code complètement non maintenable. En prime chacun y va de sa copie sans jamais faire la moindre mise à jour histoire de variés les bugs d'un code à l'autre.
# Article sur LWN
Posté par Sébastien Koechlin . En réponse au journal Arduino.cc devient Genuino suite à un litige entre ses cofondateurs. Évalué à 6.
Il y a quelques temps LWN y a consacré un article: http://lwn.net/Articles/637755/
[^] # Re: C'est moi ou ?
Posté par Sébastien Koechlin . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 10.
Non, ce n'est pas KSM qui s'en occupe.
KSM permet a ma connaissance de merger rétrospectivement deux pages identiques. C'est utile lorsqu'on utilise plusieurs fichiers identiques (par exemple lorsqu'on a n VM du même OS qui vont chacune avoir la même copie des binaires et des librairies). Ça demande de parcourir la mémoire à la recherche de pages identiques.
Le gestionnaire de mémoire de Linux est capable au moment du mappage mémoire, de voir qu'une page en lecture seule est déjà présente en mémoire dans le système, et de l'utiliser. Cela est possible parce pour ce type de mémoire, le système garde une référence sur le fichier et l'offset qui ont servi à son chargement. Ça évite de dupliquer la mémoire utilisée par les librairies (tel que la libc ou le chargeur dynamique utilisée par tout le monde); en cas de saturation mémoire, ça évite d'avoir à écrire ces pages dans le swap (on pourra les recharger depuis le fichier), et ça permet de ne faire le chargement effectif en mémoire que lorsque (et si) la page est utilisée. Tu trouveras toutes les informations sur la correspondance entre les adresses mémoire et les fichiers dans /proc//maps
L'effet de bord un peu déroutant est qu'il est impossible d'avoir la mémoire occupée par un processus donné. Une partie de la mémoire étant partagée avec d'autres processus, il est difficile de déterminer comment elle doit être comptabilisée.
En prime, les pages en écriture peuvent également être partagées jusqu'à la première écriture par un mécanisme appelé copy-on-write, très utilisé lorsqu'on lance un nouveau processus (fork).
[^] # Re: C'est moi ou ?
Posté par Sébastien Koechlin . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 9.
Pour limiter les risques, il est probablement préférable de dissocier l'upgrade de version et le changement d'architecture.
Crossgrader une Debian permet de passer de i386 à amd64:
https://wiki.debian.org/CrossGrading
[^] # Re: Eh ben...
Posté par Sébastien Koechlin . En réponse à la dépêche Haiku se lâche enfin. Évalué à 9.
C'est dommage, parce que se farcir toute la couche des drivers nécessaire pour utiliser une machine moderne nécessite un travail considérable et peu intéressant.
Hurd a les mêmes problèmes, les BSD également dans une moindre mesure.
Pour se démocratiser, gagner en visibilité, en parc d'utilisateurs, le système doit être très utilisable. Ca ne plait à personne d'être obligé de rebooter sur un autre OS pour pouvoir utiliser sa carte son son scanner, sa webcam… Ca tue un peu l'intérêt. On comprends que quelques passionnés fassent vivre le projet selon leurs besoins, avec leur matériel; mais est-ce que la base des utilisateurs grossis ? Si ça n'est pas le cas, le projet est condamné à mon avis.
Et pour avoir ce support matériel varié:
1. soit on l'écrit soit même et c'est lourd et pénible (et ça n'intéresse pas les développeurs),
2. soit on se base sur l'existant comme Linux; c'est moins efficace, le compromis fait hurler les puristes; mais ça permet de donner une visibilité sans commune mesure.
Le problème se pose également pour les cartes graphiques…
[^] # Re: Bravo!
Posté par Sébastien Koechlin . En réponse au journal FreshRSS, 2 ans et tout va bien.. Évalué à 1.
Je suis étonné, j'ai plusieurs flux RSS de comptes Youtube dans mon FreshRSS. Qu'est ce qu'ils ont de particulier ?
# Plus clairement ?
Posté par Sébastien Koechlin . En réponse au journal wlfreerdp: un client Wayland pour FreeRDP. Évalué à 5.
Je suis très intéressé par tout ce qui touche à Wayland et le réseau (j'ai pas mal de terminaux X sur des serveurs LTSP), mais je suis un peu largué par le journal.
Si je devine entre les lignes, Weston propose maintenant un export en RDP ? Est-ce qu'il est fonctionnellement similaire à ce que l'on fait avec X ? Est-ce que je vais pouvoir connecter plusieurs terminaux sur un même serveur, chacun (chaque utilisateur) ayant son propre bureau ?
Les questions bonus: Est-ce que l'audio est pris en charge ? Est-ce que le stockage local est pris en charge ?
[^] # Re: Pas de problème
Posté par Sébastien Koechlin . En réponse au journal SSD Samsung 840: le fiasco annoncé du TLC ?. Évalué à 4.
Super, il faudrait faire des full régulièrement sinon on est un âne.
[^] # Re: Pas de problème
Posté par Sébastien Koechlin . En réponse au journal SSD Samsung 840: le fiasco annoncé du TLC ?. Évalué à 3.
Si la solution de backup est un peu intelligente, elle ne relit pas l'intégralité de tous les fichiers à chaque fois. Surtout les fichiers qui ne changent pas ou quasiment jamais.
# Et le set ?
Posté par Sébastien Koechlin . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 8.
Le shell est très permissif avec les variables, et je demande toujours que les scripts soient développés avec:
set -u: Write a message to standard error when attempting to expand a variable that is not set, and if the shell is not interactive, exit immediately.
set -e: If not interactive, exit immediately if any untested command fails. The exit status of a command is considered to be explicitly tested if the command is used to control an if, elif, while, or until; or if the command is the left hand operand of an “&&” or “||” operator.
C'est pénible au début; mais on évite pas mal de bugs bien compliqués, parce que lorsqu'on a un soucis et que le script continue a exécuter 20 lignes de codes derrière avec des mauvaises valeurs; on peut faire de beaux feux d'artifices.
# Bête convertisseur Numérique Analogique
Posté par Sébastien Koechlin . En réponse au journal Raspberry B+ : Sortie VGA via le GPIO. Évalué à 5.
Le montage semble être un bête convertisseur numérique analogique (DAC en anglais) qui produit un signal RVB sur 6 bits. Cette partie là consomme donc 18 ports de sortie.
En réduisant à 1 bit par couleur (soit 8 couleurs), on libère 15 pins supplémentaires.
[^] # Re: Le TRNG, moi aussi les bras m'en tombent
Posté par Sébastien Koechlin . En réponse à la dépêche Jericho Chat - Chiffrement incassable utilisant les masques jetables. Évalué à 4.
Sans avoir d'expérience particulière en crypto, le matériel n'est pas parfait et on a rarement accès aux données brutes.
L'ordinateur ou le matériel se contente d'échantillonner périodiquement une valeur analogique pour en faire une valeur numérique. Et on retrouve dans ses données finales pas mal de choses:
Dans le temps, le bruit généré par le secteur (à 50Hz) est tout à fait prévisible. Le bruit généré par tout autre équipement utilisant un signal périodique doit s'y retrouver: écran, bus de l'ordi, GSM, alimentation à découpage, disque dur… Dans le cas du son, on peut avoir une musique qui microscopiquement donne un signal très périodique et très prévisible.
Dans l'espace, la qualité du signal initial est souvent déformé; le micro n'a pas la même capacité à capter toute la gamme de fréquences, la webcam donne une qualité d'image souvent exécrable parce que la plage de mesure est très réduite.
Ensuite le matériel fait souvent une normalisation. Si toutes les mesures de signal se font entre 0% et 5% des valeurs possibles; pour avoir quelque chose d'intéressant, on va multiplier tout par 20, ce qui donnera des valeurs entre 0 et 100%. Parfois cette normalisation se fait partiellement ou totalement en analogique (et de façon plus ou moins réactive), ce qui revient à modifier la sensibilité; parfois elle est bêtement faite en numérique, ça coûte nettement moins cher; et au final on a une large plage de valeurs, mais en n'utilisant qu'une fraction des valeurs possibles. Le cas inverse existe également, on mesure le signal sur 10 ou 12 bits, et on réduit à 8 en sortie. Cette normalisation va faire disparaitre les petits signaux comme un petit bruit à coté d'un bruit fort.
[^] # Re: Fallait attendre vendredi
Posté par Sébastien Koechlin . En réponse au journal Ubuntu 14.04 LTS : Pourquoi il vaudrait mieux ne pas du tout s'en servir. Évalué à 4.
Je pense que cette partie fait référence au fait que le kernel 3.2 a été choisi pour faire de la maintenance sur le long terme, on voit sur https://www.kernel.org/ qu'elle est taggée longterm et que la dernière version est sortie le 9 avril. En plus du mainteneur chargée de produire la version, beaucoup de monde envoi des correctifs.
Le kernel 3.13 n'est plus maintenu depuis le 22 avril par l'équipe kernel. Cela veut dire qu'en plus de tout le travail propre a la distribution, le mainteneur doit aller à la pêche pour récupérer tous les patchs correctifs qui passent pour les intégrer. En prime ces patchs ne seront pas prévus pour le kernel 3.13 et ne lui seront pas spécialement adressés.
J'imagine qu'il va tenter d'intégrer tous les patchs de la 3.12 et probablement de toutes les autres longterm qui sortiront ensuite. Ça représente quand même un gros boulot, les patchs ayant tendance à toucher le code qui vient d'être modifié.
# Évènement géographique
Posté par Sébastien Koechlin . En réponse à la dépêche Amateurs-Nés, seconde édition, festival du cinéma amateur en licence libre les 25-26-27 avril 2014. Évalué à 6.
Ça serait sympa que lorsqu'une news concerne quelque chose de géographique; on trouve systématiquement dans le sujet ou dans le premier paragraphe l'emplacement. Là il faut lire quasiment tout l'article pour découvrir que ça se passe pas au centre de l'univers (lieu par défaut).
[^] # Re: ECMAScript
Posté par Sébastien Koechlin . En réponse à la dépêche Firefox 27. Évalué à 4.
Pour la fonction distance() basée sur cette formule, sur la terre c'est rappé puisque ce n'est pas une surface euclidienne. Ça limite un peu plus l'intérêt.
# DNSSec
Posté par Sébastien Koechlin . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 7.
Si DNSSEC améliore bien la sécurité, la contrepartie c'est qu'en cas de gag, on a vite fait de rendre toute la zone indisponible, parfois pour une semaine.
# Et le DNS ?
Posté par Sébastien Koechlin . En réponse à la dépêche Le programme de Google pour améliorer la sécurité des logiciels libres. Évalué à -4.
C'est dommage qu'il n'y ai aucun serveur DNS dans le lot, c'est quand même une pierre angulaire.
# UDP et la congestion
Posté par Sébastien Koechlin . En réponse au journal Google veut réduire la latence sur Internet avec QUIC. Évalué à 6.
Le gros soucis avec UDP, c'est qu'au niveau congestion, il a un effet amplificateur contrairement à TCP.
En TCP, lorsqu'on commence a saturer, on ralenti la transmission. Il y a une fenêtre d'envoi de données qui augmente pour s'adapter à la capacité du lien (même si l'envoi de documents de 2Ko ne suffit pas pour qu'elle fonctionne pleinement).
En UDP, lorsqu'on arrive en timeout, on retransmets la requête; et plus il y a de saturation, plus il y a de pertes, et donc plus de retransmissions.
Google a peut-être les moyens de gérer ça, ça ne risque pas d'être le cas de tous les autres acteurs.