Ignatz Ledebur a écrit 427 commentaires

Oui, j'ai vu, et c'est entre autres pour ça que ça attendra le changement de machine (sur celle-ci, il m'arrive de « perdre » le disque, ça ne devrait donc pas trop tarder :).

On voit bien que vous ne connaissez rien au marché (saturé) que vous prétendez pénétrer. Eh oui, les petites crevures félines hirsutes et effarées c'est l'Almanach du facteur, les pompiers s'adonnant depuis des années à un étrange cosplay « Power Rangers sous acide ».

Présentez un truc qui marche fièrement depuis des années, il se ratatine en pleine lumière. Le résultat attendu est bien sûr :

$ revolution /tmp/cycle month 2 12/11
/tmp/cycle: the 12 of every 2 months, completed next on the 12/11/2014.

La date indiquée étant celle (optionnelle) du début du cycle. Corrigé.

Merci pour les précisions et pour le tuyau sur LIBVGL. Je pense que ma prochaine machine que j'espère prochaine (l'actuelle est une vieille 32bits avec trop peu de disque pour l'aventure) commencera son service par un tour de libellule, et plus si affinités. :)

Ne connaissant pas anachron, je m'étais fait un petit programme AWK pour gérer ce genre de choses (ménage dans le système, remise à l'heure, sauvegardes, etc.), baptisé revolution.

C'est une approche plus basique qu'anachron, mais peut-être plus souple dans la mesure où il n'y a pas de fichier de configuration central.

L'idée est que tu crées un fichier de cycle où tu veux :

$ revolution /tmp/cycle month 2 12/11
/tmp/cycle: the 12 of every 2 months, completed next on the 12/12/2014.

Puis que tu l'évalues depuis un script de démarrage ou de login (la commande re-initialise le cycle et renvoie 0 si celui-ci est complet) :

if revolution /tmp/cycle; then
  commandes_au_jour_dit
fi

Je ne dis pas que c'est révolutionnaire, mais chez moi ça fait son boulot depuis plus de 3 ans… :)

Merci pour ce journal, car ça fait un bout de temps que me mettre (je veux dire vraiment, pas en touriste) aux BSD me titille, avec je dois bien le dire une forte envie de bouffer de la libellule.

un détail cloche, tu te retrouves devant une magnifique ligne de commande en 80x40, muni d'une police de caractères ne supportant pas UTF-8, te demandant si tu n'as pas été propulsé 40 ans dans le passé. Don't panic. Il est temps d'y remédier.

En faisant des recherches (quand je dis que ça me titille), j'ai vu à ce sujet qu'il y avait le projet vt chez freebsd pour moderniser la console, ça en dit quoi du côté de la libellule ? Bon de toute façon j'imagine qu'il ne faut pas escompter avoir un framebuffer à la Linux (avec possibilité d'y faire tourner MPlayer ou un équivalent fbida, par exemple), d'où in fine la nécessité de travailler sous X.

Hammer fournit d'autres fonctionnalités assez pratiques, comme la déduplication ou la réplication automatique, que je te laisse découvrir en consultant le manuel.

Il me semble avoir lu qu'on peut aussi utiliser UFS, quel est vraiment l'intérêt de HAMMER sur un ordinateur de bureau ? Par exemple, j'ai toujours employé EXT (3 puis 4) sans jamais ressentir le besoin de passer à autre chose (je fais régulièrement des sauvegardes, du reste pas énormes, principalement du texte), est-ce qu'UFS ne serait pas suffisant pour avoir l'équivalent (j'ai l'impression qu'HAMMER a plus à voir avec btrfs, alors que je privilégie le terre-à-terre de la fiabilité aux fonctionnalités « magiques » ) ?

La structure d'une recette est quand même assez basique (une liste d'ingrédients, une liste d'étapes de préparation, puis éventuellement une liste de conseils/commentaires), d'où la possibilité de se contenter d'un sous-ensemble du html (comme epub 2). L'avantage étant d'avoir un format source hyper-répandu et nativement publiable en ligne. De plus, si ensuite on ne veut pas passer par une traduction LaTeX, avec une bonne CSS d'impression il devrait être assez simple de faire l'export vers le pdf via l'interface de M. ToutLeMonde qu'est le navigateur (le papier est ce qu'il y a àmha de plus pratique pour l'utilisation en cuisine).

C'est très controversé, d'autant que l'éclairage consomme de moins en moins.

Cette activité m'a appris énormément mais m'a aussi montré les limites du shell et de Bash. Je pense donc me tourner vers Python3 à l'avenir, ce que j'en ai vu jusque là m'a beaucoup plu.

Alors c'est comme ça ; après tous les trucs bien crapuleux que je t'ai faits en AWK, c'est par voie de presse que j'apprends que je suis lourdé ? :)

À ce sujet, on peut signaler aux aventuriers qu'un travail a été engagé pour utilser LFS avec un init basé sur runit.

C'est vrai que dans le premier message auquel je réponds, Mickaël parle de problèmes au-delà de « l'extraction de pures données », ce qui anticipe l'essentiel de mes objections. Du coup on est bien d'accord qu'il faut plus qu'iconv et un AWK UTF-8 dans ces cas-là. Manque d'attention de ma part : Sorry for the noise, comme qu'on dit…

Dans mon commentaire, je dis que awk montre ses limites quand on a besoin de Unicode et tu réponds que ce n'est pas le cas parcequ'on a en pratique pas très souvent d'Unicode: c'est une réponse à côté de la plaque!

Non, dans ma réponse, je dis plusieurs choses :

1. tu parles d'Unicode, mais dans le contexte du travail en shell, il vaudrait mieux parler d'UTF-8, qui sera soit l'encodage Unicode des documents sources, soit pourra être obtenu en passant ceux-ci à iconv (ex. une page HTML UTF-16 peut sans problème se traduire en UTF-8) ;
2. les cas où on a un réel besoin de l'UTF-8 pour travailler sont rares ;
3. au pire, si vraiment on en a besoin, on a GAWK. qui gère (très bien) l'UTF-8 (comme lo Heirloom d'ailleurs, mais je ne sais pas ce qu'elle vaut).

Plus généralement, le problème que tu pointes n'a encore ici que peu à voir avec Unicode, mais plus avec le support de l'encodage en général. On pourrait plutôt dire que dès que tu ne peux plus supposer que l'utilisateur traite des documents en accord avec son LC_CTYPE, le shell ne convient pas (même en Perl, ce n'est pas une partie de plaisir : extraire l'encodage du source, langinfo &cie pour obtenir le charset local, configuration des différents descripteurs… )

(Au passage, ce que tu pointes précisément a en fait plus à voir avec la capacité à supporter la locale qu'avec unicode, une locale avec un encodage 8bits posant les mêmes difficultés quant à l'usage de classes de caractères « nommées ».)

C'est vrai, mais dans le cadre du shell, ça reste du contenu, pas de la syntaxe. Ce que je veux dire, c'est que tu prennes du HTML, du Mardown, du LaTeX, du Groff, de l'INI ou n'importe quel fichier de configuration, tu n'as besoin que de l'ascii pour en faire l'analyse syntaxique. Après, que tu puisses avoir besoin d'unicode pour l'analyse du contenu introduit par l'utilisateur, on est d'accord, mais on est alors au-delà de la stricte analyse syntaxique (en HTML, ça reviendrait à analyser du #PCDATA, ce pourquoi effectivement le shell/awk n'est probablement pas l'outil le plus adapté).

J'ai guillemetté à cause de la taille moyenne d'une bibliothèque supportant UNICODE de façon poussée ou quasi complète.

Unicode sera quasi-toujours implémenté en UTF-8 au niveau du shell (pour la compatibilité avec l'ASCII) et pour le reste, il y a toujours la commande standard iconv. Quant à Gawk, s'il est vrai qu'il grossit de manière inquiétante, il demeure au moins aussi performant que la version de Kernighan, y compris en UTF-8 (non supporté par cette dernière — mais la plupart du temps, à part pour la longueur des chaînes dans le formatage des sorties, on s'en moque, car il n'y a aucune raison d'employer des caractères non-ASCII comme clés de formatage interne, bien au contraire).

il existe de nombreuses variantes de 'ls' et le résultat peut aussi dépendre de la locale.

Je suis d'ailleurs surpris de ne rien lire au sujet de la locale dans ce journal des bonnes pratiques. C'est en effet généralement une bonne idée de toujours commencer par positionner LC_ALL (qui. rappelons-le, ne devrait jamais être définie dans l'environnement courant) à "C", afin que les commandes aient des sorties formatées conformément à POSIX (en plus de gagner en performances pour les commandes où l'ajout d'utf-8 s'est fait avec un certains coût), quitte ensuite à l'enlever à certains points précis (avant mailx, par exemple, qui dans sa version Heirloom échouera à envoyer le message si son encodage n'est pas en accord avec la locale).

Dans le même genre, on peut aussi mettre systématiquement le masque à 022, afin d'éviter les mauvaises surprises si le script doit créer des dossiers/fichiers.

Je ne vais pas trop rebondir sur tes parallèles politiques (intéressants), mais je pense que cette forme de "modération par les pairs" est aussi prône à des abus qu'une concentration du pouvoir dans une catégorie choisie de modérateurs—d'ailleurs sur LinuxFr on a les deux, et on entend moins parler du second.

C'est un très vieux débat, dans les textes antiques tu trouves déjà toutes sortes de réflexions pour déterminer si le meilleur régime est démocratique, oligarchique ou monarchique, avec des arguments pertinents de part et d'autre (la question était réellement ouverte à l'époque).

J'ai l'impression que la récompense par les pairs fonctionne bien, mais que la punition par les pairs est plus délicate à mettre en place et a un rapport gains/coûts qui n'est pas évidemment en sa faveur. Mais le problème de fond ce n'est pas ça, c'est l'ambiance générale des discussions—ceci dit, il est bien possible que les pratiques de notation participent à plomber cette ambiance.

Le truc que je me suis toujours demander pour ma part, c'est l'utilité de moinser. Dans la vie on fréquente aussi des gens qu'on peut trouver odieux et obtus, or on ne peut pas leur clouer le bec au chatterton avant de les couvrir d'une bâche opaque, alors précisément que c'est là où ils sont le plus dur à supporter et le plus inévitable. Sur internet, il est au contraire si facile d'arrêter de lire un contenu affligeant et de passer à autre chose — d'ailleurs, quand on voit la dégringolade du nombre d'évaluations sur les messages dans les fils qui s'éternisent, c'est ce que semblent faire les gens ici plus que tout autre chose.

Pour le plussage, sur les forums d'accord (on dépatouille, c'est une question de politesse), mais pour des opinions, ça me paraît nettement plus discutable : est-ce qu'on peut vraiment remercier quelqu'un dans ce contexte ? on exprime plutôt son accord, àmha, ce qui est souvent au cœur des débats sur le (prétendu, parce que ça me paraît en fait être sa fonction intrinsèque) dévoiement du système de notation.

De plus, souvent (hors jeu de réponses à ralonge où une partie de la population est passée à autre chose), le -10 est un truc du genre +20/-30, donc je me remet en question sur quoi? le -30 ou le +20?

Sur rien. Les messages qui arrivent à cumuler une trentaine d'évaluations sont plus que minoritaires, alors que j'ai déjà vu un post « Preum's ! » se manger un -70. Autrement dit, non seulement toute note est statistiquement insignifiante (en absolu et relativement au nombre de comptes actifs sur LinuxFR), mais en plus aucune ou presque n'est évaluée par la totalité des gens utilisant le système – binaire – de notation.

quand on a des arguments convainquants en face plutôt qu'une religion incohérente haineuse des autres sans réfléchir).

Le problème, c'est que tes contradicteurs pensent exactement le même chose, en entendant évidemment quelque chose de très différent par « argument convaincant ».

