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
Bon, le jeu m'avait l'air sympathique mais ne pas avoir de lien direct est assez rebutant. Le torrent c'est cool et je ne dis pas le contraire mais pour des petits logiciels c'est assez barbant à utiliser.
Git est de base déjà décentralisé alors pourquoi refuser une plateforme publique ? On peut refuser GitHub, GitLab et autres pour des raisons éthiques, mais on peut aussi auto héberger sur un vps ou utiliser une plateforme éthique comme codeberg…
N'oubliez pas non plus les packagers, en tant que contributeur à Alpine, si je veux packager le jeu je suis obligé de créer une image locale hébergée quelque part. Oui c'est résilient car tout le monde fait un peu un miroir et d'un autre côté c'est la plaie à maintenir si une tarball est incorrectement générée etc.
Je pense que les convictions aussi radicales devraient pas être imposées aussi fortement à un logiciel, là ce sont les utilisateurs/contributeurs que vous pénalisez.
git is great because linus did it, mercurial is better because he didn't
La majorité des gens ne peuvent pas installer un OS libre sur la majorité des terminaux.
Et je pense que la majorité des gens qui souhaitent installer des systèmes libres restent des personnes expérimentées et qui choisissent du matériel plus respectueux et compatible. Je vois mal des personnes souhaitant acheter un iPhone pour y installer Linux.
git is great because linus did it, mercurial is better because he didn't
Je ne développe pas mon logiciel/matériel en décidant dans mon coin : il me faut une prise USB-C, je dois respecter les fréquences radio autorisées
Ça je suis d'accord et c'est bien normal. En revanche, si on développe une machine de chronométrage d'évènements sportifs basée sur la RFID, la seule chose qui est importante est de respecter les régulations radio et CEM/CE si on en fait un produit commercial (et d'autres règles purement technique)
Cependant, rien ne m'empêche de concevoir mon produit de chronométrage sous Linux, x86, arm, riscv, ou baremetal, zephyr, OpenBSD, etc. Mon message a été compris plus d'une manière générique, or moi je parle principalement de l'aspect software. Cela m'emmerderait bien qu'un jour le gouvernement toque à notre porte et nous dise « heu, pour votre machine de chronométrage, on voudrait que vous le codiez en Rust et sous ARM, parce qu'on la décidé »
Je suis pour certaines obligations qui ont du bon sens. Je salue l'obligation de l'USB-C, RGPD et toutes les choses que l'UE a imposé parce que ça touche quasiment tous les produits et il y a un véritable enjeu écologique. Pourtant, imposer le choix d'un navigateur ou d'un lecteur de musique sur iOS me parait pas cohérent : utiliser iOS est un choix personnel, si les gens n'aiment pas l'écosystème, ils peuvent se tourner vers Android, lineage, etc.
git is great because linus did it, mercurial is better because he didn't
Bon, j'ai que 35 ans mais on ne sait pas de quoi l'avenir est fait. J'avoue me demander parfois comment on devrait gérer ma disparation pour mes proches. J'ai plusieurs serveurs, un nom de domaine et un site web à moi. Mais surtout il y a les abonnements (netflix, soundcloud et des patreons à quelques entités). Peu de personnes de mon entourage ou de ma famille connait ses existences mais aucun ne connait ni OpenBSD ni les services qui tournent sur mes serveurs. Que faudrait-il faire si je disparaissais du jour au lendemain et que tout devenait impayé et pas mis à jour ?
git is great because linus did it, mercurial is better because he didn't
Je comprends pas les gouvernements qui forcent Google ou Apple à ce genre de pratique. Chrome (le vrai, propriétaire) est effectivement à Google, mais vous pouvez aller sur Duckduckgo ou bing comme bon vous semble. Vous pouvez aussi l'utiliser sans aucun service Google.
Le gouvernement européen force aussi Apple à autoriser d'autre navigateur web sur iOS (jusqu'à présent un firefox ou un chrome était juste une interface proche de l'original mais sur le moteur de webkit) alors, pourquoi pas sauf que ça induit plein de choses dont le gouvernemnt n'est pas au courant : un fabricant conçoit des APIs et des intégrations. Ainsi quand on utilise WebKit sur iOS tout ce qui concerne l'accessibilité est fortement ancré dans le système et hyper bien intégré, si on autorise d'autres frameworks on aura pas forcément les mêmes atouts.
Laisser passer toutes ces choses risque de rendre les systèmes d'exploitation de plus en plus incohérents juste pour la liberté de chacun dont tout le monde se fout : si une personne ne veut pas utiliser un produit Google elle peut installer un OS libre, utiliser firefox et c'est parti. Quand on utilise un Android, un iOS ou un Windows on sait déjà qu'on est lié à des services propriétaires. La seule chose que les gouvernements devraient imposer, c'est l'interopérabilité des services parce que devoir utiliser chrome pour avoir certaines fonctionnalités sur des sites de visioconférence est en effet une hérésie.
Avec cette boite de pandore, on va bientôt demander à ce qu'on puisse changer les icônes d'un OS, de pouvoir installer linux sur iPhone ou iOS sur Samsung, metal sous Windows, directx sous mac, des .ELF natif sous windows. Bref, j'ai du mal à concevoir qu'une entité gouvernementale puisse décider comment les développeur doivent concevoir leur plateformes.
git is great because linus did it, mercurial is better because he didn't
J'ai fait une troisième professionnelle quand j'avais 13-14 ans (2002-2003) et pour un stage j'ai aussi du écrire un CV et une lettre de motivation. Je me souviens très bien c'était en cours de VSP (Vie Sociale et Professionnelle).
Pour moi rien de choquant, un CV c'est pas juste un catalogue d'expérience et on peut déjà avoir des compétences ou des passions. Le CV peut indiquer dans quoi on est à l'aise et ce qui nous anime (langues, musique, technologie, sports). Je me souviens pas de ce que j'avais mis mais dans mon CV actuel les expériences couvrent que 60~% de la page.
git is great because linus did it, mercurial is better because he didn't
Et surtout que si c'est une fonction locale à un fichier (donc static ou namespace anonyme) le compilateur met un warning si bien configuré
C:/w/src/sigi/firmware/bootloader/main.c:46:13: warning: 'flash' defined but not used [-Wunused-function]
46 | static void flash(const void *firmware, uint32_t firmware_len) {
Pour moi c'est le moyen correct de vérifier qu'une fonction est utilisée ou non plutôt que raboter au hasard.
Autrement, le linker fait les choses bien à ne pas inclure les symbols inutilisés dès lors qu'ils sont pas tous dans le même fichier.
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é à 7 (+5/-0).
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 (+4/-2).
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
# Difficile d'accès
Posté par David Demelier (site web personnel) . En réponse à la dépêche Tuxemon Tower 0 : sortie de la première version !. Évalué à 9.
Bon, le jeu m'avait l'air sympathique mais ne pas avoir de lien direct est assez rebutant. Le torrent c'est cool et je ne dis pas le contraire mais pour des petits logiciels c'est assez barbant à utiliser.
Git est de base déjà décentralisé alors pourquoi refuser une plateforme publique ? On peut refuser GitHub, GitLab et autres pour des raisons éthiques, mais on peut aussi auto héberger sur un vps ou utiliser une plateforme éthique comme codeberg…
N'oubliez pas non plus les packagers, en tant que contributeur à Alpine, si je veux packager le jeu je suis obligé de créer une image locale hébergée quelque part. Oui c'est résilient car tout le monde fait un peu un miroir et d'un autre côté c'est la plaie à maintenir si une tarball est incorrectement générée etc.
Je pense que les convictions aussi radicales devraient pas être imposées aussi fortement à un logiciel, là ce sont les utilisateurs/contributeurs que vous pénalisez.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Faut qu'on m'explique
Posté par David Demelier (site web personnel) . En réponse au lien Le gouvernement américain veut que Google vende son navigateur Chrome, le plus utilisé au monde. Évalué à 1.
Et je pense que la majorité des gens qui souhaitent installer des systèmes libres restent des personnes expérimentées et qui choisissent du matériel plus respectueux et compatible. Je vois mal des personnes souhaitant acheter un iPhone pour y installer Linux.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Faut qu'on m'explique
Posté par David Demelier (site web personnel) . En réponse au lien Le gouvernement américain veut que Google vende son navigateur Chrome, le plus utilisé au monde. Évalué à 3.
Ça je suis d'accord et c'est bien normal. En revanche, si on développe une machine de chronométrage d'évènements sportifs basée sur la RFID, la seule chose qui est importante est de respecter les régulations radio et CEM/CE si on en fait un produit commercial (et d'autres règles purement technique)
Cependant, rien ne m'empêche de concevoir mon produit de chronométrage sous Linux, x86, arm, riscv, ou baremetal, zephyr, OpenBSD, etc. Mon message a été compris plus d'une manière générique, or moi je parle principalement de l'aspect software. Cela m'emmerderait bien qu'un jour le gouvernement toque à notre porte et nous dise « heu, pour votre machine de chronométrage, on voudrait que vous le codiez en Rust et sous ARM, parce qu'on la décidé »
Je suis pour certaines obligations qui ont du bon sens. Je salue l'obligation de l'USB-C, RGPD et toutes les choses que l'UE a imposé parce que ça touche quasiment tous les produits et il y a un véritable enjeu écologique. Pourtant, imposer le choix d'un navigateur ou d'un lecteur de musique sur iOS me parait pas cohérent : utiliser iOS est un choix personnel, si les gens n'aiment pas l'écosystème, ils peuvent se tourner vers Android, lineage, etc.
git is great because linus did it, mercurial is better because he didn't
# Parfois j'y pense
Posté par David Demelier (site web personnel) . En réponse au lien Put your usernames and passwords in your will, advises Japan's government. Évalué à 6.
Bon, j'ai que 35 ans mais on ne sait pas de quoi l'avenir est fait. J'avoue me demander parfois comment on devrait gérer ma disparation pour mes proches. J'ai plusieurs serveurs, un nom de domaine et un site web à moi. Mais surtout il y a les abonnements (netflix, soundcloud et des patreons à quelques entités). Peu de personnes de mon entourage ou de ma famille connait ses existences mais aucun ne connait ni OpenBSD ni les services qui tournent sur mes serveurs. Que faudrait-il faire si je disparaissais du jour au lendemain et que tout devenait impayé et pas mis à jour ?
git is great because linus did it, mercurial is better because he didn't
# Faut qu'on m'explique
Posté par David Demelier (site web personnel) . En réponse au lien Le gouvernement américain veut que Google vende son navigateur Chrome, le plus utilisé au monde. Évalué à -5.
Je comprends pas les gouvernements qui forcent Google ou Apple à ce genre de pratique. Chrome (le vrai, propriétaire) est effectivement à Google, mais vous pouvez aller sur Duckduckgo ou bing comme bon vous semble. Vous pouvez aussi l'utiliser sans aucun service Google.
Le gouvernement européen force aussi Apple à autoriser d'autre navigateur web sur iOS (jusqu'à présent un firefox ou un chrome était juste une interface proche de l'original mais sur le moteur de webkit) alors, pourquoi pas sauf que ça induit plein de choses dont le gouvernemnt n'est pas au courant : un fabricant conçoit des APIs et des intégrations. Ainsi quand on utilise WebKit sur iOS tout ce qui concerne l'accessibilité est fortement ancré dans le système et hyper bien intégré, si on autorise d'autres frameworks on aura pas forcément les mêmes atouts.
Laisser passer toutes ces choses risque de rendre les systèmes d'exploitation de plus en plus incohérents juste pour la liberté de chacun dont tout le monde se fout : si une personne ne veut pas utiliser un produit Google elle peut installer un OS libre, utiliser firefox et c'est parti. Quand on utilise un Android, un iOS ou un Windows on sait déjà qu'on est lié à des services propriétaires. La seule chose que les gouvernements devraient imposer, c'est l'interopérabilité des services parce que devoir utiliser chrome pour avoir certaines fonctionnalités sur des sites de visioconférence est en effet une hérésie.
Avec cette boite de pandore, on va bientôt demander à ce qu'on puisse changer les icônes d'un OS, de pouvoir installer linux sur iPhone ou iOS sur Samsung, metal sous Windows, directx sous mac, des .ELF natif sous windows. Bref, j'ai du mal à concevoir qu'une entité gouvernementale puisse décider comment les développeur doivent concevoir leur plateformes.
git is great because linus did it, mercurial is better because he didn't
# J'avais un CV à 13 ans
Posté par David Demelier (site web personnel) . En réponse au journal On n’a pas de CV quand on a 14 ans. Évalué à 6.
J'ai fait une troisième professionnelle quand j'avais 13-14 ans (2002-2003) et pour un stage j'ai aussi du écrire un CV et une lettre de motivation. Je me souviens très bien c'était en cours de VSP (Vie Sociale et Professionnelle).
Pour moi rien de choquant, un CV c'est pas juste un catalogue d'expérience et on peut déjà avoir des compétences ou des passions. Le CV peut indiquer dans quoi on est à l'aise et ce qui nous anime (langues, musique, technologie, sports). Je me souviens pas de ce que j'avais mis mais dans mon CV actuel les expériences couvrent que 60~% de la page.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Map file
Posté par David Demelier (site web personnel) . En réponse au journal Le bon sens et le C++. Évalué à 3.
Et surtout que si c'est une fonction locale à un fichier (donc
staticou namespace anonyme) le compilateur met un warning si bien configuréPour moi c'est le moyen correct de vérifier qu'une fonction est utilisée ou non plutôt que raboter au hasard.
Autrement, le linker fait les choses bien à ne pas inclure les symbols inutilisés dès lors qu'ils sont pas tous dans le même fichier.
git is great because linus did it, mercurial is better because he didn't