Journal La multiplicité des gestionnaires de paquets

Posté par Jiehong (site web personnel) le 30 janvier 2017 à 22:17. Licence CC By‑SA.

Étiquettes :

jan.

2017

Sous Linux, s'il y a bien une chose fantastique, c'est bien les paquets !

Heureusement, ces dernières années, les gestionnaires de paquets se multiplient partout. Mais ce n'est pas toujours super.

J'aimerais vous parler ici de ce que lwn.net écrit bien mieux que moi (en accès payant).

Du côté des distributions

Nos chères distributions nous apportent le confort inouï de pouvoir gérer presque tous nos logiciels, et de synchroniser entre elles les dépendances. Un coup d'apt-get update && apt-get upgrade et tout le système se met à jour (si basé sur Débian). Même chose avec dnf sous Fedora, ou pacman sous Archlinux.

Maintenir un paquet demande certes du temps et de la sueur pour bien s'assurer que le code compile avec les dépendances présentes, ou encore que les correctifs de sécurité soient prêt à l'heure.

Les distributions de téléphones ont bien leur stores, même si le système n'est, en fait, pas géré de la même manière finalement.

Du côté des développeurs

Si vous avez eu l'occasion de développer avec un langage autre que le C/C++ par exemple, vous vous êtes sûrement rendu compte que chaque langage propose son propre gestionnaire :

pip pour Python ;
maven pour Java ;
cargo pour Rust ;
stack pour Haskell ;
npm pour Javascript ;
etc.

C'est super, n'est-ce pas ?

À la croisée des deux

Mais voilà, vous vous retrouvez à vouloir installer un logiciel écrit en Javascript, dont les dépendances ne sont pas présentes dans les dépôts de votre distribution, alors npm est là pour vous.
Le soucis, c'est qu'il vous faut maintenant maintenir votre distribution et vos logiciels dans npm maintenant.

Ah, mais vous avez aussi cette application qui a une partie Javascript, et un bout en Rust. Là, cargo ou npm ne peuvent pas gérer les dépendances de l'autre langage, alors il faut passer par la distribution, qui là est superbe si elle contient le paquet correspondant.

Containers

Et si les applications étaient déjà empaquetée d'une manière standardisée, ça serait plus simple, non ?

Pensez à Flatpak, ou Docker.

Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?

Le future

Le présent semble donc être à l'exploration des possibilités pour résoudre un souci identique à plusieurs niveau (système ou développeur), mais avec des contraintes différentes.

Pensez-vous que certaines solutions soient en train d'émerger ?

Par exemple, les distributions vont-elles proposer des systèmes de bases sur lesquels les applications utilisateurs seraient gérées autrement ?

# Modularité

Posté par Spack le 30 janvier 2017 à 23:26. Évalué à 4.

Fedora y pense. Pour l'instant, l'idée ne semble pas clairement définie et ressemble à un gros .tar.gz avec toutes les dépendances d'une application donnée. En gros, ce contre quoi se bat le projet.

En tout cas, le besoin est là mais la solution élégante n'a pas encore été trouvée.
- [^] # Re: Modularité
  
  Posté par Stibb le 07 février 2017 à 11:43. Évalué à 1.
  
  Ces histoires de fix par securité, c'est vraiment l'arlésienne. Sous mac les dépendances d'un programme sont tout dans un seul bundle et il n'y a pas plus de probleme de sécurité. Il y a plus de risque à mettre à jour une librairie partagée (elle peut cassée une feature ou une API) que de laisser chaque fournisseur tester et valider son soft. Car oui en theorie une nouvelle version ne casse rien, mais le monde est tel qu'il est, et ça arrive. Résultat, on freeze toutes les dépendences dans des grosses archives. Rust et Go le font, Python le fait avec virtualenv, c'est comme cela que l'on résoud les probleme de stabilité entre version. Et ca marche. Alors au lieu de dire que ça pose trop de risque, faisons en sorte d'intégrer ce fonctionnement pour que tout le monde soit content.
  
  Pour ma part, que les soft soient intégrée par le mainteneur de la distribution et avec les lib partagée, pas de probleme, c'est lui qui s'occupe de tester la compatibilité. Mais quand je distribue un soft, je mets tout dans une seule archive en attendant qu'un mainteneur package ça comme il faut. Et je trouve ça très bien.
  - [^] # Re: Modularité
    
    Posté par bunam le 07 février 2017 à 14:00. Évalué à 1.
    Ce n'est pas aussi simple sous Mac, ce n'est pas parce qu'on peut installer une Application (qui en fait est un dossier Dropbox.app) en la copiant n'importe ou qu'elle est forcement autonome :
```
otool -L /Applications/Dropbox.app/Contents/MacOS/Dropbox
/Applications/Dropbox.app/Contents/MacOS/Dropbox:
    /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1253.0.0)
```
    cf http://wiki.qt.io/Show_library_dependencies
    
    à moins que je n'ai pas compris le sens du com.
  - [^] # Re: Modularité
    
    Posté par ariasuni le 07 février 2017 à 23:09. Évalué à 2.
    
    Résultat, on freeze toutes les dépendences dans des grosses archives. Rust
    
    En Rust c’est surtout l’opération par défaut vu qu’y a pas encore d’ABI fixe.
    
    Écrit en Bépo selon l’orthographe de 1990
# tendance

Posté par steph1978 le 30 janvier 2017 à 23:32. Évalué à -2.

Si l'on considère que :
- le stockage ne coûte pas grand chose,
- il est possible de faire de la déduplication au nivau FS ou blockdevice,
- MacOS et Android proposent déjà d'empacter toutes les dépendances d'une application avec son exécutable,
- Winsxs est une grosse daube,
- le travail des empacteurs pour distribution linux s'apparente à du stakhanovisme,
Je pense que la tendance est à Flatpak, ou Docker ou similaire.
- [^] # Re: tendance
  
  Posté par lockidor le 31 janvier 2017 à 00:12. Évalué à 9.
  
  Je pense que la tendance est à Flatpak, ou Docker ou similaire.
  
  Ce qui ne règle malheureusement pas le problème des libs pas à jour :/
  - [^] # Re: tendance
    
    Posté par Jehan (site web personnel, Mastodon) le 31 janvier 2017 à 00:31. Évalué à 4. Dernière modification le 31 janvier 2017 à 00:34.
    
    Si ça y répond même plutôt pas mal. :-)
    Cf. mon message plus bas.
    
    P.S.: en tous cas pour Flatpak. Pour Docker, je sais pas, mais comme c'est orienté plutôt services et système de prob, j'en doute. Et pour d'autres alternatives de bureau, type Snap, aucune idée non plus du modèle adopté.
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
  - [^] # Re: tendance
    
    Posté par Misc (site web personnel) le 31 janvier 2017 à 11:11. Évalué à 7.
    
    Ni celui de la vérification des licences et autre trucs qu'on oublie un peu facilement jusqu'à ce qu'un SCO 2 sorte du bois et qu'on se dise "oups".
    
    Il y a aussi de la valeur ajouté des distributions à faire un peu de vérification de sécurité (en général, je fait une passe rapide sur les paquets quand je fait une revue Fedora, histoire de pas trouver trop d'horreur).
    
    Mais bon, tout ça, ça requiert de faire du travail, pas de reprendre les trucs upstream. Et c'est pas rpm qui rends ce travail plus complexe, ni docker/flatpack qui va le rendre plus rapide.
- [^] # Re: tendance
  
  Posté par cbri le 31 janvier 2017 à 09:15. Évalué à 5.
  - le stockage ne coûte pas grand chose,
  Mais la bande passante oui!!
  
  Tout le monde n'a pas la fibre pour mettre à jour des GiO de données dans le cadre d'un jeux.
  
  L'avantage de la gestion par paquets est que l'on télécharge juste que le programme qui a besoin du patch de sécurité. ET non pas tout un bloc ou la totalité du système. La dessus MS dans windows 7 fait une régression en faisant un seul même paquet pour tous les patchs de sécurité: un paquet de plusieurs centaines de Mo qui faut recommencer à télécharger car il est corrompu, merci :-(
  Android et iOS font maintenant des MàJ des applications avec juste le delta nécessaire. Je me souviens plus si c'est aussi utilisé pour les MàJ majeur d'iOS et d'Android (ou cela l'est pour les MàJ de sécurité).
  - [^] # Re: tendance
    
    Posté par Renault (site web personnel) le 31 janvier 2017 à 09:28. Évalué à 2.
    
    Beaucoup de distributions comme Fedora gèrent les mises à jour par delta nativement (c'est même souvent le mode par défaut). Rien n'empêche donc de le généraliser, notamment à ces applications contenant tout ce qui est nécessaire.
    - [^] # Re: tendance
      
      Posté par Misc (site web personnel) le 31 janvier 2017 à 11:12. Évalué à 3. Dernière modification le 31 janvier 2017 à 11:13.
      
      Oui, mais deltarpm a eu pendant longtemps un cout non négligeable coté serveur. Je suis pas sur que maintenant que les serveurs sont suffisament rapide pour les petits paquets, ça passe aussi bien pour les gros paquets, et qu'on se retrouve pas avec le même souci qu'avant.
- [^] # Re: tendance
  
  Posté par fasthm le 31 janvier 2017 à 09:33. Évalué à 4.
  
  Par curiosité, c'est quoi ce winsxs ? Une rapide recherche n'explique rien, on ne trouve que des âmes en peine qui se plaignent que le répertoire winsxs est trop volumineux.
  
  La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
  - [^] # Re: tendance
    
    Posté par madhatter (site web personnel) le 31 janvier 2017 à 09:59. Évalué à 9.
    
    C'est un dossier de travail de Windows. Il stocke des copies de fichiers système et de DLL à chaque mise à jour et installation de logiciel pour éviter de casser la dépendance d'une application à une DLL partagée avec une autre. En gros.
    
    Ça permet de revenir en arrière si un truc pète à la suite d'une install/mise à jour.
    
    Si l'idée est louable, le problème, c'est que ça fini par prendre énormément de place.
    
    There is no spoon...
  - [^] # Re: tendance
    
    Posté par Albert_ le 01 février 2017 à 22:25. Évalué à 0.
    
    Une grosse Merde de Microsoft au moins jusqu'à Windows 7. Un gros répertoire qui garde toutes les mises à jour sans possibilité de le vider et qui peut casser tout le système si tu tentes d'aller en énorme bourrin. Un truc jouissifs au possible surtout quand ton disque dur était pas gigantesque. La seule façon de régler (un peu) le problème c'était une réinstallation et encore.
    - [^] # Re: tendance
      
      Posté par Albert_ le 06 février 2017 à 09:59. Évalué à 3. Dernière modification le 06 février 2017 à 10:00.
      
      Si si c'est une grosse merde:
      
      One commonly asked question is can I delete the WinSxS folder to regain some disk space? The short answer is no
      
      J'ai vu des PC (vieux et avec peu d'espace DD) qui ne pouvait plus fonctionner a cause de ce truc. Meme une réinstallation ne fonctionnait pas ou bien il fallait ne pas faire de mise a jour du système car sinon ce répertoire se gonflait a tel point que on repartait au point précédent. Alors oui on peut acheter un autre DD, plus de ram, changer de PC etc mais bon ça dans la vraie vie c'est pas faisable pour tout le monde.
      - [^] # Re: tendance
        
        Posté par flan (site web personnel) le 06 février 2017 à 20:55. Évalué à 3.
        
        Mais le même lien explique qu'on peut réduire sa taille.
        Ça ne me choque pas qu'il y ait des dossiers à ne pas supprimer sur un OS (as-tu essayé de supprimer /boot ou /bin ?).
        Que vaut la taille de ce dossier après l'utilisation des méthodes documentées ?
        
        [^] # Re: tendance
        
        Posté par Albert_ le 07 février 2017 à 11:00. Évalué à 1.
        
        Essaye et apres on rigolera. Tu peux "reduire" la taille en effet qui passera de 14G a 13G (exemple). Une enorme progression mais sur certains PC ce n'est pas suffisant.
        
        Et franchement avoir 14G de pris pour garder toutes les mises a jours pour pouvoir un roll back et sans possibilite ou presque de diminuer cela ne te gene pas?
        
        [^] # Re: tendance
        
        Posté par flan (site web personnel) le 07 février 2017 à 14:34. Évalué à 3.
        
        Je peux difficilement essayer, faute de Windows sous la main.
        As-tu essayé ? qu'est-ce que ça donne précisément ?
        
        [^] # Re: tendance
        
        Posté par Albert_ le 08 février 2017 à 09:20. Évalué à 1.
        
        Oui j'ai essaye. J'avais un laptop avec 30Gig pour windows pour les documents a la con docx. Pour que cela soit utilisable il a fallu que je vire le fichier swap (j'avais 16G de ram ie la moitie de la partition) et malgre tout a cause de cette merde de winsxs c'etait limite si je voulais installer un seul autre truc.
        
        Comme j'ai dit j'ai aussi des exemples de laptop un peu ancien qui etaient tout simplement inutilisable a cause de ce truc enfin c'est pas vrai ils etaient utilisable si l'utilisateur ne voulait pas sauvegarder sur le disque ses donnees… Du grand delire, plusieurs personnes ont essaye toutes les recettes trouve sur le net et zip, nada cela ne servait pas a grand chose.
        
        [^] # Re: tendance
        
        Posté par xcomcmdr le 08 février 2017 à 09:45. Évalué à 1. Dernière modification le 08 février 2017 à 09:50.
        
        Pas sûr que ce soit la faute à WinSxS (qui est loin d'être une merde).
        
        WinSxS c'est beaucoup de hard links, ainsi la taille rapporté par l'explorateur Windows est farfelue.
        
        C'est plutôt au constructeur qui a mis une capacité de stockage rachitique (mon PC de 1998 avait 40 Go de disque dur, pas mon PC d'aujourd'hui).
        
        Par ailleurs, tu peux faire bien plus pour gagner de la place :
        - Enlever le fichier d'hibernation
        - Enlever les fichiers temporaires / de cache (avec le nettoyage de disque)
        - Enlever la "Protection du système" (le truc qui permet de revenir en arrière)
        - Supprimer des fonctionnalités et des programmes Windows inutilisées
        - Mettre les fichiers lourds sur un support externe (exemple : vidéos)
        - Activer la compression NTFS (fait en général gagner quelques Gina-octets). Par contre, ça peut prendre quelques heures
        Au pire, revoir le partitionnement (je pense surtout aux partitions de restauration à la con)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: tendance
        
        Posté par Albert_ le 08 février 2017 à 10:21. Évalué à 1.
        
        Petite question: tu dis quoi aux personnes qui veulent utiliser windows et qui ont des budgets faible mais un ordi (pas si vieux que cela) qui fonctionnait parfaitement jusqu'au moment ou winsxs a pris la plus grosse partie de DD?
        
        Je suis curieux.
        
        [^] # Re: tendance
        
        Posté par xcomcmdr le 08 février 2017 à 10:25. Évalué à 2.
        
        D'abord, WinSxS ne prend jamais la part que tu décris. Il ne faut pas du tout se fier à ce que dit l'explorateur Windows, qui se trompe énormément à cause des hard links (as-tu seulement LU les liens que j'ai donné ?!)
        
        Et si ils ont problème de place, la première solution c'est souvent mettre les fichiers les plus lourds sur un support externe (voire plusieurs histoire d'avoir des sauvegardes), et ensuite ce que j'ai dit plus haut.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: tendance
        
        Posté par Albert_ le 08 février 2017 à 10:55. Évalué à 2.
        
        Donc tu n'as jamais ete confronte au probleme mais tu as LU des articles. Comme je m'en doutais.
        
        C'est fou il suffit "d'acheter" pour resoudre ce probleme. Tellement simple comme solution.
        
        C'est une merde quoi que tu en dises. Cela part d'une bonne idee et d'une bonne intention MAIS si c'est pas configurable cela peut foutre le bordel tres tres vite. Si ils ont fait la meme chose sur le windows phone tu m'etonnes que cela ait ete un enorme echec…
        
        [^] # Re: tendance
        
        Posté par xcomcmdr le 08 février 2017 à 11:05. Évalué à 2. Dernière modification le 08 février 2017 à 11:08.
        
        Ah ben tu as parlé de budget faible, pas de budget inexistant.
        
        Par ailleurs, nope ce n'est pas de la merde quoi que tu en dises. WinSxS apporte de la fiabilité et de la sécurité à Windows, c'est un fait indéniable.
        
        Par ailleurs, je n'ai jamais dit que ACHETER était la seule solution, mais tu lis uniquement ce qui t'arrange.
        
        Enfin, oui j'ai déjà été confronté au problème, et j'ai toujours pu le résoudre sans tenter de supprimer un dossier système important pour le fonctionnement de l'OS.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: tendance
        
        Posté par Albert_ le 09 février 2017 à 10:40. Évalué à 1.
        
        Je n'ose imaginer ce que les gens comme toi dirais des distributions qui ne permettraient pas d'effacer les packages obsoletes apres leurs mise a jour…
        
        Mais c'est vrai comme c'est Microsoft ce comportement est SUPERBE et tu n'as qu'as etre riche ou travailler avec des associations bourres de fric … comme la fondation gates probablement…
        
        [^] # Re: tendance
        
        Posté par Juke (site web personnel) le 09 février 2017 à 11:19. Évalué à 3.
        
        Depuis toutes ces années que tu nous les ride avec microsoft, t'as pas essayé de passer à autre chose ?
        
        [^] # Re: tendance
        
        Posté par xcomcmdr le 09 février 2017 à 11:46. Évalué à 2.
        
        Je n'ose imaginer ce que les gens comme toi dirais des distributions qui ne permettraient pas d'effacer les packages obsoletes apres leurs mise a jour…
        
        Il y a justement par défaut une tâche programmée dans Windows pour nettoyer régulièrement WinSxS.
        
        On peut aussi virer le cache des mises à jours et mises à niveau via l'outil "Nettoyage de disque".
        
        Mais c'est vrai comme c'est Microsoft ce comportement est SUPERBE et tu n'as qu'as etre riche ou travailler avec des associations bourres de fric … comme la fondation gates probablement…
        
        Le comportement dont tu parles n'existe pas.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: tendance
        
        Posté par ackernul le 08 février 2017 à 13:04. Évalué à 3.
        
        La seule solution connue pour diminuer la taille de ce dossier est de faire une installation de Windows avec un media d’installation incluant toutes les mises à jour. L'autre avantage est que l'on ne perd pas 2 jours à faire toutes les màj après l’installation.
        
        Il me semble que c'est faisable avec des outils Microsoft, mais les seuls tutos trouvés utilisent "Win Toolkit" qui permet d'intégrer les mises à jour à une ISO Windows 7. Par contre ne sais pas ce qu'il en est du respect de la licence d'utilisation de Windows avec cet outil.
# Flatpak pour les paquets de logiciels de bureau

Posté par Jehan (site web personnel, Mastodon) le 30 janvier 2017 à 23:36. Évalué à 10.
Tu cites déjà la réponse dans ton journal. Je pense que Flatpak, si le projet continue dans la bonne direction (ça a l'air d'être le cas pour l'instant), peut être la solution au problème cité.

Note que je ne considère absolument pas que le système de paquet par distribution est cassé pour autant, ni qu'il disparaîtra. C'est simplement complémentaire. L'écosystème logiciel GNU est simplement devenu trop important pour que tous les logiciels intéressants soient inclus dans les paquets gérés par la distrib (on peut voir cela comme un succès du "bureau Linux" si on veut alimenter le troll! :P). Donc il faut trouver des solutions pour répartir mieux le travail, et ça veut en général dire que les développeurs doivent s'y mettre. Par contre — on le sait bien depuis le temps — faire un paquet par distribution n'est pas gérable, surtout si ce sont des logiciels faits sur le temps libre (cas non rare dans le logiciel libre!). Un format standard comme flatpak, utilisable sur toute distribution GNU/Linux, est donc une très bonne alternative.

Mais là, qui va s'assurer que tout vos containers utilisent bien la dernière version patchée d'une bibliothèque critique ?

Alors je sais pas comment ça marche pour Docker que tu cites aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique (surtout parce que c'est fait pour les serveurs et on veut pas voir des trucs genre maj auto en prod!). Par contre Flatpak a un système de dépôt. En gros, chaque projet aura désormais un mini-dépôt de paquets pour ses logiciels et mettra à jour ses dépendances (note: il est aussi possible de faire des Flatpak standalone, sans dépôt, mais ce n'est pas la procédure conseillée).
Ainsi quand le projet mettra à jour son paquet, l'ensemble des gens qui auront installé ce paquet recevront des notifications qu'une mise-à-jour est dispo. Personne ne se baladera avec des applis et dépendances trouées (tant que le projet upstream est maintenu). Note que le projet n'a même pas à maintenir l'ensemble des dépendances possibles d'un logiciel puisque Flatpak fonctionne par "niveaux" de runtime. Ainsi le projet Flatpak lui-même maintient un runtime "Freedesktop" qui à lui seul contient déjà environ 200 dépendances de base qui vont suffire pour énormément de projets. Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances. Le projet KDE aussi maintient un runtime. Un logiciel doit simplement choisir un runtime sur lequel se baser.
Pour énormément de projet, celui signifie qu'il n'y aura peut-être aucune dépendance supplémentaire à ajouter dans le Flatpak (et donc à maintenir), ou très peu. Cela dilue énormément la tâche tout en permettant de rester sécurisé.
- Ainsi pour les distributions, ça ne change pas grand chose: elles peuvent continuer à proposer les logiciels les plus notables notamment, et avoir des mises-à-jour fonctionnelles pas forcément au taquet (mais une fois tous les 6 mois ou 1 an en fonction du cycle de sortie de la distrib). Ça sera suffisant pour la majorité des logiciels.
- Les développeurs eux auront moins de travail puisqu'il n'y aura plus qu'un seul paquet à maintenir pour être dispo partout.
- Enfin tout le monde aura accès à des mises-à-jour immédiates fonctionnelles ET de sécurité si on choisit d'installer le paquet Flatpak upstream.
En tous cas, le projet GIMP par exemple fournira désormais un paquet Flatpak upstream que je crée et maintiens. Je pense que c'est vraiment une avancée car jusqu'à ce jour, les gens sous Windows ont un installeur, ceux sous OSX un DMG, et sous Linux… on leur disait d'attendre le paquet de leur distrib ou de compiler. Ça fait limite "citoyens de seconde zone" (bon c'est pas vrai, hein. Quasi tous les dévs de GIMP sont sous Linux, et donc ça veut dire notamment que la version nux est bien plus stable que les autres! Mais bon on pourrait croire). Ben plus maintenant. Tant que je serai dév de GIMP, les linuxiens auront leur Flatpak (bon à part si une alternative encore mieux fait son apparition bien sûr, ou si je découvre un truc horrible qui me fait changer d'avis sur l'utilité… espérons que non, mais on sait jamais!) et seront toujours des citoyens de première zone! :-D

Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: Flatpak pour les paquets de logiciels de bureau
  
  Posté par reynum (site web personnel) le 31 janvier 2017 à 10:25. Évalué à 3.
  
  Le projet GNOME aussi maintient un runtime, basé sur celui Freedesktop et qui ajoute environ 50 dépendances
  
  Du coup si on veut installer un logiciel qui utilise une dépendance du runtime GNOME et que l'on a pas ce dernier il faudra tout de même tirer les 250 dépendances (200 de Freedesktop et 50 de GNOME) ?
  
  kentoc'h mervel eget bezan saotred
  - [^] # Re: Flatpak pour les paquets de logiciels de bureau
    
    Posté par Jehan (site web personnel, Mastodon) le 31 janvier 2017 à 19:24. Évalué à 10.
    
    Du coup si on veut installer un logiciel qui utilise une dépendance du runtime GNOME et que l'on a pas ce dernier il faudra tout de même tirer les 250 dépendances (200 de Freedesktop et 50 de GNOME) ?
    
    Non. :-)
    Ça se répond en petits morceaux.
    
    1/ Déjà en vrai y a un runtime et un SDK faits en même temps. Le runtime ne contient que ce qui est nécessaire pour exécuter les logiciels (librairies partagées, etc.) alors que le SDK contient aussi les trucs de développement (headers de lib, mais aussi des outil divers comme les autotools, etc.). Les dévs doivent bien sûr installer tout, mais les autres n'installent que le runtime. Ça fait déjà beaucoup moins de dépendances que la liste "naïve" que j'ai faite précédemment avec un grep et un wc pour compter les lignes.
    
    2/ Un runtime comme celui de freedesktop va contenir énormément de libs que beaucoup de logiciels utilisent sans même forcément s'en rendre compte (car pas en dépendance directe). Que ce soit libpng, ou les libs X11 ou Wayland, si votre appli a une GUI, vous en aurez vraisemblablement besoin. Beaucoup de cas d'usage "bureau" feront aussi des appels DBus, même si vous n'en avez aucune connaissance dans votre code. Vous voudrez forcément les libs alsa et pulseaudio pour le son, les diverses libs de Desktop ou d'affichage de texte, etc.
    Au final ce sont des libs de base qui sont nécessaires pour quasi toute appli graphique (même si la dépendance n'est pas directe). Il faut bien voir que le "bureau linux" est lui-même vraiment stratifié sur de nombreux niveaux sur lesquels la plupart des logiciels graphiques s'appuient. Dire un chiffre genre "200" bibliothèques peut paraître énorme, mais je vous assure, pour faire tourner votre ordi super-moderne, ça ne l'est pas du tout! Même en espace disque, ce ne sera pas énorme. Beaucoup de libs de base sont très simples et ne tiendront que sur quelques Ko une fois compilés. Le fameux "faire une seule chose et le faire bien".
    
    3/ Si vraiment vous êtes dans un cas exceptionnel où vous pouvez faire tourner l'application sur quasi aucune dépendance, vous êtes libre de faire votre propre runtime super-minimal.
    Si vous voulez dépendre du runtime Freedesktop, mais pas de celui de GNOME: supposons qu'il y a une seule lib que vous voulez qui est dans le runtime GNOME, vous pouvez aussi bien l'ajouter dans votre Flatpak et vous baser sur le runtime Freedesktop. Il n'est pas nécessaire de tirer le runtime GNOME.
    
    4/ Aussi il faut bien se rendre compte que si les gens se mettent à installer Flatpak, ils auront probablement déjà les principaux runtimes, dont celui de GNOME (et celui de KDE). Celui-ci est partagé entre les applications et téléchargé une seule fois, donc pas téléchargé pour une application unique. C'est plutôt efficace et permet des Flatpaks de taille réduite.
    
    En outre, côté sécurité, ça signifie que vous bénéficierez de la réactivité de l'équipe de Flatpak (contenu du runtime Freedestop) ainsi que de l'équipe GNOME (runtime GNOME) donc des mises-à-jour de sécurité de ces 2 runtimes. En tant que développeur d'application, c'est autant de dépendances dont on n'aura pas à s'inquiéter.
    
    Au final, je trouve ce système de niveaux de runtime les uns au dessus des autres assez bien et cela permet de bien diluer le travail entre les packageurs de divers projets, de garantir une sécurité plutôt bonne tout en ayant des mises-à-jour fonctionnelles régulières.
    Pour le moment, mon expérience est assez positive. Je n'ai que des problèmes d'accès de fonctionnalités du bureau qui ne sont pas encore possible parfois à cause de la problématique "sandbox". Mais ce sont des problèmes connus et sur lesquels l'équipe de Flatpak travaille. Mon interaction avec eux est plutôt constructive jusqu'à présent (GIMP étant un logiciel avec pas mal de dépendances, et qualifiable de relativement complexe, j'ai forcément rencontré plusieurs petits embêtements ici et là).
    
    P.S.: je conclurai avec un truc auquel je viens juste de penser; le fait d'installer des apps KDE est toujours très ennuyeux dans les distribs classiques, car cela va souvent tirer des dizaines d'autres applications graphiques (souvent pas parce que ce sont de vrais dépendances, mais parce que les packageurs de distribs veulent se simplifier la vie et "supposent" que si vous voulez une application KDE, ça veut dire que vous les voulez toutes) qui vont notamment polluer mon overview lors d'une recherche d'application (ou les menus d'application pour ceux qui en ont encore). Cela ne sera — je pense bien — pas possible avec Flatpak et si j'installe une application KDE qui aura été packagé en Flatpak, je pense que je n'aurai que cette app dans mon overview/menu ce qui améliorera le confort d'utilisation. Et au besoin, désinstaller le runtime Flatpak KDE sera 1000 fois plus simple, minimal en taille et propre que me débarrasser des dépendances multiples dans mon système principal. C'est aussi un gros avantage!
    
    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
- [^] # Re: Flatpak pour les paquets de logiciels de bureau
  
  Posté par Misc (site web personnel) le 31 janvier 2017 à 19:40. Évalué à 3.
  
  Alors je sais pas comment ça marche pour Docker que tu cites
  aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique
  (surtout parce que c'est fait pour les serveurs et on veut pas
  voir des trucs genre maj auto en prod!).
  
  En fait, si tu regardes dans tout les systémes de CD, c'est un peu justement ce qui se passe. Tu pousses ton code, il passe les tests, et paf, il est déployé.
  
  L'industrie va de plus en plus vers le fait de déployer juste en automatique. Certes, tu as des risques mais j'ai l'impression que le modèle inverse (ie, pas de mise à jour) cause plus de soucis mais de manière moins visible (ie, le cout des piles technologiques qui lagguent, le non déploiement de systèmes plus sur et plus efficaces, etc). Peut être que c'est juste aussi parce qu'il est plus répandu.
# A chaque clou son marteau

Posté par Firwen (site web personnel) le 30 janvier 2017 à 23:37. Évalué à 10.
Le monde du packaging est oui, en effet, le bordel. Mais ce n'est pas sans raisons…

Chaque package système a été crée pour résoudre un ou des problématiques précises, et souvent contradictoires.

RPM ou Deb sont clairement orienté "sys admin", ils ont été désigné pour le système et par le système :
- Ils compilent depuis les sources
- Autorisent l'ajout de "patch" home made pour gérer ton infrastructure, la recompilation meme du kernel lui meme…
- Supportent une résolution des dépendances complexes et sont fait pour des updates "smooth"
- Mettent un accent important sur la sécurité signature
- Integrent des choses comme
- le support de la documentation
- la gestion des symbols de debuggage
- la separation des headers / libs

Mais d'un autre coté :
- Ils demandent un apprentissage et un effort conséquent
- Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
- Ils nécessitent les droits roots
- Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )

Pour toute ces raisons, on a vu l’émergence de système packaging orienté "développeur" bien plus "quick & dirty" et souvent langage spécifique pour une meilleur intégration avec l’environnent de développement :

pip pour python, gem pour Ruby, cargo pour rust, mvn pour Java, npm pour node, cabal pour haskell, cpan pour perl, go get pour go …. Et j'en oublie….

L'avantage de ça, c'est que si ils sont en effet très "pratique" pour du développement et du déploiement rapide… car sont très bien intégrés avec leur langage respectif et demande un effort minimal pour packager une nouvelle app existante..

Le problème de ça c'est que ce sont bien souvent des cauchemars à administrer qui risque très certainement de causer plusieurs crises d’épilepsie a votre pauvre sysadmin.
- Ils sont difficile à tracer car souvent installer en home-env
- Certains ont une sécurité souvent douteuse (…pip)
- Ils s’intègrent pas ou peu avec des softs en code natifs ou dans un langage concurrent
- Le versionning est souvent partiel, ou même incomplet
- ils necessitent tous leur propre repository…. souvent sous control externe.
- La reproducibilité est souvent une catastrophe.
Maintenant qui blamer dans l'histoire ? Le sysadmin conservateur ou le developpeur avant-gardiste ?

Je dirai, aucun des deux. Chacun a ses cas d'utilisations et de très bonnes raisons de faire ce qu'il fait.

Ce qu'il faudrait c'est avant tout un peu de compréhension mutuel qui aiderait a ce que :
1- le developpeur comprenne que non, deployer un tool obscure à coup de pip en production n'est pas acceptable
2 - le sys admin comprenne que oui, utiliser un compilateur ou un package vieux datant de la premiere guerre mondiale, est souvent une grosse source d'emmerdes.

Et la solution sur le long terme pourrait venir de packaging système "hybride" comme Nix (http://nixos.org/) qui essaient de conjuguer le "moins-pire" des deux mondes.
- [^] # Re: A chaque clou son marteau
  
  Posté par reynum (site web personnel) le 31 janvier 2017 à 10:07. Évalué à 1. Dernière modification le 31 janvier 2017 à 10:12.
  Pour moi l'important dans un système c'est sa cohérence et sa stabilité et cerise sur le gateau sa sécurité.
  Du coup un système de paquet qui installe des lib ou binaires d'une manière pas propre (voire sale) et n'est compatible avec rien d'autre que lui même doit être utilisé en dernier recours.
  D'ailleurs quand je trouve une lib python qui m'intéresse je regarde toujours si elle est disponible sur apt et c'est presque toujours le cas.
  Vous l'aurez compris je penche très largement en faveur du package système (tel que décrit ci dessus) sauf que je trouve que dans le cas d'apt les assertions :
  - Ils sont peu ou pas du tout adaptés a la gestion des versions multiples
  - Ils ne sont pas fait pour du packaging quick & dirty ( deploiement de binaires )
  sont erronée car on trouve de plus en plus de binaires packagés et versionnés (les driver proprios Nvidia par exemple).
  
  Par contre le gros problème que je vois ce n'est pas leur fonctionnement mais c'est qu'ils sont incompatibles entre eux du coup c'est vrais que c'est toujours casse pied de voir des logiciel qui existe sur linux, qui sont bien proprement packagés, mais qu'il faut compiler à la main parce que le package n'est pas compatible avec la distribution qu'on utilise.
  
  Du coup peut être que flatpack sera mon eldorado ? ;-)
  
  kentoc'h mervel eget bezan saotred
  - [^] # Re: A chaque clou son marteau
    
    Posté par Firwen (site web personnel) le 31 janvier 2017 à 10:52. Évalué à 8. Dernière modification le 31 janvier 2017 à 10:55.
    
    Du coup peut être que flatpack sera mon eldorado ? ;-)
    
    Flatpack ou Docker sont à mon sens des fausses solutions.
    
    Ce que te donne flatpack ou Docker, c'est un environnent isolé où le développeur est roi: Il y installe ce qu'il veut, comme il veut… et l'utilisateur n'a pratiquement aucun contrôle sur ça.
    
    L'avantage c'est que ça donne une flexibilité total au développeur, l’inconvénient c'est que ton "package" devient une blackbox avec une plétoire de dépendances dupliquées, trés souvent, qui ne sont pas à jour.
    
    Shipper du flatpack, du docker revient à shipper un grossso modo blob binaire compilé statiquement dans un environment pseudo-isolé.
    
    Prenons un exemple simple : Admettons que je télécharge Firefox, VLC, FreetuxTV et owncloud, et une bonne 15ene de logiciels en archive flapack…..
    
    Et comme toujours, une faille OpenSSL arrive….. Il me faudra attendre que chaque développeur de chaque application dédaigne updater son propre blob….. c'est à dire probablement plus d'une semaine pour avoir un système "sur" à nouveau…. La où va le système centralisé actuel, ça prendrait quelques heures.
    
    C'est le problème N°1 des containers ou des systèmes "tout en un" style .dmg sous OSX…. La duplication des dépendances.
    - [^] # Re: A chaque clou son marteau
      
      Posté par Psychofox (Mastodon) le 31 janvier 2017 à 12:14. Évalué à 5.
      
      Docker tout dépend de comment c'est fourni :
      
      Exemple:
      
      Grosse image docker avec grosseapplication basée sur tomcat, apache, je ne sais combien de languages/frameworks, mariadb dedans ---> beurk.
      
      Image docker avec juste mariadb maintenue par l'upstream ---> bien
      
      Fournir des Dockerfile et docker-compose.yml avec recette complette pour installer l'application ---> bien, ça te permet de rebuilder les images régulièrement avec des libs/dépendances upstream à jour.
    - [^] # Re: A chaque clou son marteau
      
      Posté par reynum (site web personnel) le 31 janvier 2017 à 14:31. Évalué à 3.
      
      Shipper du flatpack, du docker revient à shipper un grossso modo blob binaire compilé statiquement dans un environment pseudo-isolé.
      C'est le problème N°1 des containers ou des systèmes "tout en un" style .dmg sous OSX…. La duplication des dépendances.
      
      Moui c'est bien ce que je craignais, c'est aussi pour ça que je défend les systèmes de packages style système (comme apt), mais en lisant http://flatpak.org/ à la section "How it works" on y voit des "runtime shared" il y a aussi le message de jehan du coup j'ai pensé qu'une alternative intelligente (et surtout compatible inter distrib) avait été trouvée, manifestement d'après ce que vous dîtes ce n'est pas le cas.
      
      kentoc'h mervel eget bezan saotred
    - [^] # Re: A chaque clou son marteau
      
      Posté par barmic le 01 février 2017 à 00:52. Évalué à 6.
      Non.
      
      Je vais parler uniquement de docker.
      
      Docker se base sur un dockerfile, ce qui te permet de reconstruire un docker très facilement. Toutes les images du docker hub sont reconstructibles facilement (tu clone le dépôt et tu build). Mettre à jour ou modifier une image est triviale. C'est le langage partagé par tous les linux : le shell.
      
      Donc non, on est très loin du « gros blob binaire ». C'est une boite noire (pourquoi mettre de l'anglais partout ?) que si tu ne veux pas t'y intéresser comme pour tous tes systèmes de paquets.
      
      environnement pseudo-isolé
      
      Il y a peut être des failles dans les namespaces, les cgroups, etc. Mais :
      
      ça va pas mal intéresser la LKML si tu les connais parce que ça ne concerne pas que les utilisateurs de docker. Si tu connais des failles je pense qu'il ne faut hésiter à leur en parler :)
      
      il est largement plus intéressant d'un point de vu sécurité d'avoir un cloisonnement perfectible que pas de cloisonnement du tout
      
      si on arrête le FUD (et ça restera du FUD tant que tu n'aura pas des arguments un chouia plus solides que… ben pas d'arguments du tout), il est très simple de contrôler ce que fait et ce que peut faire le contenu d'une image docker par rapport au moindre programme de ta machine. Les LSM sont très complexes à mettre en place et personne ne va toucher celles de la distribution. Là où pour les images docker tout le monde le fait
      
      Et comme toujours, une faille OpenSSL arrive….. Il me faudra attendre que chaque développeur de chaque application dédaigne updater son propre blob…
      
      Non :
      
      soit tu met à jour le contenu des conteneurs sur ta machine (tu ouvre un shell dans ton conteneur et tu fais ton apt update && apt upgrade)
      
      soit tu reconstruis les images. Par exemple tu vois que nginx dépende de jessie, si tu fais un nouveau build, il prendra la dernière version de celle-ci : https://github.com/nginxinc/docker-nginx/blob/e950fa7dfcee74933b1248a7fe345bdbc176fffb/mainline/jessie/Dockerfile
      
      Ça n'a rien de compliqué, ça ne te demande pas d'apprendre des choses démentes.
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: A chaque clou son marteau
        
        Posté par Firwen (site web personnel) le 01 février 2017 à 12:08. Évalué à 9. Dernière modification le 01 février 2017 à 12:12.
        
        Non.
        
        Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
        
        Docker se base sur un dockerfile, ce qui te permet de reconstruire un docker très facilement. Toutes les images du docker hub sont reconstructibles facilement (tu clone le dépôt et tu build). Mettre à jour ou modifier une image est triviale. C'est le langage partagé par tous les linux : le shell.
        
        Un docker container est une blackbox ( ou une boite noire si ça peut te faire plaisir ). C'est un gros ensemble binaire indivisible pas très différent d'une tarball de fichiers binaires. Tu peux certes créer ce blob à l'aide d'un script bash, mais ça reste la production d'un blob avec un contenu indivisible en lui même.
        
        D'ailleurs, je te propose d'envoyer un gros script bash à ton sys-admin qui pip install la moitié d'internet, curl quelques binaires pré-compilés, installes des RPM depuis des repos non-trustés, et sed ses propres fichier de configuration. Tu lui dis "pas de soucis, c'est reproduisible, c'est un script linux bien connu, du SHELL, on peut déployer ça en production" et tu regardes sa réaction.
        
        Je te conseil de courir vite également.
        
        Ça te choque de faire quelque-chose comme ça ? C'est pourtant exactement ce que fait un bon paquet de DockerFile, et exactement ce que font un grand nombre d'utilisateur de Docker.
        
        Maintenant ne me fait pas dire ce que je n'ai pas dit. Docker est un outil fantastique et une trés bonne technologie. Seulement ce n'est PAS un système de packaging.
        
        C'est un système de shipping avec un système de snapshot (oui de l'anglais, encore ). Même son nom l'indique d'ailleurs.
        
        Ça ne résous absolument pas les autres problématiques associés au packaging que j'ai listé précédemment ( tracabilité, update incrémentale, construction depuis les sources, versionning).
        
        Les deux sont complémentaires et ça beaucoup de développeurs tentent à l'oublier.
        
        Non :
        
        soit tu met à jour le contenu des conteneurs sur ta machine (tu ouvre un shell dans ton conteneur et tu fais ton apt update && apt upgrade)
        soit tu reconstruis les images. Par exemple tu vois que nginx dépende de jessie, si tu fais un nouveau build, il prendra la dernière version de celle-ci : https://github.com/nginxinc/docker-nginx/blob/e950fa7dfcee74933b1248a7fe345bdbc176fffb/mainline/jessie/Dockerfile
        
        Ça n'a rien de compliqué, ça ne te demande pas d'apprendre des choses démentes.
        
        Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions… Allez de préférence, avec des distributions différentes et des images différentes.
        
        Et aprés tu compareras ça avec ce que tu peux faire avec un infra puppet ou ansible, et un packaging proprement fait.
        
        Même RedHat propose maintenant des solutions qui tentent de "scanner" les containers dockers à la volée pour analyser les versions réellement utilisées en production… C'est peu dire si la bête n'est un example de transparence … ( http://www.infoworld.com/article/3089425/application-virtualization/red-hat-builds-linux-container-security-scanning-into-rhel.html )
        
        [^] # Re: A chaque clou son marteau
        
        Posté par barmic le 01 février 2017 à 15:04. Évalué à 2.
        
        Non à quoi ? tu peux être en désaccord avec certains de mes propos, mais je doute que tu sois en désaccord sur la totalité si ce n'est juste par pur plaisir de contrariété.
        
        Tu fais de la mauvaise fois à tous tes paragraphes. Tes flugschreiber (oui l'allemand c'est plus classe que l'anglais) tu les as aussi dans tes paquets debian/rpm ou autre. Ton ansible tu peux très bien t'en servir sur du docker, ça ne pose véritablement aucun problème, je le fais.
        
        Une flugschreiber dont tu as accès aux sources, que tu peux reconstruire avec toutes les modifications que tu veux ou simplement les dériver, dans la quelle tu peux ouvrir un shell pour y faire tout ce qui peux te faire plaisir… ce n'est pas une flugschreiber. Tu peux trouver que la granularité n'est pas assez fine pour toi, mais rien est caché et tout est maîtrisable (plus facilement qu'avec des paquets de distribution (jongler avec les diversions, les rebuilds de paquets etc ce n'est pas particulièrement simple).
        
        Je te conseil d'essayer de re-construire à chaque faille d'OpenSSL, ou chaque mise à jour de libc une infrastructure qui contient 500-600 containers docker en productions… Allez de préférence, avec des distributions différentes et des images différentes.
        
        Sur ce genre de trucs si tu fais n'importe quoi, c'est de ta faute à toi plus qu'à la techno que tu utilise. À toi de choisir ou construire les conteneurs correctement.
        
        Tu affirme que la techno ne permet pas sans la connaître ou avoir cherché à la comprendre. Comme tu peux faire de l'héritage d'image et que si tu construit véritablement une infra avec 500 images différentes, alors tu dois faire partir toutes tes images d'une base que tu maîtrise. Finalement tu va modifier cette base. Puis faire le rebuild de tout le reste (c'est incrémental). Ça marche bien (tu peux gérer tout ça dans un gestionnaire de version et une CI comme jenkins tout est automatique et totalement sous ton contrôle => c'est pas vraiment l'idée qu'il y a derrière les flugschreiber). Ou alors il va falloir que tu en dise plus.
        
        Comprends-moi bien, il y a pleins de bonnes raisons de ne pas envoyer du docker en prod (notamment pour les bases de données), mais là c'est plus un changement de démarche qu'une quelconque impossibilité. Si la démarche en question est critiquable, mais tu affirme que c'est impossible ce qui est tout faux.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: A chaque clou son marteau
        
        Posté par Firwen (site web personnel) le 01 février 2017 à 15:48. Évalué à 1. Dernière modification le 01 février 2017 à 15:50.
        
        Tu fais de la mauvaise fois à tous tes paragraphes. Tes flugschreiber (oui l'allemand c'est plus classe que l'anglais) tu les as aussi dans tes paquets debian/rpm ou autre.
        
        Quand on utilise une langue ( ou fait semblant ), c'est bien de la connaître un minimum et d'éviter Google Translate.
        
        Blackbox se dit "blackbox" en Allemand. L'allemand est une langue précise et "flugschreiber" est réservé pour les boites noires des avions.
        
        [^] # Re: A chaque clou son marteau
        
        Posté par barmic le 01 février 2017 à 15:52. Évalué à 3.
        
        Une boite noire c'est quelque chose dont on ne maîtrise pas ce qui se passe à l'intérieur… Je sais pas en quoi docker est une boite noire.
        
        « Quand on utilise un mot (quelque soit la langue), c'est bien de savoir un minimum à quoi ça correspond. »
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: A chaque clou son marteau
        
        Posté par Firwen (site web personnel) le 01 février 2017 à 15:57. Évalué à 3.
        
        Une boite noire c'est quelque chose dont on ne maîtrise pas ce qui se passe à l'intérieur… Je sais pas en quoi docker est une boite noire.
        
        Je viens de passer 3 paragraphe à tenter de l'expliquer et j'ai la forte impression que tu ne veux pas écouter dans tous les cas.
        
        Ceci dit, si tu es au FOSDEM, fait le moi savoir, je te paie un café et on pourra en discuter :)
        
        [^] # Re: A chaque clou son marteau
        
        Posté par barmic le 02 février 2017 à 01:59. Évalué à -1.
        
        Ceci dit, si tu es au FOSDEM, fait le moi savoir, je te paie un café et on pourra en discuter :)
        
        Bof. D'une part je n'y serais, pas d'autre part tu semble soit ne pas comprendre ce qu'est docker soit ce qu'est une boite noire. J'ai décris en long en large et en travers qu'il est possible de reconstruire en modifiant donc à froid et de modifier à chaud tout ce que tu peux imaginer et je n'ai pas vu d'autre explication que des affirmations sans même une explication. Le café n'est pas une explication. Ça ne te plaît pas, tant mieux, mais pas la peine d'en discuter si c'est pour des raisons non rationnelles :)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: A chaque clou son marteau
        
        Posté par Lutin le 03 février 2017 à 16:08. Évalué à 5.
        
        C'est triste ton avis sur les cafés gratuits.
    - [^] # Re: A chaque clou son marteau
      
      Posté par Stibb le 07 février 2017 à 11:50. Évalué à 1.
      
      oui il faudra attendre, et c'est très bien. Car il y aura plus de ca ou, quand tu télécharges Firefox, Chrome, etc, en dehors de ta distribution, qui ne marcheront pas car telle dépendances n'est pas testée, pas fonctionnelle.
      
      Ce que tu ne te rends pas compte, c'est que les soft comme ceux que tu cites incorporent deja des dépendances statique, pour éviter justement qu'une mise à jour intempestive ne casse le logiciel, car non testée par les mainteneur de ta distribution.
      
      Si le soft avait été installé par apt-get pas de probleme.
  - [^] # Re: A chaque clou son marteau
    
    Posté par flagos le 31 janvier 2017 à 14:00. Évalué à 3.
    
    D'ailleurs quand je trouve une lib python qui m'intéresse je regarde toujours si elle est disponible sur apt et c'est presque toujours le cas.
    
    Wahou, des lib python en apt ! Et tu fais comment pour avoir un equivalent de virtualenv ou de pip freeze ?
    - [^] # Re: A chaque clou son marteau
      
      Posté par reynum (site web personnel) le 31 janvier 2017 à 14:18. Évalué à 2.
      
      Je ne suis pas sûr de comprendre votre question mais naïvement je répondrais :
      
      Pour les venv
      sudo apt install python3-virtualenv/testing
      
      Pour pip freeze
      apt search <module_name or partial_module_name> |grep python
      
      kentoc'h mervel eget bezan saotred
- [^] # Re: A chaque clou son marteau
  
  Posté par ZeroHeure le 31 janvier 2017 à 14:30. Évalué à 4.
  
  C'est intéressant, tu sous-entend au début (mais ta conclusion dit l'inverse) qu'aucun système ne peut prétendre tout résoudre à la fois. Partant de là on peut se demander comment faire efficacement cohabiter les trois outils : celui du sysadmin et de la distribution, celui du développeur et celui de l'utilisateur "bureau". Sans oublier le mainteneur de logiciels à qui on demande des paquets pour tous les systèmes possibles…
  
  Je ne vois aucune gêne à la cohabitation de tous ces systèmes, puisqu'ils ne visent pas le même public. Et quand bien même on les unifierait un peu, l'évolution fera apparaître à moyen terme des nouveaux besoins et l'histoire se répètera.
  
  Je ne dis là rien de neuf.
  C'est le discours autour du système de paquet prétendant être mieux que les autres, ou la recherche d'une solution universelle, qu'on devrait éviter : nous ne sommes pas des machines, mais des êtres divers avec des besoins différents. Note que le discours c'est moi le meilleur, je suis le sauveur semble faire partie de la destinée humaine, et s'accompagne toujours de il faut, il faut. On l'entend dans tous les domaines (en ce moment chez les candidats à la présidentielle).
  
  En parenthèse, il me semble que le conflit sysadmin-développpeur peut-être, sinon résolu, au moins soulagé, par les machines virtuelles, compartimentages et chroot, ce qui le sors du souci de paquetages.
  
  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
  - [^] # Re: A chaque clou son marteau
    
    Posté par pulkomandy (site web personnel, Mastodon) le 31 janvier 2017 à 16:34. Évalué à 5.
    
    Pour les utilisateurs: le système de paquets de Haiku permet d'installer, d'une part, des paquets systèmes dans /system, d'autre part, des paquets utilisateurs dans /home/config. Plusieurs variables d'environnement (PATH, chemin de recherche des includes du compilateur, etc) sont configurées pour tenir compte de l'existence de ces deux hiérarchies. Ce qui permet d'avoir une partie commune au système, et une propre à chaque utilisateur qui peut compléter où remplacer des choses.
  - [^] # Re: A chaque clou son marteau
    
    Posté par lasher le 07 février 2017 à 21:03. Évalué à 3.
    
    C'est intéressant, tu sous-entend au début (mais ta conclusion dit l'inverse) qu'aucun système ne peut prétendre tout résoudre à la fois. Partant de là on peut se demander comment faire efficacement cohabiter les trois outils : celui du sysadmin et de la distribution, celui du développeur et celui de l'utilisateur "bureau". Sans oublier le mainteneur de logiciels à qui on demande des paquets pour tous les systèmes possibles…
    
    Alors j'arrive après la bataille, mais par exemple pour Perl, il existe des outils dans Debian qui permettent d'utiliser cpan/CPAM.pm (l'outil de gestion de paquetages de Perl), de les télécharger, lancer les scripts kivonbien, puis de convertir le tout sous forme de paquet .deb en modifiant les chemins pour les bibliothèques, etc. Les fois où je m'en étais servi, cet outil faisait le boulot comme je voulais, et du coup j'avais un workflow relativement fluide.
    
    Qu'est-ce qui empêcherait les gens de faire de même avec les gem/pip/etc. ? (je suis sûr qu'il y a de bonnes raisons, je ne sais juste pas lesquelles).
    - [^] # Re: A chaque clou son marteau
      
      Posté par flan (site web personnel) le 08 février 2017 à 07:29. Évalué à 2.
      
      C'est également le cas pour pip, mais ce n'est pas toujours directement applicable au paquet Python s'il n'est pas parfait dès le début (par exemple, si le paquet Python s'appelle « toto », le nom Debian sera « python3-toto »… sauf que si le paquet Python s'appelle déjà « python-truc », on ne va pas l'appeler « python3-python-truc »…).
      
      Mais en pratique, ça fonctionne assez bien.
    - [^] # Re: A chaque clou son marteau
      
      Posté par Tonton Th (Mastodon) le 08 février 2017 à 10:26. Évalué à 3.
      
      pour Perl, il existe des outils dans Debian qui permettent d'utiliser cpan/CPAM.pm (l'outil de gestion de paquetages de Perl), de les télécharger, lancer les scripts kivonbien, puis de convertir le tout sous forme de paquet .deb
      
      Tu pourrais donner plus de détails, ce truc m'interesse pas mal en ce moment ?
      - [^] # Re: A chaque clou son marteau
        
        Posté par lasher le 08 février 2017 à 21:49. Évalué à 2.
        
        Je ne me souviens plus du nom, mais après googling, je crois que j'utilisais dh-make-perl (je peux me tromper). Lorsque ça ne marchait pas, c'était généralement que la compilation au niveau de Makefile.PL se passait mal (donc le paquetage était mal formé de toute manière).
        
        Y'a un topic sur PerlMonks à ce sujet.
    - [^] # Re: A chaque clou son marteau
      
      Posté par BAKfr le 08 février 2017 à 17:15. Évalué à 0.
      
      Pour pip, ça marche bien avec des programmes simples, mais dès qu'on sort du cas basique d'une lib ou un logiciel en cli, c'est plus compliqué. Par exemple la génération des fichiers Desktop, l'association de fichier au programme, et tout ces petits trucs qui font partie de l’intégration avec le système sont compliqué.
      Un autre point qui est difficile à traiter, c'est la location des ressources: Mettre les fichiers de données au bon endroit dans /usr/share de façon propre n'est pas simple, et y accéder depuis le code python non plus.
      
      Et puis aussi, l'histoire du packaging python est compliqué, avec plein de réécriture de techno plus ou moins compatibles entre-elles (setuptools, distutils, …), donc on a une grande diversité de format et de méthode d'installation.
# Guix

Posté par dzecniv le 31 janvier 2017 à 00:08. Évalué à 8.

Même idée que Nix(os), puisque cousin: c'est un objectif de Guix, le gestionnaire de paquets et Guix SD la distro.

On a un exemple avec Guix-tox, qui souhaite remplacer l'outil de test python tox pour justement la raison que pip ne peut pas installer des dépendances qui ne sont pas dans pip. Guix/Guix-tox les gère.

J'ai lu qu'ils travaillent sur la possibilité d'installer les paquets de npm et pip.

Guix permet(tra) les conteneurs à la Docker, les environnements de dév,…

(lien: avantages de Guix dans un environnement de supercalculateurs)
# des recettes

Posté par bunam le 31 janvier 2017 à 00:11. Évalué à 1.

Je pense à http://brew.sh ou pourquoi pas Ansible/Chef/…?
Ne connaissant pas http://nixos.org/nix/ peut-être que ça correspond à l'idée.

J'ai déjà produit des RPMs ajoutés a un DVD d'install ou en les ajoutant via un dépôt à une CentOS minimale = une bonne galère ;)

Sinon sous Mac j'utilise :
- macport.org (rigide, mais sur)
- brew mais il ne gère pas correctement la MAJ certaines recettes, c'est peu-être le point faible de celles-ci
- npm
- gem
- mvn
- pip{2,3} c'est un beau bince car il provient du système natif, de macport.org et de brew
- go get (go de google)
- composer (php)
- docker beta (je ne l'utilise pas plus)

Sans lignes de commandes :
- macupdate.com fournir un soft pour faire des maj des logiciels de bureau plus ou moins rapidement sans passer par leur système interne
- mas (Mac Apple Store)
- [^] # Re: des recettes
  
  Posté par Arthapz le 31 janvier 2017 à 14:20. Évalué à 1.
  
  A noté que l'on peut mettre à jour a partir de mas en ligne de commandes
# PPAs, Haiku, alien, ...

Posté par pulkomandy (site web personnel, Mastodon) le 31 janvier 2017 à 09:08. Évalué à 3.

Il y a des solutions qui existent depuis longtemps. Dans Debian et toutes les distributions basées dessus, tu as l'outil "alien" qui permet d'installer des RPM. Comme ça, le développeur fournit un RPM, et il peut s'installer partout. Par contre, c'est difficile d'avoir un RPM avec les bonnes dépendances et qu'on arrive quand même à installer.

Dans Ubuntu, il y a les PPA, qui permettent à plein de gens de proposer des paquets. Tu as la même chose avec AUR pour ArchLinux, et également dans Gentoo.

Pour la difficulté à créer un paquet, je peux en parler du côté de Haiku, que je connaît bien. C'est une tâche qu'on confie aux participant du Google Code-In, qui ont de 13 à 17 ans, et c'est un truc qui marche plutôt bien (sachant que les participants n'ont souvent jamais entendu parler de Haiku avant de participer à ce concours).

