David Delassus a écrit 761 commentaires

Tant qu'a générer du Rust, tu peux aussi utiliser des macro procédurale.

Idée intéressante, mais je trouve qu'utiliser des templates est moins capilo-tracté que manipuler le TokenStream de Rust. J'ai jamais réussi à faire ce que je veux avec les macros de Rust, je les trouve atroces.

Mais bon, ça c'est parce que mon langage préféré, Elixir, a juste la meilleure syntaxe du monde (totalement subjectif, totalement assumé) pour les macros :)

Pour les erreurs, je suggère codemap-diagnostic

Excellent ! Je garde de côté, merci :)

tu pourrait avoir un self-contained Cargo.toml (qui est à la fois valid toml et rust) comme fichier pour le build système:

J'ai pas compris l'exemple, ce code irait dans le main.rs du projet ? Et il est censé faire quoi ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Rust est memory safe sans GC.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'ai eu l'occasion de bosser avec pour mettre en place une infra multi-tennant. C'est une tuerie.

Il manquait une seule chose à l'époque : la possibilité de sélectionner quelles ressources sont répliquées sur le cluster hôte.

Cela permettrait de mutualiser des opérateurs comme TektonCD, ou même celui que he développe Kubirds.

Faudra que j'aille zieuter si ça a changé.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Le lisp c'est très bien. Paraîtrait même que c'est le papa de nombreuses fonctionnalités que tu retrouves dans quasiment tout les langages. Rust inclus.

Seulement voilà, je n'ai jamais écrit une ligne de Lisp. Donc l'idée ne m'a pas traversé l'esprit. Et maintenant que tu en parles, non je ne pense pas que cela serait mon choix. Rust apporte des garanties de sécurité de la mémoire qui sont trop intéressante.

Et puis le plus important je pense : je veux progresser en Rust.

Accessoirement: 

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

ne crains-tu pas qu'au niveau des messages on se retrouve un peu loin des paradigmes du langage initial ?

Je prévois une compilation en plusieurs phases :

• Phase 0: l'analyse lexicale transforme le texte en "Token Stream"
• Phase 1: l'analyse syntaxique transforme le "Token Stream" en un AST annoté de metadata (nom du fichier, ligne, colonne, token, …)
• Phase 2: l'analyse sémantique parcours ce premier AST pour vérifier le respect des règles du langage
• Phase 3: l'analyse statique parcours à nouveau l'AST pour vérifier la cohérence des types du mieux qu'il peut, ainsi que l'inférence de type quand c'est possible
• Phase 4: le compilateur traduit l'AST annoté par les 2 phases précédentes en langage Rust
• Phase 5: appel du compilateur Rust

Mon hypothèse, c'est qu'une fois arrivée à l'etape 4, on a la garantie que le code Rust produit ne générera pas d'erreur de compilation.

Les éléments qui me permettent de soutenir cette hypothèse sont :

• l'AST consommé par l'étape 4 est censé avoir toutes les informations nécessaire pour produire un code complet
• le code produit par les différents noeuds de l'AST a été testé en amont (un Literal::Number va toujours produire le même code)
• l'AST garanti qu'on ne trouvera pas un "bloc de fonction" utilisé comme string literal pour un import, donc le code Rust produit reflète cet aspect aussi, on ne peut trouver que du code Rust valide dans le contexte/scope ou il est produit car c'est comme ça que l'implémentation aura été faite

En fait, c'est comme se demander : que se passe-t-il si après avoir compilé le C en ASM, l'assembleur renvoi une erreur ? Le soucis est au niveau de GCC ici, pas au niveau du code que je lui fournit.

Maintenant, que mon hypothèse est posée, l'implémentation suivi par les tests la confirmera ou l'infirmera.

A ce moment là, je peux toujours identifier grâce au message d'erreur de rustc quel est le bout de code qui produit l'erreur, et grâce aux annotations de l'AST produites en phase 0 à 3, retrouver le code Letlang concerné.

NB: Dans ce journal, j'explique comment j'ai commencé l'implémentation de la phase 4 et 5, en construisant à la main l'AST "valide".

J'ai fait il y a quelques temps une grammaire pest pour la phase 0 et 1. Mais comme je change d'avis sur la syntaxe comme je change de chemise, c'était contre productif.

Par contre, l'AST lui risque pas de bouger beaucoup, après tout, les concepts sont la, et les informations dont j'ai besoin pour les représenter aussi. Au final, commencer par la phase 4 et 5 c'est plus simple, et ça me fournit une suite de test pour implémenter les phases précédentes.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ha! Je suis pas tout seul à me foirer sur la relecture :)

Faut ptet qu'on arrête d'écrire après 23h.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ton compilo a mangé des lignes dans la partie « Le design pattern Visitor » ;)

Ah! Si un modo passe par la:

trait Visitor {
  type Node;

  fn visit(node: Box<Self::Node>, context: &mut Context) -> Result<String>;
}

Finalement, Letlang est devenu un (r)habillage de Rust avec ton déclic (:

Au final, tout les langages ne sont ils pas un rhabillage du langage cible (javascript pour typescript, erlang pour elixir, …) ? (:

J'ai plus confiance dans ma capacité à implémenter ce que je souhaite en Rust qu'en LLVM IR ou Assembleur.
Et j'ai plus confiance dans le résultat que cela va produire. Il me semble que débugger du Rust sera plus simple que débugger du LLVM IR.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Cela me rappelle un peu PlayOnLinux.

C'est quoi les grosses différences ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

On joue a trouver des proverbes à la con pour se lancer des fions ?

Si tu te tapes la tête contre une cruche et que ça sonne creux, n’en déduis pas forcément que c’est la cruche qui est vide

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Sauf que Qt Widget c'est un concept périmé

Source ?

C'est mon avis et pas que le mien.

Ce n'est pas un argument.

Je ne pense pas que les devs de Qt company soit sous l'emprise de champignons hallucinogènes.

Source ?

De plus je ne trouve pas dans la doc la moindre explication sur l'implémentation du moteur de rendu. Il faut utiliser une Image pour faire de l'OpenGL ?

Dans la doc de Gio UI, on trouve la ligne suivante :

app.NewWindow chooses the appropriate “driver” depending on the environment and build context. It might choose Wayland, Win32, Cocoa among several others.

J'ai pas regardé pour Fyne, mais c'est pas déconnant pour une appli native soit d'utiliser OpenGL (portable) soit un moyen de détecter l'api native comme Gio UI.

En lisant la survey, ils manquent des aspects essentiels pour une UI. Je me demande franchement qu'elle ait l'expérience de ces gens en la matière.

Quels aspects essentiels ? Qui es-tu pour juger l'expérience des gens, toi qui ne sait pas ouvrir un Bescherelle.

Quant au binding Qt. Il n'y a pas eu un commit depuis 2 ans. Et ça n'a aucun sens si le binding n'est pas autogénéré comme PyQt/PySide.

Ou alors l'ABI a pas changé depuis, hmm?

Pour les UI en techno web sur browser, React est à mon avis une des meilleures solutions.

Encore une fois, ce n'est que ton avis. Il y a Flutter, Angular, VueJS, Knockout, du SSR rendering avec Django/Flask, ou Elixir/Phoenix LiveView, … Il y a le bon vieux site statique, les Web Components, etc… Toute une myriade de solutions pour une myriade de besoins différents, et personne ne peut objectivement dire que l'une est la meilleure.

Mais Redux me donne des migraines au cerveau.

Ok. Je vois pas ce que ça apporte à l'argumentation.

Le seul avantage, c'est quand la puissance du CSS apporte une valeur ajoutée, par exemple si on veut afficher une typographie à la Wikipédia dans une application. cf. Qt Rich Text.

Tu passes du Coq à l'Ane, et aucun n'est à la bière. La possibilité de personnaliser une interface est quelque chose de très demandé par les designers depuis très longtemps. GTK 3 a introduit le CSS pour ses widgets pour remplacer les GtkStyle de GTK 2, et on a la même chose côté Qt. Ca fait quoi, 15-20 ans ?

Être aussi réducteur sur une technologie, je comprends pas l'intérêt.

Donc yet another UI…

Donc yet another commentaire trollesque qui donne son avis sans aucun argument.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ça ne m'étonne pas. Dans le monde du gamedev tu retrouvera beaucoup :

• C++ (Ogre, Irrlicht, Unreal Engine, Cryengine, …)
• C# (Cryengine, Hazel, Unity, …)

Godot est développé en C++ et introduit GDScript (qui ressemble a Python), et gagne en popularité. Donc charger une DLL pour étendre les fonctionnalités de l'engine n'est pas très complexe. Pareil pour GameMaker Studio.

Donc avoir un SDK en C, c'est s'assurer de pouvoir intégrer à toutes ces engines de manière assez simple.

Pourquoi le C est plus simple à intégrer que le C++ ? C'est une question d'ABI. En C++ tu as ce qu'on appelle le name mangling, donc tu peux pas juste naïvement faire un dlopen / dlsym.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Pardon, j'aurais du dire "le logiciel n'est pas libre". En effet si on considère que "le logiciel" englobe son code et son nom et ses assets.

Vu qu'il y a des conditions sur ce que tu peux distribuer, c'est pas 100% libre.

Pour l'exemple opposé, on a Python ou Debian a continué la branche 2.7 bien plus longtemps que upstream (2.7.18-13 étant la dernière en date). Et ils ont droit de l'appeler Python.

Le code est libre, mais la marque ne l'est pas. Et ça ne me choque pas

Moi non plus ça ne me choque pas. Ce qui me choque c'est que cela soit utilisé comme argument détracteur de Debian, alors que le principe même de Debian c'est de ne pas accepter un quelconque truc propriétaire (que cela soit un nom, une image, ou un bout de code).

On adhère à cette philosophie, ou on adhère pas, c'est pas le sujet.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Windows en lui même n'est pas difficile à maintenir. Ce qui a posé problème pendant longtemps, c'était effectivement la mise à jour des applications.

Cependant, avec l'arrivé d'outils tels que chocolatey, winget, et le store, je peux mettre à jour et gérer mes applis super simplement. C'est pas des gestionnaires de paquets à proprement parler, juste un utilitaire pour télécharger et exécuter des installeurs et me filer une commande pour aller chercher une version plus récente.

Quand je choco install jq je wget le binaire et je le place dans le dossier de bin de chocolatey. Quand je choco install cmake, je wget l'installer de CMake et ça l'installe dans Program Files. C'est minime, mais ça marche.

En tant qu'utilisateur final, je ne vais pas toucher a system32, etc… De la même manière, un utilisateur final sous Linux ne devrait pas aller éditer le /etc ou jouer avec apt/yum.

pour le moment aucune n'a suffisamment percée pour être disponible partout et avoir la finition qui convient pour vraiment permettre de le laisser dans les mains d'un utilisateur moyen.

Il manque pas grand chose je pense.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Tu essentialise tellement que ça n'a plus de sens.

Tu as dit toi même que c'était l'intégration minimum qu'un dev d'appli attendait : qu'on puisse trouver et exécuter l'application qu'on a installé sur son système.

Quand tu parle de .tar.gz je ne sais pas de quoi tu parle. Les .tar.gz dont on parle classiquement sont des sources qui demandent ./configure.sh && make && make install.

Alors là, c'est de la mauvaise foi. Depuis le début je fais le rapprochement entre la méthode d'install de Valve, de Windows avec son Program Files, etc…

J'ai même dit dès le début "une archive tar.gz qui contient tout ce dont elle a besoin", à savoir le binaire et ses libs dynamiques, et un script pour configurer proprement le LD_LIBRARY_PATH.

Exemple : https://go.dev/doc/install

Soit : wget + tar xvf + ajout au PATH.

Faire croire que je parle d'une archive de source, c'est tout simplement me faire dire ce que je n'ai pas dit. C'est du troll.

Tout le monde à le droit écrire dans ce /apps ? Il n'est pas définir par HFS actuellement, /opt peut mais il n'est pas aussi normalisé. Comment tu met à jour tout ça ?

C'est un exemple, stop la mauvaise foi. Regarde Gobolinux et NixOS si tu veux un exemple concret plus industrialisé.

Mais du coup ta solution pour dire qu'il n'y a pas de problème avec les systèmes de paquets c'est d'en concevoir un nouveau ?

J'ai jamais dit ça. Je dis simplement que les mainteneurs de distro ont tout les outils nécessaire pour permettre à n'importe quel dev d'intégrer son app au système sans en faire un package. Similaire à ce que tu trouve sur Windows et Mac OS.

Merci d'arrêter de déformer mes propos.

Le boulot de créer des package doit revenir au développeurs des applications à packager.

Il existe un nombre immense de distribution Linux, c'est vraiment au dev de fournir ça pour tout le monde ? Cela va au delà du format de paquet, il y a le nom des dépendances qui change d'une distro à l'autre. La découpe de ces mêmes paquets (-dev, -doc, -dbg, …). C'est une problématique d'intégration à un système cohérent, une problématique rencontrée par les mainteneurs de la distro.

Le boulot de créer les systèmes de paquets doit revenir aux développeurs de distribution.

L'ensemble des paquets disponibles, leur découpe, leur organisation, etc… fait partie de ce que tu appelle "le système de paquet".

Le point initial c'est "la difficulté à créer un package qui soit utilisable à peu près partout sans difficulté est un problème".

Sauf que c'est faux. Regarde le tar.xz de Golang. Tu peux l'installer sur n'importe quelle distro sans aucun problème (tar xf). Tu peux le désinstaller sans problèmes et sans rien oublier (rm -rf). Et tu peux le mettre à jour tout aussi simplement.

Beaucoup de mauvaise foi et de sourde oreille dans les précédents messages…

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ça ne marche pas et ça ne marchera pas dans l'avenir.

Bah c'est la ou on est pas d'accord.

Il y a l'OS (linux kernel + GNU userland), il y a la distribution (gestionnaire de paquet, configuration centralisée, firmware/driver commun, …), et enfin il y a les applications de l'utilisateur (navigateur web, client mail, libreoffice, vs code pour les devs, …).

Ces applications de l'utilisateur ont juste besoin d'être trouvable dans le PATH et d'avoir un .desktop quelque part. Il existe une solution hyper simple :

• Avoir un truc du style /apps/*/bin dans le PATH qui soit supporté par les shell
• Avoir le même système pour les .desktop: /apps/*/*.desktop

Cette solution est à implémenter au niveau de la distribution. Ensuite, il s'agit d'extraire un .tar.gz dans le dossier /apps.

Alors oui, "duplication de shared libs", "bordel à la 'program files' de windows", etc… Mais clairement, l'utilisateur final s'en cotrefiche.

Sur windows les gens font pas mal d'installeur

Un installeur dont le job est d'extraire les fichiers de l'appli dans Program Files et d'ajouter le raccourci dans le menu démarrer. Quelle différence avec extraire un .tar.gz ?

sous mac ça se rapporche (il me semble) d'un appimage mais mieux intégré (le finder les prends automatiquement en compte)

Donc une archive extraite quelque part sur le système, avec la solution que j'ai cité ci dessus du /apps/*/bin et /apps/*/*.desktop (sauf que l'archive est pas vraiment "extraite" pour Mac, mais le principe est le même). Et qui a fait ça ? Les mainteneurs de Mac OS, pas les devs de l'appli.

aujourd'hui les 2 poussent vers un store, mais ce n'est pas comme les dépôts debian/redhat, les développeurs poussent eux même leurs paquets.

Les dépôts communautaires ça existe (les PPA pour Ubuntu, AUR pour Arch, …). Le store de Windows est juste un endroit centralisé ou télécharger/exécuter l'installeur de l'appli. Au lieu d'aller sur le site de l'éditeur.

Mais cet installeur n'a toujours comme seul rôle d'extraire une archive qui contient tout ce dont elle a besoin.

Aujourd'hui on s'en approche à peu prêt […], mais ça demande encore du travail.

Et ce travail n'est pas a être fait par le développeur de l'application.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Et être constructif, ne pas se comporter comme un troll c'est de ne pas se contenter de s’arrêter là dessus pour "vaincre l'adversaire".

Si tu lis mes réponses, tu verras que j'argumente, que j'expose les informations dont je dispose, qui contredisent les "faits" balancé par mon interlocuteur.

Aucun n'a pour le moment changé véritablement la donne. Aujourd'hui le packaging de distribution est toujours extrêmement majoritaire et les distributions qui tentent de s'appuyer quasi exclusivement sur ces packgings sont tout à fait expérimental.

Comme je l'ai dit plus haut, le packaging de distribution type APT / RPM ne disparaitra pas, car l'objectif est de fournir un système cohérent et intégré. Ce n'est pas au développeur d'application de faire ce travail, mais au mainteneur de la distribution.

Le fait que les développeurs ne sont pas en mesure de produire des packages n'est pas un problème pour les systèmes de packaging ?

Non car c'est pas leur boulot. Si le développeur d'appli peut filer un .tar.gz avec son appli dedans, c'est suffisant. C'est ce qu'il fait pour Windows, et Mac de toute façon, sauf que ça s'appelle par "tar.gz". Certains iront un peu plus loin et fourniront un .deb/.rpm pour la version la plus récente de la distribution. D'autres iront même jusqu'à fournir un dépôt APT ou RPM.

Mais travailler activement avec l'upstream de la distro pour intégrer le package au reste du système ? Non, définitivement, c'est pas le taf du dev.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

De plus Linus ne dis pas « je m'appelle Linus et je vous dis que ça c'est mal »

L'argument fallacieux c'est pas Linus qui le commet. Mais bien celui qui le cite.

Alors tu peux affirmer que la debconf n'est pas pertinente pour parler de packaging sur linux, mais il va falloir un peu plus d'arguments.

La DebConf 14 en particulier, d'il y a 8 ans, les choses ont bien évoluées depuis et donc cette vidéo est obsolète. Flatpak, Snap, Appimage, Docker, …

De plus, il est pas en train de dire que le packaging Debian a des problèmes, mais plutôt que du point de vue d'un développeur d'appli (pas un mainteneur de distro), c'est compliqué de faire les choses bien. Ce qui est une grosse différence.

Les arguments sont pour autant bien là quelque soit ton manque de respect.

Donc me dire que j'ai tord parce que "Linus Torvald a dit que" il y a 8 ans, le tout pour souligner que "Debian c'est de la chiasse au moins sous Windows et Mac ça marche", c'est pas de l'irrespect ?

Désolé, j'ai pas de respect non plus pour les trolls.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Par contre, pour OpenSSH, c'est certain.

Ah ok, good to know.

Mais pour le coup, depuis cet incident, ça n'a pas motivé Debian à travailler un peu plus avec upstream sur ce type de composant critique ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Merci pour le gist, je le mets en favoris !

Vraiment pas sur que Torval est le même avi aujourd'hui.

De toute façon, c'est que l'avis d'une personne de plus. Les arguments fallacieux d'autorité ("mais un tel il a dit que"), je me torche avec :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Je ne demande pas pourquoi, je demande si c'est possible :-)

Ma réponse, ça serait "oui en trichant". Si tu fais un /opt/monappli, que tu mets les .so dedans et que tu configure proprement le LD_LIBRARY_PATH, comme ce que fait Valve avec les jeux Steam.

C'est tout à fait possible d'avoir une appli isolée avec ses propres dépendances. Perdant tout les avantages des shared libs et gagnant tout les avantages des static libs, le tout sans les compiler statiquement pour autant.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Potentiellement est utilisé de façon assez créative dans cette phrase.

Aucune CVE n'ont été ouvertes pour les patchs de OpenSSL à ce que je sache.

Mozilla autorise l’utilisation de la marque firefox sous réserve que le source n’est pas modifié de façon non triviale

Ce qui impose des conditions sur la distribution du code, ce qui est contraire à l'esprit du libre et la philosophie de Debian.

Ce qui, oh, comme par hasard, me parait plutôt bien correspondre au concept de « patches non voulus ».

Sauf que quand tu distribue ton code sous une licence libre, le concept de "patch non voulu" est juste stupide. Et si tu distribue pas ton code sous une licence libre, tu sera jamais intégré dans les dépôts officiels de Debian.

Cela ne t'empêche pas de fournir ton propre dépôt APT, comme ce que fait NodeJS, MongoDB, et bien d'autres.

Pour citer l'article LWN que tu a mis en lien:

The issue at hand is trademarks. Mozilla Foundation software comes with trademarked names, and the use of those names is governed by the Mozilla Trademark Policy.

C'est bien dit explicitement, si tu veux distribuer un logiciel qui s'appelle "Mozilla Firefox" ou "Mozilla Thunderbird", c'est soumis à conditions. Donc le code n'est pas libre. Donc Debian fork, retire les choses qui sont soumises à la trademark, et boom Iceweasel lui est 100% libre ce qui correspond à la philosophie de Debian.

La réponse est donc là, tu veux pas de "patch non voulu" ? Tu mets pas ton code sous licence libre. AKA: Tu ne donnes pas la liberté de le faire. (Je sens qu'à force de répéter ça, je vais finir par invoquer Zenitram).

Après, comme j’ai dit plus haut, t’es clairement la juste pour me contredire, je suppose que t’as pas supporté que je dise que C est largement cantonné à l’embarqué et bas niveau, donc je vais passer sous silence tes autre remarques qui n’ont pas grand chose à voir avec la choucroute, et je vais me retirer de ce fil, pas grand chose de productif n’en sortira.

J'y peux rien si ça fait 2 threads ou tu rabâche un ramassis de connerie. Mais bon, à la base j'avais même pas fait le rapprochement.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Si tu veux un jeu turing complet, je te conseil Magic the gathering.

https://beza1e1.tuxen.de/articles/accidentally_turing_complete.html

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ok, mais ca aide pas avec les versions majeures. Tout le monde n'a pas forcement envie de se taper des gros changements comme ca. GTK3 n'est pas source compatible avec les version précédentes. GTK4 non plus.

C'est pour ça que les distros permettent d'avoir plusieurs versions d'une même lib en parallèle. libgtk.so.3, libgtk.so.4, …

Et Debian fait un travail phénoménal pour backporter les patchs de sécurités.

Je comprends bien la philosophie sous jacente qui pousse a faire des changements qui petent tout.

Sauf que non, c'est pas ça la philosophie d'une distro. La philosophie c'est de fournir un système cohérent ou chaque paquet est bien intégré avec le reste du système.

Devnewton demande pourquoi est ce qu'on pourrait vouloir embarquer un framework en statique, je lui dit pourquoi certains sont intéressés par du tout statique.

Sauf que tes arguments à l'encontre du dynamic linking sont erronés. Je ne remets pas en cause les avantages du static linking.

il me semble qu'OpenSSL a trouvé a redire sur un certain patch de Debian.

C'est anecdotique. OpenSSL a un process de code review assez strict, et les patchs fait par Debian bypassaient ce process, ce qui pouvait potentiellement introduire des failles de sécurités dont OpenSSL n'avait pas connaissance. Ce qui est critique dans le cas spécifique de OpenSSL. Mais pour le reste, osef un peu.

Iceweasel est né d'une dispute entre Mozilla et Debian au sujet des patches de Debian dans firefox

Non, Iceweasel est né d'une dispute concernant le licencing de certains assets (images / logos / …) de Mozilla. Debian ayant une philosophie "100% libre", il n'était pas possible d'intégrer ces assets dans les dépôts officiels de Debian. La seule différente donc entre Iceweasel et Firefox, c'est les images.

Apres, tu me crois, tu me crois pas. C'est toi qui voit.

C'est pas la question. Tu avances des propos incorrects et peint une image erronée de la situation.

Linus Torvarlds a l'air d'être du meme avis que moi, et tu serais mal venu de lui expliquer qu'il est ignorant a propos des problemes de link statique vs dynamique, les chaines de compilation ou comment les distributions fonctionnent.

Linus Torvalds n'est pas un dieu, il n'a pas la science infuse, ça lui arrive d'avoir tort. Dans l'extrait vidéo que tu cites, il explique qu'il n'y a qu'une distribution Windows, et qu'une distribution Mac OS, mais plein de distributions Linux, ce qui rend le packaging par le développeur compliqué. Il enchaîne en expliquant que Valve a opté pour "embarquer le runtime avec l'application".

Ça veut dire quoi ? Ça veut dire qu'en tant que développeur d'application, je peux fournir un tar.gz qui contient mon binaire et ses libs partagées, extraire ça dans /opt, et basta. Si les mainteneurs d'une distribution veulent intégrer le logiciel au système, c'est à eux de faire le travail de packaging et d'intégration.

De nombreux projets fournissent un .deb/.rpm pour la version la plus récente, mais tu trouvera aussi un .tar.gz contenant la version portable sur toutes les distros.

La solution du .tar.gz avec tes .so dedans, ça réduit les problématiques de déploiement/distribution au même niveau qu'un binaire statique. C'est la solution que Valve a choisit, c'est la solution que Flatpak et Snap ont choisit. C'est la solution que conda (pour Python) a choisi depuis des décénies.

Si je veux m'intégrer au système et distribuer moi même un paquet .deb / .rpm, je le fais en connaissance de cause. Et j'implémente les tests d'intégrations qui vont bien.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Sous Linux, dépendre de gtk/qt/whatever ça devient plus compliqué. C’est une jungle de différentes versions

Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.

de différentes options de compilation

Juste le classique -lmalib

compilateur

Compilo différent, même standard. Osef

Si t’arrives a être intégré upstream, ça aide

Upstream d'une distro ? Ça va rien changer à ta chaine de compilation.

mais après tu te tapes des patches qui te plaisent pas forcemment

T'as des exemples de patch non voulu sur GTK / Qt ? Qui vont impacter négativement ton appli ?

tu contrôles pas quelle version est distribué

Ah oui, parce que tu peux pas spécifier une version de ta dépendance au niveau du gestionnaire de paquet.

ce genre de choses qui peuvent être un gros problème en fonction du projet

Non, car aucune de ces choses que tu as cité ne font sens.

Si t’es pas upstream, bon courage. Ça va être la foire à « Debian machin a gtk 42.31, mais on a linké a la version 43.21 et des choses bizarres se passent ».

Tu n'aurais pas pu prendre un pire exemple:

• Debian, la distro LTS par excellence qui va faire en sorte de pouvoir maintenir plusieurs version de GTK en parallèle
• GTK qui change de version majeure une fois tout les 10 ans

Et du coup, l’intérêt du link statique de go devient beaucoup plus apparent.

Ah oui, c'est vrai, c'était une discussion sur le static linking, et il a fallu que tu viennes dire des inepties sur le dynamic linking, faisant office de preuve de ton ignorance sur le sujet. Totalement HS.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'attend le support des modèles C4 dans mermaid pour m'en servir : https://github.com/mermaid-js/mermaid/issues/1276

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg