Je veux dire, quand tu utilises un utilitaire comme buildroot, Yocto ou similaires, pour travailler il va utiliser au départ des éléments de ta machine : ton compilateur, les en-têtes et les bibliothèques.
Ok l'embarqué c'est un domaine que je ne connais pas du tout, je veux bien te croire. Ceci dit ça me parait un détail. Qu'il faille une solution particulière pour les types qui utilisent buildroot ou Yocto je le conçois, mais ça concerne une proportion infinitésimal des systèmes et si cette solution a des inconvénients elle ne devrait pas s'échapper de ce périmètre.
Et comment tu gères aussi les différences entre Python, PHP tout ça ? La compilation ne suffit pas, il faut potentiellement récupérer tout l'écosystème en entier. Une distribution offre rarement ce genre de choses nativement, Docker pallie aisément à ce besoin.
Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?
Perso je suis dev (client lourd) ET admin. Ca biaise peut-être (probablement) mon raisonnement, mais je n'aime pas du tout les 'pip install', 'gem install' et compagnie que j'ai déjà croisé. J'ai déjà un gestionnaire de paquet qui est responsable de l'installation des paquets. Et en tant que dev, je tiens particulièrement au principe de responsabilité unique qui est mis à mal avec ce genre de solution.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
Ok l'embarqué c'est un domaine que je ne connais pas du tout, je veux bien te croire. Ceci dit ça me parait un détail. Qu'il faille une solution particulière pour les types qui utilisent buildroot ou Yocto je le conçois, mais ça concerne une proportion infinitésimal des systèmes et si cette solution a des inconvénients elle ne devrait pas s'échapper de ce périmètre.
Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?
Perso je suis dev (client lourd) ET admin. Ca biaise peut-être (probablement) mon raisonnement, mais je n'aime pas du tout les 'pip install', 'gem install' et compagnie que j'ai déjà croisé. J'ai déjà un gestionnaire de paquet qui est responsable de l'installation des paquets. Et en tant que dev, je tiens particulièrement au principe de responsabilité unique qui est mis à mal avec ce genre de solution.