Posté par barmic .
En réponse au journal Flatpak.
Évalué à 3.
Parce que tous ces outils vivent sur leur petite île langage spécifique et n'ont aucune compatibilité entre eux. En pratique, tu as trés rapidement un cas où tu veux utiliser une lib Rust associé à une lib C++ dans un module python
Non ça n'arrive pas tant que ça. De toute ma vie ça n'est arrivé qu'une fois en fait (je sais que tu va pouvoir citer pleins de cas, ça n'en fait pas la règle).
Tous ces outils sont orienté "devs" et généralement très peu approprié pour un utilisateur final
C'est normal, un utilisateur ne devrait pas avoir besoin de s'en servir. Et jouer au power user moijecompilemesprog ne rend pas cette remarque fausse. Tu veux jouer avec les outils des développeurs, très bien.
Tous ces outils téléchargent le monde en considérant que: Internet est toujours disponible, Installer spécifier les dépendences à la main est inutile.
Pour ceux que je connais, ils n'est pas nécessaire d'avoir internet, c'est juste l'option par défaut parce qu'elle convient au plus grand nombre. Et oui dans ton environ haute sécurité, on installe pas n'importe quoi ce qui par définition montre qu'il y a peu de programmes qui sont construit pour.
intrégration dans un écosystème plus grand qui a déjà des dépendances et où tu veux eviter les dépendances en Diamant
Sans cloisonnement ? Soit. Mais tu paie une complexité démesurée. La complexité des systèmes n'augmente pas linéairement avec la taille (je crois avoir lu qu'elle est plutôt quadratique) donc empiler les logiciels et leurs dépendances sans cloisonnement et se dire que ça doit marcher c'est à minima assez joueur...
Dans des contextes très sécurisés, on va être bien plus intéressé par la reproductibilité du build donc soit :
tu contrôle les dépendances du système
tu contrôle les dépendances de ton gestionnaire de fenêtre
Les 2 approches existent et son utilisés.
C'est la question des dev et des ops. Si les ops reprochent aux dev de ne pas utiliser les gestionnaires de dépendances systèmes, il faut bien comprendre que l'inverse est vrai aussi.
tu as un gestionnaire de dépendance par langage ? mais en avoir un par OS est-ce que c'est bien mieux ?
tu ne peux pas faire de mise à jour d'une lib système wide ? mais comment tu fais pour installer une dépendance sans être root ?
etc
Se plaindre c'est bien marrant (quoi que), mais personne n'arrive à spécifier un truc qui soit intéressant pour les 2 types d'utilisation
[^] # Re: Espace disque partagé...
Posté par barmic . En réponse au journal Flatpak. Évalué à 3.
Non ça n'arrive pas tant que ça. De toute ma vie ça n'est arrivé qu'une fois en fait (je sais que tu va pouvoir citer pleins de cas, ça n'en fait pas la règle).
C'est normal, un utilisateur ne devrait pas avoir besoin de s'en servir. Et jouer au power user moijecompilemesprog ne rend pas cette remarque fausse. Tu veux jouer avec les outils des développeurs, très bien.
Pour ceux que je connais, ils n'est pas nécessaire d'avoir internet, c'est juste l'option par défaut parce qu'elle convient au plus grand nombre. Et oui dans ton environ haute sécurité, on installe pas n'importe quoi ce qui par définition montre qu'il y a peu de programmes qui sont construit pour.
Sans cloisonnement ? Soit. Mais tu paie une complexité démesurée. La complexité des systèmes n'augmente pas linéairement avec la taille (je crois avoir lu qu'elle est plutôt quadratique) donc empiler les logiciels et leurs dépendances sans cloisonnement et se dire que ça doit marcher c'est à minima assez joueur...
Dans des contextes très sécurisés, on va être bien plus intéressé par la reproductibilité du build donc soit :
Les 2 approches existent et son utilisés.
C'est la question des dev et des ops. Si les ops reprochent aux dev de ne pas utiliser les gestionnaires de dépendances systèmes, il faut bien comprendre que l'inverse est vrai aussi.
Se plaindre c'est bien marrant (quoi que), mais personne n'arrive à spécifier un truc qui soit intéressant pour les 2 types d'utilisation