Étienne a écrit 707 commentaires

En plus, sur mon compteur, les vitesse indiquées sont les multiples de 20, donc 40, 60, 80, 100, 120, 140.
Or les limitations de vitesse majeures en France sont 30, 50, 70, 90, 110 et 130...
Ça aussi c'est particulièrement crétin !

Au contraire, entre les chiffres il y a un trait plus long pour marquer les dizaines "impaires", c'est plus facile de voir que l'aiguille est alignée sur un trait qu'au milieu d'un nombre (sauf si tu ne sais pas que 90 c'est pile entre 80 et 100).

Étienne

3) Être capable de couper le son de chaque application individuellement par une commande externe. Amarok à des raccourcis clavier pour ça par exemple. Éventuellement utiliser xdotool pour cela.

En utilisant pulseaudio, on a moyen de contrôler le son par application. Il faudrait voir comment le faire en ligne de commande avec pacmd (voir par exemple list-sources et set-source-volume).

Étienne

Je te remercie

Je suis convaincu que si l'on fait régulièrement des équipes de cinq personnes très très doué(e)s et qu'on leur leur lâche les baskets pendant quelques temps, on aura de temps en temps quelque idée géniale qui en sortira

A ce propos, Herb Sutter a rendu hommage à Dennis Ritchie sur son blog en ces termes :

So this young upstart whippersnapper comes along and decides to try to specify a language that will let people write programs that are: (a) high-level, with structures and functions; (b) portable to just about any kind of hardware; and (c) efficient on that hardware so that they’re competitive with handcrafted nonportable custom assembler code on that hardware. A high-level, portable, efficient systems programming language.

How silly. Everyone knew it couldn’t be done.

C is a poster child for why it’s essential to keep those people who know a thing can’t be done from bothering the people who are doing it. (And keep them out of the way while the same inventors, being anything but lazy and always in search of new problems to conquer, go on to use the world’s first portable and efficient programming language to build the world’s first portable operating system, not knowing that was impossible too.)

Je tente une traduction :

Ce jeune freluquet est arrivé et a essayé de spécifier un langage permettant d'écrire des programmes qui soient: (a) de haut niveau, avec des structures et des fonctions; (b) portable sur à peu près tout type de machine; et (c) efficace sur ce même matériel de sorte qu'ils soient compétitifs vis à vis d'assembleur spécifique écrit à la main. Un langage pour la programmation système de haut niveau, portable et efficace.

Quel inconscient. Tout le monde savait que c'était impossible.

Le C est un cas d'école de la raison pour laquelle il est essentiel de garder les gens qui savent que quelque chose est impossible à l'écart de ceux qui la réalise. (Et les écarter pendant que cet inventeur, qui était tout sauf feignant et toujours à la recherche de nouveau problème à résoudre, utilisait le premier langage système portable et efficace pour construire le premier système d'exploitation portable, sans savoir que c'était également impossible).

Désolé pour la faiblesse de la traduction.

Étienne

Dans une migration vers un autre gestionnaire de source, l'aspect humain est je pense beaucoup plus important que l'aspect technique. Je pense que pour réussir sa migration, il faut plusieurs ingrédients :

1. commencer par mettre en place une solution qui change le moins de chose possible, c'est à dire garder le même workflow (un repository centralisé qui sert à tout le monde)
2. mettre à disposition des docs très simples à suivre pas à pas pour les actions de base, c'est à dire :
   • faire un checkout
   • faire un commit
   • faire un merge
3. utiliser le DVCS pendant quelques temps sans changer les habitudes

Avec ce système, on voit déjà l'intérêt de Git ou Hg par une gestion des merges beaucoup plus puissante qui donne beaucoup moins de conflit, on peut aussi commencer à voir qu'on peut faire des commits dans son coin sans impacter personne et ainsi jalonner son travail.

Le changement du workflow peut se faire dans un second temps. Je suis d'accord avec toit qu'un workflow intégrateur est très intéressant mais il est plus facile de le vendre comme un changement d'habitude que comme un changement d'habitude et d'outil.

Si on regarde le projet PostgreSQL, ils ont fait une transition de CVS vers git, mais pour le moment, ils n'utilisent qu'une partie de git, par exemple ils se refusent à faire des merges et font uniquement des rebase pour garder un historique linéaire comme ils en avaient l'habitude avant. Ils ont maintenant les bases techniques pour faire des changement d'organisation plus tard. (voir à ce sujet l'article sur l'indispensable lwn : Lessons from PostgreSQL's Git transition

Pour terminer, il est intéressant de bien vendre sa migration. C'est à dire repérer dans l'outil actuel ce qui pose problème : dans une migration que j'ai eu à faire, on utilisait svn avec des branches et l'équipe était relativement nombreuse (une petit quinzaine). Les merges devenaient vraiment compliqué, malgré l'utilisation de svnmerge (plus tard intégré à la version 1.6 de svn si mes souvenirs sont bons). J'ai commencé à faire des essais avec git-svn, puis sur un développement que j'avais à faire avec quelqu'un d'autre nous avons travaillé à 2 avec git. L'opération étant concluante, il a fallu bien préparer la migration et convertissant tous les outils (divers scripts, intégration continue, génération des fiches de version logiciel, etc.) et préparer des docs hyper directives. La migration a pu être vendue sur la facilité des merges par rapport à l'outil précédent et le fait que tout soit prêt à l'avance a permit de limiter les problèmes techniques rencontrés et grandement facilité l'adoption.

Étienne

Tes propos sont très vexants. Tu ne me connais pas. Tu devrais te renseigner sur les gens qui postent avant de répondre

Désolé de t'avoir vexé, ce n'était pas du tout le but, je suis simplement étonné qu'entre la mort de Steeve Jobs et Dennis Ritchie, on voit des milliers de gens faire des remerciements aux mort et je me disait simplement que c'est l'occasion de penser à ceux qui sont encore là. Désolé si ça passe pour une leçon de morale mal venue, c'était plus une invitation à ne pas attendre que les gens ne soient plus là pour prendre conscience de leur apport.

Encore désolé

Étienne

C'est un petit peu tard. Il risque de ne pas te répondre. C'est marrant il faut attendre que les gens cassent leur pipe pour être remerciés. Il faudrait plutôt en profiter pour remercier Ken Thomson ou Rob Pike pendant qu'il est encore temps.

on me dit que Steve venait tout juste de passer sur Android

Visiblement ça ne lui a pas réussi.

Il y a aussi les messages des anonymes :

http://www.20min.ch/ro/news/suisse/story/Les-fans-se-recueillent---New-York-27638794#showid=40885&index=2 pourquoi le mec il dessine une bite ? A mon avis c'était un proche.

J'ai une nièce âgée de 1 mois, et déjà les commentaires fusent : "elle est belle", "elle sera très belle quand elle sera plus grande". Mais merde, on ne dit pas ça d'un garçon.

Non, on dit "il est beau", "il sera très beau quand il sera plus grand".

Mais les contributeurs BENEVOLES ils ne cherchent pas à vivre de leurs contributions. Enfin merde Raphaël est un gros contributeur à Debian qui cherche à vivre de ça (et ce n'est pas facile, si vous regardez sur http://raphaelhertzog.com/support-my-work/ il récupère quelques dizaines d'euros de flattr et paypal par mois), il se dit que faire la traduction de SON bouquin peut lui permettre de vivre de cela pendant quelques mois, que faire payer la libération peut lui permettre de contribuer à d'autres choses sur Debian pendant encore quelques temps (par exemple bosser sur dpkg ou sur l'un des 26 packages qu'il maintient) ; et tout ce qu'il récupère comme commentaire c'est :

• Si j'ai un peux compris le sens du truc, on peut payer pour que vous récupériez vos droits auprès de l'éditeur afin de le traduire en Anglais ? Si je suis dans le bon sens, je n'aime pas !!!!! pas du tout , et je dirai même "gonflé"
• Je trouve particulièrement douteux quand même de refuser l'aide de la communauté pour traduire bénévolement le document en anglais
• Cependant demander de l'argent pour traduire un livre le publier sous licence libre et paradoxalement refuser toute contribution qui pourrait accélérer sa traduction et requérir moins d'argent, je trouve cela un peu limite.
• Et j'en passe ...

Et après ce sont les même qui vont nous dire que libre ne veut pas dire gratuit, qu'il n'y a aucun problème à vivre du libre, que le principe c'est qu'une fois payé, un développement est gratuit ... encore faut-il réussir à se faire payer une fois.

Étienne

PS: par ailleurs, je vous invite à vous renseigner sur le bonhomme, par exemple sur sa page web.

Si j'ai un peux compris le sens du truc, on peut payer pour que vous récupériez vos droits auprès de l'éditeur afin de le traduire en Anglais ? Si je suis dans le bon sens, je n'aime pas !!!!! pas du tout , et je dirai même "gonflé" .

Je crois que tu as mal compris. Tu paye pour qu'ils puissent passer le temps nécessaire à la traduction et continuer à bouffer et faire bouffer leurs familles. L'accord d'Eyrolles ils l'ont déjà, mais il ils estiment à 3 mois à 2 le temps nécessaire à la traduction, c'est à cela que correspondent les 15000€, et à mon avis ce n'est vraiment pas cher payé si la traduction est bien faite.

Étienne

Je ne vois pas ce que systemd a à voir là-dedans.

C'est via systemd que Gnome pourrait récupérer l'association des périphériques par siège. Cf http://www.freedesktop.org/wiki/Software/systemd/multiseat

Étienne

Je pense que la grosse différence c'est que ack ne scanne que les fichiers qu'il connait, par exemple il ne scanne pas les fichiers sans extension. Sur ma machine quand je lance ack dans /etc il me scanne 381 fichiers (1981 avec un ack -a qui continue à en louper plein) là où grep m'en scanne 7535.

C'est d'ailleurs un des pièges de ack qui, rappelons le, n'est pas un outil généraliste, on peut passer à côté de fichiers qu'il ne scanne pas sans s'en rendre compte.

Étienne

Pourtant il y a parfois des cores beaux. Mais on ne va pas en faire un fromage.

Si on tape avec 2 doigts c'est vrai, avec 10 doigts ack se tape avec "auriculaire gauche", "index gauche", "majeur droit", ce qui est plus facile sur un clavier azerty (on alterne les doigts) que "index gauche", "index gauche", "majeur gauche", "annulaire droit" ;)

Étienne

Dire que ack est mieux que grep c'est comme dire que la carte au 25000ème est mieux que la carte au 500000ème, c'est vrai pour la randonnée, pas pour traverser une région. Ack est un outil plus spécialisé que grep et pour une activité de codage est plus adapté que grep (comme rappelé, le fait qu'il ignore les répertoires de VCS ou les fichiers de sauvegarde, qu'il connaisse les types de fichiers et permette de filtrer dessus).

Si on veux faire un grep dans tout /etc par exemple, grep sera plus rapide que ack (le point 1 de la dépêche veut en fait dire : "ack est plus lent que grep pour le matching mais il compense en ne cherchant pas dans tous les fichiers", c'est intéressant si on ne veut pas chercher dans tous les fichiers).

Voilà c'était juste pour tempérer la remarque "mieux que grep", je l'utilise personnellement en remplacement de grep pour mes activités de codage, mais je n'ai pas pour autant remisé grep au placard.

Sinon merci pour la dépêche, ack mérite d'être un peu plus connu.

Étienne

Le deuxième ne sert que pour le décore en fait.

Il me semble (d'après http://www.postgresql.org/docs/9.1/static/warm-standby.html#SYNCHRONOUS-REPLICATION), que le maitre valide la transaction dès qu'un esclave est à jour et non pas dès que tous les esclaves sont à jour comme indiqué dans la dépêche.

Ceci permet de s'assurer que si la maitre tombe, la transaction existe quand même ailleurs en au moins un exemplaire. Ce qui permet d'avoir un compromis entre performance et fiabilité.

Sauf que Linus ne fait jamais de pull du repo principal car il n'y a que lui qui commit dessus. Au prochain push, git lui dira qu'il faut puller et ça risque de lui mettre la puce à l'oreille.

Étienne

Juste pour préciser que "learning Go" n'est pas sous CC by-sa mais sous CC-by-nc-sa. Donc pas d'utilisation commerciale.

Étienne

Honnêtement, en dehors de fait que c'est une syntaxe bash, la différence de complexité avec arora.spec n'est pas énorme.
J'ai l'impression qu'on surestime pas mal la complexité de faire des packages, qui est souvent plus liée à la complexité de compiler le soft que le packaging lui-même.

Étienne

Ouais enfin la SM qui fait des trucs dans mon dos j'ai pas trop confiance non plus.

Il faut faire attention qu'il y a 2 attributs manipulés par un shared_ptr :

1. Le pointeur vers l'objet
2. Le compteur de référence

La garantie identique au type pointeur de base que tu évoque dans le premier paragraphe concerne l'accès au pointeur (par exemple les fonctions get(), reset(), operator*())

Le point que tu évoque sur l'aspect lock-free concerne le compteur de référence. C'est à dire que plusieurs threads peuvent copier le shared_ptr, puis détruire des shared_ptrs, l'accès au compteur de référence est protégé par l'utilisation de fonctions atomiques (lorsque le CPU et boost les gèrent).

On peut regarder sur boost/smart_ptr/shared_ptr.hpp que la classe shared_ptr contient 2 membres :

• T * px
• boost::detail::shared_count pn

C'est cette deuxième classe qui utilise des fonctions atomiques définies dans sb_counted_base, on peut par exemple regarder boost/smart_ptr/detail/sp_counted_base_sync.hpp qui utilise les fonctions fournies par gcc (voir Atomic-Builtins).

Étienne

C'est sans doute le seul gag présent sur le DVD d'ailleurs.