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.
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.
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…
Ç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.
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.
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.
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.
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.
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.
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.
une faille de sécurité dans un composant critique de 80% de l'infrastructure IT mondiale
Et
une faille de sécurité dans un logiciel utilisé de manière anecdotique par quelques utilisateurs
Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.
Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.
Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.
Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.
Écrire 10 lignes de C sans UB, ça demande un talent et un temps dont peu de personnes disposent.
Et alors ?
Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.
Le C permet des choses formidables mais il amène de gros coûts, qui se résolvent très mal avec des yakas.
Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.
Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.
Il n'a aucune garantie que la prochaine version de son compilateur fasse la même chose
Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.
Il n'a aucune garantie que le changement d'une option de son compilateur continuera à faire un programme qui a le même résultat.
On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.
Il ne faut pas avoir d'UB en se disant "je sais ce que je fais".
C'est le principe même des Undefined Behavior.
Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.
Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.
Non, un programme avec un UB n'est pas un programme valide.
A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.
Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction add des x86.
C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.
Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.
Tu veux être portable sur toutes les archis ? Tu évites les undefined behavior.
Tu sais quel est ton CPU target, et ta toolchain (version/arch du compilo) ? Tu prend connaissance de leur spec, et tu peux utiliser les undefined behavior qui sont spécifiés à un autre niveau
Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.
il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.
Quant à la question de l'assembleur elle n'a pas de sens
Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.
mais sa sémantique ne permet pas de s'en assurer
Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.
Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).
Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.
Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?
ok, super, t'as trouvé des softs écrits en C.
Je peux te sortir swiftc ou clang ou hotspot, tous écrits en C++, ca fera pas avancer le chimilimili.
Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.
C'est le genre de code qui rentre dans "la montagne de code a porter" dont je parlais.
Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?
SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.
Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.
Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".
Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.
Encore cet argument…
C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.
Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.
Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.
Il n'y a pas d'autres raisons à ça que son statut
Bonjour les oeillères.
Le langage qui est utilisé comme référence en terme de performance et auquel tout les langages se comparent
Le langage qui te permet de contrôler avec le plus de précision où et quand allouer / libérer de la mémoire (as tu déjà eu des problèmes avec le GIL de Python ou le GC de Go ?)
Le seul langage qui, un demi siècle plus tard, est encore l'un des plus utilisés dans l'industrie (finance, vidéo, embarqué, OS, …)
Le langage qui est considéré comme le plus portable qui existe
Le langage qui peut s'interfacer avec tout les autres langages qui existe
Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.
Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.
Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.
SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
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 jqje wget le binaire et je le place dans le dossier de bin de chocolatey. Quand jechoco 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.
Il manque pas grand chose je pense.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
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.
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.
C'est un exemple, stop la mauvaise foi. Regarde Gobolinux et NixOS si tu veux un exemple concret plus industrialisé.
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.
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.
L'ensemble des paquets disponibles, leur découpe, leur organisation, etc… fait partie de ce que tu appelle "le système de paquet".
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 1.
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 :
/apps/*/bindans le PATH qui soit supporté par les shell/apps/*/*.desktopCette 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.
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 ?
Donc une archive extraite quelque part sur le système, avec la solution que j'ai cité ci dessus du
/apps/*/binet/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.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.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 5.
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.
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.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 1.
L'argument fallacieux c'est pas Linus qui le commet. Mais bien celui qui le cite.
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.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 2.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Merci pour le gist, je le mets en favoris !
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 5.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
Aucune CVE n'ont été ouvertes pour les patchs de OpenSSL à ce que je sache.
Ce qui impose des conditions sur la distribution du code, ce qui est contraire à l'esprit du libre et la philosophie de Debian.
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:
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).
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
[^] # Re: Fourvoyé
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 4.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 9.
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.
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.
Sauf que tes arguments à l'encontre du dynamic linking sont erronés. Je ne remets pas en cause les avantages du static linking.
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.
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.
C'est pas la question. Tu avances des propos incorrects et peint une image erronée de la situation.
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
[^] # Re: Go with C
Posté par David Delassus (site web personnel) . En réponse au journal Interface graphique en Go!. Évalué à 3.
Heureusement que les distros et les devs se chargent de garder l'ABI compatible entre les différentes versions mineures.
Juste le classique
-lmalibCompilo différent, même standard. Osef
Upstream d'une distro ? Ça va rien changer à ta chaine de compilation.
T'as des exemples de patch non voulu sur GTK / Qt ? Qui vont impacter négativement ton appli ?
Ah oui, parce que tu peux pas spécifier une version de ta dépendance au niveau du gestionnaire de paquet.
Non, car aucune de ces choses que tu as cité ne font sens.
Tu n'aurais pas pu prendre un pire exemple:
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
[^] # Re: enfin ?
Posté par David Delassus (site web personnel) . En réponse au lien [Github] Include diagrams in your Markdown files with Mermaid. Évalué à 2.
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
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 0.
Il y a une différence entre :
Et
Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.
Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.
Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.
Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.
J'arrête de débattre avec des sourds, tchao.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -2.
Non, comme je l'ai dit précédemment, j'écris du C + Compilo + CPU. Par exemple :
Comme quoi, faut bien lire tout dans son ensemble pour comprendre un argument.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5.
Comment tu peux te faire pwn avec un programme qui accède pas à internet ? Tout les échecs ne sont pas critique.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
Et alors ?
Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.
Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.
Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 1.
Et donc dans ce cas la, tu évites les undefined behavior comme j'ai dit plus haut.
Dépendre des undefined behavior ne rend pas ton programme invalide, il le rend pas portable, c'est tout.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à -5.
Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.
On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.
C'est le principe même des Undefined Behavior.
Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.
Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.
A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 4.
Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction
adddes x86.C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.
Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.
Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.
Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.
Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.
Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.
Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 8. Dernière modification le 28 février 2022 à 23:45.
Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.
Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?
SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.
Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.
Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".
Pour ceux qui ont envie de rire un coup : https://github.com/ansuz/RIIR/issues
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
Encore cet argument…
C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.
Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.
Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.
Bonjour les oeillères.
Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.
Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 8.
SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).
https://sqlite.org/whyc.html
CPython par exemple, c'est pas un kernel, pas un driver, pas de l'embarqué, etc… Il existe PyPy pourtant, après tout Python n'est qu'une spec.
Ou alors Lua.
Ou alors tout le domaine de la finance qui a besoin de performance à la nanoseconde près.
C'est effectivement l'observation qu'on peut faire si on détourne le regard sur ce qu'apporte le C depuis maintenant 50 ans.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Survivor
Posté par David Delassus (site web personnel) . En réponse au journal C, un âge remarquable. Évalué à 10.
50 ans.
50 ans que chaque année un nouveau langage apparaît pour l'enterrer.
50 ans qu'il survit. Nay, que dis-je, 50 ans qu'il est en vie!
Un demi siècle, et toujours aucun signe de la retraite.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg