rogo a écrit 282 commentaires

Pour ceux qui voudraient essayer Warzone2100, attention. J'ai voulu y rejouer un peu cet été pour voir ce qui avait changé, et j'en suis ressorti très frustré par des problèmes techniques.

Il y a quelques années, j'avais fini la campagne de wz2100 avec plaisir. Je réinstalle donc le paquet Debian, et je finis quelques missions de la campagne Beta. Tout va bien, mais pas de changement notable. Le pathfinding des unités est même pire que dans mes souvenirs. Mais quand j'ai voulu recharger une sauvegarde toute fraîche, plantage. Après pas mal d'essai, j'abandonne et je compile le jeu directement à partir du dépôt Git. Mais au bout de quelques heures de jeu, même problème, mes sauvegardes sont inutilisables.

Il semblerait que la cause du bug soit le passage de la version 3.1 à 3.2, avec la réécriture de l'AI en JS. C'est en tout cas ce qu'avançait ce ticket Debian. J'avais aussi déniché dans les forums de wz2100 un ticket de bug, mais impossible de retrouver le lien: leur Trac ne permet de chercher que par texte, sans pouvoir filtrer par l'état du ticket. Or je n'ai plus le message d'erreur exact sous la main. En plus leur site refuse l'indexation par Google.

Je n'avais pas la motivation pour m'attaquer à des bugs signalés et persistants depuis des années, donc j'ai préféré tout effacer de mon disque dur.

J'imagine que les campagnes de wz2100 sont peu utilisées et peu testées. En tout cas, si après quelques heures de campagne vous devez recommencer à zéro, vous aurez été prévenus.

Beaucoup d'affirmations fausses…

Tes problèmes de performances sont liés au fait que tu as énormément de message.

J'en doute, et quand bien même ce serait le cas, un fonctionnement dégradé non-signalé n'est pas acceptable. Thunderbird devrait me prévenir qu'il ne peut pas gérer avec fluidité une inbox de plusieurs milliers de messages.

Par ailleurs, tout est souvent lent. Quand je tapais un message, j'avais parfois un mot d'avance sur l'affichage. Pourquoi ma composition locale serait ralentie par mon volume de messages IMAP ? Même en filaire sur Renater, Thunderbird était peu réactif par rapport à Claws-mail (qui peut lui aussi geler, hélas).

La comparaison avec les web mail est complètement débile.

Je n'en ai pas faite.

il doit tout de même télécharger au moins les entêtes de tes milliers de messages : il en a besoin par exemple quand tu veux trier tes messages

Thunderbird était configuré pour stocker localement les messages ("cache" sur SSD). Donc le réseau n'est pas nécessaire pour trier.

Le protocole IMAP ne prevoit pas de fonction de recherche

Ah bon ? Wikipedia IMAP et la RFC 3501 seraient donc faux ?

Mais si tu as interrompu brutalement le processus de chargement (ou de suppression de messages etc) en tuant TB, faut pas t'étonner

C'est gentil pour Thunderbird de faire des hypothèses pour expliquer ses problèmes, mais il ne faut pas trop extrapoler. Je n'ai jamais interrompu le chargement des messages. Comme je l'ai écrit, la seule fois où j'ai tué le processus, c'était quand Thunderbird a planté sur la suppression d'un ensemble de messages dans un sous-dossier.

En plus, j'avais mis ThB sur plusieurs de mes machines, donc je ne vois pas comment ce plantage localisé sur l'une aurait pu tout perturber ailleurs.

La recherche aussi n'est pas si terrible que ça.

La recherche ? Quelle recherche ? Il y a 3 mécanismes indépendants, sans aucune passerelle entre les trois.

La recherche globale m'a semblé trop coûteuse en indexation au regard de sa piètre pertinence.

Le filtrage des messages est utile, mais extrêmement limité. Il manque un mode avec un mini-langage pour utilisateur averti, genre "f bernard & s patate" (*f*rom et *s*ubject).

La recherche avancée est tellement bien cachée que je soupçonne qu'une majorité d'utilisateurs ignore son existence. Elle est puissante, mais avec une interface extrêmement lourde.

C'est ce que j'ai fait pour les messages qui était archivés :
- installé l'extension ImportExportTools dans ThB ;
- cd ~/Mail_OLD/subdir && rename 's/$/.eml/' * ;
- ajouté ce répertoire aux répertoires locaux de ThB ;
- déplacé les répertoires ou les fichiers par glissé-déposé dans ThB.

Ça fonctionne, mais ma remarque initiale portait sur le partage des répertoires de mail entre plusieurs applications, sans conversion. Par exemple, j'indexe les dossiers Maildir de Claws-mail avec notmuch pour pouvoir faire des recherches très complexes de temps à autre.

Comme je l'écrivais en préambule, je n'avais pas cherché à évaluer Thunderbird en général, juste à voir ce qui gênait mon usage. Et il y aurait bien plus à dire pour comparer avec des webmails. De mémoire, ce qui m'a semblé mieux que dans Claws-mail (celui que j'utilise finalement, lui aussi libre et diffusé sous Debian) :

• La configuration des serveurs est bien simplifiée en cas d'hébergeur standard.
• Plus généralement, ThB est bien plus accessible à des néophytes que Claws-mail. Le fonctionnement de base avec la configuration par défaut peut suffire à bien des usagers.
• L'affichage des mails reçus en HTML est fourni et satisfaisant (et bien sûr, on peut exclure les fichiers distants).
• Le système d'étiquettes (labels) semble bien fait. On peut facilement filtrer les messages selon leurs étiquettes. Un bémol : il est plus difficile de trouver les messages sans étiquette dans un répertoire.
• L'intégration avec un calendrier existe, bien qu'imparfaite.
• Quelques extensions utiles, même si l'écosystème semble moribond et grevé par des soucis de compatibilité.
• Quelques détails de configuration sont bien pensés, comme le placement de la signature par rapport à la citation, etc.

Il y a bien sûr d'autres différences, par exemple la possibilité de rédiger en HTML, mais je n'en ai pas l'utilité.

Pour la recherche avancée, si bien sûr qu'elle existe: clique droit sur un dossier / compte dans la liste de gauche "Rechercher dans les messages" ou Edition > Rechercher > Rechercher dans le courrier ou Ctrl-Shift-F

Au temps pour moi, je ne l'avais pas vue. À ma décharge, je n'avais pas imaginé que l'entrée de menu "Rechercher dans les messages" était différente de la zone de saisie "Rechercher" en haut de page.

En voyant les résultats d'une recherche normale, pour lesquels on peut ajouter des facettes pour la transformer en recherche multi-critères, je n'avais pas non plus imaginé qu'il existait une autre recherche multi-critères dans ThB, sans passerelle entre les deux.

Par ailleurs, je soupçonne un bug supplémentaire : l'entrée "Recherche" du menu principal est grisée dans la plupart des cas, suivant le répertoire sélectionné. Je ne comprends d'ailleurs pas sur quel critère : j'ai trois adresses chez un même fournisseur, et deux d'entre elles désactivent ce menu de recherche.

pour le reste, tu n'a pas marqué (ou je n'ai pas vu) d'où vient ton build de thunderbird et quelle en est la version.

Thunderbird ESR 52.6.0 de Debian (1 stable + 1 testing).

C'était dans mon laïus, mais noyé dans le passage sur le ticket de bug.

C'est justement le genre d'info que j'aurais aimé lire avant ma tentative de passage à ThB. J'aurais désactivé le cache lors de la création des comptes.

J'ai plusieurs milliers de messages dans certaines inbox. Pendant l'initialisation dans ThB, j'ai parfois eu des sueurs froides (il ne me listait aucun message dans des répertoires où je venais de déplacer des messages), mais j'en ai été quitte pour quelques redémarrages de ThB, pas besoin d'aller piocher dans les sauvegardes. Bref, pour ma part, aucun problème de fiabilité.

Je ne sais pas pourquoi ton journal est mal noté ; peut-être parce qu'il ne s'agit pas vraiment d'un journal

Merci de prendre ma défense ! À vrai dire peu m'importe cette note, je ne sais même pas pourquoi j'ai posté ce compte-rendu.

Et désolé si je n'ai pas respecté l'usage. Pourtant, comme c'était mon premier envoi de journal, je suis allé lire le wiki de linuxfr qui les décrit comme des blogs personnels, sans indication sur le contenu attendu.

il est raisonnable de ne pas parier à long terme sur les clients lourds

Loin de moi toute promotion du webmail. J'envisageais simplement de passer de Claws-mail + POP3 à Thunderbird + IMAP. Finalement, ce sera Claws+IMAP.

Pour les problèmes critiques de performance, c'était sûrement spécifique au fait que c'était une migration. Thunderbird récupérait des gigaoctets de messages. Le problème était que j'avais l'impression qu'il avait fini cette récupération initiale, mais il ramait. Ça c'est calmé par la suite, peut-être aussi parce que j'ai désactivé la recherche globale.

Mais pour la lenteur générale, ça me semble flagrant. Avec le focus dans la liste des messages, quand j'appuie sur une flèche la fenêtre inférieure clignote et met une demi-seconde à m'afficher le contenu du message nouvellement sélectionné. Dans Claws-mail ou mutt, c'est visuellement immédiat.

Pour la recherche, je veux bien m'adapter à une méthode "très difficile", mais si elle ne filtre pas efficacement les messages, à quoi bon ? J'ai listé mes trois besoins fréquents : exclure un terme, chercher un terme exact, et appliquer des critères sur plusieurs champs (par exemple le sujet contient X et l'expéditeur contient Y).

Il ne suffisait pas de « bien paramétrer ces logiciels » pour échapper à cette extension. La boulette est en totalité du côté de Mozilla. L'utilisateur n'est pas en faute dans cette histoire, quelle que soit sa configuration.

Pour les logiciels libres, je les autorise habituellement à collecter des données anonymes et à pratiquer des expériences mineures sur mon instance. C'est exactement ce qu'est censé activer le réglage « Shield studies » de Firefox :

Les « Shield studies » sont des études qui portent sur la protection de la vie privée et vous permettent d'expérimenter différentes fonctionnalités et idées avant qu'elles ne soient disponibles pour toutes celles et ceux qui utilisent Firefox. Grâce à vos retours d'expérience, nous pouvons prendre des décisions plus en phase avec ce dont vous avez réellement besoin.

https://support.mozilla.org/fr/kb/envoi-donnees-techniques-et-interaction-par-firefox-vers-mozilla

Dans l'affaire Looking Glass, Mozilla a utilisé ce canal d'études et d'expériences pour mener une opération commerciale.

Par ailleurs, de nombreux témoignages, parfois accompagnées de vidéos probantes, montrent que le réglage qui désactive les « shield studies » est parfois réactivé, sans action du l'utilisateur, simplement en accédant à la page des extensions.

Le bilan de ces derniers jours est dramatique pour un Firefox qui était déjà dans une situation inquiétante :

• Mozilla monte une opération commerciale en détournant des fonctionnalités non-commerciales de Firefox. Ils font participer à leur insu des utilisateurs qui n'ont jamais donné leur accord pour une activité promotionnelle. C'est une grave faute éthique.
• L'extension est installée à l'insu des utilisateurs, et sa présentation fait croire à du malware. C'est une faute idiote, comment a-t-elle pu passer en production ?
• L'affaire fait apparemment ressortir des bugs logiciels dans la gestion des réglages de la vie privée dans Firefox. C'est pourtant un sujet où il cherche à être en pointe.
• Pas de réaction officielle pendant 4 jours, laissant libre cours aux rumeurs et aux exagérations (immense activité sur Reddit, HackerNews, etc). À ma connaissance, il n'y a que deux commentaires officieux (sur HN et Gizmodo) de responsables, chacun affirmant que ce n'est pas bien grave et que l'opération est arrêtée, et que tout le monde chez Mozilla est trop occupé pour faire plus que cela.

Le manque de professionnalisme et d'éthique de Mozilla dans cette histoire est sidérant. Je comprends que certains de leurs salariés enragent publiquement. Ma confiance en Mozilla est sous la ligne de flottaison.

A ma connaissance, mysql ne propose pas d'outils de (vrai) backup autre que mysqldump qui reprend le principe du fichier qui est différent à chaque lancement.

Oracle propose un tel outil pour MySQL, mais il faut payer. Heureusement, Percona diffuse en logiciel libre son excellent XtraBackup avec toutes les fonctionnalités souhaitées (apt install percona-xtrabackup sous Debian).

Urbackup n'est bien sur pas seul dans son genre, et j'aurais apprécié une comparaison, même succinte, avec des concurrents.

Selon ma faible expérience du domaine, on trouve en logiciel libre quelques solutions traditionnelles, soient complètes et lourdes comme BackupPC et Amanda, soient plus simples et limitées comme rsnapshot (à base de rsync). Il y a aussi des nouveaux venus, le plus connu étant bup qui déduplique et stocke au format Git. bup est par nature en CLI, mais peut être complété par des interfaces graphiques.

Si je comprends bien le message dans ce retour d'expérience : avec Arch, vous allez en baver pour obtenir un système présentable, voire utilisable, mais c'est pédagogique !

Je suis d'accord sur le principe que d'en baver longtemps aide à l'apprentissage. Mais combien abandonnent en cours de route ? J'ai toujours été réticent face à ceux qui recommandaient Slackware ou LFS pour mieux apprendre l'environnement Linux. Il me semble qu'on peut partir d'un cadre déjà confortable (Fedora, Debian, etc) et bricoler dedans. Je supposais qu'Arch proposait aussi ce cadre, et je suis étonné qu'il faille mettre les mains dans le cambouis pour obtenir un simple mode graphique.

Dans mon cas, ma Debian a pour session graphique lxdm suivi d'xmonad, avec roxterm comme terminal (sans transparence). Il est très facile d'essayer plein d'interfaces ; je suis passé par KDE, Gnome et XFCE, avant d'essayer les WM expérimentaux où Xmonad fut mon coup de cœur. Pour que l'hibernation fonctionne, j'ai remplacé Nouveau par le module nvidia, compilé automatiquement par Debian sur mon noyau perso. Un démon DNS local me sert de cache et de filtre anti-pub partiel. J'utilise des conteneurs nspawn, des déclarations "maison" de services, des règles udev sur mesure, des CSS pour personnaliser GTK3… Bref, si on veut bidouiller, n'importe quelle installation de Linux est suffisante pour remplir une vie.

La question sur le contenu des paquets était posée en amont parce que la dépêche en faisait une description incohérente — si j'étais de mauvais poil, j'aurais ajouté « et publicitaire. » Le sujet doit être un peu honteux puisque la réponse est implicite : les paquets minimaux de ArchLinux contiennent bien tous les fichiers de développement, même s'ils sont superflus pour beaucoup d'utilisateurs. Je trouve même amusant qu'on justifie qu'il est plus « serein » de supprimer le choix d'installation alors que la distribution vise un public très pointu.

Quant au second argument sur la simplicité accrue de la gestion des paquets avec Arch parce que c'est une rolling release, ça me semble totalement hors-sujet. Ma machine principale est une Debian testing, mise à jour au file de l'eau. Je n'ai aucun souvenir d'une quelconque difficulté dans ma gestion des paquets depuis des années. J'ai même l'assurance qu'une mise à jour ne cassera pas les applications qui n'auraient pas encore adopté la nouvelle ABI d'une biblio.

J'ai de la sympathie pour ArchLinux, mais les discours d'adorateurs m'énervent. Les choix d'Arch se justifient, mais il ne faut pas pousser les inconvénients sous le tapis en jurant que tout est parfait et mieux qu'ailleurs.

Digression, Mais ce n'est pas moi qui ai commencé ! Et le vendredi c'est permis !

les clins d'œil (les clins d'œils? les clins de z-yeux? les clins d'yeux? «Il a fait deux clins d'œil» vs «Ils se sont fait des clins d'yeux»? Le mec qui a écrit les specs du français était vraiment bourré).

Je ne sais quel est l'usage moderne, mais ma référence personnelle reste l'excellent dictionnaire de M. Littré. Je le cite donc :

Au plur. Des clins d'œil, mais on peut dire aussi, si l'on considère les deux yeux, des clins d'yeux.
A prix de faux clins d'yeux et d'élans affectés, [Molière, Tartuffe. I, 6]

Très correct pour des specs élaborées au fil du temps, sans planification. L'alcool a sûrement joué un rôle¹ dans l'évolution de la langue française, mais peut-être pas plus que dans l'évolution d'autres langages naturels² comme PHP ;-)

