Je le connais un peu car il est parmi les anciens contributeurs de la distribution Alpine dont je suis aussi contributeur.
Loin de moi l'idée de vouloir le dénigrer mais j'ai du mal avec sa façon de faire.
Il réinvente la roue pour beaucoup de choses et nous les impose par après. Chez Alpine il a voulu mettre en place son système de mailing list assez mauvais (peu personnalisable et quelques problèmes) et a décidé de partir dès lors qu'on a dit qu'on l'utiliserait plus pour contribuer. Il n'aime pas les manpage alors il a écrit son propre format bien plus minimaliste et largement pas assez flexible pour écrire des pages de qualité. Devinez quoi, il l'a mis en place dans les pages de manuel du gestionnaire de paquet apk. Cela signifie qu'en tant que nouveau contributeur, au lieu de pouvoir contribuer à quelque chose que vous connaissez, vous devez apprendre un nouveau format pour une seule et unique personne à cause du syndrome NIH. Il a aussi des opinions personnelles assez fortes et vous empêches littéralement de faire autrement (essayez d'envoyer un mail HTML sur Alpine ou avec une petite pièce jointe, vous allez être renvoyé vers une de ces pages perso. Il n'aime pas nvidia (oui nvidia c'est mal), mais ce n'est pas non plus obligatoire de faire pression sur ceux qui en ont une. C'est vrai que les deux cas sont à proscrire sur une ML mais bon). Quelques recherches sur HN/Reddit vous en dira un peu plus à son sujet.
Pour moi ce langage n'est qu'un énième syndrome NIH dont il est atteint alors comme il n'aime pas Rust, C++, Go ou autre langage moderne et ben… il en écrit un nouveau. Ainsi, ce dont j'ai à lui reprocher se répercutera sur son énième projet.
git is great because linus did it, mercurial is better because he didn't
Ils ont beaucoup de datacenter. Celui de Strasbourg n'est toujours pas rétabli (ils migrent vers Gravelines si j'ai bien compris). J'ai un dédié à Roubaix (bien accessible) mais mon VPS de Strasbourg est bien mort pour le moment.
En plus depuis hier je me disais qu'il était temps qu'un jour je fasse une copie de mes sauvegardes à la maison (mes laptops et mon NAS) sur un VPS ou un serveur de stockage car je me suis dit que je ne suis pas à l'abri d'un incendie ou cambriolage à la maison…
Comble du sort, bien que je fasse des backups de mon dédié, j'ai jamais encore pris la peine de faire un backup de mon VPS (car c'est juste un petit blog et un shell permanent). Mais bon là je peux m'en prendre qu'à moi même.
git is great because linus did it, mercurial is better because he didn't
Joli bug destructeur en effet. Heureusement avec une portée limitée, plus grand monde n'utilise de fichier de swap aujourd'hui et probablement encore moins une RC du noyau Linux (même si elles ont tendance à être solides comme le rappel également Linus).
Pourtant moi je trouve que c'est la meilleure solution. Au lieu d'avoir une partition swap d'une taille arbitraire, on pourrait créer des fichiers swap à la volée quand le système en a besoin comme macOS fait (et Windows).
Le seul problème, c'est qu'il faudrait que ce soit géré par le kernel lui même sans doute.
git is great because linus did it, mercurial is better because he didn't
J'avoue avoir très envie de savoir ce qui a été utilisé car c'est vraiment de très bonne qualité.
Je fais aussi de la musique et j'ai bien longtemps essayé d'utiliser ardour et quelques plugins comme calf, caps mais j'étais vraiment limité sans compter un nombre incalculable de bugs et crash d'ardour (bon j'avoue je l'utilise sous Alpine dont je suis le mainteneur) et aussi la complexité de mise en place avec Jack et le partage de carte son pour faire tourner ardour et d'autres logiciels (tuxguitar, etc).
Enfin bref, j'ai vendu mon âme au diable et acquis un petit MacBook pour faire de la MAO sous Logic Pro X et je dois avouer que malheureusement la MAO sous Linux est tout de même encore à des kms. J'ose espérer que ça puisse s'améliorer mais avec les éditeurs de plugins comme Native Instruments qui font que des VST (et pas de lv2 ni ladspa) je pense qu'on sera malheureusement toujours en retard. Idem pour ma carte son (une Focusrite 4i4) qui n'est pas configurable sans un logiciel propriétaire uniquement disponible sous macOS/Windows.
À mon avis le “year of the Linux on desktop” est plus proche que “year of the MAO on Linux”.
Mais comme diraient certains ”use the appropriate tool for the job”.
git is great because linus did it, mercurial is better because he didn't
Moi j'ai la Pocketbook Touch Lux 3. Elle est un peu âgée mais fonctionne toujours. Elle a une autonomie démentielle aussi quand on utilise pas la luminosité. Elle a le wifi, un jeu d'échec et en plus tourne sous des logiciels libres !
Mais réellement je m'en sers assez peu car comme j'en avais déjà parlé sur un autre journal, les DRMs dans les livres c'est mort pour ma part et des DRMs free il y en a peu.
git is great because linus did it, mercurial is better because he didn't
Bof, comme d'habitude il est atteint de la surconception connu de chez Boost. L'API de nlohmann-json est bien plus facile. En revanche son implémentation et sa quantité de fonctionnalités annexe est similaire à une centrale à charbon, ce n'est plus un parseur JSON mais un véritable framework. Dommage.
beast pour faire des clients et serveurs http mieux qu'en Node.js ;
Désolé mais ce n'est pas le cas. J'ai déjà essayé et c'est tellement bas niveau que tu perds plus de temps à écrire le code de gestion HTTP que de coder ton application. Node.js n'est pas mieux, mais Beast n'est clairement pas mieux que Node.js non plus. En plus, son auteur est particulièrement égocentrique.
smart_ptr pour être plus memory safe que Rust tout en gardant un langage plus simple et portable;
Les smart pointers existent en standard depuis C++11, aucunement besoin de Boost.
git is great because linus did it, mercurial is better because he didn't
Faudrait expliquer pourquoi ces deux langages n'ont rien en commun. Et pourquoi Go serait inutile (c'est un troll mais bon).
Go est inutile parce que :
Il n'apporte absolument rien, c'est une sorte de Java simple. Au moins Rust suit les langages modernes en fournissant des syntaxes puissantes comme le pattern matching.
Il a un GC, il existe des techniques de programmation qui font qu'il est tout simplement plus nécessaire d'en avoir un dorénavant.
Il supporte les pointeurs du style void * comme en C.
Les développeurs laissent pourrir des problèmes et n'écoutent pas la communauté.
Go est écrit en Go, ce qui rend sa compilation sur des nouvelles plateformes pénible. C'est dingue cette obsession de développer quelque chose puis d'en faire un logiciel self-hosted.
Pas de gestion de RAII propre, il faut faire des defer à tout va.
Toujours pas de généricité type-safe (c'est en cours seulement).
Il y a encore plein d'autres raisons que tu peux trouver sur les moteurs de recherche. Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
git is great because linus did it, mercurial is better because he didn't
Ce qui m'énerve le plus en ce moment sur reddit et HN, ce sont les gens qui peuvent pas s'empêcher de “why didn't you write it in Rust” à chaque fois que quelqu'un présente un nouveau projet.
git is great because linus did it, mercurial is better because he didn't
Autant j'aime pas Rust, autant conseiller Go plutôt que Rust est plutôt culotté. Ceux deux langages n'ont absolument rien en commun. Rust est un mix entre C et C++ ultra type safe. Go est… inutile.
git is great because linus did it, mercurial is better because he didn't
Un truc qui m'a toujours semblé un peu une mauvaise idée (d'un point de vue maintenance) dans lua et que tu ne mentionnes pas, c'est le fait que les variables sont globales par défaut et qu'il faut utiliser local, plutôt que le comportement inverse (un global à la Tcl ou Python).
Oui c'est vrai je l'avais oublié. Pour ma part j'ai rarement été affecté par ce choix de décision donc je dois avouer que ça ne m'a pas dérangé tant que ça mais je peux le comprendre.
Le goto est une version très restreinte (un peu comme en Go, c'est un goto sans vraiment l'être), donc qui évite les cas vraiment problématiques qui lui valent une mauvaise réputation, non ?
C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme setjmp et il n'est pas possible de stocker des labels de goto non plus. Je pense que ça aurait pu avoir un quelconque intérêt de rajouter les goto si les labels étaient des objets de première classe.
Pour le coup, ça c'est assez compréhensible pour un langage qui se veut petit et d'extension : un moteur d'expression régulières un peu moderne représenterait probablement autant de code que le reste de l'interpréteur, et un moteur trop simpliste donnerait de mauvaises performances.
Oui c'est ce qu'ils ont indiqué dans leur livre. Mais utiliser un format spécial plutôt que rester proche des vrai regex fait qu'on doive apprendre une nouvelle syntaxe quand même. Bon l'avantage est qu'il n'y pas besoin de faire des échappement du style \d -> \\d comme en C.
git is great because linus did it, mercurial is better because he didn't
Je suis l'auteur original du binding Lua-SDL2, je l'ai commencé globalement quand Lua 5.2 est sorti et donc j'ai rajouté de la compatibilité pour Lua 5.1 et pour Lua 5.3 et pour Lua 5.4.
Les 3 développeurs (parce que Lua n'accepte pas les patchs ni les contributeurs externes) cassent l'API C et l'API Lua à chaque version sans aucun guide précis de migration et comme il n'y a pas de SCM public, vous perdez un temps fou à la sortie d'une nouvelle version pour mettre à jour vos modules et rajouter une trentaine de #ifdef de compatibilité. D'ailleurs, c'est bien pour ça que même les modules connus comme LuaSocket étaient pendant très longtemps en retard sur les nouvelles versions et de manière générale c'est souvent le cas pour les autres modules. Malgré cela beaucoup continuent d'utiliser ce langage est finissent emprisonnés par ce problème. La solution la plus adéquate : embarquer une version du langage dans votre logiciel puis fournir la documentation de cette version précise et espérer que personne ne s'en plaigne. Exemple : löve est toujours basé sur du Lua 5.1 (parce que LuaJIT est encore sur du 5.1)
J'ai beaucoup aimé Lua au début mais avec l'émergence d'ECMAScript 6 et versions ultérieures qui font Javascript un bien meilleur langage qu'auparavant; je ne comprends pas l'intérêt de continuer un langage qui n'offre plus grand chose à part des inconvénients majeurs.
À part ça, il y a beaucoup de choses qui sont bizarres et sont choisies arbitrairement :
La syntaxe du non-égal est ~=, dans la plupart des cas on considère ça comme « approximativement égal ».
Les développeurs sont fortement contre l'ajout du mot clé continue, alors ils ont rajouté le terrible goto. Par contre break existe.
Les tableaux commencent à 1. Oui il est possible d'utiliser un tableau avec un indice de 0, voire -1 mais l'API Lua ne fonctionnera pas avec.
Mélanger les structures clé-valeur avec les tableau dans la même syntaxe est une bonne chose sur le papier, mais dans la réalité c'est plutôt merdique (voir # et tableaux à trous).
Pas d'expression régulière, mais un format maison bien plus limité.
Pas de fonctionnalité modernes comme le pattern matching ni de switch case amélioré.
Les chaînes sont des « objets », mais pas les tableaux.
Je ne peux que conseiller de bien réfléchir avant d'utiliser Lua, à moins que perdre votre temps ou utiliser 3 versions de retard ne vous rebute pas.
git is great because linus did it, mercurial is better because he didn't
Je me demande si des gens prennent vraiment du plaisir à argumenter contre des complotistes. Pour moi c'est une perte de temps monumentale. Quand ma voisine commence à me parler de vaccins je coupe directement la discussion disant que je dois partir.
Pas de stress, pas de perte de temps.
git is great because linus did it, mercurial is better because he didn't
J'ai un thinkpad x1 carbon et j'avoue adorer la qualité de frappe du clavier. J'ai aussi un MacBook Pro 2020 et je dois avouer que le touchpad est du pur bonheur. Depuis, je n'utilise plus du tout le trackpoint du thinkpad.
git is great because linus did it, mercurial is better because he didn't
Je suis développeur et dans mes différentes expériences professionnelles je n'ai jamais rencontré de consommateur. D'ailleurs j'ai aussi remarqué que les fumeurs en règle générale étaient bien moins fréquent que lorsque j'ai travaillé comme préparateur de commande pour une grande enseigne où là bien la moitié des employés étaient fumeurs.
git is great because linus did it, mercurial is better because he didn't
Loin de moi l'idée d'être rabat joie mais en quoi un économiseur d'écran est il encore utile aujourd'hui ? GNOME n'en a plus, les téléphones n'en ont pas, de base Windows n'en a pas non plus (si je me souviens bien) et il n'y a que macOS qui daigne encore en activer un par défaut.
À l'heure où de plus en plus de machines personnelles deviennent des portables, on préfère largement l'autonomie et mettre en veille plutôt qu'admirer une courbe de Bezier se dessiner.
Du coup ma question est : qui utilise encore un écran de veille de son plein gré actuellement ?
git is great because linus did it, mercurial is better because he didn't
Si ça se trouve les APIs cassées de la nouvelle version touche des modules peu utilisées ou sont mêmes en très peu nombre. Si ça se trouve, une application Gtk ultra basique en Gtk 3 compile même déjà en Gtk 4 sans aucune modification.
Surtout que Gtk est développée en même temps que GNOME et toutes ses applications alors je doute fort qu'ils s'amusent à tout casser juste pour « tout casser » parce que là ils se tireraient une balle dans le pied gratuitement.
git is great because linus did it, mercurial is better because he didn't
Oui et tu imagines le nombre de différentes versions qu'on aurait dans les dépôts parce que certains projets n'ont pas le temps ni l'envie de migrer tout de suite à une version majeure ?
Il y a juste à voir le bordel de nodejs et leur version majeure tous les ans, c'est simple presque personne n'installe node depuis les dépôts mais utilise des outils annexes (comme nvm) pour avoir 25 versions de node sur son système.
git is great because linus did it, mercurial is better because he didn't
Je ne peux que plussoir. Surtout que tar est loin d'être un programme instable. Pour ma part pour n'importe quelle implémentation que j'ai testée (GNU coreutils, BSD, libarchive) jamais eu un seul crash.
Rust permet de faire du code plus sûr « par défaut » mais si on utilises les bon outils (sanitizers, linter, warnings au max, tests excessifs) on peut aussi s'affranchir de pas mal de bugs stupide en C et C++.
git is great because linus did it, mercurial is better because he didn't
# Drew ? J'ai un peu du mal avec ce type
Posté par David Demelier (site web personnel) . En réponse au journal Appel à contribution pour un nouveau langage !. Évalué à 10. Dernière modification le 25 mars 2021 à 11:24.
Je le connais un peu car il est parmi les anciens contributeurs de la distribution Alpine dont je suis aussi contributeur.
Loin de moi l'idée de vouloir le dénigrer mais j'ai du mal avec sa façon de faire.
Il réinvente la roue pour beaucoup de choses et nous les impose par après. Chez Alpine il a voulu mettre en place son système de mailing list assez mauvais (peu personnalisable et quelques problèmes) et a décidé de partir dès lors qu'on a dit qu'on l'utiliserait plus pour contribuer. Il n'aime pas les manpage alors il a écrit son propre format bien plus minimaliste et largement pas assez flexible pour écrire des pages de qualité. Devinez quoi, il l'a mis en place dans les pages de manuel du gestionnaire de paquet apk. Cela signifie qu'en tant que nouveau contributeur, au lieu de pouvoir contribuer à quelque chose que vous connaissez, vous devez apprendre un nouveau format pour une seule et unique personne à cause du syndrome NIH. Il a aussi des opinions personnelles assez fortes et vous empêches littéralement de faire autrement (essayez d'envoyer un mail HTML sur Alpine ou avec une petite pièce jointe, vous allez être renvoyé vers une de ces pages perso. Il n'aime pas nvidia (oui nvidia c'est mal), mais ce n'est pas non plus obligatoire de faire pression sur ceux qui en ont une. C'est vrai que les deux cas sont à proscrire sur une ML mais bon). Quelques recherches sur HN/Reddit vous en dira un peu plus à son sujet.
Pour moi ce langage n'est qu'un énième syndrome NIH dont il est atteint alors comme il n'aime pas Rust, C++, Go ou autre langage moderne et ben… il en écrit un nouveau. Ainsi, ce dont j'ai à lui reprocher se répercutera sur son énième projet.
git is great because linus did it, mercurial is better because he didn't
# Digital
Posté par David Demelier (site web personnel) . En réponse au lien Comment dit-on en français data science, backdoor, digital..? - france inter. Évalué à 6. Dernière modification le 10 mars 2021 à 09:51.
Ça fait des années que je lutte contre digital, mais il est déjà présent dans l'académie française depuis un moment :
http://academie-francaise.fr/digital
Malgré ça, beaucoup de gens de mauvaise foi continuent de m'argumenter que c'est tout à fait tolérable.
git is great because linus did it, mercurial is better because he didn't
# Toujours down à Strasbourg
Posté par David Demelier (site web personnel) . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 8. Dernière modification le 10 mars 2021 à 09:47.
Ils ont beaucoup de datacenter. Celui de Strasbourg n'est toujours pas rétabli (ils migrent vers Gravelines si j'ai bien compris). J'ai un dédié à Roubaix (bien accessible) mais mon VPS de Strasbourg est bien mort pour le moment.
En plus depuis hier je me disais qu'il était temps qu'un jour je fasse une copie de mes sauvegardes à la maison (mes laptops et mon NAS) sur un VPS ou un serveur de stockage car je me suis dit que je ne suis pas à l'abri d'un incendie ou cambriolage à la maison…
Comble du sort, bien que je fasse des backups de mon dédié, j'ai jamais encore pris la peine de faire un backup de mon VPS (car c'est juste un petit blog et un shell permanent). Mais bon là je peux m'en prendre qu'à moi même.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dans la langue de Jean-Baptiste Poquelin
Posté par David Demelier (site web personnel) . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 3.
La taille des disques ? Les ultrabooks avec NVMe ont rarement des très grandes tailles (on est plutôt sur du 256Go/512Go).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Dans la langue de Jean-Baptiste Poquelin
Posté par David Demelier (site web personnel) . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 5.
Pourtant moi je trouve que c'est la meilleure solution. Au lieu d'avoir une partition swap d'une taille arbitraire, on pourrait créer des fichiers swap à la volée quand le système en a besoin comme macOS fait (et Windows).
Le seul problème, c'est qu'il faudrait que ce soit géré par le kernel lui même sans doute.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Puisqu'on est sur linuxfr...
Posté par David Demelier (site web personnel) . En réponse au journal Sortie de mon premier album de musique libre : Flammes. Évalué à 6. Dernière modification le 02 mars 2021 à 14:36.
J'avoue avoir très envie de savoir ce qui a été utilisé car c'est vraiment de très bonne qualité.
Je fais aussi de la musique et j'ai bien longtemps essayé d'utiliser ardour et quelques plugins comme calf, caps mais j'étais vraiment limité sans compter un nombre incalculable de bugs et crash d'ardour (bon j'avoue je l'utilise sous Alpine dont je suis le mainteneur) et aussi la complexité de mise en place avec Jack et le partage de carte son pour faire tourner ardour et d'autres logiciels (tuxguitar, etc).
Enfin bref, j'ai vendu mon âme au diable et acquis un petit MacBook pour faire de la MAO sous Logic Pro X et je dois avouer que malheureusement la MAO sous Linux est tout de même encore à des kms. J'ose espérer que ça puisse s'améliorer mais avec les éditeurs de plugins comme Native Instruments qui font que des VST (et pas de lv2 ni ladspa) je pense qu'on sera malheureusement toujours en retard. Idem pour ma carte son (une Focusrite 4i4) qui n'est pas configurable sans un logiciel propriétaire uniquement disponible sous macOS/Windows.
À mon avis le “year of the Linux on desktop” est plus proche que “year of the MAO on Linux”.
Mais comme diraient certains ”use the appropriate tool for the job”.
git is great because linus did it, mercurial is better because he didn't
# Pocketbook
Posté par David Demelier (site web personnel) . En réponse au journal Liseuse, recherche conseils et retours d'expérience. Évalué à 8.
Moi j'ai la Pocketbook Touch Lux 3. Elle est un peu âgée mais fonctionne toujours. Elle a une autonomie démentielle aussi quand on utilise pas la luminosité. Elle a le wifi, un jeu d'échec et en plus tourne sous des logiciels libres !
Mais réellement je m'en sers assez peu car comme j'en avais déjà parlé sur un autre journal, les DRMs dans les livres c'est mort pour ma part et des DRMs free il y en a peu.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quel est le problème ?
Posté par David Demelier (site web personnel) . En réponse au lien Le cauchemar de l'empaquetage: côté distrib. Évalué à 3.
C'est un problème avec n'importe quel langage même non-compilé.
Exemple, si ton application fournit un module python lui même au lieu de réutiliser celui du système le problème est le même.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pinning
Posté par David Demelier (site web personnel) . En réponse au lien Le cauchemar de l'empaquetage: côté distrib. Évalué à 8.
J'ai très hâte de savoir en quoi le C est obsolète.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Boost ? À réfléchir avant d'utiliser
Posté par David Demelier (site web personnel) . En réponse au journal Des nouvelles de boost. Évalué à 4. Dernière modification le 24 février 2021 à 08:39.
Je crois que tu n'as pas lu la bonne personne. Il est venu demander sur le projet Duktape de changer la licence MIT parce qu'il ne l'aime pas.
L'auteur de Boost.Beast est Vinnie Falco, pas Sami Svaarala (qui lui au passage est une personne formidable).
git is great because linus did it, mercurial is better because he didn't
# Boost ? À réfléchir avant d'utiliser
Posté par David Demelier (site web personnel) . En réponse au journal Des nouvelles de boost. Évalué à 4.
Bof, comme d'habitude il est atteint de la surconception connu de chez Boost. L'API de nlohmann-json est bien plus facile. En revanche son implémentation et sa quantité de fonctionnalités annexe est similaire à une centrale à charbon, ce n'est plus un parseur JSON mais un véritable framework. Dommage.
Désolé mais ce n'est pas le cas. J'ai déjà essayé et c'est tellement bas niveau que tu perds plus de temps à écrire le code de gestion HTTP que de coder ton application. Node.js n'est pas mieux, mais Beast n'est clairement pas mieux que Node.js non plus. En plus, son auteur est particulièrement égocentrique.
Les smart pointers existent en standard depuis C++11, aucunement besoin de Boost.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 3.
Go est inutile parce que :
void *comme en C.deferà tout va.Il y a encore plein d'autres raisons que tu peux trouver sur les moteurs de recherche. Celles que j'ai citées sont celles qui me feront jamais utiliser ce langage.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 2.
C'est vrai, je suis assez d'accord.
Ce qui m'énerve le plus en ce moment sur reddit et HN, ce sont les gens qui peuvent pas s'empêcher de “why didn't you write it in Rust” à chaque fois que quelqu'un présente un nouveau projet.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pourquoi Rust ?
Posté par David Demelier (site web personnel) . En réponse au lien Rewrite it in Rust : au delà du meme (Google finance la réécriture en Rust de certains logiciels lib. Évalué à 0.
Autant j'aime pas Rust, autant conseiller Go plutôt que Rust est plutôt culotté. Ceux deux langages n'ont absolument rien en commun. Rust est un mix entre C et C++ ultra type safe. Go est… inutile.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas vraiment
Posté par David Demelier (site web personnel) . En réponse au lien Lua, un langage incompris.. Évalué à 3.
Oui c'est vrai je l'avais oublié. Pour ma part j'ai rarement été affecté par ce choix de décision donc je dois avouer que ça ne m'a pas dérangé tant que ça mais je peux le comprendre.
C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme
setjmpet il n'est pas possible de stocker des labels de goto non plus. Je pense que ça aurait pu avoir un quelconque intérêt de rajouter les goto si les labels étaient des objets de première classe.Oui c'est ce qu'ils ont indiqué dans leur livre. Mais utiliser un format spécial plutôt que rester proche des vrai regex fait qu'on doive apprendre une nouvelle syntaxe quand même. Bon l'avantage est qu'il n'y pas besoin de faire des échappement du style
\d->\\dcomme en C.git is great because linus did it, mercurial is better because he didn't
# Pas vraiment
Posté par David Demelier (site web personnel) . En réponse au lien Lua, un langage incompris.. Évalué à 10. Dernière modification le 14 février 2021 à 09:25.
Je suis l'auteur original du binding Lua-SDL2, je l'ai commencé globalement quand Lua 5.2 est sorti et donc j'ai rajouté de la compatibilité pour Lua 5.1 et pour Lua 5.3 et pour Lua 5.4.
Les 3 développeurs (parce que Lua n'accepte pas les patchs ni les contributeurs externes) cassent l'API C et l'API Lua à chaque version sans aucun guide précis de migration et comme il n'y a pas de SCM public, vous perdez un temps fou à la sortie d'une nouvelle version pour mettre à jour vos modules et rajouter une trentaine de
#ifdefde compatibilité. D'ailleurs, c'est bien pour ça que même les modules connus comme LuaSocket étaient pendant très longtemps en retard sur les nouvelles versions et de manière générale c'est souvent le cas pour les autres modules. Malgré cela beaucoup continuent d'utiliser ce langage est finissent emprisonnés par ce problème. La solution la plus adéquate : embarquer une version du langage dans votre logiciel puis fournir la documentation de cette version précise et espérer que personne ne s'en plaigne. Exemple : löve est toujours basé sur du Lua 5.1 (parce que LuaJIT est encore sur du 5.1)J'ai beaucoup aimé Lua au début mais avec l'émergence d'ECMAScript 6 et versions ultérieures qui font Javascript un bien meilleur langage qu'auparavant; je ne comprends pas l'intérêt de continuer un langage qui n'offre plus grand chose à part des inconvénients majeurs.
À part ça, il y a beaucoup de choses qui sont bizarres et sont choisies arbitrairement :
continue, alors ils ont rajouté le terriblegoto. Par contrebreakexiste.#et tableaux à trous).Je ne peux que conseiller de bien réfléchir avant d'utiliser Lua, à moins que perdre votre temps ou utiliser 3 versions de retard ne vous rebute pas.
git is great because linus did it, mercurial is better because he didn't
# Perdre son temps ?
Posté par David Demelier (site web personnel) . En réponse au lien Comment argumenter face à des complotistes ?. Évalué à 7.
Je me demande si des gens prennent vraiment du plaisir à argumenter contre des complotistes. Pour moi c'est une perte de temps monumentale. Quand ma voisine commence à me parler de vaccins je coupe directement la discussion disant que je dois partir.
Pas de stress, pas de perte de temps.
git is great because linus did it, mercurial is better because he didn't
# La première violation de GPL
Posté par David Demelier (site web personnel) . En réponse à la dépêche Histoire de l'Objective-C et décès de son créateur. Évalué à 10.
On notera par ailleurs que l'extension de GCC pour supporter l'objective C a été la première violation de la licence GPL.
git is great because linus did it, mercurial is better because he didn't
# Au début oui
Posté par David Demelier (site web personnel) . En réponse au journal Le trackpoint sur les thinkpad…. Évalué à 2.
J'ai un thinkpad x1 carbon et j'avoue adorer la qualité de frappe du clavier. J'ai aussi un MacBook Pro 2020 et je dois avouer que le touchpad est du pur bonheur. Depuis, je n'utilise plus du tout le trackpoint du thinkpad.
git is great because linus did it, mercurial is better because he didn't
# J'aurais pensé l'inverse
Posté par David Demelier (site web personnel) . En réponse au lien LEs informaticiens ans le top10 des fumeurs de oinj. Évalué à 4.
Je suis développeur et dans mes différentes expériences professionnelles je n'ai jamais rencontré de consommateur. D'ailleurs j'ai aussi remarqué que les fumeurs en règle générale étaient bien moins fréquent que lorsque j'ai travaillé comme préparateur de commande pour une grande enseigne où là bien la moitié des employés étaient fumeurs.
git is great because linus did it, mercurial is better because he didn't
# Utilité d'un screensaver en 2021 ?
Posté par David Demelier (site web personnel) . En réponse au lien sortie de XScreenSaver 5.45: support (douloureux?) de systemd. Évalué à 6.
Loin de moi l'idée d'être rabat joie mais en quoi un économiseur d'écran est il encore utile aujourd'hui ? GNOME n'en a plus, les téléphones n'en ont pas, de base Windows n'en a pas non plus (si je me souviens bien) et il n'y a que macOS qui daigne encore en activer un par défaut.
À l'heure où de plus en plus de machines personnelles deviennent des portables, on préfère largement l'autonomie et mettre en veille plutôt qu'admirer une courbe de Bezier se dessiner.
Du coup ma question est : qui utilise encore un écran de veille de son plein gré actuellement ?
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Portabilité ?
Posté par David Demelier (site web personnel) . En réponse au lien Scoop : GTK+2 is dead ! (ha oui, et GTK4 est sorti). Évalué à 3. Dernière modification le 18 décembre 2020 à 19:01.
Tu es vraiment défaitiste.
Si ça se trouve les APIs cassées de la nouvelle version touche des modules peu utilisées ou sont mêmes en très peu nombre. Si ça se trouve, une application Gtk ultra basique en Gtk 3 compile même déjà en Gtk 4 sans aucune modification.
Surtout que Gtk est développée en même temps que GNOME et toutes ses applications alors je doute fort qu'ils s'amusent à tout casser juste pour « tout casser » parce que là ils se tireraient une balle dans le pied gratuitement.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Portabilité ?
Posté par David Demelier (site web personnel) . En réponse au lien Scoop : GTK+2 is dead ! (ha oui, et GTK4 est sorti). Évalué à 3. Dernière modification le 18 décembre 2020 à 10:18.
Oui et tu imagines le nombre de différentes versions qu'on aurait dans les dépôts parce que certains projets n'ont pas le temps ni l'envie de migrer tout de suite à une version majeure ?
Il y a juste à voir le bordel de nodejs et leur version majeure tous les ans, c'est simple presque personne n'installe node depuis les dépôts mais utilise des outils annexes (comme nvm) pour avoir 25 versions de node sur son système.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Fanboy rouillé
Posté par David Demelier (site web personnel) . En réponse au lien Un remplaçant au tar.gz fait par l'ANSSI. Évalué à 3.
Je ne peux que plussoir. Surtout que tar est loin d'être un programme instable. Pour ma part pour n'importe quelle implémentation que j'ai testée (GNU coreutils, BSD, libarchive) jamais eu un seul crash.
Rust permet de faire du code plus sûr « par défaut » mais si on utilises les bon outils (sanitizers, linter, warnings au max, tests excessifs) on peut aussi s'affranchir de pas mal de bugs stupide en C et C++.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Zstandard
Posté par David Demelier (site web personnel) . En réponse au lien Un remplaçant au tar.gz fait par l'ANSSI. Évalué à 4.
Exact, tar c'est un format d'archivage. gz c'est une compression. Deux choses bien distinctes. On peut effectivement faire des .tar.zst aussi.
Ce projet semble être une alternative justement à faire les deux en même temps et en rajoutant du chiffrement (ce que tar ne sait pas faire).
git is great because linus did it, mercurial is better because he didn't