Je pense aussi à CPack, qui peut être utilisé avec CMake et permet de générer un .deb, un .rpm, un .tar.gz avec des binaires, un paquet pour Haiku, et/ou un installeur pour Windows, entre autre choses.

Sous Windows, il y a chocolatey, un outil qui ne se base pas sur des paquets ou une distribution. Il se contente de télécharger les installeurs depuis le site des logiciels qu'on veut installer, et de les exécuter automatiquement.

Enfin, un problème qui n'a pas encore été trop abordé. Quand on est développeur, on a souvent plusieurs projets, parfois des vieux trucs. Et on a parfois besoin de compiler un projet avec les bibliothèques et outils de l'époque, les nouvelles versions n'étant pas forcément compatibles. Là, le gestionnaire de paquets de la distribution ne suffit pas. Par contre je crois qu'on peut s'en sortir avec les npm et compagnie en installant les choses dans un répertoire spécifique. Vous me direz que c'est pas bien de dépendre de vieilles versions de bibliothèques, mais on a pas toujours le choix où le temps de tenir un projet à jour tout le temps.
- [^] # Re: PPAs, Haiku, alien, ...
  
  Posté par Renault (site web personnel) le 31 janvier 2017 à 09:35. Évalué à 3.
  Il y a des solutions qui existent depuis longtemps. Dans Debian et toutes les distributions basées dessus, tu as l'outil "alien" qui permet d'installer des RPM. Comme ça, le développeur fournit un RPM, et il peut s'installer partout. Par contre, c'est difficile d'avoir un RPM avec les bonnes dépendances et qu'on arrive quand même à installer.
  
  En fait la question des RPM, DEB ou autres n'est pas réellement pertinente, à part ceux qui font les paquets qui ce sont qui vont subir la difficulté (ou pas) d'en concevoir un proprement. On le voit avec en effet alien qu'il ne suffit pas de convertir de format pour résoudre le soucis.
  
  Car ce qui diffère vraiment entre les distributions, ce sont les conventions de nommages des paquets (httpd pour Fedora et assimilés, apache pour Debian et similaires), les numéros de version (faire fonctionner un RPM de Fedora flambant neuf sur une Debian pourrait échoué à cause des différences de versions) sans compter les options de compilations attribués à chaque paquet ou d'autres choses comme de l'intégration à des composants systèmes comme SELinux qui est fait par la distribution.
  
  Et ces aspects là sont fondamentaux et insolubles. Pour vraie du vrai cross-distribution il faut donc soit :
  - Repartir systématiquement des sources, mais bon on n'est pas chez Gentoo ici ;
  - Inclure un maximum de dépendances dans le paquet pour que cela passe partout (modulo un noyau et une base suffisamment compatibles mais c'est assez faisable).
  - [^] # Re: PPAs, Haiku, alien, ...
    
    Posté par robin le 31 janvier 2017 à 10:23. Évalué à 3.
    
    Repartir systématiquement des sources, mais bon on n'est pas chez Gentoo ici ;
    
    En quoi un gestionnaire de paquet décrivant comment compiler les sources (tel que les AUR d'arch) avec un système de cache binaire ne pourrais pas fonctionner. N'étant pas sûr d'être clair, voici un petit exemple.
    
    Un dev créer son soft, et écrit sa recette. Il l'utilise pour compiler sur son PC qui va tout re-compiler pour vérifier que tout marche.
    
    Un utilisateur est sur Fedora, il veux installer le paquet. Fedora propose un cache binaire (la compilation a été faite sur les serveur de Fedora), ce qui permet à l'utilisateur de directement télécharger le binaire.
    
    Un utilisateur de Debian veut également installer ce paquet. Debian propose également un cache binaire, mais qui inclus des patchs pour bien fonctionner sur Debian. C'est transparent pour cet autre utilisateur qui va également télécharger un binaire.
    
    Enfin un utilisateur de Slackware veut l'installer mais pas de chance le cache binaire de Slackware ne contient pas ce pacquet. Par conséquent le paquet va être builder sur son PC depuis les sources (comme pour le dev).
    
    Les dépendances suivant le même schéma, il est donc toujours possible de re-construire un paquet quelque-soit son système.
    
    Ça me parait trop simple pour que ça n'existe pas déjà. Où est ce que le bas blesse dans mon raisonnement ?
    
    bépo powered
    - [^] # Re: PPAs, Haiku, alien, ...
      
      Posté par pulkomandy (site web personnel, Mastodon) le 31 janvier 2017 à 11:23. Évalué à 2.
      
      C'est l'approche de pkgsrc, développé d'abord chez NetBSD mail il existe des dépôts de binaires pour Solaris, par exemple.
      Par contre, ça ne s'intègre pas (je crois) avec un éventuel dépôt pré-existant (celui de Debian ou de Fedora, par exemple). Tu risques donc d'avoir des paquets en double et installés au même endroit, ce qui risque de créer plein de problèmes.
    - [^] # Re: PPAs, Haiku, alien, ...
      
      Posté par Renault (site web personnel) le 31 janvier 2017 à 12:54. Évalué à 2.
      Je ne comprends pas ton idée de cache binaire.
      Si je devine ce que tu veux dire, cela implique que le paquet existe déjà pour la distribution. Ce qui n'est pas toujours le cas (je dirais même que ce sont les paquets absents des dépôts qui sont les plus concernés par les dispositifs qu'on décrit).
      
      Tu mets sous le tapis plusieurs problèmes :
      
      Comment la recette devine le nom de la dépendance qui manque (les noms de paquets diffèrent pour un même paquet) ? Comment il gère le cas où une distribution fournit la dépendance et une autre pas ? Comment il gère le cas où deux distributions ont des options de compilations qui diffèrent fondamentalement ce qui peut induire qu'une dépendance soit inutilisable car avec des trucs en moins ?
      
      Quid des licences ? Fedora Copr permet par exemple de faire des équivalents de PPA et qui pourraient, d'un point de vue architecture, ressembler à ce que tu proposes. Mais Fedora refuse que ce système soit utilisé par autre chose que des paquets libres non couverts par des brevets.
      
      Bref, tu ne réponds pas vraiment à ces questions. Il ne faut pas se mentir, sur la question de dépôts contre les solutions tout en un, aucun n'est parfait. Suivant le contexte l'un sera plus adapté que l'autre.
      Il est selon moi important que les distributions proposent les deux modèles simplement, pour prendre en compte tous les cas de figures. Ensuite à l'utilisateur de choisir ce qui est le mieux pour lui au cas par cas.
      - [^] # Re: PPAs, Haiku, alien, ...
        
        Posté par robin le 31 janvier 2017 à 17:09. Évalué à 1.
        
        Merci pour les détails, je n'avais effectivement pas pensé à l'histoire des licences, ni celle des paquets compilés avec des options de compilation différentes qui les rendent en pratique incompatible.
        
        Et concernant ma proposition c'est en remplacement de apt/rpm/pacman actuel qui marchent très bien, mais sont totalement incompatible entre eux (en pratique, même si je sais que alien et autre existe). Mais effectivement c'est plus compliqué que ça n'en à l'air, d'où ma question. J'ai préféré passer (un peu) pour un idiot, afin de mieux comprendre le problème que de me taire.
        
        bépo powered
    - [^] # Re: PPAs, Haiku, alien, ...
      
      Posté par bunam le 31 janvier 2017 à 14:12. Évalué à 1. Dernière modification le 31 janvier 2017 à 17:00.
      macport.org, basé sur port, dispose d'un cache binaire maintenant.
      avant c'était compilation sur le poste
      il y a des variants, si on utilise le variants non classic on se paye une recompilation : (sudo port install curl+wolfssl)
      
      port info curl curl @7.52.1 (net, www) Sub-ports: curl-ca-bundle Variants: ares, darwinssl, gnutls, gss, http2, idn, metalink, openldap, sftp_scp, spnego, [+]ssl, universal, wolfssl Description: curl is a client to get documents/files from servers, using any of the supported protocols. The command is designed to work without user interaction or any kind of interactivity. Homepage: https://curl.haxx.se Build Dependencies: pkgconfig Library Dependencies: zlib, openssl, curl-ca-bundle Platforms: darwin, freebsd License: Curl Maintainers: Email: ryandesign@macports.org
# Dockerfiles

Posté par MTux le 31 janvier 2017 à 09:46. Évalué à 2.

C'est exactement la raison pour laquelle je gueule en tant que sysadmin contre les dev qui veulent utiliser plein de gestionnaires de dépendances au lieu d'utiliser apt, et je passe pour un emmerdeur.

Une solution intermédiaire : construire soi-même les images Docker ?
Quand tu prends une image Docker depuis le Docker hub ou un autre dépôt, c'est en gros un paquet de binaires dont tu ne sais pas grand chose. MAIS souvent tu as accès au Dockerfile correspondant, c'est à dire le fichier de recette qui te permet de construire toi-même l'image, tu peux donc t'assurer que tu utilise des versions de logiciels à jour ou patchés.
- [^] # Re: Dockerfiles
  
  Posté par Renault (site web personnel) le 31 janvier 2017 à 09:56. Évalué à 5.
  
  En tant que développeur je vais te répondre, parfois on n'a pas le choix et cela simplifie grandement la vie.
  
  Dans mon boulot, il m'arrive de devoir travailler (en systèmes embarqués) sur des programmes antédiluviens, qui nécessitent des programmes ou bibliothèques non maintenues dans les distributions principales. On fait quoi ? On jette tout et on dit merde au client et au fournisseur ?
  
  Docker et assimilés permettent de contourner les limitations de notre système pour développer sur ce projet ce qui économise une VM ou éventuellement un boot dédié pour développer dessus. Cela permet aussi très facilement de s'abstraire des différences entre distributions. Tiens un sous-traitant débarque avec un système différent sur sa machine, pas grave, il va avoir facilement les outils pour développer dessus de manière identique aux autres. La production a un serveur sous Debian X quand les développeurs sont sur Debian Y ? Pas de soucis, tout le monde pourra avoir la même version que la prod localement pour tester.
  
  Bref, n'en veux pas forcément aux dev, pour bien faire notre travail, Docker ou autres peuvent être vraiment indispensables. Je ne dis pas que cela doit être fait pour tout et n'importe quoi, mais cela fait sens dans ce contexte.
  - [^] # Re: Dockerfiles
    
    Posté par guppy le 31 janvier 2017 à 11:37. Évalué à 3.
    
    Dans mon boulot, il m'arrive de devoir travailler (en systèmes embarqués) sur des programmes antédiluviens, qui nécessitent des programmes ou bibliothèques non maintenues dans les distributions principales. On fait quoi ? On jette tout et on dit merde au client et au fournisseur ?
    
    Pourquoi ne pas lier statiquement uniquement les binaires obsolètes dans ce cas ?
    - [^] # Re: Dockerfiles
      
      Posté par Renault (site web personnel) le 31 janvier 2017 à 11:55. Évalué à 4.
      
      Car cela ne répond pas forcément au besoin ?
      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.
      
      Et souvent, si tu travailles sur de vieilles versions ce qui est courant, ta distribution ne propose pas ce qu'il faut. Un symbole introuvable, une en-tête manquante, ou un outil qui a changé de comportement ce qui casse tout (GCC en particulier qui a activé par exemple C++11 par défaut).
      
      La compilation statique ne résout que partiellement ce genre de soucis. Et cela reste contraignant pour le déploiement. Avec Docker, le gars débarque, en 10 minutes montre en main il a les outils d'opérationnels. Combien de temps pour s'il doit récupérer et placer au bon endroit les outils ? Sans compter qu'il devra aussi chercher dans sa distribution ce qui marche manuellement dans les dépôts.
      
      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.
      - [^] # Re: Dockerfiles (petit détail)
        
        Posté par madhatter (site web personnel) le 31 janvier 2017 à 14:25. Évalué à 3.
        
        Docker pallie aisément ce besoin.
        
        C'est "pallier quelque chose" et non "pallier à quelque chose".
        
        ;-)
        
        There is no spoon...
        
        [^] # Re: Re: Dockerfiles (petit détail)
        
        Posté par Renault (site web personnel) le 31 janvier 2017 à 16:15. Évalué à 1.
        
        Hum, aisément est un adverbe et non une préposition comme à, du coup je ne vois pas la pertinence de ta remarque : ma phrase est correcte.
        
        [^] # Re: Re: Dockerfiles (petit détail)
        
        Posté par BAud (site web personnel) le 31 janvier 2017 à 16:51. Évalué à 3.
        
        Ta phrase était en fait :
        
        Docker pallie aisément à ce besoin.
        
        qu'il a sans doute corrigé par habitude :-) (donc non correcte initialement)
      - [^] # Re: Dockerfiles
        
        Posté par guppy le 31 janvier 2017 à 15:00. Évalué à 2.
        
        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 Renault (site web personnel) le 31 janvier 2017 à 15:11. Évalué à 6.
        
        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 ?
        
        Tu oublies quatre choses :
        
        Des versions supportées simultanément, il y en a parfois plusieurs. Les distributions proposent rarement tous les supports d'un coup.
        
        Il y a parfois des outils, non reliés au réseau, qui sont utiles et dont le portage coût cher par rapport au gain. Car ici les considérations de sécurité sont absentes et donc il faut se coltiner un peu les vieux trucs tant que c'est possible.
        
        Il y a un temps entre le moment où tu débutes le portage et la fin, et parfois il faut une fonctionnalité ou la correction d'un bogue. Puis il te faut une copie de l'environnement initial pour vérifier que tu n'as pas changé le comportement de l'application dans le portage.
        
        Pour bien tester et développer, il faut minimiser les différences entre la machine de prod et la machine du développeur. Utiliser Docker ou une VM permet de s'abstraire de tout ceci sans être contraignant (avoir la même distribution sur le serveur et les machines de développement ne me paraît pas judicieux).
        
        Pour tout ça, sans être en systèmes embarqués, Docker et autres sont de bonnes solutions. Ce ne sont pas des solutions universelles, mais les distributions traditionnelles non plus… Au bout d'un moment, il faut accepter de faire cohabiter les solutions suivant les besoins.
        
        [^] # Re: Dockerfiles
        
        Posté par guppy le 31 janvier 2017 à 16:25. Évalué à 0.
        
        Il y a parfois des outils, non reliés au réseau, qui sont utiles et dont le portage coût cher par rapport au gain. Car ici les considérations de sécurité sont absentes et donc il faut se coltiner un peu les vieux trucs tant que c'est possible.
        
        On est d'accord, mais c'est un autre cas particulier. Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.
        
        Il y a un temps entre le moment où tu débutes le portage et la fin, et parfois il faut une fonctionnalité ou la correction d'un bogue.
        
        Donc avant d'être portée l'appli est déjà en prod ? trouée ?
        
        Puis il te faut une copie de l'environnement initial pour vérifier que tu n'as pas changé le comportement de l'application dans le portage.
        
        Ok, cas particulier qui concerne les dev.
        
        Pour bien tester et développer, il faut minimiser les différences entre la machine de prod et la machine du développeur.
        
        Dans l'embarqué c'est peut-être le cas je ne sais pas, mais dans le cas général la portabilité est considérée comme une qualité.
        
        Notre désaccord vient de là je pense : dans l'embarqué c'est selon toi une excellente solution et je veux bien te croire, mais dans l'informatique "classique" ce n'en est pas une selon moi. On est formaté par nos domaines d'application respectifs.
        
        Mais pour conclure je préférerai que ce genre de techno restent où elles sont utiles et donc pas sur mes serveurs.
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 31 janvier 2017 à 16:47. Évalué à 4.
        
        On est d'accord, mais c'est un autre cas particulier. Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.
        
        Cas particulier + cas particulier + …
        Pour moi, ce ne sont plus des cas particuliers, à la fin cela représente un taux non négligeable.
        
        Donc avant d'être portée l'appli est déjà en prod ? trouée ?
        
        Tu sais il y a pas mal d'applications qui restent en vie très longtemps, plus longtemps que plusieurs versions de PHP ou de Python. Quand c'est un peu gros, la transition n'est pas immédiate. Donc tu peux avoir une application qui tourne mais avec des solutions obsolètes oui. On fait quoi dans ce cas ? On coupe tout ?
        
        Ok, cas particulier qui concerne les dev.
        
        Les développeurs ne sont qu'un cas particulier ? En fait c'est quoi ton cas général car ça commence à faire beaucoup.
        
        Dans l'embarqué c'est peut-être le cas je ne sais pas, mais dans le cas général la portabilité est considérée comme une qualité.
        
        Quand ton langage change de syntaxe ou d'écosystème, le portage n'est pas trivial. 10 ans après le début de Python 3 de nombreuses applications n'en ont pas fini avec Python 2 encore (près de 33% des applications ayant une dépendance avec Python dans Fedora dépendent de Python 2). Quand ton compilateur change les normes par défaut ce qui flingue certains codes aux comportements anciens dont tu n'as pas toujours le plein contrôle tu ne peux pas le prévoir non plus.
        
        Tu peux faire la portabilité maximale que tu ne peux pas te prémunir de ce genre de changements.
        
        Notre désaccord vient de là je pense : dans l'embarqué c'est selon toi une excellente solution et je veux bien te croire, mais dans l'informatique "classique" ce n'en est pas une selon moi. On est formaté par nos domaines d'application respectifs.
        
        Pas du tout, je viens de te montrer que le reste de l'informatique aussi était concernée par ces questions (moins, mais quand même). Je l'ai vu en vrai ces situations aussi. Les applications ne sont pas tous des Hello world à porter tu sais.
        
        Mais pour conclure je préférerai que ce genre de techno restent où elles sont utiles et donc pas sur mes serveurs.
        
        On parle d'offrir le choix aux utilisateurs d'utiliser le dépôt ou les applications tout en un et toi tu me parles de serveurs ? Je comprends pourquoi tu me réponds à côté aussi.
        
        [^] # Re: Dockerfiles
        
        Posté par guppy le 31 janvier 2017 à 17:28. Évalué à -1.
        
        Pour moi le cas général à l'heure actuelle c'est les applications dont l'interface est accessible via le réseau (web en général). C'est ça que les utilisateurs utilisent le plus. Effectivement certains utilisateurs (qui sont des devs embarqués) doivent utiliser des vieux compilos pour de bonnes raisons, mais tu vas être d'accord avec moi que c'est une petite proportion des utilisateurs de l'informatique ?
        
        D'autres aussi utilisent des ordinateurs non reliés au net. Mais c'est devenu une petite proportion des utilisateurs également et cette petite proportion devient de plus en plus petite non ?
        
        Cette grande proportions d'utilisateurs utilisent facebook, google, youtube, le site de leur banque, le site des impôts, des forums divers et variés etc…
        
        Toi en tant que dev, j'imagine que tu as dispositions un wiki, un bugtracker, peut-être un serveur de supervision, un calendrier partagé etc. Si tu te connectes à tes objets connectés c'est peut-être par SSH ?
        
        Le cas général ça me semble donc être ça. Et pour ce cas général je pense que la solution d'un unique dépôt centralisé est la meilleure.
        
        Tu sais il y a pas mal d'applications qui restent en vie très longtemps, plus longtemps que plusieurs versions de PHP ou de Python. Quand c'est un peu gros, la transition n'est pas immédiate. Donc tu peux avoir une application qui tourne mais avec des solutions obsolètes oui. On fait quoi dans ce cas ? On coupe tout ?
        
        Si le mainteneur du site de ta banque te dit que la version d'aujourd'hui est trouée mais t'inquiète pas, ils sont en train de développer la correction qui arrivera semaine 53 ça te pose pas de soucis ?
        
        J'ai des applis en php sur mes serveurs installés depuis 2007 ; elles ont du subir plusieurs mises à jour de php, sans problème. Bien sûr ça ne veut pas dire que les problèmes n'arrivent jamais mais je ne les ai jamais rencontré par contre.
        
        J'évite Python pour la raison que tu mentionnes (je dois juste avoir une instance d'un Radicale qui traine).
        
        On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.
        
        PS : prends pas ça comme une attaque personnelle.
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 31 janvier 2017 à 21:20. Évalué à 4.
        
        Pour moi le cas général à l'heure actuelle c'est les applications dont l'interface est accessible via le réseau (web en général). C'est ça que les utilisateurs utilisent le plus.
        
        Ça me paraît un poil exagéré.
        Les applications lourdes sur chaque poste de travail, les applications d'entreprises non visibles de l'extérieur sans oublier les systèmes embarqués existent et je pense que l'ensemble surpasse ce que tu décris en quantité.
        
        Effectivement certains utilisateurs (qui sont des devs embarqués) doivent utiliser des vieux compilos pour de bonnes raisons, mais tu vas être d'accord avec moi que c'est une petite proportion des utilisateurs de l'informatique ?
        
        Il n'y a pas que les développeurs embarqués hein… Tout développeur peut être confronté à une situation où un Docker est bien utile pour reproduire localement un environnement de développement ou de tests. Cela n'a peut être pas été ton cas, mais je t'assure que cela arrive très souvent. Je dirais même que c'est une bonne pratique pour reproduire au mieux l'application sur l'environnement cible (comme un serveur) sans pour autant avoir le même système.
        
        D'autres aussi utilisent des ordinateurs non reliés au net. Mais c'est devenu une petite proportion des utilisateurs également et cette petite proportion devient de plus en plus petite non ?
        
        Des ordinateurs en entreprises qui ont des fonctions très minimalistes et sans accès au net, il y en a une armée dans la nature.
        
        Je ne sais pas où tu bosses, mais cette situation est très fréquente. Tu as déjà été dans un labo de recherches aussi ? Tu en pleurerais vu ce que tu dis ici.
        
        Cette grande proportions d'utilisateurs utilisent facebook, google, youtube, le site de leur banque, le site des impôts, des forums divers et variés etc…
        
        Ils utilisent aussi une machine à café, un lave linge ou lave vaisselle, une télé ou un téléphone… Qui ont été programmés par quelqu'un.
        Bref, oui pas mal de gens utilisent ce que tu dis, mais ce n'est que la partie émergée des applications existantes et utilisées au quotidien aujourd'hui.
        
        Le cas général ça me semble donc être ça. Et pour ce cas général je pense que la solution d'un unique dépôt centralisé est la meilleure.
        
        Mais même pour ton cas général ceux qui le développent ont intérêt à utiliser Docker. Il est même probable qu'ils le fassent sans que tu ne le saches.
        
        Si le mainteneur du site de ta banque te dit que la version d'aujourd'hui est trouée mais t'inquiète pas, ils sont en train de développer la correction qui arrivera semaine 53 ça te pose pas de soucis ?
        
        Tu sais que les banques et assurances, ces grosses structure, ont beaucoup de code écrit en COBOL ? Tu sais, ce langage hyper moderne et probablement hyper sécurisé.
        Je doute que la sécurité des applications qu'ils manipulent reposent uniquement sur la mise à jour du système. Je suis convaincu qu'ils ont beaucoup de choses dans leur infrastructure pour que si faille il y a l'impact soit la plus faible possible.
        
        Pour beaucoup de services la coupure peut coûter plus cher que de laisser tourner malgré les failles (cela dépend évidemment de ce que fait l'application et la machine hein).
        
        On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.
        
        Propose mieux.
        La question de la sécurité des applications embarquées est fondamentale, mais il faut comprendre que ses contraintes font que les raisonnements provenant de développement d'applications dans une infra haute disponibilité ne tiennent pas.
        
        On parle de produits qui ont les caractéristiques suivantes :
        
        Des performances souvent faibles, ce qui t'empêche de faire pas mal de choses (notamment d'utiliser des frameworks ou langages de haut niveau) ;
        
        Des accès à l'énergie ou à Internet intermittent, voire inexistant pour le second cas ;
        
        Souvent des machines difficiles à déboguer, tester ou n'ayant pas un opérateur humain disponible pour le réparer (donc pour les mises à jour il faut des garanties que cela se fasse de manière autonome dans tous les cas) ;
        
        Le produit se paye en une fois, tu fais la maintenance combien de temps du produit ? Comment tu gères le fait que tes logiciels peuvent rendre inopérant le matériel à cause du surpoids qu'il prend avec le temps ?
        
        Car bon, pour les applications Web ou d'entreprise, comme le développement est continue sur des années, les rentrées d'argent sont aussi continues. Tu peux mettre à jour l'infra aussi pour tenir compte du fait qu'avec le temps un logiciel (et ses dépendances) prennent du poids.
        
        Un système embarqué, en général tu le payes une fois à l'achat. Le constructeur ne te vend pas pour ce prix un support illimité (même MS, RH ou Apple ne proposent pas ça pour leur OS). Pourtant moult appareils embarqués tiennent bien au delà des espérances et au delà parfois de la vie de leur propre fabricant. Ton application de la banque, elle va évoluer tant qu'il y a des clients et que la banque est en vie. Et elle peut facilement le faire et facturer tout ça tout le long. Et quand la banque meurt, le service avec donc pas de soucis. Ce raisonnement ne peut pas marcher avec un système embarqué où le constructeur peut disparaître alors que des produits tournent encore, et dont la maintenance pendant 20 ans n'est pas compatible avec une seule facturation du produit (ou alors ce sera exorbitant).
        
        Puis il faut comprendre comment fonctionne le doux univers du matériel. Qualcomm par exemple te sort une puce en 2015. Pour pouvoir l'exploiter et le vendre, ils conçoivent ce que l'on appelle le BSP, qui contient en gros un noyau, un chargeur de démarrage, des bibliothèques, firmwares ou applications pour l'exploiter. Pour des raisons de propriétés intellectuelles et économiques, ils ne maintiennent que très peu le dit BSP.
        
        Les patchs sont de mauvaise qualité, impossible d'envoyer upstream (et si tu essayes de le corriger toi, le processeur ne sera plus vendu quand tu auras fini) et le constructeur s'en fout. Dans 2 ans, il vendra un nouveau modèle, donc quel intérêt il a à porter ses patchs de versions en versions de Linux si peu de temps après son premier jet il fera autre chose ?
        
        On râle, on râle, mais ça ne fait rien changer à l'affaire. J'aimerais aussi que ce soit autrement. De toute façon si on les contraint à faire cette qualité, ça va faire monter les prix des consommables. Et pas mal de gens n'en voudraient pas à un tel prix. Surtout qu'on parle de systèmes peu évolutifs, dont globalement l'application est faite une fois et les mises à jour très rares car difficiles voire impossibles.
        
        Économiquement, il y a donc un soucis pour un support de sécurité pour ces appareils, il y a donc aussi des contraintes techniques, qui rendent ce qui est banal ailleurs en terme de bonnes pratiques, très difficiles à mettre en œuvre.
        
        Je ne rêve pas de cette situation et oui, il y a des discussions en cours sur le sujet qui est bouillonnant. Faut pas croire que c'est un soucis simple à régler et qu'il suffit de faire une application portable ou maintenable pour résoudre tous les cas de figures. Faut pas croire que tout le monde s'en fout. Mais on ne peut pas en l'état actuel des choses garantir la même sécurité à l'application de la banque et de ta lampe connectée.
        
        [^] # Re: Dockerfiles
        
        Posté par guppy le 01 février 2017 à 11:08. Évalué à 2.
        
        Les applications lourdes sur chaque poste de travail, les applications d'entreprises non visibles de l'extérieur sans oublier les systèmes embarqués existent et je pense que l'ensemble surpasse ce que tu décris en quantité.
        
        Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
        
        Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
        
        Des ordinateurs en entreprises qui ont des fonctions très minimalistes et sans accès au net, il y en a une armée dans la nature.
        
        Ben ce que je constate chez mes clients (ça n'a pas valeur d'universalité on est bien d'accord), c'est justement qu'il n'y en a plus beaucoup et que d'années en années, il y en a de moins en moins.
        
        Ils utilisent aussi une machine à café, un lave linge ou lave vaisselle, une télé ou un téléphone
        
        Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc. Pour les 2 derniers, si ils sont connectés ils rejoignent mon cas général. Une télé connectée avec un vieux serveur UPNP doit pouvoir être compromise pour rejoindre un botnet par exemple.
        
        Tu sais que les banques et assurances, ces grosses structure, ont beaucoup de code écrit en COBOL ? Tu sais, ce langage hyper moderne et probablement hyper sécurisé.
        
        C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
        
        Pour beaucoup de services la coupure peut coûter plus cher que de laisser tourner malgré les failles (cela dépend évidemment de ce que fait l'application et la machine hein).
        
        Ok pour ça.
        
        Ce qui me gène dans ces technos (je ne nie pas leur intérêt dans certains cas) c'est que j'ai l'impression de les retrouver de plus en plus dans ce que j'appelle le cas général. Et dans ce cas précis, la balance avantages / inconvénients d'un unique dépôt centralisé des dépendances est meilleure que celle des images qui embarquent leurs dépendances.
        
        Mais on ne peut pas en l'état actuel des choses garantir la même sécurité à l'application de la banque et de ta lampe connectée
        
        Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 01 février 2017 à 11:46. Évalué à 3.
        
        Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
        
        Je peux te dire que j'en développé aussi qui n'ont pas besoin de réseaux, et des tas de programmes qui sont soient dans des labos (tu sais, le programme pour manipuler l'instrument de mesure super cher mais dont seul l'ordi qui y est branché y a accès, pas de réseau) ou même dans les entreprises (bancs d'essais par exemple).
        
        Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
        
        Pas toutes les machines ne sont reliés au réseau interne de la structure. Ou ont un réseau dédié qui ne risque rien. Après si tu as peur de l'attaque par accès physique, on n'y peux plus grand chose.
        
        Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc.
        
        Oui, mais il faut programmer ces machins avec des technos hyper anciennes. D'où l'intérêt d'avoir la possibilité d'un environnement de travail différent que celui que propose ta distribution.
        
        C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
        
        Utiliser un langage que peu de monde connaissent, sur des applications ayant souvent un lourd héritage technique et qui en plus souffre des limitations de son époque, c'est augmenter le risque qu'un problème soit présent dans le système.
        
        Et non la sécurité ne repose pas que sur le fait d'être à jour, je dirais même qu'une bonne sécurité doit prendre en compte l'exploitation d'une faille quelconque pour en limiter ses conséquences. C'est d'ailleurs ce qui se fait en embarqué souvent pour pallier le manque de possibilités pour mettre à jour le système. Genre signature des firmware, cryptographie dans les communications, cloisonnement des applications, réduction des applications au strict minimum ou encore firmware en lecture seule seulement.
        
        Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.
        
        Je trouve que tu mélanges beaucoup de choses en sécurité.
        La sécurité absolue n'existe pas, d'abord, il me semble illusoire de vouloir l'atteindre systématiquement.
        
        Ensuite, ce n'est pas parce qu'ils sont sur le même réseau que tout doit être sécurisé de la même façon. J'espère bien que l'interface Web de ma banque est bien plus sécurisée que les accès à Linuxfr. Pourtant ils sont sur le même réseau. Et si Linuxfr se fait niquer, honnêtement je m'en fiche (je serais déçu mais ça serait supportable), ma banque pas vraiment.
        
        Donc les objets connectés n'ont pas à avoir la même sécurité que l'application de ta banque, que les accès depuis l'extérieur aux données sensibles d'une grande structure via un VPN, etc. Cela ne signifie pas qu'il ne faut pas traiter la question, mais tu ne peux pas en exiger la même chose. Cela n'a pas d'intérêt.
        
        [^] # Re: Dockerfiles
        
        Posté par guppy le 01 février 2017 à 17:15. Évalué à 2.
        
        Oui, mais il faut programmer ces machins avec des technos hyper anciennes. D'où l'intérêt d'avoir la possibilité d'un environnement de travail différent que celui que propose ta distribution.
        
        J'ai l'impression qu'on ne se comprend pas très bien. ;) J'ai jamais dit que docker n'avait aucun intérêt, il y a plusieurs intervenant du thread qui s'en servent et qui assurent que c'est utile pour eux (dont toi), très bien je n'ai rien contre (et je comprends bien l'exemple du vieux compilo pas de soucis) !
        
        C'est quand ça arrive sur mon PC perso ou sur mes serveurs que ça me pose un problème, parce que j'estime que dans ce cas la sécurité est moins bonne avec ce type de solution qu'avec un dépôt centralisé classique.
        
        Et non la sécurité ne repose pas que sur le fait d'être à jour, je dirais même qu'une bonne sécurité doit prendre en compte l'exploitation d'une faille quelconque pour en limiter ses conséquences. C'est d'ailleurs ce qui se fait en embarqué souvent pour pallier le manque de possibilités pour mettre à jour le système. Genre signature des firmware, cryptographie dans les communications, cloisonnement des applications, réduction des applications au strict minimum ou encore firmware en lecture seule seulement.
        
        Dans la partie à laquelle tu réponds : Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue. Je suis d'accord avec toi sur ce point.
        
        Ensuite, ce n'est pas parce qu'ils sont sur le même réseau que tout doit être sécurisé de la même façon. J'espère bien que l'interface Web de ma banque est bien plus sécurisée que les accès à Linuxfr. Pourtant ils sont sur le même réseau. Et si Linuxfr se fait niquer, honnêtement je m'en fiche (je serais déçu mais ça serait supportable), ma banque pas vraiment.
        
        Donc les objets connectés n'ont pas à avoir la même sécurité que l'application de ta banque, que les accès depuis l'extérieur aux données sensibles d'une grande structure via un VPN, etc. Cela ne signifie pas qu'il ne faut pas traiter la question, mais tu ne peux pas en exiger la même chose. Cela n'a pas d'intérêt.
        
        On en reparlera quand ton frigo avec ses 10000 voisins sera en train de faire un ddos sur le site de ta banque. Pour mémoire : https://fr.wikipedia.org/wiki/Mirai_(logiciel_malveillant)
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 01 février 2017 à 17:27. Évalué à 3.
        
        J'ai l'impression qu'on ne se comprend pas très bien. ;) J'ai jamais dit que docker n'avait aucun intérêt, il y a plusieurs intervenant du thread qui s'en servent et qui assurent que c'est utile pour eux (dont toi), très bien je n'ai rien contre (et je comprends bien l'exemple du vieux compilo pas de soucis) !
        
        Je te rappelle que c'est toi qui a commencé l'enfilade en me demandant pourquoi j'utilise ça et que tu essayes de me dire que c'est une mauvaise solution.
        
        C'est quand ça arrive sur mon PC perso ou sur mes serveurs que ça me pose un problème, parce que j'estime que dans ce cas la sécurité est moins bonne avec ce type de solution qu'avec un dépôt centralisé classique.
        
        Précise-le que tu parles de ton cas depuis le début, car honnêtement vu comment le fil a débuté, je ne trouve pas cela évident que tu ne souhaites pas ces solutions chez toi.
        
        On en reparlera quand ton frigo avec ses 10000 voisins sera en train de faire un ddos sur le site de ta banque. Pour mémoire : https://fr.wikipedia.org/wiki/Mirai_(logiciel_malveillant)
        
        Pourtant la plupart des machines de ce monde ne sont pas maintenus par des professionnels, voire pas du tout en fait, loin de là et vont aussi sur Internet. Devons-nous couper l'accès à Internet à tous ces négligeant sur ce prétexte ?
        
        Ce n'est vraiment pas spécifique au monde des objets connectés, le problème existe depuis longtemps. Et gage aux responsables de ces gros systèmes de trouver une parade pour se protéger. Car avant que tous les ordinateurs reliés au Net soient sécurisés pour éviter le botnet, tu peux rêver longtemps. Cela ne signifie pas pour autant que la sécurité des objets connectés ne doit pas exister.
        
        [^] # Re: Dockerfiles
        
        Posté par guppy le 01 février 2017 à 19:40. Évalué à 1.
        
        Je crois que cette discussion a déjà duré trop longtemps ;) Merci pour les exemples que tu as apporté qui m'éclairent sur des vrais cas d'utilisation. Mais pour ma part je reste sur ma position : ça peut faciliter le boulot du dev (voire de l'admin tant qu'il y a pas de soucis), mais ça ne peut que la dégrader l'aspect sécurité. En tout cas c'est toujours intéressant de discuter avec des devs qui travaillent dans d'autres domaines. Bonne soirée à toi.
        
        [^] # Re: Dockerfiles
        
        Posté par Anthony Jaguenaud le 31 janvier 2017 à 23:23. Évalué à 2.
        
        On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.
        
        Le problème des objets connectés, bien au delà des problèmes de faille potentiel dans le logiciel, vient principalement de l’obligation pour le fabriquant de mettre des mots de passes par défaut écrit dans la doc… la première chose à changer, mais l’interface chaise-clavier à souvent un bug.
        
        Si je devais piraté des objets connectés, je ne chercherais pas les failles de sécurités, je téléchargerais les notices d’utilisations.
        
        [^] # Re: Dockerfiles
        
        Posté par Antoine le 06 février 2017 à 13:04. Évalué à 4.
        
        Prétendre que l'utilisateur devrait changer lui-même le mot de passe de ses « objets connectés », c'est faire peser sur l'utilisateur la responsabilité d'un défaut de conception : si le fabricant sait que la plupart des utilisateurs ne changeront pas le mot de passe, alors c'est au fabricant de régler un mot de passe différent sur chaque machine vendue (un peu comme sur les modems ADSL qui viennent d'office avec des identifiants wifi uniques).
        
        La sociologie des utilisateurs n'est pas un bug, c'est une contrainte de conception.
        
        [^] # Re: Dockerfiles
        
        Posté par bunam le 06 février 2017 à 13:52. Évalué à 0. Dernière modification le 06 février 2017 à 13:53.
        
        Un constructeur est considéré comme extrémiste par des fabricants tiers :
        http://www.iphon.fr/post/details-certification-homekit-objets-connectes-873082
        Qui a raison ?
        Cet extrémisme n'est-il pas obligatoire face au public visé ?
        
        [^] # Re: Dockerfiles
        
        Posté par Kerro le 06 février 2017 à 19:58. Évalué à 2.
        
        Un constructeur est ~~considéré~~ présenté comme extrémiste par le service marketing des fabricants tiers
        
        [^] # Re: Dockerfiles
        
        Posté par Anthony Jaguenaud le 06 février 2017 à 16:15. Évalué à 2.
        
        Je comprends ton argument, mais comment régler se problème ?
        
        Ajouter un bouton sur l’objet au moment où on veut s’y connecter pour l’administrer. (peut-être compliqué sur une caméra déjà en place)
        
        Obliger l’utilisateur à se connecter au moins une fois pour changer le mot de passe par défaut. (C’est une contrainte pour l’utilisateur, mais aussi une garantie)
        
        Avoir une clé physique sur clé USB pour l’authentification ? (l’utilisateur va la perdre)
        
        …
        
        Je n’ai pas d’autre idée pour le moment.
        
        [^] # Re: Dockerfiles
        
        Posté par barmic le 06 février 2017 à 16:29. Évalué à 3.
        
        générer un mot de passe unique comme avec les box maintenant
        
        utiliser un certificat client que le constructeur te fournit
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Dockerfiles
        
        Posté par Juke (site web personnel) le 06 février 2017 à 16:46. Évalué à 3.
        
        utiliser un certificat client que le constructeur te fournit
        
        Comment tu geres quand le constructeur cesse son activité ? (et ça arrivera)
        
        [^] # Re: Dockerfiles
        
        Posté par barmic le 06 février 2017 à 16:52. Évalué à 3.
        
        Comment tu geres quand le constructeur cesse son activité ? (et ça arrivera)
        
        Tu change de matériel (c'est ce que tu devrait faire quand tu perds le support, parce que sinon tu es ouverts à toutes les failles pas encore corrigée). Si tu as du support du constructeur initial ou d'ailleurs, tu pourra changer l’autorité.
        
        Ces choses ne sont pas des stylos. Ça ne peut pas être acheté et oublié. Il faut appliquer les mises à jour régulièrement.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 06 février 2017 à 19:46. Évalué à 3.
        
        Et le support du matériel doit être illimité ?
        Car maintenir tout un firmware potentiellement sur 10 ans, c'est très très cher, surtout s'il y a différents produits à maintenir et qu'ils ne peuvent pas supporter la montée en version (car pas assez puissant pour prendre en charge des composants trop récents).
        
        Du coup cela signifie que tout doit être racheté régulièrement, ce qui coûte cher et n'est pas très écologique non plus.
        
        [^] # Re: Dockerfiles
        
        Posté par barmic le 07 février 2017 à 07:36. Évalué à 4.
        
        Si tu garde du matériel non maintenu et que ton matériel contribue à une attaque d'envergure, tu as une part de responsabilité. Si tu as une fibre écologique, tu devrais de base te poser la question de l'utilité réelle des objets connectés (même à durée de vie infini comme tous les autres appareils ils consomment de l'énergie et sont construit avec des matériaux comme des terres rares etc). Tu peux aussi te poser la question des conditions dans les quels ils ont était construit…
        
        Bref si tu veux te la jouer écolo-bobo, tu en achètera déjà que par véritable nécessité et ce sera déjà pas mal. Si ensuite tu garde de l'équipement connecté à internet sans le maintenir, tu contribuera à des attaques qui ça ne te fais rien, je trouve que c'est dommage (mais t'inquiète pas ce n'est pas répréhensible aujourd'hui). Ça peut aussi devenir le point d'accès sur ton réseau pour ensuite attaquer tes autres équipements.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Dockerfiles
        
        Posté par Renault (site web personnel) le 07 février 2017 à 10:12. Évalué à 2.
        
        Si tu garde du matériel non maintenu et que ton matériel contribue à une attaque d'envergure, tu as une part de responsabilité.
        
        Soyons honnête, maintenir des équipements sur le réseau à jour, que ce soit pour les constructeur comme pour les utilisateurs, cela demande un investissement financier et temporel très important.
        
        Comme je le disais ici, les équipements tu les achètes en one shot, tu ne peux pas garantir avec ce modèle économique des mises à jour régulière durant un temps raisonnable (pas juste une année quoi). On pourrait passer à un modèle de service, du genre tu payes un abonnement pour l'usage du produit, mais le tollé des consommateurs (et même des gens ici hein) vont râler car ce sera exorbitant.
        
        De toute façon, pour limiter les attaques, le système doit être entretenu et géré convenablement. Tous les systèmes. Je suis désolé mais malgré tous les efforts du monde, Mme Michu n'est pas sys admin. Les objets connectés ne changent pas tellement la donne, son ordi, sa tablette ou son téléphone sont déjà des cibles pertinentes et malgré la proximité de ces objets elle ne sait pas les sécuriser correctement. Je ne vois donc pas ce que l'ajout des objets connectés dissimulés changent fondamentalement dans l'équation. Ou alors toute personne incompétente doit abandonner les objets connectés à Internet et utiliser des trucs maintenu par des pro ? Je ne souscris pas à cet élitisme.
        
        Si tu as une fibre écologique, tu devrais de base te poser la question de l'utilité réelle des objets connectés (même à durée de vie infini comme tous les autres appareils ils consomment de l'énergie et sont construit avec des matériaux comme des terres rares etc). Tu peux aussi te poser la question des conditions dans les quels ils ont était construit…
        
        Bref si tu veux te la jouer écolo-bobo, tu en achètera déjà que par véritable nécessité et ce sera déjà pas mal.
        
        Je te trouve très caricatural sur la question. Il y a des objets connectés utiles d'une part, certains dans un but professionnel. Remettre en question l'utilité d'un objet ne me semble pas pertinent. Après on peut avoir la fibre écologique sans aller jusqu'à l'extrême : je suis pour une réduction des déchets, de la consommation énergétique et tout mais pas à cet extrême là. J'ai une voiture et je m'en sers, cela ne m'empêche pas de faire des efforts à côté. J'estime important de se poser la question de ne pas racheter un objet neuf uniquement parce que son support est terminé alors que fonctionnellement il est bon. Sans pour autant renoncer à l'achat original. Cela ne rend pas la démarche incohérente.
        
        Si ensuite tu garde de l'équipement connecté à internet sans le maintenir, tu contribuera à des attaques qui ça ne te fais rien, je trouve que c'est dommage (mais t'inquiète pas ce n'est pas répréhensible aujourd'hui). Ça peut aussi devenir le point d'accès sur ton réseau pour ensuite attaquer tes autres équipements.
        
        Même avec un équipement officiellement maintenu, dans les faits ils sont vulnérables : failles non révélées mais exploitées, matériel / système gérés n'importe comment (les sys admins sont une part négligeable des utilisateurs des appareils reliés à Internet), etc. À t'écouter, on devrait arrêter d'utiliser Internet car forcément des machines vont tomber sous le jougs de personnes malveillantes (on n'a pas attendu les caméras de surveillance non maintenues pour faire des attaques d'envergure, des PCs de particulier c'est déjà bien). Je ne pense pas que de se débarrasser des objets connectés sur le réseau soit la bonne solution. Je pense surtout qu'il faut envisager la sécurité autrement : mettre des mécanismes de protections pour qu'une faille soit la moins impactant possible, mettre des protections d'accès aux objets disponibles sur le réseau et protéger les machines du dit réseau qui pourraient subir une attaque de la part de ceux qui sont vulnérables.
        
        [^] # Re: Dockerfiles
        
        Posté par Albert_ le 07 février 2017 à 11:02. Évalué à 2.
        
        Je pense que c'est meme pire que ca. Qui n'a pas un router fournit par son fournisseur d'acces a un internet? Qui peux me dire qu'il a fait les mises a jour du firmware? Qui peut me dire ou trouver le firmware pour le router que j'ai depuis 2 ans car je vois bien qu'il a pas ete mis a jour de facon automatique par mon fournisseur?
        
        [^] # Re: Dockerfiles
        
        Posté par flan (site web personnel) le 06 février 2017 à 20:57. Évalué à 3.
        
        Tout simplement générer un mot de passe unique et le mettre sur une étiquette collée sur l'objet en question.
        Aucune difficulté technique particulière, ni pour l'utilisateur.
        
        [^] # Re: Dockerfiles
        
        Posté par claudex le 31 janvier 2017 à 19:59. Évalué à 4.
        
        Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.
        
        Tu as aussi le cas où une application non-sécurisée est protégée derrière une authentification sécurisée (comme une auth apache). Du coup, tu as des cas où tu n'as que des gens de confiance qui y accèdent¹. Alors, ce n'est certe pas recommandé, mais ça peut coûter très cher de remplacer un truc si c'est juste pour éviter des failles (pas forcément exploitable sur cette instance en plus).
        
        je dis confiance parce que, par exemple, ils ont déjà les droits root sur la machine, ça ne sert à rien d'exploiter les failles de l'appli. ↩
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Dockerfiles
      
      Posté par pulkomandy (site web personnel, Mastodon) le 31 janvier 2017 à 13:11. Évalué à 4.
      
      Un exemple concret: un projet qui a été développé sur une version de Debian qui est maintenant la oldstable. Il a besoin d'une vieille version de perl et de GNU make, entre autres.
      
      Il est beaucoup plus simple de dire aux nouveaux développeurs d'installer le système Linux de leur choix, puis de déployer la Debian oldstable à partir d'une image (ça pourrait être docket je suppose, mais en l'occurence c'est un truc avec un chroot et des scripts maison). Et ça marche tout seul, pas de maintenance à faire sur l'environnement.
      
      On a clairement pas le temps de s'amuser à recompiler de vieilles versions de Perl, make, du compilateur croisé utilisé, etc. D'ailleurs, par exemple, il est impossible (enfin, compliqué, en faisant plein de patches, peut-être) de compiler un gcc 4.5 ou antérieur pour x86_64 avec un gcc récent. Et oui, on peut avoir besoin de ce genre de choses, par exemple si on maintient un produit avec un CPU 68hc11, qui n'est pas supporté par un gcc actuel et pour lequel on doit pouvoir avoir au mieux un gcc 3.4, de mémoire (les patches n'ont jamais été intégrés dans le gcc officiel).
      
      Donc voilà, l'environnement de dev, il est comme ça, il changera pas, et il fait sa vie. ça coûte rien à maintenir tant que le noyau Linux ne change pas ses appels systèmes et qu'on trouve des CPU x86 compatibles avec les binaires qui sont dedans.
  - [^] # Re: Dockerfiles
    
    Posté par Maclag le 31 janvier 2017 à 13:48. Évalué à 4.
    
    On jette tout et on dit merde au client et au fournisseur ?
    
    "Oh làlà! C'est obsolète tout ce bazar, et pas fiable! Et même pas bien sécurisé!
    Monsieur je pense qu'il vaut mieux tout réécrire. Je vous prépare le devis?"
    - [^] # Re: Dockerfiles
      
      Posté par Renault (site web personnel) le 31 janvier 2017 à 13:57. Évalué à 6.
      
      "Oh làlà! C'est obsolète tout ce bazar, et pas fiable! Et même pas bien sécurisé!
      Monsieur je pense qu'il vaut mieux tout réécrire. Je vous prépare le devis?"
      
      Cela peut être pertinent pour un serveur Web ou un logiciel traditionnel, cela l'est moins quand on parle du support d'une puce précise dont le constructeur de la dite puce a fait un bon gros patch dégueulasse pour le noyau, le chargeur de démarrage et potentiellement d'autres trucs pour des versions précises de ces composants et basta tu te débrouilles avec.
      
      Oui on peut réécrire et adapter l'ensemble, le projet ne prendra pas 1 an mais 5 ans. Demandera des compétences différentes. Ne coûtera pas le même prix non plus et sans garanties de fonctionner mieux (d'autant qu'on n'a pas accès aux documentations ayant servi à concevoir ce gros patch). En plus quand tu auras fini ce travail, tu seras en retard pour les évolutions qui ont eu lieu entre temps. C'est sans fin.
      
      Ou alors tu utilises Docker en 10 minutes et tout le monde est content. Au bout d'un moment il faut être pragmatique et arrêter de croire qu'on peut toujours faire la solution idéale partout. Ça se saurait.
# Ocaml et Opam : une solution ?

Posté par JN le 01 février 2017 à 11:25. Évalué à 3.

Le gestionnaire de paquets de OCaml, Opam contient une extension depext qui permet depuis Opam de vérifier les dépendances système et le cas échéant indiquer quels paquets systèmes supplémentaires sont nécessaires pour pouvoir compiler et installer le paquet opam demandé.

Sous ma Debian, ça marche®, mais je ne sais pas si cette option ne pourrait pas être "généralisée" pour uniformiser et industrialiser le protocole de dépendances entre les systèmes à paquet des distrib et ceux "embarqués" pour les écosystèmes.
# WebJars

Posté par devnewton 🍺 (site web personnel) le 12 février 2017 à 20:42. Évalué à 2.

Si comme tous les gens bons, vous faites du java, sachez que le projet WebJars permets d'utiliser les libs javascript de npm et bower.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.