A priori, le jeu sera distribué sous les 2 noms "lugaru" et "openlugaru" puisque le premier est déjà un alias du second chez Debian :

% apt-cache search 'lugaru$'
openlugaru - third-person rabbit action game
lugaru - transitional dummy package

Il ne reste qu'à trouver un gentil parrain pour remplacer le paquet actuellement distribué par Debian. Parce que le "lugaru" de Debian est en stable et vieux de presque 6 ans :

% apt-cache policy lugaru
lugaru:
Installed: (none)
Candidate: 0~20110520.1+hge4354+dfsg-4.1
Version table:
0~20110520.1+hge4354+dfsg-4.1 600
600 http://ftp.debian.org stable/contrib amd64 Packages


Un système d'init c'est assez bidon, il en existe au moins une dizaine c'est une bonne preuve que ce n'est pas d'une difficulté incroyable à créer.

Certes, un sustème d'init minimaliste est plutôt simple, mais dans ce cas on est obligé de le compléter par une panoplie d'outils très hétérogènes, chacun apportant sa complexité à un édifice baroque. Je révère la musique baroque, mais côté logiciel, ce n'est pas ma tasse de thé.

Par exemple, au démarrage on veut lancer certains démons, mais avec un mécanisme pour les relancer s'ils s'arrêtent (et gérer intelligemment s'ils plantent systématiquement au redémarrage). Impossible avec un sysvinit de base. Il faut par exemple aller chercher Monit. Sauf que certains démons n'écrivent pas leur PID dans un fichier et pratiquent des forks à tout va, et ça Monit ne gère pas. Donc il faut aller voir du côté de runit, etc.

Idem quand on veut démarrer un service uniquement quand un socket ou un port est lu (inetd), quand on veut paralléliser (startpar), ordonnancer (insserv), gérer les changements matériels comme les conexions USB (hotplug, udev)…

Ma vision des choses, à prendre avec autant de pincettes que les "potins" que tu cites :

• Ruby est lent, c'est notable même par rapport à d'autres langages interprétés comme PHP7. Mais Python3 n'est pas un foudre de guerre non plus.
• Un framework MVC avec ORM ralentit forcément par rapport à du code sur mesure. Rails est lourd, mais Django (Python) ou Symfony (PHP) sont du même ordre.
• Ruby, comme beaucoup d'autres langages, date d'avant l'explosion des processeurs multi-core, et la nature du langage ne permet pas de parallélisation facile, d'où une programmation concurrente médiocre.

Mais, puisque l'accent est sur la performance :

• Tout ceci est focalisé sur la performance, alors que ce n'est pas forcément crucial pour le projet concerné.
• Pour un site web, si la quasi-totalité des pages peut se mettre en cache (cache global ou partiel de la page), alors tous les frameworks sont pertinents.
• On peut optimiser au cas par cas les pages critiques, notamment en contournant l'ORM avec du SQL natif.
• Il vaut mieux choisir un langage de base et un framework que l'on maîtrise, adapté au projet, quitte à l'interfacer avec un backend écrit dans un langage différent et plus performant. Par exemple, frontend en Rails utilisant des services en Java ou Go, voire déporter du code dans Postgresql.

Et côté programmation fonctionnelle :

• La VM d'Erlang (et donc d'Elixir) est super pour créer des milliers de tâches concurrentes, éventuellement distribuées sur plusieurs serveurs. Reste à savoir si c'est adapté au projet.
• Un langage peut être fonctionnel, mais difficilement compatible avec la programmation concurrente, comme OCaml (pour cause de GIL et parce que les fonctions impures ne sont pas explicites).
• Certains langages fonctionnels privilégient une concurrence explicite (Erlang) d'autres implicite (Haskell).
• De ce que je vois, Elixir est faiblement typé. Pour un projet où la fiabilité est critique, les langages fonctionnels de type ML (OCaml, Haskell) apportent la fiabilité de leur typage.
• Il faut bien sur tenir compte des écosystèmes (bibliothèques, déploiement, communauté, professionnels, etc).

