Posté par barmic 🦦 le 27 août 2022 à 23:39. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
J'ai tendance à penser que les contraintes logicielles ne devraient pas tant interférer avec la forme rédactionnelle.
Oui mais c'est un peu le problème avec les couplages, tu peux totalement les ignorer et passer à côté. La RFC821 qui crée smtp a 40 ans ce mois ci. On a plus de recul.
Il est certainement possible de faire des choses au niveau de la couche de présentation pour qu'il n'y ait pas de limite tangible à la longueur de ligne et que l'utilisateur ne soit pas gêné par les choix de longueurs de ligne des autres utilisateurs.
Tout à fait ça demande d'avoir un encodage entre ce qui est affiché et ce qui passe sur le réseau, par exemple tu encode en base64. HTML peux être vu comme une forme d'encodage dans ce contexte. Aux débuts d'internet on pensait que les protocoles en mode texte était géniaux car très facile à debuger. En effet tu peux directement lire ce qui passe sur le réseau. Dans les faits c'est une très mauvaise idée en particulier quand tu passe des données utilisateur. Actuellement de moins en moins de protocoles n'ont plus l'avantage d'être lisibles car ils transitent sur du TLS tout en gardant les inconvénients du mode texte (le contenu transmis impact le protocole et il passe en base64 s'il y a conflit entre le contenu et le fonctionnement du protocole ce qui augmente le volume a envoyer).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par barmic 🦦 le 27 août 2022 à 20:56. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  -1.
Défendre le « peux-tu regarder ? » contre le « tu peux me faire une synthèse » (ou autre besoin/intention explicite) c’est défendre un ordre social qui exige que l’autre doive connaître les intentions sans les exprimer, ce qui à un certain niveau peut même relever d’une forme d’abus : 1. l’exigence peut-être démesurément élevée, 2. l’investissement pour y satisfaire (ou s’en approcher) peut être démesurément élevé.
Blablabla
C'est complètement HS et il était question de gestion de l'historique des mails. Personne n'a défendu une formulation particulière.
Posté par barmic 🦦 le 27 août 2022 à 11:54. En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  4.
Ta référence montre bien que ça n'est pas spécialement français comme problème.
Posté par barmic 🦦 le 27 août 2022 à 11:52. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  -1.
Pas nécessairement si ça arrive peu fréquemment tu t'en fou.
Posté par barmic 🦦 le 27 août 2022 à 11:52. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  3.
Alors pour moi c'est pas une question d'incompétence générale mais sur la question qu'il pose. Si je t'envoie un message pour te demander quelque chose, c'est généralement parce que je te considère comme plus compétent que moi sur le sujet, sinon je répondrai moi même à la question. Note que ça marche même à compétence égale en fait, si j'ai un avis et que je te demande le tiens d'une part je ne sais pas complètement sur quoi se base ton avis donc je ne sais pas forcément quoi enlever et quoi garder, mais en plus si je le fais je vais inclure mon biais dans ta prise de décision.
Posté par barmic 🦦 le 27 août 2022 à 10:00. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  0.
On peut te demander ton avis sur une idée qui a été proposée dans la discussion, on peut te demander de rajouter des infos inconnues des participants, etc.
C'est exactement pareil. Le demandeur n'est probablement pas à même de déterminer ce qui est l'information pertinente ou non pour que tu donne ton avis.
Quand bien même on n’en aurait rien à faire de la politesse, c’est aussi une question d’efficacité.
La personne qui va faire passe et quasiment systématiquement moins compétente sur le sujet, lui demander d'ajouter un travail amène facilement une détérioration de l'information. Prendre un mauvais choix ou devoir repartir à la pêche aux informations n'est pas plus efficace. Si la personne est aussi compétente que toi, alors c'est par manque de temps qu'elle ne répond pas elle même au mail donc lui demander de prendre du temps en plus ne marche pas bien.
(Et même dans le cas où on demande une synthèse, ça n’interdit pas de le demander clairement : « Tu peux me faire une synthèse de cette discussion pour la réunion de demain ? », au lieu encore une fois de laisser le destinataire deviner ce qu’on attend de lui.)
Mais ça n'a rien à voir avec la manière dont tu gère l'historique de la conversation.
Posté par barmic 🦦 le 27 août 2022 à 00:49. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  10.
Comme dit ted la RFC5322 pose une limite à 998 caractères en consultant de se limiter à 78.
78 parce que au doigt mouillé ils ont trouvé que ça marchait bien avec la plupart des MUA (en octobre 2008)
le paragraphe qui parle de ça dans RFC5322
la partie qui parle de ça dans la RFC5321 mais c'était présent dès la première RFC sur le sujet la 821 de 1982
Tu remarquera que les RFC elles-mêmes utilisent cette convention, mais comment sont écrites les RFC ? Je veux dire, la RFC 821 qui décrit le mail. Les 820 premières RFC n'ont pas été envoyées par mail.
Elles étaient tapées à la machine à écrire et les machines à écrire ont longtemps eu des limitations à 80 caractères. 78 c'est 80 moins CR LF.
Tout n'est pas complètement figé car depuis 2019, ils publient les RFC en text (toujours en 78 colonnes faudrait pas trop brusquer), html, pdf et xml (un exemple).
Posté par barmic 🦦 le 27 août 2022 à 00:01. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  5.
le mail qui contient juste "peux-tu regarder ?"
Ce genre de mail consiste justement à extraire et détailler l'information utile. Si celui qui te donne la tâche le fait à ta place, il n'a pas besoin de toi. Il peut aussi faire des erreurs de transcription, penser qu'un point n'est pas pertinent alors que si, etc
Posté par barmic 🦦 le 26 août 2022 à 23:41. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  4.
Si je prends le dernier mail envoyé par un humain à l'heure où j'écris sur la LKML.
https://lkml.org/lkml/2022/8/26/1221
Si mon dispositif d'affichage est configuré pour avoir des lignes plus petites que le nombre de caractères de large que ce qu'il a utilisé, j'aurais un saut de ligne là où je mis attend et en cours de route systématiquement. Et c'est ça la pratique la plus rependu avec cet usage text plain. C'est pour ça que j'en ai fais un exemple dans mon premier message.
Posté par barmic 🦦 le 26 août 2022 à 22:47. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  7.
VoilĂ pour ce que j'ai en tĂŞte, mais on doit pouvoir en trouver d'autres.
Posté par barmic 🦦 le 26 août 2022 à 20:51. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Non parce que tu ne peux pas déterminer ce qui est un retour à la ligne qu'il faut garder (pour garder du sens) ou pas.
Posté par barmic 🦦 le 26 août 2022 à 20:50. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Je suis pas sûr de comprendre. Tu as plus de contrôle avec HTML. C'est pour ça que l'epub c'est bien.
Posté par barmic 🦦 le 26 août 2022 à 16:50. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  4.
Va de 5 en 5Â ;)
Posté par barmic 🦦 le 26 août 2022 à 16:03. En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Bof moi je trouve pas. Parce que quand tu laisse l'émetteur choisir la largeur de son texte ça donne souvent des choses assez louches d'avoir ses retours à lui plus ceux de ton logiciel à toi qui ne coïncident pas (parce qu'on a pas tous la même taille d'écran, le même logiciel, etc). C'est aggravé si tu utilise une police avec une taille particulièrement plus grosse que ce que la plèbe a l'habitude de voir.
Posté par barmic 🦦 le 26 août 2022 à 15:19. En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  3.
agile à la française
Avant que certains fassent trop d'amalgame. L'agilité consiste à itérer plutôt que de suivre un long tunnel jusqu'à avoir fini un cahier des charges déterminé à l'avance et potentiellement loin des besoins réels au moment de la livraison. S'ils ont cru être agile, ils ne l'étaient pas.
Je sais pas pourquoi « à la française », pour un exemple récent Cyberpunk c'est 328 millions de $ de budget chez un développeur polonais et c'est au moins tout aussi catastrophique si ce n'est pire.
Posté par barmic 🦦 le 26 août 2022 à 09:48. En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  2.
On fait une lettre ouverte quand on a pas accès facilement à la cible à qui on souhaite parler ou quand on veut bénéficier d'une pression populaire. Aller discuter par mail directement sur les listes de diffusion ou dans les évènements est tout de même largement plus doux comme méthode et n'empêche pas d'acter un désaccord avec une lettre si les discussions n'ont pas abouties.
Posté par barmic 🦦 le 26 août 2022 à 09:34. En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  9.
La migration du centre de données = 7.5 + 2.4 = 10 millions . Il serait intéressant de connaître les gains futurs (économies ?) mais il est clair qu'aller chez Amazon est un choix stratégiquement nul, je ne sais pas comment ce choix a pu être fait alors qu'il y avait déjà une infrastructure fonctionnelle.
J'imagine que c'est pour débaucher une parti du personnel… C'est toujours considéré comme un gain substantiel de hum… grof… « diminuer sa charge salariale ». Quand tu donne 100 € à AWS, tu n'en a pas la moitié qui va pour payer des hôpitaux, l'assurance chômage, les retraites, des routes, des lignes de train… oh wait !
Posté par barmic 🦦 le 26 août 2022 à 06:55. En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  8.
C'est tout à fait possible, c'est juste qu'il faut déposer une plainte. J'ai plus l'intitulé mais c'est un peu comme l'affaire des mutuelles de Bretagne et du ministre il n'y a pas si longtemps.
Mais je suis d'accord que ça devrait être plus automatique. Ce genre de dirigeants sont payés rubis sur ongle et leur plus gros risque c'est de se faire remercier avec un parachute doré.
Posté par barmic 🦦 le 26 août 2022 à 06:48. En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  4. Dernière modification le 26 août 2022 à 06:48.
Ils avaient et ont encore l'Assistant SNCF Ă qui il manquerai uniquement quelques Ă©crans pour payer et annuler son billet.
Quand tu connaît la fin, c'est plus simple de faire les bons choix.
Posté par barmic 🦦 le 24 août 2022 à 07:00. En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  2.
C’est presque digne de l’éternel sujet « pour ou contre systemd » !
Éternel ? systemd n'a que 10 ans ! vi/emacs ou pour ou contre le copyleft c'est déjà autre chose
Posté par barmic 🦦 le 24 août 2022 à 00:02. En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  -5.
Donc il semble qu'on a fait le tour des arguments :
Posté par barmic 🦦 le 23 août 2022 à 23:54. En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à  2.
OK OK je comprends
Posté par barmic 🦦 le 23 août 2022 à 22:19. En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à  5.
Il me semble que tu disais que les développeurs de GPG n'arrivaient pas à supprimer des algos pourtant considérés comme plutôt fragiles à cause de leur communauté qui réclamait de les garder.
Ça ne semble pas être si simple de désactiver un algo (probablement tant qu'il n'est pas complètement percé).
Posté par barmic 🦦 le 23 août 2022 à 22:10. En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  1. Dernière modification le 23 août 2022 à 22:10.
Et gimp plafonne à 4 ou 5 développeurs les jours de pluie il me semble.
Mais je parlais des utilisateurs qui même s'ils ne sont pas nombreux semblent être un peu plus au vu du nombre de téléchargements.
Posté par barmic 🦦 le 23 août 2022 à 22:07. En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  -1.
Alors après tu peux sortir les stats que tu veux, je m'en balance.
Vraiment si je prend le temps de chercher des chiffres c'est pour chercher l'impact de cette division. À part vos ressenti, ça paraît très limité.
De 2 choses l'une :
AOO est tout petit à côté de LO, mais sa taille actuelle est encore usurpée à mes yeux.
Tu accepte que le projet existe ou chaque utilisateur d'AOP est un utilisateur de trop qu'il faut ramener dans le droit chemin ?
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Oui mais c'est un peu le problème avec les couplages, tu peux totalement les ignorer et passer à côté. La RFC821 qui crée smtp a 40 ans ce mois ci. On a plus de recul.
Tout à fait ça demande d'avoir un encodage entre ce qui est affiché et ce qui passe sur le réseau, par exemple tu encode en base64. HTML peux être vu comme une forme d'encodage dans ce contexte. Aux débuts d'internet on pensait que les protocoles en mode texte était géniaux car très facile à debuger. En effet tu peux directement lire ce qui passe sur le réseau. Dans les faits c'est une très mauvaise idée en particulier quand tu passe des données utilisateur. Actuellement de moins en moins de protocoles n'ont plus l'avantage d'être lisibles car ils transitent sur du TLS tout en gardant les inconvénients du mode texte (le contenu transmis impact le protocole et il passe en base64 s'il y a conflit entre le contenu et le fonctionnement du protocole ce qui augmente le volume a envoyer).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  -1.
Blablabla
C'est complètement HS et il était question de gestion de l'historique des mails. Personne n'a défendu une formulation particulière.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 50 M€
Posté par barmic 🦦 . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  4.
Ta référence montre bien que ça n'est pas spécialement français comme problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  -1.
Pas nécessairement si ça arrive peu fréquemment tu t'en fou.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  3.
Alors pour moi c'est pas une question d'incompétence générale mais sur la question qu'il pose. Si je t'envoie un message pour te demander quelque chose, c'est généralement parce que je te considère comme plus compétent que moi sur le sujet, sinon je répondrai moi même à la question. Note que ça marche même à compétence égale en fait, si j'ai un avis et que je te demande le tiens d'une part je ne sais pas complètement sur quoi se base ton avis donc je ne sais pas forcément quoi enlever et quoi garder, mais en plus si je le fais je vais inclure mon biais dans ta prise de décision.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  0.
C'est exactement pareil. Le demandeur n'est probablement pas à même de déterminer ce qui est l'information pertinente ou non pour que tu donne ton avis.
La personne qui va faire passe et quasiment systématiquement moins compétente sur le sujet, lui demander d'ajouter un travail amène facilement une détérioration de l'information. Prendre un mauvais choix ou devoir repartir à la pêche aux informations n'est pas plus efficace. Si la personne est aussi compétente que toi, alors c'est par manque de temps qu'elle ne répond pas elle même au mail donc lui demander de prendre du temps en plus ne marche pas bien.
Mais ça n'a rien à voir avec la manière dont tu gère l'historique de la conversation.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  10.
Comme dit ted la RFC5322 pose une limite à 998 caractères en consultant de se limiter à 78.
78 parce que au doigt mouillé ils ont trouvé que ça marchait bien avec la plupart des MUA (en octobre 2008)
le paragraphe qui parle de ça dans RFC5322
la partie qui parle de ça dans la RFC5321 mais c'était présent dès la première RFC sur le sujet la 821 de 1982
Tu remarquera que les RFC elles-mêmes utilisent cette convention, mais comment sont écrites les RFC ? Je veux dire, la RFC 821 qui décrit le mail. Les 820 premières RFC n'ont pas été envoyées par mail.
Elles étaient tapées à la machine à écrire et les machines à écrire ont longtemps eu des limitations à 80 caractères. 78 c'est 80 moins CR LF.
Tout n'est pas complètement figé car depuis 2019, ils publient les RFC en text (toujours en 78 colonnes faudrait pas trop brusquer), html, pdf et xml (un exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mon avis
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  5.
Ce genre de mail consiste justement à extraire et détailler l'information utile. Si celui qui te donne la tâche le fait à ta place, il n'a pas besoin de toi. Il peut aussi faire des erreurs de transcription, penser qu'un point n'est pas pertinent alors que si, etc
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  4.
Si je prends le dernier mail envoyé par un humain à l'heure où j'écris sur la LKML.
https://lkml.org/lkml/2022/8/26/1221
Si mon dispositif d'affichage est configuré pour avoir des lignes plus petites que le nombre de caractères de large que ce qu'il a utilisé, j'aurais un saut de ligne là où je mis attend et en cours de route systématiquement. Et c'est ça la pratique la plus rependu avec cet usage text plain. C'est pour ça que j'en ai fais un exemple dans mon premier message.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  7.
VoilĂ pour ce que j'ai en tĂŞte, mais on doit pouvoir en trouver d'autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Non parce que tu ne peux pas déterminer ce qui est un retour à la ligne qu'il faut garder (pour garder du sens) ou pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Je suis pas sûr de comprendre. Tu as plus de contrôle avec HTML. C'est pour ça que l'epub c'est bien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  4.
Va de 5 en 5Â ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: vraiment?
Posté par barmic 🦦 . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à  6.
Bof moi je trouve pas. Parce que quand tu laisse l'Ă©metteur choisir la largeur de son texte ça donne souvent des choses assez louches d'avoir ses retours Ă
lui plus ceux de ton logiciel à toi qui ne coïncident pas (parce qu'on a pas tous la même taille d'écran, le même logiciel, etc). C'est aggravé si tu
utilise une police avec une taille particulièrement plus grosse que ce que la plèbe a l'habitude de voir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 50 M€
Posté par barmic 🦦 . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  3.
Avant que certains fassent trop d'amalgame. L'agilité consiste à itérer plutôt que de suivre un long tunnel jusqu'à avoir fini un cahier des charges déterminé à l'avance et potentiellement loin des besoins réels au moment de la livraison. S'ils ont cru être agile, ils ne l'étaient pas.
Je sais pas pourquoi « à la française », pour un exemple récent Cyberpunk c'est 328 millions de $ de budget chez un développeur polonais et c'est au moins tout aussi catastrophique si ce n'est pire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Lettre ouverte
Posté par barmic 🦦 . En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  2.
On fait une lettre ouverte quand on a pas accès facilement à la cible à qui on souhaite parler ou quand on veut bénéficier d'une pression populaire. Aller discuter par mail directement sur les listes de diffusion ou dans les évènements est tout de même largement plus doux comme méthode et n'empêche pas d'acter un désaccord avec une lettre si les discussions n'ont pas abouties.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: 50 M€
Posté par barmic 🦦 . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  9.
J'imagine que c'est pour débaucher une parti du personnel… C'est toujours considéré comme un gain substantiel de hum… grof… « diminuer sa charge salariale ». Quand tu donne 100 € à AWS, tu n'en a pas la moitié qui va pour payer des hôpitaux, l'assurance chômage, les retraites, des routes, des lignes de train… oh wait !
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Récupération
Posté par barmic 🦦 . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  8.
C'est tout à fait possible, c'est juste qu'il faut déposer une plainte. J'ai plus l'intitulé mais c'est un peu comme l'affaire des mutuelles de Bretagne et du ministre il n'y a pas si longtemps.
Mais je suis d'accord que ça devrait être plus automatique. Ce genre de dirigeants sont payés rubis sur ongle et leur plus gros risque c'est de se faire remercier avec un parachute doré.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Récupération
Posté par barmic 🦦 . En réponse au lien SNCF Connect : le vrai coût d'une application qui bugge (en court 50 millions d'euros). Évalué à  4. Dernière modification le 26 août 2022 à 06:48.
Ils avaient et ont encore l'Assistant SNCF Ă qui il manquerai uniquement quelques Ă©crans pour payer et annuler son billet.
Quand tu connaît la fin, c'est plus simple de faire les bons choix.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: hé bhé !
Posté par barmic 🦦 . En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  2.
Éternel ? systemd n'a que 10 ans ! vi/emacs ou pour ou contre le copyleft c'est déjà autre chose
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aux confins de l'absurdité
Posté par barmic 🦦 . En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  -5.
Donc il semble qu'on a fait le tour des arguments :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une seule suite crypto ?
Posté par barmic 🦦 . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à  2.
OK OK je comprends
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une seule suite crypto ?
Posté par barmic 🦦 . En réponse à la dépêche WireGuard, protocole de communication chiffré sur UDP et logiciel libre. Évalué à  5.
Il me semble que tu disais que les développeurs de GPG n'arrivaient pas à supprimer des algos pourtant considérés comme plutôt fragiles à cause de leur communauté qui réclamait de les garder.
Ça ne semble pas être si simple de désactiver un algo (probablement tant qu'il n'est pas complètement percé).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aux confins de l'absurdité
Posté par barmic 🦦 . En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  1. Dernière modification le 23 août 2022 à 22:10.
Et gimp plafonne à 4 ou 5 développeurs les jours de pluie il me semble.
Mais je parlais des utilisateurs qui même s'ils ne sont pas nombreux semblent être un peu plus au vu du nombre de téléchargements.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aux confins de l'absurdité
Posté par barmic 🦦 . En réponse à la dépêche Apache OpenOffice 4.1.13. Évalué à  -1.
Vraiment si je prend le temps de chercher des chiffres c'est pour chercher l'impact de cette division. À part vos ressenti, ça paraît très limité.
De 2 choses l'une :
Tu accepte que le projet existe ou chaque utilisateur d'AOP est un utilisateur de trop qu'il faut ramener dans le droit chemin ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll