raphj a écrit 1448 commentaires

Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.

Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.

Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.

Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.

Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).

Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.

Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.

Merci, c'est commité !

XDG_DOCUMENTS_DIR n'est pas définie chez moi donc j'ai ajouté un fallback sur ~/Documents quand même si le dossier existe.

Tout ça fait de L un de mes projets avec la plus grande proportion de code contribué xD.

Pour moi non plus xD

C'est juste un vieux script qui traine à la base.

Merci, c'est commité ! J'ai retiré le dollar en trop, et tant qu'à faire le point virgule que j'avais laissé là pour aucune raison valable. J'ajoute cette substitution dans ma boite à outils shell pour le futur. Je ne pensais pas avoir une contribution aussi vite après une annonce caché dans un commentaire sur un script sans grande importance xD.

Pourquoi avoir nommé le fichier de configuration Ljournalrc plutôt que Lrc ? Je ne me souviens plus, mais je vois trois raisons qui me pousseraient à reprendre la même décision aujourd'hui :

• Clarté : Lrc dans la listes des fichiers dans .config serait potentiellement cryptique. C'est beaucoup plus facile de percuter avec Ljournalrc.

• Éviter les clashs : si tout le monde appelle son petit script avec une lettre, ça va vite devenir la foire.

• Nom du « projet » : J'avais peut-être, pour ces deux raisons, pensé le nom du projet comme Ljournal plutôt que simplement L, mais opté pour L pour le nom du script. Aujourd'hui, j'appellerais peut-être plutôt le script Ljournal et suggérerais aux gens de mettre en place un lien ou un alias nommé L. Et c'est peut-être ce que je ferai si jamais un jour je m'embête à mettre en place un processus d'installation. Pour l'instant, cette responsabilité repose sur la personne qui va réutiliser mon code.

En général oui. Sinon, je commence avec la première ligne et je complète en ouvrant l'éditeur, donc c'est toujours daté. Il est également possible de prendre en note l'entrée standard : Je lance L - et je tape ou je colle plusieurs lignes et CTRL+D pour finir la note. L e permet ensuite de corriger des choses si besoin. L + et L + - permettent aussi de compléter la dernière note.

Rien n'empêcherait d'enregistrer ces notes dans un système plus complexes que ce bête fichier texte :-)

C'est une bonne amélioration, surtout la dernière version. Ça simplifie le code mais ça fait mieux :-)

Je peux faire un commit avec le bon auteur si tu me donnes le nom et l'email à utiliser.

Oups, corrigé, merci :-)

Je vis pas mal dans le terminal et je suis brouillon. J'ai parfois besoin de noter un truc en vitesse sans friction pour être sûr de ne pas le perdre, pour finalement souvent ne jamais y retourner, mais au moins c'est consigné xD

Du coup, j'ai un petit script écrit en plus ou moins une fois (vous savez, ces hacks qui deviennent définitifs ?) que j'utilise depuis des années (y compris quand j'étais à Algoo :-)).

Son utilisation est simple : dans le terminal, je tape L, puis ce que je veux noter.

L une note

Ça ajoute une entrée dans un fichier texte synchronisé avec Nextcloud, avec la date.

On peut consulter le journal en tapant L. Ça ouvre le fichier avec less (ou autre outil configurable), et comme les notes les plus récentes sont en haut du journal, c'est plutôt pratique.

Une entrée :

Fri, 23 Feb 2024 22:09:36 +0100:

        Une note

Et on peut appeler l'éditeur de texte de son choix sur le journal avec L e.

L'aide de l'outil :

Usage:
    L           - show the content of the journal
    L message   - add message to the journal, with a date
    L + message - add message to the previous entry in the journal
    L -         - add stdin to the journal
    L + -       - add stdin to the journal, without a date
    L e         - edit the journal manually
    L h, L -h  - show this help

Config file is in /home/raph/.config/Ljournalrc

Ça supporte les étiquettes de la manière la plus débile possible : il suffit d'ajouter "l'étiquette" à la ligne de cette manière : [tag], et une recherche dans le fichier la retrouvera.

Je l'ai mis en ligne pour l'occasion : https://git.jakse.fr/raph/L/src/branch/main/L

Bien sûr, personne ne l'utilisera, parce que chacun a sa manière de prendre ses petites notes, voire de réinventer son outil. Sinon il y a les gens organisés qui écrivent des notes markdown et qui parfois même font des liens entre les notes. Moi, ça m'explose le cerveau xD.

J'ai abandonné l'idée d'utiliser un outil plus complexe que L depuis longtemps. Il faut que l'outil soit discret et immédiat (aucun lag possible, ça peut tuer une pensée. Ça a tendance à marcher sur les smartphones que je peux utiliser aussi (avec Termux sous Android, ou de manière native sur un mobile Linux). C'est extrêmement user-friendly… pour moi. Finalement, ça fait le taf et c'est rentré dans mes habitudes. Je pourrais améliorer ça un peu et respecter un peu la syntaxe Markdown maintenant que Nextcloud prend ça en charge nativement.

Et sinon, pour les gens qui utilisent un shell avec une gestion sensée de l'historique (comme zsh), un petit # avec la note dans la suite marche aussi. C'est un commentaire en shell et ça reste dans l'historique, et ça ne nécessite aucune installation. Mais gare aux historiques corrompus, ça a pu m'arriver de temps en temps.

En tout cas j'espère que vous aurez du succès avec cette nouvelle fonctionnalité de Tracim :-) C'est une bonne idée, et c'est plutôt malin.

Je ne saurai parler pour cette entreprise, mais je pense que la question de GitLab n’est pas par rapport à Confluence mais plutôt par rapport à BitBucket et éventuellement Jira (si ça ne fait que des tickets et Epic liés aux codes.)

Ah oui :-)

Il y a aussi OpenProject comme alternative à Jira, en général les gens ont des utilisations complexes de Jira pour lesquelles GitLab peut être un peu léger.

On utilise malheureusement beaucoup Jira, on utilise déjà GitLab pour l'hébergement des projets clients et pour certaines choses pour lesquelles on utilisait Jira, et on est en train d'évaluer OpenProject pour d'autres usages.

Sauf si XWiki fait aussi forge Git

Au secours xD non, je ne parlais que de Confluence.

Rester sur Confluence, ça permet de garder le contenu et de ne pas reformer tout le monde à un nouvel outil. C'est un choix naturel.

Mais les nouveaux tarifs et les changements de conditions liées à l'auto-hébergement ne conviennent pas à tout le monde. Beaucoup d'organismes migrent en ce moment vers XWiki et je travaille en ce moment à quasi plein temps sur ces migrations, notamment et en particulier sur les outils de migrations et sur l'accompagnement des clients sur l'aspect migration. Je me retrouve soudainement expert du format d'export Confluence malgré moi. Ou plutôt, comme écrirait le collègue qui a le plus travaillé sur ce code, "format" (avec les guillemets).

Si ta boite venait à revenir sur sa décision de passer au cloud d'Atlassian, c'est une solution possible, libre et auto hébergeable. On accompagne ces migrations au besoin. C'est surtout nécessaire pour la migration de gros wikis. Et on peut former les gens.

Je peine à imaginer une migration vers GitLab ou Gitea, c'est tellement différent… Oui, il y a une fonction de wiki sur ces outils, mais c'est beaucoup plus léger. J'imagine bien commencer une base de connaissances from scratch avec ça, surtout si c'est déjà en place, mais vous utilisez Confluence et ça fait tellement plus. Une migration vers GitLab ne peut probablement fonctionner sans perdre du contenu que si vous avez une utilisation ultra basique de Confluence sans trop utiliser de macros, le système de permissions, etc. Et aussi, si vous avez des outils pour transférer le contenu vers ces plateformes. Migrer vers XWiki, ça ne marche pas trop mal parce que :

• la plupart des fonctionnalités et des concepts de Confluence ont leur équivalent dans XWiki (contenus, espaces, commentaires, pièces jointes, macros, formatage du texte, tags, utilisateurs, groupes, permissions… tout ne mappe pas parfaitement mais il y a déjà de quoi faire)
• on peut convertir la syntaxe Confluence vers celle d'XWiki sans trop de perte et qu'on peut réimplémenter beaucoup de leurs macros (même plus tard après la migration) pour retrouver la plupart des fonctionnalités.

Dans tous les cas, je ne peux qu'espérer pour ta boite qu'elle fera le choix de récupérer le contrôle de sa base de connaissance (avis perso : idéalement libre, idéalement hébergé chez vous), peut importe l'outil.

Je fais un peu de pub, difficile de résister, c'est pile dans mon quotidien du moment :-)

https://linuxfr.org/users/glandos/journaux/jpeg-xl-ne-fait-pas-consensus-au-sein-de-l-union-des-vendeurs-de-navigateurs#comment-1950239

Ouais, mais derrière un drapeau expérimental (pas activé par défaut). Ça n'encourage pas l'adoption. C'est presque comme si l'accès au pont était barré, pour reprendre la comparaison évoquée par un autre commentaire.

les hommes en ont mare des histoire de femmes

C'est quoi des histoires de femmes ?

il y a beaucoup de femmes qui se revendiquent "masculine" et d'homme "feminin"

Ah bon ?

une femme très "virile"

C'est quoi ?

Oui, c'est vrai. Entre autres il y a eu un peu de "comme les mecs n'étaient pas dispo parce que partis en guerre, on a accepté que les nanas sortent de leur foyer pour que le pays ne s'écroule pas complètement".

J'imagine aussi que ça peut être des questions de coûts de maintenance.

Je n'ai jamais vu de JPEG-XL sur le web

Peut-être parce que ça n'est pas pris en charge sur Chrome et Firefox justement, parce que sinon, vu de loin avec un œil distrait, c'est plutôt séduisant, je me pencherais probablement sur la question perso.

Tu fais des raisonnements circulaires et des appels à la nature.

Tes utilisations de "c'est évident que", "il est indéniable que" sont un témoin criant que ta démonstration est fragile.

On observe des différences et des tendances notables entre des catégories de gens : les femmes et les hommes. Maintenant, tout le travail consiste à savoir pourquoi. (et encore, je n'aborde pas la question des trans, non-binaires, intersexes et plus généralement des personnes pour qui sexe ≠ genre ou qui ne se reconnaissent pas dans la catégorie "femme" ni dans la catégorie "homme").

Ta thèse c'est : "pour des raisons biologiques". La thèse que tu réfutes (implicitement ?) c'est : "à cause de biais causés par des constructions sociales".

Observer les différences ne suffit pas à appuyer ta thèse et à réfuter l'autre. Il va donc falloir sortir de l'intuitif, qui est un mode de pensée très pratique qui permet de prendre des raccourcis, d'aller vite, d'être efficace et qui marche plutôt bien mais pas toujours, et enclencher un mode de réflexion plus posé, construit, rigoureux et scientifique. Ton commentaire démontre aussi un manque de documentation sur le sujet. Autrement dit, no offense mais tu raisonnes sans savoir donc on est plus sur le domaine de la croyance.

elle n'ont pas les mêmes goût que les hommes (En général, pas toutes/tous) et cela suffit à expliquer la différence dans nos sociétés occidentale

Non, parce que tu n'as pas expliqué ces différences de goût.

ou la discrimination sexuelle est extrêmement limité dans le domaine de l'éducation

C'est malheureusement faux. À cause de mécanismes parfois très subtiles du style les profs ont plus tendance à poser des questions ouvertes aux mecs et des questions oui/non aux nanas sans même le vouloir. On attend d'un mec qu'il soit plus créatif et on tolère plus qu'il soit pénible et dissipé, et on attend plus d'une nana qu'elle soit sage et disciplinée. Ça explique aussi en partie les meilleurs notes des filles à l'école. On pousse plus les nanas à faire des études littéraires ou sociales que scientifiques pour aucune bonne raison.

Il y a tellement de cas ou les femmes montrent plus d'attrait pour le contact humain, pour le mignon et les hommes pour la technique et la force/violence que je ne comprends pas que ce soit négligé voir nié.

Mais pourquoi ? C'est tout l'enjeu. N'est-ce pas parce qu'on apprend (plus ou moins volontairement) aux petits garçons qu'il faut être fort et aux petites filles qu'il faut être attentifs aux autres, tendre, etc dès le plus jeune âge ? Que ce soit les parents, la société, etc ? Aka construction sociale ? On habille les filles en rose et les garçons en bleu. Sûrement, ça n'a rien à voir avec des choix et des goûts quand on est bébé, on n'a pas encore la carte de crédit pour aller s'acheter nos vêtements nous-même à cet âge ni même les capacités communicationnelles pour exprimer ses préférences sur la question. Non, la société fait sans arrêt des choix genrés pour nous. Ces différences de couleurs qu'on nous impose tout petit est un seul aspect discriminatoire, très évident, parmi les nombreux présents dans la société, variés et parfois subtiles. Ou alors, comment expliques-tu ce genre de différences ?

Par ailleurs, comment expliques-tu que l'informatique, début-milieu 20ème siècle était plutôt mixte, voire majoritairement féminine ? (les personnes qui ont travaillé sur l'ENIAC par exemple, plein de femmes là dedans !). Et pourquoi ça a changé maintenant ?

Peut-être qu'il y a des différences biologiques qui expliquent certaines choses. Peut-être qu'elles expliquent des rapports de domination et des chaines de réactions sociales qui mènent à ces différences qu'on observe dans la société qui n'ont rien avoir avec des différences fondamentales qui causent des appétences différentes. Ou peut-être pas.

On ne peut pas balayer ces problèmes de discriminations et d'inégalités sous le tapis de l'explication biologique et naturelle. Ce tapis est peut-être confortable pour une partie de la population, mais c'est probablement un peu beaucoup une illusion, ou bien existant mais beaucoup plus fin que prévu.

Et dans tous les cas, on a bien un soucis d'égalité à régler, à commencer par les revenus.

Oui, tu as la pile d'appel. Elle est stockée dans la stack, à laquelle le débogueur a accès.

Un (hardware) watchpoint devrait se comporter exactement comme un breakpoint, l'exécution du programme est stoppée par une interruption, à ceci près qu'aucune instruction n'est remplacée par un truc du genre int 3, le processeur prévient l'OS qu'un accès en lecture ou en écriture a eu lieu sur la case mémoire demandée. Et l'OS prévient le débogueur.

Je n'utilise pas trop les watchpoints de gdb, je devrais, surtout qu'il y a un support hardware

Yep, de vieille mémoire il y a 4 registres dédiés à ça sur x86_64, donc on peut surveiller jusqu'à 4 variables en hardware. Au delà, c'est affreusement lent par contre.

Grammalecte est top pour ce genre de chose, je recommande et c'est spécialisé pour la tâche :-)

Il y a une extension pour les navigateurs. Ça garantie de garder ton style d'écriture.

https://grammalecte.net/

Faut bien remplir le reste du sac à dos bien trop vide sinon :-)

Sans surprise, c'est la raison qui est donnée par l'article : par défaut, stdout a un tampon. Les caractères ne sont envoyés que lorsqu'un caractère nouvelle ligne est trouvé (ou à partir d'un certain nombre max de caractère je suppose). C'est plus efficace. Ça regroupe.

Écrire dans un fichier, c'est un syscall. Écrire caractère par caractère, c'est un syscall par caractère, et ça, c'est lent.

Mais mais mais, ce n'est probablement pas souhaitable pour stderr, parce qu'on veut que les erreurs soient affichées sans attendre. Et aussi, normalement on n'affiche pas des tartines dans stderr, juste des messages d'erreurs, donc il n'y a pas vraiment besoin d'optimiser ça.

Sinon l'article a l'air intéressant, là je mentionne la raison mais l'article semble être une excellente trace écrite d'une belle investigation avec une explication de plein de choses en profondeur. Ne vous arrêtez pas à ce commentaire.

Ça tombe un peu à pic, je viens justement de rendre un processus qui était CPU-bound IO-bound et trois fois plus rapide juste en rendant une lecture de fichier bufferisée (et ce serait probablement plus que trois fois s'il n'y avait pas d'autres sources de lenteurs). Précédemment la lecture se faisait octet par octet, et ça, c'est mortel. Je me suis pour l'occasion formé au profiling d'application Java et je recommande chaudement async-profiler qui donne de beaux flame graphs qui, très important, contiennent aussi la partie système de l'exécution. Vous pourrez trouver les miens ici.

C'est un correctif de quelques caractères mais qui a demandé des heures d'investigations, et qui va avoir un sérieux impact aussi. Comme quoi, compter les lignes de codes pour évaluer les choses, ce n'est pas toujours la panacée, s'il y avait encore un doute à ce sujet…

c'est peut-être ça l'astuce

Ouaip. Il y a moyen que ça puisse marcher comme ça.

Je n'ai jamais suffisamment creusé comment ça marche côté WordPress, j'avais toujours supposé que le code des extensions payantes est en fait libre mais que soit :

• l'extension dépend d'un service qui nécessite une sorte de clé qu'on a en payant

• une partie (premium) du code est gardé à coup de if (licence valide) { ... }

Chez XWiki, on vend des extensions libres avec cette dernière méthode. Les gens pourraient venir chercher le code source, retirer la gestion de la licence, compiler et installer l'extension manuellement eux-mêmes, mais en fait c'est tellement plus simple de juste cliquer et payer + avoir un peu de support que les boites font juste ça. Et c'est plus facile à justifier auprès de la compta qu'un don pour les entreprises conscientes qu'un code, même libre, ça ne se développe pas tout seul.

Attention : sur le plan juridique, par défaut le client n'est pas propriétaire de la propriété intellectuelle du code même si c'est lui qui paie. Il faut une clause explicite de session de droit d'auteur pour cela

Ah yes, les règles sont peut-être différentes sans cette clause, peut-être que tu te retrouves effectivement à distribuer au sens de la GPL dans ce cas.

À noter que la GPL impose la licence du logiciel qui en dépend

Tout a fait. Je persiste cependant à penser que la FAQ de Drupal est solide et elle dit "service providers can use GPL code together with GPL-incompatible code for a client, but cannot redistribute that code to the public.", et donc ça n'importe finalement pas tellement.

Également, il me semble qu'un code propriétaire qui dépendrait exclusivement d'un code GPL ne peut pas être diffusé, c'est la raison de l'apparition de la LGPL (tu peux t'appuyer sur une brique libre et la modifier mais tes modifs de cette brique doivent être diffusées)

Absolument.

Félicitations pour le partage et je te souhaite plein de fun, peut-être à base de contributions extérieures :-)

Pour une certaine raison, GitHub est perdu pour déterminer la licence de ton projet, je n'ai cependant que très peu d'expérience en la matière pour aider sur la question.

Maintenant, comme dit dans un autre commentaire, dans le contexte de ce projet, ce n'est pas un sujet car l'outil est sous GPL mais c'est le résultat qu'on diffuse (et le résultat est sous la licence que l'on souhaite)

On est d'accord :-)
Malgré tout le sujet plus généralement me parait important, peut-être encore plus pour toi que pour moi.

si le client souhaite que tu lui fournisses les sources, tu es obligé.

Oui. Mais ce n'est pas une distribution au sens de la GPL. C'est une utilisation interne. C'est plus clair en se plaçant du point de vue du client.

Supposons que tu aies un besoin qui dépend d'un code GPL :

• tu bricoles une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.
• tu paies un prestataire pour bricoler une solution que tu gardes pour toi. Pas de distribution, tu fais ce que tu veux.

En tant que prestataire, tu es un agent du client, tu n'es pas un éditeur de logiciel qui distribue un logiciel. C'est en fait la freedom 1 qui s'applique, pas la freedom 3.

C'est justement pour moi la force principale du logiciel libre : tu as un outil libre à ta disposition mais tu as un besoin un peu spécifique ou le monde a un peu changé : tu peux l'adapter pour tes besoins perso sans conditions (autres que la loi). Tu peux le faire toi même, ou, plus probablement, si tu n'en as pas les compétences ou les moyens, payer quelqu'un pour le faire. Dans ce cas, il n'y a pas de distribution au sens de la GPL et personne ne te force à distribuer ton code. Autrement dit : La GPL force un auteur de logiciel à distribuer le code sous copyleft à son utilisateur. Mais dans le cas d'une prestation, le client est "auteur" (au sens où il a les droits patrimoniaux sur le code, puisqu'il a payé la prestation) ET utilisateur. Le prestataire n'est qu'un "détail d'implémentation" (no offense). Il a écrit le code, mais pour le compte du client.

C'est d'ailleurs pour ça que le projet GNU et la plupart des distributions Linux ne considèrent pas la licence du compilateur du bios de virtualbox comme libre (la licence Sybase) :

https://www.gnu.org/licenses/license-list.html#Watcom

This is not a free software license. It requires you to publish the source code publicly whenever you “Deploy” the covered software, and “Deploy” is defined to include many kinds of private use.

Tu n'as pas le droit de modifier ce code et l'utiliser en privé (dans trop de cas) sans le redistribuer, ce qui est trop restrictif.

Ça fait de la GPL une licence en réalité très raisonnable, même (et surtout) pour l'éditeur de logiciel ou le prestataire : on peut réutiliser son travail, mais il a la garantie de bénéficier des modifications de quelqu'un qui distribuerait le logiciel largement (caveat pour les situations à la red hat).

Alors que pour du code MIT, une telle garantie n'existe pas. En revanche, tu n'attireras pas les contributions de quelqu'un qui voudrais fermer ton code pour le distribuer à des utilisateurs finaux mais qui serait enclin à contribuer upstream puisqu'il ne pourrait pas utiliser ton code GPL pour ça.

C'est évidemment une histoire de compromis et je comprendrais très bien quelqu'un qui choisisse MIT dans l'espoir que plus de contributions arrivent, ou parce qu'il fait du business sur ce code et veut quand même des contributions externes. Il faut bien garder en tête que ça peut se retourner contre soi sévèrement. L'alternative serait GPL + CLA, mais c'est beaucoup moins accepté que contribuer à un projet sous MIT (certainement parce que d'un coup, la boite est la seule à pouvoir fermer le code comme bon lui semble, alors qu'en MIT, tout le monde peut le faire - c'est précisément le cas où je vois quelqu'un choisir une licence permissive pour des raisons philosophiques, et c'est probablement la position des projets *BSD).

D'autres cas méritent une licence permissive, comme les codecs. Tu veux que ton format se diffuse le plus largement possible, tant mis s'il atterrit dans un logiciel propriétaire : au moins, il y a un peu d’interopérabilité et une adoption du format.