Rapidement, ce que dit l'article, c'est que les wheels python sont compilés avec la glibc. Et comme Alpine utilise musl, ces wheels ne peuvent pas être utilisés, et tout le code est recompilé, ce qui est lent et coûteux.
Il y a aussi des bugs plus subtils, liés aussi à musl, qui n'a pas tout à fait les même comportement que la glibc.
Ça peut être aussi vu comme un avantage, la monoculture n'est pas non plus la panacée. Mais à part si vous faites la chasse aux bugs, utiliser une image avec une glibc, c'est mieux (pour Python).
Ce que ne dit pas l'article, le problème de la taille de l'image peut être résolu par le multi stage : tu crées les packages avec musl dans une première image et tu les installes dans une seconde.
Oui, ça m'a semblé aussi assez partial. C'est comme si on disait: "n'utilisez pas Linux, sous Windows ça marche bien et vous aurez d'autres problèmes en passant à Linux". Le plus répandu ne détient pas la vérité absolue.
J'ai trouvé les apports de musl, même pour les autres systèmes, intéressants en termes d'amélioration de la qualité de code. J'aime aussi leur approche "on essaie de faire les choses de la bonne manière".
A une époque, on disait de se méfier de alpine Linux, les truc tordus de la glibc ne sont pas la pour le plaisir. A une époque, il y a avait une série de faille de sécurité, je ne sais pas si cela a changé.
Globalement, les softs sont développés/testés avec glibc, faire le run avec Alpine, c'est prendre un risque.
À une époque, utiliser Linux plutôt que Windows, c'était prendre un risque. Prendre des risques, c'est bien des fois pour faire avancer le schmilblik, tant qu'ils sont mesurés.
# Les wheels ne sont pas fait pour musl
Posté par Glandos . Évalué à 10.
Rapidement, ce que dit l'article, c'est que les wheels python sont compilés avec la glibc. Et comme Alpine utilise musl, ces wheels ne peuvent pas être utilisés, et tout le code est recompilé, ce qui est lent et coûteux.
Il y a aussi des bugs plus subtils, liés aussi à musl, qui n'a pas tout à fait les même comportement que la glibc.
Ça peut être aussi vu comme un avantage, la monoculture n'est pas non plus la panacée. Mais à part si vous faites la chasse aux bugs, utiliser une image avec une glibc, c'est mieux (pour Python).
[^] # Re: Les wheels ne sont pas fait pour musl
Posté par Jarvis . Évalué à 5.
Ce que ne dit pas l'article, le problème de la taille de l'image peut être résolu par le multi stage : tu crées les packages avec musl dans une première image et tu les installes dans une seconde.
[^] # Re: Les wheels ne sont pas fait pour musl
Posté par liberforce (site web personnel) . Évalué à 3.
Oui, ça m'a semblé aussi assez partial. C'est comme si on disait: "n'utilisez pas Linux, sous Windows ça marche bien et vous aurez d'autres problèmes en passant à Linux". Le plus répandu ne détient pas la vérité absolue.
Je vous conseille cette présentation sur alpine et musl au FOSDEM 2017: https://www.youtube.com/watch?v=Cc1rBayMnVI
J'ai trouvé les apports de musl, même pour les autres systèmes, intéressants en termes d'amélioration de la qualité de code. J'aime aussi leur approche "on essaie de faire les choses de la bonne manière".
[^] # Re: Les wheels ne sont pas fait pour musl
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
A une époque, on disait de se méfier de alpine Linux, les truc tordus de la glibc ne sont pas la pour le plaisir. A une époque, il y a avait une série de faille de sécurité, je ne sais pas si cela a changé.
Globalement, les softs sont développés/testés avec glibc, faire le run avec Alpine, c'est prendre un risque.
"La première sécurité est la liberté"
[^] # Re: Les wheels ne sont pas fait pour musl
Posté par liberforce (site web personnel) . Évalué à 4.
À une époque, utiliser Linux plutôt que Windows, c'était prendre un risque. Prendre des risques, c'est bien des fois pour faire avancer le schmilblik, tant qu'ils sont mesurés.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.