Journal Marque page sur l'unification possible des systèmes Linux

Posté par  (site web personnel) . Licence CC By‑SA.
43
1
sept.
2014

Voici un simple marque page pour vous faire part d'un article de Lennart (en anglais) à propos de changements à venir qui pourrait changer profondément la gestions des applications sur Linux.

Je vous laisse lire l'article en détail (c'est un peu long).

  • # Wahou

    Posté par  . Évalué à 8.

    M'enfin, voilà encore un pavé dans la mare : une proposition d'hiérarchie des systèmes de fichiers qui permette d'atteindre le Graal :

    • des applications empaquetées pour toutes les distributions
    • plusieurs distributions linux utilisant les mêmes comptes utilisateurs

    Bien sûr, cela part d'un postulat à la Android/OsX : les applications viennent avec leur propres librairies, donc les trous de sécurité sont à combler appli par appli…

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

    • [^] # Re: Wahou

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

      Non, pas vraiment, c'est un "peu mieux", dans le sens que les applications vont dépendre d'un "runtime", qui contient à priori les "bibliothéques" de base. Mais contrairement à aujourd'hui où il n'y a qu'un "runtime", tu pourra en avoir n en parallèle (il suffit de jouer avec LD_LIBRARY_PATH ou RPATH ou ld.so.conf pour faire la même chose aujourd'hui).

      • [^] # Re: Wahou

        Posté par  . Évalué à 9.

        Je ne vois pas la révolution, ni le pavé dans la marre, par rapport à 0install qui n’a jamais vraiment décollé. Ça utilise systemd et BTRFS donc c’est forcément mieux, mais à part ça ?

        • [^] # Re: Wahou

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

          La solution proposée semble plus générique, puisque tu peux te retrouver avec plusieurs versions de ton /usr, et même avec ton /home (tout l'avantage des sous-volumes de Btrfs).

          Mais l'idée semble aussi de le faire fonctionner avec ext4/xfs.

          Bref, on va se retrouver avec une autre manière de faire, et on verra bien si elle décolle, puisque c'est bien le plus important. Une solution qui ne décolle pas, c'est une solution ratée.

          • [^] # Re: Wahou

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

            Une solution qui ne décolle pas, c'est une solution ratée.

            Ça dépend, si tu l'imposes… (koff koff… systemd… koff koff)</troll>

            • [^] # Re: Wahou

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

              Ça dépend, si tu l'imposes… (koff koff… systemd… koff koff)

              Tu rigoles, mais la plupart du temps, c'est comme cela que ça marche. Par exemple, Apple a imposé l'Iphone comme téléphone de référence en 2007. Et encore aujourd'hui, beaucoup de personnes se référent à l'Iphone pour parler de téléphone, alors que de nombreux autres existent sur le marché.

        • [^] # Re: Wahou

          Posté par  . Évalué à 5.

          À part ça systemd a lui vraiment décollé. Comme il sera avec le temps de plus en plus difficile de s'en passer, il imposera sa méthode là où 0install proposait la sienne.

          Ça va foutre des mainteneurs de paquets au chômage, ça.

          • [^] # Re: Wahou

            Posté par  . Évalué à 10.

            Ça va foutre des mainteneurs de paquets au chômage, ça.

            C'est ce que se disait IBM avec System/370 - compatibilité maximale avec l'existant (System/360) et prise en compte bas niveau des hiérarchies pour éviter les émulateurs à la con et les compilations depuis les sources.
            Ah, la terminologie "System 370 compatible" - si vous avez un dino sous la main, demandez-lui de vous raconter. C'est drôle…

            C'est ce que c'est dit Multics, avec ses répertoires fixes et son unique langage de programmation PL/I. Le bas niveau (gestion I/O et mémoire) étant écrit en assembleur et ne devant jamais être accessible à qui que ce soit autre que les fabriquants. Unix ne serait pas ce qu'il est sans toutes les erreurs de Multics.

            Netware/ZenWorks est un bel exemple de truc qui aurait vraiment pu marcher. Quel dommage que les protocoles routables aient gagnés la guerre. Au moment ou Novell s'est réveillé et a commencé à rendre leur protocole routable (au début avec du tunneling) ben il y avait plus personne.

            Dans le genre il y en a eu un paquet d'autres… Qui ont fini par se vautrer aussi, il faut croire que l'informatique n'aime pas les carcans et les structures rigides.

            Ceci dit j'ai toute confiance en Lennart pour réussir avec brio là ou IBM, Digital, le MIT, Novell et tant d'autres ont échoués, mais bon si j'étais mainteneur de paquet je commencerai pas ma reconversion immédiatement quand même.

          • [^] # Re: Wahou

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

            Ça va foutre des mainteneurs de paquets au chômage, ça.

            Extrait :

            Also note that this in no way a departure from packaging systems like RPM or DEB. Even if the new scheme we propose is used for installing and updating a specific system, it is RPM/DEB that is used to put together the vendor OS tree initially. Hence, even in this scheme RPM/DEB are highly relevant, though not strictly as an end-user tool anymore, but as a build tool.

          • [^] # Re: Wahou

            Posté par  . Évalué à 10.

            Ça va foutre des mainteneurs de paquets au chômage, ça.

            T'inquiète, il restera toujours des projets upstream avec des licences foireuses, des bugs dans tous les sens, des bibliothèques mal ou pas gérées, pas de gestion de qualité (tests, etc.).

            Bref, le plus gros travail de mainteneurs de paquet n'est pas de faire le paquet. C'est de le faire bien, et le gérer dans la distribution.

  • # Une anecdote en passant

    Posté par  . Évalué à 10.

    Une petite anecdote sur la gestion des executables sous Linux/Unix, j’ai travaillé pour un gros projet de recherche en physique. Il s’avère que c’était plus simple d’écrire notre propre gestionnaire de paquet (en Python) que de tenter de fournir des paquets pour toutes les distributions des utilisateurs du code (surtout quand une fraction de ces user n’a pas le mot de passe du root)
    Le principe est simple, un script python va télécharger les diverses dépendances (sur nos propre dépots) les compilers (avec les options qui vont bien) et regler LD_LIBRARY_PATH et PATH comme il faut pour que les dépendances suivantes les aie etc… Il suffit ensuite de sourcer un ficher sh/csh pour avoir le bon environnement pour trouver toute les dépendances. Et ca a été un gros gain de temps pour installer/mettre à jours l’environnement logiciel par rapport à ce que c’était avant

    • [^] # Re: Une anecdote en passant

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

      <HS>
      C'est possible de savoir où c'était ?

      J'ai été presta au CEA et j'ai codé un outil python qui faisait globalement ce que tu décris (et un peu plus).

      Soit on parle du même outil, soit chacun refait ses trucs dans son coin.
      <\HS>

      Matthieu Gautier|irc:starmad

    • [^] # Re: Une anecdote en passant

      Posté par  . Évalué à 5.

      Ce n'était pas plus simple de faire un paquet pour 0install ?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Une anecdote en passant

      Posté par  . Évalué à 10.

      Le principe est simple, un script python va télécharger les diverses dépendances (sur nos propre dépots) les compilers (avec les options qui vont bien) et regler LD_LIBRARY_PATH et PATH comme il faut pour que les dépendances suivantes les aie etc… Il suffit ensuite de sourcer un ficher sh/csh pour avoir le bon environnement pour trouver toute les dépendances.

      Note qu'aujourd'hui, Conda et Binstar automatisent tout ça :
      http://conda.pydata.org/
      https://binstar.org/

      Conda est l'outil qui crée et installe les paquets, Binstar est un service permettant d'héberger tes propres paquets… Conda vient aussi avec des dépôts standard gérés par Continuum, avec pas mal de paquets autour de Python et du calcul scientifique.

      (disclaimer : Continuum est l'entreprise pour laquelle je travaille)

    • [^] # Re: Une anecdote en passant

      Posté par  . Évalué à 3. Dernière modification le 01 septembre 2014 à 20:09.

      LD_LIBRARY_PATH c'est bien si ton programme n'appel pas de programme en dehors de ton package, autrement l'env sera propagé.
      Le mieux que j'ai trouve c'est de faire un wrapper qui appel le linker dynamique de ton package

      Par exemple:

      /myroot/lib/ld-2.17.so --library-path /myroot/lib:/myroot/usr/lib /myroot/bin/myprogram
      Reste le problème des autres variables d'env qu'il faut définir pour les bibliothèque que tu utilises dans ton package

  • # btrfs

    Posté par  . Évalué à 2.

    The scheme we propose is built around the variety of concepts of btrfs and Linux file system name-spacing. btrfs at this point already has a large number of features that fit neatly in our concept, and the maintainers are busy working on a couple of others we want to eventually make use of.

    On va devoir tous passer sur brtfs si on utilise systemd ?

    I originally intended to discuss this at the Linux Plumbers Conference (which I assumed was the right forum for this kind of major plumbing level improvement), and at linux.conf.au, but there was no interest in my session submissions there…

    • [^] # Re: btrfs

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

      Oui, ce qui m'étonne, c'est que pour un problème de l'espace utilisateur, on propose une solution du noyau. Parce que là, ça revient à se lier à un système de fichier, c'est très embêtant. Je pense qu'on pourrait faire le même genre de chose avec git, sans souci (une branche par config) puisque git a été conçu au départ par Linus comme un système de fichiers.

      • [^] # Re: btrfs

        Posté par  . Évalué à 3. Dernière modification le 01 septembre 2014 à 19:58.

        Je pense qu'on pourrait faire le même genre de chose avec git, sans souci (une branche par config) puisque git a été conçu au départ par Linus comme un système de fichiers.

        git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.

        Ce projet semble aller exactement dans le même sens que "Fedora-Next".

        • [^] # Re: btrfs

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

          git ne propose pas la déduplication des données (enfin je ne pense pas), fonction assez importante ici.

          Si, et heureusement : un gestionnaire de versions qui copierait intégralement chaque version gaspillerait pas mal de place. Dans ses concepts de base, Git peut être vu comme gardant chaque version intégralement, mais s'y ajoute une couche de déduplication, même interne aux fichiers.

          • [^] # Re: btrfs

            Posté par  . Évalué à 2.

            La déduplication interne ne marche que pour le texte ou ça s'applique aussi aux données binaires?

            • [^] # Re: btrfs

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

              À mon avis, uniquement au texte, mais je n'en suis absolument pas sûr : à vérifier.

              • [^] # Re: btrfs

                Posté par  . Évalué à 3.

                Si deux binaires sont strictement identiques, la déduplication a forcément lieu puisque git adresse les objets par leur hash.

                Par contre je peux pas dire si il est très efficace en cas de petite différence.

                • [^] # Re: btrfs

                  Posté par  . Évalué à -2.

                  git est une grosse merde ambulante pour la gestion des binaires. D'ou la naissance de projet tel que git annex.

            • [^] # Re: btrfs

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

          • [^] # Re: btrfs

            Posté par  . Évalué à 3.

            Oui, via un système de diff. BTRFS fonctionne différemment. Il est capable de repérer (au prix d'une consommation mémoire extravagante de l'ordre de 3Go par To) les blocs identiques au niveau système de fichier et est donc capable de retrouver les blocs identiques entre des fichiers qui ne sont pas liés du tout, ce que ne peut faire git. Après, je ne connais pas le détail de fonctionnement des deux outils, mais j'imagine que par contre ZFS ne serait pas capable de factoriser deux fichiers dont l'un des deux a un offset de quelques octets par rapport à l'autre.

            • [^] # Re: btrfs

              Posté par  . Évalué à 5.

              Oulah, il est tout pourri mon commentaire oO'. Ce qui est écrit ne s'applique qu'à ZFS, pas à BTRFS.

              Par contre la deduplication sur BTRFS a l'air de se chercher pour le moment, entre les bedup dedup, les truc inband et le reste …

      • [^] # Re: btrfs

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

        Je pense qu'on pourrait faire le même genre de chose avec git

        Git pour des binaires ? Vraiment ?

        De plus, tu fais comment pour qu'une application utilise les libs d'une branche quand, en même temps, une autre application utilise une lib d'une autre branche ?

    • [^] # Re: btrfs

      Posté par  . Évalué à 7.

      On va devoir tous passer sur brtfs si on utilise systemd ?

      Ben non.

      There's no need to fully move to a system that uses only btrfs and follows strictly this sub-volume scheme. For example, we intend to provide implicit support for systems that are installed on ext4 or xfs, or that are put together with traditional packaging tools such as RPM or dpkg: if the the user tries to install a runtime/app/framework/os image on a system that doesn't use btrfs so far, it can just create a loop-back btrfs image in /var, and push the data into that. Even us developers will run our stuff like this for a while, after all this new scheme is not particularly useful for highly individualized systems, and we developers usually tend to run systems like that.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: btrfs

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

        Ben non.

        Ouais, on dit ça maintenant, mais j'attends de voir. Avec Lennart, je me méfie. (Mais si, je vous assure, je ne fait que maintenir udev dans le même dépôt que systemd mais ça restera tout à fait indépendant, je vous jure. Mais bien sûr, et maintenant ?)

        • [^] # Re: btrfs

          Posté par  . Évalué à 1.

          A-t-il jamais promis cela?

          Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: btrfs

        Posté par  . Évalué à 3.

        De toute façon il peut pas prétendre supporter les systèmes embarqués avec brtfs vu que pas mal d'entre eux ont de la flash sans FTL qui ont besoin de FS spécialisés comme ubifs ou yaffs2 pour éviter que la flash crame dans l'heure.

        • [^] # Re: btrfs

          Posté par  . Évalué à 1.

          Il me semblait que btrfs est adapté à la nand.

  • # vers la "privatisation" du système

    Posté par  . Évalué à -10.

    Au fur et à mesure que l'on empile surcouche sur surcouche, que l'on complexifie la chose pour "arranger tout le monde, que l'on choisit des solutions techniques peut être meilleures mais qui ont besoin de plus de concepts pour être compris, on s'éloigne du libre.

    Ce n'est pas libre parce que c'est gratuit, c'est libre parce que le commun des mortels peut avec un peu de travail et de volonté entrer dans le coeur et comprendre (chacun à son niveau). Bien sur, celui qui a choisi ubuntu aura du mal avec debian ou slack ou fedora ou gentoo ou suse ou … mais dans l'ensemble il fera vivre l'écosystème.

    Demain si on veut unifier tout en complexifiant les concepts, seuls les "ingénieurs" arriveront à comprendre et le libre sera privatisé, au main d'une poignée.. avec peut être des utilisateurs (si c'est gratuit) et la base des contributeurs potentielles se restreindra et les 1% deviendront peut être 5%, mais à quel prix.. celui d'utilisateurs qui seront comme sous windows, incapable de résoudre un soucis si ils n'arrivent pas à télécharger l'utilitaire merdique qui installera en même temps une extension firefox que les gens ne sauront pas désintaller car la fonctionnalité sera trop profondément enfouie dans les sous menus.

    Alors je peux bien comprendre que cet avenir est un avenir radieux pour les grosses boites comme canonical ou red hat mais pour l'utilisateur de base… pourquoi se faire chier avec un truc différent, qui aura toujours les même problèmes avec les pilotes, avec le matériel, et qui en plus aura les même inconvénient que windows : uniforme, incompréhensible, hors de porté.

    Demain les virus et autre saloperies windowsienne n'auront même plus à s'embêter au niveau compatibilité entre les machines, on leur offre un autoroute de compatibilité, c'est cool…

    • [^] # Re: vers la "privatisation" du système

      Posté par  . Évalué à 7.

      Si tu t'intéressais au lieu de râler, yaurais plus de gens pour comprendre le système.

      Pasque franchement, c'est pas si compliqué. Et je trouve que c'est moins compliqué que les ignobles montagnes de shell qu'y avait avant (oui je viens de me plonger dans le code de debian-installer et c'est juste un gros traumatisme)

      • [^] # Re: vers la "privatisation" du système

        Posté par  . Évalué à -10.

        Oui mais bon, le gros du probléme c'est qu'on s'éloigne d'une façon radical de la phylosophie d'Unix "Un outils fait une chose et il le fait bien". Perso systemd je suis pas fan, je connais pas vraiment, mais je suis pas fan, tu te rends compte que pendant un moment il était aussi question que systemd gére le DNS et le ntp !! wtf.

        Bordel, pour gagner 10 seconde au démarrage que de changements, c'est ridicule.
        Mea culpa je n'ai pas lue l'article en question dans ce journal.

        Allez tous vous faire spéculer.

        • [^] # Re: vers la "privatisation" du système

          Posté par  . Évalué à 10.

          Wep donc nan, faut arrêter avec ça aussi.

          Bordel de marde, systemd ne gère pas le dns et le ntp. Le projet systemd fournit des outils qui les gèrent, mais ça n'est absolument pas dans l'init systemd, et ce sont des outils totalement optionnels.

          Sinon, c'est comme si tu disais « ZOMG, OpenBSD gère SMTP ! On est loin de la philosophie Unix "Un outils fait une chose et il le fait bien" » à cause de OpenSMTPd sans vouloir comprendre que le projet OpenBSD n'est pas le noyau OpenBSD.

    • [^] # Re: vers la "privatisation" du système

      Posté par  . Évalué à 9. Dernière modification le 01 septembre 2014 à 23:18.

      Heu… Désolé, mais non.

      Le kernel Linux n'est sans doute pas la chose à laquelle il est techniquement le plus facile de contribuer. Je dois en conclure qu'il n'est pas libre ? La liberté d'un logiciel, c'est une question de licence, pas de complexité plus ou moins grande du code concerné.

      Ce que tu semble déplorer, c'est que les distributions Linux adoptant ce genre de technos deviennent de moins en moins « KISS ». Peut-être. Les technos en question n'en sont pas moins libres et documentées.

      Quant à l'utilisateur souhaitant contribuer, je pense qu'il considérera que pouvoir distribuer simplement son logiciel est un plus, pas une régression. Et pour celui s'intéressant au basses couches du système, je ne doute pas qu'il saura s'adapter.

      • [^] # Re: vers la "privatisation" du système

        Posté par  . Évalué à 10.

        Le kernel Linux n'est sans doute pas la chose à laquelle il est techniquement le plus facile de contribuer.

        Mauvais exemple, il est très très facile de contribuer au kernel en temps que débutant. Le nombre d'aspects même fondamentaux du kernel qui ont été chamboulés par un étudiant universitaire première année (notamment gestion mémoire, priorisation des processus, ordonnancement etc.) est considérable. J'étais en première année, avec moins de 6 mois de C dans les pattes quand j'ai participé au module smbfs, pendant qu'un autre étudiant pas meilleur que moi écrivait un pilote pour la prise en charge du retour de force sous Linux.

        Si tu as un sujet qui intéresse, même si tu est nul en C, tu vas avoir pleins de contributeurs qui vont te prendre par la main et t'aider à mener ton truc à terme.

        Bon sur certains sujets tu te fais allumer (genre changer le code des VT), mais en général le kernel Linux c'est plutôt sympa, même avec les newbies. Honnêtement c'est beaucoup plus facile d'aller dans le Kernel pour écrire un petit module rigolo que d'aller sur la glibc, DBus ou tout un tas de truc Gnome… (Et Xfree a "disparu", mais la il fallait avoir le cuir du dos bien tanné pour rentrer.)

        La liberté d'un logiciel, c'est une techniquement question de licence, pas de complexité plus ou moins grande du code concerné.

        Ça se discute, la liberté c'est surtout la capacité technique et légale de pouvoir adapter un logiciel à ses besoins. La capacité technique peut toujours s’acquérir en signant un gros chèque si besoin est. Enfin elle pouvait avant systemd. Si systemd rigidifie encore l'OS il n'y aura bientôt plus moyen de passer outre sans créer de toute pièce une nouvelle distrib et en la maintenant. Ça fait un vraiment gros chèque là quand même. Techniquement Linux en tant qu'OS sera toujours libre, mais si il devient impossible d'utiliser cette liberté on aura quand même perdu quelque chose. En théorie je suis libre de marcher sur la planète Mars, en pratique ça me fait une belle jambe.

        Peut-être. Les technos en question n'en sont pas moins libres et documentées.

        Documentées il faut le dire vite. Au niveau interface déjà c'est loin d'être évident, pour systemd sur les scopes et les environnements j'en ai soupé avant que la doc ne soit claire et à jour. Pour tout un tas de trucs genre journald, même si on nous explique comment s'en servir, bien malin qui est capable de dire comment ca fonctionne aujourd'hui - et même Lennart ne doit pas savoir comment ca fonctionnera dans six mois.
        Par contre coté mécanique, les entrailles de la bête sont en constante évolution. C'est tous les jours une surprise. Un jour on fait un hold-up sur les cgroups, le lendemain on rajoute un démon NTP - tiens on a encore changé le format interne de networkd etc. La roadmap de systemd ressemble à un mauvais trip sous acide, j'aimerai vraiment pas avoir besoin de faire un dev spécifique pour cet init (vous savez le genre de trucs pour faire fonctionner une interface ou un périph très peu utilisé au sein de la communauté systemd…)

        Et pour celui s'intéressant au basses couches du système, je ne doute pas qu'il saura s'adapter.

        Ben écoute personellement, étant quelqu'un pour qui les couches basses du systèmes sont à la fois mon gagne pain, mon domaine d'expertise et ma passion - je ne te cacherai pas que j'ai des doutes. Je passe autant de temps que possible sur systemd (c'est à dire environ 10h par mois, j'ai une prod à faire tourner, d'autres trucs à surveiller et une vie sociale déjà bien assez maigre) et j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.

        • [^] # Re: vers la "privatisation" du système

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

          j'ai plus l'impression de me faire distancer par systemd que d'apprendre à le maitriser.

          Ah, moi j'ai surtout l'impression d'attendre avec impatience d'avoir systemd sur le prod parce que avec lui, j'aurais peut être plus d'information quand un service reste bloqué sur un /etc/init.d/service start … Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…

          • [^] # Re: vers la "privatisation" du système

            Posté par  . Évalué à 4.

            Et surtout avec systemd, ça bloquera pas la fin du boot de l'OS…

            Autant les logs activé dès les premières phases du boot je suis assez fan, autant ça fait longtemps que le plantage/le freeze d'un daemon au démarrage ne bloque plus le boot à moins qu'il ne soit strictement nécessaire (c'est clair que si lo plante, ou si le FS échoue le montage en RW c'est foutu - mais c'est le cas pour tout le monde.)

            L'immense majorité de systèmes d'init de nos jours font du démarrage parallèle et sont capables d'envoyer des SIGTERM/SIGKILL à un daemon qui reste bloqué. Ca fait des années que tous les BSD ont ce type de système, et même sous Debian (pourtant gros partisans du SysV init jusque très récemment) depuis Wheezy on a tout ce qu'il faut.

            • [^] # Re: vers la "privatisation" du système

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

              Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…

              Je rien vu dans les logs, pas eu le temps de chercher…

              • [^] # Re: vers la "privatisation" du système

                Posté par  . Évalué à 5.

                Et pourtant, j'ai retrouvé hier un serveur Debian bloqué sur /etc/init.d/opsview start et ssh n'était pas démarré…

                Attention, le fait qu'il soit possible d'écrire des scripts propres ne veut pas dire que tous les scripts sont propres.
                Même sous systemd si je suis assez bête pour créer un service qui fait "while 1" avec un timeout à 0 et que je rend tout mon boot dépendant strictement de la fin de l’exécution de ce service - ben mon boot va figer.

                Pour freezer le boot d'un systemd il faut y aller, alors que sous les inits classiques il faut faire attention pour éviter toute possibilité de freeze. C'est un plus de systemd (mais qui a un prix au niveau logs/processus/mémoire) mais clairement pas une exclusivité.

                Ceci dit quand on commence à définir des scopes et des slices à la mano, on a vite fait de faire des boots qui freezent. (Peu de gens joueront à ce jeu. Certes)

    • [^] # Re: vers la "privatisation" du système

      Posté par  . Évalué à 4.

      Exactement. Quand j'étais passé de DOS/Windows à Linux, c'était parce que j'avais plaisir d'une part à voir ce qui était sous le capot au lieu d'avoir affaire à un truc mystérieux/aléatoire et à pouvoir éventuellement le contrôler/configurer et d'autre part à pouvoir à comprendre rapidement des parties importantes en lisant leur code. Accessible, compréhensible, démystificateur.

      Maintenant, le code est bien sûr toujours libre, mais vais-je étudier les millions de lignes de code du noyau, les millions de lignes d'un navigateur, les dizaines de millions de ligne d'un bureau, les dizaines de milliers de ligne de C++ cryptique d'un projet qui appelle la libfoo qui elle appelle la libbar qui elle appelle la libtoto ?
      Eh bien non, je n'utilise quasiment plus Linux que comme si c'était un Windows, et ceci alors qu'en tant que vieux con, je me prive pourtant d'un certain nombre de surcouches dites « modernes » qui singent Windows/OS X pour être Michu-compatibles.

      Quand tu écrivais « en complexifiant les concepts, seuls les "ingénieurs" arriveront à comprendre », tu aurais pu ajouter « … comprendre la partie sur laquelle ils se sont spécialisés », car la complexification devient telle que personne ne peut s'intéresser à beaucoup de parties. À part peut-être le génie hanséatique, Dieu nous préserve.

      • [^] # Re: vers la "privatisation" du système

        Posté par  . Évalué à 10.

        Ouais, on devrait freezer tous les projets libres.
        Hors de question d'avancer si gnx n'est pas capable de comprendre le source code.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: vers la "privatisation" du système

          Posté par  . Évalué à 5.

          Il y a une "petite" différence entre freezer des projets, garder une compatibilité des libs pendant 15 ans et de simplement tout chambouler, parce que tu as les moyens de payer, pour "unifier".

          Il me semble que ceux qui râlent le plus sur le manque d'uniformisation sont ceux qui n'utilisent pas. Maintenant vous pensez que changer les fera venir ? ils continueront à trouver autre chose. C'est un truc que j'ai appris au cours de mon existence : les gens ont des objections pour ne pas faire une chose. Ces objections sont des "excuses" pour ne pas faire, et très rarement des causes. Si tu changes pour leur faire plaisir, tu perds une partie de ceux que tu as, et tu ne gagnes pas ceux qui avaient ces objections : ils en trouvent d'autre.

          J'ai la bêtise de penser que les modifications, sont, comme en médecine, un équilibre entre bénéfice/risque. Maintenant si cela va à tout le monde, parfait, mais je peux dire que j'ai vu la communauté évoluer au cours des 10 dernières années, et la notion de liberté se pastélliser au profit de la notion d'efficacité, au profit de l'uniformisation soit disant nécessaire (mais pour qui ?).

          Oui le code est toujours libre, mais ce n'est pas la question. D'ailleurs le code doit être commenté en anglais avec des noms de variables en anglais aussi, pourquoi pas en coréen ? ou en chinois ? il resterait tout aussi libre, mais peut être moins accessible.

          Maintenant ce que l'on voit surtout ce sont les gens s'écharper parce qu'ils sont convaincu de leur vérité, qui sont condescendants en diable. Ils ne peuvent même pas imaginer que dans le discours de l'autre il y a une piste de réflexion intéressante, c'est tellement simple de basher.

          tiens : ouais pas la peine de discuter tant que groumly ne comprendra pas de quoi on parle.
          ou : on peut faire ce que l'on veut parce que groumly y voit pas ce que cela implique.

          • [^] # Re: vers la "privatisation" du système

            Posté par  . Évalué à 3.

            D'ailleurs le code doit être commenté en anglais avec des noms de variables en anglais aussi, pourquoi pas en coréen ? ou en chinois ?

            En espéranto! → […]

            Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: vers la "privatisation" du système

        Posté par  . Évalué à 1.

        C'est marrant, c'est le contraire pour moi.

        Je maitrisais à fond mon système MS-DOS (les arcanes d'autoexec.bat et de config.sys pour maximiser la mémoire conventionnelle requise par les jeux gourmands n'avaient plus de secrets pour moi).
        Je maîtrisais tout bien mon Windows 3.1.

        Ensuite j'ai plus rien maîtrisé du tout avec Windows 95 et pis les Linux que j'ai eu ensuite et qui étaient d'une complexité effarante (dès 1997 !). Plus ça va, plus c'est pire, aujourd'hui quand tout ne marche pas en plug&play sous Linux, c'est l'enfer à réparer/bidouiller sans maîtriser des zilliards de composants systèmes.

        J'ai fait mon deuil de la compréhension des OS modernes; en choisissant ceux qui "juste marchent" (BeOS, Mac OS X, …), il n'y a plus trop de questions à se poser.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: vers la "privatisation" du système

          Posté par  . Évalué à 10.

          J'ai fait mon deuil de la compréhension des OS modernes; en choisissant ceux qui "juste marchent" (BeOS, Mac OS X, …), il n'y a plus trop de questions à se poser.

          T'es sûr que ce n'est pas simplement l'envie de bidouiller qui décroit avec l'age ? Perso, je pense que c'est mon cas.

          Je n'ai pas franchement l'impression que mon système actuel soit plus compliqué à bidouiller que la RedHat 5.2 que j'installais dans ma jeunesse (je me trompe peut-être), mais je sais que j'ai moins envie de le bidouiller parce que :
          1 - Ça m'amuse moins ;
          2 - Ça merde moins, donc j'ai moins besoin de le faire.

          • [^] # Re: vers la "privatisation" du système

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

            2 - Ça merde moins, donc j'ai moins besoin de le faire.

            Je pense d'ailleurs que c'est pour cela que nous sommes nombreux sous ArchLinux, histoire de donner plus de chance à l'action… Et encore, c'est assez rare…

          • [^] # Re: vers la "privatisation" du système

            Posté par  . Évalué à 5.

            Oui, tout à fait.

            J'ai un pote qui en a eu marre de "bidouiller" lui aussi mais qui a eu envie de mettre les mains dans le cambouis quand même. Il est passé sur OpenBSD, un système qui se veut "simple" dans le sens ou quelqu'un qui veut ouvrir le capot peut arriver à comprendre comment fonctionne le système avec des efforts raisonnables.

            C'est plutôt les incantations vaudou pour faire marcher Windows et les lignes de commande à copier/coller sans les comprendre des forums linuxiens pour tenter de faire marcher un truc qui ne marchera de toute façon pas qui m'ont fatigué.

            BeOS le faisait il y a 20 ans !

    • [^] # Re: vers la "privatisation" du système

      Posté par  . Évalué à 7.

      Félicitations ! Tu es mûr pour essayer OpenBSD :)

      BeOS le faisait il y a 20 ans !

    • [^] # Re: vers la "privatisation" du système

      Posté par  . Évalué à 2.

      Trop gros, passera pas.

  • # Enfin

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

    C'est vraiment bien de voir une initiative pour faire évoluer la distribution des applications sur les distributions. Le modèle actuel fonctionne bien pour certains cas d'utilisation mais il échoue à adresser certains besoins basiques comme par exemple pouvoir utiliser une version spécifique d'un logiciel ou même d'en avoir plusieurs d'installées.

    En tant que développeur 'upstream' mon principal reproche que je fais au système de packaging actuel c'est qu'on se retrouve coupé des utilisateurs. Impossible de dire quand ton application sera disponible sur telle distro. Tu te retrouves souvent avec des utilisateurs qui ont plusieurs années de retard sur la version de ton soft tu coup tu perds la dynamique sur les retours de bugs.

    La proposition de Lennart me semble excellente car il résout une équation délicate, garder ce qui est bien dans le modèle actuel des distributions tout en ouvrant de nouvelles possibilités.

    • [^] # Re: Enfin

      Posté par  . Évalué à 5.

      C'est vrai en partie, maintenant peut être que tu devras gérer en plus les problématiques d'effets de bords avec ta dernière applis qui merdera sur certaines machines ,parce que les libs systèmes sont un peu différentes et en conflit avec ta version des lib et avec des appels croisés. (en ce cas, autant faire des paquets statiques.)

      Le truc avec les distributions c'est que l'écosystème est plus ou moins testé et cohérent. tu tires des packages pour TA version, compilés avec les bonnes libs. C'est vrai que si tu as 4 versions de distro de retards tu auras un très vieux soft. Mais qu'est-ce qui se passera avec ce système si tu as 4 versions de distro de retard ? la libc sera plus la bonne et sera plus compatible ascendante avec celle qui a servi à compiler, donc paff pastèque.

      Le problème de fond de la non compatbilité c'est plus les versions de lib que l'arborescence (un targz compilé statique avec un script pour les ld_preload) et ca marche pour tout. Alors oui, on peut embarquer toutes ses versions de libs en compilant statique et ca marche SAUF pour les libc trop vielle.

      Maintenant attendons le résultat, mais je ne suis pas persuadé que ca aide les empaqueteurs. Tu devras juste te démerder pour faire ton paquet miracle et prier pour que ca merde pas. Et si ca merde sur un environnement quelconque, tu seras bien seul pour comprendre pourquoi ca ne marche pas dans un environnement que tu ne connais pas et que l'utilisateur connaîtra encore moins.

      Les paquets spécifiques aux distros ca permet à ceux qui les font de bien connaître ce qui se passe.

      • [^] # Re: Enfin

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

        Et si ca merde sur un environnement quelconque, tu seras bien seul pour comprendre pourquoi ca ne marche pas dans un environnement que tu ne connais pas et que l'utilisateur connaîtra encore moins.

        Vis à vis d'un développeur upstream c'est la situation actuelle. Ton appli est packagé pour chaque distros avec un ensemble et une combinaison de librairie que tu n'a jamais testé. Tu peux avoir fais des efforts pour valider ton appli avec une combinaison de dépendance mais il y a peu de chance que la distro fasse les mêmes choix.

        Concernant les problèmes de libc multiples, si tu regardes bien la proposition de Lennart c'est supporté : "Note that in this design apps are actually developed against a single, very specific runtime, that contains all libraries it can link against (including a specific glibc version!). Any library that is not included in the runtime the developer picked must be included in the app itself."

  • # et la sécurité ?

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

    Coté utilisateur, c'est cool, on peut installer des soft sans attendre que ces faignants d'administrateur s'occupent de nous :).

    Coté administrateur, comment on maintient une machine à jour des correctifs de failles de sécurité ?

    • [^] # Re: et la sécurité ?

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

      Coté administrateur, comment on maintient une machine à jour des correctifs de failles de sécurité ?

      D'après ce que j'ai compris, il te suffira de télécharger le nouveau "bundle" et de redémarrer le "container". Et tout devrait fonctionner comme si de rien n'était.

      • [^] # Re: et la sécurité ?

        Posté par  . Évalué à 8.

        En gros, c'est de la security by Appstore, autant dire qu'il n'y en a pas. (que le premier développeur upstream qui s'abonne aux mailings lists de toutes ses dépendances pour suivre les failles de sécurité et les applique rapidement me jette la première bière).

        « 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: et la sécurité ?

          Posté par  . Évalué à 3.

          C'est pas que j'ai confiance dans les AppStores, mais s'il est "trop dur" de rester à jour au niveau des correctifs de sécurité, les solutions techniques pour améliorer la sécurité tout de même ne sont pas inexistantes :

          They want their software quickly, and the fine distinction between trusting a single distribution or a myriad of app developers individually is usually not important for them. The companies behind the marketplaces usually try to improve this trust problem by providing sand-boxing technologies: as a replacement for the distribution that audits, vets, builds and packages the software and thus allows users to trust it to a certain level, these vendors try to find technical solutions to ensure that the software they offer for download can't be malicious.

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: et la sécurité ?

            Posté par  . Évalué à 4.

            Une sandbox, c'est bien pour ton système, pas du tout pour ton appli. Ça veut quand même dire que si c'est ton client mail qui se fait toucher, toutes les adresses récentes peuvent se faire spammer. Si c'est ton navigateur, n'en parlons pas.

            « 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: et la sécurité ?

              Posté par  . Évalué à 3.

              On a vu à quel point le mythe de "code relu par tout le monde" a vécu avec OpenSSL. Faire une vraie relecture du code (ou pas, d'ailleurs…) n'empêche pas d'utiliser des solutions techniques (sandbox, secure boot, binaires signés numériquement, capabilities par application, …) visant à améliorer vraiment la sécurité.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: et la sécurité ?

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

                On a vu à quel point le mythe de "code relu par tout le monde" a vécu avec OpenSSL.

                Je m'intérroge sur le sens de cette phrase …
                Je vois 2 solutions :

                • un mec à relu le code d'OpenSSL et a trouvé une faille, donc la relecture du code est dangereux parce qu'on peut trouver des failles ;
                • un mec à relu le code d'OpenSSL et à trouve une faille, donc cela montre que la relecture n'est pas efficace pour trouver les failles (hu?)
                • [^] # Re: et la sécurité ?

                  Posté par  . Évalué à 3.

                  Ahah, très drôle. Sauf que c'est à côté de la plaque.

                  Il l'a relu après que la faille soit dans la nature depuis des années, exploitée, et exploitable.

                  Normalement, le but de la relecture de code, c'est d'éviter les failles. Pas de les découvrir après que le code ait été écrit et déployé en faisant "oops!".

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: et la sécurité ?

                    Posté par  . Évalué à 4.

                    Normalement, le but de la relecture de code, c'est d'éviter les failles. Pas de les découvrir après que le code ait été écrit et déployé en faisant "oops!".

                    Rien est jamais garantie en terme de qualité logiciel. Celui qui te dis que le fait de faire de la relecture, d'utiliser tel langage, tel analyseur statique ou autre donne la garantie de ne pas avoir de faille est un bouffon. De même pour le sandboxing par exemple. Java et javascript ont des modes de sandboxe qui ont eu leur jolie CVE exploitables et exploitées.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: et la sécurité ?

                      Posté par  . Évalué à 1.

                      Et c'est pour ça que le mythe de la relecture linuxien/LL : "c'est du code relu par tout le monde, donc de qualité" c'est pour les gogos.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: et la sécurité ?

                        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 03 septembre 2014 à 22:46.

                        Et c'est pour ça que le mythe de la relecture linuxien/LL : "c'est du code relu par tout le monde, donc de qualité" c'est pour les gogos.

                        au moins le code libre le permet, c'est toujours mieux^Wplus crédible qu'un Microsoft qui tente de se faire passer pour un chantre de la sécurité (sans doute que tellement attaqué^Wtroué auparavant, il ne peut pas faire autrement… ne pas me lancer sur java :p).

              • [^] # Re: et la sécurité ?

                Posté par  . Évalué à 3.

                Je n'ai jamais dit qu'une sandbox était un mauvais point mais que ça n'améliorait pas la sécurité de l'application pour elle-même (sauf si elle fait des sandbox internes mais ce n'est pas le sujet) et que ça peut être une fuite d'information presque aussi grave que pour tout le système. Je ne vois pas ce qu'OpenSSL vient faire dans l'histoire, à ce que je sache, la plupart des applications des marketplaces ne sont pas libre.

                « 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: et la sécurité ?

        Posté par  . Évalué à 4.

        ouais, mais on en revient à la même situation qu'avant : nouveau bundle, nouvelles versions des libs : les paquets universels qui s'appuient sur la version que tu avais ne marche plus. Problèmes entre les paquets qui attendent une version et ceux qui en attendent une autre… ca ne semble pas changer grand chose. enfin.

      • [^] # Re: et la sécurité ?

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

        En séparant les rôles, comment moi, qui suis administrateur d'une machine sur laquelle mes utilisateurs installent n'importe quoi leurs applications, je fais pour maintenir un bon niveau de sécurité, sachant que eux ne, feront pas les mises à jours ?

        De mon point de vue, utilisateur et administrateur, ce n'est pas le même métier, pas les mêmes compétences.

  • # Il a le mérite de bien vendre sa "came".

    Posté par  . Évalué à 2.

    Qu'on le veuille ou non, Lennart fait un vrai travail pédagogique. Et de réussir à garder "ce calme" alors qu'il est trollé à longueur de billets, ça force le respect.

    Sinon l'idée est séduisante mais un poil overkill, non? On voit aussi qui cela cible, on parle utilisateur mais je crois avoir lu au moins 10 occurences de "vendor", c'est pas vraiment le terme qu'on utilise pour parler de producteurs de LL.

  • # De la dureté des diamants ou l'importance de la spécification d'interfaces.

    Posté par  . Évalué à 6.

    L'approche a beau être très intéressante, et à le mérité d'apporter une réponse dans certains cas mais elle ne répond pas au véritable problème: avoir des API/ABI/Spécification durables. Même si l'idée est intéressante sur le papier elle abouti à une multiplication des runtimes. Mettons que j'ai une application qui cesse d'être maintenue, dois je garder un snapshot d'une distribution compatible? Que ce passe t'il si j'ai une vingtaine ou une cinquantaine d'application non maintenues? Dois je me retrouver avec autant de snapshots? On va finir par avoir sur chaque machine la collection complète de toutes les révisions d'une distribution majeure.

    Et même en le faisant cela n'empêcherait pas certaines incompatibilités. Mettons que sur ma machine, ma carte graphique requiert des drivers recents qui eux ont besoin de biblothèques récentes (libY.so). Mettons également que je souhaite faire tourner une application OpenGL vieille de 10 ans ne fonctionnant qu'avec une version précise (et ancienne) de cette même libY.so . Il n'est pas possible (tout au moins avec le chargeur dynamique GNU) de charger en mémoire deux versions d'une même bibliothèque avec même nom de fichier et même SONAME.

    Fournir une application avec ces dépendances est une bonne idée (d'ailleurs déjà largement exploitée) mais pour être rellement fonctionelle il faut pouvoir faire tourner l'application dans le même environnement que celui pour lequel elle a été conçue. Ceci inclus même les composant les plus fondamentaux de l'OS que sont la libc, X, … . Il n'y a donc pas d'autre choix que de faire tourner chaque (groupe d') application dans une machine virtuelle. Ca tombe bien, Linux est bon dans le domaine.

    Il n'en reste pas moins que même si la solution peut être viable, elle demande quand même une multiplication des runtimes. Se forcer a avoir des API/ABI durables est certes plus contraignant mais plus simple sur le long terme.

    • [^] # Re: De la dureté des diamants ou l'importance de la spécification d'interfaces.

      Posté par  . Évalué à 7.

      Et même en le faisant cela n'empêcherait pas certaines incompatibilités. Mettons que sur ma machine, ma carte graphique requiert des drivers recents qui eux ont besoin de biblothèques récentes (libY.so). Mettons également que je souhaite faire tourner une application OpenGL vieille de 10 ans ne fonctionnant qu'avec une version précise (et ancienne) de cette même libY.so . Il n'est pas possible (tout au moins avec le chargeur dynamique GNU) de charger en mémoire deux versions d'une même bibliothèque avec même nom de fichier et même SONAME.

      Si tu peux. La bibliothèque standard sur ton PC est dans /lib ou /usr/lib. Il suffit de lancer ton appli vieille de 10 ans dans un environnement avec un LD_LIBRARY_PATH qui contient le chemin de ta libY.so vieille avant celle libY.so de ton /lib .

      $ ldd ./appli10
      ...
      libY.so    /usr/lib
      ...
      $ ls /mon/appli/de/dix/ans/lib
      libY.so
      $ export LD_LIBRARY_PATH=/mon/appli/de/dix/ans/lib:$LD_LIBRARY_PATH
      $ ldd ./appli10
      .../
      libY.so    /mon/appli/de/dix/ans/lib
      .../
      $ 

      L'OS n'a aucun mal à avoir plusieurs version de la même lib en RAM.

Suivre le flux des commentaires

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