Psychofox a écrit 10737 commentaires

Je crois que vous avez tous les deux décidé d'être choqué pour le plaisir de monter sur vos grands chevaux surtout.

Je croyais que c'était pour ça les nombreuses applications de coloriage :)

ça ne monte pas à l'échelle. Déjà le coloriage c'est en général pour les jeunes enfants, pas encore en âge d'avoir leur propre appareil. Et ensuite il te faut un appareil par enfant là où des crayons/feutres se partagent aiséments.

qui mettrait du Fedora en prod ?

Et pourquoi pas ma foi?

Note que Amazon Linux 2023 est basé sur Fedora donc ça va vite faire du monde en prod sur du Fedora based.

Hmmm non tu n'as pas besoin de passer par google. Certaines marques ont leur propre appli, mais souvent le plus simple c'est d'utiliser cups (malheureusement non maintenu):
https://f-droid.org/packages/io.github.benoitduffez.cupsprint/

Si la question est destinée à une personne en particulier, pourquoi ne pas le contacter directement via le formulaire de contact de sa société?

https://mediaarea.net/Contact

(tu peux même lui envoyer une carte postale écrite de ta main)

Mes 2 centimes d'euros, c'est que quelque soit l'intérêt de Rust vis à vis de C++, réécrire une librairie et un logiciel de zero est un travail important et dans un cadre commercial non hobbyiste il faut que ça ait du sens d'un point de vue business comparé à utiliser ce temps de développement pour ajouter des fonctionnalitées demandées par ceux qui paient pour ledit logiciel.

https://linuxfr.org/users/elessar/journaux/utiliser-l-identite-numerique-la-poste-sans-google-play

Tu as plusieurs options:

1. faire tourner le pod de logstash en mode privilégié en lui donnant accès àe /run/log/journal pour aller chercher le log de ton appli directement dans journald. Par contre le logstash ne serait du coup plus dans le docker compose.

2. utiliser le paquet rsyslog de la distrib sur lequel ces containers tournent pour récupérer le log du pod de ton appli dans journald via l'input imjournal et de le renvoyer à opensearch. Dans ce cas tu peux même te passer de logstash puisque rsyslog a un output omelasticsearch.

3. faire tourner logstash ou autre tournant directement sur ta machine hôte. Il existe un plugin d'input compatible journald.

4. option 1. ou 2. avec fluentbit ou fluentd qui sont aussi journald et opensearch capables.

5. utiliser log-driver k8s-file et logger dans un fichier qui est ensuite lu par logstash

6. ne pas utiliser podman-compose

Mais perso je ne vois pas bien l'intérêt d'avoir l'infra de logging gérée dans le même docker-compose qu'une application individuelle. Ton cas de figure me parait assez alambiqué. En général si on utilise opensearch ou un outil du même type, c'est qu'on veut aggréger les logs de n applications.

Oui il y a quelques années on avait encore besoin d'imprimer de temps en temps pour signer des documents mais de nos jours presque tout se fait électroniquement, même un document important comme un contrat de travail.

Reste les jeunes enfants qui te demandent de quoi faire des coloriages. Je pense que eux-seuls alimentent le marché de l'imprimante familiale.

C'est de réussir à suivre ou les projets bougent sans avoir à vérifier tout les mois, sans avoir à faire des grep/sed sur les différents dépôts git pour changer tel image vers tel registre.

Ben en fait c'est le nerf de la guerre. Il faut pas être naïf, si on pull des images publiques c'est un truc qu'on doit pouvoir faire chaque semaine.

Idem pour les warrant canaries d'ailleurs.

On s'en branle. Ce que j'entendais par là c'est que ce n'est pas forcément essentiel d'avoir une image curl officielle vu qu'il est déjà packagé par toutes les distros, qu'il ne dépend que d'une douzaine de librairies, que les sources tiennent dans une archive compressée de 3MB, qu'il est compilable en quelques secondes et que le projet met à disposition une liste des binaires compilés et dans quelle version pour une multitude d'OS. Le monde s'en remettrait si on n'avait plus d'image officielle du jour au lendemain.

30 jours ça reste peu. Il faut espérer que tous les mainteneurs qui ne veulent pas poursuivre avec l'offre payante de docker auront reçu le mémo et vont supprimer leurs images publiques ou les déménager vers un compte free-personal.

Ce n'est pas bien compliqué de faire les quelques modifs nécessaires pour que ça marche avec podman-compose non?

Non je pensais à systemd-nspawn.

C'était un des choix possibles retenus initialement mais qui au final apporté plus de contrainte qu'autre chose. Mon choix de référence était LXC mais interdit… Du coup j'ai découvert systemd-nspawn avec machinectl et pour le moment ça répond à toutes les besoins dont j'ai besoin.

Je pense que tu aurais pu remplacer cette phrase:

Mais finalement trop de contraintes et de problèmes de sécurité liés aux images toutes faites clé en main.

Par:

On avait décidé de pas mettre de chaine sur le vélo mais finalement on s'est rendu compte que c'était pas mieux qu'une trottinette.

Et accessoirement les boites auto ont toujours fonctionné comme cela. Ce n'est donc une découverte pour personne.

Microsoft n'est pas Google, mais pour prendre un exemple bête, Google ferme des trucs tout le temps.

Avoir plein de fric ne signifie pas qu'on veuille jeter l'argent par les fenêtres s'il n'y a pas de rentabilité directeou indirecte (marketing, capturer l'utilisateur pour l'orienter vers d'autres services maisons, etc).

Je n'ai jamais pris la peine de tester mais il me semble que systemd permet de faire tourner directement des containers sans passer par un runtime oci comme podman ou containerd.

Podman ne cherche pas sur le dockerhub par défaut. Podman cherche sur les registries configurées dans $HOME/.config/containers/registries.conf ou /etc/containers/registries.conf et dans l'ordre défini.

Il et possible que certains packagers de distribs choisissent le docker hub mais pas tous. Exemple chez Fedora les registries fedora, redhat et quay passent avant docker hub.

Si t'as le dockerfile t'as quand même toute la recette pour avoir ton image. Tu peux même utiliser un service de build d'image dans le nuage si t'as pas envie de la créer en local.

Et puis il faut voir le type de projet aussi. Alors certe c'est pratique d'avoir des images nextcloud toute faite. Hier j'ai lu un article qui se lamentait du fait qu'un projet comme curl pourrait voir son image docker disparaitre du docker hub…la belle affaire.

Tu dois utiliser containerd en production, sur ta machine de development, dans la ci/cc ou partout?

Ça fait plus de 5 ans que je lis des articles et parle à des acteurs de la tech qui me disent que Docker va devoir mettre la clé sous la porte s'ils ne trouvent pas un moyen magique de générer du fric.

Je suis relativement surpris qu'ils aient tenu jusque làen fait.

Le truc c'est que le docker hub arrange tout le monde pour avoir un point unique pour héberger des images de bases publiques de distros, de projets libres, etc. Mais Docker HUB est peu attrayant pour ceux qui ont des sous et qui n'ont pas besoin d'avoir des images publiques:
- ceux qui ont leur infra dans un cloud vont utiliser les services de registry du cloud qu'ils utilisent. Moins de frais egress, plus de contrôle, pas besoin d'avoir une ligne de dépense avec une autre entitée.
- ceux qui ont plus d'infra on-prem hébergent leur propre registry et s'ils veulent une registry en ligne, ils vont choisir un truc comme jfrog artifactory qui sert aussi de dépôts privés pour d'autres formats de paquets.

Après le titre et contenu du journal est effectivement très alarmiste.

1. La plupart des projets libres n'ont pas besoin d'image et peuvent fournir des dockerfiles.
2. il y a d'autres moyens d'héberger les images que le docker hub

Et ce serait bien si cet épisode pouvait éduquer les gens à prendre soin d'où ils vont chercher des binaires et pas copier/coller bêtement des lignes de commandes sans vérifier si l'image qu'ils vont utiliser est sûre, créée par le porjet upstream, toujours à jour, etc.

Ça n'a pas de sens. Rien n'impose d'utiliser les images des autres.

Il n'y a aucun de tes 3 avantages qui n'est pas aussi vrai avec Docker. Ou podman. Ou tout autre outil compatible avec les images oci.

Sans travailler là-bas on ne peut pas définir ce que ça veut dire.

Si je prends mon cas précis, sur le papier je suis dans une équipe de Dev/CloudOps. Nous répondons tous à un même chef, mais n'avons presque aucun contact et même pas un seul meeting commun. Au jour le jour "mon équipe", ce sont les DEVs/QA/Product Managers avec qui je travaille.

Ce n'est pas vraiment le sujet, mis à part ma faute d'orthographe (s/font/fond), mon commentaire se référait essentiellement de la formulation de la pétition et non à la réforme elle-même.