🚲 Tanguy Ortolo a écrit 12337 commentaires

Ben, vu que FDN passe par les DSLAM de Nerim, c'est mal barré…

Bon, je me réponds tout seul, ce sont les termes d'OVH. C'est inquiétant.

Au passage, j'ai regardé ce que Nerim proposait dans mon possible futur domicile : rien, absolument rien. Pas éligible à quoi que ce soit. Ça ne me surprend pas du tout, parce que pour de tous les endroits que j'ai essayés (chez mes parents, chez mes grands-parents, à mon domicile actuel), j'ai toujours obtenu le même résultat : pas éligible ou éligible seulement à des offres très chères.

• Débit correct et constant, étant un ancien abonné Free cela change la vie. Leur politique de "web neutre" a été un des arguments pour lequel je me suis abonné chez eux.

Tu fais exprès de répondre à une question de moi en parlant de neutralité du Web ? Ou sont-ce leurs propres termes ?

À noter qu'on peut payer par virement et pas seulement par prélèvement automatique.

Yeaaaaaaaaah ! Ça c'est la classe, le virement c'est un truc qu'on peut automatiser mais que le client contrôle totalement, contrairement au prélèvement qui revient à donner les clefs du comptes pour un usage discrétionnaire.

Ce ne serait pas une explication : il me semble qu'un point commun à tous les calendriers est la définition de l'année, faite pour coller plus ou moins bien avec une période orbitale de la Terre autour du soleil.

Bien vu, merci !

Damned, grillé !

Un complément d'Hugo Roy à ce sujet justement : http://hroy.eu/posts/jdn-licences-libres-5-approximations/

Pour remplacer le terme « contaminant », il propose « héréditaire ».

Bravo, c'est une réinvention de ce qui se fait depuis le début de SMTP : ce qui est à droite de l'@, c'est le nom de domaine ou l'adresse IP du serveur de destination.

Chez nous dans ce genre de cas, on écrit généralement de la part du collègue distrait des gentillesses à tout le monde, du genre : « Je vous aime tous et je vous fais de gros bisous. »

Avec des routes dynamiques par BGP donc. Ça implique d'avoir son AS, et la propagation de nouvelles routes n'a rien d'instantané.

Oui, d'ailleurs, si veut faire de la « disponibilité de services », il faut 2 repartiteurs de charge en failover, pour ne pas avoir de SPOF.

Pour avoir un SPoF de moins, parce que tu en auras toujours un avec ces techniques : ton FAI.

La dernière fois que j'avais essayé, j'étais tombé sur une limitation stupide et très, très pénible de l'outil de débogage intégré. Je cherchais à récupérer l'URL d'un contenu téléchargé par un module Flash, grâce à l'inspecteur de trafic réseau. Eh bien, avec celui intégré à Firefox, on peut voir cette URL… mais pas la sélectionner, donc impossible de la copier !

Je laisserai de côté ta moquerie, mais c'est toujours agréable, merci.

Je viens de vérifier, la RFC 2616 qui définit HTTP ne mentionne pas comment les connexions sont établies, donc c'est bon en effet. Si elle indiquait ne serait ce que « le client se connecte au serveur, puis […] », ce serait fichu, parce que cela impliquerait que la résolution préalable a déterminé un unique serveur et qu'il faudrait dès lors s'y tenir.

Si, parce que l'usage d'enregistrements SRV modifie non seulement la résolution, mais également la façon d'établir les connexions, et lie d'ailleurs les deux.

Que je n'ai pas lu, hein, donc je ne sais pas quel est l'avancement du sujet dans ces tickets.

Ça n'avance pas parce que l'utilisation d'enregistrements SFV avec HTTP n'a pas été normalisée. Et oui, c'est la faute de HTTP du coup.

Attention, je n'ai pas dit que l'utilisation d'enregistrements de type SRV était la panacée, en revanche, cela permet de répondre de façon extrêmement simple et raisonnablement efficace à des cas d'usage très courants.

