Haha! Le meilleur exemple qui soit. go get ou wget / curl|bash.
Sans parler de helm ou kustomize pour déployer des trucs ad-hoc sans réelle gestion de dépendance (et non, argocd/fluxcd ne résolvent pas le problème).
J'ai rédigé un draft de spec pour développer un gestionnaire de paquet avec dépôt centralisé basé sur kapp (de la team carvel), mais par manque de temps et de motivation, je m'y suis jamais attaqué.
Effectivement, c'est une meilleure analogie, merci.
Le point que je voulais avancer c'était que le fait qu'un système soit indépendant de l'OS n'enlève rien à sa qualité.
Et on est aussi d'accord, chocolatey face à un MSYS2 ne fait pas le poids d'un point de vue expérience utilisateur.
Dans tout les cas, aujourd'hui sous Windows, l'époque des "je vais chercher mes logiciels sur 50.000 sites différents" est révolue, tu as soit :
l'autorisation par ton entreprise d'utiliser chocolatey/MSYS2
un dépôt central fournit par ton entreprise qui contient les logiciels autorisés (donc un seul site à consulter)
une machine fournie par ton entreprise avec les logiciels autorisés pré-installés
une entreprise qu'il faut que tu quittes
Je pars du principe que si tu as une machine Windows personnelle chez toi, tu es libre de faire ce que tu veux dessus.
Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
Non, c'est une attaque personnelle qui n'a rien à faire dans un débat sain.
que ça te plaise ou non n'a aucune espece d'importance pour moi, et je continuerai à te dire ce que je pense en te lisant, toi ou n'importe qui d'ailleurs.
Ce qui prouve que tu n'es pas la pour débattre sainement, et donc argumenter avec toi est une perte de temps pure et simple.
Tes états d'ames à la réception ne m'importent pas.
Il ne s'agit pas de mes états d'âmes, mais de toi qui fait un jugement de valeur sur mes compétences et mon expérience basée sur 3 pauvres commentaires. Tu ne me connais pas, je te connais pas, laissons l'individu en dehors du débat et faisons parler uniquement les arguments et les faits.
rien ne t'oblige à réagir de la sorte.
Rien ne t'oblige a faire une attaque personnelle dans un débat.
"Je n'ai plus d'argument donc je vais dire que tu y connais rien pour te décrédibiliser". C'est ce que tu as fait en gros. Et moi je dis non à ce genre "d'argumentation" fallacieuse.
Côté Windows, je ne sais pas comment c'est géré par les produits que tu cites, mais ça n'a rien à voir avec un gestionnaire de paquets et tous le processus mis en place par les distrib.
Je suppose que tu entends « ta machine de dev » comme une machine perso…?
Fourni par l'employeur mais oui.
Ça n’en fait pas pour autant la vérité absolue : ce ne sont pas des solutions intégrées
Le propos était "il n'existe pas de gestionnaire de paquet sous Windows", c'est juste faux que cela soit intégré ou non.
Preuve en est, sous Linux, on peut avoir en parallèle plusieurs gestionnaires de paquets: apt, flatpak, snap, …
En te lisant, j’ai l’impression que toutes les sociétés où je suis passé, dont la moitié sont au CAC40, ne sont que des exceptions.
C'est qu'une impression alors, j'ai bien précisé "mon expérience", a aucun moment j'ai sous-entendu que j'étais passé par les millions d'entreprises existante.
Quand bien même, si l'entreprise m'embauche pour faire du développement Python et qu'elle m'interdit d'installer Python, ou pip. Il y a un problème. En théorie, l'ordinateur qui t'es fournit devrait avoir tout le nécessaire pour accomplir le boulot, pas besoin d'aller installer 40.000 paquets différents qui n'ont rien à voir avec ton travail. Si il manque un outil essentiel, la-dite entreprise est censé fournir un processus (faisant intervenir des humains surement) pour intégrer l'outil au catalogue autorisé.
Dans une précédente entreprise, on avait l'autonomie sur l'ordinateur, il y avait juste PulseSecure (VPN) d'installé pour te faire passer par leur proxy, et dépôt Maven/PyPI géré par la-dite société (pas question d'utiliser les dépôts publique).
Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.
Tu crois que les mainteneurs ont le temps de review le code des 25.000 logiciels qui sont livrés dans les dépôt officiels ? Certainement pas, donc tu fais confiance au code source upstream dans tout les cas, que le binaire soit build par l'upstream ou par le système de build de Debian, cela ne change pas grand chose à ou tu place ta confiance.
S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.
Dans la pratique, ce qui est fait c'est soit fournir un .deb pré-compilé, soit carrément un dépôt à ajouter au sources.list.
J'ai donné l'exemple de NodeJS et MongoDB qui font ça, et ce sont loin d'être les seuls.
Ils ne sont pas tenu de respecter la charte de Debian.
Quelle différence entre télécharger un binaire upstream, et un .deb/repo apt upstream ?
Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.
Libre à toi d'utiliser MSYS2 avec Pacman qui dispose donc de cette infrastructure.
Avec Debian, par exemple, tu mets ta confiance uniquement dans les mainteneurs
Il y a beaucoup trop de mainteneurs pour que l'argument tienne. Et c'est en plus faux, tu mets ta confiance dans :
le développeur upstream
le mainteneur du paquet
les mainteneurs du dépôt
Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :
le développeur upstream
le mainteneur du paquet
les mainteneurs de l'index
Et, au risque de me répéter, c'est strictement la même chose pour tout les gestionnaires paquets existant. Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.
De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.
Avec Debian, la charte impose la distribution de logiciel redistribuable et donc, si un paquet VS Code existait, il serait produit avec la version open source "codium" et donc sans la télémétrie propriétaire de Microsoft ni leur marché d'extension (car inaccessible pour les binaires non fournis par Microsoft).
Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?
Il me semble que ce n'est pas un repository de binaires et / où sources de logiciel, mais juste un index centralisé des liens de téléchargement de chaque logiciel.
Pour l'utilisateur final, cela ne change rien, c'est juste un détail d'implémentation. Et ce n'est valable que pour chocolatey, msys2 lui repose sur pacman (de archlinux).
Si je ne me trompe pas, la situation ne s'améliore pas
Ben si justement, on a maintenant des outils pour optimiser l'installation de logiciel alors qu'avant non. En quoi cela ne serait pas une amélioration de la situation ?
tu dois faire confiance aux scripts PowerShell de la communauté chocolatey.
Sous n'importe quel système de gestion de paquet (npm, pip, cargo, apt, pacman, …) tu dois faire confiance aux mainteneurs du dépôt ou du paquet.
Si c'est un argument contre Windows, c'est aussi un argument contre Linux.
Le terme "Linux Desktop" ca veut dire "Un système d'exploitation basé sur Linux pour une utilisation bureautique". Le terme bureautique a aussi une signification particulière, et "je l'ai posé sur un bureau en bois" n'est pas la définition.
Mon ordinateur est posé sur une petite table en bois et pas un bureau, du coup je suis pas inclus dans les chiffres ?
Une VM, un conteneur Docker, le WSL, ce n'est pas de la bureautique, je vois pas comment cela peut être sujet à débat.
Remarque que la phrase n'est pas Linux as the desktop OS.
Merci, mais ta mauvaise foi tu peux te la garder.
Ou alors dans ce cas laisse moi surenchérir, Mac OS est un système FOSS car je peux installer GIMP dessus ?
Personnellement je n'ai jamais compris comment on pouvait utiliser Windows pour travailler
[…]
il faut se taper 50 000 sites webs pour télécharger des trucs qui peuvent aider à travailler
Git Bash
MSYS2 (avec pacman)
Chocolatey ou winget
PowerShell
…
NodeJS, Python, Ruby, GCC (mingw), Clang, CMake, vcpkg, Rust, Go, et bien d'autres langages/toolchains tournent sous windows très bien.
Tout les IDE les plus populaires tournent aussi sous Windows pour au final aucune différence de comportement.
Après bien sûr, pour comprendre il faut d'abord faire un peu de recherche ou voir même essayer. Mais c'est plus facile de suivre la tradition de "bouh windows c'est nul pour dev"
Un live de décollage d'une fusée en direction de la lune, dont les systèmes reposent sur de nombreux logiciels/technologies libre, oui ça me semble cohérent.
Pour la cuisson du poulet, j'avoue, cela n'a rien à faire ici non plus. La preuve: -15
Je pense que cet article prédate systemd (corrigez moi si je me trompe).
En général, j'aime bien mettre le titre original de la page en guise de titre de lien, plutôt qu'une interprétation personnelle, je laisse ainsi chacun se faire son propre avis.
En tout cas, merci de ce repartage, c'est toujours un plaisir de le voir passer. Cet article regorge de ce qui m'a séduit à l'époque sous Linux: tu peux le bidouiller comme tu veux.
Même si aujourd'hui je ne bidouille plus mon système (manque de temps et de motivation), et que je tourne sous Windows, c'est quand même fun à voir.
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
Haha! Le meilleur exemple qui soit.
go getouwget/curl|bash.Sans parler de helm ou kustomize pour déployer des trucs ad-hoc sans réelle gestion de dépendance (et non, argocd/fluxcd ne résolvent pas le problème).
J'ai rédigé un draft de spec pour développer un gestionnaire de paquet avec dépôt centralisé basé sur kapp (de la team carvel), mais par manque de temps et de motivation, je m'y suis jamais attaqué.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
Effectivement, c'est une meilleure analogie, merci.
Le point que je voulais avancer c'était que le fait qu'un système soit indépendant de l'OS n'enlève rien à sa qualité.
Et on est aussi d'accord, chocolatey face à un MSYS2 ne fait pas le poids d'un point de vue expérience utilisateur.
Dans tout les cas, aujourd'hui sous Windows, l'époque des "je vais chercher mes logiciels sur 50.000 sites différents" est révolue, tu as soit :
Je pars du principe que si tu as une machine Windows personnelle chez toi, tu es libre de faire ce que tu veux dessus.
Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
Non, c'est une attaque personnelle qui n'a rien à faire dans un débat sain.
Ce qui prouve que tu n'es pas la pour débattre sainement, et donc argumenter avec toi est une perte de temps pure et simple.
Il ne s'agit pas de mes états d'âmes, mais de toi qui fait un jugement de valeur sur mes compétences et mon expérience basée sur 3 pauvres commentaires. Tu ne me connais pas, je te connais pas, laissons l'individu en dehors du débat et faisons parler uniquement les arguments et les faits.
Rien ne t'oblige a faire une attaque personnelle dans un débat.
"Je n'ai plus d'argument donc je vais dire que tu y connais rien pour te décrédibiliser". C'est ce que tu as fait en gros. Et moi je dis non à ce genre "d'argumentation" fallacieuse.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
MSYS2 c'est littéralement pacman…
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 0.
Debian est à Linux ce que MSYS2 ou chocolatey est à Windows.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à -2.
Ce genre de commentaire à la con tu te les mets ou je pense.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 1.
Fourni par l'employeur mais oui.
Le propos était "il n'existe pas de gestionnaire de paquet sous Windows", c'est juste faux que cela soit intégré ou non.
Preuve en est, sous Linux, on peut avoir en parallèle plusieurs gestionnaires de paquets: apt, flatpak, snap, …
C'est qu'une impression alors, j'ai bien précisé "mon expérience", a aucun moment j'ai sous-entendu que j'étais passé par les millions d'entreprises existante.
Quand bien même, si l'entreprise m'embauche pour faire du développement Python et qu'elle m'interdit d'installer Python, ou pip. Il y a un problème. En théorie, l'ordinateur qui t'es fournit devrait avoir tout le nécessaire pour accomplir le boulot, pas besoin d'aller installer 40.000 paquets différents qui n'ont rien à voir avec ton travail. Si il manque un outil essentiel, la-dite entreprise est censé fournir un processus (faisant intervenir des humains surement) pour intégrer l'outil au catalogue autorisé.
Dans une précédente entreprise, on avait l'autonomie sur l'ordinateur, il y avait juste PulseSecure (VPN) d'installé pour te faire passer par leur proxy, et dépôt Maven/PyPI géré par la-dite société (pas question d'utiliser les dépôts publique).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
Tu crois que les mainteneurs ont le temps de review le code des 25.000 logiciels qui sont livrés dans les dépôt officiels ? Certainement pas, donc tu fais confiance au code source upstream dans tout les cas, que le binaire soit build par l'upstream ou par le système de build de Debian, cela ne change pas grand chose à ou tu place ta confiance.
Dans la pratique, ce qui est fait c'est soit fournir un .deb pré-compilé, soit carrément un dépôt à ajouter au sources.list.
J'ai donné l'exemple de NodeJS et MongoDB qui font ça, et ce sont loin d'être les seuls.
Ils ne sont pas tenu de respecter la charte de Debian.
Quelle différence entre télécharger un binaire upstream, et un .deb/repo apt upstream ?
Libre à toi d'utiliser MSYS2 avec Pacman qui dispose donc de cette infrastructure.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 3.
Il y a beaucoup trop de mainteneurs pour que l'argument tienne. Et c'est en plus faux, tu mets ta confiance dans :
Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :
Et, au risque de me répéter, c'est strictement la même chose pour tout les gestionnaires paquets existant. Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc… qui ne sont pas curated par des mainteneurs.
De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, …), l'argument tiens encore moins.
Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?
Cela existe déjà en plus : https://community.chocolatey.org/packages/vscodium
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 4. Dernière modification le 28 décembre 2022 à 13:48.
Pour l'utilisateur final, cela ne change rien, c'est juste un détail d'implémentation. Et ce n'est valable que pour chocolatey, msys2 lui repose sur pacman (de archlinux).
Ben si justement, on a maintenant des outils pour optimiser l'installation de logiciel alors qu'avant non. En quoi cela ne serait pas une amélioration de la situation ?
Sous n'importe quel système de gestion de paquet (npm, pip, cargo, apt, pacman, …) tu dois faire confiance aux mainteneurs du dépôt ou du paquet.
Si c'est un argument contre Windows, c'est aussi un argument contre Linux.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 4.
En 10 ans de carrière, j'ai jamais rencontré une seule entreprise qui t'empêchait d'installer tes outils de devs sur ta machine de dev.
Je répète :
cf point précédent.
En fait, le reste de ton commentaire: cf point précédent. Tout ce que tu dis était vrai, il y a 10 ans. Ce n'est plus le cas.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Hahaha
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à -1. Dernière modification le 28 décembre 2022 à 10:21.
Le terme "Linux Desktop" ca veut dire "Un système d'exploitation basé sur Linux pour une utilisation bureautique". Le terme bureautique a aussi une signification particulière, et "je l'ai posé sur un bureau en bois" n'est pas la définition.
Mon ordinateur est posé sur une petite table en bois et pas un bureau, du coup je suis pas inclus dans les chiffres ?
Une VM, un conteneur Docker, le WSL, ce n'est pas de la bureautique, je vois pas comment cela peut être sujet à débat.
Merci, mais ta mauvaise foi tu peux te la garder.
Ou alors dans ce cas laisse moi surenchérir, Mac OS est un système FOSS car je peux installer GIMP dessus ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Euh, oui, mais non
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 1.
NodeJS, Python, Ruby, GCC (mingw), Clang, CMake, vcpkg, Rust, Go, et bien d'autres langages/toolchains tournent sous windows très bien.
Tout les IDE les plus populaires tournent aussi sous Windows pour au final aucune différence de comportement.
Après bien sûr, pour comprendre il faut d'abord faire un peu de recherche ou voir même essayer. Mais c'est plus facile de suivre la tradition de "bouh windows c'est nul pour dev"
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Hahaha
Posté par David Delassus (site web personnel) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 6. Dernière modification le 27 décembre 2022 à 16:35.
Ou:
Depuis quand le WSL et Docker compte comme usage "desktop" ? A ce rythme la, faut aussi compter Android, les VMs, certains grille-pains ou frigo, etc…
"C'est l'année du bureau Linux, regarde, c'est utilisé partout sauf sur le bureau."
Merci de la tranche de rire et bonnes fêtes de fin d'année ! :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: std::embed
Posté par David Delassus (site web personnel) . En réponse au lien J'embarque les assets de mon jeu dans l'exécutable, voici comment j'ai fait.... Évalué à 4.
Merci pour le lien! Très instructif.
A vrai dire, je suis conscient des problèmes de perf de la solution xxd, mais c'est aussi la plus simple.
Sur ce projet, je suis la philosophie "perfect is the enemy of good enough".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: appimage?
Posté par David Delassus (site web personnel) . En réponse au lien J'embarque les assets de mon jeu dans l'exécutable, voici comment j'ai fait.... Évalué à 2.
Les appimage c'est spécifique à Linux, et tout sauf portable.
Sous windows cela requiert le WSL et un truc du style Xming
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On s'en bats les couilles
Posté par David Delassus (site web personnel) . En réponse au lien Le youtubeur Norman Thavaud en garde à vue pour viols et corruption de mineurs. Évalué à 1.
Un live de décollage d'une fusée en direction de la lune, dont les systèmes reposent sur de nombreux logiciels/technologies libre, oui ça me semble cohérent.
Pour la cuisson du poulet, j'avoue, cela n'a rien à faire ici non plus. La preuve: -15
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Paywall
Posté par David Delassus (site web personnel) . En réponse au lien [LWN] Losing the magic. Évalué à 2.
Allez-y moinssez.
C'est vrai qu'après tout dans la vie, tout devrais être gratuit, et essayer de rentabiliser quelque chose est une ignominie capitaliste !
Vraiment des connards ces gens qui mettent un paywall.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Paywall
Posté par David Delassus (site web personnel) . En réponse au lien [LWN] Losing the magic. Évalué à 4.
LWN c'est bien, viens souscrire à un abonnement et aider à supporter le site, on a des cookies (mais pas ceux des brouteurs). :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# TLDR
Posté par David Delassus (site web personnel) . En réponse au lien [LWN] Losing the magic. Évalué à 6.
L'utilisation de "magic number" pour identifier les structures de données du noyaux vont disparaître.
0xDEADBEEF:(https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: On s'en bats les couilles
Posté par David Delassus (site web personnel) . En réponse au lien Le youtubeur Norman Thavaud en garde à vue pour viols et corruption de mineurs. Évalué à 2.
Pour clarifier : ce genre d'info n'a rien à faire sur LinuxFR.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# On s'en bats les couilles
Posté par David Delassus (site web personnel) . En réponse au lien Le youtubeur Norman Thavaud en garde à vue pour viols et corruption de mineurs. Évalué à 2.
https://www.youtube.com/watch?v=XoDY9vFAaG8
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: 404
Posté par David Delassus (site web personnel) . En réponse à la dépêche VulkanSceneGraph - Un graphe de scène en C++. Évalué à 2.
Nope, c'est du markdown bête et méchant :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# 404
Posté par David Delassus (site web personnel) . En réponse à la dépêche VulkanSceneGraph - Un graphe de scène en C++. Évalué à 3.
Les images des 2 précédents chapitres ne sont plus disponibles :(
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Old but gold
Posté par David Delassus (site web personnel) . En réponse au lien Mettre emacs à la place de systemd. Évalué à 3.
Je pense que cet article prédate systemd (corrigez moi si je me trompe).
En général, j'aime bien mettre le titre original de la page en guise de titre de lien, plutôt qu'une interprétation personnelle, je laisse ainsi chacun se faire son propre avis.
En tout cas, merci de ce repartage, c'est toujours un plaisir de le voir passer. Cet article regorge de ce qui m'a séduit à l'époque sous Linux: tu peux le bidouiller comme tu veux.
Même si aujourd'hui je ne bidouille plus mon système (manque de temps et de motivation), et que je tourne sous Windows, c'est quand même fun à voir.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg