https://blogs.gnome.org/alexl/2015/06/17/testing-rawhide-apps-using-xdg-app/
Vous savez surement que GNOME (enfin RedHat) travaille sur une solution de "sandboxing" pour les applications de bureau, cela nécessite néanmoins d'adapter le code des applications pour en profiter.
Mais, cela permet aussi de lancer une application fournis par un développeur pour un "runtime" donné.
En gros, je distribue mon soft Toto avec les libs nécessaires et je peux donc fournir la dernière version pour l'ensemble des distributions Linux.
On peut donc tester les applications de Fedora rawhide directement depuis une Fedora 21 ou 22 sans rien casser.
# Perte des avantage de mutualisation
Posté par Fabien PRORIOL . Évalué à 8.
Finalement, cette mode de sandboxing revient a créer sous linux la même chose qui existe sous Mac ou Windows…
Certe ça simplifi le packaging et la distribution, mais on perd un gros morceau de l’intérêt des distributions Linux par rapport aux autres OS…
[^] # Re: Perte des avantage de mutualisation
Posté par Fabien PRORIOL . Évalué à 9.
Je m'auto complète, malheureusement, je ne peux pas/plus modifier/corrigé mon commentaire…
Finalement, cette mode de sandboxing revient a créer sous linux la même chose qui existe sous Mac ou Windows… En gros, chaque logiciel est distribué avec ses propres libraries plutôt que de packager tout séparément…
Finalement, on devrait créer sous Linux le dossier /Program Files// non ?
Certe ça simplifie le packaging et la distribution, mais on perd un gros morceau de l’intérêt des distributions Linux par rapport aux autres OS…
Finalement, le schéma est un peu triste…
En exagérant, finalement, dans les sandbox on devrait mettre la libc et le kernel linux et le lancer sous qemu non ???
[^] # Re: Perte des avantage de mutualisation
Posté par saltimbanque (site web personnel) . Évalué à 2.
Cela fait déjà deux grosses différences majeures ; de plus je ne pense pas qu'il faille opposer cette manière de distribuer aux standards ni même au packaging (pas pour l'instant).
[^] # Re: Perte des avantage de mutualisation
Posté par neil . Évalué à 1.
Pourquoi ? Quand tu mets à jour ton noyau/core-utils/bash/whatever ça met à jour ton firefox/pidgin/vlc ou vice-versa ? C’est écrit en Haskell ou quoi ?
[^] # Re: Perte des avantage de mutualisation
Posté par saltimbanque (site web personnel) . Évalué à 4.
quand la distribution offre jusqu'au maximum telle version de telle application il faut upgrader toute la distribution.
[^] # Re: Perte des avantage de mutualisation
Posté par kna . Évalué à 4.
Quand ton appli est compilée avec libtruc-1.0 et que tu as libtruc-2.0, ça peut poser problème (essaye gentoo et ses revdep-rebuild, ou du pinning debian à haute dose).
[^] # Re: Perte des avantage de mutualisation
Posté par MTux . Évalué à 3.
Le principe des Sandbox c'est de créer en environnement isolé pour qu'en cas de pépin ça n'impacte pas le système principal. C'est pas du tout le rôle du dossier Program Files.
[^] # Re: Perte des avantage de mutualisation
Posté par Misc (site web personnel) . Évalué à 6.
Tu peux aussi remplir la sandbox avec les paquets de la distribution. Typiquement, j'ai des collègues qui font ça avec des containers ( docker en l'occurence ), avec la plateforme sous une distribution stable ( RHEL 6 ), et haproxy sur la version suivante de la distribution ( RHEL 7 ), le tout sur le même noeud.
Ensuite, comme toujours, il faut faire gaffe d'ou vient le contenu de ta sandbox. Exemple, on considére que 30% des containers sur le registry contiennent des failles classés "high" ( http://www.banyanops.com/blog/analyzing-docker-hub/ ). Même si les devs de Docker tentent d'expliquer que c'est pas si énorme ( https://jpetazzo.github.io/2015/05/27/docker-images-vulnerabilities/ ) et qu'il s'agit de vielles images, le fait est que le chiffre reste assez haut pour les images qui datent de 2015 et qu'on parle que des soucis qualifiés de "high".
Et surtout, l'étude ne parle que des images officiels. Pas des images non officiels, ou je pense que ça doit être un peu la fête du slip une fois qu'une image n'est plus maintenu.
Donc oui, la techno est cool en soit. Mais tout comme les ppas, les rpms, ou n'importe quoi du même genre comme les saucisses, il faut regarder d’où vient le contenu, comment il est fait et ce qu'on trouve dedans.
[^] # Re: Perte des avantage de mutualisation
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Perso j'attends ces technologies avec impatience.
Par contre ce n'est pas du tout fait pour remplacer les systèmes de packaging des distribs Linux (et j'espère sincèrement que personne n'aura cette idée saugrenue).
Sur mon ordi, 99% (doigt mouillé) sont des logiciels installés par le packaging de ma distrib. Par exemple j'en ai rien à faire que Firefox soit un chouille en retard en version. Pareil pour mes lecteurs vidéo/audio, libreoffice, ou de manière générale la plupart des logiciels que j'utilise et qui me conviennent très bien. Par contre il existe 2 cas où ça me gêne:
1/ Certains programmes ont un problème qui me gêne depuis longtemps (voire une régression, bug qui n'existait pas avant et apparu lors d'une mise à jour). Or en cherchant des infos, je me rends compte que ce problème est connu et corrigé par la version stable en download. Franchement dans ce cas, attendre que la distrib mette à jour son paquet, ce qui prend souvent du temps (surtout pour les petits logiciels) me fait chier.
2/ Il existe de rares cas où avoir les dernières fonctionnalités upstream est important, en général c'est en rapport avec ses activités. Typiquement pour moi: Blender, GIMP, Scribus… ont des fonctionnalités qu'on va vraiment utiliser dès qu'on les obtient. Je ne veux pas attendre je-ne-sais-combien de mois non plus.
Or sous GNU/Linux, les téléchargements sur site, c'est en général soit du source-seulement, soit des archives à décompresser, et à mettre quelque part. Un utilisateur de base ne sera pas capable de faire en sorte que les fichiers correspondants lancent la version téléchargée (par exemple, double cliquer sur un .blend -> cela lance Blender installé par la distrib, pas celui téléchargé). Vous n'aurez pas le programme dans le menu (donc la plupart du temps, les utilisateurs gardent le dossier décompressé sur le bureau pour accès "plus ou moins simple et rapide"). Etc. C'est chiant, sale (l'installation) et pas du tout intégré à votre environnement.
Or ce type de solution a pour but d'installer des apps en mode utilisateur mais de manière propre. Vous pourrez cliquer sur des fichiers qui ouvriront votre application (installation des fichiers desktop); vos menus seront mis à jour avec la nouvelle app, sa description et son icône, dans la catégorie adéquate; vous n'avez pas besoin d'encombrer votre bureau de répertoires, etc. Tout comme une app installée par le système de paquetage de votre distrib, intégrée et propre, mais en mode utilisateur et avec une version récente, avec des droits réduits (car installé depuis une source moins sûre) à donner au fur et à mesure à l'application!
Franchement je trouve cela extrêmement gênant que tous les logiciels Libres — si on veut la version upstream — sont finalement bien plus simples à installer sous Win et OSX que sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Perte des avantage de mutualisation
Posté par laviestbelle . Évalué à -3.
C'est pas le principe des rolling releases ? Avec une Arch/manjaro/rawhide/tumbleweed/sid/etc l'on a tout les derniers softs de manière automatisé (contrairement à Windows) et ce très simplement =]
D'ailleurs est-ce que quelqu'un pourrait m'expliquer l'intérêt d'une distribution "stable" qui s'update seulement tout les 6 mois ? C'est dommage qu'il y ai si peu de rolling releases, ça réduit tellement mon choix en matière de distribs.
Et sinon quelqu'un a des news sur le projet bedrock Linux ?
[^] # Re: Perte des avantage de mutualisation
Posté par eric gerbier (site web personnel) . Évalué à 5.
En entreprise, quand tu gère des milliers de machines linux, et que tu dois tester toute modif avant de la propager, tu te limite assez vite à une distribution "stable", du type redhat/CentOs, plutôt que fedora …
Quand on ne gère que sa machine, qu'on a du temps et des compétences, c'est autre chose.
[^] # Re: Perte des avantage de mutualisation
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 19 juin 2015 à 09:16.
À part si on a envie de développer des compétences dans les systèmes de dépendances et de packaging ou travailler comme packageur, je ne vois pas trop l'intérêt de passer son temps à gérer des dépendances cassées, même si on a le temps. :)
[^] # Re: Perte des avantage de mutualisation
Posté par Misc (site web personnel) . Évalué à 3.
Et pourtant, les gens prennenet plus souvent des trucs neufs ( Fedora, Arch, Debian unstable, Ubuntu non TLS ) que de tourner en desktop sur les trucs stables et solide ( RHEL/Centos, Debian stable ).
Donc je pense que l'envie de stabilité est pas si forte que ça, car sinon, les gens prendraient les OS adaptés.
[^] # Re: Perte des avantage de mutualisation
Posté par Anthony Jaguenaud . Évalué à 4.
Je pense que c’est une question de visibilité. Ceux qui choisissent quelque chose de stable ne traîne pas sur les forums pour être au courant de la dernière version d’un logiciel, ni sur les forums d’aide « Pourquoi tout est cassé ? :'( »
Par exemple ici, on entend tout le temps parler d’Arch… je suis sûr que si on faisait un sondage, arch ne serait pas majoritaire. Et encore sur Linuxfr la plupart d’entre nous sont des bidouilleurs.
[^] # Re: Perte des avantage de mutualisation
Posté par Michaël (site web personnel) . Évalué à 4.
D'ailleurs à propos de bidouille, opam – un gestionnaire de paquets pour OCaml – a une fonction fantastique, le pinning ou épinglage. On a un dépôt de paquets mais on peut épingler un paquet à une copie de travail, et le gestionnaire de paquets sait qu'au lieu d'installer la version X.Y du paquet il doit prendre la version dans la copie de travail. C'est super chouette car lorsqu'on a corrigé un bug dans un logiciel ou développé une fonction nouvelle, on peut commencer à utiliser directement cette version avec le gestionnaire de paquets et c'est franchement génialissime!
Est-ce que des gestionnaires de paquets font ça dans les distributions Linux ou dans les BSDs? Peut-être OpenBSD?
[^] # Re: Perte des avantage de mutualisation
Posté par Ytterbium . Évalué à 3.
C'est tout ce que j'ai trouvé. C'est un peu vieux (4 ans), mais on voit que Arch était en 3e position après Ubuntu et Debian. Je ne pense pas que ça ait beaucoup changé. Ce serait rigolo de faire un sondage annuel pour suivre l'évolution.
[^] # Re: Perte des avantage de mutualisation
Posté par gnumdk (site web personnel) . Évalué à 2.
L'envie de stabilité passe par une distribution à jour… Si t'as un bug corrigé dans GNOME 3.16, tu fais comment avec ta Debian stable?
[^] # Re: Perte des avantage de mutualisation
Posté par laviestbelle . Évalué à 1.
Oui je sais :) je me suis mal exprimé, je parlais d'un usage desktop pour les particuliers.
[^] # Re: Perte des avantage de mutualisation
Posté par kna . Évalué à 2.
Je me vois mal expliquer à un client que son appli/site/script qui fontionnait avec telle version d'une lib ou telle version de php/python/ruby ne fonctionne plus parce que, bah, j'ai fait une mise à jour quoi.
[^] # Re: Perte des avantage de mutualisation
Posté par Albert_ . Évalué à 3.
6 mois c'est pas stable du tout enfin pas pour 99% des gens. C'est amusant de faire ca et j'aimais bien le rolling telease que je faisais avec debian unstable mais bon ca c'est sur mon ordi a moi que je maintient tous les jours. Sur celui des collegues ou ceux de ma famille que je ne touche que occasionnellement c'est pas quelques chose que je veux ni que je souhaite.
[^] # Re: Perte des avantage de mutualisation
Posté par Michaël (site web personnel) . Évalué à 4.
Ça c'est un côté très cool de FreeBSD et des ports.
Il y a depuis quelques années une branche stable des ports, mise à jour tous les trois mois, et j'ai configuré l'installateur de binaires pour suivre cette branche (pas de nouveau soft, màj de sécu et de stabilité).
Si j'ai besoin d'une nouvelle version plus récente d'un soft qui est déjà dans les ports, je peux l'installer facilement à partir des ports.
On a donc essentiellement une branche stable mais on peut suivre des paquets au plus près si on veut! :)
# Modification du code des applications
Posté par saltimbanque (site web personnel) . Évalué à 3.
Je n'ai pas vu où étaient les docs expliquant quel code doit être modifié ; as tu des explications ou un lien à ce sujet?
# Pas le temps pour en dire plus
Posté par Yuul B. Alwright . Évalué à 2.
https://wiki.gnome.org/Projects/SandboxedApps
# Docker et snappy
Posté par quent57 . Évalué à 3.
Je ne connais pas encore bien ces techno, mais selon moi, cela ressemble
- un peu a Docker (a ceci prêt que docker peut contenir plusieurs applications en un seul package, et peut être des configuration ?)
- à snappy de Canonical qui permet si j'ai bien compris du sand boxing et d'embarquer ses propres dépendances.
Vous en pensez quoi ?
[^] # Re: Docker et snappy
Posté par anarnux . Évalué à 1.
Même réaction pour la comparaison avec Docker, mais LXC m'est venu en premier. Ce système doit surement s'appuyer sur les même outils du noyau que Docker et LXC, et ça c'est cool.
C'est sur que livrer des applications avec tout l'environnement peut rebuter certains, mais c'est pour gnome qui est un DE, et pas le plus léger. C'est pas pour faire tourner des aplis sur de l’embarqué ou micro ordinateurs.
Pour la majorité des PC cela ne devrait pas être une gêne, vu la taille des disques actuelles.
[^] # Re: Docker et snappy
Posté par quent57 . Évalué à 3.
Ce qui m'inquiète personnellement, c'est les mises à jour de sécurité et bugfix des dépendances.
Est-ce que TOUTES les applications devront être repackagé avec les libs mises a jour ?
Ne va-t-on pas se retrouver dans une situation comparable à Adobe Reader qui avait une faille de sécurité car ils n'avaient pas mis a jour une dépendance sur une lib de parsing xml ? (je n'ai plus la source dsl)
En ce qui concerne la taille des disques, je suis bien content de pouvoir installer gnu/linux sur des anciens netbook de 16Go, voir sur un pc ultra portable récent ou je vais remplacer le HDD par un SSD de >=64 Go (si je ne compte pas mettre trop de médias dessus).
[^] # Re: Docker et snappy
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
La différence, c'est que Docker, c'est pour les serveurs, alors que là c'est un système de packaging utilisateur. On veut donc qu'un programme s'intègre à son environnement. Comme j'explique plus haut, on veut notamment lier les formats de fichier à une application (double clique sur un .xcf: ça doit ouvrir GIMP); on veut aussi mettre à jour le menu utilisateur automatiquement; on veut peut-être aussi fournir des infos aux autres logiciels pour interagir entre logiciels; on veut mettre l'icône de l'application accessible aux divers logiciels du bureau qui pourraient en avoir besoin, etc.
La partie sandboxing n'est pas pour moi la fonctionnalité cible. C'est uniquement une nécessité. Puisque ce sont des logiciels qui pourront être téléchargés d'un peu n'importe où, il faut pouvoir protéger un minimum l'utilisateur (même si on ne peut le protéger de lui-même et donc les risques existent toujours) et ses données.
Pareil pour les dépendances. Ce n'est pas à voir comme un but. Je suis certain que les dévs préféreraient ne pas en avoir besoin. Mais sans cela, un paquetage sera lié à une distribution en particulier (puisque chaque distrib a potentiellement des versions de lib différentes).
Le besoin, c'est simplement qu'il est très dur de télécharger un programme pour Linux quand il n'est pas packagé par sa distribution, ou seulement dans une version ancienne/bugguée. Et les rares fois où certains projets proposent quelques choses (en général juste une archive à décompresser quelque part), ça s'intègre absolument pas à votre bureau. Et s'ils proposent un paquetage de distrib, c'est limité à certaines distrib (.rpm, .deb, et encore pas toutes les distribs avec le même système de paquetage ne peuvent installer les mêmes paquets si certains chemins d'accès ou des noms de dépendances diffèrent par exemple…), et on a besoin des droits root pour installer.
C'est dommage qu'il n'existe aucun standard pour cela, et c'est ce qu'ils sont en train de créer.
D'ailleurs plusieurs font la remarque que c'est du GNOME, mais comme je le lis, même si cela vient de dévs GNOME au départ, c'est un projet de standard (XDG) qui devra fonctionner sous tous les environnements de bureau.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Docker et snappy
Posté par Albert_ . Évalué à 3.
Snappy c'est du canonical seulement et vu les derniers comportements de cette boîte et de son patron. J'éviterai de l'utiliser. A force de ne faire que des trucs dans ton coin tu t'isoles.
Je suis encore sur Ubuntu mais pas pour longtemps et vu que la dernière version à bien merdouillé mon système (le réseau ne se fonctionne plus à chaque mise en veille. Je dois manuellement relancé networkmanager…) c'est le bon moment pour changer. Le truc qui va me manquer ce sont les ppa…
[^] # Re: Docker et snappy
Posté par robin . Évalué à 1.
Passe sous arch, si le truc qui te tiens le plus à cœur sont les ppa. Les aur sont bien plus fournis.
bépo powered
[^] # Re: Docker et snappy
Posté par Albert_ . Évalué à 2.
Je vais tenter probablement. J'ai tente Fedora et KDE et franchement c'est … vraiment pas au niveau de ubuntu pour les paquets enfin c'est surtout pas au niveau d'une debian like. Apper ou gnome-package c'est a des annees lumieres de synaptic ou muon surtout apper vu que la seul facon de trouver un package c'est le nom (les listes par groupes sont cassees!)
# Ah la memoire de merde
Posté par Albert_ . Évalué à 3.
Cela me rappel un système sous debian qui permettait d'installer des applications en tant qu'utilisateur. Cela récupérait les différentes dépendances. Si quelqu'un se souvient du nom je suis preneur.
Je suis persuadé qu'il y a de grosses différences niveau technos et que, en particulier cela est beaucoup plus isolé. C'est très attrayant ces systèmes mais j'ai un peu peur de la taille que cela va prendre sur UN DD…
[^] # sympa, mais …
Posté par Julien.D . Évalué à 1.
Jehan< a très bien résumé l’intérêt de ce système.
Cette initiative est intéressante, car elle essaye de fournir une solution similaire à celle de Windows dans GNU/Linux, on aurait ainsi les avantages de l’une des méthodes qui gomment les inconvénients de l’autre.
La plupart des utilisateurs se moquent de la version du logiciel qui tourne sur leurs machines, l’important c’est généralement la stabilité et la sécurité. Chose que fournissent déjà les distributions.
C’est dans les cas où l'on attache une importance particulière à la version du logiciel que cela pose problème.
On peut très bien imaginer qu’avec ce standard, on puisse diffuser des versions par la distribution comme à l’heure actuelle et à côté des versions plus récentes ou au contraire des versions LTS.
Ces versions pourraient indiquer des dépendances dont la version est sans importance (et donc ne pas consommer d’espace ni de bande passante supplémentaire en profitant de la version de la bibliothèque disponible sur le système) et d’autres dont la version serait importante, et packagées dans le logiciel.
Le problème de ces dépendances serait toujours le possible manque de stabilité ou de sécurité, mais plusieurs points sont alors à prendre en considération :
Finalement cette solution pourrait augmenter les possibilités offertes par le monde GNU/Linux dans l’installation de logiciels, mais il faut que les choses soient bien faites, en n’ignorant pas cette problématique de sécurité et de stabilité.
Je me demande si les ports BSD permettent l’installation de plusieurs versions d’une même dépendance ?
[^] # Re: sympa, mais …
Posté par Sufflope (site web personnel) . Évalué à 1.
Pour un jouet genre http://linux.about.com/od/funnymanpages/a/a_man_funindex.htm (amusant, la man page de woman est non cliquable ; un raid de Sarkeesian et ses vavassaux SJW ?) oui j'imagine que les dépendances sont sans importance ; pour un vrai logiciel utile, qui se base sur des briques opensource (c'est-à-dire, en langage courant, des briques dont la gestion de version est lolol ça marche sur mon poste donc c'est bon), aucune dépendance n'est insignifiante.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.