Et donc, surtout, cela permet d'une vraie redondance, qui sans cela ne peut être mise en place qu'avec des délais d'indisponibilité incompressibles en poussant jusqu'à l'utilisation de routes dynamiques par BGP.

C'est pas nouveau, par contre c'est plus joli maintenant (enfin c'est bleu au lieu d'être gris quoi).

Rah punaise, encore un syndrome NIH, à utiliser une interface maison au lieu de se contenter de celle fournie par la plate-forme. Si le gris n'est pas joli et que le bleu c'est mieux, la solution n'est pas de concevoir une interface maison mais de publier un thème GTK+ bleu !

Parce qu'un répartiteur de charge ne va pas attendre de timeout avant d'interroger un second serveur ?

Pour sauvegarder une page, sur à peu près tous les navigateurs : Ctrl + S.
Pour marquer une page, sous Firefox (je ne sais pas quel est le raccourci pour les autres) : Ctrl + D.

C'est censé être nouveau ? J'ai ça dans Iceweasel 30, et il s'agit de la fenêtre de préférences du navigateur, seulement intégrée dans un onglet au lieu d'être détachée.

À noter que tout cela s'applique à un service particulier, le Web, et que cette complexité n'est rendu nécessaire que par un défaut de conception du protocole HTTP et son incapacité à évoluer.

Ainsi, avec d'autres services qui bénéficient protocoles plus moderne à ce regard, tels que SMTP ou XMPP, la disponibilité peut être améliorée de façon infiniment plus simple, en installant simplement un second serveur, en faisant ce qu'il faut pour qu'il collabore avec le premier, et en publiant un simple enregistrement DNS (MX ou SRV) qui indique ce serveur secondaire. Pas besoin de répartiteur de charge, et surtout pas de SPoF lié à ce répartiteur, ce qui permet de faire de la vraie redondance instantanée sur toute la chaîne, ce qui est à peu près infaisable pour le Web.

Tu es dans le cas typique du proverbe « les bons développeurs sont de mauvais empaqueteurs »

Note que ce n'est pas une insulte, hein. C'est comme dire que je suis un mauvais musicien, c'est un fait et ça ne me dérange pas.

Je pensais a installer les dépendances pour mon programme (automatiser la tâche),
car si l'utilisateur cible clique ou exécute (dpkg -i) mon paquetage *.deb il peut soit:

-) avoir installer les dépendances tout seule dans ce cas pas de soucis mon script teste si les paquets sont installé avant l'appel a apt-get.

-) Exécuter bêtement le paquet afin d'installer le programme et dans ce cas le test et l'installation sont utile (sous condition d'une connexion internet et disponibilité de apt-get).

Et que faire si ce n'est pas le cas car le programme ne peut pas fonctionner sans ses paquets.

Fait ça au postinst est une horreur, ce n'est pas du tout le rôle d'un script de post-installation. Il y a dans les infos du paquet un champ de dépendances, qui est là pour ça.

Je doit créer un dossier cacher dans le $HOME de l'utilisateur pour les ressources de mon programme et ça a été un vrai calvaire de créer un paquetage valide car:

Car c'est une pratique horrible également de faire ça par le paquet : un paquet ne doit pas toucher aux répertoires personnels, mais seulement aux répertoires système. L'ajout de répertoires ou de fichiers dans le répertoire personnel de l'utilisateur, c'est au logiciel de le faire, au premier lancement.

Heureusement que l'on peut exécuter un script…

Argh. Jamais un paquet comme ça ne serait admis dans Debian.

Je trouve simplement que lintian est trop stricte et il est vrai que les paquetage se doivent d'être de qualité contrôler

Lintian est strict pour faire respecter des conventions de qualité, que tu cherches à contourner. Il n'est pas étonnant que tu aies du mal. Tu es dans le cas typique du proverbe « les bons développeurs sont de mauvais empaqueteurs » : développeur, tu aimes coder, mais pas empaqueter, tout simplement.