Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio Que :
$ apt install moment-js
$ yum install python-trio
Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
Debian ?
Ubuntu ?
Linux Mint ?
..?
RPM:
RedHat ?
CentOS ?
Fedora ?
..?
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
On a le même problème entre dire qu'on a une production Écologique et une production Bio.
Écologique/vert indique que tu suis une certaines philosophie, que ton produit fait son maximum pour être éco-responsable, ce qui a une signification précise. Non c'est pas QUE du marketing.
« le logiciel qui améliore la productivité de ton équipe ! » ou alors « Un outil de gestion de projet Agile ».
Oui, parce qu'il n'y a pas que la méthode Agile qui peut améliorer la productivité. Par exemple un logiciel d'automatisation comme Ansible, Puppet, Gitlab CI, … ça améliore la productivité de ton équipe et c'est pas une méthode Agile.
Les gens ont une certaine attente derrière l'expression "améliorer la productivité".
mais « Truth », c'est quoi ?
Instinctivement, je dirais que c'est un réseau social sans censure centralisée par un organisme privé. Donc ce qui tu y vois c'est la réalité du monde:
des gens qui disent des idioties
des gens qui font de la désinformation
des gens qui font du prosélytisme de leurs idées
des gens qui publient des facts
…
C'est ptet difficile à gober, mais non le monde n'est pas tout beau tout rose, la "vérité" c'est moche.
Pour conclure, je trouve ton avis réducteur et naïf.
quand un mot du genre "Vérité" ou "Liberté" (ou "écologique/vert") est mis en avant dans un produit, c'est pour masquer le fait que c'est un de ses défauts…
De plus les abonnements vont dans les poches de l'éditeur, pas forcément de l'auteur.
Je prend l'exemple de Medium qui a aussi un paywall après 5 articles lu gratuitement. Il faut minimum 100 followers et un certain nombre d'heure de lectures par d'autres membres pour pouvoir être rémunéré. Ce qui signifie qu'il y a un bon nombre d'article qui sont monétisés sans que rien n'aille dans la poche de l'auteur.
Sur le principe non, mais il existe d'autres solutions qu'un paywall. Je préfère avoir de la pub comme sur 20minutes plutôt que me dire "ah bon tant pis je lirais pas".
Les sites ou on est obligé d'être inscrit, voir de payer pour lire et où même la navigation privée ne fonctionne pas (contrairement à Medium), moi je dis non.
Ça sert à quoi de publier un lien si personne peut le lire ?
Qu'il y ait une raison, soit. Il y a toujours une raison pour faire les choses d'une certaine façon. Mais dire que cette façon de faire est plus KISS que le reste, c'est juste faux.
le dossier /bin, /usr/bin et /usr/local/bin permet d'avoir une gestion du PATH plus simple
le dossier /lib, /usr/lib, et /usr/local/lib permet de mutualiser les libs
le dossier /etc permet de centraliser la configuration admin
C'est une vision orientée système, et non orientée application. Franchement, regardez Gobolinux pour voir ce qu'il est possible de faire tout en restant compatible.
Chacune de ces visions répond à des besoins différents, et il s'avère que dans le second cas, on peut se passer d'un gestionnaire de paquet, et se la jouer à la Slackware (la seule distribution linux vraiment KISS).
Je ne vois pas en quoi c'est le bordel, au contraire c'est bien rangé.
Peut-être, mais quid de mon argument qui expose la nécessité d'avoir un gestionnaire de paquet pour savoir qui a installé quoi ?
Il n'y a rien qui t'empêche d'installer tout ce que tu veux dans /opt/ si ça te change.
Si tu m'as lu entièrement, c'est ce que je fais la plupart du temps.
Quoi de plus simple que de "tar xf appli.tgz -C /programs/appli" ?
Pourquoi un gestionnaire de paquet ne pourrait pas installer les dépendances dans /programs et /libraries et gérer les liens symboliques si nécessaire ?
En quoi c'est moins KISS que ce qui est fait aujourd'hui:
/usr/bin ou /usr/local/bin ou /bin
/usr/lib(64) ou /usr/local/lib ou /lib
/etc/appli
/usr/shared/appli
…
Aujourd'hui une appli est éclatée partout sur le système de fichier, et à moins d'avoir le gestionnaire de paquet pour:
te lister les fichiers installés par un paquet
te dire a quel paquet appartient tel fichier
Ben c'est pas "KISS" selon moi, alors que tout dans /programs/appli, ça l'est.
espace dans le chemin
Je parlais du concept derrière, pas du détail d'implem. Dans "/programs" il n'y a pas d'espaces.
pas mal d'applis qui peuvent -ou pas- le gérer correctement
Une appli n'est pas censée être dépendante de la où elle est installée. La preuve la majeure partie des softs sous linux peuvent être installé dans /bin, /usr/bin, /usr/local/bin, /home/user/.local/bin, /opt/appli/bin, etc…
Donc /programs/appli/bin ça change quoi ?
accès au dossier dépendant de la locale
Sous Windows, c'est l'explorateur qui fait la traduction. Il me semble que la plupart des bureaux GNOME te créent aussi des dossiers dans ton $HOME : Documents, Musics, Videos, etc… dépendant de la locale.
Si ls et cd gèrent que /programmes ca veut dire /programs, au niveau du FS j'ai toujours qu'un seul dossier.
Ou alors, si c'est pas possible, j'ai des liens symboliques (cc Gobolinux).
pour un gain pas particulièrement perceptible (pour rester pudique)
Windows a su se passer d'un gestionnaire de paquet depuis les 30 dernières années. Il est extrêmement simple de packager pour Windows. Et même la sauvegarde se résume à un simple copier/coller (pour peu que l'application n'utilise pas le registre windows).
D'ailleurs, la retro compatibilité de windows est phénoménale. Je peux installer MS-DOS et upgrade jusqu'à Windows 10 sans soucis.
Je peux travailler avec un installeur standalone, le Marketplace Microsoft, chocolatey, ou simplement copier coller les fichiers dans program files, rien ne se marche dans les pattes.
Essaye d'utiliser 2 gestionnaires de paquets différents sur un même système Linux, et bonjour les emmerdes.
Il est ou le KISS sous Linux ?
Et si tu es développeur, c'est encore pire. Je ne fais plus confiance à APT pour installer mes dépendances, heureusement en python il y a poetry/conda, en Go il y a go mod, en rust il y a cargo, en JS il y a npm/yarn, en Elixir il y a mix et avec Docker il y a ton registry favoris.
Je n'installe même plus mes interpréteurs/compilateurs via le gestionnaire de paquet. J'utilise :
install manuelle de python/elixir/go
nvm pour node
rustup pour rust
Docker n'est pas dans les dépôts officiels, mais ils fournissent le leur.
Au final, que je travaille sous Windows, dans un WSL, sur un Linux baremetal, mon workflow restera le même, car sous Linux je finis avec plus de choses dans /opt que dans le gestionnaire de paquet.
Perso j'évite le copyleft et les projets sous licence GPL au max.
Si je fais du libre, je fais sous licence MIT ou Apache-2.0, voir CC0 si c'est trivial, dépendre de code GPL m'empêcherai de distribuer sous ces licences.
Si je fais du proprio, je veux encore moins de code sous GPL.
AMHA, les licences GPL font plus de mal que de bien à l'écosystème à cause du flou juridique qu'est le copyleft.
GitHub, qui héberge à l’œil les trois quarts des projets libres de la planète?
Sans parler des Bugtrackers, Wiki, Github Pages, Github Packages (npm, docker, maven, nuget, …), Github Actions, Dependabot, et bien d'autres fonctionnalités qui assurent la qualité d'un nombre incalculable de projets.
Sans oublier qu'ils te permettent d'avoir un nombre infini de projet privé gratuitement. Ce qui est payant en général avec Github, c'est les organisations pour collaborer avec d'autres personnes sur des projets proprio.
M'est avis que la réponse est oui, tout comme n'importe quel projet libre qui s'inspirerait de code propriétaire se trouverait entacher par la connaissance de ce code.
Co-pilot ne fait pas un copier coller, il a apprit et produit du nouveau code.
Si je fais un tutoriel sous licence GPL (ou équivalent), est-ce que le code produit par les lecteurs doit être sous licence GPL ?
La réponse est bien évidemment non.
La vraie question c'est: où est la liste des logiciels dont le code a été utilisé pour entraîner cette abrutie artificielle ?
J'ai travaillé sur quelques projets proprio dans d'autres boites, j'y ai appris certains design pattern que j'utilise dans mes propres projets. Je leur doit des royalties ?
Non, et Github non plus ne doit rien à ces projets (si on exclus la reconnaissance).
Ce qui me fait penser au meme Tech Enthusiasts VS Engineers:
Tech Enthusiasts: Toute ma maison est connectée à l'Internet des Objets! Je contrôle tout depuis mon smartphone! Ma maison intelligente a du bluetooth et je peux lui donner des ordres avec Alexa! J'adore le futur!
Ingénieurs: L'équipement le plus récent que j'ai est une imprimante de 2004, et je garde un flingue chargé à côté au cas ou elle fait un bruit inattendu
Perso, ni mypy, ni pyre, ni pytype (google) n'ont su correctement analyser les annotations de type que j'avais (des TypedDict recursifs et des Union à droite à gauche).
Pire même, pytype ne supporte pas les TypedDict de Python 3.9 et nécessite donc un import de mypy_extensions (ce que je voudrais éviter dans du code en production).
Seul pyright (microsoft, développé en typescript :/ pour l'extension pylance de VSCode) par contre marche du tonnerre :)
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Donnez nous de la déduplication au niveau du système de fichier et ça règlera le problème.
Si tu fais tourner beaucoup de conteneurs Docker, tu as déjà de la dédup non négligeable lors du téléchargement grâce à son système de layers.
En tant qu'entreprise, distribuer un conteneur Docker est infiniment plus simple et pour nous (éditeur) et pour le client (utilisateur). Je sais que ça marchera pareil que sur nos environnements de test, et le client sait qu'il pourra le déployer comme le reste de ses applications.
J'adore Docker, et si j'avais pu avoir ça il y a 10 ans, ça m'aurait évité beaucoup de travail répétitif
et pénible dans ma carrière.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 1.
Le soucis des libs de 4 lignes c'est la pauvreté de la stdlib.
En Rust ça pose pas problème, c'est compilé statiquement. En Python la stdlib est colossale.
Ce que je voulais dire c'est que j'ai plus confiance dans :
$ yarn add moment
$ pip install trio
$ apt install moment-js
$ yum install python-trio
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Developers: Let distros do their job
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 0.
Premièrement, j'ai plus confiance dans NPM/PyPI/Hex.pm/Crates.io pour empaqueter correctement une lib du-dit langage que Debian par exemple.
Deuxièmement, ça a pas l'air de déranger les utilisateurs de Archlinux et AUR d'installer des paquets avec des logiciels potentiellement setuid root venant d'un repository non contrôlé.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Faites des paquets Debian pour vos applications
Posté par David Delassus (site web personnel) . En réponse au lien "Si vous maintenez une distribution Linux, je vous en supplie, n'utilisez pas Flatpak et Snap". Évalué à 3.
IMHO, c'est aux mainteneurs d'une distribution de créer les paquets pour cette dernière.
Qui d'autres qu'eux peuvent assurer la compatibilité de l'intégration avec le reste du système ?
Et surtout, si les développeurs devaient gérer eux mêmes la création des paquets pour toutes les distributions, ils n'auraient pas le temps de développer la-dite application…
cf Linux Distribution Timeline
Ok, bon disons que le développeur choisis DEB et RPM pour couvrir la plupart des utilisateurs. Il cible quelle distribution?
DEB:
RPM:
Je peux t'assurer que les développeurs solo et bénévole vont te caller un Makefile et un README en te disant de te débrouiller avec des instructions "qui marchent sur leurs machines".
Oui Flatpak, Snap, et compagnie ne sont pas des solutions idéales d'un point de vue mainteneur de distribution (doublons de runtime, et toute la ribambelle d'argument que tu peux trouver à droite/à gauche sur le net).
Mais d'un point de vue développeur c'est un moyen de cibler tout le monde sans se poser de question.
Et d'un point de vue utilisateur c'est un moyen d'avoir des applications populaires sans devoir faire une pétition aux mainteneurs de la distribution qui sont occupés à avoir des débats stériles sur le vocabulaire autorisé.
Alors cet article m'a fait beaucoup rire d'ailleurs. A un moment il parle de Windows:
Oui bon, en même temps tu n'as qu'une seule "distribution" Windows contrairement au monde de Linux.
Les gens commencent-ils à se rendre compte que "trop de choix tue le choix ?" après avoir perdu une soirée à chercher quelque chose de correct sur Netflix ?
Quid donc d'une "distribution" Linux n'incluant que le noyau, systemd et Flatpak ? (au passage, c'est pas le choix de ElementaryOS ?).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Le réseau où la vérité est un argument marleting.
Posté par David Delassus (site web personnel) . En réponse au lien Le réseau social de Trump serait basé sur Mastodon et ne respecterait pas sa licence. Évalué à 1.
Écologique/vert indique que tu suis une certaines philosophie, que ton produit fait son maximum pour être éco-responsable, ce qui a une signification précise. Non c'est pas QUE du marketing.
Oui, parce qu'il n'y a pas que la méthode Agile qui peut améliorer la productivité. Par exemple un logiciel d'automatisation comme Ansible, Puppet, Gitlab CI, … ça améliore la productivité de ton équipe et c'est pas une méthode Agile.
Les gens ont une certaine attente derrière l'expression "améliorer la productivité".
Instinctivement, je dirais que c'est un réseau social sans censure centralisée par un organisme privé. Donc ce qui tu y vois c'est la réalité du monde:
C'est ptet difficile à gober, mais non le monde n'est pas tout beau tout rose, la "vérité" c'est moche.
Pour conclure, je trouve ton avis réducteur et naïf.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Le réseau où la vérité est un argument marleting.
Posté par David Delassus (site web personnel) . En réponse au lien Le réseau social de Trump serait basé sur Mastodon et ne respecterait pas sa licence. Évalué à 5.
OpenBSD, FreeBSD, LibreOffice, OpenSSL/LibreSSL, …
Quand tu lances la flèche de la vérité, trempe toujours la pointe dans du miel.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Vive les paywalls et autres conneries
Posté par David Delassus (site web personnel) . En réponse au lien It’s Time to Stop Paying for a VPN. Évalué à 1.
De plus les abonnements vont dans les poches de l'éditeur, pas forcément de l'auteur.
Je prend l'exemple de Medium qui a aussi un paywall après 5 articles lu gratuitement. Il faut minimum 100 followers et un certain nombre d'heure de lectures par d'autres membres pour pouvoir être rémunéré. Ce qui signifie qu'il y a un bon nombre d'article qui sont monétisés sans que rien n'aille dans la poche de l'auteur.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Vive les paywalls et autres conneries
Posté par David Delassus (site web personnel) . En réponse au lien It’s Time to Stop Paying for a VPN. Évalué à 2.
Tu as 5 articles gratuit par mois, ensuite: paywall
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Vive les paywalls et autres conneries
Posté par David Delassus (site web personnel) . En réponse au lien It’s Time to Stop Paying for a VPN. Évalué à -4.
Sur le principe non, mais il existe d'autres solutions qu'un paywall. Je préfère avoir de la pub comme sur 20minutes plutôt que me dire "ah bon tant pis je lirais pas".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Vive les paywalls et autres conneries
Posté par David Delassus (site web personnel) . En réponse au lien It’s Time to Stop Paying for a VPN. Évalué à 3.
Les sites ou on est obligé d'être inscrit, voir de payer pour lire et où même la navigation privée ne fonctionne pas (contrairement à Medium), moi je dis non.
Ça sert à quoi de publier un lien si personne peut le lire ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à -1.
Mauvaise fois.
Dans mon cerveau ça fait tilt que tout ce qui est listé a été installé par firefox.
Dans mon cerveau ça fait pas tilt a qui appartient les 1400 binaires qu'on y trouve.
Et j'explore plus souvent mon système à coup de cd et ls qu'avec un package manager.
Oui, mais rien n'empêche le reste de l'OS d'aller chercher ces informations dans le dossier de l'application.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 3.
DOS au moins, c'était KISS.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 2.
Qu'il y ait une raison, soit. Il y a toujours une raison pour faire les choses d'une certaine façon. Mais dire que cette façon de faire est plus KISS que le reste, c'est juste faux.
C'est une vision orientée système, et non orientée application. Franchement, regardez Gobolinux pour voir ce qu'il est possible de faire tout en restant compatible.
Chacune de ces visions répond à des besoins différents, et il s'avère que dans le second cas, on peut se passer d'un gestionnaire de paquet, et se la jouer à la Slackware (la seule distribution linux vraiment KISS).
Peut-être, mais quid de mon argument qui expose la nécessité d'avoir un gestionnaire de paquet pour savoir qui a installé quoi ?
Si tu m'as lu entièrement, c'est ce que je fais la plupart du temps.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 1.
Oui NixOS est carrément une avancée dans le domaine, surtout au niveau config a un seul endroit <3
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 2. Dernière modification le 24 août 2021 à 02:41.
Allez, je vais faire l'avocat du diable.
Quoi de plus simple que de "tar xf appli.tgz -C /programs/appli" ?
Pourquoi un gestionnaire de paquet ne pourrait pas installer les dépendances dans /programs et /libraries et gérer les liens symboliques si nécessaire ?
En quoi c'est moins KISS que ce qui est fait aujourd'hui:
Aujourd'hui une appli est éclatée partout sur le système de fichier, et à moins d'avoir le gestionnaire de paquet pour:
Ben c'est pas "KISS" selon moi, alors que tout dans /programs/appli, ça l'est.
Je parlais du concept derrière, pas du détail d'implem. Dans "/programs" il n'y a pas d'espaces.
Une appli n'est pas censée être dépendante de la où elle est installée. La preuve la majeure partie des softs sous linux peuvent être installé dans /bin, /usr/bin, /usr/local/bin, /home/user/.local/bin, /opt/appli/bin, etc…
Donc /programs/appli/bin ça change quoi ?
Sous Windows, c'est l'explorateur qui fait la traduction. Il me semble que la plupart des bureaux GNOME te créent aussi des dossiers dans ton $HOME : Documents, Musics, Videos, etc… dépendant de la locale.
Si ls et cd gèrent que /programmes ca veut dire /programs, au niveau du FS j'ai toujours qu'un seul dossier.
Ou alors, si c'est pas possible, j'ai des liens symboliques (cc Gobolinux).
Windows a su se passer d'un gestionnaire de paquet depuis les 30 dernières années. Il est extrêmement simple de packager pour Windows. Et même la sauvegarde se résume à un simple copier/coller (pour peu que l'application n'utilise pas le registre windows).
D'ailleurs, la retro compatibilité de windows est phénoménale. Je peux installer MS-DOS et upgrade jusqu'à Windows 10 sans soucis.
Je peux travailler avec un installeur standalone, le Marketplace Microsoft, chocolatey, ou simplement copier coller les fichiers dans program files, rien ne se marche dans les pattes.
Essaye d'utiliser 2 gestionnaires de paquets différents sur un même système Linux, et bonjour les emmerdes.
Il est ou le KISS sous Linux ?
Et si tu es développeur, c'est encore pire. Je ne fais plus confiance à APT pour installer mes dépendances, heureusement en python il y a poetry/conda, en Go il y a go mod, en rust il y a cargo, en JS il y a npm/yarn, en Elixir il y a mix et avec Docker il y a ton registry favoris.
Je n'installe même plus mes interpréteurs/compilateurs via le gestionnaire de paquet. J'utilise :
Docker n'est pas dans les dépôts officiels, mais ils fournissent le leur.
Au final, que je travaille sous Windows, dans un WSL, sur un Linux baremetal, mon workflow restera le même, car sous Linux je finis avec plus de choses dans /opt que dans le gestionnaire de paquet.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à -2.
Sincèrement, c'est quoi le soucis avec "Program Files" ?
Avant qu'on me réponde : "ça duplique les fichiers (ex: les dlls)" :
C'est facile de voir ce qui est installé avec un simple "ls".
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: un point intéressant pour la prochaine version (la 12 aka bookworm)
Posté par David Delassus (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 5.
Tu veux dire https://www.gobolinux.org/ ?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Un sacré merdier ?
Posté par David Delassus (site web personnel) . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 0.
Perso j'évite le copyleft et les projets sous licence GPL au max.
Si je fais du libre, je fais sous licence MIT ou Apache-2.0, voir CC0 si c'est trivial, dépendre de code GPL m'empêcherai de distribuer sous ces licences.
Si je fais du proprio, je veux encore moins de code sous GPL.
AMHA, les licences GPL font plus de mal que de bien à l'écosystème à cause du flou juridique qu'est le copyleft.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Pas sur de comprendre
Posté par David Delassus (site web personnel) . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 10.
Sans parler des Bugtrackers, Wiki, Github Pages, Github Packages (npm, docker, maven, nuget, …), Github Actions, Dependabot, et bien d'autres fonctionnalités qui assurent la qualité d'un nombre incalculable de projets.
Sans oublier qu'ils te permettent d'avoir un nombre infini de projet privé gratuitement. Ce qui est payant en général avec Github, c'est les organisations pour collaborer avec d'autres personnes sur des projets proprio.
Le savais-tu?
Oui non c'est vrai que tout ça montre bien que Github s'en fou du libre :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Un sacré merdier ?
Posté par David Delassus (site web personnel) . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 6.
Si π n'est pas un nombre univers, alors ce système de fichier[1] risque de causer pas mal de pertes de données.
[1] - https://github.com/philipl/pifs
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: je marche dedans ! Zenitram impersonation time !
Posté par David Delassus (site web personnel) . En réponse au journal GitHub lance copilot, un générateur de code entraîné sur du code GPL. Évalué à 9.
Co-pilot ne fait pas un copier coller, il a apprit et produit du nouveau code.
Si je fais un tutoriel sous licence GPL (ou équivalent), est-ce que le code produit par les lecteurs doit être sous licence GPL ?
La réponse est bien évidemment non.
J'ai travaillé sur quelques projets proprio dans d'autres boites, j'y ai appris certains design pattern que j'utilise dans mes propres projets. Je leur doit des royalties ?
Non, et Github non plus ne doit rien à ces projets (si on exclus la reconnaissance).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Boss finaux de l'IT
Posté par David Delassus (site web personnel) . En réponse au journal SFR rejettent les mails de Framaliste. Évalué à 10. Dernière modification le 25 juin 2021 à 16:31.
Ce qui me fait penser au meme Tech Enthusiasts VS Engineers:
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: RejetteNT?
Posté par David Delassus (site web personnel) . En réponse au journal SFR rejettent les mails de Framaliste. Évalué à 0.
SFR c'est pas un groupe réunissant plusieurs entités?
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Type Checking
Posté par David Delassus (site web personnel) . En réponse à la dépêche Python — partie 9 ― formateur de code, analyse statique. Évalué à 4.
Perso, ni mypy, ni pyre, ni pytype (google) n'ont su correctement analyser les annotations de type que j'avais (des TypedDict recursifs et des Union à droite à gauche).
Pire même, pytype ne supporte pas les TypedDict de Python 3.9 et nécessite donc un import de mypy_extensions (ce que je voudrais éviter dans du code en production).
Seul pyright (microsoft, développé en typescript :/ pour l'extension pylance de VSCode) par contre marche du tonnerre :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Belle exemple du gain en lisibilité
Posté par David Delassus (site web personnel) . En réponse au journal Constexpr versus template. Évalué à 2.
Faut pas oublier npm qui essaye de résoudre des dépendances, et rust qui essaye de vérifier la memory-safety de ton programme :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg