Non, df -h -x squashfs n'est pas acceptable, ça devrait être un opt-in.
C'est un choix de distribution. L'utilisation des .deb n'est pas en opti-in, le choix de bash comme login shell par défaut n'est pas en opt-in, etc. C'est une distribution elle représente une vision en elle-même soit tu adhère, soit tu configure, soit tu en choisi à la quelle tu adhère (ou que tu veux bien configuré). C'est le principe des distributions ça l'a toujours était. Ne vient pas nous dire que tu découvre. Tu pense qu'il n'en existe pas assez ?
pourquoi ça me travaille ? c'est parceque YouTube est le seul service de Google que j'utilise et que j'aimerais disparaître de la vue de Google…
Je trouve ça vraiment bizarre. Tu utilise leur service. Tenter de faire des pieds et des mains pour continuer à les utiliser "sans qu'ils ne te voient", passer par n'importe quel intermédiaires dont on sait pas grand-chose (ça n'a pas l'air d'être très important dans ton journal) moi je trouve ça vraiment bizarre. Résoud ton cas de conscience arrête de te servir de YouTube c'est plus simple. Tu gagnera du temps. Surtout qu'il a des alternatives.
Note que je pense aussi la même chose des moteurs de recherche qui ne sont que des surcouches comme startpage ou ddg. C'est pas viable comme principe. Vous dependez toujours autant de Google, mais vous vous faites croire que vous êtes des antigoogle.
Trottinette à assistance électrique ? Je ne connais pas. Les trottinettes électriques ne sont pas à assistance. Tu appuie sur le bouton ça avance, en fait ça doit même être plutôt dangereux de tenter de pousser quand le moteur est enclenché. Là où le VAE ne fait qu'améliorer ton pédalage. Si tu ne pédale pas, tu n'a pas de moteur.
je trouvais ça abusé d’indexer des entiers naturels
:) ben si quelque soit la solution de stockage que tu choisi. Un index ça sert à ne pas parcourir la totalité de tes données (c'que les english appellent fullscan). Même s'il s'agit d'un booléen, si tu n'a pas d'index ton moteur de stockage doit parcourir toutes tes données les unes après les autres pour te données un résultat. Un index lui permet d'avoir plus d'info sur les données stockées sans avoir à les parcourir.
un champ qui augmentait considérablement la taille des documents (+15ko)
C'est clairement ce qui fais généralement le plus de mal à mongo : augmenter la taille des documents.
Je ne sais pas si ça vient du modèle de NoSQL, mais quand on parle de big data on pense plus facilement à cassandra ou hbase qui sont une magnitude au dessus amha.
Scoop : tu peux même publier ton source contenant ton include, sans aucune préoccupation vis à vis de la licence du projet truc (GPL ou non), et sans aucune inquiétude de quelque sorte.
Ce noyage de poisson… Tu reporte juste la question à celui qui ça utiliser ton travaille. C'est pas avec ce genre de réflexion que la gpl ou le projet gnu ou la fsf vont se grandir.
Il n'est pas question d'hérédité avec la gpl puisqu'elle impose sa licence au code lié. La LGPL a une hérédité par contre. Après si vitalité ne plaît pas choisissez un terme qui vous plaît plus, juste qu'il corresponde à la réalité.
Pour ton second problème, ça n'est pas forcément choquant. Est-ce que le champ en question est indexé ? Quelle taille font tes documents ? Est-ce que tu fais une projection de très données ?
Il n'y a que sqlite et derby qui sont prévus pour 5000 entrées. Mongo ne possède pas un gros overead en principe. Mais surtout il est pas vraiment fait pour de gros volume. Ça n'est vraiment pas une base taillée pour le big data (ça ne monte pas vraiment en charge en fait).
Sur un système digne de ce non, Qt est installé au niveau système, il n'a pas a venir avec chaque exécutable.
Dans ce cas il faut justement éviter le linkage statique, en effet; pour la première application qui se lance et qui utilise Qt, les librairies sont chargées en mémoire, les suivantes se lance rapidement car elle ne font que les ré-utiliser…
Que le monde est beau ! Les oiseaux chantent ! Les méchants sont habillés en noir, les gentils en blanc,…
Ce que tu dis est tellement proche de la réalité que l'on a pas de problème de packaging sous linux. Donc pas de guerre des gestionnaires de paquet, on a pas besoin des snap/appimage/flatpak, docker n'existe pas,…
Posté par barmic .
En réponse au journal Flatpak.
Évalué à 3.
C'est intéressant. Il y a quoi pour faire de la distribution en rust ? Il me semble que dans ce milieu l'écosystème est au moins aussi important que le langage lui même. J'entends partout que la JVM est bloated et que tel ou tel langage fais 10, 100 ou 1000 fois mieux, alors qu'on voit du Spark et du Kafka. Cassandra a peut être un concurrent mais ScyllaDB n'est pas encore très populaire (voir sur google trend).
Si c'est plus pour tourner sur supercalculateurs, l'écosystème est encore différent. Je vois un binding d'MPI qui a l'air prométeur mais peut être un peu jeune : rsmpi. Il y a aussi timely dataflow qui me semble un peu plus mature. Je connais mal se monde. C'est tout ce dont il y a besoin ? J'imagine qu'il faut une bibliothèque de calcul et une pour gérer la mémoire efficacement (consommer toute la mémoire vive et pouvoir la persister pour pouvoir reprendre les calculs en cas de problème).
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
Posté par barmic .
En réponse au journal Flatpak.
Évalué à 6.
Dernière modification le 12 octobre 2018 à 11:47.
Je n’ai pas dis que ça ne servait à rien en prod[…]
Tu as écris :
Effectivement Docker ne sert à rien (en tout cas en prod)
Je l'invente pas.
(t'es relou avec tes liens pas nommés…) mais c'est cool tu as des arguments :)
Pour « Au secours, ma prod est sous Docker (Francois Teychene) », il mélange sidecar et docker in docker. Un sidecar n'a pas besoin d'accéder à la socket docker, la définition d'un sidecar c'est de partager des namespaces. Par contre effectivement traeffic peut utiliser la socket docker (mais tu peux très bien t'en servir sans). Ensuite tu peux ne pas donner accès à la socket unix, mais passer par du http (les 2 sont du rest) et donc ajouter une couche de sécurité avec un reverse proxy.
Pour « Containers, VMs… Comment ces technologies fonctionnent et comment les différencier? (Quentin Adam) » (j'aime beaucoup ce gars) et oui il faut choisir (ou construire) intelligemment ses images de base. Pour le fait qu'il utilise une vm par client, ça ne me choque pas. Les problèmes de clevercloud ne sont pas les même que celui du développeur moyen. Rien que les manque en terme de limitation de consommations de ressources font que tu ne peux pas te servir uniquement de docker pour ça.
Posté par barmic .
En réponse au journal Flatpak.
Évalué à 10.
Effectivement Docker ne sert à rien (en tout cas en prod) parce que tu peux utiliser LXC & cie, et parce qu’il apporte plus de problèmes qu’il n’en résout (problème du monitoring, mise-à-jour, maîtrise de l’environnement, etc).
Il est mignon…
Alors déjà affirmer que docker ne sert à rien parce que tu peux utiliser LXC c'est euh… Ce sont 2 softs qui font à peu prêt la même chose. Les 2 se basent sur les namespaces et chroot pour produire des environnements maîtrisés.
Docker est massivement utilisé en production et ce n'est pas pour rien:
l'utilisation d'images réutilisables entre tes environnements t'aident à avoir quelque chose de vraiment reproductible
l'utilisation d'images permet aussi une interopérabilité entre hébergeurs
ça a permis l'arrivé de techno comme istio ou traefik1
les surcouches comme swarm, mesos, k8s simplifient fortement les déploiements, y compris les déploiements complexes et les plateformes élastiques
Tu peux faire sans, ce n'est pas une nécessité loin de là, mais affirmer que ça ne sert à rien en prod c'est faux.
les 2 sont une démonstration du fait qu'il est tout à fait possible de monitorer du docker entre autre ↩
Posté par barmic .
En réponse à la dépêche mat2 0.4.0.
Évalué à 2.
Le fait qu'ils aient mis Cyberpunks, les punks se réclamants anarchistes me fait me demander si ce n'est pas justement pour pouvoir se dédouaner qu'ils ont trouvé des rétroacronymes. C'est un peu comme quand on chante que le roi Dagobert ne sait pas s'habiller…
GraalVM is a universal virtual machine for running applications written in JavaScript, Python 3, Ruby, R, JVM-based languages like Java, Scala, Kotlin, and LLVM-based languages such as C and C++.
Je ne suis pas d'accord que ça soit un usage « totalement à la marge » : le projet GNU a établit des standards https://www.gnu.org/prep/standards/standards.html qui, lorsqu'ils sont suivis (en utilisant les autotools) permettent de correctement distribuer un travail (on parle de « distribution » dans la terminologie autotools pour désigner un tarball d'une version donnée d'un logiciel).
Je sais pas comment le dire autrement. Ça fait déjà un paquet de fois que je le dis, mais bon…
Tu ne pourra jamais respecter ce standard sans utiliser les autotools. Jamais. Tu peux tenter d'y ressembler, mais ton configure ne ferra pas la même chose, ton make sera différent et ton make install.
L'intérêt de ce standard ce n'est pas d'avoir un script configure et d'utiliser make, mais de décrire ce que font chacune de ses étapes et comment elles le font. Hors quand tu utilise meson ils ne feront pas la même chose ou de la même façon. C'est ce qui permet à d'autres outils de s'interfacer avec (pense à checkinstall). Produire un simulacre d'autotools s'apparenterait plus à du « Embrace, extend and extinguish » qu'autre chose.
Du coup :
Et dire que c'est juste « changer les habitudes » de quelques utilisateurs, oui, si tu veux… mais alors pourquoi a-t-on inventé les distributions pour englober / uniformiser ça ? Parce les utilisateurs ne veulent pas juste s'emmerder.
Oui le fait d'avoir les même commandes exactement ce n'est qu'une question d'habitude et pas de standard. Si vous êtes satisfait avec les commandes c'est que le standard ne vous intéresse pas tant que ça et que c'est plus une question d'habitude des commandes.
Une solution pourrait être que meson génère un dist un tar.gz qui ne dépend que des autotools, mais ça signifie qu'il produit une seconde chaîne de build et s'assurer que les 2 sont bien équivalentes est très compliqué.
Par système de packaging, j'entendais gestionnaire de paquets (désolé c'était pas clair). Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
Bien sûr que ton build peut générer des artifacts qui sont des packages que ce soit pour des linuxeries (deb/rpm/flatpack) voir pour des trucs comme des images docker ou autre.
Bref, point de vue utilisateur du logiciel (depuis les sources, donc utilisateur avancé quand même), pas besoin même de « système de build » puisque du point de vue de celui qui exécute ./configure, autotools n'est pas nécessaire.
En fait on s'en fout pas mal de son point de vu. Ce que vous voulais c'est un système de packaging de sources standard hors ça n'existe pas parce qu'il y a pleins de projets qui ont déjà un système différents. On parle de C et C++, mais si tu joue avec des programmes en python, en java, en go, en rust, en js,… tu aura des dizaines de builder et c'est normale. Le build est un outil du développeur. Lui il l'exécute plusieurs dizaines de fois par jours. La minute qu'il perd à cause de sont build peut facilement représenter des dizaines de minutes dans la journée, ralentir son intégration continue ça ralenti tous sont travaille, ne pas pouvoir lancer un build + les tests tout le temps ça nuit à la qualité de ce qu'il te fourni.
À coté de ça changer les habitudes de quelques utilisateurs qui ne veulent pas lire un fichier INSTALL et qui ne veulent pas changer leur 3 commandes (alors qu'ils vont bien devoir installe meson, python et ninja !). Ça ne représente pas un intérêt énorme.
Les packageurs de distribution sont déjà habitués à gérer un paquet de builder différents (tu as même Debian (et d'autres je présume) qui fait des builds via différent compilateurs).
Le builder est un outil du développeurs, pas un système de packaging.
Tu es donc exactement dans la situation décrite par le xkcd ; tu crées un système alternatif avec l'espoir qu'il remplace à terme l'existant, mais tu crées juste une nouvelle syntaxe qui s'additionne aux systèmes de build alternatifs qui existent.
Non tu crée un build plus rapide parce que ton build est lent. Je ne pense pas que meson ai vocation à gouverner le monde.
Je pense justement que le coût d'une dépendance à un logiciel qui est installé par défaut sur la quasi-totalité des distributions et un wrapper trivial est minime par rapport au coût d'être dans l'inconnu total quand tu télécharges un .tar.gz.
Tu aura toujours besoin de découvrir qu'il faut installer meson, python et ninja, hein ? Les 3 pauvres commandes ne changent pas grand chose au problème du « qu'est-ce que je fais quand je télécharge un .tar.gz ? »
Posté par barmic .
En réponse à la dépêche E.T. téléphone Meson.
Évalué à 4.
Dernière modification le 08 octobre 2018 à 11:12.
Ça n'est pas un standard et ça n'a pas vocation à l'être. Des outils de builds il y en a déjà un tas, on a pas attendu meson pour que ce soit l'anarchie.
Pourquoi ne pas s'être débrouillé pour que tout système de build génère par défaut un exécutable "configure" dans le répertoire, un Makefile minimal de trois lignes qui appelle ninja ou n'importe quoi d'autre, avec une cible "install" qui installe le truc? C'est ça le problème, c'est l'apparition de nouvelles syntaxes pour faire la même chose qu'avant.
Parce que ça ne changerait rien au problème ? Ça te gêne d'avoir d'autres commandes que ./configure && make && make install, mais le fais qu'il soit nécessaire d'installer ninja avant ne te gène pas ? Ou que les outils comme checkinstall ne fonctionnent plus ?
Tenter de ressembler, mais ne pas être compatible est bien pire que d'être plus ou moins compatible. Tout ça pour qu'au final la proportion de gars qui font des installations depuis les sources soit ridicules (d'autant qu'ils ont juste des commandes différentes à utiliser) face au temps passé par les dev et les intégrateurs à faire des builds un paquet de fois par jour (et leurs serveurs qui font ça en boucle).
[^] # Re: C'est quoi le problème ?
Posté par barmic . En réponse au journal Est-ce qu'on est sérieux?. Évalué à 6.
C'est un choix de distribution. L'utilisation des .deb n'est pas en opti-in, le choix de bash comme login shell par défaut n'est pas en opt-in, etc. C'est une distribution elle représente une vision en elle-même soit tu adhère, soit tu configure, soit tu en choisi à la quelle tu adhère (ou que tu veux bien configuré). C'est le principe des distributions ça l'a toujours était. Ne vient pas nous dire que tu découvre. Tu pense qu'il n'en existe pas assez ?
# Incongru
Posté par barmic . En réponse au journal Voir les vidéos YouTube en ligne sans être vu de Google. Évalué à 7.
Je trouve ça vraiment bizarre. Tu utilise leur service. Tenter de faire des pieds et des mains pour continuer à les utiliser "sans qu'ils ne te voient", passer par n'importe quel intermédiaires dont on sait pas grand-chose (ça n'a pas l'air d'être très important dans ton journal) moi je trouve ça vraiment bizarre. Résoud ton cas de conscience arrête de te servir de YouTube c'est plus simple. Tu gagnera du temps. Surtout qu'il a des alternatives.
Note que je pense aussi la même chose des moteurs de recherche qui ne sont que des surcouches comme startpage ou ddg. C'est pas viable comme principe. Vous dependez toujours autant de Google, mais vous vous faites croire que vous êtes des antigoogle.
[^] # Re: Hum...
Posté par barmic . En réponse au journal Le VAE n'est PAS un truc de fainéant. Évalué à 9.
Trottinette à assistance électrique ? Je ne connais pas. Les trottinettes électriques ne sont pas à assistance. Tu appuie sur le bouton ça avance, en fait ça doit même être plutôt dangereux de tenter de pousser quand le moteur est enclenché. Là où le VAE ne fait qu'améliorer ton pédalage. Si tu ne pédale pas, tu n'a pas de moteur.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . En réponse au journal SSPL: All your service are belong to us. Évalué à 4.
:) ben si quelque soit la solution de stockage que tu choisi. Un index ça sert à ne pas parcourir la totalité de tes données (c'que les english appellent fullscan). Même s'il s'agit d'un booléen, si tu n'a pas d'index ton moteur de stockage doit parcourir toutes tes données les unes après les autres pour te données un résultat. Un index lui permet d'avoir plus d'info sur les données stockées sans avoir à les parcourir.
C'est clairement ce qui fais généralement le plus de mal à mongo : augmenter la taille des documents.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . En réponse au journal SSPL: All your service are belong to us. Évalué à 6.
Je ne sais pas si ça vient du modèle de NoSQL, mais quand on parle de big data on pense plus facilement à cassandra ou hbase qui sont une magnitude au dessus amha.
[^] # Re: Sémantique toxique
Posté par barmic . En réponse au journal SSPL: All your service are belong to us. Évalué à 4.
Ce noyage de poisson… Tu reporte juste la question à celui qui ça utiliser ton travaille. C'est pas avec ce genre de réflexion que la gpl ou le projet gnu ou la fsf vont se grandir.
Il n'est pas question d'hérédité avec la gpl puisqu'elle impose sa licence au code lié. La LGPL a une hérédité par contre. Après si vitalité ne plaît pas choisissez un terme qui vous plaît plus, juste qu'il corresponde à la réalité.
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . En réponse au journal SSPL: All your service are belong to us. Évalué à 3.
Pour ton second problème, ça n'est pas forcément choquant. Est-ce que le champ en question est indexé ? Quelle taille font tes documents ? Est-ce que tu fais une projection de très données ?
[^] # Re: Le mieux est d’utiliser une autre DB
Posté par barmic . En réponse au journal SSPL: All your service are belong to us. Évalué à 3.
Il n'y a que sqlite et derby qui sont prévus pour 5000 entrées. Mongo ne possède pas un gros overead en principe. Mais surtout il est pas vraiment fait pour de gros volume. Ça n'est vraiment pas une base taillée pour le big data (ça ne monte pas vraiment en charge en fait).
[^] # Re: Une page qui se tourne
Posté par barmic . En réponse au journal Fin du service SWITCHmirror . Évalué à 3.
Pour des gestionnaires de paquets je comprends bien, pour des images iso je vois pas vraiment l'intérêt face au P2P.
[^] # Re: Qt static
Posté par barmic . En réponse au journal Réduire la taille des exécutables générés avec PyInstaller. Évalué à 1.
Que le monde est beau ! Les oiseaux chantent ! Les méchants sont habillés en noir, les gentils en blanc,…
Ce que tu dis est tellement proche de la réalité que l'on a pas de problème de packaging sous linux. Donc pas de guerre des gestionnaires de paquet, on a pas besoin des snap/appimage/flatpak, docker n'existe pas,…
Ou alors ce n'est pas si simple ?
[^] # Re: Espace disque partagé...
Posté par barmic . En réponse au journal Flatpak. Évalué à 3.
C'est intéressant. Il y a quoi pour faire de la distribution en rust ? Il me semble que dans ce milieu l'écosystème est au moins aussi important que le langage lui même. J'entends partout que la JVM est bloated et que tel ou tel langage fais 10, 100 ou 1000 fois mieux, alors qu'on voit du Spark et du Kafka. Cassandra a peut être un concurrent mais ScyllaDB n'est pas encore très populaire (voir sur google trend).
Si c'est plus pour tourner sur supercalculateurs, l'écosystème est encore différent. Je vois un binding d'MPI qui a l'air prométeur mais peut être un peu jeune : rsmpi. Il y a aussi timely dataflow qui me semble un peu plus mature. Je connais mal se monde. C'est tout ce dont il y a besoin ? J'imagine qu'il faut une bibliothèque de calcul et une pour gérer la mémoire efficacement (consommer toute la mémoire vive et pouvoir la persister pour pouvoir reprendre les calculs en cas de problème).
[^] # 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
[^] # Re: Dépendances
Posté par barmic . En réponse au journal Flatpak. Évalué à 6. Dernière modification le 12 octobre 2018 à 11:47.
Tu as écris :
Je l'invente pas.
(t'es relou avec tes liens pas nommés…) mais c'est cool tu as des arguments :)
Pour « Au secours, ma prod est sous Docker (Francois Teychene) », il mélange sidecar et docker in docker. Un sidecar n'a pas besoin d'accéder à la socket docker, la définition d'un sidecar c'est de partager des namespaces. Par contre effectivement traeffic peut utiliser la socket docker (mais tu peux très bien t'en servir sans). Ensuite tu peux ne pas donner accès à la socket unix, mais passer par du http (les 2 sont du rest) et donc ajouter une couche de sécurité avec un reverse proxy.
Pour « Containers, VMs… Comment ces technologies fonctionnent et comment les différencier? (Quentin Adam) » (j'aime beaucoup ce gars) et oui il faut choisir (ou construire) intelligemment ses images de base. Pour le fait qu'il utilise une vm par client, ça ne me choque pas. Les problèmes de clevercloud ne sont pas les même que celui du développeur moyen. Rien que les manque en terme de limitation de consommations de ressources font que tu ne peux pas te servir uniquement de docker pour ça.
[^] # Re: Dépendances
Posté par barmic . En réponse au journal Flatpak. Évalué à 10.
Il est mignon…
Alors déjà affirmer que docker ne sert à rien parce que tu peux utiliser LXC c'est euh… Ce sont 2 softs qui font à peu prêt la même chose. Les 2 se basent sur les namespaces et chroot pour produire des environnements maîtrisés.
Docker est massivement utilisé en production et ce n'est pas pour rien:
Tu peux faire sans, ce n'est pas une nécessité loin de là, mais affirmer que ça ne sert à rien en prod c'est faux.
les 2 sont une démonstration du fait qu'il est tout à fait possible de monitorer du docker entre autre ↩
[^] # Re: ACAB?
Posté par barmic . En réponse à la dépêche mat2 0.4.0. Évalué à 1. Dernière modification le 12 octobre 2018 à 08:51.
supprimé pour cause de doublon…
[^] # Re: ACAB?
Posté par barmic . En réponse à la dépêche mat2 0.4.0. Évalué à 2.
Le fait qu'ils aient mis Cyberpunks, les punks se réclamants anarchistes me fait me demander si ce n'est pas justement pour pouvoir se dédouaner qu'ils ont trouvé des rétroacronymes. C'est un peu comme quand on chante que le roi Dagobert ne sait pas s'habiller…
[^] # Re: Aucun !
Posté par barmic . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 2.
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 4.
Je sais pas comment le dire autrement. Ça fait déjà un paquet de fois que je le dis, mais bon…
Tu ne pourra jamais respecter ce standard sans utiliser les autotools. Jamais. Tu peux tenter d'y ressembler, mais ton configure ne ferra pas la même chose, ton
makesera différent et tonmake install.L'intérêt de ce standard ce n'est pas d'avoir un script
configureet d'utilisermake, mais de décrire ce que font chacune de ses étapes et comment elles le font. Hors quand tu utilise meson ils ne feront pas la même chose ou de la même façon. C'est ce qui permet à d'autres outils de s'interfacer avec (pense àcheckinstall). Produire un simulacre d'autotools s'apparenterait plus à du « Embrace, extend and extinguish » qu'autre chose.Du coup :
Oui le fait d'avoir les même commandes exactement ce n'est qu'une question d'habitude et pas de standard. Si vous êtes satisfait avec les commandes c'est que le standard ne vous intéresse pas tant que ça et que c'est plus une question d'habitude des commandes.
Une solution pourrait être que meson génère un dist un
tar.gzqui ne dépend que des autotools, mais ça signifie qu'il produit une seconde chaîne de build et s'assurer que les 2 sont bien équivalentes est très compliqué.[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 1.
Par système de packaging, j'entendais gestionnaire de paquets (désolé c'était pas clair). Ce que nous disent benoar et d'autres c'est qu'ils aiment les autotools en tant que gestionnaire de paquet (en lieu et place de dpkg, rpm ou flatpack). Je veux signifier que c'est un usage totalement à la marge et que les gains apportés pour les usages conventionnels sont bien plus grands que l'inconvénient qu'ils voient sur l'usage qu'ils en font.
Bien sûr que ton build peut générer des artifacts qui sont des packages que ce soit pour des linuxeries (deb/rpm/flatpack) voir pour des trucs comme des images docker ou autre.
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 3.
En fait on s'en fout pas mal de son point de vu. Ce que vous voulais c'est un système de packaging de sources standard hors ça n'existe pas parce qu'il y a pleins de projets qui ont déjà un système différents. On parle de C et C++, mais si tu joue avec des programmes en python, en java, en go, en rust, en js,… tu aura des dizaines de builder et c'est normale. Le build est un outil du développeur. Lui il l'exécute plusieurs dizaines de fois par jours. La minute qu'il perd à cause de sont build peut facilement représenter des dizaines de minutes dans la journée, ralentir son intégration continue ça ralenti tous sont travaille, ne pas pouvoir lancer un build + les tests tout le temps ça nuit à la qualité de ce qu'il te fourni.
À coté de ça changer les habitudes de quelques utilisateurs qui ne veulent pas lire un fichier INSTALL et qui ne veulent pas changer leur 3 commandes (alors qu'ils vont bien devoir installe meson, python et ninja !). Ça ne représente pas un intérêt énorme.
Les packageurs de distribution sont déjà habitués à gérer un paquet de builder différents (tu as même Debian (et d'autres je présume) qui fait des builds via différent compilateurs).
Le builder est un outil du développeurs, pas un système de packaging.
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à -2.
make ? le compilateur ? la bibliothèque standard du C ou C++ ? Ce n'est pas dans les outils de base de ma distribution.
[^] # Re: on en a déjà parlé dans la meson.
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 1.
Surtout que du coup la cross compilation est détaillée.
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 1.
Non tu crée un build plus rapide parce que ton build est lent. Je ne pense pas que meson ai vocation à gouverner le monde.
Tu aura toujours besoin de découvrir qu'il faut installer meson, python et ninja, hein ? Les 3 pauvres commandes ne changent pas grand chose au problème du « qu'est-ce que je fais quand je télécharge un
.tar.gz? »[^] # Re: Autres portages
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 7.
Et au final la migration s'est bien passé ? Il y a eu des adaptations à faire ? Ça t'a pris combien de temps ? Le gars est significatif ?
[^] # Re: Un nouveau standard ?
Posté par barmic . En réponse à la dépêche E.T. téléphone Meson. Évalué à 4. Dernière modification le 08 octobre 2018 à 11:12.
Ça n'est pas un standard et ça n'a pas vocation à l'être. Des outils de builds il y en a déjà un tas, on a pas attendu meson pour que ce soit l'anarchie.
Parce que ça ne changerait rien au problème ? Ça te gêne d'avoir d'autres commandes que
./configure && make && make install, mais le fais qu'il soit nécessaire d'installer ninja avant ne te gène pas ? Ou que les outils comme checkinstall ne fonctionnent plus ?Tenter de ressembler, mais ne pas être compatible est bien pire que d'être plus ou moins compatible. Tout ça pour qu'au final la proportion de gars qui font des installations depuis les sources soit ridicules (d'autant qu'ils ont juste des commandes différentes à utiliser) face au temps passé par les dev et les intégrateurs à faire des builds un paquet de fois par jour (et leurs serveurs qui font ça en boucle).