Bref, rien d'original, il faut voir en fonction du projet quel sont les outils les plus adaptés, et se focaliser sur les critères essentiels de l'application. Le passage à l'échelle n'est pas forcément important.

Je suis étonné que tant de gens trouvent ça normal. En tant que barbu linuxien, j'aurais préféré un lien explicite vers le tar.gz (j'aime savoir ce que je télécharge et sourtout pouvoir faire un wget), accompagné de quelques lignes détaillant le contenu de l'archive.

Pour un non-barbu, c'est moche. Je suis parfois prosélyte en installant Linux chez des amis ou proches, et je peux imaginer certains voulant essayer la dernière version de Firefox que ne leur propose pas leur système de base. Après la page web clinquante, le site les laisse tomber, et ils bloqueraient sûrement à la phase suivante. Même si ça ne concerne qu'une petite part des téléchargements, ce n'est pas pro, et bien des logiciels libres sans finance font mieux.

A mon avis, ce téléchargement est donc inadapté pour les linuxiens, quelque soit leur profil.

Sur l'aspect plus anecdotique et plus technique de l'archive, je supposais que des deux principaux exécutables, l'un était un wrapper de l'autre, par exemple pour y greffer les autres exécutables comme "crashreporter" et "updater". Il semble que non, les fichiers "firefox*" sont quasi identiques malgré des tailles différentes. Et "run-mozilla.sh" est apparemment un résidu depuis longtemps obsolète. Même pour un utilisateur averti, des explications seraient utiles pour ne pas avoir à deviner par soi-même.

J'ai voulu voir comment Firefox distribuait ses exécutables sous Linux. C'est par pure curiosité, parce que je me suis échiné récemment à construire un paquet AppImage et que j'ai lu en partie la doc de FlatPack.

Je cherche "firefox" dans DuckDuckGo, ce qui m'amène sur le site mozilla avec une grande image d'une rivière qui brille au soleil levant comme à l'ombre, et un bouton "Free Download". Je clique, et j'arrive sur une 504 de CloudFlare. Idem 2 minutes plus tard.

Quand je finis par télécharger le fichier, je me retrouve avec un tar.gz nu. Aucune instruction à l'écran, pas même un lien vers une doc.

J'extrais les fichiers, et je me retrouve avec 23 exécutables, dont tous les ".so". Pas de readme ni de documentation dans quelque format que ce soit. Les candidats plus sérieux à l'exécution sont "firefox", "firefox-bin" et "run-mozilla.sh", mais je suis censé deviner lequel lancer ?

Deux remarques sans rapport :

1. La configuration de Ctrl-Tab a simplement été ajoutée à l'interface graphique, puisqu'elle existait déjà via about:config.
2. Quel dommage que about:performance n'existe que pour les développeurs ! Quand mon Firefox pompe 30% d'un CPU, je ne sais pas quel onglet est fautif, à moins que ce soit une extension comme TreeStyleTabs.

Je suis désolé d'endosser un rôle de rabat-joie, mais j'ai détesté la forme de cette dépêche. La description affichée sur la liste des dépêches ne décrivait pas clairement son sujet. Trois paragraphes de contexte, avec tout juste une vague piste pour deviner le principe de ces "Chatons". La vraie description n'arrive qu'après, en seconde page.

Si je n'avais pas voulu signaler ce défaut, je n'aurais jamais lu la suite de la dépêche. Quand un article est flou ou mal construit, je me dis généralement que sa lecture n'en vaut pas la peine.

Merci pour ces précisions. Je n'insiste pas, parce que remplacer du code Python par du code TeX, je reconnais que c'est un peu pervers.

Tu mentionnes au passage qu'il y a tout de même un fichier tex prêt à l'emploi. À mon avis, ça devrait être apparent dès le README principal, ou au moins dans le readme de compilation.

Sur ma machine moyenne (SSD, proc AMD, Debian testing) la préparation du PDF complet prend 2 minutes et 10 secondes de temps effectif, à 100 % sur un CPU. Dans mon cas, il manquait une dépendance ("SIunits.sty" du paquet Debian "texlive-science") en plus de la dépendance interne "exocorr.sty". Et en passant outre les protestations de BibTeX (30 erreurs, et beaucoup d'avertissements), j'obtiens un beau pdf de 3667 pages !

wget https://raw.githubusercontent.com/LaurentClaessens/exocorr/master/exocorr.sty
tlmgr install SIunits
latexmk -pdf -silent -f mazhe.tex

Maintenant que je peux compiler le PDF, il me reste maintenant à proposer des corrections plus intéressantes que les coquilles dans les README !

Je comprends mieux le rôle de pytex que le readme de compilation décrivait peu, mais je reste dubitatif sur son intérêt. Moi aussi, j'ai écrit une surcouche à latex, notamment pour faire du prétraitement du source tex et analyser les aux produits, mais j'en suis revenu pour passer aux outils existant. Et sur chaque point que tu avances, le gain par rapport à du LaTeX vanilla me semble maigre.

Pour la compilation partielle, certes en quittant pytex on perdrait le découpage fin, mais chaque chapitre aurait ses .aux et compagnie, et le temps de re-compilation serait nettement accéléré.

Pour ton booléen changé à la volée, est-ce que \IfFileExists{security.png}{... ne suffirait pas ?

Pour la position relative des références, ça pourrait être indépendant de la compilation, comme les tests unitaires ou fonctionnels d'un code source. Et donc facultatif pour les contributeurs. En plus, ça peut se faire en TeX pur, dixit texstackexchange.

Pour intégrer des données Git dans le source LaTeX, le package gitinfo est là pour ça. Et tu peux même le charger en facultatif, pour qu'on puisse compiler sans git ni ce package.

Pour le comportement différent si on compile en Frido ou non, il me semble qu'il suffirait de compiler des fichiers différents : un frido.tex ou un everything.tex, chacun définissant quelques macros avant d'inclure un fichier main.tex commun.

À mon avis, tout ça rendrait le projet plus simple d'accès et de maintenance, et faciliterait aussi les changements de structure. Mais je reconnais que la migration demanderait du travail, sans aucun gain immédiat sur les PDF produits.

Il ne faut pas confondre domaine public et propriété de l'État. Et même dans le cas où le droit d'exploitation est « cédé de plein droit à l'État » l'auteur initial garde son droit moral.

Voici le texte de loi du Code de la propriété intellectuelle sur ce sujet.

L'ambiguïté repose sur « Dans la mesure strictement nécessaire à l'accomplissement d'une mission de service public […] une oeuvre créée par un agent de l'Etat dans l'exercice de ses fonctions ». Si l'enseignant déclare qu'il a rédigé un document pendant son temps libre, en complément du cours normal fait pour son travail, comment prouver le contraire ?

Noter que les travaux de recherche sont exclus de ce mécanisme, comme l'indique la dernière phrase de cet article de loi.

Tout d'abord, merci pour cette contribution libre. J'ai encore assez de souvenirs de maths pour pour en relire une bonne partie, et proposer des corrections. J'ai ouvert le chapitre 3 "Anneaux" et repéré plusieurs erreurs mineures dès la première page (un mot oublié, un signe oublié, des parenthèses mal dimensionnées). La preuve par récursion en page suivante est correcte, mais j'y ajouterais un commentaire pour justifier la double initialisation. Tout ceci pourrait être proposé via des pull requests, sauf que…

L'organisation du dépôt et sa compilation me refroidissent. 4428 fichiers à plat et en vrac — plus un répertoire avec du C++ et le .o correspondant. Pour compiler en PDF, il faut copier des fichiers venant d'autres dépôts, y compris du code Python qui se chargera de lancer pdflatex. C'est assez rebutant.

Je n'ai pas compris l'intérêt de cet outil maison pytex par rapport aux outils distribués dans une distribution LaTeX standard, par exemple latexmk. Ce dernier gère aussi les passages multiples et signale les erreurs. Quant au refus d'utiliser les include de LaTeX, c'est refuser la compilation partielle. Je prône une structure avec un répertoire par chapitre, inséré par include, lequel se composerait de différents fichiers TeX, insérés par input. Il est alors très simple de faire une compilation partielle avec includeonly, même sans toucher aux sources ; par exemple avec pdflatex "\def\foo{bar}\input{filename}" (la macro foo étant ensuite inséré dans le includeonly) ou avec un IfFileExists{local.tex}{\input{local.tex}}{} pour avoir un fichier facultatif, non versionné, de personnalisation.

Si tu es intéressé par ce changement de structure et d'outil, je veux bien en discuter et éventuellement le réaliser.

Actuellement, et comme dans la plupart des applications à onglets, Ctrl-PageUp et Ctrl-PageDown permettent de passer à l'onglet qui est placé avant, respectivement après, l'onglet courant. Dans un terminal moderne (Konsole, VTE/gnome), c'est le raccourci par défaut.

Dans Firefox, au moins sous Linux, le comportement de Ctrl-Tab dépend de la configuration dans about:config. Sur mes machines, j'active browser.ctrlTab.previews et le raccourci permet alors de basculer sur l'onglet consulté précédemment. Autrement dit, le futur comportement que promet la dépêche est déjà celui de mon FF, sans extension.

Attention, ce paramètre n'est pas documenté, ni dans FF ni dans la Knowledge Base de Mozilla. Donc aucune garantie sur son fonctionnement au fil des versions. Et comme souvent, le nom du paramètre n'a aucun rapport avec son action.

Au passage, la page about:config de Firefox est vraiment désastreuse : on se retrouve avec plein de paramètres dont seule la lecture du code source de Firefox permet de comprendre le rôle. Certains réglages sont d'ailleurs totalement inactifs. Je me demande pourquoi on n'impose pas aux développeurs de fournir ne serait-ce qu'une phrase de description.