Non car ChatGPT est instantanné et ne demande pas un minimum de reflexion et de recherche. D'autant plus que ChatGPT conçoit une réponse à votre propre question alors que les réponses sous stackoverflow sont basées sur des questions existantes et donc nécessite parfois une adaptation pour un usage personnel. En revanche, quand vous posez une question sur stackoverflow, il faut déjà écrire un minimum de code pour avoir une réponse.
Utiliser ChatGPT est le moyen le plus simple de devenir un développeur médiocre.
Comme dirait un de mes collègues (plutôt bon justement) « pourquoi je lirais la documentation si ChatGPT le fait pour moi ».
git is great because linus did it, mercurial is better because he didn't
C'est vrai, mon collègue qui me montre son code généré par ChatGPT et demande pourquoi ça fonctionne pas sans savoir le fonctionnement d'aucune des ligne écrite… c'est productif !
La sélection naturelle, je sais avec qui j'ai envie de travailler et ceux que j'ai envie d'aider ou pas. D'une certaine manière, merci l'IA !
git is great because linus did it, mercurial is better because he didn't
Par contre wayland pour le coup est beaucoup trop basique. Même si les fonctionnalités ont changé il reste des choses assez génériques comme les entrées et sorties et globalement ce n'est pas prêt de changer avant un moment. Ce que je veux dire c'est que X11 a été pensé avec des besoins de l'époque dont les APIs n'ont cessé d'être remodelées et/ou remplacées pour du matériel changeant. Or, aujourd'hui on a quand même une stabilité qui nous permettrait d'avoir un minimum de support directement dans les protocols wayland plutôt que réimplémener toute la pile pour chaque compositeur (quand on veut/peut pas utiliser des bibliothèques existantes). Par exemple, on a quasiment tous un ou des écrans plutôt rectangle, un clavier et un pointeur quelconque.
Beaucoup de compositeurs sont basés sur wlroots avec les avantages et inconvénients que cela comporte. Si demain je décide de faire un compositeur de zéro je dois implémenter une grosse partie de la gestion des entrées/sorties plutôt que de me baser sur mon compositeur lui même. Et on voit le nombre de problème liés à KDE/GNOME qui implémentent eux même leur compositeur créant une fragmentation encore plus élevée dès lors qu'une application s'attend à utiliser un protocol expérimental xyz-abc-v2 que l'un ou l'autre ne supporte pas correctement ou pas du tout (n'est-ce pas xdg-decoration)
git is great because linus did it, mercurial is better because he didn't
X11 ça fouette, on va pas se mentir. Ça date des années boys band et ça vient avec plein de limitations liées à notre utilisation de l'époque. On avait tous un clavier PS2 et une souris PS2, un écran et c'est tout. Puis on a eu l'USB, les écrans multiples, le hotplug et tout le tralala. Bien évidemment X11 n'était pas prêt pour ça et nous avons du ajouter une multitude de couches par dessus. Maintenant, compiler X.Org est impossible sans warning dans chacune des libx*.
Oh wayland simplifie le tout en implémentant quasiment rien. Super, chaque compositeur doit réimplémenter la pile graphique, la gestions des entrées et des sorties. On a déplacé le problème à l'extérieur.
Du coup on peut passer du temps à recoder une grosse partie et/ou utiliser quelques bibliothèques toutes faite mais il nous reste notre manière d'implémenter la partie visible à l'utilisateur : comment lui laisser configurer les écrans et entrées. Donc à chaque compositeur, on rajoute ce risque. Avec X.Org, il n'y a pas de problème puisque c'est géré en amont avec nos outils habituels setxkbpmap, xrandr, etc.
En plus, aujourd'hui on a une fragmentation des bibliothèques qui ne supportent pas ou ne veulent pas supporter Wayland. Oh et bien sûr je ne parle pas des protocols Wayland en doublons qui font la même chose que les compositeurs décident d'implémenter ou non…
Bref, c'est pas 2025 l'année du bureau sous Linux :)
git is great because linus did it, mercurial is better because he didn't
(mais bon, comme le but de Drew Devault, c'est avant tout de gueuler et d'avoir du pognon, forcément, il va pas passer par la solution en question)
Et ne pas oublier qu'il est une personne ultra arrogante, fermée d'esprit et pleurnicharde. J'invite toute personne sensée à rester loin de tout projet où il est impliqué.
git is great because linus did it, mercurial is better because he didn't
Pas entièrement mais ça fait parti des hardware les plus libres. Leur HAL est libre, leur outils (idf) le sont, ils poussent du code dans le projet zephyr. Bref, Espressif est vraiment coopératif.
Pour le moment ce n'est pas le cas de la parti radio (wifi/bt) comme pour beaucoup de chip (j'ai vraiment jamais compris cette obsession…) mais le reste l'est déjà beaucoup
Vive ESP32 et vive RISC-V.
git is great because linus did it, mercurial is better because he didn't
On est loin d'avoir atteint l'égalité et les conservateurs le savent très bien, on assiste même à une regression. On s'est battu pour avoir le droit à l'IVG et aux US on fait machine arrière.
Ce monde est fou.
git is great because linus did it, mercurial is better because he didn't
Si je me trompe pas sur les specs des MacBook de 2005 on est sur du Intel Core Duo à même pas 1,8Ghz. Je suis navré mais Linux ou pas, il ne sera pas spécialement performant pour une distribution moderne à moins de faire tourner un environnement de bureau sans aucun effet 3D… Donc exit GNOME ou Plasma. Ajoute à ça un bon vieux disque dur mécanique, lui ne fera pas de miracle.
git is great because linus did it, mercurial is better because he didn't
Avec C et le C++ c'est facile de faire planter un programme mais ça l'est tout autant en python qu'en rust. J'ai des programme en python qui ont planté, en rust aussi, bref. C'est sûr que que le C et le C++ ne sont pas parfait mais les compilateurs ont fait des efforts de dingue maintenant.
De plus les sanitizers et les linter statiques sont vraiment puissant qu'ils permettent de voir beaucoup de problèmes à la compilation et pendant le phase de dev.
Pour ma part, ça fait un bien grand moment que j'ai pas fait un buffer overflow.
git is great because linus did it, mercurial is better because he didn't
Il faut regarder sur ta distribution actuelle s'il y a un paquet nommé b43 ou similaire. Si le module n'est pas chargé automatiquement au démarrage on pourra regarder pour faire un règle udev mais normalement un simple ajout dans /etc/modprobe ou /etc/module* devrait faire le taf.
Ne pas oublier de voir si la carte n'est pas verrouillé par rfkill aussi :
sudo rfkill list
sudo rfkill unblock all
git is great because linus did it, mercurial is better because he didn't
comme tout le monde… faire un .deb nécessite un doctorat. un trillion de commandes différente (dh, deb, dpkg) et un trillions de fichiers de syntaxe différente. pour l'utilisateur apt, apt-*, aptitude. j'ai jamais compris l'engouement pour ce gestionnaire de paquet.
même si je suis pas fan du RPM, c'est un .spec et on en parle plus.
vive apk.
git is great because linus did it, mercurial is better because he didn't
C'était une bonne présentation. C'était aussi cool de voir Lennart en vrai, ça met un visage et un aperçu sur un des personnages dont on entend régulièrement parler.
Son visage apparaissait souvent (et même sur des coussins, mais je trouve plus la photo) et d'ailleurs je sais pas si le travail le stress mais pour son âge je trouve qu'il a pris une claque par rapport aux débuts de systemd. Ça fait presque de la peine, qu'on aime ou pas systemd, il s'est pris une sacré shitstorm dont il en avait fait un message sur google+ à l'époque.
git is great because linus did it, mercurial is better because he didn't
La connectique USB-C varie beaucoup je trouve d'un fabricant à l'autre. Sur les thinkpad du travail c'est vraiment mou et pas enfoncé jusqu'au bout. On est nombreux à avoir des déconnexions intempestives avec des docks. C'est frustrant sur des ordinateurs ayant même pas 3 ans.
Sur mon MacBook, la connectique du cable officiel et même de ceux d'autres marques s'enfoncent vraiment jusqu'au bout et le cable n'a plus aucun moyen de bouger. On sent le souci du détail, d'autant plus que celui du chargeur officiel a un petit effet magnétique si je ne dis pas de bêtises.
Je suis assez inquiet du manque de qualité de certains fabricants, surtout que l'USB-C se veut comme un remplaçant à tous les autres connecteurs. Mais si déplacer un ordinateur (fixe comme portable) rend une connexion fragile alors je préfère rester sur du DisplayPort au moins pour la vidéo.
Alors imaginez le micro-b et le micro hdmi (qui ne peste pas sur ce connecteur du diable de la Pi >= 4)
git is great because linus did it, mercurial is better because he didn't
Donc quand j’écris un texte qui a pour vocation d’être lu, je préfère la clarté de SystemD à la coquetterie pédante de systemd.
Ce que tu préfères et pense comme lisible est subjectif et ne respecte pas le nommage souhaité des auteurs. Il en va de même avec Lua qui n'est pas un acronyme et dont les auteurs souhaitent qu'on écrive Lua et non LUA. Je vois pas en quoi un D majuscule améliore la lisibilité, sinon je peux aussi écrire un article comme tel :
À la découverte de GnomE sous ArcH LinuX. Pour installer le bureau GnomE, on utilise PacmaN :
# pacman -S gnome
C'est encore plus remarquable à quel point ça met en erreur puisque les commandes n'ont pas du tout cette orthographe.
Mon cousin s'appelle Thiebault, je pense qu'il préfère que je l'orthographie comme ça et non Thibaut, Thibault ou encore Tibo sauf autorisation explicite de sa part.
Personne n'écrit SndioD, HttpD, TftpD, VmD alors il n'y a aucune raison de le faire avec systemd.
git is great because linus did it, mercurial is better because he didn't
Un modérateur peut-il faire un gros sed s/SystemD/systemd/g, qu'on aime ou pas, c'est important de respecter le nommage des services (httpd, mpd, sndiod, nsd, etcd).
Je ne comprends toujours pas d'où cette orthographe a pu voir le jour…
git is great because linus did it, mercurial is better because he didn't
Je ne connais pas ton niveau d'utilisation de tous les outils « bas niveau » donc je te donne ma vision assez roots mais que j'utilise souvent.
Pour ma part c'est :
Prendre un disque dur externe >= SSD actuel et le monter dans /mnt
Faire un bon gros rsync -avHX --exclude=/dev --exclude=/sys --exclude=/proc --exclude=/mnt / /mnt/DISQUE_EXTERNE/
Installer le nouveau SSD/NVMe
Booter un iso linux quelconque avec au minimum rsync
Partitionner son nouveau disque au choix et le monter dans /mnt/target
Monter le disque dur externe de backup dans /mnt/backup
Copier le contenu rsync -avHX /mnt/backup/ /mnt/target
En fonction du chargeur de démarrage, rajouter une entrée EFI s'il n'y a pas un bootx64.efi par défaut (efibootmgr par exemple)
Attention à bien mettre des slash en fin de nom des répertoire sources, il s'agit de copier le contenu et pas le répertoire lui même rsync -a /foo /bar copie /foo dans /bar alors que rsync -a /foo/ /bar copie le contenu de /foo dans /bar ce qui nous intéresse dans ce genre de cas.
git is great because linus did it, mercurial is better because he didn't
Je sais qu'il y a un concept de mainteneur qui valide et « supervise » le développement de certaines parties, mais l'article laisse supposer que personne ne va être en mesure de continuer le développement. Or, il est clair qu'il y avait quand même beaucoup de contributeurs sur l'aspect wireless si on regarde l'historique
git is great because linus did it, mercurial is better because he didn't
La variable volatile n'est pas normalement autorisée à être passée à memset et ne changerait pas forcément le résultat. Le compilateur retire l'appel à memset car il voit qu'il y a rien derrière qui utilise la variable. C'est un mot clé utilisé plutôt en relation avec des accès registres pour éviter des optimisations sur des variables modifiées « à l'extérieur ».
Je crois qu'en C standard pur (si on a pas memset_explicit) le mieux est de passer la variable à une fonction externe qui fait un memset derrière. Dans ce cas il est possible que le compilateur ne prenne plus trop d'initiatives sans savoir ce que la fonction fait.
J'ai une relation particulière avec Gimp. C'est ce que j'utilise peu importe la plateforme pour réaliser des montages, du graphisme de base pour mes jeux et retravailler rapidement des photos mais je suis loin d'être un gros graphiste même si je suis assez à l'aise avec.
Même à l'époque où on avait pas d'écran haute résolution (et encore GNOME sous Gtk 2) j'avais du mal à aimer Gimp. Au début il y avait cette fameuse interface multi fenêtres et puis on a fusionné en une, c'était déjà mieux mais ça reste vraiment compliqué pour la plupart des utilisateurs.
La migration vers Gtk 3 a pris une éternité (et Gtk 5 verra bientôt le jour…). N'est-il pas temps d'imaginer une refonte intégrale de l'interface et de ses icônes austères ? Le thème sombre par défaut et les icônes en noir et blanc : je ne comprends vraiment pas. La première chose que je fais quand j'ouvre gimp est de changer le thème tellement j'ai du mal à les reconnaitre (quand je ne connais pas le raccourci d'un outil par cœur).
Dans tous les cas, merci pour le travail qui est fait par les développeur pour nous permettre d'avoir tout de même un outil libre décent.
git is great because linus did it, mercurial is better because he didn't
Pour moi cette dépêche, le jeu et son organisation (gouvernance) sont un brillant exemple de sobriété numérique. On y trouve des compétences et du plaisir à produire du code, faire des sprites et communiquer là-dessus. Cette activité contemporaine crée du lien avec un impact écologique insignifiant.
ça c'est difficile à quantifier. on peut développer chez soi avec une machine de guerre, un, deux voire trois écrans ultra lumineux et des lumières de maison pas led tout comme on peut dev sur une raspberry pi ou un ordinateur portable ARM ne consommant rien.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ma version
Posté par David Demelier (site web personnel) . En réponse au lien Why I stopped using AI code editors. Évalué à 5 (+3/-0).
Non car ChatGPT est instantanné et ne demande pas un minimum de reflexion et de recherche. D'autant plus que ChatGPT conçoit une réponse à votre propre question alors que les réponses sous stackoverflow sont basées sur des questions existantes et donc nécessite parfois une adaptation pour un usage personnel. En revanche, quand vous posez une question sur stackoverflow, il faut déjà écrire un minimum de code pour avoir une réponse.
Utiliser ChatGPT est le moyen le plus simple de devenir un développeur médiocre.
Comme dirait un de mes collègues (plutôt bon justement) « pourquoi je lirais la documentation si ChatGPT le fait pour moi ».
git is great because linus did it, mercurial is better because he didn't
[^] # Re: On peut faire du bureau avec ?
Posté par David Demelier (site web personnel) . En réponse à la dépêche Raspberry Pi 5, évolution ou révolution ?. Évalué à 2 (+0/-0).
Tout ce que tu veux est un peu exagéré. Déjà, vaut mieux passer sur un SSD parce que la carte SD introduit des ralentissements non négligeable.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Ma version
Posté par David Demelier (site web personnel) . En réponse au lien Why I stopped using AI code editors. Évalué à 3 (+1/-0). Dernière modification le 09 avril 2025 à 08:58.
C'est vrai, mon collègue qui me montre son code généré par ChatGPT et demande pourquoi ça fonctionne pas sans savoir le fonctionnement d'aucune des ligne écrite… c'est productif !
La sélection naturelle, je sais avec qui j'ai envie de travailler et ceux que j'ai envie d'aider ou pas. D'une certaine manière, merci l'IA !
git is great because linus did it, mercurial is better because he didn't
# Ma version
Posté par David Demelier (site web personnel) . En réponse au lien Why I stopped using AI code editors. Évalué à 2 (+0/-0).
“why I'll never use any AI thing ever”
git is great because linus did it, mercurial is better because he didn't
[^] # Re: En quel langage ?
Posté par David Demelier (site web personnel) . En réponse au lien KNOME : un nouveau DE union de GNOME et KDE. Évalué à 2 (+0/-0). Dernière modification le 02 avril 2025 à 12:09.
C'est mort né.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par David Demelier (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 3 (+1/-0).
Aucune idée, je m'y suis jamais intéressé.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: J'aime pas X11 mais encore moins Wayland
Posté par David Demelier (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 3 (+1/-0).
Je suis assez d'accord sur le principe.
Par contre wayland pour le coup est beaucoup trop basique. Même si les fonctionnalités ont changé il reste des choses assez génériques comme les entrées et sorties et globalement ce n'est pas prêt de changer avant un moment. Ce que je veux dire c'est que X11 a été pensé avec des besoins de l'époque dont les APIs n'ont cessé d'être remodelées et/ou remplacées pour du matériel changeant. Or, aujourd'hui on a quand même une stabilité qui nous permettrait d'avoir un minimum de support directement dans les protocols wayland plutôt que réimplémener toute la pile pour chaque compositeur (quand on veut/peut pas utiliser des bibliothèques existantes). Par exemple, on a quasiment tous un ou des écrans plutôt rectangle, un clavier et un pointeur quelconque.
Beaucoup de compositeurs sont basés sur wlroots avec les avantages et inconvénients que cela comporte. Si demain je décide de faire un compositeur de zéro je dois implémenter une grosse partie de la gestion des entrées/sorties plutôt que de me baser sur mon compositeur lui même. Et on voit le nombre de problème liés à KDE/GNOME qui implémentent eux même leur compositeur créant une fragmentation encore plus élevée dès lors qu'une application s'attend à utiliser un protocol expérimental
xyz-abc-v2que l'un ou l'autre ne supporte pas correctement ou pas du tout (n'est-ce pas xdg-decoration)git is great because linus did it, mercurial is better because he didn't
# J'aime pas X11 mais encore moins Wayland
Posté par David Demelier (site web personnel) . En réponse au journal Wayland, l'obsession éternelle du carré blanc. Évalué à 9 (+8/-1).
X11 ça fouette, on va pas se mentir. Ça date des années boys band et ça vient avec plein de limitations liées à notre utilisation de l'époque. On avait tous un clavier PS2 et une souris PS2, un écran et c'est tout. Puis on a eu l'USB, les écrans multiples, le hotplug et tout le tralala. Bien évidemment X11 n'était pas prêt pour ça et nous avons du ajouter une multitude de couches par dessus. Maintenant, compiler X.Org est impossible sans warning dans chacune des
libx*.Oh wayland simplifie le tout en implémentant quasiment rien. Super, chaque compositeur doit réimplémenter la pile graphique, la gestions des entrées et des sorties. On a déplacé le problème à l'extérieur.
Du coup on peut passer du temps à recoder une grosse partie et/ou utiliser quelques bibliothèques toutes faite mais il nous reste notre manière d'implémenter la partie visible à l'utilisateur : comment lui laisser configurer les écrans et entrées. Donc à chaque compositeur, on rajoute ce risque. Avec X.Org, il n'y a pas de problème puisque c'est géré en amont avec nos outils habituels
setxkbpmap,xrandr, etc.En plus, aujourd'hui on a une fragmentation des bibliothèques qui ne supportent pas ou ne veulent pas supporter Wayland. Oh et bien sûr je ne parle pas des protocols Wayland en doublons qui font la même chose que les compositeurs décident d'implémenter ou non…
Bref, c'est pas 2025 l'année du bureau sous Linux :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: robot.txt
Posté par David Demelier (site web personnel) . En réponse au lien Drew Devault : Please stop externalizing your costs directly into my face . Évalué à -3 (+1/-6).
Et ne pas oublier qu'il est une personne ultra arrogante, fermée d'esprit et pleurnicharde. J'invite toute personne sensée à rester loin de tout projet où il est impliqué.
git is great because linus did it, mercurial is better because he didn't
# Quasiment opensource
Posté par David Demelier (site web personnel) . En réponse au journal Une backdoor dans les ESP32 ?. Évalué à 10 (+10/-0).
Pas entièrement mais ça fait parti des hardware les plus libres. Leur HAL est libre, leur outils (idf) le sont, ils poussent du code dans le projet zephyr. Bref, Espressif est vraiment coopératif.
Pour le moment ce n'est pas le cas de la parti radio (wifi/bt) comme pour beaucoup de chip (j'ai vraiment jamais compris cette obsession…) mais le reste l'est déjà beaucoup
Vive ESP32 et vive RISC-V.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Plutôt une bonne chose, non ?
Posté par David Demelier (site web personnel) . En réponse au lien Apple et Google suppriment la journée internationale des droits des femmes de leur calendrier . Évalué à 10 (+12/-0).
On est loin d'avoir atteint l'égalité et les conservateurs le savent très bien, on assiste même à une regression. On s'est battu pour avoir le droit à l'IVG et aux US on fait machine arrière.
Ce monde est fou.
git is great because linus did it, mercurial is better because he didn't
# Ça ne sera pas un cheval de course
Posté par David Demelier (site web personnel) . En réponse au message Vieux mac + linux. Évalué à 2 (+1/-1).
Si je me trompe pas sur les specs des MacBook de 2005 on est sur du Intel Core Duo à même pas 1,8Ghz. Je suis navré mais Linux ou pas, il ne sera pas spécialement performant pour une distribution moderne à moins de faire tourner un environnement de bureau sans aucun effet 3D… Donc exit GNOME ou Plasma. Ajoute à ça un bon vieux disque dur mécanique, lui ne fera pas de miracle.
git is great because linus did it, mercurial is better because he didn't
# Aucun langage est parfait
Posté par David Demelier (site web personnel) . En réponse au lien Bjarne Stroustrup appelle a défendre le C++ contre les attaques sur le manque de protection mémoire. Évalué à 3 (+1/-0).
Avec C et le C++ c'est facile de faire planter un programme mais ça l'est tout autant en python qu'en rust. J'ai des programme en python qui ont planté, en rust aussi, bref. C'est sûr que que le C et le C++ ne sont pas parfait mais les compilateurs ont fait des efforts de dingue maintenant.
De plus les sanitizers et les linter statiques sont vraiment puissant qu'ils permettent de voir beaucoup de problèmes à la compilation et pendant le phase de dev.
Pour ma part, ça fait un bien grand moment que j'ai pas fait un buffer overflow.
git is great because linus did it, mercurial is better because he didn't
# Visiblement une carte connue
Posté par David Demelier (site web personnel) . En réponse au message Problème wifi. Évalué à 3 (+1/-0). Dernière modification le 27 février 2025 à 13:39.
Ce chip a l'air d'être capricieux car on trouve toujours des sujets sur cette carte datant de 2022 et après.
As tu essayé cette réponse ?
Cette page en parle un peu aussi.
Il faut regarder sur ta distribution actuelle s'il y a un paquet nommé b43 ou similaire. Si le module n'est pas chargé automatiquement au démarrage on pourra regarder pour faire un règle udev mais normalement un simple ajout dans
/etc/modprobeou/etc/module*devrait faire le taf.Ne pas oublier de voir si la carte n'est pas verrouillé par
rfkillaussi :git is great because linus did it, mercurial is better because he didn't
[^] # Re: flatpak c'est nul?
Posté par David Demelier (site web personnel) . En réponse au lien Fedora should not push its users to its own Flatpak repository - OSnews. Évalué à 0 (+0/-2).
comme tout le monde… faire un .deb nécessite un doctorat. un trillion de commandes différente (dh, deb, dpkg) et un trillions de fichiers de syntaxe différente. pour l'utilisateur
apt,apt-*,aptitude. j'ai jamais compris l'engouement pour ce gestionnaire de paquet.même si je suis pas fan du RPM, c'est un .spec et on en parle plus.
vive apk.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Présentation à FOSDEM
Posté par David Demelier (site web personnel) . En réponse au lien 14 ans de systemd. Évalué à 3 (+1/-0).
Son visage apparaissait souvent (et même sur des coussins, mais je trouve plus la photo) et d'ailleurs je sais pas si le travail le stress mais pour son âge je trouve qu'il a pris une claque par rapport aux débuts de systemd. Ça fait presque de la peine, qu'on aime ou pas systemd, il s'est pris une sacré shitstorm dont il en avait fait un message sur google+ à l'époque.
git is great because linus did it, mercurial is better because he didn't
# Tous les USB ne se valent pas
Posté par David Demelier (site web personnel) . En réponse au journal J'ai testé pour vous: un câble USB magnétique. Évalué à 2 (+0/-0).
La connectique USB-C varie beaucoup je trouve d'un fabricant à l'autre. Sur les thinkpad du travail c'est vraiment mou et pas enfoncé jusqu'au bout. On est nombreux à avoir des déconnexions intempestives avec des docks. C'est frustrant sur des ordinateurs ayant même pas 3 ans.
Sur mon MacBook, la connectique du cable officiel et même de ceux d'autres marques s'enfoncent vraiment jusqu'au bout et le cable n'a plus aucun moyen de bouger. On sent le souci du détail, d'autant plus que celui du chargeur officiel a un petit effet magnétique si je ne dis pas de bêtises.
Je suis assez inquiet du manque de qualité de certains fabricants, surtout que l'USB-C se veut comme un remplaçant à tous les autres connecteurs. Mais si déplacer un ordinateur (fixe comme portable) rend une connexion fragile alors je préfère rester sur du DisplayPort au moins pour la vidéo.
Alors imaginez le micro-b et le micro hdmi (qui ne peste pas sur ce connecteur du diable de la Pi >= 4)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: s/SystemD/systemd/g
Posté par David Demelier (site web personnel) . En réponse au journal Ethernet, Udev, systemd et CUPS sont dans un bateau, tout le monde saute à l’eau. Évalué à 1 (+3/-4).
Ce que tu préfères et pense comme lisible est subjectif et ne respecte pas le nommage souhaité des auteurs. Il en va de même avec Lua qui n'est pas un acronyme et dont les auteurs souhaitent qu'on écrive Lua et non LUA. Je vois pas en quoi un D majuscule améliore la lisibilité, sinon je peux aussi écrire un article comme tel :
C'est encore plus remarquable à quel point ça met en erreur puisque les commandes n'ont pas du tout cette orthographe.
Mon cousin s'appelle Thiebault, je pense qu'il préfère que je l'orthographie comme ça et non Thibaut, Thibault ou encore Tibo sauf autorisation explicite de sa part.
Personne n'écrit SndioD, HttpD, TftpD, VmD alors il n'y a aucune raison de le faire avec systemd.
git is great because linus did it, mercurial is better because he didn't
# s/SystemD/systemd/g
Posté par David Demelier (site web personnel) . En réponse au journal Ethernet, Udev, systemd et CUPS sont dans un bateau, tout le monde saute à l’eau. Évalué à 6 (+5/-1).
Un modérateur peut-il faire un gros sed
s/SystemD/systemd/g, qu'on aime ou pas, c'est important de respecter le nommage des services (httpd, mpd, sndiod, nsd, etcd).Je ne comprends toujours pas d'où cette orthographe a pu voir le jour…
git is great because linus did it, mercurial is better because he didn't
# rsync for the win
Posté par David Demelier (site web personnel) . En réponse au message migration vers un nouveau disque interne. Évalué à 4 (+2/-0).
Je ne connais pas ton niveau d'utilisation de tous les outils « bas niveau » donc je te donne ma vision assez roots mais que j'utilise souvent.
Pour ma part c'est :
/mntrsync -avHX --exclude=/dev --exclude=/sys --exclude=/proc --exclude=/mnt / /mnt/DISQUE_EXTERNE//mnt/target/mnt/backuprsync -avHX /mnt/backup/ /mnt/targetAttention à bien mettre des slash en fin de nom des répertoire sources, il s'agit de copier le contenu et pas le répertoire lui même
rsync -a /foo /barcopie/foodans/baralors quersync -a /foo/ /barcopie le contenu de/foodans/barce qui nous intéresse dans ce genre de cas.git is great because linus did it, mercurial is better because he didn't
# Unique ?
Posté par David Demelier (site web personnel) . En réponse au lien L'unique mainteneur du pilote Wifi sur Linux se retire. Évalué à 4 (+2/-0).
Je sais qu'il y a un concept de mainteneur qui valide et « supervise » le développement de certaines parties, mais l'article laisse supposer que personne ne va être en mesure de continuer le développement. Or, il est clair qu'il y avait quand même beaucoup de contributeurs sur l'aspect wireless si on regarde l'historique
git is great because linus did it, mercurial is better because he didn't
[^] # Re: volatile ?
Posté par David Demelier (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 6 (+4/-0).
Il n'y a pas de bug, passer un pointeur
volatileà une fonction qui ne prend pas un pointeurvolatileest déjà UB (et il y a un warning par défaut).volatilec'est pour des registres matériel, pas pour des variables dont on veut empêcher l'optimisation.git is great because linus did it, mercurial is better because he didn't
[^] # Re: volatile ?
Posté par David Demelier (site web personnel) . En réponse au journal C23: un memset_explicit() qui carbure. Évalué à 4 (+2/-0).
La variable
volatilen'est pas normalement autorisée à être passée àmemsetet ne changerait pas forcément le résultat. Le compilateur retire l'appel à memset car il voit qu'il y a rien derrière qui utilise la variable. C'est un mot clé utilisé plutôt en relation avec des accès registres pour éviter des optimisations sur des variables modifiées « à l'extérieur ».Je crois qu'en C standard pur (si on a pas
memset_explicit) le mieux est de passer la variable à une fonction externe qui fait unmemsetderrière. Dans ce cas il est possible que le compilateur ne prenne plus trop d'initiatives sans savoir ce que la fonction fait.Exemple même avec volatile
Exemple avec une fonction vite fait
git is great because linus did it, mercurial is better because he didn't
# J'ai du mal à aimer Gimp
Posté par David Demelier (site web personnel) . En réponse à la dépêche GIMP 3.0 RC2 est sorti. Évalué à 4.
J'ai une relation particulière avec Gimp. C'est ce que j'utilise peu importe la plateforme pour réaliser des montages, du graphisme de base pour mes jeux et retravailler rapidement des photos mais je suis loin d'être un gros graphiste même si je suis assez à l'aise avec.
Même à l'époque où on avait pas d'écran haute résolution (et encore GNOME sous Gtk 2) j'avais du mal à aimer Gimp. Au début il y avait cette fameuse interface multi fenêtres et puis on a fusionné en une, c'était déjà mieux mais ça reste vraiment compliqué pour la plupart des utilisateurs.
La migration vers Gtk 3 a pris une éternité (et Gtk 5 verra bientôt le jour…). N'est-il pas temps d'imaginer une refonte intégrale de l'interface et de ses icônes austères ? Le thème sombre par défaut et les icônes en noir et blanc : je ne comprends vraiment pas. La première chose que je fais quand j'ouvre gimp est de changer le thème tellement j'ai du mal à les reconnaitre (quand je ne connais pas le raccourci d'un outil par cœur).
Dans tous les cas, merci pour le travail qui est fait par les développeur pour nous permettre d'avoir tout de même un outil libre décent.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: ~~Paradoxal~~ Sobre
Posté par David Demelier (site web personnel) . En réponse à la dépêche Tuxemon Tower 0 : sortie de la première version !. Évalué à 3.
ça c'est difficile à quantifier. on peut développer chez soi avec une machine de guerre, un, deux voire trois écrans ultra lumineux et des lumières de maison pas led tout comme on peut dev sur une raspberry pi ou un ordinateur portable ARM ne consommant rien.
git is great because linus did it, mercurial is better because he didn't