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
En même temps si les projets suivent le semantic versioning ce n'est pas un problème. Les versions majeures de Gtk ne sont pas si fréquentes et c'est pas le problème des développeurs Gtk (ou tout projet) de se dire « cette version va tout casser en terme de compatibilité ». Si on reste bloqué à faire du rétro compatible éternellement on avance jamais et on peut pas nettoyer.
Les sauts entre les versions 2, 3 et 4 ont été bien assez longs pour ne pas frustrer les développeurs. Ce serait plus problématique s'ils faisaient des nouvelles versions majeures tous les ans.
En plus, Qt 4 et Gtk 2 sont encore utilisables (Gimp, hplip) c'est juste qu'il y a des fonctionnalités en moins comme wayland, la ultra haute résolution, etc…
git is great because linus did it, mercurial is better because he didn't
Ah effectivement au début je croyais que c'était une blague mais j'ai souvent vu des OpenBSD-istes parler de l'inutilité du bluetooth pour argumenter le retrait du code.
En revanche, je suis entièrement d'accord sur la qualité non-bloat d'OpenBSD.
git is great because linus did it, mercurial is better because he didn't
J'adore ta façon de voir les choses. « je n'ai pas besoin de ça je n'utilise pas ça donc c'est de la merde ».
Si ça te plait d'avoir 35 câbles sur ton bureau c'est bien. Moi j'apprécie d'avoir un clavier et une souris bluetooth d'une autonomie de 8 mois sur mon bureau et de la place pour mettre d'autres choses. J'apprécie aussi mes manettes 8BitDo pour jouer à mes jeux rétro préférés. J'apprécie aussi de pouvoir connecter mon téléphone à une enceinte bluetooth (ou Linux).
Et concernant la rapidité, j'ai une fois tenté l'expérience d'OpenBSD sur mon thinkpad « machine de guerre » et pourtant il n'y a qu'OpenBSD qui arrivait à faire saturer mon son en ouvrant des applications (à la manière d'un windows 98 qui n'arrive plus à suivre).
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
[^] # 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 17 décembre 2020 à 14:07.
Gtk 3 fonctionne sous Windows, le problème c'est que cela utilise le thème Adwaita par défaut et pour le coup c'est pas du tout « intégré ».
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é à 2.
En même temps si les projets suivent le semantic versioning ce n'est pas un problème. Les versions majeures de Gtk ne sont pas si fréquentes et c'est pas le problème des développeurs Gtk (ou tout projet) de se dire « cette version va tout casser en terme de compatibilité ». Si on reste bloqué à faire du rétro compatible éternellement on avance jamais et on peut pas nettoyer.
Les sauts entre les versions 2, 3 et 4 ont été bien assez longs pour ne pas frustrer les développeurs. Ce serait plus problématique s'ils faisaient des nouvelles versions majeures tous les ans.
En plus, Qt 4 et Gtk 2 sont encore utilisables (Gimp, hplip) c'est juste qu'il y a des fonctionnalités en moins comme wayland, la ultra haute résolution, etc…
git is great because linus did it, mercurial is better because he didn't
[^] # Re: moi c'est l'inverse
Posté par David Demelier (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 2.
FreeBSD n'a pas de support bluetooth A2DP. PC-BSD n'existe plus par contre.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: moi c'est l'inverse
Posté par David Demelier (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Ah effectivement au début je croyais que c'était une blague mais j'ai souvent vu des OpenBSD-istes parler de l'inutilité du bluetooth pour argumenter le retrait du code.
En revanche, je suis entièrement d'accord sur la qualité non-bloat d'OpenBSD.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: moi c'est l'inverse
Posté par David Demelier (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
J'adore ta façon de voir les choses. « je n'ai pas besoin de ça je n'utilise pas ça donc c'est de la merde ».
Si ça te plait d'avoir 35 câbles sur ton bureau c'est bien. Moi j'apprécie d'avoir un clavier et une souris bluetooth d'une autonomie de 8 mois sur mon bureau et de la place pour mettre d'autres choses. J'apprécie aussi mes manettes 8BitDo pour jouer à mes jeux rétro préférés. J'apprécie aussi de pouvoir connecter mon téléphone à une enceinte bluetooth (ou Linux).
Et concernant la rapidité, j'ai une fois tenté l'expérience d'OpenBSD sur mon thinkpad « machine de guerre » et pourtant il n'y a qu'OpenBSD qui arrivait à faire saturer mon son en ouvrant des applications (à la manière d'un windows 98 qui n'arrive plus à suivre).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: moi c'est l'inverse
Posté par David Demelier (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3. Dernière modification le 10 décembre 2020 à 13:23.
Exit le bluetooth, le trim SSD, la rapidité et wayland.
git is great because linus did it, mercurial is better because he didn't