Ça me rappelle un ancien dirigeant du Shin Bet, qui avait lors d'une rencontre avec le camp palestinien réalisé que ce qu'il appelait du terrorisme était pour les autres de la résistance – je veux dire qu'il devait de par ses fonctions parfaitement connaître les discours de l'ennemi, il n'avait simplement jamais pensé jusqu'alors que ça pouvait être autre chose que de la vile propagande.

Je rendrais aussi les champs optionnels

Dans l'idée, tous les champs peuvent être omis, c'est pourquoi il n'y a pas besoin de spécifier « - » à la place de « + », un titre de tâche n'ayant aucune raison de commencer par [+-#@].

je tiendrais compte des blancs au début de ligne (un indent) pour faire des taches hiérarchiques.

Si une tâche est requise par deux autres tâches, elle sera nécessairement placée avant celles-ci dans la liste, si elle est propre à une tâche alors sa place est dans la description de celle-ci. De plus, étant donné qu'on gère la liste via l'éditeur, il est très facile de faire des renvois, ne serait-ce qu'en plaçant des ancres du style :revoir_module_xxx dans la description de la tâche puis cf. :revoir_module_xxx à la fin de celles concernées. Même un éditeur basique devrait s'en sortir.

Typiquement, le sous-découpage en items me paraît un tic de pensée informatique, où effectivement un programme est une suite de petites résolutions. Mais humainement, si on n'est pas foutu de se rappeler que pour ranger le garage on a besoin du camion d'un pote (exemple sur le site de todotxt), on a un problème qu'aucun logiciel ne pourra jamais résoudre.

(J'ai pas réussi non plus à formater ce que je voulais.)

Je me suis lancé dans un bout de C (comme ça, je suis certain de n'avoir jamais le courage d'y ajouter autre chose que le strict nécessaire), je verrai bien si ça tient effectivement la route (si toutefois j'arrive au bout :).

Ce que je ne comprends pas dans vos systèmes, c'est la notion d'aléatoire, car il y a quand même très peu de chances que ça vous ressorte quelque chose que vous ayez le temps et l'humeur d'accomplir. La manière la plus naturelle paraît être de simplement parcourir la liste pour voir si quelque chose accroche.

Sinon, j'ai remis le nez dans tofu, et y a pas, ça me gave. C'est beaucoup trop compliqué pour mes besoins, si complètement aux antipodes de mes attentes présentes que c'en est fascinant. Du coup j'hésite vraiment à y ajouter encore quoi que ce soit.

Ce journal me donne presqu'envie de recoder autre chose, sur un ou plusieurs fichiers (un par projet ?) avec un format du genre :

 ! @140725 #tag0 #tag1 + Coder un petit truc pour remplacer tofu

Actuellement, c'est trop compliqué, et les todos, de toutes façons, ça
sent la crevette.

Pour l'implémentation, c'est très simple…

—
#tag0 Peut-être quand même terminer l'intégration des dates butoirs dans tofu

Tout ce qui précède le titre de la tâche est optionnel et signifie : sortir en haut de pile et graissé (!), date butoir (@AAMMJJ), tags (#tag),présence d'une description de tâche se terminant par deux tirets sur une ligne (+). Pour les priorités, on peut soit bosser sur plusieurs fichiers toujours appelés dans le même ordre, soit simplement en déplaçant les tâches à l'aide de l'éditeur. C'est un truc dans cet esprit que tu recherches (a priori, c'est faisable en shell) ?

P-S. Désolé pour la mise en forme, mais je n'arrive pas à tout placer dans le bloc littéral…

A contre-pieds, il y a le post de Jeff Atwood à ce sujet:

Effectivement, je retrouve le gros de mes griefs contre les todos en particulier, et plus généralement contre tout ce qui est « statistification » de soi.

J'utilise des post-it papier pour les trucs du quotidien.

Pareil, je fais des blocs de récup' où je note des rappels (un mot ou deux) de ce que je dois voir dans le futur immédiat, tofu ne me servant que pour les choses à moyen ou long terme, que précisément je veux me sortir de la tête pour le moment. Cela dit, je vais peut être voir pour l'ajout de dates butoirs, histoire de pouvoir éventuellement l'utiliser en tant qu'agenda du pauvre.

Vu que tu bosses en texte, j'imagine qu'une solution en ligne de commande ne te fait pas peur.

avoir une catégorie de tâche (genre "codebase A", "système", "linuxfr", etc..), mais avec la possibilité de multicatégoriser les tâches

Tu peux mettre autant de tags que tu veux, puis sélectionner ou exclure en fonction.

avoir un historique des tâches terminées, et des tâches poubellisées qui soit différent

Pas à la base, mais en jouant avec les macros (oui, il y a un petit mécanisme de macros), peut-être. La philosophie de base, c'est plutôt qu'on ne parle plus de ce qui est fait.

Pouvoir éditer/ajouter des infos aux tâches

Chaque tâche est éditable en tant que fichier texte : la première ligne en est le nom, et ensuite tu peux y raconter ta vie (pratique pour les idées sur l'implémentation et le rappel des difficultés qu'elles doivent prendre en compte).

avoir une possibilité de mettre une urgence (et/ou une date butoir)
avoir une possibilité de mettre une priorité

Couleur et/ou tag + macro. C'est ce que j'utilise, avec trois niveaux de priorité, mais on peut raffiner. Pas de date butoir, ça dort dans ma todo, mais je n'en ai guère l'utilité.

avoir une vue d'ensemble global/par catégorie

Chaque tag peut être promu en catégorie (file), limitant les actions et la vue aux seules tâches le portant.

avoir une zone "magma": les tâches que l'on met dedans apparaissent en mode 'random' lors de la vue globale.

En fait les projets ne sont que les tags que tu vas promouvoir en tant que tel, une tâche n'a pas à être rattachée à l'un d'eux et peut donc vivre sa vie dans la file principale.

Je vais être honnête, tofu n'est pas ce qu'il y a de plus facile à prendre en main, son UI étant l'accouplement improbable de find (les sélections de tâches précèdent les actions à effectuer sur celles-ci) et de dd (opérateurs du style "x=y"). Mais bon, je me suis fendu d'un tuto, et je reste au pire joignable par courriel. Aujourd'hui, je l'utilise principalement comme boîte à idées, tout ce qui est GTD me donnant littéralement la nausée (se retrouver dans l'inéluctable accumulation de son bazar, d'accord, mais vivre une vie de machine dont le but ultime est d'abattre le maximum de tâches, quelle désolante conception de l'existence ! – ce qui certainement explique aussi qu'il n'y a pas d'historique de quoi que ce soit).

Pas selon ce post, ce qui me paraît crédible dans la mesure où autrement mon Karma/intervention est dans les mêmes eaux que celui de patrick_g (alors que je fais rarement de gros scores).

Ton compte date d'avant la remise à zéro, si tu veux une mesure qualitay, tout ce qu'on peut faire c'est extrapoler en appliquant le ratio d'intervention aux jours écoulés depuis la remise à zéro (le 20 février 2011, selon mes recherches) :

stuff () {
    local now=$(date "+%s") first=$(date -d"$1" "+%s") \
          karmafirst=$(date -d"20110220" "+%s"); shift 1
    echo $now $first $karmafirst $*
}

stuff $@ | awk '{ days = ($1-$2)/84600
                  postrate = $4/days
                  print "Interventions/jour: " postrate
                  if ($2 < $3) {
                      posts = (($1-$3)/84600)*postrate
                      print "Karma/intervention (ext.) : " $5/posts
                  } else {
                      print "Karma/intervention : " $5/$4
                  }}'

Qui nous donne :

./trollfrmystat2 20021212 5880 22622
Interventions/jour: 1.36321
Karma/intervention (ext.) : 13.1946

Dans ce cas, effectivement le second chiffre n'est pertinent (dans les limites de la foi qu'on place dans le karma) que pour les comptes ouverts après.