Michaël a écrit 2935 commentaires

À cette heure, un seul programmeur OCaml a répondu au sondage! :-)

Je confirme. J’ai eu la folie de me mettre au violon il y a deux ans. Folie parce que je partais de loin.

J'ai eu la folie de me mettre au chant cette année. Folie parceque je partais de rien. La vie, sans folie, ça pue.

Je suis en train de me battre avec la documentation et les outils debian pour créer un paquet source:

Du temps où j'utilisais Linux (avant de passer sous FreeBSD en 2000), j'étais sous Debian et j'ai donc gardé une certaine affection pour la distribution. Il m'arrive donc d'écrire des paquets pour Debian. Comme toi je trouve la documentation particulièrement imbitable, et j'ai passé une petite demi-journée à packager un programme installable par le mantra (./configure && make && make install) alors que ce devrait être le cas facile!

Lorsque j'ai posé des questions sur la mailing-list j'ai appris que la méthode décrite par les docs était plus ou moins obsolète…

En regard, j'apprécie la grande simplicité et la bonne documentation du système de ports de FreeBSD!

Je crains que l'arrivée nouveau format de paquet signifie la mort des deb pour 99% des applications.

D'après ce que je comprends de la news, le but n'est pas de remplacer les DEB mais de fournir une fonction équivalente aux PBIs. Cela permet aux éditeurs de logiciels de publier des paquets all-included et donc de maîtriser complètement les versions des bibliothèques utilisées par leur soft. Cela leur facilitera la vie pour le support des clients.

Déterminer si on peut utiliser LibreOffice ou pas me paraît bien difficile. Même pour le meilleur des informaticiens ce n'est pas si évident. C'est facile dans une PME de 20 salariés. Un peu moins dans une administration de plusieurs milliers de personnes.

Même le passage d'une version majeure de Office à une autre est un évènement nécessitant beaucoup de préparation (formations, etc.) et de réflexion quant à son opportunité — dès qu'on passe à des grandes échelles.

C'est pas

--exclude={$EXCLUDE_LIST}

mais plutôt

--exclude="${EXCLUDE_LIST}"

Trois conseils: 1. pour le débogage (trace) utilise l'option x du shell ou place un echo devant les lignes que tu veux vérifier; 2. découpe le plus possible ton programme en fonctions, car tu peux tester chaque fonction individuellement pour t'assurer de son bon fonctionnement; 3. lis des scripts shells écrits par d'autres (par exemple les scripts du système), cela t'apprendra des tas de choses!

Le procédé standard est de définir une fonction make_exclude_list du style

make_exclude_list()
{
   grep -v '^#' /etc/backup_OS/exclude.list
}

ou bien si tu préfères éviter d'avoir un fichier externe,

