Oui, rails a prévu la commande db:setup pour préparer la première fois la base de donnée (ça permet de la monter sans avoir besoin de passer tous les scripts).
Quand tu vois que le Docker mysql est prêt avec un log du genre:
database_1 | 2020-09-21 16:03:12 139820938893312 [Note] mysqld: ready for connections.`
tu peux exécuter la commande suivante:
docker-compose run linuxfr.org bin/rails db:setup
Dans l'idéal, il aurait fallu faire un entrypoint pour le Docker linuxfr.org pour qu'il configure la première fois la base avec db:setup.
Pour bien le faire, il faudrait faire une boucle de sleep qui attend que le Docker mysql soit prêt.
Je préfère ce PR, parce qu'on suit simplement les mises à jour de Rails et parce qu'on n'a pas besoin d'ajouter le paquet shared-mime-info dans les dépendances du projet.
mimemagic est sous license MIT et il incluait un fichier de shared-mime-info qui est sous GPL-2. La mise à jour 0.3.10, n'inclue plus ce fichier et nécessite donc l'installation du projet shared-mime-info pour rester sous license MIT.
Comme j'ai indiqué dans le Pull Request, je ne suis pas sûr de pouvoir mettre à jour la version bundle dans le Gemfile.lock.
Si ce n'est pas possible, j'aurai encore besoin de modifier le Gemfile.lock, mais en attendant, tu peux utiliser ce patch pour réussir à build l’environnement.
Oh, je n'avais pas pensé que l'on pouvait enlever des versions sur rubygems.org…
D'un côté je comprends, les développeurs ne peuvent pas faire le support de toutes les versions, mais d'un autre côté, ce n'est pas très pratique pour pouvoir construire des environnements stables.
Heureusement, je vois sur rubygems que l'on pourrait essayer de passer à la version 0.3.10, en croisant les doigts pour que semver soit bien respecté.
Si jamais, j'ai choisi de faire les images Docker avec Debian Stretch, parce que ça correspond aux serveurs de productions de LinuxFr et parce que je n'avais simplement pas réussi à monter l'environnement avec Buster.
Je n'ai pas assez d'expérience avec les environnements Ruby et Rails pour m'aventurer avec d'autres versions de Debian, mais c'est volontiers si quelqu'un y arrive :)
Ce n'est qu'une question d'habitudes… Attention, elles changent souvent 😂
L'article explique justement qu'Adwaita est maintenant clairement le langage visuel et comportemental de GNOME et, surtout, validé par l'équipe design de GNOME.
De fait, c'est un thème GTK, un set d'icônes et de widgets GTK prêt à l'emploi pour créer une application estampillée GNOME (ou qui cible uniquement la plateforme GNOME).
Le thème Adwaita que tu as connu avant va s'appeler dorénavant "Défaut" dans GTK et sera une copie de l'ancien Adwaita. Il ne suivra plus les préceptes de GNOME et deviendra naturellement compatible multi-plateforme, car GTK ne cible plus aucune plateforme en particulier (Windows, MacOS, Elementary, XFCE…).
La bonne nouvelle de ce changement d'habitude, c'est que GTK pourra enfin mieux fonctionner sur Windows, MacOS, Elementary, XFCE… et ce sans avoir besoin de triturer le thème par défaut ni les widgets par défaut.
Il faut voir Adwaita, comme la marque de GNOME. Avant, GTK 3 était très lié à GNOME et c'est pour ça que Adwaita était directement dans GTK.
Aujourd'hui, GTK n'a plus besoin d'évoluer aussi vite que GNOME, il faut voir ça comme un bon signe: GTK est devenue plus mûre et assagit sa vitesse de développement pour être à nouveau plus stable, générique et multiplateforme :-)
Toutefois, je pense que l'on ne va pas se retrouver bloqué avec de vieux widgets comme à l'époque de GTK+ 2 et GNOME 2: en effet, libadwaita permettra d'expérimenter de nouveaux widgets et, à terme, s'ils sont intéressants pour toutes les plateformes cibles de GTK, de les intégrer dans GTK directement.
J'ai le sentiment que GNOME et GTK ont enfin pu se séparer correctement grâce à GTK 4 et son nouveau paradigme où "tout est un widget" (enfin, si j'ai bien suivi GTK 4, je ne suis pas sûr).
MMhhh, ça sera intéressant à debugger: le problème semble être le mélange de la syntaxe Markdown pour les liens [super lien](http://localhost) et les liens wikipédias custom de LinuxFr [[article wikipédia.]]. En effet l'exemple [[article wikipédia]] (avec des explications) contient les 2 syntaxes imbriquées.
Pour info, la source Markdown des exemples donnés dans le poste orignal:
- **texte original :** métadonnées GeoTIFF (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
- **wikilien ajouté :** métadonnées [[GeoTIFF]] (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
- **contournement :** métadonnées [[GeoTIFF]] _(informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF)_ ;
Je ne suis pas sûr que ça sera facile à corriger, car il faudrait modifier l'interpréteur Markdown.
Par contre, un autre exemple de contournement, ça serait de faire tout en Markdown:
- **contournement markdown uniquement :** métadonnées [GeoTIFF](https://fr.wikipedia.org/wiki/GeoTIFF) (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
contournement markdown uniquement : métadonnées GeoTIFF (informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF) ;
On perd la fonction "wikipedia", mais on évite de devoir mettre le texte en italique après.
Tout le monde n’est pas heureux du retour de Richard Stallman.
J’ai lu l'article de Sam Hartmann (Chef du projet Debian en 2019), où il explique qu’il aurait dû parler avant des comportements désagréables de Richard Stallman et que c’est de sa responsabilité d’en parler.
J’y ai aussi appris qu’il n’est pas le seul à trouver intolérable que le comité de la FSF ait accepté le retour de Richard Stallman. Une lettre ouverte a donc été créé pour demander la démission de tout le comité.
Une version plus avancée serait de positionner le no follow et no index si (au moins) une des conditions est remplie:
- le journal a moins de 24h et il a une note inférieure ou égale à 5
- le journal a une note négative.
Ça me semblait facilement faisable: j'ai proposé un PR avec cette modification.
L'architecture de Bruno est vraiment top pour ça: cette simple modification modifie le "noindex,nofollow" pour tous les types de contenus publiés!
Si besoin, je peux rendre configurable le "seuil de fraîcheur" et le "seuil de score", mais 24h et 5 me semblent bien pour l'instant :)
Merci pour ces propositions, ça donne très bien en effet :)
J'avais complètement oublié cette discussion, mais elle est toujours pertinente et du coup, dans mon oubli, je n'ai même pas essayé les "sous-sections"…
Je préfère le rendu proposé par vous deux, donc il n'y aura pas de soucis à se faire avec les "sous-sections" 👍
Pour le module wifi, en tout cas chez Lenovo (même la gamme pro), tu peux en effet remplacer une carte wifi défaillante, mais elle devra être exactement du même modèle, car l'UEFI du système contrôle que les modèles sont conformes à une liste pré-établie par Lenovo.
Si tu veux du wifi 6 sur ton PC de 2011, tu peux oublier chez Lenovo. Ici, ils proposent quand même de mettre à jour la carte wifi et non pas de juste la remplacer par le même modèle.
The Framework Laptop is available in a range of pre-configured models running Windows 10 Home or Pro. For those of you who love to tinker, we’ve also created the Framework Laptop DIY Edition, the only high-end notebook available as a kit of modules that you can customize and assemble yourself, with the ability to choose Windows or install your preferred Linux distribution.
Ça donne bien envie, mais, pour l'instant, je ne vois qu'un site vitrine. C'est un peu dur d'avoir son avis sur juste quelques photos et des promesses.
Je me demande bien comment ils vont gérer l'UEFI pour un système évolutif comme ça et il me semble que je n'ai pas vu mention de carte graphique.
Pour information, j'ai regardé la liste des mainteneurs de Wine (suite à un commentaire sur Hacker News) et j'ai trouvé que, en effet, Zebediah est un des nombreux mainteneurs de Wine et en particulier, de la branche wine-staging.
Par contre, il n'est pas mainteneur du driver X11 (c'est Alexandre Julliard), ni de ce qui touche aux window manager à priori. Il serait donc possible que, malgré son avis, d'autres mainteneurs et développeurs de Wine trouvent de l'intérêt au driver Wayland.
Par contre, comme il "maintient la branche wine-staging" (je ne sais pas vraiment ce que ça veut dire), ça risque d'être compliqué de le convaincre de fusionner le patch si aucun des développeurs (soit du patch, soit ceux déjà participant à Wine) ne se propose comme mainteneur du driver Wayland.
Le développeur de Collabora a proposé son patch à Wine et a écrit:
Au fait, on m'a dit dans les discussions précédentes, qu'il faudrait qu'un tel patch soit acceptable pour upstream. Quelles sont les critères d'acceptation ?
Le driver Wayland doit être au moins entièrement compatible avec les fonctionnalités du driver X11, voire même "plus compatible". Ceci inclus du point de vue du protocole et également être compatible avec tous les gestionnaires de fenêtres. Je veux que ce soit actif par défaut dans staging et qu'il y aie peu de rapports de bugs à ce sujet, comme preuve que le driver n'est pas une mauvaise idée.
4. 5. Des promesses des développeurs de maintenir le patch, le rebase si besoin et faire la maintenance eux-même à long terme.
Même avec tous ces points réalisé, je ne suis pas particulièrement enthousiaste avec ce nouveau driver. Je reconnais que je n'ai peut être pas de pouvoir de décision à ce sujet que je ne suis pas un développeur X11 et que je manque de contexte, mais je n'aime pas la manière dont un protocole avec des fonctionnalités incomplètes a été poussé de force dans les applications avec une intention de rapidement remplacer et supprimer le protocole précédant.
Pour le point "1", je ne connais pas Alexandre, mais il doit avoir autorité dans le sujet, soit.
Pour le point "2", je comprend en partie, mais je trouve ça particulièrement lourd pour le développeur nouveau venu qui souhaite aider. Surtout associés à toutes les promesses que le nouveau venu doit faire.
J'ai l'impression que le mainteneur lui dit:
Si tu veux que ton patch passe chez les testeurs, tu dois promettre d'avoir terminé ton patch, qu'il n'y a aucuns bugs et qu'il règle toutes les incompatibilités Wayland / X11 [ce qui est hors sujet pour le développeur du driver évidemment], que tous les gestionnaires de fenêtre fonctionnent [il devra modifier les gestionnaires de fenêtre ?], que tu proposes plus de fonctionnalités et que tu deviennes mainteneur toi-même.
La barrière est plutôt très haute et je trouve que c'est le meilleur moyen de décourager / dégoûter un potentiel nouveau contributeur, même si son entreprise s'appelle "Collabora[tion]"…
En fait, le mainteneur me donne surtout l'impression d'avoir beaucoup de rancœur face à Wayland et il pense que le développeur de Collabora pourra résoudre tous ses problèmes grâce à son patch pour Wine.
De mon point de vue, il aurait été plus honnête d'être plus direct avec une réponse du genre: "Je suis mainteneur, mais je ne suis pas intéressé par un driver pour Wayland. Il faut regarder avec les autres mainteneurs" et, ensuite, mettre son dernier paragraphe pour expliquer ce qui ne l'intéresse pas dans Wayland. Parce que là, les directives qu'il a donné son clairement disproportionnées pour un nouveau driver dont le développement vient de débuter.
Il ne faut pas oublier que les emails ne sont pas synchronent: il peut y avoir beaucoup de délais entre l'envoi et la réception d'un email.
En plus, en général, il me semble que les fournisseurs de mail essaient pendant 5 jours d'envoyer l'email au serveur destinataire s'il est indisponible.
Du coup, si le serveur destinataire est indisponible pendant quelques temps (soit à cause du réseau IPv6 / IPv4 / BGP / VPN intermédiaire / firewall / DOS chez les intermédiaires / routeurs en rade…), c'est tout à fait possible que 3 heures ne suffisent simplement pas à recevoir un mail.
Je pense que garder 3 jours un compte inactif sur son service GIT n'est pas trop dérangeant (quelques Kio de disques employés) et permet au potentiel contributeur de terminer son inscription quand ses emails sont à nouveau disponible.
Si les disques se prennent vraiment trop de comptes ainsi à cause des bots, je descendrai la limite à 1 jour, voir 9 heures. En tout cas, je n'irai pas plus bas qu'"une journée de travail" (et encore, cette définition dépend des pays sources de contributeurs, par exemple, Suisse vs France vs Japon…).
Une piste serait de ne plus employer Mono, mais directement .Net Core: c'est le nouveau moteur de Microsoft et il est open-source et compatible Linux nativement.
Je l'ai employé pour un petit PoC pour créer une API REST et Microsoft fournissait directement un répertoire APT pour installer .Net Core sur Ubuntu.
Je n'ai pas donc pas essayé de faire d'interface graphique avec ce moteur, mais ça doit sûrement être possible, car c'est le nouveau fer de lance de Microsoft et qu'il doit à terme remplacer Mono si je me souviens bien.
[^] # Re: Rails ne dépend plus de mimemagic
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 3 (+0/-0).
Oui, rails a prévu la commande
db:setuppour préparer la première fois la base de donnée (ça permet de la monter sans avoir besoin de passer tous les scripts).Quand tu vois que le Docker mysql est prêt avec un log du genre:
tu peux exécuter la commande suivante:
Dans l'idéal, il aurait fallu faire un entrypoint pour le Docker linuxfr.org pour qu'il configure la première fois la base avec
db:setup.Pour bien le faire, il faudrait faire une boucle de sleep qui attend que le Docker mysql soit prêt.
[^] # Re: Rails ne dépend plus de mimemagic
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 2 (+0/-0).
Chouette, c'est cool que ça marche :-)
L'url par défaut, c'est http://dlfp.lo
Il faut penser à configurer son fichier hosts pour le définir, ainsi que img.dlfp.lo
Pour plus d'informations, tu peux regarder le fichier Docker.md.
[^] # Rails ne dépend plus de mimemagic
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 3 (+0/-0).
Alors, j'ai fait un autre Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/301
En effet, j'ai appris que Rails a décidé de proposer des versions correctives pour ne plus dépendre de mimemagick.
Je préfère ce PR, parce qu'on suit simplement les mises à jour de Rails et parce qu'on n'a pas besoin d'ajouter le paquet
shared-mime-infodans les dépendances du projet.[^] # Re: mimemagic 0.3.5 a été retiré de rubygems.org 😯
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 3 (+0/-0).
Pour info, il y a quelques liens qui expliquent pourquoi cette version a été retirée: https://github.com/mimemagicrb/mimemagic/issues/148
mimemagic est sous license MIT et il incluait un fichier de
shared-mime-infoqui est sous GPL-2. La mise à jour 0.3.10, n'inclue plus ce fichier et nécessite donc l'installation du projetshared-mime-infopour rester sous license MIT.[^] # Re: mimemagic 0.3.5 a été retiré de rubygems.org 😯
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 2 (+0/-0).
Ok, j'ai réussi à build avec les changements de ce Pull Request: https://github.com/linuxfrorg/linuxfr.org/pull/300/files
Comme j'ai indiqué dans le Pull Request, je ne suis pas sûr de pouvoir mettre à jour la version bundle dans le Gemfile.lock.
Si ce n'est pas possible, j'aurai encore besoin de modifier le Gemfile.lock, mais en attendant, tu peux utiliser ce patch pour réussir à build l’environnement.
# mimemagic 0.3.5 a été retiré de rubygems.org 😯
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Le script de build docker-compose de linuxfr n'est pas à jour. Évalué à 3 (+0/-0). Dernière modification le 12 avril 2021 à 21:28.
Hello,
Oh, je n'avais pas pensé que l'on pouvait enlever des versions sur rubygems.org…
D'un côté je comprends, les développeurs ne peuvent pas faire le support de toutes les versions, mais d'un autre côté, ce n'est pas très pratique pour pouvoir construire des environnements stables.
Même Debian Bullseye (la testing) a la version 0.3.5 de mimemagic 😅
Heureusement, je vois sur rubygems que l'on pourrait essayer de passer à la version 0.3.10, en croisant les doigts pour que semver soit bien respecté.
Si jamais, j'ai choisi de faire les images Docker avec Debian Stretch, parce que ça correspond aux serveurs de productions de LinuxFr et parce que je n'avais simplement pas réussi à monter l'environnement avec Buster.
Je n'ai pas assez d'expérience avec les environnements Ruby et Rails pour m'aventurer avec d'autres versions de Debian, mais c'est volontiers si quelqu'un y arrive :)
[^] # Re: Thème GTK ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche GNOME annonce la nouvelle bibliothèque libadwaita. Évalué à 10.
Ce n'est qu'une question d'habitudes… Attention, elles changent souvent 😂
L'article explique justement qu'Adwaita est maintenant clairement le langage visuel et comportemental de GNOME et, surtout, validé par l'équipe design de GNOME.
De fait, c'est un thème GTK, un set d'icônes et de widgets GTK prêt à l'emploi pour créer une application estampillée GNOME (ou qui cible uniquement la plateforme GNOME).
Le thème Adwaita que tu as connu avant va s'appeler dorénavant "Défaut" dans GTK et sera une copie de l'ancien Adwaita. Il ne suivra plus les préceptes de GNOME et deviendra naturellement compatible multi-plateforme, car GTK ne cible plus aucune plateforme en particulier (Windows, MacOS, Elementary, XFCE…).
La bonne nouvelle de ce changement d'habitude, c'est que GTK pourra enfin mieux fonctionner sur Windows, MacOS, Elementary, XFCE… et ce sans avoir besoin de triturer le thème par défaut ni les widgets par défaut.
Il faut voir Adwaita, comme la marque de GNOME. Avant, GTK 3 était très lié à GNOME et c'est pour ça que Adwaita était directement dans GTK.
Aujourd'hui, GTK n'a plus besoin d'évoluer aussi vite que GNOME, il faut voir ça comme un bon signe: GTK est devenue plus mûre et assagit sa vitesse de développement pour être à nouveau plus stable, générique et multiplateforme :-)
Toutefois, je pense que l'on ne va pas se retrouver bloqué avec de vieux widgets comme à l'époque de GTK+ 2 et GNOME 2: en effet, libadwaita permettra d'expérimenter de nouveaux widgets et, à terme, s'ils sont intéressants pour toutes les plateformes cibles de GTK, de les intégrer dans GTK directement.
J'ai le sentiment que GNOME et GTK ont enfin pu se séparer correctement grâce à GTK 4 et son nouveau paradigme où "tout est un widget" (enfin, si j'ai bien suivi GTK 4, je ne suis pas sûr).
[^] # Re: IPOT ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au sondage Faut-il remplacer la police d'écriture "Lato Light" par "Lato" sur LinuxFr ?. Évalué à 2.
Pas de problèmes, merci pour l'explication :)
[^] # Re: IPOT ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au sondage Faut-il remplacer la police d'écriture "Lato Light" par "Lato" sur LinuxFr ?. Évalué à 4.
C'est ça, on est déjà passé en Regular.
Le titre du sondage est donc lui même faux.
# IPOT ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au sondage Faut-il remplacer la police d'écriture "Lato Light" par "Lato" sur LinuxFr ?. Évalué à 5. Dernière modification le 09 avril 2021 à 17:59.
Ça fait 2 ans que j'ai proposé ce sondage, on dirait qu'IPOT a fonctionné à l'envers 😅
En fait, j'avais finalement demandé de ne pas publier ce sondage, mais je ne sais plus pourquoi exactement.
Peut être simplement que, finalement, on est passé de Lato Light à Lato Regular ?
Bref, je ne comprends pas bien pourquoi ce sondage est ressorti 2 ans après et s'il est vraiment pertinent aujourd'hui ?
[^] # Re: A propos de l'espace de rédaction
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Nouvelles de l'espace de rédaction. Évalué à 4. Dernière modification le 06 avril 2021 à 13:30.
Pour l'espace de rédaction, il faut utiliser le style par défaut de LinuxFr: https://linuxfr.org/suivi/la-barre-laterale-ne-peut-etre-masquee-et-masque-le-contenu-d-une-depeche-en-redaction
# Intéressant
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi un lien wikipedia masque les parenthèses suivantes. Évalué à 3 (+0/-0). Dernière modification le 05 avril 2021 à 09:21.
Hello,
MMhhh, ça sera intéressant à debugger: le problème semble être le mélange de la syntaxe Markdown pour les liens
[super lien](http://localhost)et les liens wikipédias custom de LinuxFr[[article wikipédia.]]. En effet l'exemple[[article wikipédia]] (avec des explications)contient les 2 syntaxes imbriquées.Pour info, la source Markdown des exemples donnés dans le poste orignal:
Je ne suis pas sûr que ça sera facile à corriger, car il faudrait modifier l'interpréteur Markdown.
Par contre, un autre exemple de contournement, ça serait de faire tout en Markdown:
On perd la fonction "wikipedia", mais on évite de devoir mettre le texte en italique après.
[^] # Re: Implémentation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Indexation différée des contenus non modérés a priori. Évalué à 2 (+0/-0).
Ah oui, c'est bien vu d'utiliser le seuil d'acceptation de la modération, j'ai ajusté le commit.
# C'est prêt
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Ne pas indexer les étiquettes masquées. Évalué à 2 (+0/-0).
Hello,
En effet, c'est bien vu et le correctif est assez simple: https://github.com/linuxfrorg/linuxfr.org/pull/298 :)
# Lettre ouverte pour la démission du comité de la FSF
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Richard Stallman réintègre la direction de la Free Software Foundation. Évalué à 7. Dernière modification le 24 mars 2021 à 08:19.
Tout le monde n’est pas heureux du retour de Richard Stallman.
J’ai lu l'article de Sam Hartmann (Chef du projet Debian en 2019), où il explique qu’il aurait dû parler avant des comportements désagréables de Richard Stallman et que c’est de sa responsabilité d’en parler.
J’y ai aussi appris qu’il n’est pas le seul à trouver intolérable que le comité de la FSF ait accepté le retour de Richard Stallman. Une lettre ouverte a donc été créé pour demander la démission de tout le comité.
# Implémentation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Indexation différée des contenus non modérés a priori. Évalué à 2 (+0/-0).
Hello,
Ça me semblait facilement faisable: j'ai proposé un PR avec cette modification.
L'architecture de Bruno est vraiment top pour ça: cette simple modification modifie le "noindex,nofollow" pour tous les types de contenus publiés!
Si besoin, je peux rendre configurable le "seuil de fraîcheur" et le "seuil de score", mais 24h et 5 me semblent bien pour l'instant :)
[^] # Re: Comment rendre sympa les codes ISO ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Les langues ne devraient pas être indiquées avec des drapeaux de pays. Évalué à 2 (+0/-0).
J'ai proposé un PR pour appliquer ça: https://github.com/linuxfrorg/linuxfr.org/pull/296
[^] # Re: Comment rendre sympa les codes ISO ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi Les langues ne devraient pas être indiquées avec des drapeaux de pays. Évalué à 2 (+0/-0).
Merci pour ces propositions, ça donne très bien en effet :)
J'avais complètement oublié cette discussion, mais elle est toujours pertinente et du coup, dans mon oubli, je n'ai même pas essayé les "sous-sections"…
Je préfère le rendu proposé par vous deux, donc il n'y aura pas de soucis à se faire avec les "sous-sections" 👍
[^] # Re: Quelques doutes
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Introducing the Framework Laptop. Upgradeable, repairable, and 100% yours.. Évalué à 4.
Pour le module wifi, en tout cas chez Lenovo (même la gamme pro), tu peux en effet remplacer une carte wifi défaillante, mais elle devra être exactement du même modèle, car l'UEFI du système contrôle que les modèles sont conformes à une liste pré-établie par Lenovo.
Si tu veux du wifi 6 sur ton PC de 2011, tu peux oublier chez Lenovo. Ici, ils proposent quand même de mettre à jour la carte wifi et non pas de juste la remplacer par le même modèle.
[^] # Re: les prix ?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Introducing the Framework Laptop. Upgradeable, repairable, and 100% yours.. Évalué à 4.
Sur leur article présentant leur laptop, c'est bien mentionné Linux:
Ça donne bien envie, mais, pour l'instant, je ne vois qu'un site vitrine. C'est un peu dur d'avoir son avis sur juste quelques photos et des promesses.
Je me demande bien comment ils vont gérer l'UEFI pour un système évolutif comme ça et il me semble que je n'ai pas vu mention de carte graphique.
[^] # Re: En gros
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Comment Google se moque de la CNIL (Pixel de Tracking). Évalué à 2.
Pour LinuxFr, ce n'est pas un cookie de tracking, c'est un cookie de session ;)
Par contre, je ne sais pas à quoi il sert quand l'utilisateur n'est pas connecté…
[^] # Re: Ce n'est malheureusement pas pour tout de suite et peut être pour jamais
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Wayland sur Wine : Une première mise à jour!. Évalué à 4.
Pour information, j'ai regardé la liste des mainteneurs de Wine (suite à un commentaire sur Hacker News) et j'ai trouvé que, en effet, Zebediah est un des nombreux mainteneurs de Wine et en particulier, de la branche wine-staging.
Par contre, il n'est pas mainteneur du driver X11 (c'est Alexandre Julliard), ni de ce qui touche aux window manager à priori. Il serait donc possible que, malgré son avis, d'autres mainteneurs et développeurs de Wine trouvent de l'intérêt au driver Wayland.
Par contre, comme il "maintient la branche wine-staging" (je ne sais pas vraiment ce que ça veut dire), ça risque d'être compliqué de le convaincre de fusionner le patch si aucun des développeurs (soit du patch, soit ceux déjà participant à Wine) ne se propose comme mainteneur du driver Wayland.
# Ce n'est malheureusement pas pour tout de suite et peut être pour jamais
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au lien Wayland sur Wine : Une première mise à jour!. Évalué à 5.
Le développeur de Collabora a proposé son patch à Wine et a écrit:
Un des mainteneurs de Wine a répondu en gros:
Pour le point "1", je ne connais pas Alexandre, mais il doit avoir autorité dans le sujet, soit.
Pour le point "2", je comprend en partie, mais je trouve ça particulièrement lourd pour le développeur nouveau venu qui souhaite aider. Surtout associés à toutes les promesses que le nouveau venu doit faire.
J'ai l'impression que le mainteneur lui dit:
La barrière est plutôt très haute et je trouve que c'est le meilleur moyen de décourager / dégoûter un potentiel nouveau contributeur, même si son entreprise s'appelle "Collabora[tion]"…
En fait, le mainteneur me donne surtout l'impression d'avoir beaucoup de rancœur face à Wayland et il pense que le développeur de Collabora pourra résoudre tous ses problèmes grâce à son patch pour Wine.
De mon point de vue, il aurait été plus honnête d'être plus direct avec une réponse du genre: "Je suis mainteneur, mais je ne suis pas intéressé par un driver pour Wayland. Il faut regarder avec les autres mainteneurs" et, ensuite, mettre son dernier paragraphe pour expliquer ce qui ne l'intéresse pas dans Wayland. Parce que là, les directives qu'il a donné son clairement disproportionnées pour un nouveau driver dont le développement vient de débuter.
[^] # Re: Follow-up
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Gitea contre les bots. Évalué à 6. Dernière modification le 21 février 2021 à 23:19.
Il ne faut pas oublier que les emails ne sont pas synchronent: il peut y avoir beaucoup de délais entre l'envoi et la réception d'un email.
En plus, en général, il me semble que les fournisseurs de mail essaient pendant 5 jours d'envoyer l'email au serveur destinataire s'il est indisponible.
Du coup, si le serveur destinataire est indisponible pendant quelques temps (soit à cause du réseau IPv6 / IPv4 / BGP / VPN intermédiaire / firewall / DOS chez les intermédiaires / routeurs en rade…), c'est tout à fait possible que 3 heures ne suffisent simplement pas à recevoir un mail.
Je pense que garder 3 jours un compte inactif sur son service GIT n'est pas trop dérangeant (quelques Kio de disques employés) et permet au potentiel contributeur de terminer son inscription quand ses emails sont à nouveau disponible.
Si les disques se prennent vraiment trop de comptes ainsi à cause des bots, je descendrai la limite à 1 jour, voir 9 heures. En tout cas, je n'irai pas plus bas qu'"une journée de travail" (et encore, cette définition dépend des pays sources de contributeurs, par exemple, Suisse vs France vs Japon…).
# .Net Core
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au message Environnement de développement pour C#. Évalué à 5.
Hello,
Une piste serait de ne plus employer Mono, mais directement .Net Core: c'est le nouveau moteur de Microsoft et il est open-source et compatible Linux nativement.
Je l'ai employé pour un petit PoC pour créer une API REST et Microsoft fournissait directement un répertoire APT pour installer .Net Core sur Ubuntu.
Je n'ai pas donc pas essayé de faire d'interface graphique avec ce moteur, mais ça doit sûrement être possible, car c'est le nouveau fer de lance de Microsoft et qu'il doit à terme remplacer Mono si je me souviens bien.