Pareil sur un forum : aucune garantie que les abonnés penseront à se connecter et à lire les messages.
Ça n’est pas mon propos : un mail aussi peut ne jamais être lu, le problème n’est pas là. Le problème, c’est qu’un mail ne peut jamais être reçu, alors que sur un forum, le message posté est posté, point. Il est donc disponible pour tout le monde.
Exactement pareil sur un forum : le nouveau message est peut-être publié tout de suite, mais encore faut-il que les destinataires soient encore connectés et qu'ils pensent à rafraîchir la page de consultation. Sinon ils recevront le message s'ils repassent par là un jour. À moins d'avoir une notification par mail.
Ça n’est pas mon propos : un message posté sur un forum l’est instantanément. Donc, quand tu consultes le forum, tu vois tous les messages ; quand tu réponds, tu réponds toujours au dernier message (les forums bien faits ont un mécanisme pour prévenir des réponses pendant que tu rédigeais la tienne). Rien de tout ça n’est garanti avec les mails.
Si, les archives pour la centralisation. Pour reconstruire l'arbre de discussion, les clients lourds font ça très bien, et l'utilisateur peut, en un clic, choisir de l'activer ou non.
Encore faut-il avoir des archives, et que celles-ci soient découvrables. C’est très loin d’être toujours le cas.
Pour les arbres de discussions recréés par le client lourd, c’est souvent un réglage général à tout le logiciel, et surtout c’est très souvent cassé.
Pareil avec n'importe quel forum
Heu non : à moins d’avoir des CSS custom, toute personne qui consulte un sujet a la même mise en forme. Allez, deux versions, celle mobile et celle desktop. On est plus comme il y a 15 ans où les navigateurs font n’importe quoi avec le CSS.
Euh, on est sur linuxfr là et l'arbre de discussion explose en vol dés 5 réponses, et on ne sait jamais à qui un message répond. Et sur la plupart des forums les réponses sont en vrac à la suite les unes des autres.
Au moins avec une mailing-list, tu as toujours, sauf action explicite du répondant, tout ou partie de la citation du message auquel il est répondu. Sur un forum, c'est la croix et la bannière pour citer le message auquel on répond.
Ça n’est pas mon propos : avec un forum, tout est affiché sur une page, ou dans un sujet paginé. Avec une mailing list, la discussion est souvent explosée en plusieurs sujets, parce que l’arbre n’est pas correctement reconstruit, ou que quelqu’un a trouvé malin de changer le titre du mail en plein milieu.
D’autre part, sur un forum bien fait (… pas linuxfr.org sur ce point…) tu as un bouton « citer ce message ».
Au moins tu peux faire quelque chose et organiser les données chez toi. Toutes les mailing-lists auxquelles je suis abonné, je les reçois et les organise dans une même interface, celle de Thunderbird. Pour les forums, chacun a son interface et il faut les parcourir les uns après les autres. Et bien entendu, pas moyen de faire ça hors-ligne, tout juste lire un résumé si on a un flux RSS.
Oh, un argument valable !
(Je rajoute quand même que la plupart des gens, en tous cas que je connais, ont autre chose à faire que organiser des données à la main ; les interfaces web, ça peut être juste des onglets épinglés dans ton navigateur).
Sur les listes que je modère pour LibreOffice, il m'arrive moins d'une fois par an de devoir faire appel à un administrateur pour désabonner quelqu'un dont l'adresse n'est plus valide.
Sur des mailing list avec beaucoup de non-informaticiens dedans, c’est clairement plus fréquent que ça.
C'est au choix de l'administrateur. Sur Framaliste / Sympa, par défaut la notification de désabonnement est envoyée. Sinon je ne vois pas l'utilité d'envoyer une notification à une adresse qui n'existe plus.
C’est pas forcément un choix conscient.
L'antispam de Thunderbird fait le plus gros du travail.
Tu confonds « lutte contre le spam » et « modération », ce sont deux choses différentes. Pense par exemple à la diffusion d’informations illégales.
À l’usage, je constate deux types de mailing list :
Les mailing list de diffusion, où un nombre très restreint de personnes envoient des informations à beaucoup d’autres (newsletters, informations de sécurité, etc.) avec en général un volume faible.
2. Les mailing list de discussions, où chacun peut répondre à tout le monde, et qui peuvent avoir un volume important.
Le premier cas d’utilisation fonctionne en général assez bien sans trop de souci, si ce n’est qu’il n’y a aucune garantie que les mails envoyés aient été reçus (on sait comment les gros fournisseurs adorent casser des envois sans aucune raison).
Le second cas est, au mieux, un reliquat d’une époque révolue où on avait pas mieux comme outil. Parce que la mailing list est un très mauvais outil de discussion, pour plein de raisons qui ont déjà été évoquées ici :
aucune garantie que les messages arrivent à leurs destinataires,
aucune garantie du temps d’arrivée des messages (même encore aujourd’hui),
aucune centralisation des discussions (charge au client de reconstruire l’arbre de discussions à partir des données et métadonnées,
ce qui implique que les clients les aient transmises correctement et que les utilisateurs aient cité et répondu correctement),
recherche difficile dans l’historique (surtout si on recherche quelque chose qui date d’avant l’abonnement),
mise en forme aléatoire,
arbre de discussion qui peut exploser en vol si le débat devient un peu long,
une mailing list verbeuse impose à l’utilisateur une configuration spécifique à la mailing list sur ses clients mails pour ne pas être noyé sous les messages en vrac (que cette configuration soit simple ou non n’est pas la question : le problème est bien qu’elle soit nécessaire)
nécessite souvent des opérations administrateur pour des opérations triviales (désinscription…)
aucune notification des concernés sur certaines de ces opérations (message de désinscription si celle-ci a été faite par l’administrateur)
la modération est très difficile
et j’en passe.
Il y a parfois une interface web couplée qui permet de s’y retrouver un peu mieux, mais c’est loin d’être systématique ni même utilisable. Par exemple, si je veux trouver quelque chose dans la (très verbeuse) mailing list du noyau Linux, j’ai le choix entre cet outil sur le domaine officiel (bon courage), ou des outils tiers comme https://lkml.org/ (qui utilise Google pour sa recherche interne, ironie, tout ça).
En fait, je ne connais aucune mailing list de discussion, dans toutes celles que j’utilise (pour le libre, pour l’associatif) dont la gestion soit fluide et agréable à utiliser :
Associatif : on a de plus en plus de problèmes de mails qui n’arrivent pas dès que le fournisseur du mail enregistré n’est pas un énorme FAI, Google ou Microsoft.
Associatif encore : on passe notre temps à renvoyer les mêmes mails d’explication d’un lieu de rendez-vous parce que les nouveaux n’ont aucun moyen simple de retrouver l’info dans les mails existants (quand ils savent que c’est possible), et que les anciens ne retrouvent pas le mail déjà envoyé dans la masse de leurs mails existants (quand ils n’ont pas supprimé le message « pour faire des économies d’énergie »).
LinuxFR.org : tout envoi à l’une des mailing list sans y être inscrit (on ne peut pas de toutes façons) nécessite d’envoyer un deuxième mail de confirmation à la main.
Je veux bien croire que Discourse (ou l’instance de Discourse dont il est question ici) soit perfectible en terme d’utilisation et d’ergonomie ; mais pour moi il faudrait que ça soit une catastrophe absolue pour réussir à faire pire qu’une mailing list.
J’ai l’impression que c’est de « l’écologie » à papy : on lance des idées en vrac parce qu’elles ont l’air écologiques, mais sans aucune mesure d’impact. Or, il y a beaucoup de choses pas du tout triviales d’un point de vue écologie en informatique – par exemple, lire une vidéo est moins consommateur en CPU que naviguer sur Internet (surtout sur des sites très chargés en JS), parce que la vidéo est décodée matériellement.
C’est surtout que c’est une preuve de concept, pour laquelle il n’y a pas besoin d’avoir un démonstrateur à l’échelle 1:1.
Les principales questions visées ici étaient :
Est-ce qu’on est capables d’aller percuter un astéroide à haute vitesse ?
Si oui, à quel point l’impact va le faire dévier ? (ça dépend largement le la structure interne des astéroïde, qui est à peu près inconnue aujourd’hui).
L'article a été mis à jour avec des compléments culturels par l'équipe bulgare, l'auteur lui-même est rassuré. Je vous laisse re-cliquer sur le lien pour les détails.
Je suis grand aussi, je comprends parfaitement qu'il y ait besoin que des équipements soient accessibles aux personnes de petite taille ou en fauteuil roulant.
Ce que je trouve dommage, c'est ces cas d'équipements multiples qui sont tous adaptés pour un usage de ce type, et donc sont tous pénibles d'accès pour les grands. Et même inaccessibles pour quelqu'un de grand avec un problème de dos, en réalité. Ça fait partie des cas où en voulant résoudre un problème réel d'accessibilité, on en a créé un nouveau.
Je pense par exemple à ce centre commercial ouù il aurait suffit de mettre les trois distributeurs à des hauteurs différentes.
Ça c’est un coup dur, j’espère qu’ils vont finir par trouver une solution. Parce qu’aujourd’hui, l’absence de décodage matériel sur ces codecs est un vrai handicap pour une utilisation desktop. S’il reste le décodage logiciel, c’est beaucoup moins efficace, surtout sur les contenus en très haute définition.
A-t-on une idée de comment cette décision va devoir être répercutée par d’autres distributions ?
C’est vrai que les réactions ici sont en mode dramatique par rapport au problème réel engendré par les corrections non voulues ici.
Par contre, je me suis aussi retrouvé avec des modifications difficiles à comprendre suite au passage de mes dépêches en modération. Honnêtement c’est des modifications à la marge, mais c’est toujours désagréable de se voir attribuer en son nom un texte qui contient des ajouts avec lequel on est pas d’accord.
Dans les cas auxquels j’ai été confronté, c’était des détails, mais c’est toujours bizarre de se dire « WTF » devant une modification éditoriale. Pour être précis, j’ai eu un cas ou toute l’orthographe post-réforme-1990 a été « corrigée » en vieille orthographe, et l’ajout de l’insert « (en non-libre) » dans cette note de bas de page que je ne m’explique pas.
Le sujet avait déjà été soulevé en commentaires de rédaction de je ne sais plus quelle dépêche, mais ces modifications ne sont pas autorisées par défaut par les licences libres. Celles-ci – en particulier les Creative Commons BY (éventuellement CA), choisies par défaut sur linuxfr.org – autorisent la création d’œuvres dérivées sans prétendre que le dérivé est approuvé par l’auteur d’origine, mais pas les correctifs dans l’œuvre d’origine.
Vient ensuite la problématique de la correction éditoriale, qui est nécessaire ne serait-ce que pour éviter les grosses fautes et la typographie aléatoire. Il faut donc que les éditeurs soient autorisés à corriger les publications :
Soit directement, en ajoutant une précision dans les conditions d’utilisation du site ;
Soit en autorisant les auteurs à mettre le dernier coup de tampon avant publication.
Je ne crois pas que l’exception (1) soit dans les conditions d’utilisation du site.
La gestion telle que (2) correspond à ce qui était fait sur le Site du Zéro et est toujours fait sur Zeste de Savoir. Les éditeurs ne corrigent pas directement le texte, ou bien demandent explicitement l’autorisation à l’auteur de corriger les typo. Et surtout, l’auteur peut relire la version corrigée avant publication s’il le désire. Le principal problème, c’est que ça rallonge le processus de publication, surtout si l’auteur est peu disponible ou peu coopératif. Sur linuxfr.org, c’est encore plus compliqué parce qu’il n’y a aucun système de messagerie privée qui permettrait facilement de discuter de la dépêche en cours d’édition.
Je pense à titre personnel que, dans le cas des dépêches non collaboratives, le processus d’édition gagnerait à être plus transparent. En particulier, toute modification qui n’est pas purement cosmétique mériterait d’être validée par les auteurs concernés, pour éviter de créer des contresens involontaires.
Mon voisin du dessus semble dire que les dépêches collaboratives ne sont pas soumises à édition privée, est-ce bien le cas ? Si oui, ça résoudrait facilement le problème, on pourrait juste dire à la création : « Si vous rédigez une dépêche privée, vous donnez l’autorisation aux éditeurs de faire toutes les corrections nécessaires ; si ça ne vous va pas, faites une dépêche collaborative ou un journal ».
Enfin, si le problème est mineur, pour moi il existe quand même, je trouverais dommage de le nier simplement parce que quelqu’un le désigne de la mauvaise manière.
mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux
Encore une fois, tu inventes un élément et tu réponds à cet élément. Mon propos, c’est qu’on doit bidouiller, pas que « ça ne marche pas ».
Ici, j’ai dû bidouiller parce que mon besoin ne rentrait pas dans les cases prévues : le plugin ne peut s’authentifier qu’à un seul dépôt (et crée un fichier de configuration dédié, donc enchâsser les configurations l’une dans l’autre ne fonctionne pas). Il y bien un plugin qui le permet, mais c’est pas celui qui est installé sur le serveur Jenkins et qu’on utilise pour tout le reste. Et c’est pas un plugin exotique, hein, c’est les standards.
Mais en fait on s’en fout, c’est qu’un exemple. Je ne viens pas ici pour demander comment faire ce truc en particulier.
Alors oui, dans un monde parfait, théorique et tout, je me serais contenté d’utiliser le plugin qui va bien dans Jenkins et tout aurait été parfait, doux et rose. Mais justement, on est pas dans un monde théorique et je dois composer avec des contraintes extérieures. Et c’est précisément là que le bât blesse : trop souvent ces outils de configuration par DSL partent du principe que tu es en Théorie, ne sont pas conçus pour gérer autre chose, et dès que tu t’en éloignes c’est l’enfer.
Et ça n’est pas la peine de venir expliquer qu’il suffit de changer d’outil ou de rentrer dans une configuration « standard » : le problème est précisément quand on ne peut pas faire ce genre de chose, quelle qu’en soit la raison.
Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.
Je ne parle pas de projet sur lesquels on a pas la main mais de cas sur lesquels on a pas la main. C’est plus général que le simple projet, ça implique des règles internes à l’entreprise, etc.
Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence1). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.
C’était un exemple pour te montrer que « n’importe quoi » n’implique pas « vieux projet » ou « technologies pourries », et réciproquement. Et oui, ce truc est débile et impossible à maintenir en l’état.
On gère ça avec une properties dockerRepository qu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.
Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses. D’une part le problème n’est pas l’URL du dépôt mais l’identification ; d’autre part ça concerne Jenkins et pas Docker, donc « une properties » n’est pas une solution utilisable (en tous cas pas de façon simple sans dupliquer une tâche).
Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.
Le problème des « cases » n'est pas « les vieilles technologies ». D'ailleurs le pire pom.xml que j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.
Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.
Le seul truc positif que je retiens : on était obligés de coder en français, et le C# (celui de M$ uniquement ?) autorise les caractères accentués dans les identifiants. Indispensable pour conjuguer et accorder, ce qui n'existe pas (pas totalement) en anglais. D'autres langages permettent ça ?
Note qu’au moins une configuration par langage déclaratif ne te promet pas de pouvoir exécuter du code arbitraire, à effort égal ça force un système mieux documenté et plus complet. Les DSL, eux, se retrouvent avec beaucoup de « solutions » qui sont du type « utilise ce bout de code dégueu qui fait approximativement ce que tu demandes », et le problème d’origine n’est jamais résolu.
Pour le build simple, je suis d’accord en théorie. Sauf qu’on ne bosse pas uniquement sur des projets récents et/ou dont on a maitrisé l’architecture de A à Z. En fait, je pense même que le problème source de ce genre d’outils est précisément là : ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.
Je fais une différence entre « essayer de de pas consommer comme un sac en faisant n’importe quoi » et « la majorité de l’effort sur mon projet concerne les performances ».
Ce que j’appelle « orienté performances », c’est ce deuxième cas, où tu es obligé d’utiliser des langages qui te permettent une gestion fine des ressources sans quoi le résultat est vraiment déraisonnable.
C’est pas du tout mon propos : Java, C#/Mono ou Python sont d’excellents langages dans leurs domaines d’application, surtout dans leurs dernières versions ; et comme dit ci-dessus, ils évoluent assez rapidement.
Non, mon propos, c’est que je suis étonné que l’on puisse proposer ces langages pour remplacer C ou C++.
Je sais par exemple que C# ou Java ont pu remplacer les utilisations les plus « haut niveau » de C++, mais pour moi aucun des langages de la liste n’a jamais été un candidat sérieux au remplacement de C++ pour les projets orienté performance, et encore moins au remplacement de C.
# Choisissez votre EPOCH
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Avis aux lève-tôt : time(NULL) == 1666666666 demain à 04:57:46 UTC+2. Évalué à 2.
Wikipédia recense pas moins de 21 dates d’origine différentes pour des calendriers informatiques (dont au moins deux invalides en tant que dates et une autre basée sur un calendrier qui n’existait pas à cette date). C’est autant d’opportunités d’avoir des nombres-qui-représentent-une-date esthétiques ou rigolos.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Discourse :(
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 7.
Ça n’est pas mon propos : un mail aussi peut ne jamais être lu, le problème n’est pas là. Le problème, c’est qu’un mail ne peut jamais être reçu, alors que sur un forum, le message posté est posté, point. Il est donc disponible pour tout le monde.
Ça n’est pas mon propos : un message posté sur un forum l’est instantanément. Donc, quand tu consultes le forum, tu vois tous les messages ; quand tu réponds, tu réponds toujours au dernier message (les forums bien faits ont un mécanisme pour prévenir des réponses pendant que tu rédigeais la tienne). Rien de tout ça n’est garanti avec les mails.
Encore faut-il avoir des archives, et que celles-ci soient découvrables. C’est très loin d’être toujours le cas.
Pour les arbres de discussions recréés par le client lourd, c’est souvent un réglage général à tout le logiciel, et surtout c’est très souvent cassé.
Heu non : à moins d’avoir des CSS custom, toute personne qui consulte un sujet a la même mise en forme. Allez, deux versions, celle mobile et celle desktop. On est plus comme il y a 15 ans où les navigateurs font n’importe quoi avec le CSS.
Ça n’est pas mon propos : avec un forum, tout est affiché sur une page, ou dans un sujet paginé. Avec une mailing list, la discussion est souvent explosée en plusieurs sujets, parce que l’arbre n’est pas correctement reconstruit, ou que quelqu’un a trouvé malin de changer le titre du mail en plein milieu.
D’autre part, sur un forum bien fait (… pas linuxfr.org sur ce point…) tu as un bouton « citer ce message ».
Oh, un argument valable !
(Je rajoute quand même que la plupart des gens, en tous cas que je connais, ont autre chose à faire que organiser des données à la main ; les interfaces web, ça peut être juste des onglets épinglés dans ton navigateur).
Sur des mailing list avec beaucoup de non-informaticiens dedans, c’est clairement plus fréquent que ça.
C’est pas forcément un choix conscient.
Tu confonds « lutte contre le spam » et « modération », ce sont deux choses différentes. Pense par exemple à la diffusion d’informations illégales.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Discourse :(
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 3. Dernière modification le 24 octobre 2022 à 11:18.
Ah, et j’oubliais : les messages qui disparaissent dans les spams (même si tu l’as signalé plusieurs fois comme n’étant pas du spam).
Et la mailing list qui renvoie des messages en retour qui font se demander si l’envoi est passé, donc dans le doute on renvoie ou on pose la question.
Oui, c’est deux cas qui viennent d’arriver, et c’est pas la première fois, ni la dernière.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Discourse :(
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal La communauté GNOME remplace ses mailing lists par Discourse. Évalué à 10.
À l’usage, je constate deux types de mailing list :
Le premier cas d’utilisation fonctionne en général assez bien sans trop de souci, si ce n’est qu’il n’y a aucune garantie que les mails envoyés aient été reçus (on sait comment les gros fournisseurs adorent casser des envois sans aucune raison).
Le second cas est, au mieux, un reliquat d’une époque révolue où on avait pas mieux comme outil. Parce que la mailing list est un très mauvais outil de discussion, pour plein de raisons qui ont déjà été évoquées ici :
Il y a parfois une interface web couplée qui permet de s’y retrouver un peu mieux, mais c’est loin d’être systématique ni même utilisable. Par exemple, si je veux trouver quelque chose dans la (très verbeuse) mailing list du noyau Linux, j’ai le choix entre cet outil sur le domaine officiel (bon courage), ou des outils tiers comme https://lkml.org/ (qui utilise Google pour sa recherche interne, ironie, tout ça).
En fait, je ne connais aucune mailing list de discussion, dans toutes celles que j’utilise (pour le libre, pour l’associatif) dont la gestion soit fluide et agréable à utiliser :
Je veux bien croire que Discourse (ou l’instance de Discourse dont il est question ici) soit perfectible en terme d’utilisation et d’ergonomie ; mais pour moi il faudrait que ça soit une catastrophe absolue pour réussir à faire pire qu’une mailing list.
La connaissance libre : https://zestedesavoir.com
[^] # Re: oops !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Someone released the FOSS RTS 0 A.D. on Steam without speaking to the developers. Évalué à 3.
À ce sujet, le jeu semble avoir été retiré, et je serais vraiment curieux d'en connaître la raison.
La connaissance libre : https://zestedesavoir.com
# L'étude elle-même
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Render Yourself Invisible To AI With This Adversarial Sweater Of Doom. Évalué à 4.
Le lien vers l'étude elle-même (PDF, 6,37 Mo) : https://arxiv.org/pdf/1910.14667
La connaissance libre : https://zestedesavoir.com
# 7 ans déjà
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Bocker : Docker implemented in around 100 lines of bash [2015]. Évalué à 8.
Je sais, le projet est déjà ancien (2015, n’a pas évolué depuis), mais je trouve le truc intéressant quand même.
La connaissance libre : https://zestedesavoir.com
[^] # Re: En quoi c’est écologique ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 5.
C’est précisément le genre de non-trivialités auxquelles je faisais référence.
La connaissance libre : https://zestedesavoir.com
# En quoi c’est écologique ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 3.
J’ai l’impression que c’est de « l’écologie » à papy : on lance des idées en vrac parce qu’elles ont l’air écologiques, mais sans aucune mesure d’impact. Or, il y a beaucoup de choses pas du tout triviales d’un point de vue écologie en informatique – par exemple, lire une vidéo est moins consommateur en CPU que naviguer sur Internet (surtout sur des sites très chargés en JS), parce que la vidéo est décodée matériellement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Déflexion
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Modification de l'orbite d'un astéroïde par la mission DART en image. Évalué à 6.
C’est surtout que c’est une preuve de concept, pour laquelle il n’y a pas besoin d’avoir un démonstrateur à l’échelle 1:1.
Les principales questions visées ici étaient :
La connaissance libre : https://zestedesavoir.com
[^] # Mise à jour dans l'article
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Pepper&Carrot (heavy) derivation: the case of the succesful Bulgarian book publishing by Prikazka-Ig. Évalué à 5. Dernière modification le 12 octobre 2022 à 15:04.
L'article a été mis à jour avec des compléments culturels par l'équipe bulgare, l'auteur lui-même est rassuré. Je vous laisse re-cliquer sur le lien pour les détails.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Même pour les « valides »
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Captcha, écrans tactiles... : ces technologies qui empoisonnent la vie des déficients visuels. Évalué à 5.
Je suis grand aussi, je comprends parfaitement qu'il y ait besoin que des équipements soient accessibles aux personnes de petite taille ou en fauteuil roulant.
Ce que je trouve dommage, c'est ces cas d'équipements multiples qui sont tous adaptés pour un usage de ce type, et donc sont tous pénibles d'accès pour les grands. Et même inaccessibles pour quelqu'un de grand avec un problème de dos, en réalité. Ça fait partie des cas où en voulant résoudre un problème réel d'accessibilité, on en a créé un nouveau.
Je pense par exemple à ce centre commercial ouù il aurait suffit de mettre les trois distributeurs à des hauteurs différentes.
La connaissance libre : https://zestedesavoir.com
[^] # En passant par USB…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Brother ne mettra pas à jour les micrologiciels des imprimantes qui utilisent TLS 1.0. Évalué à 5.
Il y a toujours la possibilité de mettre à jour le firmware en passant par le port USB. Mais ça nécessite un PC sous Windows ou un Mac, officiellement de désactiver les antivirus et firewall (je suppose qu'en fait c'est pour se prémunir des systèmes trop restrictifs), et surtout ça nécessite d'être sur place.
D'autre part, le dernier firmware de ce modèle date de mars 2018, si l'installation avait été faite à l'époque elle n'aurait posé aucun problème.
La connaissance libre : https://zestedesavoir.com
# Un coup dur pour Linux sur desktop
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Fedora Linux Disabling Mesa's H.264 / H.265 / VC1 VA-API Support Over Legal Concerns - phoronix. Évalué à 5. Dernière modification le 28 septembre 2022 à 11:33.
Ça c’est un coup dur, j’espère qu’ils vont finir par trouver une solution. Parce qu’aujourd’hui, l’absence de décodage matériel sur ces codecs est un vrai handicap pour une utilisation desktop. S’il reste le décodage logiciel, c’est beaucoup moins efficace, surtout sur les contenus en très haute définition.
A-t-on une idée de comment cette décision va devoir être répercutée par d’autres distributions ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Correction
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Pétrolette 1.6. Évalué à 8.
C’est vrai que les réactions ici sont en mode dramatique par rapport au problème réel engendré par les corrections non voulues ici.
Par contre, je me suis aussi retrouvé avec des modifications difficiles à comprendre suite au passage de mes dépêches en modération. Honnêtement c’est des modifications à la marge, mais c’est toujours désagréable de se voir attribuer en son nom un texte qui contient des ajouts avec lequel on est pas d’accord.
Dans les cas auxquels j’ai été confronté, c’était des détails, mais c’est toujours bizarre de se dire « WTF » devant une modification éditoriale. Pour être précis, j’ai eu un cas ou toute l’orthographe post-réforme-1990 a été « corrigée » en vieille orthographe, et l’ajout de l’insert « (en non-libre) » dans cette note de bas de page que je ne m’explique pas.
Le sujet avait déjà été soulevé en commentaires de rédaction de je ne sais plus quelle dépêche, mais ces modifications ne sont pas autorisées par défaut par les licences libres. Celles-ci – en particulier les Creative Commons BY (éventuellement CA), choisies par défaut sur linuxfr.org – autorisent la création d’œuvres dérivées sans prétendre que le dérivé est approuvé par l’auteur d’origine, mais pas les correctifs dans l’œuvre d’origine.
Vient ensuite la problématique de la correction éditoriale, qui est nécessaire ne serait-ce que pour éviter les grosses fautes et la typographie aléatoire. Il faut donc que les éditeurs soient autorisés à corriger les publications :
Je ne crois pas que l’exception (1) soit dans les conditions d’utilisation du site.
La gestion telle que (2) correspond à ce qui était fait sur le Site du Zéro et est toujours fait sur Zeste de Savoir. Les éditeurs ne corrigent pas directement le texte, ou bien demandent explicitement l’autorisation à l’auteur de corriger les typo. Et surtout, l’auteur peut relire la version corrigée avant publication s’il le désire. Le principal problème, c’est que ça rallonge le processus de publication, surtout si l’auteur est peu disponible ou peu coopératif. Sur linuxfr.org, c’est encore plus compliqué parce qu’il n’y a aucun système de messagerie privée qui permettrait facilement de discuter de la dépêche en cours d’édition.
Je pense à titre personnel que, dans le cas des dépêches non collaboratives, le processus d’édition gagnerait à être plus transparent. En particulier, toute modification qui n’est pas purement cosmétique mériterait d’être validée par les auteurs concernés, pour éviter de créer des contresens involontaires.
Mon voisin du dessus semble dire que les dépêches collaboratives ne sont pas soumises à édition privée, est-ce bien le cas ? Si oui, ça résoudrait facilement le problème, on pourrait juste dire à la création : « Si vous rédigez une dépêche privée, vous donnez l’autorisation aux éditeurs de faire toutes les corrections nécessaires ; si ça ne vous va pas, faites une dépêche collaborative ou un journal ».
Enfin, si le problème est mineur, pour moi il existe quand même, je trouverais dommage de le nier simplement parce que quelqu’un le désigne de la mauvaise manière.
La connaissance libre : https://zestedesavoir.com
[^] # Re: en tout trois vidéos
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Le marché de l'électricité (chaîne Heu?reka). Évalué à 2. Dernière modification le 27 septembre 2022 à 00:51.
(doublon)
La connaissance libre : https://zestedesavoir.com
[^] # Re: en tout trois vidéos
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Le marché de l'électricité (chaîne Heu?reka). Évalué à 4.
Une chaîne entière sur ce sujet, en fait. Par un ancien trader.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien La « configuration » par langage dédié (DSL), une invention de Satan. Évalué à 1.
Encore une fois, tu inventes un élément et tu réponds à cet élément. Mon propos, c’est qu’on doit bidouiller, pas que « ça ne marche pas ».
Ici, j’ai dû bidouiller parce que mon besoin ne rentrait pas dans les cases prévues : le plugin ne peut s’authentifier qu’à un seul dépôt (et crée un fichier de configuration dédié, donc enchâsser les configurations l’une dans l’autre ne fonctionne pas). Il y bien un plugin qui le permet, mais c’est pas celui qui est installé sur le serveur Jenkins et qu’on utilise pour tout le reste. Et c’est pas un plugin exotique, hein, c’est les standards.
Mais en fait on s’en fout, c’est qu’un exemple. Je ne viens pas ici pour demander comment faire ce truc en particulier.
Alors oui, dans un monde parfait, théorique et tout, je me serais contenté d’utiliser le plugin qui va bien dans Jenkins et tout aurait été parfait, doux et rose. Mais justement, on est pas dans un monde théorique et je dois composer avec des contraintes extérieures. Et c’est précisément là que le bât blesse : trop souvent ces outils de configuration par DSL partent du principe que tu es en Théorie, ne sont pas conçus pour gérer autre chose, et dès que tu t’en éloignes c’est l’enfer.
Et ça n’est pas la peine de venir expliquer qu’il suffit de changer d’outil ou de rentrer dans une configuration « standard » : le problème est précisément quand on ne peut pas faire ce genre de chose, quelle qu’en soit la raison.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien La « configuration » par langage dédié (DSL), une invention de Satan. Évalué à 3. Dernière modification le 26 septembre 2022 à 14:59.
Je ne parle pas de projet sur lesquels on a pas la main mais de cas sur lesquels on a pas la main. C’est plus général que le simple projet, ça implique des règles internes à l’entreprise, etc.
C’était un exemple pour te montrer que « n’importe quoi » n’implique pas « vieux projet » ou « technologies pourries », et réciproquement. Et oui, ce truc est débile et impossible à maintenir en l’état.
Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses. D’une part le problème n’est pas l’URL du dépôt mais l’identification ; d’autre part ça concerne Jenkins et pas Docker, donc « une properties » n’est pas une solution utilisable (en tous cas pas de façon simple sans dupliquer une tâche).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien La « configuration » par langage dédié (DSL), une invention de Satan. Évalué à 3.
Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.
Le problème des « cases » n'est pas « les vieilles technologies ». D'ailleurs le pire
pom.xmlque j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Les trucs plus anciens
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 7. Dernière modification le 26 septembre 2022 à 12:09.
SQL (au moins PostgreSQL) et la JVM (au moins Java et Kotlin). On peut même utiliser des emojis ! (Ne faites pas ça !)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Bof
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien La « configuration » par langage dédié (DSL), une invention de Satan. Évalué à 2.
Note qu’au moins une configuration par langage déclaratif ne te promet pas de pouvoir exécuter du code arbitraire, à effort égal ça force un système mieux documenté et plus complet. Les DSL, eux, se retrouvent avec beaucoup de « solutions » qui sont du type « utilise ce bout de code dégueu qui fait approximativement ce que tu demandes », et le problème d’origine n’est jamais résolu.
Pour le build simple, je suis d’accord en théorie. Sauf qu’on ne bosse pas uniquement sur des projets récents et/ou dont on a maitrisé l’architecture de A à Z. En fait, je pense même que le problème source de ce genre d’outils est précisément là : ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 5.
Je fais une différence entre « essayer de de pas consommer comme un sac en faisant n’importe quoi » et « la majorité de l’effort sur mon projet concerne les performances ».
Ce que j’appelle « orienté performances », c’est ce deuxième cas, où tu es obligé d’utiliser des langages qui te permettent une gestion fine des ressources sans quoi le résultat est vraiment déraisonnable.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 4.
C’est pas du tout mon propos : Java, C#/Mono ou Python sont d’excellents langages dans leurs domaines d’application, surtout dans leurs dernières versions ; et comme dit ci-dessus, ils évoluent assez rapidement.
Non, mon propos, c’est que je suis étonné que l’on puisse proposer ces langages pour remplacer C ou C++.
Je sais par exemple que C# ou Java ont pu remplacer les utilisations les plus « haut niveau » de C++, mais pour moi aucun des langages de la liste n’a jamais été un candidat sérieux au remplacement de C++ pour les projets orienté performance, et encore moins au remplacement de C.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 5.
Il y a vraiment des gens qui ont conseillé (ou conseillent toujours) d’utiliser Java, C#/Mono ou Python pour remplacer C++ et surtout C ?
Parce que c’est pas les mêmes domaines d’application !
La connaissance libre : https://zestedesavoir.com