make_exclude_list()
{
   grep -v '^#' - <<EOF
/dev/*
…
EOF
}

et tu définis ta variable EXCLUDE_LIST par

EXCLUDE_LIST=`make_exclude_list`

D'ailleurs à vue d'œil, la relation entre les w,r et n qui marchent est w = 2r x cos(Pi/2n) — cas où des diamètres adjascents se rencontrent en un seul point sur le périmètre du cercle (en fait en 2, il y a deux côtés).

Si tu veux, mais ce n’est pas du tout ce que je recherche. Les formules théoriques seules ne me contentent pas, pour moi sans validation empirique quelque chose de logiquement valide est au mieux quelque chose qui n’est pas logiquement impossible et donc éventuellement dénotable dans une performance physique.

Quand tu fais tes comptes à la fin du mois, tu sors un sac contenant 400000 cailloux pour représenter (en cents) les positons de ton compte courant et les diverses transactions, ou bien tu te fies aveuglement au résultat «théorique» livré par la théorie de l'addition des nombres entiers sans en faire de validation empirique?

D'ailleurs si tu essaies de définir empirique et théorique, je pense que tu vas très rapidement te rendre compte que la différence entre les deux est essentiellement subjective.

Aussi pour moi la géométrie ne se fait pas sans figure à l’appui, sinon j’appelle ça de l’algèbre et pas de la géométrie

La géométrie se fait en dimension plus grande que 2 et 3 et là c'est plus coton de faire des des figures. La frontière entre l'algèbre et la géométrie est très floue — surtout pour le géomètre algébriste que je suis! :-)

Et l’algèbre me rebute d’autant plus quand elle fait appel à tout un tas d’identités remarquables qui sont aussi clair pour celui qui les connais que d’aspect ésotérique pour le profane.

Rechercher une solution qu'on comprend bien est on ne peut plus légitime! Si les banquiers avaient la même sagesse, on ne serait peut-être pas tant dans la mouise! :-)

Utilise METAPOST, c'est un langage de programmation pour faire des dessins (Postscript et SVG). Il est intallé généralement avec TeX (commande mpost).

Sur le TUG tu trouveras plein d'infos: http://www.tug.org/metapost.html

Je te conseille le tutorial d'André Heck (dans la list ci-dessus). En regardan les exemples tu devrais rapidement arriver à construire une macro du style experience(r,n,w) qui trace un cercle de rayon r et n diamètres de largeur w, régulièrement espacés d'un angle de Pi / n — c'est bien ce que tu veux?

Je note la plupart de mes mot de passe dans un carnet et retiens par cœur la poignée de mot de passe vraiment importants (la banque et mes deux mails principaux, machine).

Pour une personne privée (hors contexte entreprise, défense, sûreté, etc.) c'est une politique de sécurité complètement raisonnable.

Je ne sais pas si utiliser une suite de mots présents dans le dictionnaire est une bonne idée: Est-ce que ça ne rends pas vulnérable à une attaque par dictionnaire ?

Tu peux voir un dictionnaire de 300000 mots comme un alphabet A avec 300000 lettres. Un mot de passe habituel est un mot dans un alphabet B avec environ 70 lettres.

Comme log(300000) / log(70) est environ égal à 3, une mot de passe de 6 lettres dans A est aussi sûr qu'un mot de passe de 18 = 3 x 6 lettres dans B.

Si au lieu de regarder un dictionnaire de 300000 mots tu te restreints au 20000 mots les plus courants (alphabet C), le rapport est environ égal à 7/3 et un mot de passe de 6 lettres dans C est aussi sûr qu'un mot de passe de 6 x 7/3 = 14 lettres dans B.

Deux liens:

http://world.std.com/~reinhold/diceware.html

http://xkcd.com/936/

Le probleme c'est que si tu dis je suis sûr il y a plus de X personnes dans 1 m² avec une confiance de 99%, alors il y a plus de 400X personnes dans 400m² avec une confiance d'au moins 33%.

Je ne pense pas avoir dit autre chose, si? Le point crucial c'est que lorsqu'on arrive à 45000m², on peut fièrement annoncer qu'à la manifestation il y avait au moins
45000*X
avec une certitude plus grande que 0%. Ce n'est sûrement pas très informatif, si on ne fait pas mieux qu'une confiance de 0% ce n'est franchement pas la peine se fatiguer à faire des calculs!

La subtilité c'est quand tu parles d'une variation de .2 sur ta moyenne, tu ne précise pas de quelle source de variabilité tu parles. En effet tu as deux sources de variabilités. La première c'est la variabilité de ton estimation, elle doit être assez faible si tu estimes sur une surface suffisament grande ; cette variabilité apparaitra dans le resultat final en étant multiplié par la surface totale.

La variation dont je parle est l'erreur potentielle sur l'estimation de la moyenne en question. Vu qu'il me paraît assez improbable qu'un grand nombre de gens divisé par un grand nombre de mètres carrés tombe sur 2 pile poil, j'ai jugé utile de souligner qu'avec ce genre de méthodologie pourrie on n'est même pas sûr, dans le plus optimiste des mondes où la méthodologie serait bonne, d'obtenir ne serait-ce qu'un chiffre exact sur le résultat.

J'ai ensuite repris l'hypothèse émise par d'autres d'une moyenne de 2 personnes par m². Cette hypothèse est évidemment discutable mais constitue, je pense, une bonne base de départ.

Le problème de cette méthode est qu'avec une superficie de 45000 m² une variation de 0.2 sur ta moyenne te donne une variation de 9000 personnes au total, soit environ l'ordre de grandeur du résultat: le premier chiffre du résultat n'est même pas sûr!

Si tu pars d'une affirmation plus fine du type je suis sûr à 99% qu'il y a plus de X personnes par m², tu peux affirmer être sûr à 33% qu'il y a plus 400*X personnes par 400m² (on a déjà beaucoup perdu en confiance!) mais quand tu passes à 45000m² tu as une confiance de 0 (avec 32 décimales!) dans le fait qu'il y a plus de 45000*X personnes dans la manif.

Ma phrase préférée N°1: «pour que tout cela fonctionne, il faut tout de même des ordinateurs — fabriqués dans des conditions de semi-escalvage — une infrastructure gigantesque (câbles, data center, etc.) […]»

Quand on écrit «fabriqués dans des conditions de semi-escalvage» on ne peut-être pris au sérieux que lorsqu'on distribue les copies de son journal copiées à la main, ou à la rigueur ronéotypées… Ensuite j'aime bien l'idée selon laquelle les câbles sont nécessaires au fonctionnement du logiciel libre. Oui il faut des fils pour que cela fonctionne, mooossieur! Vous n'imaginiez de tout de même que cela fonctionnât sans fils?

ne surtout pas prendre la peine de comprendre le sujet avant d'en parler.

À lire le discours marxo-déprissivo-paranoïaque de notre ami, j'ai l'impression que ce n'est pas seulement le logiciel libre qui lui pose des problèmes de compréhension.

Plus c'est moderne, plus c'est bien!

Le SQL moderne ?

C'était une blague, ce qui est moderne dans l'affaire — par rapport au reste — c'est JSON, et vu qu'il n'y a dans ce cas précis aucune raison de l'utiliser, j'ironise. Tordant. :)

Tu parle d'un format CSV pourri ?

Pourri à ceci-près que c'est la langue que parlent awk, sort, join, etc.

S'il faut choisir entre un fichier JSON qui contient des centaines de

{
  "pkgname":"blabla"
  "pkgversion":"1.0.1"
  …
}

et un fichier texte qui contient des centaines de lignes

blabla|1.0.1|…

je préfère de loin la version 2, qui au moins ne prend pas des plombes à analyser. En extrême recours, on peut introduire des codes d'échappement s'il apparaît primordial de pouvoir traiter les noms de logiciels qui contiennent des |

C'est un exemple real life puisque c'est comme ça qu'est fichu le fichier INDEX-* de FreeBSD — l'information est reproduite dans une BDB, mais ce n'est pas relationnel.

Je pense surtout que c'est à l'utilisateur de choisir quelle doit être la largeur de sa fenêtre, et non un dogme "80 colonnes".

Ta position est complètement dogmatique elle aussi: jusqu'ici tes arguments sont… on est en 2013!

Les bons éditeurs de texte comme Kate savent très bien faire du word wrap correct i.e. en affichant le reste de ligne (repoussé à la ligne suivante) avec la bonne indentation.

C'est peut-être du word-wrap à peu près correct pour du texte, mais pour du code source, se fier au mode word-wrap d'un éditeur c'est la garantie 1. de lire du code imbitable là où du code imbitable a été écrit et 2. de commiter involontairement des modifications d'espacement.

Pourquoi ils n'utilisaient pas une BDD légère genre SQLite, je n'en sais rien.

Ou une BDD encore plus légère comme un fichier texte dont les lignes sont les paquets et les attributs sont séparés par des | ? Plus c'est moderne, plus c'est bien!

Enfin, quelqu'un leur a dit que la meilleure ergonomie atteignable pour éteindre un ordinateur, c'est un gros menu clair avec des gros boutons comme on avait du glorieux temps de Gnome 2 (et, soyons honnête, windows XP).

Je n'ai pas de menu pour éteindre dans mon environnement de travail et j'utilise assez bêtement le bouton power-off de mon PC qui s'éteint proprement grâce à l'ACPI.

Depuis 15-20 ans les ordinateurs sur lesquels sont faits les très gros calculs comme ceux de la météo sont devenus massivement parallèles et les algorithmes ont été adaptés pour en tirer parti.

L'exposé de ne parlait pas de la puissance brute de calcul mais bel et bien d'algorithmes: c'est surtout grâce à une meilleur compréhension mathématique du problème qu'une amélioration des algorithmes a été possible. D'après l'orateur la partie «je vais plus vite car je fais des calculs plus vite» compte pour 1000 et la partie «je vais plus vite car je fais moins de claculs pour arriver au même résultat» compte pour 1000*1000. Après c'est un sujet que je ne connais personnellement pas et je n'ai pas le numéro de l'orateur en question pour lui demander plus de détails!

Oui oui tout le monde sait que python/JS sont aussi rapide que du C++, bien sûr.

Dans les 15-20 dernières années, d'après un membre du Fraunhofer Institut spécialisé dans le domaine, les cacluls numériques utilisés en météorologie sont devenus a³ fois plus rapides (de mémoire a ≈ 1000) où les processeurs sont responsables d'un facteur a et les algorithmes d'un facteur a². Cela signifie qu'un ordinateur vieux de 15 ans utilisant les algorithmes d'aujourd'hui est a ≈ 1000 fois plus rapide qu'un ordinateur d'aujourd'hui utilisant les algorithmes d'il y a 15 ans. Pour aller le plus vite possible il faut donc privilégier l'expressivité du langage — qui va permettre de retravailler les algorithmes avec le plus de souplesse possible — à sa proximité avec la machine.

De plus les processeurs ont des propriétés rendant la comparaison des vitesses d'éxécution de deux variantes d'un même programme impossible^H très difficile, le but étant de la répondre à la question «l'accélération de 90% de mon programme est-elle due à mon patch?» Les processeurs sont, pour faire court, très sensible à la position du code et des données en mémoire, pour plus de détails voir l'article d'Emery et son abondante bibliographie:

http://www.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf

À cause de ces deux faits, la recherche de la rapidité est certainement la dernière des raisons pourlaquelle on doit s'intéresser aux langages de bas niveau, du moins en ce qui concerne le calcul.

Ceci dit, lorsqu'une application desktop rame, la cause serait selon moi plutôt à rechercher dans l'utilisation inappropriée d'un appel système, d'une base de données, ou d'un format de sérialisation inapdaté pour échanger des données (genre XML, utilisé beaucoup plus souvent qu'il ne le devrait: si on ne s'intéresse pas à la validation autant utiliser un format plus léger comme les S-expression ou JSON). Relier dans ce domaine la lenteur d'éxécution au langage utilisé relève plus la naïveté que d'autre chose.

Tu dis cela uniquement parce que tu n'as aucune idée des avantages de limiter la longueur des lignes.

Limiter la longueur des lignes est effectivement indispensable pour faciliter la lecture et 80 caractères sont effectivement une limite à ne pas dépasser, je commence déjà à avoir des difficultés avec cette largeur! Soit dit en passant, augmenter la taille de l'intervalle de ligne facilite également la lecture sur les supports de mauvaise définition (comme un écran…)

Ne t'es-tu donc jamais posé la question du pourquoi les journaux font des colonnes si peu larges ?

Je crois que pour les journaux, le but est plutôt d'obtenir une grille de composition assez fine pour placer le maximum d'articles sur une page ou de permettre la lecture de l'articles lorsque le journal est replié dans le sens de la largeur (souvent en 3 ou en 4, il y a parfois du monde dans le métro!).

ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes.

Au contraire, la taille du fichier compressé est une bonne approximation de la quantité d'information qu'il contient.

Ça fait plaisir de voir qu'il y en a qui suivent! :-)

En ayant lu l’ensemble, je me demande toujours ce qu’est concrètement un visiteur ?

Par exemple Base est abstraite pure et représente les expressions algébriques,les classes dérivées concrètes représentent les atomes (nombres et indeterminées) et les combinateurs + et * (pour simplifier).

Tu peux alors implémenter les algorithmes développer, dériver ou évaluer comme des visiteurs concrets de la classe de base.

Le point clef du modèle est que tu veux implémenter un traitement par une classe (le visiteur) qui reçoit un pointeur sur une classe abstraite, surlaquelle le visiteur ne sait rien faire: les traitements ne sont définis que sur les classes concrètes. En renversant l'ordre d'appel (c'est la classe abstraite qui se présente au visiteur par une méthode virtuelle, ce qui permet de récupérer le type concret de la classe).

En C++ il y a deux mécanismes de polymorphisme: les méthodes virtuelles où la résolution se passe à l'éxécution du programme, et les templates, où la résolution se passe à la compilation.

Du coup quand on lit un truc du style «Le Visiteur template à base de RTTI» qui annonce mélanger du polymorphisme à l'éxécution et du polymorphisme à la compilation, on se dit à quoi bon?

on peut passer par un membre mais c'est moins joli.

Si tu ne veux pas montrer ton membre dans l'espace public, il suffit d'encapsuler l'appel à Visitor::visit dans une fonction qui renvoie la valeur du membre. Au passage, cela permet de donner un vrai nom à la fonction au lieu de visit.

L'implémentation classique du modèle n'est d'ailleurs pas ce que tu donnes: dans Base la méthode accept est virtuelle et abstraite et implémentée dans les classes concrètes Derived1, Derived2. Dans ce cas Visitor::visit(Base& b) est b.accept(*this).