Bonsoir,
Je viens vous parler de FlatPak, une des nouvelles solutions pour empaqueter pour nos distrib préférées. L'autre jour, j'ai eu la surprise de voir ceci dans mon gestionnaire de logiciels lorsque j'ai voulu installer le logiciel OpenSCAD:
OpenSCAD
755,6Mo à télécharger, 2,4Go d'espace disque requis (Flathub)
Mais WTF??? 2,4Go juste pour ça? Alors je suis allé sur le site officiel, et j'ai téléchargé leur version compilée (Appimage) qui fait 20Mo. Bon, j'ai quand même du installer une dépendance qui manquait.
Aujourd'hui je voulais installer Nextcloud:
NextCloud
768,5Mo à télécharger, 2,4Go d'espace disque requis (Flathub)
Uh??? Pareil, je suis allé voir le site officiel, et ai choisi d'installer le PPA. Un vingtaine de Mo plus tard, c'est réglé.
Je comprend qu'on puisse parfois être frustré des logiciels disponibles dans nos distributions, mais est-ce que Flatpak répond vraiment au problème? Pour moi c'est un problème qu'on me propose ces logiciels dans la logithèque sans exposer clairement qu'ils ne sont pas dans les dépôts officiels (l'info est pas très claire pour tous).
Voici quelques problèmes:
- Prendre plus de 2Go pour un logiciel qui ne nécessite que 20Mo?
- La sandbox qui est mal utilisée et inutile
- Les versions obsolètes contenant des failles de sécurité
- L'intégration au système (installation des plugins, différencier les versions installées)
- Pas de réutilisation des bibliothèques du système (inconvénient, ou avantage…)
Je ne sais pas si c'est beaucoup mieux avec snap ou Appimage (que je trouve quand même vachement plus simple).
Pour quelques infos en plus: http://flatkill.org/
Merci de votre écoute.
# Fedora
Posté par AlexTérieur . Évalué à 1.
J'ai testé Flatpak pour certains logiciels (comme Retroarch) et c'est étrange ça fout un merdier et ce n'est pas clair ! La sandbox est étrange, tu as accès entièrement au /home/ mais le /var/share/ est à part ?!
[^] # Re: Fedora
Posté par Firwen (site web personnel) . Évalué à 10.
En un nom et parce que c'est Vendredi: Lennart Poettering.
Et oui, l'idée originel derrière Flatpak c'est Lennart. Un homme qui, comme tout le monde le sait a toujours fait des softwares simple, fiable et minimaliste comme systemd, avahi ou pulseaudio.
C'est trop gros comme troll ou ça passe quand même pour un Vendredi ?
[^] # Re: Fedora
Posté par Firwen (site web personnel) . Évalué à 2.
-12 Pour ça. Les traditions se perdent, les gens manquent cruellement de second degré pour un Vendredi…
[^] # Re: Fedora
Posté par Gauthier Monserand (site web personnel) . Évalué à -6.
Je ne pense pas qu'on atteigne le deuxième. Quand c'est part définition de ses projets, c'est du 1er degré voir même du zéroième. Je plussoie donc.
[^] # Re: Fedora
Posté par ff9097 . Évalué à 1. Dernière modification le 15 octobre 2018 à 15:19.
Tu peux modifier les permissions de base si elles ne te conviennent pas
# Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 11 octobre 2018 à 20:18.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Appimage
Posté par Cᴬᴾᵀ Samavor . Évalué à 2.
Quelle distribution ?
Pour moi (Gentoo) c'est AppImage qui ne marche pas toujours (genre SubSurface, justement l'AppImage "de vitrine")
De mon point de vue de packager c’est ni fait ni à faire, quand le conseil pour faire une AppImage qui fonctionne sur le maximum de configuration c'est: utiliser la distribution la plus vielle possible pour build, y'a un problème !
Sans compter qu'avec AppImage v2 on commence à se rapprocher de Flatpak ou Snap (formule de build, sandbox…) Comme quoi les autres sont plus en avance qu'en erreur.
# Flatexagération
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 12 octobre 2018 à 07:37.
Pour relativiser ce qui est écrit sur flatkill il faut aller lire ce post.
# Espace disque partagé...
Posté par Adrien BUSTANY (site web personnel) . Évalué à 10.
La première installation va te coûter "cher" en espace disque parce que tu récupères la runtime en dessous… Qui est partagée entre plusieurs logiciels ensuite. Pour voir le vrai coût de OpenSCAD par exemple, installe d'abord la runtime dont il dépend (freedesktop ou GNOME ou autre) et regarde ensuite la taille affichée.
Dire "la sandbox peut être mal utilisée donc elle sert à rien" me semble un peu fallacieux, il faut juste le temps que les logiciels s'y adaptent et se confinent de mieux en mieux. Au moins on leur donne les moyens de le faire ! Si la sandbox était totalement inflexible, aucun logiciel actuel ne marcherait dedans et l'adoption de la technologie serait nulle…
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . Évalué à 10.
La gestion des permissions a été un désastre partout avant, que ça soit les applications Android ou les extensions Firefox. Personne ne lit jamais les permissions, on les accepte sans réfléchir, et les devs doivent viser le maximum d’utilisabilité donc le maximum de permission.
Typiquement les accès réseaux sont généralement actifs parce qu’une appli qui n’utilise pas Internet en 2018, c’est rare, ou encore l’accès à
~est nécessaire pour sauvegarder ses documents dans un endroit accessible (bien que FlatPak vise l’utilisation de couche d’abstraction/tunnel pour régler ça.Ça risque du coup de se chier encore sur les grôles sur ce sujet à la fin…
De plus, le besoin de cloisonnement est une solution à un non problème. Qui ici a déjà eu une application malveillante sous GNU ? Quel est du coup l’utilité du cloisonnement ?
[^] # Re: Espace disque partagé...
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
Si tu n'utilises que des logiciels libres issus de ta distribution, effectivement, ça n'a pas grand intérêt. Maintenant, on voit de plus en plus d'applications propriétaires arriver sous Linux. Soit des applications natives, soit des machins multi-plateformes à base d'Electron (pour ne citer que la techno qui a le vent en poupe).
Et pour ce genre de cas, plus ça sera isolé, plus je serais content.
[^] # Re: Espace disque partagé...
Posté par Renault (site web personnel) . Évalué à 9. Dernière modification le 12 octobre 2018 à 10:15.
Puis ça a un intérêt. J'adore Fedora, je l'utilise au boulot pour programmer avec GNOME Builder.
Si je veux la dernière version de Builder disponible, je dois changer de version de Fedora pour l'obtenir. C'est dommage car ce n'est pas le moment pour une telle opération mais je veux bien ces fonctionnalités qui m'apporteraient un gros confort.
Hop Flatpak, et si ça foire, j'ai toujours la version stable de ma distribution disponible. Et je peux aussi aider les développeurs des projets upstream an testant les dernières versions qu'ils proposent (voire les nightlies) si je le souhaite. Ce qui était plus pénible si on se base uniquement sur ce que propose la distro.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . Évalué à 6. Dernière modification le 12 octobre 2018 à 11:20.
À une époque où les gens font du
wget http://www.whatever/bidule_inconnu.sh | sudo bash, se protéger contre des menaces potentielles ne me semble pas superflu. En plus, le fait que tu n'ais jamais vu d'application malveillante ne veut pas dire qu'elles n'existent pas, juste que tu n'en as pas vu. Un rootkit qui s'installe par exemple, ça le crie pas sur les toits.Le besoin de cloisonnement vient du fait que le modèle des distributions est peu flexible, et que des softs produits pour Linux et Windows sont en général plus à jour sous Windows ! Pour Linux, il faut attendre la prochaine version de ta distrib, croiser les doigts et espérer un backport, etc. Ensuite à partir du moment où tu veux exécuter du code tel que fourni par le développeur de l'application et que tu fais sauter l'intermédiaire de sécurité qu'est la distrib, tu te retrouves exposé au bon vouloir de chaque développeur d'appli de mettre à jour les bibliothèques qu'il utilise à chaque faille de sécurité détectée. S'il ne le fait pas, tu es exposé (comme le montre bien http://flatkill.org ) , la seule solution solution est donc de cloisonner, et de bien cloisonner (i.e. réduire les permissions au minimum).
[^] # Re: Espace disque partagé...
Posté par patrick_g (site web personnel) . Évalué à 8. Dernière modification le 12 octobre 2018 à 11:30.
Arch Linux.
[^] # Re: Espace disque partagé...
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
Très bonne distribution, mais clairement pas à destination du premier venu. Et même si Manjaro simplifie un peu les choses, je ne la conseillerai pas à un débutant.
Puis bon, dans les dépôts officiels de Arch, il n'y a finalement pas grand chose. La plupart du temps, il faut taper dans AUR. Ce qui implique de redoubler d'attention et d'accepter de se coltiner tous les paquets de développements nécessaires, et la compilation qui s’ensuit.
Donc bon, même sous Arch, Flatpak n'est peut être finalement pas si mal :p
[^] # Re: Espace disque partagé...
Posté par ff9097 . Évalué à -2.
Le truc qui s'installe en ligne de commande ?
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . Évalué à 4.
Non. Tu te prends par la main, tu codes ton appli pour utiliser les libs couramment utilisées par les plus grosses distrib’ du marché et tu livres un soft potable.
Les gens se feront un plaisir de packager un logiciel propre.
Ça prend 40 ans à packager pour beaucoup d’applis parce que les devs font juste n’importe quoi et ne pensent pas à leur release avant.
Oui, un soft qui embarque la moitié du monde, les packageurs ne vont pas se presser au portillon…
[^] # Re: Espace disque partagé...
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Le propos concerne les utilisateurs qui veulent (même sans besoin ;-) de la dernière version d'un logiciel.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . Évalué à 10. Dernière modification le 12 octobre 2018 à 12:29.
Tu te berces d'illusions là.
Les "libs couramment utilisées par les plus grosses distrib’ du marché" ça veut rien dire. Toutes les distribs n'ont pas les mêmes versions de bibliothèques, et faire des cas spécifiques par combinaison de version sans les tester ça, ça ne marche pas.
Exemple en tête: GTK+ qui a changé la gestion du CSS en cours de route sur GTK+ 3. Tu fais comment quand tu as fait le portage de ton appli pour la nouvelle version, mais que toutes les distribs ne l'ont pas ? En général tu te retrouveras avec les distribs qui ont l'ancienne version de dépendance qui diffuseront l'ancienne version de l'appli, et les les distribs qui ont la version récente qui diffuseront la nouvelle version de l'appli.
Tu noteras que l'appli est propre, mais c'est l'écosystème qui fait que la distrib contrôle les dépendances, et pas le développeur de l'appli. Flatpak lui permet de livrer exactement la version qui est connue pour fonctionner avec telle autre version de dépendance, et ça marchera sur toutes les distribs gérant flatpak. Le développeur reprend le contrôle.
Ensuite s'il sort une nouvelle version majeure, bin désolé mais si tu n'as pas une distrib rolling release, la réalité du terrain c'est que ton soft ne sera que dans la version N+1 de la distrib parce que faire un backport ce serait aussi backporter les dépendances dans leur version plus récentes. Si ces dépendances sont partagées avec d'autres applis et non parallèlement installables, la validation devient un cauchemar, donc personne ne fait le backport.
[^] # Re: Espace disque partagé...
Posté par Okki (site web personnel, Mastodon) . Évalué à 7.
Hormis Debian qui, il faut le reconnaître, possède un très grand nombre de paquets, toutes les autres distributions zappent des milliers d'applications, qui sont pourtant sans doute très bien codées, avec les bonnes bibliothèques, un système de build propre et efficace et tout ce que tu veux.
Tout simplement parce que la plupart des distributions n'ont clairement pas la main d'oeuvre nécessaire pour tout packager.
Et aussi propre soit-il, t'as également le problème de la popularité de l'application. Si elle est suffisamment populaire, il y a de fortes chances pour qu'un packageur soit intéressé pour s'en occuper. Mais à côté de ça, t'as tout plein d'applications qui n'intéressent pas forcément grand monde (et on ne parlera pas des histoires de brevets logiciels, qui font que certaines distributions refusent de packager des applications pourtant populaires, mais qui poseraient certains risques juridiques).
Alors, tu lui réponds quoi à l'utilisateur qui en a besoin, mais dont la distribution n'a pas jugé que ça en valait la peine ? À mon avis, il sera sans doute bien content de pouvoir installer facilement un Flatpak…
[^] # Re: Espace disque partagé...
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
C'est quoi un logiciel propre? En C89 avec autotools?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 9.
Pour avoir fait suffisamment de packaging, tous les packagers s'accordent sur les points suivant:
Un logiciel "propre" a packagé c'est:
un logiciel qui n'embarque pas ses dépendances
un logiciel qui ne dépend pas sur du code propriétaire ou à license problématique.
un logiciel qui a un tool standard pour builder ( pas un script louche qui tombe en marche le 31 du mois sur la machine du voisin uniquement)
un logiciel qui compile/install en environnement isolé sans télécharger internet 2 fois.
Pour prendre un contre exemple parfait, je recommence de regarder ce talk de la fosdem qui décrit parfaitement un software désigné avec le cul (veuillez pardonner l'expression) et quasi impossible a packagé
https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/
[^] # Re: Espace disque partagé...
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Ca me semble très facile de faire un logiciel difficile à packager :-)
Par contre si on utilise un langage avec un outil de construction / gestion des dépendances standard (maven, npm, pip, cargo…), pourquoi l'empaquetage n'est pas automagique?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 15 octobre 2018 à 13:54.
Pour plusieurs raisons :
Parce que tous ces outils vivent sur leur petite île langage spécifique et n'ont aucune compatibilité entre eux. En pratique, tu as trés rapidement un cas où tu veux utiliser une lib Rust associé à une lib C++ dans un module python
Tous ces outils sont orienté "devs" et généralement très peu approprié pour un utilisateur final
Tous ces outils téléchargent le monde en considérant que: Internet est toujours disponible, Installer spécifier les dépendences à la main est inutile. Ces deux préceptes sont faux dans beaucoup environnement ( environnent haute sécurité proxifié, intrégration dans un écosystème plus grand qui a déjà des dépendances et où tu veux eviter les dépendances en Diamant )
[^] # Re: Espace disque partagé...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 15 octobre 2018 à 15:26.
Donc il n'y a pas de solution pour faire un logiciel facilement empaquetable avec des outils de développement moderne ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Espace disque partagé...
Posté par diorcety . Évalué à 5.
Clé en main? Non… Ça fait plus de 3 ans que je tourne autour de cette problématique (je suis passé par plusieurs solutions: cross compilation, openembedded, oe-lite, …) et j'arrive à une solution qui marche bien dans mon cas mais qui demande quand même quelques patchs sur les dépendances pour que ça marche.
Mes contraintes sont: Linux (vieilles distributions < 4 ans) et Windows(avec les outils natifs, donc pas de MINGW, uniquement MSVC), sur une suite logiciel composée de C++ et de python le tout tirant une 30 aine de dépendances(dont notamment libressl, cryptography, paramiko, numpy, boost, pythran, qt et pyside2) et qui doit fonctionner sur tout les CPU 64 bits (donc pas d'autodetection du CPU à la compilation)(ce qui peut est très tricky sous Windows et pour certaine dépendances comme Qt)
Je suis arrivé à faire quelque chose de pas trop mal avec cmake, en utilisant les ExternalProject, et des dépendances avec des systèmes builds fonctionnement aussi bien sous Linux que Windows (pas de autotools donc) et des macros plutôt génériques.
Le soucis c'est surtout la libc. La solution sous linux c'est d'utiliser docker(ou une VM) avec une vieille Centos 5, avec le strict minimum, et tout ce qui est custom (LLVM/Clang récent par exemple) dans les préfixes non standard (pour éviter pendant la compilation qu'une dépendance la trouve et l'utilise). L'image docker manylinux ou dockcross est pas mal pour ça. Sous Windows il suffit de rien n'installer en dépendances(du runtime) ça s'arrête là.
Bien sur il y a quelques patches pour les bugs sur les projets ne gérant pas les prefix custom et autres. Le pire je pense sont les modules python avec une partie native, la détection des dépendances sur Windows étant catastrophique, souvent c'est du bricolage. La palme revenant à lxml dans mon cas, qui va télécharger des binaires pré-compilés sortant de je ne sais pas trop où.
Au final je fais mon superbuild en décrivant simplement mes dépendances et je fais un packaging custom sur la fin: tar.gz pour linux, innosetup pour Windows(la je tire uniquement l'installation de python et du redistribuable MSVC associé), et mes binaires ne sont pas énorme (j'embarque juste tout sauf la libc)
Exemple (incomplet):
Par contre ça résout pas le problème que tu dois tout surveiller pour les patches de sécurité… Mais au moins tu contrôles de A à Z les binaires produits.
[^] # Re: Espace disque partagé...
Posté par liberforce (site web personnel) . Évalué à 2.
Tu as jeté un coup d'oeil à conan ?
[^] # Re: Espace disque partagé...
Posté par barmic . Évalué à 3.
Non ça n'arrive pas tant que ça. De toute ma vie ça n'est arrivé qu'une fois en fait (je sais que tu va pouvoir citer pleins de cas, ça n'en fait pas la règle).
C'est normal, un utilisateur ne devrait pas avoir besoin de s'en servir. Et jouer au power user moijecompilemesprog ne rend pas cette remarque fausse. Tu veux jouer avec les outils des développeurs, très bien.
Pour ceux que je connais, ils n'est pas nécessaire d'avoir internet, c'est juste l'option par défaut parce qu'elle convient au plus grand nombre. Et oui dans ton environ haute sécurité, on installe pas n'importe quoi ce qui par définition montre qu'il y a peu de programmes qui sont construit pour.
Sans cloisonnement ? Soit. Mais tu paie une complexité démesurée. La complexité des systèmes n'augmente pas linéairement avec la taille (je crois avoir lu qu'elle est plutôt quadratique) donc empiler les logiciels et leurs dépendances sans cloisonnement et se dire que ça doit marcher c'est à minima assez joueur…
Dans des contextes très sécurisés, on va être bien plus intéressé par la reproductibilité du build donc soit :
Les 2 approches existent et son utilisés.
C'est la question des dev et des ops. Si les ops reprochent aux dev de ne pas utiliser les gestionnaires de dépendances systèmes, il faut bien comprendre que l'inverse est vrai aussi.
Se plaindre c'est bien marrant (quoi que), mais personne n'arrive à spécifier un truc qui soit intéressant pour les 2 types d'utilisation
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 4.
Ben tu as bien de la chance car ça m'arrive toute les semaines. Les gens qui font du machine learning où qui utilise intensivement python ( scientifiques ) ont une plétoire de dépendances en C, Fortran, C++, Rust et ma grand mère compilé en native derrière leur script. Et pip absoluement infame pour compiler du code natif.
Doc fait qu'en pratique tu auras besoin d'un second "package manager" / "installer" / "deployment system" X uniquement pour tes utilisateurs car celui que tu auras en CI sera différent. Ce qui au passage est potentiellement aussi une source de bug.
Toi tu as pas encore essayer Bazel :D
Et ignorer cette complexité et surtout les dépendances en Diamant c'est la garantie suprème de se foutre une balle dans le pied. De manière bien douloureuse, souvent aprés des semaines de débugging.
Je ne reprochent ni à l'un ni à l'autre: ils ont tous les deux leur raison. Le problème de la situation actuel c'est qu'il n'y a rien pour satisfaire les deux, alors que techniquement il n'y a aucun barrière à ce que ça soit le cas.
Nix ? Spack ? Bazel (que je considérerai comme une failure ) ?
[^] # Re: Espace disque partagé...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 16 octobre 2018 à 10:58.
Le problème vient des distributions: les outils de devs ont été fait pour embarquer toutes les dépendances faute de solution côté distrib.
En attendant de créer Le système dépendance magique et universel, pourquoi ne pas simplement mettre les libs des dépôts maven/npm/cargo dans /usr/lib/{maven,npm,cargo} et faire des plugins pour permettre de générer facilement des rpm/deb/… à partir de ces outils ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Espace disque partagé...
Posté par BAud (site web personnel) . Évalué à 1. Dernière modification le 16 octobre 2018 à 11:13.
c'est le choix entre le PGCD et le PPCM
la sécu et l'exploit' sont côté PGCD pour limiter leur boulot (il n'y a que 24h par jour), si côté dév' il faut promouvoir le PPCM, bin que les dévs' viennent aider la prod' et on en reparle :-)
La résorption des dépendances à de multiples versions aiderait déjà les deux côtés à se réconcilier un peu :-)
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 1.
Du calcul scientifique avec Rust? Tu as un lien que je rigole. Franchement c'est rigolo de voir certains academiques se precipiter sur la derniere nouveautes. Je dois me tromper, ne connaissant le language que de nom, mais je soupconne malgre tout que les libs de calculs scientifiques (je ne parle meme pas de libs optimise) pour ce language ne doivent pas etre pletore.
[^] # Re: Espace disque partagé...
Posté par David Delassus (site web personnel) . Évalué à 3. Dernière modification le 16 octobre 2018 à 16:24.
Quand la plupart des libs scientifique Python sont développées (partiellement ou entièrement) en C/C++ (numpy, tensorflow, …), il n'est pas si étonnant d'en voir apparaître en Rust.
Il faut bien se rendre compte que Python ne fait souvent que office de glue entre les différentes briques de ta pipeline de traitement de données.
https://link-society.com - https://kubirds.com
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 3.
Merci mais bon un manque dans tes languages c'est le fortran. Oui les calculs matriciel fait avec blas/atlas c'est du fortran et bon les matrices c'est "legerement" important en calculs numerique…
En ce qui concerne le C/C++ c'est deja bien penible de faire du calcul numerique. Peut etre que Rust est un peu mieux mais vu que personne ne donne de lien pour j'ai comme l'impression que ce n'est pas le cas.
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 5.
c'est (souvent) le module du Phd student qui a fini en prod et que personne veut recoder :D
Tu peux remplacer Rust par le language X fashion du moment.
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 3.
On est donc bien d'accord sur le sujet :)
[^] # Re: Espace disque partagé...
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 16 octobre 2018 à 18:04.
On est bien d'accord que là tu décris pas du code scientifique Rust mais l'intégralité des bibliothèques scientifiques dans tous les langages ?
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 4.
Mais bien sur… Tous les codes scientifiques sont pourris…
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 7. Dernière modification le 16 octobre 2018 à 21:29.
J'ai travaillé suffisamment avec des scientifiques pour avoir une opinion assez tranché sur la question:
Non, bien évidemment tous les code scientifiques ne sont pas pourris.
Mais à mon expérience ( qui n'engage que moi ) une grande parti du code issue du monde de la recherche est souvent bâclé, sans aucun respect des principes de base en ingénieure logiciel et souvent in-maintenable.
Ce n'est pas l'absolue, mais c'est souvent le cas. Et il y a des raisons à ça, des raisons humaines parfaitement compréhensibles. Les chercheurs sont payés, respectés et récompensés pour leur résultats, leurs publications et leur données.
Leurs programmes ne sont que des outils secondaires nécessaires à achever ça, rien d'autre. La pérennité, ré-usabilité, modularité, maintenabilité de leur code, ils s'en moquent… ils ne sont pas et ne seront jamais évaluer sur ça…. En tout cas pas dans 90% des labos de recherche, même dans l'informatique.
Et je peux parfaitement les comprendre, ils sont payé pour faire de la recherche, pas de ingénierie, ils font de la recherche. Faire de ingénierie correcte, ça prend du temps et de l'argent… Et ils ont souvent ni l'un, ni l'autre.
Et tant que les grand journaux de publications ne forceront pas la publication des outils sources, testés, et maintenu correctement pour des raisons de reproductibilité, ça restera comme ça.
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 2.
La aussi nous sommes d'accord mais moi je repondais a ca:
[^] # Re: Espace disque partagé...
Posté par Sufflope (site web personnel) . Évalué à 2.
intégralité était une hyperbole trollesque, mais bon en attendant, que ce soit en labo lors de mes études, ou dans le monde du travail en cotoyant des "chercheurs", j'ai encore jamais vu du code propre de leur part d'un point de vue ingénierie (cf. autre commentaire qui explique que c'est pas leur taff mais qu'on le leur demande quand même…). Bon il doit bien y avoir quelques exceptions, mais vla la quantité de code en prod qui repose sur le bon vouloir de chacun de ne pas envoyer une liste vide…
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 3. Dernière modification le 19 octobre 2018 à 08:56.
"Legere" hyperbole.
Que les logiciels developpes de facon interne par le doctorant/postdocs/chercheur ok ca je veux bien le croire (je le sais) mais il y a malgre tout un paquet de logiciel scientifique de tres haute qualite:
et tout ca pars de lab universitaire et j'en connais un paquet d'autre mais oui ce n'est pas la majorite loin de la.
Mais pendant ce temps la dans le prive on a aussi droit a des Ansys… et si tu consideres sale les codes universitaire, celui la est vendu, tres cher, et utilise dans l'industrie et c'est une usine a gaz fait de bric et de broc… et je ne parlerai pas d'un certain logiciel proprio que beaucoup de personne se servent pour faire des stats alors que les mathematiciens ont montre que certaines des formules sont … fausses.
[^] # Re: Espace disque partagé...
Posté par Firwen (site web personnel) . Évalué à 2. Dernière modification le 19 octobre 2018 à 10:04.
Tu peux ajouter à la liste des projets scientifiques avec une bonne qualité de code :
Je n'ai pas dit que le monde académique ne produisait pas des logiciels de qualités, mais souvent que c'est exception, pas la norme. Pour des raisons de financement et d'organisations malheureusement.
Heureusement, il y a aussi maintenant de plus en plus de labos qui ont compris l'intêret économique,à garder leur pile logiciel "maintenanble" qui emploie maintenant des équipes d'ingénieures pour s'occuper de ça. Mais encore une fois, c'est souvent l'exception, pas la norme.
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 2. Dernière modification le 19 octobre 2018 à 11:59.
J'ai donne des exemples et je redis nous sommes d'accord. Ce n'est pas toi qui a dit que l'integralite des codes scientifiques etait pourri :)
[^] # Re: Espace disque partagé...
Posté par Sufflope (site web personnel) . Évalué à 4. Dernière modification le 16 octobre 2018 à 18:03.
Donc ça va pas t'empêcher de donner un avis péremptoire sur un sujet dont tu ne connais rien.
Alors pour du calcul numérique ou calcul matriciel spécifiquement là tout de suite j'en sais rien, mais avec les Data Scientist chez nous on regarde pour faire notre prochain projet lié à du traitement d'image, en Rust (basé sur des biblios existantes, par exemple pHash). Parce que le python lent comme le cul et qui pète des exceptions, pour leurs PoC c'est très bien, mais en prod', merci bien, et le C, lol bon soyons sérieux on est pas archéologue ni jongleur d’assiettes. Rust semble d'après les premiers tests le compromis parfait et moderne entre rapidité de calcul natif et propreté théorique du langage. Alors après il y a moins de bibliothèques dans un langage qui a percé il y a deux ans que dans un qui en a trente, no shit Sherlock. Mais ça vient.
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 5.
Je demande des exemples. Peut etre peux tu m'en donner?
[^] # Re: Espace disque partagé...
Posté par Sufflope (site web personnel) . Évalué à 2.
Oui c'est vrai que j'ai pas décoré ma référence du lien adéquat, mais je pense qu'à l'ère de l'information tu sais chercher phash rust dans ton outil de recherche préféré.
Alors avant de venir dire c'est juste un algo de quelques dizaines de lignes, oui, mais bon c'est du state of the art de traitement d'image et c'est pas "une biblio pour faire des API JSON" non plus, et comme j'ai dit oui tu en trouveras moins qu'en C… en même temps combien de biblios à peine compatibles C89 quand on est en 2018 ?
[^] # Re: Espace disque partagé...
Posté par nokomprendo (site web personnel) . Évalué à 3. Dernière modification le 16 octobre 2018 à 20:51.
Je ne reconnais pas complètement mon expérience personnelle dans ce que vous décrivez du calcul scientifique. Pour moi la popularité de Python tient surtout à sa simplicité et à son expressivité. Beaucoup de scientifiques ne sont pas des informaticiens et ont plutôt intérêt à utiliser Python/R/Matlab et à réserver C/C++/Fortran aux parties très calculatoires.
Concernant la popularité de Rust dans le calcul scientifique, ça m'étonne beaucoup. Rust a peut-être du potentiel pour implémenter les libs bas-niveau (BLAS & co) mais cet écosystème est déjà bien fourni, optimisé et mature. Quant à remplacer Python, je n'y crois pas une seule seconde, pour les raisons de simplicité/expressivité évoquées précédemment.
Par contre, le langage Julia, qui est à la fois performant et expressif, commence à devenir vraiment populaire dans le milieu.
[^] # Re: Espace disque partagé...
Posté par Albert_ . Évalué à 2.
Comme je dis souvent:
"N'essayez pas de recoder la roue. Il y a des tres tres grandes chances que votre code numerique puisse benificier d'une libs optimise par quelqu'un d'autre."
Donc oui python est un excellent language pour faire du calcul numerique car bien souvent cela ne veut pas dire "nouvel algo de multiplication de matrices" mais utilisation de la multiplication de matrices pour resoudre un probleme non resolvables autrement que par une approximation numerique.
[^] # Re: Espace disque partagé...
Posté par barmic . Évalué à 3.
C'est intéressant. Il y a quoi pour faire de la distribution en rust ? Il me semble que dans ce milieu l'écosystème est au moins aussi important que le langage lui même. J'entends partout que la JVM est bloated et que tel ou tel langage fais 10, 100 ou 1000 fois mieux, alors qu'on voit du Spark et du Kafka. Cassandra a peut être un concurrent mais ScyllaDB n'est pas encore très populaire (voir sur google trend).
Si c'est plus pour tourner sur supercalculateurs, l'écosystème est encore différent. Je vois un binding d'MPI qui a l'air prométeur mais peut être un peu jeune : rsmpi. Il y a aussi timely dataflow qui me semble un peu plus mature. Je connais mal se monde. C'est tout ce dont il y a besoin ? J'imagine qu'il faut une bibliothèque de calcul et une pour gérer la mémoire efficacement (consommer toute la mémoire vive et pouvoir la persister pour pouvoir reprendre les calculs en cas de problème).
[^] # Re: Espace disque partagé...
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 18 octobre 2018 à 21:40.
T'as quand même conscience que les bindings pyspark sont juste du sucre syntaxique pour pythonistes (et je comprends les mecs de spark, ils bossent pour ceux qui leur donnent à manger) et qu'au coeur Spark ne sera jamais en python mais a besoin d'outils tels que la JVM pour ne serait-ce qu'exister ?
N.B. ça ne répond pas à la question sur Rust hein ! Mais juste viens pas parler de Python pour de la (vraie) distribution…
[^] # Re: Espace disque partagé...
Posté par Dr BG (site web personnel) . Évalué à 2.
Il parle de l'écosystème de Java, hein…
[^] # Re: Espace disque partagé...
Posté par Psychofox (Mastodon) . Évalué à 4.
Oui et non.
Il y'a des trucs comme copr.fedora.org et build.opensuse.org qui fournissent des services de building et hébergement de package assez intéressant et je connais moins mais les fameux ppa ubuntu permettent je crois de fournir aisémment des packages alternatifs. Pour des gros trucs très envahissant comme gnome, kde, c'est peut-être moins pratique que du flatpak mais pour des plus petites applications ou outils je trouve que c'est une meilleure alternative même si l'utilisateur doit quand même se poser la question de qui gère ces dépôts, quel degré de confiance on peut lui donner et jeter un oeil de temps en temps pour voir si ces dépôts tiers et non officiels sont toujours mis à jour.
[^] # Re: Espace disque partagé...
Posté par Okki (site web personnel, Mastodon) . Évalué à 6.
Ouais, enfin là, t'as perdu le grand public depuis longtemps…
[^] # Re: Espace disque partagé...
Posté par Psychofox (Mastodon) . Évalué à 4.
Tu l'as aussi perdu avec flatpak ou appimage, ça ne change rien.
[^] # Re: Espace disque partagé...
Posté par ff9097 . Évalué à 1.
Bah non le flatpak s'installe et se met à jour en un clic (voir automatiquement si on veut)
[^] # Re: Espace disque partagé...
Posté par claudex . Évalué à 8.
Tout application qui permet de charger des fichiers ou qui reçoit du trafic via le réseau est malveillante (ce qui fait qu'il ne reste pas grand chose à part une calculatrice basique). Ce n'est pas parce que le développeur fait du code libre qu'il n'y pas de faille dans le logiciel. Prend un logiciel comme VLC, tu as tout intérêt à ce qu'il n'ait aucun accès aux fichier à part celui que tu veux lire.
« 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: Espace disque partagé...
Posté par gUI (Mastodon) . Évalué à 8.
Tout le monde, toi y compris : Firefox, OpenSSH, libSSL, le kernel Linux etc.
C'est le propre d'une faille de sécurité : transformer un logiciel bienveillant en un logiciel malveillant.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . Évalué à 3.
Et donc tu arrêtes d’embarquer en dur tes libs ou de te transformer en leur mainteneur.
Pour justement te mettre à jour le plus vite possible quelque soit l’état d’utilisation des logiciels à la fin.
Et tu vires immédiatement tout ce qui ne supporte pas la nouvelle versions patchée.
[^] # Re: Espace disque partagé...
Posté par gUI (Mastodon) . Évalué à 3.
En effet, dur de justifier de faire exploser le nb de libs potentiellement hackables sur son système.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Espace disque partagé...
Posté par HL . Évalué à 9.
Ça revient presque à une deuxième distrib' installée par dessus du coup ? Est-ce qu'on ne perd pas un peu du cloisonnement initial aussi ?
[^] # Re: Espace disque partagé...
Posté par Adrien BUSTANY (site web personnel) . Évalué à 4. Dernière modification le 12 octobre 2018 à 00:15.
Oui, c'est le concept d'avoir une couche standard, parce que personne sait quelle version de gtk/openssl/… ta distro a. Ça réduit pas le cloisonnement dans le sens où la runtime est montée en lecture seule, elle peut donc être partagée en toute sécurité.
[^] # Re: Espace disque partagé...
Posté par saltimbanque (site web personnel) . Évalué à -5. Dernière modification le 12 octobre 2018 à 11:15.
On est en deux mille dix huit ; 2go c'est que dalle, parce que, comme indiqué ci dessus c'est une seule fois : les applications suivantes utiliseront le même runtime. Au pire si un deuxième runtime est installé les fichiers identiques ne seront pas dupliqués sur le disque. Je préfère perdre 2go que des heures sur des problèmes idiots de dépendance. Mais votre temps est peut être moins précieux que le mien!
edit : ceci vise évidemment uniquement le cas du "bureau". il va de soi que le modèle ne saurait s'appliquer à d'autres usages. D'ailleurs flatpak ne vise pour l'instant que les applications graphiques.
[^] # Re: Espace disque partagé...
Posté par Aeris (site web personnel) . Évalué à 9.
Et c’est exactement avec ce type d’argumentation qu’on en est là aujourd’hui…
[^] # Re: Espace disque partagé...
Posté par saltimbanque (site web personnel) . Évalué à -2.
es tu au courant que 2go valaient, en 2015, cinq centimes?
Il n'y a pas de lenteur incriminée que je sache. Donc pour en revenir à la taille, flatpak n'est pas pensé pour tourner sur du Android ou sur de l'embarqué ; non.
https://www.journaldugeek.com/2015/11/13/en-1956-1-go-coutait-26-millions-deuros-combien-vaut-il-aujourdhui/
[^] # Re: Espace disque partagé...
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
5c du Go à l'achat. Faut aussi compter les sauvegardes, les transferts réseau, les besoins en RAM, la vitesse des bus internes, l'analyse antivirale ou sécurité de ces données, l'indexation de ces données, etc. pour manipuler ce giga de données. Bref il y a des coûts cachés à ne pas négliger si on ne veut pas une simple fuite en avant. (La barrière du giga c'était aussi avoir besoin du 64 bits, celle des 32 Gigas le besoin de revoir la JVM et son GC, etc.)
Raisonner juste sur le court terme (ici l'achat) est une approche très économiste/capitaliste de rendement. Tout prendre en compte serait une approche plus écologique ou sociétale. Et pour caricaturer, ça ressemble à la différence entre le développeur "il n'y a qu'à mettre plus de ressources" et l'adminsys "euh c'est moi qui devrait gérer ces ressources supplémentaires".
[^] # Re: Espace disque partagé...
Posté par gnumdk (site web personnel) . Évalué à 3.
Oui, enfin du coup, si on compte les millions de machines qui buildent un stack complet parce que le paquet et/ou la version n'est pas disponible dans la distrib utilisée, je pense que Flatpak est largement gagnant.
# Dépendances
Posté par Aeris (site web personnel) . Évalué à 10.
Pour moi, c’est ça le vrai problème de FlatPac, AppImage, Docker, Go et plus ou moins tout ce qui embarque en dur la liste de ses dépendances.
Ça transforme de facto le mainteneur de l’application en le mainteneur de l’ensemble de ses dépendances.
À la moindre modification d’une dépendance, pour cause de fix de sécu par exemple, il faut explicitement reconstruire toute la chaîne jusqu’à l’image finale (les overlay chez Docker, les runtime chez FlatPak, etc).
Ça donne une longue traîne de trucs pas patchés parce que quelqu’un s’est endormi quelque part sur la chaîne.
Je serais par exemple curieux de connaître le nombre d’images Docker basées sur Alpine qui sont maintenant fixées depuis la grosse CVE de fin septembre.
Ça incite les gens à ne pas mettre leurs applications à jour et à utiliser des trucs complètement dépréciés au motif qu’avec FlatPak, ça tourne.
Bref, c’est un joyeux bordel au niveau sécurité.
[^] # Re: Dépendances
Posté par gnumdk (site web personnel) . Évalué à 7.
C'est le seul reproche que je fais. La team flathub, globalement, ce ne sont pas des devs mais je suis pas sur qu'ils font le boulot d'une distro.
Mais bon, genre pour des applis proprio ou des gros bousins merdiques à installer, c'est quand même top. Je l'utilise au taf sur le postes Ubuntu des étudiants et j'ai pu installer des 10zaines d'applications (non dispo en .deb) sans galérer.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 0. Dernière modification le 11 octobre 2018 à 23:22.
Pour installer des trucs vraiment craignos ou qui risquent de t’exploser ton système, tu passes par de la virtualisation ou des chroot quoi… Pas besoin de s’emmerder avec des trucs à la flatpak…
Et si ça ne s’installe pas sur une distrib standard, c’est peut-être que ça ne devrait pas être installé ni utilisé tout court :D
[^] # Re: Dépendances
Posté par Adrien BUSTANY (site web personnel) . Évalué à 5.
Bah un chroot, il faudra aussi le mettre à jour, c'est pas exactement trivial à mettre en place, et c'est de toute façon plus ou moins exactement ce que flatpak fait pour toi :-) c'est comme dire que Docker sert à rien parce que tu peux utiliser lxc/nsenter/etc. à la main. Faire une vm certes c'est un coup de virt-builder mais niveau intégration et utilisation optimale des ressources on a vu mieux.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 2. Dernière modification le 12 octobre 2018 à 10:11.
Oui et non. Effectivement Docker ne sert à rien (en tout cas en prod) parce que tu peux utiliser LXC & cie, et parce qu’il apporte plus de problèmes qu’il n’en résout (problème du monitoring, mise-à-jour, maîtrise de l’environnement, etc).
Tout comme FlatPak réinvente la roue en répondant à un non-problème (les applications foireuses quasi inexistantes sous GNU ou dont tu devrais te passer plutôt que de chercher à les faire tourner) via un syndrome du « pas inventé ici » (si tu veux du cloisonnement, AppArmor ou NSJail existent déjà et sont bien moins bloatware que FlatPak) tout en apportant d’autres problèmes encore plus toxiques (duplication des bibliothèques, longue traîne des mises-à-jour, incitation à continuer à ne pas migrer les applications vers les nouvelles versions des dépendances vu qu’on aura FlatPak pour les faire tourner, incitation à continuer à faire de la merde dans les applis en se disant qu’on aura de toute façon FlatPak pour les cloisoner).
[^] # Re: Dépendances
Posté par barmic . Évalué à 10.
Il est mignon…
Alors déjà affirmer que docker ne sert à rien parce que tu peux utiliser LXC c'est euh… Ce sont 2 softs qui font à peu prêt la même chose. Les 2 se basent sur les namespaces et chroot pour produire des environnements maîtrisés.
Docker est massivement utilisé en production et ce n'est pas pour rien:
Tu peux faire sans, ce n'est pas une nécessité loin de là, mais affirmer que ça ne sert à rien en prod c'est faux.
les 2 sont une démonstration du fait qu'il est tout à fait possible de monitorer du docker entre autre ↩
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 2.
Je n’ai pas dis que ça ne servait à rien en prod, j’ai juste dit que ça apportait tout plein de problème (en particulier de sécurité, cf le problème de la longue traîne des fixes de sécu qui doivent remonter tous les layers) par rapport à d’autres solutions équivalentes si tu veux de la reproductibilité.
Le rapport avantages/problèmes est en défaveur de Docker (la sécurité pesant devant peser un ÉNORME poids quand on fait un choix technique).
Cf ça par exemple.
Ou ça.
Ou encore ça.
Oui, il est possible de monitorer. Avec des blagues dans le système en terme de sécurité.
Cf ça.
[^] # Re: Dépendances
Posté par barmic . Évalué à 6. Dernière modification le 12 octobre 2018 à 11:47.
Tu as écris :
Je l'invente pas.
(t'es relou avec tes liens pas nommés…) mais c'est cool tu as des arguments :)
Pour « Au secours, ma prod est sous Docker (Francois Teychene) », il mélange sidecar et docker in docker. Un sidecar n'a pas besoin d'accéder à la socket docker, la définition d'un sidecar c'est de partager des namespaces. Par contre effectivement traeffic peut utiliser la socket docker (mais tu peux très bien t'en servir sans). Ensuite tu peux ne pas donner accès à la socket unix, mais passer par du http (les 2 sont du rest) et donc ajouter une couche de sécurité avec un reverse proxy.
Pour « Containers, VMs… Comment ces technologies fonctionnent et comment les différencier? (Quentin Adam) » (j'aime beaucoup ce gars) et oui il faut choisir (ou construire) intelligemment ses images de base. Pour le fait qu'il utilise une vm par client, ça ne me choque pas. Les problèmes de clevercloud ne sont pas les même que celui du développeur moyen. Rien que les manque en terme de limitation de consommations de ressources font que tu ne peux pas te servir uniquement de docker pour ça.
[^] # Re: Dépendances
Posté par gnumdk (site web personnel) . Évalué à 6.
Ah pardon, je n'avais pas compris que j'avais à faire à un troll qui ne sait pas de quoi il parle… Bref, chroot/virtualisation et flatpak ou comment montrer qu'on ne maîtrise pas son sujet…
[^] # Re: Dépendances
Posté par flagos . Évalué à 1.
La question des security updates n'est clairement pas assez documentée, mais que ce soit snap ou flatpak, les dépendances utilisées sont clairement listées par les développeurs.
A partir du moment ou les dépendances sont proprement déclarées, la plateforme de build peut tracer quels sont les packages qui ont besoin d’être rebuildes, et donc relancer un build automatiquement.
Sur Snapcraft, ca semble etre fait comme ca (https://forum.snapcraft.io/t/further-automation-of-build-snapcraft-io/2926), et vu que les updates sont automatiques du cote de l'utilisateur, on sait que chaque mise a jour sera rapidement déployé.
Sur Flathub, je n'ai pas trouve de documentation sur le sujet.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 6. Dernière modification le 12 octobre 2018 à 10:57.
Sauf que ça va à l’encontre complet de ce qu’annonce FlatPak : stabilité et reproductibilité.
Finit aussi l’argument de « on va faire tourner de vieilles applis comme ça ou des trucs qui dépendent de vieilles bibliothèques ! »
Si tu veux faire des choses comme ça, ça s’appelle bizarrement apt ou pacman… :)
Pas besoin de FlatPak encore une fois.
Ou alors FlatPak est juste en train de faire le taff d’une distribution, et devient une inception avec une distrib dans une distrib…
[^] # Re: Dépendances
Posté par gnumdk (site web personnel) . Évalué à 4.
Tu connais silverblue? Je ne sais pas si elle deviendra la prochaine Fedora mais en tout cas les démos que je vois sont juste "awesome" grâce à rpm-ostree.
[^] # Re: Dépendances
Posté par flagos . Évalué à 5.
On parle la d'update mineures de librairies, au moment de patcher les failles de sécurité.
Pourquoi ? Tant que ces librairies sont maintenues sur le système de build, tout va bien. Tu declares de quels libs (et versions) tu depends, et voila, tu as ta veille lib qui sera empaquete et tout de meme mise a jour s'il le faut. Example sur snap: https://docs.snapcraft.io/t/c-c-applications/7817
Et bizarrement, a force d'avoir chacun leur systeme de build et un tel merdier dans les versions de librairies, toutes les distros frezzent complètement les versions des logiciels qu'elles proposent ! Si le build et de distribution est tellement complique et heterogene que personne n'ose mettre a jour, a quoi bon s'en servir ?
Concrètement, j'ai mis a jour ma dernière LTS sur ubuntu, je sais tres bien que je n'aurai pas de mise a jour de mes logiciels. Souviens toi par exemple qu'il n'y a pas si longtemps meme la version de Firefox etait freeze pendant la duree de vie d'Ubuntu !!
Il propose surtout a ses utilisateurs d'avoir des logiciels mis a jour, chose qu'apt nous a jamais vraiment proposé.
[^] # Re: Dépendances
Posté par Anonyme . Évalué à 10.
D'expérience, je me suis rendu compte que cette approche était en réalité une illusion de sécurité que d'avoir les dépendances partagées entre toutes les applications, parce que dans la pratique, cela implique souvent que les admins ne mettent pas à jour au risque que cela casse des applications existantes. Pour avoir travaillé chez un hébergeur, en vrai je ne me suis jamais connecté à une machine en ssh sans y voir un avis de mise à jours de plusieurs centaines de paquets dont de sécurité, les majs n'étaient faites que lorsqu'on avait une CVE un peu plus populaire que les autres.
L'isolation des dépendances à au moins l'avantage de permettre la reproductibilité de l’environnement, de pouvoir exécuter des tests dans un environnement contrôlé et rentre tout processus de mise à jour automatisable plus facilement.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 1.
Pour moi c’est justement exactement le contraire.
L’embarquement des dépendances pose la question de la glibc et du kernel utilisés.
La compatibilité entre versions y est plutôt bonne mais pas garantie et tu t’exposes à des crashs totalement incompréhensibles d’une machine à l’autre si tu utilises un binaire compilé avec une glibc qui n’est pas celle utilisée par le kernel de ta machine. Cf ici pour le détail du problème de compatibilité.
La garantie de reproductibilité vient donc de sauter (et encore pire sous Docker avec des trucs type Alpine/µClibc quand le dev a toutes les chances d’utiliser et de tester sous glibc).
Les mises-à-jour automatisables sont rarement des mises-à-jour des libs systèmes.
Peu de monde s’amuse à changer ses fichiers de dépendances pour mettre à jour avec la dernière version connue.
Généralement, les gens ne rebuildent que sur des changements de version upstream de l’application (et non d’une des dépendances) et ne changent les versions des dépendances que sur une version majeure de l’application (et non d’une dépendance).
Je ne connais d’ailleurs pas de process de build capable d’aller détecter un changement de dépendances de manière fiable, et encore moins capable de garantir que l’image finale est toujours fonctionnelle avec la nouvelle version. C’est un processus relativement très manuel qui nécessite de revalider l’ensemble de l’applicatif suite à un tel changement, et l’automatisation demanderait des tests d’intégration très couvrants pour ça, ce qu’on a généralement jamais.
Ton idée de maj auto vient de sauter aussi du coup.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 1.
Pour résumer, tu as la reproductibilité pour une image donnée et un contexte d’exécution donné.
Dès que tu reconstruits l’image en changeant une dépendance, tu ne garanties plus rien (incompatiblité fonctionnelle).
Dès que tu changes le contexte d’exécution (passage alpine/debian, ou changement de distribution hôte), tu ne garanties plus rien non plus (incompatibilité ABI).
[^] # Re: Dépendances
Posté par Anonyme . Évalué à 5.
Ouais enfin bon, on peut quand même considérer que les syscall du kernels sont relativement stable dans le temps et que la rétro compatibilité est assurée d'une version de kernel à une autre… Donc dire que tu ne peux pas avoir un environnement reproductible parce que tu peux pas garantir que la verison du kernel, c'est un peu pousser mémé dans les orties…
Sinon concernant les tests, la quasi majorités des logiciels libres importants sont aujourd'hui couvert par un nombre de tests suffisamment important pour garantir leur bon fonctionnement dans un environnement donnée, quand il s'agit de logiciel développé en interne, j'ose espérer que les développeurs sont payé pour avoir au moins une série de tests fonctionnels qui permettent garantir leur bon fonctionnement… sinon c'est que ton produit n'est de toute façon pas suffisamment critique pour tolérer une panne.
Encore une fois, moi je te dis ce que je constate, considérer que tu garanties mieux la sécurités d'un système parce que tu peux mettre à jour les libs indépendamment des logiciels qui en sont dépendant est une chimère, encore faut-il que les sysadmins se donne la peine de réaliser ces mises à jours compte tenu du risque que cela représente. Quand tu as la possibilité de réaliser ces mises à jours dans une environnement reproductible, tu n'as plus aucune raison pour ne pas les faire étant données que tu as toujours la possibilité de revenir en arrière si dans le pire des cas tu observais un problème après avoir effectué l'upgrade.
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 3.
Les tests vont peut-être exister.
Est-ce que les tests unitaires seront lancés lors du build de l’image ? Déjà c’est loin d’être garanti.
Est-ce que les tests d’intégration (ie du binaire final dans libc+kernel d’exécution) le seront ? Quasiment certains que non.
Au contraire.
Tu n’as justement plus aucune raison de les faire avec FlatPak, parce que ton appli fonctionne toujours avec la vieille lib chez tous tes utilisateurs.
Alors que tu es contraint de faire le portage sous Debian ou Arch si tu ne veux pas voir ton appli se faire virer des dépôts.
D’autant plus que j’ai déjà montré plus haut que la reproductibilité ne s’applique que pour une image donnée dans un hôte d’exécution donné.
Tu n’as plus aucune reproductibilité (ie que ton application qui fonctionnait en v1 fonctionne toujours en v2), en tout cas pas garantie, quand tu passes d’une v1.x à une v2.x sur le soft ou une dépendance ou que tu changes l’hôte d’exécution.
Un soft qui tourne parfaitement en glibc peut se tauler magistralement µclibc.
Un soft qui tourne parfaitement avec libssl 1.1.x peut ne même pas compiler en 1.2.x.
Un soft qui tourne parfaitement sur une Debian 9 (libc 2.24) peut ne pas fonctionner en Debian 8 (2.19) ou en Debian 10 (2.27) ou sous Arch (2.28), même FlatPakisée.
[^] # Re: Dépendances
Posté par flagos . Évalué à 3.
Tu mélanges 2 types d'upgrade:
- un changement de version de lib (ton exemple libssl 1.1.x peut ne même pas compiler en 1.2.x)
- un upgrade de mise a jour de securite, par exemple 1.1.x vers 1.1.y qui corrige une faille.
Evidement, le jour ou on passe de 1.1 vers 1.2, il est évident qu'il faudra refaire des tests, mais objectivement, ce n'est pas le role des mainteneurs de décider de cela.
Mais au final, on se fiche un peu qu'une appli soit sur 1.1 ou sur 1.2. Ce qui compte, c'est qu'elle soit sur une version maintenue en terme de sécurité, et que dès qu'il y ait un correctif, ce soit publie le plus tot possible, en 1.1.x ou en 1.2.x.
Et pour cela, je vois pas pourquoi on peut pas rebuilder des la sortie d'une version 1.1.y tous les paquets snap ou flatpak qui étaient basés sur 1.1.x. Et pour cela, il n'y a pas besoin de faire 15000 tests avant de livrer. De toute maniere aujourd'hui, avec yum, apt et les autres, lorsqu'une lib est fixée, ca m'étonnerait que tous les tests unitaires et d'intégration soit relancés sur toutes les distribs.
D'ailleurs, tu viens peut etre meme de trouver malgré toi un argument pour snap et autres. Avec Snap et flatpak, il me parait concevable de relancer les tests fonctionnels du projet s'il existe un pipeline. Par contre, avec apt et yum, avec la myriade de distribs linux, le test fonctionnel c'est l'utilisateur qui va le faire.
[^] # Re: Dépendances
Posté par flagos . Évalué à 3.
Pourtant unattended-upgrades est active par default avec Debian et Gnome: https://wiki.debian.org/UnattendedUpgrades
Quelle différence ca fait ?
[^] # Re: Dépendances
Posté par Aeris (site web personnel) . Évalué à 7. Dernière modification le 12 octobre 2018 à 19:59.
Je parlais bien évidemment dans le cas de FlatPak et au point de vue du build de l’image, pas au niveau de l’upgrade côté utilisateur.
Dans le cas de Debian, les mises-à-jour ne sont justement pas automatiques.
Un mainteneur intervient manuellement pour mettre à jour son ou ses (quelques) paquets maintenus, s’emmerde à lire les releases notes pour s’assurer que c’est bien ABI compatible avec la dernière version, etc.
Il pousse ensuite son paquet, et tout le monde en profite dans toutes les applications.
Il n’est pas noyé sous la tonne de dépendance dont il n’est même pas supposé être le mainteneur, comme c’est le cas de freedesktop qui va devoir se coltiner les releases note aussi diverses et variées que gpg (j’espère qu’ils ont des cryptologues), xorg (et aussi des experts en matos vidéo), nano, ffmpeg, gstreamer, gcc, cmake, zip et j’en passe.
S’amuser à tester toutes les combinaisons possibles jusqu’à trouver un truc qui tombe en marche capable de builder tout ce petit monde (un libssl 1.2.x pour compiler gnupg 2.2.10, ça passe ou pas ?).
Pousser leur image… Et devoir notifier tous les mainteneurs des applications du dessus pour les mettre à jour et remonter les problèmes de build éventuels (« coucou, on a mis à jour gcc ! il build toujours ton projet ? »).
Qui devront rebuilder leur image, pester contre les mainteneurs de freedesktop (stabilité et reproductibilité vous avez dit ?), etc.
D’ailleurs, rien que de voir actuellement du 1.0.2o en libssl pour freedesktop, ça montre bien le problème…
La branche 1.0.x est obsolète, même Debian est plus à jour quoi…
Et il n’y a pas le patch 1.0.2p qui date pourtant de août 2018 et patche une CVE…
Ou encore gpgme 1.1, quand on en est à la 1.12…
[^] # Re: Dépendances
Posté par flagos . Évalué à 2.
Et ce travail est fondamental. L'idée, c'est de reutiliser ce travail au niveau de la machine de build et non sur la machine de l'utilisateur.
Ca c'est avec apt. Avec snap, il pousse son paquet de librairie (ABI compatible, tout bien) -> ca retriggue un job de build -> et tout le monde en profite dans ses applications.
La grande différence ? C'est qu'on se base que sur le travail d'un seul mainteneur pour produire une image de reference alors qu'avec apt, yum etc, tu as autant de mainteneurs que de distribs, ce qui fait qu'en pratique, l'écosystème logiciel est completement freeze pendant le temps de vie de la distrib.
# Kill flatkill
Posté par EmmanuelP . Évalué à 7.
Franchement, on peut émettre des critiques sur flatpak, il y a sans doute beaucoup à dire, comme n'importe quel développement logiciel.
Mais pour ça, il faut faire un minimum d'effort, et pas juste balancer des chiffres sans essayer de comprendre ce qu'ils représentent. Non, l'installation de logiciels via flatpak ne prends pas 100 fois plus de place que l'équivalent dans un format de paquet traditionnel.
Appimage est peut-être plus simple que flatpak, mais il ne cherche pas à implémenter un quart des fonctionnalités de flatpak: isolation, mises à jour atomiques, runtime, déduplication, notification de mises à jours…
Et puis ne pas prendre pour argent comptant une page web parmi tant d'autres, dont le seul but est de détruire flatpak.
[^] # Re: Kill flatkill
Posté par liberforce (site web personnel) . Évalué à 8.
Flatkill a tout de même un avantage: montrer que le boulot n'est pas fini, car faire un package flatpak les yeux fermés en donnant toutes les autorisations à l'appli c'est une hérésie au niveau sécurité, parce que ça ouvre des failles de sécurité.
Des packageurs inconséquents peuvent donc ruiner la réputation d'une application, et ça c'est un vrai problème. J'ai déjà vu des développeurs refuser de mettre le doigt dans flatpak, et refuser les rapports de bug à ce sujet parce que l'appli a été packagée par un tiers.
[^] # Re: Kill flatkill
Posté par gnumdk (site web personnel) . Évalué à 5.
Oui, mais globalement, l’intérêt sécurité je le vois plus avec un Spotify bien cloisonné (et c'est le cas chez flathub). Que la version nightly de nautilus puisse accéder à mon home, je m'en fou un peu plus.
[^] # Re: Kill flatkill
Posté par claudex . Évalué à 6.
Comme pour les packages faits par les distributions.
« 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
# SDK téléchargé en dépendance
Posté par damaki . Évalué à 3.
J'ai eu à peu près le même soucis récemment ; j'ai repéré les 2 Go du SDK de flatpack dans /var/lib/flatpack parce que j'ai du avoir le malheur de télécharger une appli qui avait tiré ça en dépendance.
Flatpack n'est pas le problème, le soucis est plutôt du côté des mainteneurs des paquets qui ne comprennent pas ce qu'ils font. Il y a le même soucis avec certains paquets de distro qui tirent la terre entière comme dépendances, par flemme ou impossibilité d'avoir des dépendances optionnelles.
Les trucs de sandbox contraignantes pour l'écriture de fichiers, c'est toujours pareil pour les applis sur des OS Desktop, ça finit désactivé dans quasiment toutes les applis parce que c'est trop chiant à gérer pour écrire des fichiers utilisateur. J'ai vu le même souci avec les Snaps de Ubuntu (utilisables aussi sur d'autres OS).
Ma conclusion à moi est qu'AppImage reste la meilleure solution. Ça n'est pas efficace niveau espace disque et libs à jour, mais pour fournir une appli fonctionnelle et ses dépendances, ça reste le meilleur moyen. Les vertus :
- ça marche ailleurs que chez soi
- ça culpabilise les devs de faire un livrable qui dépend de 2000 paquets et donc ça réduit la taille des livrables+deps.
C'est ni original, ni efficace, mais des années d'expérience sous Windows montrent que ça marche plutôt bien.
[^] # Re: SDK téléchargé en dépendance
Posté par gnumdk (site web personnel) . Évalué à 2.
Oui, enfin les 2 Go, ça sent le KDE à plein nez… (puisque certains veulent troller…)
[^] # Re: SDK téléchargé en dépendance
Posté par BAKfr . Évalué à 3. Dernière modification le 12 octobre 2018 à 21:24.
Les runtimes de Gnome et de KDE ont plus ou moins la même taille.
Sur mon PC:
org.gnome.Platformprend 1,3 GBorg.kde.Platformprend 1,6 GB[^] # Re: SDK téléchargé en dépendance
Posté par gnumdk (site web personnel) . Évalué à 2. Dernière modification le 13 octobre 2018 à 17:07.
[^] # Re: SDK téléchargé en dépendance
Posté par BAKfr . Évalué à 2. Dernière modification le 14 octobre 2018 à 17:57.
Étrange. Non seulement les chiffres ne sont pas du tout les mêmes chez moi, mais en plus ils ne correspondent pas avec ce que flatpak lui-même indique.
[^] # Re: SDK téléchargé en dépendance
Posté par YBoy360 (site web personnel) . Évalué à 4.
si, ça correspond, faut ajouter freedesktop à KDE et Gnome.
[^] # Re: SDK téléchargé en dépendance
Posté par ff9097 . Évalué à 1.
Et ajoute le runtime freedesktop
[^] # Re: SDK téléchargé en dépendance
Posté par BAKfr . Évalué à 4.
De ce coté, je trouve le système proposé par flatpak plutôt bien pensé. Les boites de dialogue de sélection de fichier sont des "portes de sorties" de la sandbox et c'est complètement transparent sous GTK et Qt.
Avec ça et la whitelist des fichiers et dossiers à autoriser, ça couvre déjà pas mal de cas.
# flatkill dot org
Posté par Wawet76 (site web personnel) . Évalué à 10.
C'est intéressant cette technique de prendre un nom de domaine pour faire juste une page d'opinion comme ça.
La page n'a pas plus de contenu qu'un post de blog, et n'a en plus pas d'info de date ni d'auteur. Je me demande qui trouve que son point de vue à tant d'importance qu'il justifie de dépenser quelques dollars pour avoir cette visibilité.
C'est peut-être un site volontairement polémique pour que plein de monde fasse des liens vers lui dans le seul but de l'utiliser plus tard pour du SEO…
[^] # Re: flatkill dot org
Posté par kna . Évalué à 0.
Et puis bon, quand on parle de sécurité, c'est bien de balayer devant chez soi aussi : https://www.ssllabs.com/ssltest/analyze.html?d=flatkill.org
# dépendances
Posté par jirayatira . Évalué à -1.
je crois que si tu avait télécharger openscad NextCloud aurais étais moins gourmand en espace disque
il faut juste que quelques dépendances (gnome kde freedesktop) soin déjà installer normalement le poids des app va beaucoup baisser
# Docker
Posté par Marotte ⛧ . Évalué à 6.
Pourquoi pas aller carrément vers la solution Docker, voire avec Kubernetes mais même sans ça, avec un simple Docker engine sur son poste de travail.
Là c’est pareil, les premiers softs vont peser lourd mais comme des « layers » seront éventuellement réutilisée d’une app’ à l’autre tu n’auras pas quelques giga-octets à installer à chaque fois. Par contre, j’imagine qu’il faut choisir ces images en essayant de garder un maximum de chose mutualisé. Par exemple, si tu as déjà une image de base de données qui se base sur une image Debian particulière et que tu veux « dockeriser » une application, tu auras mieux fait de choisir Debian pour ton image de l’applicatif, pour mutualiser les couches (layers) entre tes deux images.
Docker c’est vraiment un bon moyen de profiter des fonctionnalités de cgroups et de l’overlayFS offerts par Linux. Parce que gérer tout ça à la main ce serait un travail énorme, trop énorme pour un simple desktop. Faire tourner un Docker engine (et apprendre à s’en servir) par contre c’est à la portée du premier geek venu.
[^] # Re: Docker
Posté par Okki (site web personnel, Mastodon) . Évalué à 5.
Flatpak propose déjà des runtimes (Freedesktop, GNOME, KDE…) qui fournissent les principales bibliothèques. Et bien évidemment, ça utilise un certain nombre de technologies du noyau Linux (cgroups, namespaces, bind mounts, seccomp…) pour ne pas avoir à réinventer la roue.
[^] # Re: Docker
Posté par nokomprendo (site web personnel) . Évalué à 1.
A ma connaissance, Docker ne permet pas de générer et de lancer facilement une image d'appli graphique, avec accès au disque et au GPU.
[^] # Re: Docker
Posté par Marotte ⛧ . Évalué à 6.
Je t’avoue que je n’y avais pas pensé. Par contre, sans que ce soit tellement évident, ça a l’air possible de la faire relativement facilement, si je me fie à une rapide recherche sur Google.
https://medium.com/@SaravSun/running-gui-applications-inside-docker-containers-83d65c0db110
Je vois pas ce qui peut bloquer d’un point de vue théorique.
[^] # Re: Docker
Posté par nokomprendo (site web personnel) . Évalué à 6.
Oui en théorie Docker résout le problème. Mais en théorie aussi les distributions proposent une logithèque et un système de packaging qui font que le problème n'existe juste pas. Et pourtant…
Ton lien est intéressant mais je t'invite à tester les exemples proposés. Perso, j'arrive à faire tourner l'exemple de xeyes mais pour android-studio ou même juste gimp ou geany, ça ne fonctionne pas. Donc bon, on est loin de la solution facile. Et je ne parle même pas de la solution cross-platform que "We will see that in another post" depuis 8 mois et encore moins du gpu qui mérite certainement un roman entier à lui tout seul (https://github.com/NVIDIA/nvidia-docker)…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.