J'ai toujours trouvé checkinstall pratique pour complier, tester avec installation réelle et modifier un soft sans risquer de mettre le bazar sur son système (oui on peut aussi faire des chroot, des VM, … mais bon).
Apparemment cmake a une fonction équivalente, cpack. On peut soit le configurer dans le projet, et il suffit de faire "make package" pour que le projet soit packagé/taré à la fin soit directement lancer l'outil cpack avec toutes les variables sur la ligne de commande. Ici le lien utilise la configuration.

Pour être honnête j'ai pas trop compris, je me mangeais un mur tout le temps comme quoi cpack ne pouvait pas initialier la sortie en "DEB" mais tout à coup ça s'est débloqué après avoir testé d'autres sorties… les magies de cmake et des configurations changées à la volée je suppose (oui j'avais reset le dossier build…).
Bref bien pratique !

GIMP est sorti en version 2.10, version qui a mis 6 ans à être prête. La nouvelle fait un peu le tour du monde libriste, mais en tant qu'utilisateur depuis une version 1.x je dois quand même avouer que j'étais bien triste de lire ça et là que le logiciel était "en perte de vitesse". Et cette version a tout de même beaucoup de points d'amélioration importants, même s'il en reste. Je vous laisse lire la dépêche ! En tous cas les quelques fonctionnalités que j'ai testées sont bien chouettes (exemple, accéder aux entrées menu/outils via une recherche unifiée (par défaut le raccourcis '/')) :)
Ce qui me rend triste et me donne envie d'aider c'est que leur infra de dev a l'air bien mal en point… c'est toujours la même histoire, pas de mystère, rien d'anormal mais tout de même. Peut-être quand j'aurai le temps ? Lol.

On en apprend toujours : j'ai bloqué un moment sur du code C, pour comprendre pourquoi mes printf n'apparaissaient pas quand je faisais une redirection dans un fichier, et un tailf dessus…
Forcément c'était une histoire de buffer, forcément un write allait être la solution. Mais je voulais quand même savoir, et effectivement le buffering n'est apparemment pas le même par défaut si on envoie sur de l'interactif (line-buffered) ou un fichier (full buffering) !

En python on peut quand même bien s'amuser autour du langage… envie de savoir où est installé un module ? inspect.getsourcefile est là. On peut aussi accéder au code du module de la même manière. C'est toujours marrant de voir ce qu'il y a autour du langage, ici pour de la magie avec pyinstaller par exemple.
Je suppose que c'est pareil avec les autres langages du même style.

L'installation d'un module python avec un python perso échoue en chargeant le mauvais module python (le module du système au lieu du module recompilé dans l'install perso de python) ?
Il y a un petit fichier fourni par easy-install qui est changé et qui ajoute au PYTHONPATH des dossiers avant la variable d'environnement ! Et ce fichier est dans le home, donc commun à tous les python que l'utilisateur lance… donc s'il y a le dossier système dedans (va savoir pourquoi…) bah le chargement de modules persos utilise le module système quand même.

Pour mettre le fichier hors d'état de nuire :
mv .local/lib/python2.7/site-packages/easy-install.pth .local/lib/python2.7/site-packages/easy-install.pth.orig

Bonne question : comment on fait pour changer le nom d'un process (visible via ps ou /proc). Par exemple, au lieu d'avoir la commande nginx on voit "nginx: worker process".
Sur cette page, ils disent comment faire en modifiant directement dans argv… ça fonctionne mais ça a l'air crade est pas très souple.
D'ailleurs pour se marrer on peut le faire avec gdb (une fois à un breakpoint) :
(gdb) p argv[0]
$3 = 0x7fffffffe5cf "/home/john/code/a.out"
(gdb) set {char}0x7fffffffe5cf = 'a'
Là ça modifie bien /proc/<pid>/cmdline et ps… mais on ne peut pas par exemple malloc et remplir une string et la poser en argv[0] : ça fait juste rien.

Il y a apparemment prctl (voir https://github.com/electrum/procname) mais ça ne fonctionne que avec "c" comme argument à ps.

J'ai regardé dans les sources de nginx, ils expliquent bien… mais ça sent le gros gros hack :P
https://github.com/nginx/nginx/blob/branches/default/src/os/unix/ngx_setproctitle.c
En tous cas ça fonctionne avec gdb…
(gdb) b main
(gdb) r lala
(gdb) set argv[1] = 0x0
(gdb) p argv[0]
$1 = 0x7fffffffe5ca "/home/john/code/a.out"
(gdb) p strcpy($1, "coucou coincoin lala pouet trucmuche")

for… else en python : je connaissais pas (tombé dessus en lisant un bout de code). Ça peut être pratique en effet, mais si on passe une demi-heure à se demander ce que c'est que ce truc et en vérifiant qu'il n'y a pas de problème tab/space c'est pas forcément un cadeau :)

Tableau de comparaison de libc Linux écrit par l'auteur d'une d'elles, musl (donc pas forcément impartial). J'ai trouvé intéressant quand même, rien que pour la liste des points de comparaison choisis et les notes sur les tests effectués.

Envie de savoir si la compilation a bien profité d'extensions processeur ? Il "suffit" de voir si des instructions spéciales correspondantes sont utilisées. Ici un script bash autour d'un gros coup de grep sur la sortie d'objdump.

Après perso j'ai testé pour AVX et sans avoir spécialement activé AVX il trouvait déjà des instructions … donc je sais pas, peut-être qu'il y en a trop qui sont considérées AVX ?
En tous cas en recompilant avec -march=native, j'avais bien des binaires différents, et même très différents niveau taille (des plus petits, des plus gros…).

Dans GCC, il y a une belle liste d'options spécifiques à la machine (target). Cette commande permet de toute les lister, et de voir lesquelles sont choisies si on demande d'utiliser la machine courante comme référence (native). Je la paste directement ici pour les impatients :)
gcc -march=native -Q --help=target

Petit programme tout simple, sans état (pas de base de données ou de fichier dans les coins), qui exécute des scripts et envoie des alertes en cas d'erreur. En gros, un cœur de monitoring, en version légère et moderne. Il y a le minimum pour cette tâche, mais j'ai autant que possible voulu optimiser les fonctionnalités, il y a par exemple un "'threading" des mails problem/recovery (bien pratique), le moyen de configurer plusieurs vérifications à plusieurs hôtes d'un coup (avec les mêmes paramètres, intervalle etc.), ce genre de petites choses qui simplifient la vie.
Je considère depuis quelques jours que c'est convenablement testé (chez ARN), mais bien sûr pas à grande échelle.
Il a été conçu dans l'optique d'être léger, par exemple dans le cas de l'auto-hébergement : on peut très bien l'installer rapidement chez un autre auto-hébergé et configurer les vérifications de son serveur @home sans se prendre la tête avec un nagios ou autre zabbix du même tonneau.

Tout pareil pour moi, avec les projets geany (que je commence à peine à utiliser). Je pensais que c'était par défaut dans git, mais bon si ça se configure c'est pas plus mal.

Hé oui, pile mon cas avec picomon… comme quoi toujours des surprises. Mais là c'était bien embêtant quand même.

… quand malgré tout le dépôt git veut garder quelques blob au chaud malgré tous nos efforts, on peut encore tenter de virer ce qu'il y a dans packed-refs. A priori ça supprime des "points d'entrée" dans les commit, donc avec un peu de chance ça peut supprimer la raison qui retient git de supprimer cette partie. En tous cas ça a fonctionné ce matin pour moi.

… et surtout la section "Removing a File from Every Commit", c'est assez la classe ! Bon par contre ça ne réduit pas immédiatement la copie locale du dépôt car les commits sont encore liés par le backup de filter-branch et par le reflog. Pour vraiment nettoyer, il faut virer ces deux références et passer le GC, voir la fin de la page de man, c'est tout bien expliqué.

Fixed ? OK mais pas dans le 3.2 de Debian Wheezy… cool ! Bon bin y'a qu'à reprendre la ligne de fix (un peu étrange) avec le decode / encode et hop ça roule.

Hé oui je les ai souvent cherchés, jamais trouvés mais ils existent bien depuis un peu de temps : les tableaux associatifs en bash…

Ils ont fous ces devs. En 2014 tout le monde code en java. Tout ? Non ! Seule une petite minorité résiste encore et toujours à l'envahisseur et code… direct en assembleur :)