Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des #ifdef de partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).
Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de #ifdef/#endif dans son module natif et des if au runtime pour un module Lua.
C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
Je vais probablement passer pour un boomer mais tant pis.
J'ai atteint environ 1/3 de ma vie en âge et je dois admettre qu'après 20 ans dans le logiciel libre et le développement j'ai atteint un dégoût profond envers mon métier (je suis développeur) et la technologie en général.
À chaque fois que je regarde un produit il y a toujours quelque part un marketing "Vision" "AI ready" et autres termes inutiles.
Tout ce qui tourne autour de l'IA actuellement me donne des boutons. Certains de mes collègues utilisent ChatGPT pour répondre à des problèmes dans leur code, certains l'ont même utilisé pour me répondre à une question lors d'une merge-request. Non seulement j'ai trouvé ça particulièrement irrespectueux mais ça m'a encore plus questionné sur ce que nous sommes entrain de faire. Cet individu n'a soit pas eu envie de me répondre directement par ses propres mots soit pas compris ma question et s'est dit que ChatGPT allait me répondre à sa place. Le commentaire en question était à côté de la plaque et il ne répondait pas à ma question mais m'expliquait le morceau de code comme si j'avais aucune idée du contenu. Pour faire court, la merge request ajoutait du code pour faire une requête HTTP, le collègue a utilisé par erreur un entête content-type application/x-www-form-urlencoded or la requête envoyait du JSON, on a demandé pourquoi il a mis ce content-type précisément et la réponse de ChatGPT m'expliquait à quoi sert un content-type (merci je connais HTTP).
J'ai 20 ans de développement derrière moi, toutes mes connaissances sont acquises par l'investissement personnel, la lecture, les essais, les dents cassés, etc. Mais je sais ce que je fais dans les domaines où j'interviens. En ce moment je vois une recrudescence de collègues utilisant massivement ChatGPT au moindre problème sans même essayer d'y réfléchir et y trouver la solution. J'ai le sentiment qu'on tend vers la médiocrité croissante où le but final va être de faire un produit rapidement sans même allumer son cerveau. Tout le monde va finir par copier-coller des trucs par ci par là sans utiliser aucune des connaissances personnelles.
Ah et puis dans le côté musical, je préfère même pas commenter.
git is great because linus did it, mercurial is better because he didn't
sourcehut est une forge intéressante, mais de mon point de vue, c'est un peu le souk;
Tu cites sourcehut qui est développé par une personne ayant un égo surdimensionné, en plus cette même personne préfère justement le développement/contributions par mail plutôt que par merge requests.
Pour ceux qui pensent aller sur sourcehut, je vous invite à prendre en compte que les fortes opinions de Drew peut vous risquer votre dépôt quand un jour il décidera que ce que vous y faites n'est pas éthique selon lui.
git is great because linus did it, mercurial is better because he didn't
Et il y a eu beaucoup de contributions externes? Parce que c'est un peu l'intérêt majeur de sourceforge, github et gitlab, pour moi.
Sur un point je suis d'accord ça facilite les contributions mais ne pas passer par GitHub ça permet aussi de s'affranchir des personnes qui ne veulent pas faire les efforts nécessaires ou recevoir des PRs qui n'ont aucun sens.
Certains projets populaires sont parfois spammés par des gens qui ne font même pas parti du projet dès qu'une PR ou un tickets GitHub est popularisé via un partage reddit/hn, etc. Donc on a des individus qui débarquent sur des projets où ils n'ont jamais été juste pour “I was here” ou coller un emoji quelconque.
Les CIs sont pratiques quand on veut fournir des projets continuellement, je pense par exemple à RetroArch qui fournit des binaires tous les jours ce qui est pratique pour les projets qui changent beaucoup, ce n'est pas mon cas. La seule CI qui pourrait me servir est de m'assurer que mes projets compilent sur toutes les plateformes avant de faire une release et ça je le fais plutôt manuellement avec plusieurs VMs locales. Je n'ai pas spécialement besoin de l'automatiser.
Mais comme je suis tout de même un gens sympa et raisonnable j'ai mis des miroirs GitHub de la plupart de mes projets.
git is great because linus did it, mercurial is better because he didn't
J'ai simplement dit que la configuration n'a pas changé, les mises à jour sont faites par le gestionnaire de paquets (aka sysupgrade/pkg_add -u dans mon cas).
git is great because linus did it, mercurial is better because he didn't
L'auto-hébergement est une plaie, mais il faut être sysadmin.
Ma configuration Mercurial/nginx n'a pas changé depuis 2009. Après bien entendu installer son propre GitLab nécessite un peu de connaissance mais on parle pas non plus de faire tourner une plateforme entière. Un cgit, hgweb, gotweb c'est aisé.
git is great because linus did it, mercurial is better because he didn't
Humans come first, machines second. The most simple and straightforward heuristic for whether a particular output stream (stdout or stderr) is being read by a human is whether or not it’s a TTY.
Je hais tous ces scripts qui mettent une tonne de couleur, de bannières, d'emojis, de symboles. Si seulement ces gens savaient que parfois ça finit dans des fichiers ou dans un | grep. Je vise personne
Make it easy to see the current state of the system. If your program does a lot of complex state changes and it is not immediately visible in the filesystem, make sure you make this easy to view.
Je suis étonné qu'ils choisissent git status comme example, le format de sortie est beaucoup trop verbeux comparé à un hg status ou son équivalent avec l'antédiluvien svn.
Use symbols and emoji where it makes things clearer.
Au secours, voir au dessus.
Use a pager (e.g. less) if you are outputting a lot of text.
Bah non. Je t'ai pas demandé de lancer un pager pour moi. Tu vas imprimer la documentation par défaut aussi ?
Bienvenue dans le monde moderne. Si on doit attendre que tout le monde soit prêt alors on fait du C++20 en 2040. Je chouine pas quand un projet demande une version récente de rust, soit je m'adapte soit je laisse tomber mais je blâme pas les développeurs qui prennent les outils disponibles. La volonté de s'adapter est propre à l'utilisateur. Sinon on innove jamais. Tout le monde criait au scandale quand on a enlevé les lecteurs de disquette spuis de CDs et maintenant plus grand monde en utilise. C'est pareil dans les langages, si on prend pas de parti pris on avance pas et je suis bien content qu'en C++17 on puisse enfin parcourir des répertoires avec la bibliothèque standard sans passer par boost ou une douzaine de #ifdef.
STL utilisée, et pour de mauvaises raisons en plus. La STL, c'est gros, c'est lent à compiler, c'est chiant a debugguer, le contrôle sur la mémoire est pénible. Certains par exemple y préférerons EASTL.
Ah donc quand on fait du C++ on doit pas utiliser la bibliothèque standard qui est implémentée nativement et optimisée sur chaque plateforme ? Pareil en C ? en C# ? en python ? en rust ?
Commentaire vivement subjectif.
git is great because linus did it, mercurial is better because he didn't
Est-ce réellement confortable un ordinateur de 11" ?
J'ai un thinkpad x1 carbon de 14" et un macbook pro de 13". Le thinkpad a une résolution QHD et un scaling x2 sur GNOME, franchement je suis à l'étroit. Même une fenêtre firefox avec gmail est ridiculeusement petite. Alors j'avoue que le côté transportable de mes deux laptops est cool comparé à mon t15 du travail mais je dois admettre que travailler une journée entière sur l'un des deux n'est pas agréable non plus.
git is great because linus did it, mercurial is better because he didn't
J'ai toujours trouvé ça beau et avant-gardiste, surtout les premières fois où je l'ai utilisé à mes débuts (~2003). Néanmoins après quelques minutes d'utilisations il y a toujours beaucoup de choses qui me déplaisent et non abouties, au final ça m'amuse que peu de temps.
Suivant des communautés comme r/unixporn, je ne vois quasiment jamais d'utilisation de ce WM, de plus avec wayland prenant le dessus je me demande quel est l'avenir de enlightenment.
git is great because linus did it, mercurial is better because he didn't
Pourtant 58Wh c'est beaucoup. Mon thinkpad x1 carbon 4 (2016) avait 11h d'autonomie lorsque je l'ai reçu. C'est un 14" avec un i7.
Bien entendu, beaucoup de paramètres entrent en compte. Mais 8h d'autonomie n'a rien d'exceptionnel pour un ordinateur sous Linux. Les rares fois où j'ai constaté de faibles autonomies, cela venait d'ordinateurs d'entrée de gammes.
À mon travail nous avons exclusivement des thinkpads, pas toujours les plus haut de gamme mais leur autonomies avoisinent toujours les 7-10h (Windows et/ou Linux).
git is great because linus did it, mercurial is better because he didn't
Utilise un outil different si ton outil est pas capable de faire des trucs de base
L'outil en question est une merge-request sur GitLab avec un écran 27". Je pense que quand le diff ne passe pas sur l'écran splité en deux c'est qu'il y a un vrai problème.
git is great because linus did it, mercurial is better because he didn't
Je pense qu'il n'y a aucune solution parfaite, de toute façon YMMV avec chaque spécificité des utilisateurs.
Pour ma part j'ai pas trop de problèmes bloquants. Ce que je peux constater en 2023 :
Sous X11 :
Mélanger les densité de pixel par écran reste compliqué (thinkpad ~100 DPI avec un écran 4k ~212 PPI).
Un peu de tearing par moment.
Sous wayland :
Lancer des compositeurs par le tty et le quitter me rend plus mon tty (l'écran reste noir) mais le système est toujours opérationnel, je peux taper des commandes à l'aveugle pour relancer.
Quelques problème d'intégration de la souris avec un VNC/qemu. Ça par contre, c'est embêtant. En plus, qemu indique dans la barre de titre un raccourci clavier pour désactiver l'intégration or GNOME indique un autre…
Un de mes collègues m'a fait une merge request comme ça, avec 9 niveaux d'indentation en mettant toute la logique dans un nouvel indent.
if(init==OK){if(open_partition()==OK){}}
Il ne comprend pas non plus pourquoi je demande à ce qu'on dépasse pas environ 100 colonnes dans le code. Bah… tout simplement parce que le diff la merge request ne passait pas verticalement avec toute cette indentation.
Le grand problème quand ce genre d'individu a toujours travaillé tout seul sans jamais regarder le code de quelqu'un d'autre ou d'un projet opensource.
git is great because linus did it, mercurial is better because he didn't
Wayland le sauveur, voilà qui est aussi téléphoné qu'ennuyeux !
Je suis d'accord, X11 c'est un bordel. Pour avoir commencé une distribution maison j'ai bien pesté face à l'inclusion des 300 millions de bibliothèques X11 (qui compile jamais sans un warning). Il y a des choses en double, on voit la dette technique.
Cependant, je trouve que wayland est aussi trop minimaliste. Aujourd'hui développer un compositeur from scratch nécessiterait de recoder la moitié du serveur X et donc d'ajouter possiblement un bug différent dans chaque. On pourrait dire « utilise wlroots » oui, peut-être mais il y a d'autres alternatives et ni GNOME ni KDE ne l'utilisent. Pour ma part je pense que c'est un poil trop minimaliste. Heureusement il reste tout de même des bibliothèque ayant un bon consensus général (comme libinput) mais pour la pile graphique et la gestion des sessions ça reste un peu compliqué. (cf. seat, elogind, libdrm, etc).
En tant que tel wayland est clairement le successeur de X11 mais il va apporter pas mal de complexité aussi, sans compter les DEs qui ne veulent pas supporter des choses courantes parce que ce sont des extensions de protocoles maison. Que va t'il se passer lorsque machin X implémente un protocole A et machin Y implémente a peu près la même chose mais sous un protocole B ?
git is great because linus did it, mercurial is better because he didn't
Concernant OpenBSD et sa philosophie, les choses avancent plutôt lentement et dans le sens « si ça marche, pas besoin de toucher » mais il est vrai que le FFS est particulièrement vieillissant et je serai pas contre une alternative. Cependant j'ai jamais vu trop de sujets sur tech@ ou misc@ à propos d'un nouveau FS, qu'en est-il ? Il y a t'il une chance que ce projet reste dans l'ombre ?
git is great because linus did it, mercurial is better because he didn't
Encore que l'enseigne au moins de l'extérieur est reconnaissable, mais va chercher des choses sur internet quand le nom existe déjà pour quelque chose.
téléviseur boulanger
boulanger « près de moi »
justin bieber X (au lieu de twitter)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à 3 (+1/-0).
Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des
#ifdefde partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à 1 (+0/-1).
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de
#ifdef/#endifdans son module natif et desifau runtime pour un module Lua.C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Barbant
Posté par David Demelier (site web personnel) . En réponse au lien Pour Linus Torvalds, voir toute cette hype sur l'IA c'est hilarant 🍿. Évalué à 7 (+5/-0).
Mandrake 10.0 ~2003/2004, pentium 4 et 512Mo de RAM à 14-15 ans donc. Oui j'ai connu et installé firefox 1.0, KDE 3.5, GNOME 2.8 (Fedora Core 3 ❤️) 🫠.
git is great because linus did it, mercurial is better because he didn't
# Quelle idée
Posté par David Demelier (site web personnel) . En réponse au lien Lunatik - Un framework pour scripter le noyau Linux avec Lua. Évalué à -1 (+1/-4).
Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
# Barbant
Posté par David Demelier (site web personnel) . En réponse au lien Pour Linus Torvalds, voir toute cette hype sur l'IA c'est hilarant 🍿. Évalué à 10 (+25/-0).
Je vais probablement passer pour un boomer mais tant pis.
J'ai atteint environ 1/3 de ma vie en âge et je dois admettre qu'après 20 ans dans le logiciel libre et le développement j'ai atteint un dégoût profond envers mon métier (je suis développeur) et la technologie en général.
À chaque fois que je regarde un produit il y a toujours quelque part un marketing "Vision" "AI ready" et autres termes inutiles.
Tout ce qui tourne autour de l'IA actuellement me donne des boutons. Certains de mes collègues utilisent ChatGPT pour répondre à des problèmes dans leur code, certains l'ont même utilisé pour me répondre à une question lors d'une merge-request. Non seulement j'ai trouvé ça particulièrement irrespectueux mais ça m'a encore plus questionné sur ce que nous sommes entrain de faire. Cet individu n'a soit pas eu envie de me répondre directement par ses propres mots soit pas compris ma question et s'est dit que ChatGPT allait me répondre à sa place. Le commentaire en question était à côté de la plaque et il ne répondait pas à ma question mais m'expliquait le morceau de code comme si j'avais aucune idée du contenu. Pour faire court, la merge request ajoutait du code pour faire une requête HTTP, le collègue a utilisé par erreur un entête content-type
application/x-www-form-urlencodedor la requête envoyait du JSON, on a demandé pourquoi il a mis ce content-type précisément et la réponse de ChatGPT m'expliquait à quoi sert un content-type (merci je connais HTTP).J'ai 20 ans de développement derrière moi, toutes mes connaissances sont acquises par l'investissement personnel, la lecture, les essais, les dents cassés, etc. Mais je sais ce que je fais dans les domaines où j'interviens. En ce moment je vois une recrudescence de collègues utilisant massivement ChatGPT au moindre problème sans même essayer d'y réfléchir et y trouver la solution. J'ai le sentiment qu'on tend vers la médiocrité croissante où le but final va être de faire un produit rapidement sans même allumer son cerveau. Tout le monde va finir par copier-coller des trucs par ci par là sans utiliser aucune des connaissances personnelles.
Ah et puis dans le côté musical, je préfère même pas commenter.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0).
Tu cites sourcehut qui est développé par une personne ayant un égo surdimensionné, en plus cette même personne préfère justement le développement/contributions par mail plutôt que par merge requests.
Pour ceux qui pensent aller sur sourcehut, je vous invite à prendre en compte que les fortes opinions de Drew peut vous risquer votre dépôt quand un jour il décidera que ce que vous y faites n'est pas éthique selon lui.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0).
Sur un point je suis d'accord ça facilite les contributions mais ne pas passer par GitHub ça permet aussi de s'affranchir des personnes qui ne veulent pas faire les efforts nécessaires ou recevoir des PRs qui n'ont aucun sens.
Certains projets populaires sont parfois spammés par des gens qui ne font même pas parti du projet dès qu'une PR ou un tickets GitHub est popularisé via un partage reddit/hn, etc. Donc on a des individus qui débarquent sur des projets où ils n'ont jamais été juste pour “I was here” ou coller un emoji quelconque.
Les CIs sont pratiques quand on veut fournir des projets continuellement, je pense par exemple à RetroArch qui fournit des binaires tous les jours ce qui est pratique pour les projets qui changent beaucoup, ce n'est pas mon cas. La seule CI qui pourrait me servir est de m'assurer que mes projets compilent sur toutes les plateformes avant de faire une release et ça je le fais plutôt manuellement avec plusieurs VMs locales. Je n'ai pas spécialement besoin de l'automatiser.
Mais comme je suis tout de même un gens sympa et raisonnable j'ai mis des miroirs GitHub de la plupart de mes projets.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 3 (+1/-0).
J'ai simplement dit que la configuration n'a pas changé, les mises à jour sont faites par le gestionnaire de paquets (aka
sysupgrade/pkg_add -udans mon cas).git is great because linus did it, mercurial is better because he didn't
[^] # Re: Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 2 (+0/-0). Dernière modification le 03 avril 2024 à 11:22.
Ma configuration Mercurial/nginx n'a pas changé depuis 2009. Après bien entendu installer son propre GitLab nécessite un peu de connaissance mais on parle pas non plus de faire tourner une plateforme entière. Un cgit, hgweb, gotweb c'est aisé.
git is great because linus did it, mercurial is better because he didn't
# Réaction de GitHub
Posté par David Demelier (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 10 (+9/-0).
GitHub a fermé le compte de Lasse Collin et les enregistrements DNS (xz.tukaani.org) Comme si Lasse était 100% responsable.
Voilà pourquoi je conseille à tout le monde d'héberger ses propres projets opensource.
git is great because linus did it, mercurial is better because he didn't
# Moui
Posté par David Demelier (site web personnel) . En réponse au lien Command Line Interface Guidelines. Évalué à 6 (+5/-1).
Je hais tous ces scripts qui mettent une tonne de couleur, de bannières, d'emojis, de symboles. Si seulement ces gens savaient que parfois ça finit dans des fichiers ou dans un
| grep. Je vise personneJe suis étonné qu'ils choisissent
git statuscomme example, le format de sortie est beaucoup trop verbeux comparé à unhg statusou son équivalent avec l'antédiluviensvn.Au secours, voir au dessus.
Bah non. Je t'ai pas demandé de lancer un pager pour moi. Tu vas imprimer la documentation par défaut aussi ?
Bonne chance, mais je soutiens l'idée.
Ça honnêtement, c'est pas ton problème. Tu utilises le gestionnaire de paquet ou des solutions existantes pour les autres systèmes.
Il y a du bon et du pas bon dans cet article mais il est trop subjectif.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Bof
Posté par David Demelier (site web personnel) . En réponse au lien AI Toolkit, donnez un cerveau à vos NPCs, une librairie C++ header-only. Évalué à 5.
Bienvenue dans le monde moderne. Si on doit attendre que tout le monde soit prêt alors on fait du C++20 en 2040. Je chouine pas quand un projet demande une version récente de rust, soit je m'adapte soit je laisse tomber mais je blâme pas les développeurs qui prennent les outils disponibles. La volonté de s'adapter est propre à l'utilisateur. Sinon on innove jamais. Tout le monde criait au scandale quand on a enlevé les lecteurs de disquette spuis de CDs et maintenant plus grand monde en utilise. C'est pareil dans les langages, si on prend pas de parti pris on avance pas et je suis bien content qu'en C++17 on puisse enfin parcourir des répertoires avec la bibliothèque standard sans passer par boost ou une douzaine de
#ifdef.Ah donc quand on fait du C++ on doit pas utiliser la bibliothèque standard qui est implémentée nativement et optimisée sur chaque plateforme ? Pareil en C ? en C# ? en python ? en rust ?
Commentaire vivement subjectif.
git is great because linus did it, mercurial is better because he didn't
# Confort ?
Posté par David Demelier (site web personnel) . En réponse au journal De la disparition du format « pas trop grand ». Évalué à 5.
Est-ce réellement confortable un ordinateur de 11" ?
J'ai un thinkpad x1 carbon de 14" et un macbook pro de 13". Le thinkpad a une résolution QHD et un scaling x2 sur GNOME, franchement je suis à l'étroit. Même une fenêtre firefox avec gmail est ridiculeusement petite. Alors j'avoue que le côté transportable de mes deux laptops est cool comparé à mon t15 du travail mais je dois admettre que travailler une journée entière sur l'un des deux n'est pas agréable non plus.
git is great because linus did it, mercurial is better because he didn't
# Qui utilise au quotidien ?
Posté par David Demelier (site web personnel) . En réponse au lien EFL 1.27 et Enlightenment 0.26.0 sont sortis. Évalué à 2.
J'ai toujours trouvé ça beau et avant-gardiste, surtout les premières fois où je l'ai utilisé à mes débuts (~2003). Néanmoins après quelques minutes d'utilisations il y a toujours beaucoup de choses qui me déplaisent et non abouties, au final ça m'amuse que peu de temps.
Suivant des communautés comme r/unixporn, je ne vois quasiment jamais d'utilisation de ce WM, de plus avec wayland prenant le dessus je me demande quel est l'avenir de enlightenment.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: CPU ?
Posté par David Demelier (site web personnel) . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 6.
Pourtant 58Wh c'est beaucoup. Mon thinkpad x1 carbon 4 (2016) avait 11h d'autonomie lorsque je l'ai reçu. C'est un 14" avec un i7.
Bien entendu, beaucoup de paramètres entrent en compte. Mais 8h d'autonomie n'a rien d'exceptionnel pour un ordinateur sous Linux. Les rares fois où j'ai constaté de faibles autonomies, cela venait d'ordinateurs d'entrée de gammes.
À mon travail nous avons exclusivement des thinkpads, pas toujours les plus haut de gamme mais leur autonomies avoisinent toujours les 7-10h (Windows et/ou Linux).
git is great because linus did it, mercurial is better because he didn't
# Bon débarras
Posté par David Demelier (site web personnel) . En réponse au lien Google-groups killed by Google \o/. Évalué à 6.
À chaque fois que je vois une communauté d'un projet opensource sur google groups je me dis que le projet est mort. Quelle plaie.
Vivement la fin de sourceforge tiens.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: return early pattern
Posté par David Demelier (site web personnel) . En réponse au journal La plus belle ligne de code. Évalué à 9.
L'outil en question est une merge-request sur GitLab avec un écran 27". Je pense que quand le diff ne passe pas sur l'écran splité en deux c'est qu'il y a un vrai problème.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas près d'arriver
Posté par David Demelier (site web personnel) . En réponse au journal Les distributions Linux abandonnent X11 pour Wayland. Évalué à 2.
Je pense qu'il n'y a aucune solution parfaite, de toute façon YMMV avec chaque spécificité des utilisateurs.
Pour ma part j'ai pas trop de problèmes bloquants. Ce que je peux constater en 2023 :
Sous X11 :
Sous wayland :
git is great because linus did it, mercurial is better because he didn't
[^] # Re: return early pattern
Posté par David Demelier (site web personnel) . En réponse au journal La plus belle ligne de code. Évalué à 7.
Un de mes collègues m'a fait une merge request comme ça, avec 9 niveaux d'indentation en mettant toute la logique dans un nouvel indent.
Il ne comprend pas non plus pourquoi je demande à ce qu'on dépasse pas environ 100 colonnes dans le code. Bah… tout simplement parce que le diff la merge request ne passait pas verticalement avec toute cette indentation.
Le grand problème quand ce genre d'individu a toujours travaillé tout seul sans jamais regarder le code de quelqu'un d'autre ou d'un projet opensource.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas près d'arriver
Posté par David Demelier (site web personnel) . En réponse au journal Les distributions Linux abandonnent X11 pour Wayland. Évalué à 2. Dernière modification le 25 septembre 2023 à 14:52.
Ce qui est compréhensible, l'architecture d'un compositeur wayland est tellement différente qu'il est difficile de réaliser un simple portage.
Il y avait way cooler (une réimplémentation totale, pas un portage) mais c'est finito.
git is great because linus did it, mercurial is better because he didn't
# Wayland oui mais pas parfait
Posté par David Demelier (site web personnel) . En réponse au journal Les distributions Linux abandonnent X11 pour Wayland. Évalué à 5.
Je suis d'accord, X11 c'est un bordel. Pour avoir commencé une distribution maison j'ai bien pesté face à l'inclusion des 300 millions de bibliothèques X11 (qui compile jamais sans un warning). Il y a des choses en double, on voit la dette technique.
Cependant, je trouve que wayland est aussi trop minimaliste. Aujourd'hui développer un compositeur from scratch nécessiterait de recoder la moitié du serveur X et donc d'ajouter possiblement un bug différent dans chaque. On pourrait dire « utilise wlroots » oui, peut-être mais il y a d'autres alternatives et ni GNOME ni KDE ne l'utilisent. Pour ma part je pense que c'est un poil trop minimaliste. Heureusement il reste tout de même des bibliothèque ayant un bon consensus général (comme libinput) mais pour la pile graphique et la gestion des sessions ça reste un peu compliqué. (cf. seat, elogind, libdrm, etc).
En tant que tel wayland est clairement le successeur de X11 mais il va apporter pas mal de complexité aussi, sans compter les DEs qui ne veulent pas supporter des choses courantes parce que ce sont des extensions de protocoles maison. Que va t'il se passer lorsque machin X implémente un protocole A et machin Y implémente a peu près la même chose mais sous un protocole B ?
git is great because linus did it, mercurial is better because he didn't
# Le pire
Posté par David Demelier (site web personnel) . En réponse au lien Les développeurs Mac orphelins. Évalué à 2.
C'est que Visual Studio était bien plus propre et intuitif sous mac que la version windows. Mais je plussoie l'inutilité de cet IDE sous macOS.
git is great because linus did it, mercurial is better because he didn't
# Est-ce que les devs OpenBSD sont intéressés ?
Posté par David Demelier (site web personnel) . En réponse au lien Le port de Hammer2 pour OpenBSD avance. Évalué à 2.
Concernant OpenBSD et sa philosophie, les choses avancent plutôt lentement et dans le sens « si ça marche, pas besoin de toucher » mais il est vrai que le FFS est particulièrement vieillissant et je serai pas contre une alternative. Cependant j'ai jamais vu trop de sujets sur tech@ ou misc@ à propos d'un nouveau FS, qu'en est-il ? Il y a t'il une chance que ce projet reste dans l'ombre ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Il y a pire
Posté par David Demelier (site web personnel) . En réponse au journal mais pourquoi s'appellent ils tous "OS"?. Évalué à 4.
Encore que l'enseigne au moins de l'extérieur est reconnaissable, mais va chercher des choses sur internet quand le nom existe déjà pour quelque chose.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je tente
Posté par David Demelier (site web personnel) . En réponse au journal Perles de C. Évalué à 4.
Petite astuce, cdecl
git is great because linus did it, mercurial is better because he didn't