Journal Des Bibliothèques dans le même répertoire que l'application

Posté par  .
Étiquettes :
5
16
juin
2011

Bonjour,

Cela fait un certain temps que je me pose une question:
Pourquoi, l'espace disque n'étant plus un problème, ne voit on pas apparaître une distribution basée sur Linux mais qui ne respecterai pas la norme de partage des bibliothèques ?

Explications:
Il me semble que sur Mac, une application s'installe dans un répertoire et déploie dans ce même répertoire (ou dans un sous répertoire) les bibliothèques dont elle a besoin.

Dans un soucis d'économie de l'espace disque, Linux utilise le principe de bibliothèques partagées: charge à un processus système de les mettre a disposition des programmes les demandant, charge à l'utilisateur (ou au processus de gestion de dépendance de package) des les mettre en place.

Mais voilà: de nos jours, sur un ordinateur de bureau standard, l'espace disque gagné de cette manière me semble peut intéressant (mais je peux me tromper) comparé aux problèmes de versions de bibliothèques, de dépendances, d'installation / désinstallation que ca entraine.

Connaissez vous une distribution qui permettrait cela, ou mieux encore, un moyen de faire cohabiter ce type de package (toute l'application dans un même répertoire, bibliothèques incluses) avec un autre type (les packages debian habituels) ?

  • # juste du bon sens

    Posté par  . Évalué à 10.

    Ce n'est pas qu'une question d'espace disque, quand je met à jour une lib je ne tiens pas à me coltiner la recompilation en static de toute les apps qui l'utilisent.

    • [^] # Re: juste du bon sens

      Posté par  . Évalué à 1.

      Dans le cas que j'évoque de bibliothèque non partagées tu n'aurais pas besoin de recompiler le programme, il continuerai d'utiliser la bibliothèque qui a été installée dans son répertoire. De plus je ne vois pas l'intérêt de recompiler le programme:

      Si il a été validé pour utiliser ta version 1 d'une bibliothèque qui comporte 20 fonctions, la 1.1 de ta bibliothèque de ta fonction qui elle comporte 25 fonctions n'a pas d'intérêt du point de vue du programme.

      Tu vas me dire que la version 1.1 peut apporter sur des fonctions utilisées par le programme des améliorations, dans ce cas il s'agirait d'une mise à jour du programme (revalidation).

      Je comprend bien l'intérêt des bibliothèques partagées coté OS, mais coté programmes standalone, il me semble que le desktop linux aurait à y gagner en simplicité.
      Un package static s'installerait aussi bien sur une distribution donnée que sur une autre, et le programme serait réellement le même.

      • [^] # Re: juste du bon sens

        Posté par  . Évalué à 10.

        Si il a été validé pour utiliser ta version 1 d'une bibliothèque qui comporte 20 fonctions, la 1.1 de ta bibliothèque de ta fonction qui elle comporte 25 fonctions n'a pas d'intérêt du point de vue du programme.
        Tu vas me dire que la version 1.1 peut apporter sur des fonctions utilisées par le programme des améliorations, dans ce cas il s'agirait d'une mise à jour du programme (revalidation).

        Si la bibliothèque se voit corrigée de problèmes de sécurité, on peut espérer une mise à jour plus rapide que devoir attendre que chaque programme l'utilisant revalide la bibliothèque. (Car une vraie "revalidation" peut être très longue)

        • [^] # Re: juste du bon sens

          Posté par  (site web personnel) . Évalué à 3.

          Si la bibliothèque se voit corrigée de problèmes de sécurité, on peut espérer une mise à jour plus rapide que devoir attendre que chaque programme l'utilisant revalide la bibliothèque. (Car une vraie "revalidation" peut être très longue)

          Ce n'est pas toujours vrai: la vulnérabilité peut n'avoir aucun impact dans certains environnements tandis que la validation est cruciale. On peut par exemple penser à un système d'assistance de pilotage.

          • [^] # Re: juste du bon sens

            Posté par  . Évalué à 1.

            Ce cas se produit-il si souvent qu'il ne peut pas être géré "au cas par cas" ? (spécifiquement compiler statiquement un tel programme, ou ajouter une dépendance qui force la version des bibliothèques demandées (par exemple dans Debian, libqtgui4 dépend de libqtcore4 qui doit être strictement en version 4:4.7.3-1))

            • [^] # Re: juste du bon sens

              Posté par  . Évalué à 2.

              Mauvais exemple, même si Qt a découpé les différentes fonctionnalités du framework dans différentes bibliothèques, ça ne signifie pas pour autant qu'elles sont indépendantes l'une de l'autre. D'ailleurs, toutes les distributions font de même, pas seulement Debian.
              Tu noteras également que Nokia ne fournit pas de sources distinctes de QtCore et QtGui, que la compilation séparés des deux modules n'est pas du tout supportés. Ça sera probablement différent avec Qt5 qui devrait modulariser un peu plus le framework, en tout QWidget & cie seront dans une bibliothèque développé indépendamment du core du framework

      • [^] # Re: juste du bon sens

        Posté par  . Évalué à 10.

        Si une faille de sécurité a été décelée dans une lib, tu peux:
        -soit mettre à jour la lib sur le système actuel
        -soit commencer à faire la chasse aux applis qui utilisent cette lib et les mettre à jour une par une

        De plus, ce n'est pas seulement une question d'espace disque, mais aussi de mémoire (je n'imagine même pas les bureaux Gnome ou KDE si chaque élément charge sa propre version de la lib!!).

        Enfin, peut-être que sur le bureau, l'espace disque, il y en a, mais on voit aussi une nette évolution vers un parc diversifié comprenant machines de bureau, portable, netbooks et bientôt smartphone.
        Est-il bien nécessaire d'avoir une variante de chaque distro pour chacune des catégories sus-citées?

        • [^] # Re: juste du bon sens

          Posté par  . Évalué à 5.

          _De plus, ce n'est pas seulement une question d'espace disque, mais aussi de mémoire (je n'imagine même pas les bureaux Gnome ou KDE si chaque élément charge sa propre version de la lib!!).

          Bha ca s'appelle, python, ruby, perl ou java...

      • [^] # Re: juste du bon sens

        Posté par  . Évalué à 3.

        ...Pourquoi utiliser une bibliothèque dans ce cas? Intègre les fonctions et autres éléments directement dans ton code. Ha ben oui, c'est plus de taf, mais du coup, tout ce que tu n'utilise pas dans la bibliothèque, tu le compile pas...

        Enfin, je dit ça, mais je suis pas dev, j'y connais pas grand chose.

        • [^] # Re: juste du bon sens

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Pourquoi utiliser une bibliothèque dans ce cas?

          pour ne pas avoir à réinventer la roue

          Intègre les fonctions et autres éléments directement dans ton code.

          Oui mais non, on va pas réinventer la roue, ni faire du copier coller, c'est idiot.

          C'est plus simple de dire, à la compilation, "intègre moi telle bibliothèque dans mon binaire final". Cela s'appelle de la liaison statique. Et c'est justement ce que propose de faire l'auteur du journal pour toutes les applications.

        • [^] # Re: juste du bon sens

          Posté par  . Évalué à 3.

          C'est ce que fait Google avec Chromium et les distributions n'apprécient pas trop. Par exemple Chromium n'est pas dans les dépôts officiels de Fedora : http://fedoraproject.org/wiki/Chromium.

          • [^] # Re: juste du bon sens

            Posté par  . Évalué à 3.

            Gentoo a fait pas mal de travail pour compiler Chromium avec les libs système (du moins, une partie des libs).

            DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: juste du bon sens

        Posté par  (site web personnel) . Évalué à 10.

        Faudra pas pleurer si tes programmes mettent 3 plombes à se lancer parce qu'il faut lire une ènième version de bibliothèque qui n'a pas encore été chargée.

        Sans oublier les correctifs de bugs et correctifs de sécurité plus difficiles à récupérer (tu deviens dépendant du bon vouloir du développeur de l'application pour se mettre à jour, et tu dois déployer tes correctifs pour chacune des N applications qui utilisent la bibliothèque en question).

        • [^] # Re: juste du bon sens

          Posté par  (site web personnel) . Évalué à 8.

          De surcroît, sauf erreur de ma part, l'espace mémoire nécessaire pour le système augmentera également. Au lieu d'avoir une seule fonction trucmuche en mémoire, elle sera chargée une fois par application utilisant la libtrucmuche.

          En général, les gens qui souhaitent optimiser les performances d'un système apprécient beaucoup les librairies partagées. L'utilisation de librairie statiques n'est pertinente que pour l'optimisation éventuelle d'une (ou de très peu d') application(s) particulièrement consommatrice(s) de ressources.

          Par exemple, j'utilise un système entièrement dynamique. Mais mes codes de calculs je les compile souvent en statique. En général, quand ils tournent ils sont seuls et donc je gagne quelques pouillèmes de % en temps de calcul. L'avantage c'est surtout de pouvoir copier le binaire vers une autre machine n'ayant pas forcément exactement les mêmes librairies sans recompiler.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: juste du bon sens

      Posté par  . Évalué à 1.

      ce n'est pas juste une préoccupation de développeur ou de geek ça ??

      Dans les faits, au nievau des bibliothèques partagées, l'utilisateur final il n'en a rien à faire de passer de libpangoft2-1.0.so à libpangoft2-2.4.so ou de libpthread-2.11.so à libpthread-2.13.so, ce qu'il veut c'est peut-être de pouvoir passer facilement de firefox 3.6 qui stagne sur sa distribution, vers la version 4 qui est plus mieux, même si ça doit prendre 12 Mo de place en plus sur le disque dur de 850 Go.

      Pour l'OS et le WM sous jacent, cela peut être louable d'avoir des bibliothèques partagées, mais pour certaines applications tierces, c'est plus pratique d'être en statique.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: juste du bon sens

        Posté par  . Évalué à 10.

        Il fait quoi l'utilisateur quand il y a une faille de sécurité sur une lib ? Il doit mettre à jour la moitié de ses applications ?

        Et avoir plusieurs versions de la lib en même temps, ça prend aussi plus de mémoire.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # GoboLinux

    Posté par  (site web personnel) . Évalué à 7.

    Tu peux regarder du côté de GoboLinux :
    http://www.gobolinux.org/index.php?lang=fr_FR

    • [^] # Re: GoboLinux

      Posté par  (site web personnel) . Évalué à 7.

      J'avais fait une news à l'époque : https://linuxfr.org/news/sortie-de-gobolinux-014
      Mais bon ça semble un peu mort. Ils n'ont pas sorti de nouvelle versions depuis des plombes...

      • [^] # Re: GoboLinux

        Posté par  . Évalué à 2.

        Merci, je connaissais

        Mais ca ne correspond pas exactement a mon idée qui était plus une sorte de repositery debian, configuré afin qu'il soit le 1er utiliser (on utiliserai donc un repositery standard pour le système) et n'inclurai que des programmes standalone hardlinked.

        Un tel repositery fonctionnerai sur tout les distributions basées sur apt.

        • [^] # Re: GoboLinux

          Posté par  . Évalué à 3.

          Où s'arrête le système? La librairie PNG en est-elle? Ton programme autonome l'utilisera-t-il?

          En fait, l'avantage de l'autonomie des logiciels disparaît quand tu as une distribution. Ton idée est d'utiliser debian et de prendre hors de debian quand ça n'y est pas encore, tout en gardant les avantages d'un paquet intégré au système. Pour les développeurs, ça veut dire maintenir des paquets liés au système et des paquets indépendants => travail en double.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: GoboLinux

        Posté par  . Évalué à 1.

        Dans le même genre, il y a aussi http://moonos.org/

  • # Bibliothèque partagée aussi en RAM

    Posté par  (site web personnel) . Évalué à 10.

    Y a pas que le disque... ça serait con de charger x fois GTK et x fois QT pour chaque applis.

    Plus si il y a une faille dans une bibliothèque qui est utilisée par plusieurs applications... en partagé, tu mets à jour la bibliothèque, avec chaque appli qui embarque tout, faut trouver et mettre à jour toutes les applis qui utilisent celle-ci.

    • [^] # Re: Bibliothèque partagée aussi en RAM

      Posté par  . Évalué à 9.

      Sans compter que si la lib Machin a un bug ou une faille de sécurité, pas besoin d'attendre le repackaging de toutes les applis l'utilisant !
      Pour des applis non-libres ou des applis pas/peu/plus maintenues, c'est un risque évident de se retrouver avec une faille non-colmatée !

  • # stali

    Posté par  . Évalué à 3.

    Il y a bien un projet nommé Stali qui se rapproche de ce que tu souhaites, mais je ne sais pas trop où ça en est.

    En tout cas, ils veulent vraiment se baser sur le static-linkage.

    Stali

    • [^] # Re: stali

      Posté par  (site web personnel) . Évalué à 9.

      Extrait du site :

      kernel is a single monolith based on linux, by default no kernel module support

      Ah oui quand même....putain !

      • [^] # Re: stali

        Posté par  . Évalué à 1.

        Nan nan, dans leur contexte c'est pas idiot du tout. Par exemple il doit y avoir une bonne majorité de gens sous gentoo qui n'ont pas le support des modules d'activé : ça ne sert à rien quand tu choisis tes drivers à la compilation et que tu les inclus en dur. Et niveau sécurité ça réduit la surface d'attaque, donc pourquoi pas.

        Par exemple chez moi je n'ai qu'un module en tout sur mon système : l'infâme blob nvidia.

        • [^] # Re: stali

          Posté par  (site web personnel) . Évalué à 4.

          Oui mais là je n'ai pas l'impression qu'ils incitent les gens à compiler leur noyau spécifiquement pour leur matos. Je crois que c'est plutôt un gros noyau avec tout dedans en dur....mais ça fait frissonner d'effroi !

  • # Et plus de simplicité

    Posté par  . Évalué à 4.

    Lorsqu'il y a une faille corrigée dans un bibliothèque. Tu ne la met à jour qu'une fois, si c'était les développeurs de l'application qui devaient tout ré-empaqueter à chaque mise à jour de toutes les librairies dont ils se servent. Ce serait un cauchemar à maintenir et il y aurait souvent des oublis et des failles de sécurité non corrigées pour certaines applications.
    De plus cela économise aussi un peu de bande passante, tu n'as pas à télécharger N fois la même bibliothèque mise à jour, juste une.
    N'hésitez pas a me corriger si ce que je dit est faux.

    • [^] # Re: Et plus de simplicité

      Posté par  . Évalué à 10.

      Ça existe déjà, et ça s'appelle Windows.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Et plus de simplicité

        Posté par  . Évalué à 4.

        Faux!
        Du moins en partie. Certains programmes utilisent des bibliothèque partagée (au moins directX) mais aussi d'autre; rendant certaines installation de programmes incompatible

        je me souviens de dll que je devais renommer pour certains jeux un vrai bonheur ;)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Et plus de simplicité

          Posté par  . Évalué à 3.

          Pour directX, cela a pu changer avec la derniere mouture, mais il m'est arrive de devoir installer la version n-2 pour jouer a tel ou tel jeu (j'ai de vieux jeux que j'aime bien :) et quitte a payer la taxe autant pouvoir m'amuser avec ces jeux.)

      • [^] # Re: Et plus de simplicité

        Posté par  . Évalué à -4.

        Fais moi plaisir, va dans \Program Files sur un Windows Vista / 7 , fais un dir /s *.dll et montres moi donc tous ces dlls dupliques a tout va...

        Mais a mon avis tu vas avoir du mal a sortir une grosse liste...

  • # réfléchir aux implications avant de (re)lancer un troll éculé

    Posté par  (Mastodon) . Évalué à 10.

    Dans un soucis d'économie de l'espace disque,

    s/disque/mémoire/

  • # Pas que un problème d'espace disque

    Posté par  (site web personnel) . Évalué à 10.

    C'est aussi:

    • un problème de mémoire vive, une librairie partagée peut être chargée en mémoire et effectivement partagée entre différents processus. C'est par exemple le cas avec les environnements comme Kde ou Gnome, il y a en effet beaucoup de librairies pour fournir pas mal de services, mais ces librairies ne sont présentes qu'en un seul exemplaire dans la mémoire physique.
    • un problème de mises à jour, le système de packaging ne le fait qu'une fois pour toutes les applications (bon, on pourrais avoir un gestionaire qui fasse le tour des applications installées et aille faire les mises à jour en N exemplaires).

    Ceci dit, rien n'empêche un développeur de réaliser une liaison statique avec les librairies (pour autant que celles-ci puissent être compilées de cette façon), à ce moment tu auras un gros, voir même très gros, binaire, qui contiendra toutes ses dépendances.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: Pas que un problème d'espace disque

      Posté par  . Évalué à 3.

      Et après on peut évoquer le problème de la distribution: la taille des paquets augmenterait sensiblement, et à ce niveau on peut estimer que la bande-passante est encore un problème, au moins côté serveur. Avec les médiums physiques il faudrait passer au DVD pour une installation minimum (et encore?!) et au Blueray pour installation standard.

      (à propos de bande-passante, il n'y avait pas un projet d'apt-torrent? plus il y a de monde mieux ça marche!)

    • [^] # Re: Pas que un problème d'espace disque

      Posté par  . Évalué à 2.

      C'est d'ailleurs ce que fait calibre. Il n'utilise pas les biliotheques systemes dans les binaires fournit sur le site.

  • # Ca existe déjà : Mac

    Posté par  . Évalué à -3.

    Si c'est un comportement que tu désires, le mieux est d'aller directement acheter un mac. Quel peut être l'intérêt de copier un os pour faire la même chose ?

    Ensuite pour l'application standalone qui n'utilise pas de bibliothèque partagée, ben il n'y a aucun changement parce qu'elle n'en utilise pas.

    Enfin les gestionnaires de paquets s'occupent de toute façon des soucis d'installation et de désinstallation.

    • [^] # Re: Ca existedéjà: Mac

      Posté par  (site web personnel) . Évalué à 4.

      D'ailleurs est ce géré de cette manière egalement sur IOS, car sur un systeme embarqué, la memoire disponible est beaucoup moins importante ?

      • [^] # Re: Ca existedéjà: Mac

        Posté par  . Évalué à 2.

        Surement, si un développeur veut intégrer une librairie qui sort de ce qui est fourni de base par l'OS.
        C'est comme ça sur android en tout cas.

      • [^] # Re: Ca existedéjà: Mac

        Posté par  . Évalué à 2.

        Si j'ai bien compris la "solution" adoptée c'est de pas faire de véritable multitâche :/

        DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Ca existedéjà: Mac

        Posté par  . Évalué à 3.

        Ils ont résolu le pb.

        Pas de librairie réutilisable en dehors de celle de l'OS et pas de VMs qui pourraient les proposer par dessus.
        Encore un peu et ils n'autorisaient que le copier/coller à la place des fonctions/méthodes.

    • [^] # Re: Ca existe déjà : Mac

      Posté par  . Évalué à 3.

      ou de prendre PC-BSD si on veut rester dans les OS libres

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # /opt

    Posté par  (site web personnel) . Évalué à 10.

    […] ou mieux encore, un moyen de faire cohabiter ce type de package (toute l'application dans un même répertoire, bibliothèques incluses) avec un autre type (les packages debian habituels) ?

    /opt est là pour ça.

    • [^] # Re: /opt

      Posté par  . Évalué à 1.

      bah en fait oui.. je pense que je vais passer par là :)

      De plus les commentaires rappelant les problèmes d'espace disque/mémoire et de sécurité m'ont convaincus.

      Je vais donc juste me contenter de hard linker et de mettre ca dans /opt.

      PS: Loin de moi l'idée de ranimer un vieux troll, mais je trouvais cette idée (oui, une idée venant du monde mac m'a l'air sympathique, mais c'est pas encore demain que je lâcherai mon pingouin !) intéressante.

      Il serait envisageable je pense de régler les problèmes de sécurité en faisant que les programmes à leur chargement en mémoire, demande à un processus tier si la bibliothèque X.a.b.c est déjà chargée en mémoire et l'utilise ou bien demande a ce même processus de la charger depuis son propre répertoire.

      Pour ce qui est de la sécurité et de la mise à jour centralisé, si la version X.a.b.c d'une lib est déclarée comme non sécurisé, on peut très bien via ce processus tier la déclarer comme non chargeable en mémoire. De plus si il n'y a que cette version de la lib qui est défectueuse, une mise a jour qui passerai dans chaque sous répertoire lib des programmes pour vérifier sa présence et la patcher pour la corriger serait envisageable.

      je ne reviens pas sur les atouts d'une tel solution, je pense que tout le monde comprend l'intérêt (installation / desinstallation / moins de problèmes de dépendance / validation plus aisé de certains processus). Mais c est vrai que comme on dit yakafokon, que la chose n'est pas petite, d'où l'interet d'un journal pour avoir le plus d'idée sur la question.

      • [^] # Re: /opt

        Posté par  . Évalué à 5.

        Il serait envisageable je pense de régler les problèmes de sécurité en faisant que les programmes à leur chargement en mémoire, demande à un processus tier si la bibliothèque X.a.b.c est déjà chargée en mémoire et l'utilise ou bien demande a ce même processus de la charger depuis son propre répertoire.

        Je ne comprends pas : j'ai l'impression que tu décris exactement ce qu'il se passe à l'heure actuelle mais en ayant plusieurs copies des lib ?

        Pour ce qui est de la sécurité et de la mise à jour centralisé, si la version X.a.b.c d'une lib est déclarée comme non sécurisé, on peut très bien via ce processus tier la déclarer comme non chargeable en mémoire.

        Et du coup il se passe quoi pour le logiciel qui utilise cette lib ? Il ne se lance plus ou il utilise une lib partagée ?

        De plus si il n'y a que cette version de la lib qui est défectueuse, une mise a jour qui passerai dans chaque sous répertoire lib des programmes pour vérifier sa présence et la patcher pour la corriger serait envisageable.

        Et sinon, au lieu d'en patcher 3 on en remplace une. T'en penses quoi ?

      • [^] # Re: /opt

        Posté par  . Évalué à 4.

        Il serait envisageable je pense de régler les problèmes de sécurité en faisant que les programmes à leur chargement en mémoire, demande à un processus tier si la bibliothèque X.a.b.c est déjà chargée en mémoire et l'utilise ou bien demande a ce même processus de la charger depuis son propre répertoire.

        Je vous invite à lire la page de manuel de "ld.so".

  • # Liaison statique

    Posté par  (site web personnel) . Évalué à 10.

    Autant tout lier en statique, comme ça c'est encore plus simple : les bibliothèques ne sont pas dans le même répertoire que chaque logiciel, mais carrément dans chaque logiciel.

    • [^] # Re: Liaison statique

      Posté par  (site web personnel) . Évalué à 1.

      Sur ma Gentoo, il y a une option "static" pour 37 paquets vitaux comme coreutils, make, net-tools, rsync, wget, etc. Cette question d'une compilation globale en tout statique me titille depuis quelques temps. Depuis une Gentoo, l'expérience pourrait être aisément tentée en modifiant les paramètre de compilation, puisque tout (sauf quelques softs proprio) est compilé sur une Gentoo . Et il serait intéressant de faire une comparaison impartiale entre deux machines identiques, ayant la même liste de paquets, l'une étant en liaison dynamique, l'autre en statique. Évidemment je parle de desktop moderne avec une conf en RAM et HD similaire avec ceux en standard dans les supermarchés.

  • # PC-BSD

    Posté par  (site web personnel) . Évalué à 3.

    Je connais un système BSD qui intègre la fonction que tu cherches: PC-BSD intègre un système de PBI (Push Button Installer) en plus du classique système de packages et ports. Un PBI est un package avec un installateur graphique qui contient une application indépendante du reste du système: tous les composants de l'application sont contenus dans un dossier dédié.

    Ce système coûte de l'espace disque (probablement tolérable) et de l'espace mémoire (toujours cher aujourd'hui). L'avantage est qu'une mise à jour mal faite ne cassera pas l'application en question. Cette fonctionnalité est aussi intéressante pour les éidteurs de logiciels non libres.

    PC-BSD
    PBI Tutorials

  • # J'aime bien la question

    Posté par  (site web personnel) . Évalué à 6.

    Les deux problèmes principaux, que sont l'espace mémoire utilisé et les mises à jour (de sécurité), dissuadent d'envisager une telle solution, mais la question méritait d'être poseé (donc je te pertinente) ;-)

    blog.rom1v.com

  • # Façon de voir les choses

    Posté par  (site web personnel) . Évalué à 8.

    Ce n'est pas réellement une problématique adressée au système d'exploitation : un environnement unix (comme Windows) offre la possibilité d'utiliser les bibliothèques partagées, il ne l'impose pas.
    La possibilité d'embarquer les libs dans le paquet (ou bien le linkage statique) est probablement situé du côté du mainteneur et/ou plus précisément au niveau de l'usage des outils de construction de logiciels. Ceux-ci sous Unix sont très orientés bibliothèques partagées, là où sous Windows, par nature (pas de système de dépôt pour installer automatiquement une dépendance), on est a priori plus incité à faire un gros paquet binaire (quitte à dispatcher les libs dans system32 à l'installation, ce qui dans la plupart des cas ne sert pas à grand chose car tout le monde le fait ^^).
    Bref, un système unix n'a jamais empêché de voir beaucoup de softs proprio embarquer leurs propres libs sans soucis.
    bref, si un soft proprio n'est pas assez populaire pour avoir des mainteneurs sur chaque grande distribs => deux choix :
    1. l'éditeur se casse le bonbon à maintenir les dépendances de libs à chaque version majeur de chaque distrib (me semble que c'est le cas pour la version closed source de VirtualBox)
    2. l'éditeur embarque son gros blob de libs dans le paquet. Moins de boulot mais des libs datées.

    Pour les softs libres populaires (et certains softs proprios qui ont une masse critique d'utilisateurs), on trouve des mainteneurs sur chaque "grande" distro pour gérer les dépendances.
    Pour les softs libres à diffusion confidentielle, on a la possibilité de recompiler chez soi en allant chercher ce qui manque, dans le cas où le mainteneur ne propose pas de paquet assez récent ou pour la distro cible, en priant pour que l'API utilisée des libs n'ait pas trop bougé. C'est probablement le cas le plus "chiant", là où un vieux blob qui embarque tout aurait sûrement eu plus de chance de fonctionner, mais bon, il ne se rencontre pas tous les quatre matins.

    En conclusion, ce que tu soulèves est pour moi un problème purement utilisateur, pas du système d'exploitation.

  • # Distro = une offre intégrée

    Posté par  (site web personnel) . Évalué à 6.

    ne voit on pas apparaître une distribution basée sur Linux mais qui ne respecterai pas la norme de partage des bibliothèques ?

    Ca ne serait pas la question qui serait mauvaise?
    Une distro contrôle tout, c'est même son avantage, elle gère l'ensemble des packages, vérifie la compatibilité etc... Donc aucun intérêt à embarquer 100x la même lib, puisque lors d'un upgrade, le gestionnaire de distro vérifie (en théorie) la compatibilité avec les 100 applis et patche en conséquence. Ca ne ferait que consommer du disque sans aucun avantage.

    Et ensuite, l'utilisateur est libre (à la disponibilité et compatibilité de l'appli avec sa distro près, c'est la que ça coince souvent) d'installer une appli non dans le repo, avec ses libs en statique, dans /opt. Le meilleur des deux mondes donc.

  • # sur mac

    Posté par  (site web personnel) . Évalué à 6.

    Sur mac une application peut conserver les bibliotheques un peu specifiques dans son bundle (le dossier de l'application), mais les bibliothèques d'utilité générale, susceptibles d'être réutilisées (celles fournies d'office avec le systeme par ex) sont typiquement regroupées dans des 'frameworks', cad d'autres bundles , par ex. CoreAudio, Cocoa, OpenCL , etc.. Un framework c'est donc un dossier qui contient une ou plusieur lib partagée, avec ses versions successives, pour toutes les architectures supportées, ainsi que les headers .h pour le developpement. Au final ça revient à peu pres à la même chose que sous Linux, sauf qu'au lieu d'avoir 10000 .so dans /usr/lib t'as une 100aine de frameworks dans Library/Frameworks

    • [^] # Re: sur mac

      Posté par  . Évalué à 3.

      Et pour une bibliothèque qui n'est pas installée avec le système de base mais qui est assez souvent utilisée (prenons par exemple Qt ou GTK), comment cela se passe-t-il ?
      Une application "tierce" ne peut pas supposer qu'elle sera présente, donc doit inclure sa propre copie, mais si elle était déjà présente par un autre programme, il devrait utiliser cette dernière. Cela est-il résolu ?

      • [^] # Re: sur mac

        Posté par  . Évalué à 2.

        http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Tasks/InstallingFrameworks.html#//apple_ref/doc/uid/20002261-BBCCFBJA

        Depending on the time of day, the French go either way.

        • [^] # Re: sur mac

          Posté par  . Évalué à 4.

          Ils recommandent donc soit d'installer dans /usr/lib (pour simplifier) pour que tous les programmes en profitent, soit de garder en interne dans le dossier de l'application.
          Mais si l'on supprime le programme, comment fait-il pour savoir si la bibliothèque partagée n'est pas à présent utilisée par un second programme ? Il y a un compteur ? Les bibliothèques installées ne sont jamais désinstallées même si plus rien ne s'en sert ?

          • [^] # Re: sur mac

            Posté par  . Évalué à 3.

            Pour désinstaller sous Mac OS, tu mets le dossier de l'application dans la corbeille. Point. Tout le reste … reste justement. Il existe toutefois des utilitaires qui proposent de nettoyer un peu mieux.

            • [^] # Re: sur mac

              Posté par  . Évalué à 5.

              D'accord, le système ne prend tout simplement pas en charge la désinstallation. C'est une façon de voir les choses un peu "amateur".

              • [^] # Re: sur mac

                Posté par  . Évalué à 1.

                Apple aurait bien voulu utiliser apt mais probablement pour des raisons de licence (je n'ai aucune idee des details) cela ne s'est pas fait.

                Et non je n'ai pas de lien, juste ma memoire. Je laisse le soin a tout personne interesse de faire la recherche sur leur moteur de recherche prefere.

                ps: je devrais garder cette phrase comme signature tiens...

                • [^] # Re: sur mac

                  Posté par  . Évalué à 5.

                  Ah ouais cool on pourra mutualiser l'effort entre tous ceux qui veulent vérifier en s'aidant des indices autres que 3 mots clés qui trainent dans ta mémoire.

                  Ou pas.

                  (enfin je dis ça, j'en ai rien à carrer de si Apple a ou pas envisagé d'utiliser apt)

              • [^] # Re: sur mac

                Posté par  . Évalué à 2.

                Je sais pas si c'est amateur, mais il faut savoir que l'installation se passe de la même manière : tu colles le dossier de l'application (bon un bundle en fait) à peu près où tu veux (oui je sais il y a un dossier Applications).

                • [^] # Re: sur mac

                  Posté par  . Évalué à 3.

                  Dans ce cas, ça ne peut pas copier les bibliothèques partagées dans "/usr/lib", on est donc dans un système type Windows (désinstalleur en moins).
                  (Ne copier que le ".app" ne marche que pour des applications autonomes simples, si l'on veut faire des choses un peu plus compliquées, comme installer des extensions à d'autres programmes, s'enregistrer au démarrage, etc., il faut autre chose)

                  • [^] # Re: sur mac

                    Posté par  . Évalué à 2.

                    Il existe effectivement un système d'installation utilisé pour les "grosses applications" qui modifient le système et ont besoin du mot de passe admin.

                  • [^] # Re: sur mac

                    Posté par  . Évalué à 3.

                    Il y a aussi un système d’installeur sous OS X c’est au dev de l’application, de choisir s’il veut que l’installation de son appli ce fasse soit par un simple drag n’ drop, soit en empaquetant l’application, et en fournissant un installeur, qui pourrat aussi désinstaller son bordel. Mais il y a aussi certaines boîtes dont je tairais le nom, mais dont sigle en bourse est MSFT, dont les applications, au démarrage détectent si les Lib dont elles ont besoins sont présentes et font le nécessaire si ce n’est pas le cas.

                    Pour info mon dossier /Library/Frameworks fait 400Mo, et le dossier /System/Library/Frameworks fait 1,6Go sur une machine qui a été installée il y a 7 mois et contiens tout ce qu’il me faut pour bosser, et plus.

                    http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/PackageMakerUserGuide/Overview/Overview.html#//apple_ref/doc/uid/TP40005371-CH3-SW2

                    Depending on the time of day, the French go either way.

                    • [^] # Re: sur mac

                      Posté par  . Évalué à 1.

                      Il y a aussi un système d’installeur sous OS X c’est au dev de l’application, de choisir s’il veut que l’installation de son appli ce fasse soit par un simple drag n’ drop, soit en empaquetant l’application, et en fournissant un installeur, qui pourrat aussi désinstaller son bordel.

                      Alors, je repose les questions de mon précédent commentaire : comment sait-il si une bibliothèque partagée peut être désinstallée ?

                      • [^] # Re: sur mac

                        Posté par  (site web personnel) . Évalué à 2.

                        il ne le sait pas. De toute façon il n'y a pas de desinstalleur dans macos, le packagemaker permet de fabriquer des packages qui s'installent mais ne s'occupe absolument pas d'une eventuelle desinstallation.

  • # Klik

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    C'est ce que faisait Klik il y a des années, et c'était très pratique pour tester rapidement une application (surtout qu'elle était isolée)

    http://en.wikipedia.org/wiki/Klik_%28packaging_method%29
    http://kde-apps.org/content/show.php?content=12841

    Mais c'est mort de chez mort maintenant.

    • [^] # Applis portables

      Posté par  . Évalué à 3.

      Hors des considérations techniques, je crois qu'il y a une demande pour des applis portables, même si Klik, 0install ou même LSB n'ont jamais fonctionné.

      En tant qu'utilisateur, j'aimerais pouvoir ponctuellement tester certaines applications, pas forcément dans la version fournie par ma distribution (nouveau GIMP, nouveau Wesnoth, etc). En tant que développeur, je peux vouloir faciliter la vie à ceux qui veulent tester la nouvelle version de mon application. Idéalement je n'aurais rien à installer ou en tout cas ça reste dans mon /home.

      On parle ici d'utilisation ponctuelle, pour une catégorie d'applications souvent non critiques, et avec des permissions utilisateur. C'est différent du cas des applis courantes bien intégrées à la distribution. On peut se soucier moins de la sécurité et de la taille du programme. Bundle, binaire statique ou autre, idéalement cela utiliserait ses propres fichiers de configuration sans écrire sur les existants. Ça existe quelque chose du genre ?

      • [^] # Re: Applis portables

        Posté par  . Évalué à 3.

        Exactement - on est en 2011 et avec les gestionnaires de packages des distribs les plus courantes, on ne peut pas (facilement en tout cas, et à ma connaissance - merci de me corriger ):
        - choisir le répertoire d'installation (rpm permets de le faire je crois),
        - faire une installation dans son "home" sans être root
        - choisir d'installer en // plusieurs versions

        J'ai régler ce problème chez moi à grand coups de wget, configure, make et make install et je choisi la version que je veux avec Gnu modules - Mais avoir ca de base dans une distrib serai un plus....

        • [^] # Re: Applis portables

          Posté par  . Évalué à 3.

          faire une installation dans son "home" sans être root

          Si tu peux choisir le répertoire, comme tu le signal plus haut, tu peux installer dans ton home sans être root.

          choisir d'installer en // plusieurs versions

          J'ai déjà installé 2 version de firefox en parallèle. Dont une qui n'était qu'un repacktage de la version sur le site de FF qui s'installait dans /opt. Ce n'est juste pas supporté par les distributions à cause de l'effort supplémentaire à fournir.

          « 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: Applis portables

            Posté par  . Évalué à 1.

            Si tu peux choisir le répertoire, comme tu le signal plus haut, tu peux installer dans > > ton home sans être root.
            Tu es sur de ça ? Parce qu'il il a le problème de la base centrale des rpm/deb/... et les dépendances...

            • [^] # Re: Applis portables

              Posté par  . Évalué à 2.

              Tu es sur de ça ? Parce qu'il il a le problème de la base centrale des rpm/deb/... et les dépendances...

              Tu fais un chmod 777 sur la base rpm :) Et tu installe les dépendances une à une avec le préfix.

              « 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: Applis portables

            Posté par  (site web personnel) . Évalué à 2.

            Si tu peux choisir le répertoire, comme tu le signal plus haut, tu peux installer dans ton home sans être root.

            comment ?

            • [^] # Re: Applis portables

              Posté par  . Évalué à 3.

              L'option --dbpath permet d'utiliser une autre base de donnée que celle du système, mais alors tu perd la liste de tout ce qui est installé globalement et tu va devoir faire les installations à coup de --nodeps (ou mettre à jour à la main ta copie à partie de la DB centrale chaque fois qu'elle change, je ne sais pas si c'est possible).

        • [^] # Re: Applis portables

          Posté par  . Évalué à 3.

          http://www.gentoo.org/proj/en/gentoo-alt/prefix/ devrait t'intéresser pour les deux premiers, voire aussi le dernier avec son système de slots.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Klik

      Posté par  (site web personnel) . Évalué à 1.

      Les applications portables (sur clé usb) sous windows embarquent les librairies dont elles ont besoin.

      Des mecs ont décidé de lancer un système équivalent a portableapps et framakey pour Linux Portable Linux Apps

  • # Chakra

    Posté par  . Évalué à 4.

    Chakra propose quelque chose de ce type, et fait justement cohabiter ce type de packages avec les classiques.

    C'est une nouvelle distribution basee sur Archlinux, mais ayant pour but de fournir un environnement full Qt/KDE.
    Donc toutes les applications non Qt seront distribuees sous forme de bundles, bases sur les bundles MacOS. Les bundles sont des sortes de fichiers isos contenant tous les fichiers necessaires pour lancer l'application.

    Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

  • # RPATH - library path - $ORIGIN

    Posté par  . Évalué à 2.

    Tu peux compiler tes librairies et binaires de tel sortes que ceux-ci cherchent les libraires dans un repertoire relatif ...

    http://www.gamedev.net/page/resources/_/reference/programming/platform-specific/linux/linux-game-development-part-2-r2377

    (et oui, dans certains cas particulier c'est utile de distribuer les librairies en même temps que le programme (au boulot, systeme de controle de pilotage de bateau ... ))

    • [^] # Re: RPATH - library path - $ORIGIN

      Posté par  (site web personnel) . Évalué à 1.

      En effet, tu fais absolument ce que tu veux...

      Si ça te chante de construire une distribution en mixant paquets utilisant des librairies partagées et des application ayant ses libraries chez elle, c'est as you want !!!

      T'es libre de faire ton choix !

Suivre le flux des commentaires

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