Pas de Chromium pour Debian Squeeze

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
15
14
sept.
2010
Debian
Chromium est la base libre qui permet à Google de fournir le navigateur Google Chrome. Un paquet Debian, nommé chromium-browser, fournit Chromium directement. Le paquet s'appelle chromium-browser pour le différencier du paquet fournissant le jeu chromium.

Avec le renforcement des conditions d'entrées de nouvelles versions ou de nouveaux paquets (le gel de Debian pour la publication de la nouvelle version stable se fait en plusieurs étapes), l'équipe de publication a décidé d'exclure le paquet de la prochaine version stable. En effet, l'équipe doit arbitrer entre le risque d'introduire de nouveaux problèmes en mettant à jour ou garder du code largement utilisé (et avoir une plus grande confiance dans ce dernier). Le choix est fait au cas par cas : ainsi une nouvelle version mineure de gnash a été acceptée (de 0.8.7 à 0.8.8). Chromium, probablement trop gros et trop risqué, en a fait les frais. On trouve une volonté de créer ce paquet dès mars 2009. Il semble que cette première intention ne soit pas celle ayant débouché sur le paquet actuel¹. Le paquet est rentré dans unstable en mars 2010.

Le paquet reste donc uniquement disponible dans Sid. Il reste toujours possible d'installer facilement Google Chrome en utilisant la version fournie par Google. Le .deb fonctionne sans difficulté mais est limité aux processeurs x86 et x86_64.

La licence du code source pour Chromium est de type BSD (en version sans clause de publicité) donc le paquet est intégrable à la branche principale de Debian (main) sans difficulté. En revanche, Google Chrome est soumise à une licence plus restrictive, basée sur celle des services Google, impliquant en particulier une divulgation des données personnelles.

¹ : Je ne sais pas ce qui s'est passé entre mars 2009 et mars 2010, date d'activation de la liste dédiée au paquet chromium-browser.

Aller plus loin

  • # Debian a raison

    Posté par  . Évalué à 5.

    En l'état actuel des choses, Chromium n'est pas prêt pour être distribué dans les dépôts "stables" des distributions pour une simple et bonne raison: Google est apparemment incapable de travailler avec les projets upstreams et les empaqueteurs.
    http://spot.livejournal.com/312320.html
    • [^] # Re: Debian a raison

      Posté par  . Évalué à 7.

      Oui. Y a qu'à voir l'énorme boulot de Gentoo pour debundlifier (aussi dit "dézenitramiser") les librairies… Chromium c'est très caca niveau packaging. Plutôt que de travailler avec les libs qu'ils utilisent, ils font la modification dans leur coin et copient la lib entière dans leur source.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Debian a raison

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

        Quel rapport avec le packaging ?

        >Plutôt que de travailler avec les libs qu'ils utilisent, ils font la modification dans leur coin et copient la lib entière dans leur source.
        ça suffit comme raison, non ? En quoi le packaging impacte cela ? Il est impacté, oui, par contre.

        Quant à la sécurité évoquée plus bas, j'ai autant de doutes sur chromium que sur chrome. Mais ce ne sont que des doutes. Quant je vois que Chrom{e;ium} semble ré-écrire une fonction autrefois dévolue à un service spécifique, puis plus récemment à la glibc, j'ai un peur sur ce que fait le bousin, en fait. En plus il est fourbe, il demande de jolies dépendances, mais ne s'appuye pas sur le système pour des trucs basiques.

        Merci de ces éclairages.
        • [^] # Re: Debian a raison

          Posté par  . Évalué à 10.

          Je m'exprime mal. Disons qu'ils ne sont pas package-propre-friendly.

          Le problème des libs bundlées, c'est que :

          * si tout le monde se permet ça, tout les programmes vont prendre dix fois plus de mémoire
          * quand une lib bundlée à une faille de sécurité, il faut mettre à jour tout ces paquets, c'est horrible
          * c'est très lent à compiler (ça c'est l'utilisateur de Gentoo qui parle)
          * globalement, ils feraient mieux de collaborer avec les auteurs des libs

          Enfin, Firefox est aussi un habitué, en bundlant sqlite par exemple. (Ce qu'on peut éviter sous Gentoo.)

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Debian a raison

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

            Merci de tes explications. (ça fait du bien de lire un texte qui cherche à avoir raison et non pas un texte qui cherche à prouver que l'autre à tord, donc merci, passons)

            Pour être direct, toujours :
            * si tout le monde se permet ça, tout les programmes vont prendre dix fois plus de mémoire
            * globalement, ils feraient mieux de collaborer avec les auteurs des libs

            Ok. Parfait.
            Si des programmes font cela, et que ça deviant sale sur mon système, j'arrete d'utiliser ces programmes. Point.
            Si je suis re-lecteur et que je me rends compte que tel navigateur s'amuse a implémenter une tinybd alors que le système l'as déjà, ben j'essaie de faire comprendre au projet, et de travailler avec eux, pour améliorer cela. Si le projet ne veux rien entendre et continue de faire ses saletés, je ne vois vraiment pas pourquoi je continuerai de m'enquiquiner à le packager en défaisant ce qu'ils ont choisi de faire. J'en informe les utilisateurs, et je pense qu'ils sauront écouter.

            non ?

            (je passe sur le troll des mises à jour et de la sécurité, hein, ça vaut mieux....)
            • [^] # Re: Debian a raison

              Posté par  . Évalué à 1.

              Oui. Ça me fait penser à Gentoo (décidément la meilleure distribution du monde) qui à l'installation de Flash dit en gros "Flash ça plante et c'est plein de trous, utilisez un truc du genre Flashblock pour survivre".

              DLFP >> PCInpact > Numerama >> LinuxFr.org

              • [^] # Re: Debian a raison

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

                Tant qu'on touche pas aux overlays :)
                les binaires c'est bien de les faire pour comprendre, pas pour les distribuer
                (...)

                merci encore
                • [^] # Re: Debian a raison

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

                  oupss j'aurai dû attendre vendredi pour celui là ! et puis surtout c'est juste rigolo.

                  mode évidence : moi c'est bien Debian qui me fait de plus en plus de l'oeil ! :) reste à gentoĩsé un stade 1 de Debian... ensuite à utiliser les binaires des projets directement (pour firefox, ooo, tb, VLC...) dans un beau tit env bien préparé :)
          • [^] # Re: Debian a raison

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

            Sauf que sqlite est fait pour être "bundler" lui :) les autres projets de l'auteur (http://www.fossil-scm.org par exemple) utilise sqlite en mode bundle.

            1 fichiers c et 1 fichier h suffisent pour ça etc ainsi chacun projet embarque son sqlite et le compile avec les options adaptées à son utilisation (oui beaucoup d'options de sqlite sont des options compile-time).

            Sinon dans la majeure partie des cas c'est pas bien de faire ça :)
            • [^] # Re: Debian a raison

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

              Ne serait-il pas plus intelligent de se fixer des "profiles" et proposer plusieurs versions d'un package (sqlite-perfs_profile, sqlite-functionalities_profile...) dans les repos? C'est peut-être un juste milieu entre taille démultipliée et offre technique.
              Car le problème quand chacun embarque son sqlite (très pratique pour Windows/Mac, par forcément pour Linux) est que si il y a une faille de sécurité sur sqlite, ben si on loupe une appli qui l'embarque, on a mal si le développeur upstream n'y pense pas et ne sort pas de nouvelle version de sécurité.

              Pas facile tout ça, car il n'y a pas de bonne et unique solution...
              • [^] # Re: Debian a raison

                Posté par  . Évalué à 7.

                > Pas facile tout ça, car il n'y a pas de bonne et unique solution...

                qui êtes-vous et qu'avez-vous fait de Zenitram ?
          • [^] # Re: Debian a raison

            Posté par  . Évalué à 1.

            faut relativiser quand même :
            - Si un groupe de développeurs ne suit pas les libs concernées, à un moment donné il va y avoir un problème de version dans le paquet. Inclure les libs permet de se passer de ce genre de problème, qui peut être bloquant, sans que rien d'autre que le numéro de version n'ait changé pour le groupe en question
            - Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir compte.
            - La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne change à l'usage, quand tu fais un #include 'toto.h" ou un #include "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de sérénité ?
            Le grain de sel des mises à jour tranquilles ?
            - La collaboration, c'est si possible, et si on modifie la lib de façon conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko , c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté, webkit est dispo beaucoup plus facilement :s )

            Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les programmes . Sinon, faut travailler avec du lourd.

            Sedullus dux et princeps Lemovicum occiditur

            • [^] # Re: Debian a raison

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

              Plutôt que d'imaginer tu devrais vérifier ;)

              La mémoire, ce n'est pas la place du binaire sur le disque dur. Si tu embarque une bibliothèque dans le projet de ton logiciel, tu vas compiler cette bibliothèque. Cette version ne sera pas la même que celle fournit par la distribution. Le logiciel sera lié avec cette bibliothèque, le path de la bibliothèque étant décidé lors de la compilation. Donc oui, il y aura deux version de la bibliothèque dynamique chargées en mémoire. Au passage, ça n'a rien à voir avec les headers.
              • [^] # Re: Debian a raison

                Posté par  . Évalué à -1.

                Non, mais po compris. :)
                Moi je parle non pas de faire un boulot crado comme aller donner à l'EDI un chemin vers une bibliothèque externe et l'inclure dans le paquet ... Je parle de récupérer les sources et de compiler l'ensemble dans ton logiciel. :)
                Évidemment, si les mecs font le boulot à moitié... ;S

                Sedullus dux et princeps Lemovicum occiditur

            • [^] # Re: Debian a raison

              Posté par  . Évalué à 2.

              > - Si un groupe de développeurs ne suit pas les libs concernées, à un moment
              > donné il va y avoir un problème de version dans le paquet. Inclure les libs
              > permet de se passer de ce genre de problème, qui peut être bloquant, sans que
              > rien d'autre que le numéro de version n'ait changé pour le groupe en question
              >
              > - Pour la sécurité, j'ose imaginer que l'équipe qui fait le projet sait d'où
              > vient ce qu'elle y a inclus , et est capable de s'abonner aux avis et en tenir
              > compte.

              En fait, tu dis que c'est chiant pour les développeurs de suivre les nouvelles
              versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
              s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?

              Ça n'a absolument aucun sens.

              > - La mémoire, c'est uniquement la place du binaire sur le disque dur. Rien ne
              > change à l'usage, quand tu fais un #include 'toto.h" ou un #include
              > "/usr/lib/toto.h" si les deux libs sont identiques. Et même s'il faut y
              > réfléchir, c'est quoi , 300ko de + , lorsque le To est à 70€ ? le soupçon de
              > sérénité ?

              Heu je pense que t'as pas compris. Un header contient juste en théorie les
              prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
              moment de la compilation et on s'en cogne.

              En revanche, le linkage statique va inclure toute la lib dans l'executable, et
              donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
              moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
              fois.

              > - La collaboration, c'est si possible, et si on modifie la lib de façon
              > conforme aux objectifs. Quand je vois que le paquet Epiphany inclue Gecko ,
              > c'est à dire Firefox en entier sous FreeBSD, je me dis que quelque fois, les
              > libs, ça pourrait être mieux géré. Si je devais faire un navigateur utilisant
              > Gecko, crois moi, je prendrait tout ce qui concerne Gecko dans Firefox, mais
              > ça serait du rm de tout le reste, et pas de remontées, peut -etre une énieme
              > libGecko qui sera plus à jour à la prochaine update de firefox. ( à côté,
              > webkit est dispo beaucoup plus facilement :s )

              Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
              utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
              ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?

              > Quant à sqlite, en même temps, ce truc est fait pour être inclus dans les
              > programmes . Sinon, faut travailler avec du lourd.

              Heu j'ai peur de pas comprendre ce que tu veux dire.
              • [^] # Re: Debian a raison

                Posté par  . Évalué à -2.

                En fait, tu dis que c'est chiant pour les développeurs de suivre les nouvelles
                versions des libs qu'ils utilisent, mais que c'est moins chiant qu'ils
                s'abonnent aux avis de sécurité sur les libs qu'ils utilisent ?

                Ça n'a absolument aucun sens.


                Aucun, d'ailleurs, aucun paquet n'a jamais de problèmes de dépendances au moment des mises à jour.

                Heu je pense que t'as pas compris. Un header contient juste en théorie les
                prototypes des fonctions et les déclarations de types, en gros c'est utile qu'au
                moment de la compilation et on s'en cogne.

                En revanche, le linkage statique va inclure toute la lib dans l'executable, et
                donc va l'alourdir, là où le linkage dynamique permet de charger la lib au
                moment de l'exécution, et donc elle n'est présente sur le système qu'une seule
                fois.


                Ma réponse est deux posts plus haut.

                Bah dans ce cas là, la solution c'est qu'une libgecko développée upstream et
                utilisée par Firefox soit bien faite, pas de pomper le code et de l'inclure dans
                ton soft. Qu'est-ce que tu fais pour merger les modifs upstream de gecko après ?


                Demande-toi plutôt pourquoi Firefox ne donne pas de libGecko.

                Heu j'ai peur de pas comprendre ce que tu veux dire.
                KDE utilise quelles bases de données ( au pluriel ) ?

                Sedullus dux et princeps Lemovicum occiditur

                • [^] # Re: Debian a raison

                  Posté par  . Évalué à 2.

                  Montant d'information contenu dans ton commentaire : 0

                  DLFP >> PCInpact > Numerama >> LinuxFr.org

                  • [^] # Re: Debian a raison

                    Posté par  . Évalué à -1.

                    n'est pire aveugle que celui qui ne veut pas voir. :)

                    Bon sinon, je ne prêche pas , je ne dénonce pas, et je m'en fous Royal des bibliothèques.

                    Sedullus dux et princeps Lemovicum occiditur

                    • [^] # Re: Debian a raison

                      Posté par  . Évalué à 5.

                      C'est cool mais je crois que personne n'a compris où tu voulais en venir.

                      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Debian a raison

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

        Y a qu'à voir l'énorme boulot de Gentoo pour debundlifier (aussi dit "dézenitramiser") les librairies…

        J'aime bien tes petits pics... Complètement HS.
        A aucun moment je n'ai parlé que c'était bien de packager tout ce bordel avec des libs patchées sans avoir remonté upstream pour les libs. A aucun moment je n'ai parlé de changer ce comportement pour avoir un repo stable pour ceux qui le souhaitent. Bloquer Chronium dans le repo stable car l'upstream (Google) fait n'importe quoi ne me pose aucun problème.
        Mais c'est un classique : tu n'as pas de bons arguments pour ce que je critique, donc tu m'accuses de tous les maux qui n'ont rien à voir pour essayer de me décrédibiliser. C'est une méthode très utilisée en politique.
        • [^] # Re: Debian a raison

          Posté par  . Évalué à 2.

          C'était pas méchant. Si j'avais voulu faire une critique sérieuse, je l'aurai fait en te répondant directement.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Raisons

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

    Ç'aurait été bien de mentionner les raisons, là ça fait un peu « bouh, Debian c'est des boulets, ils ont virés Chromium ».
    • [^] # Re: Raisons

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

      J'ai détaillé ici les raisons du rejet de Chromium de Debian "Squeeze", la future version stable.

      En gros :

      - Chrome 6 vient de sortir, Chrome 5 ne va plus recevoir de mises à jour de sécurité. C'est inacceptable pour un logiciel avec un si large public. Exit Chrome 5.

      - Mais Chrome 6 vient de sortir (le 2 septembre) donc il ne peut pas être considéré comme stable, il n'a pas pu être intensivement testé sur une longue période et il serait donc incohérnet de l'inclure dans une version de Debian dite stable. Donc exit Chrome 6.

      Heureusement les backports sont là et permettront aux utilisateurs d'avoir régulièrement des versions maintenues et sécurisées de Chromium.
      • [^] # Re: Raisons

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

        s/chrome/chromium dans le commentaire précédent.

        Plus d'infos sur le rejet de Chromium : http://carlchenet.wordpress.com/2010/09/14/chromium-absent-d(...)
      • [^] # Re: Raisons

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

        C'est plus complexe que ça : même si chromium 6 était inclus, il ne serait pas supporté assez longtemps (au niveau des màj de sécu) pour durer sur toute une stable (3 ans), le logiciel ne supporte pas suffisamment ses anciennes versions, du coup l'inclure dans une distrib stable n'a pas de sens.

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Raisons

        Posté par  . Évalué à 3.

        Le problème de versions est limite mineur dans le cas de Chromium, d'une révision à une autre le code peut être totalement chamboulé (suffisamment pour rendre pénible le portage des patchs et casser des trucs au passage), celui-ci inclut beaucoup de bibliothèques tierces modifiés (parfois pour des raisons cosmétiques) dont libxml, libjingle, zlib, sqlite, icu etc ... Sans compter la taille monstrueuse du code qui ne facilite pas la tâche, une mise à jour de chromium ça prends beaucoup de temps.

        > Heureusement les backports sont là et permettront aux utilisateurs d'avoir régulièrement des versions maintenues et sécurisées de Chromium.

        Rien n'est moins sûr, le code de Chromium a beau être développé sous une licence libre mais le projet ne fait aucun effort pour faciliter la tâche des intégrateurs. Chromium a une approche propriétaire de la mise à jour: je fournis un gros binaire compilé en statique et je gère tout seul les mises à jours. Les autres peuvent se démerder.
        • [^] # Re: Raisons

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

          > Rien n'est moins sûr, le code de Chromium a beau être développé sous une licence libre mais le projet ne fait aucun effort pour faciliter la tâche des intégrateurs. Chromium a une approche propriétaire de la mise à jour: je fournis un gros binaire compilé en statique et je gère tout seul les mises à jours. Les autres peuvent se démerder.

          C'est sûr que le mieux serait une modification de leur modèle de développement, mais en l'état les backports permettront de mettre à disposition des utilisateur de Debian stable des versions pour lesquelles les plus récentes failles ont été corrigées.
          • [^] # Re: Raisons

            Posté par  . Évalué à 3.

            Je ne sais plus si c'est sur ce journal qu'on en parle, mais le problème c'est que chrom(e/ium) a un mode de développement très nerveux : tout vas tres vite, l'upstream est contacté mais ils n'attendent pas les mises à jours pour intégrer ça directement dans leur statique.
            Si en plus de l'upstream il faut attendre sur les packageurs pour ramener les nouvelles versions qui ne viendront peut-être pas à cause de la politique de la stabilité, le logiciel n'avance pas.
          • [^] # Re: Raisons

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

            Les backports sont une réponse à cela, mais est ce bien le plus propre pour le système ? Si j'installe des backports, je reprends l'exemple de firefox, je vais me retrouver quant même avec certaines bibliothèques importantes (pour gnome) qui seront backportées également. Elles ne seront pas isolées sur le système, mais en seront partie intégrante. Bien que depuis quelques temps, xul-runner est il me semble en version spécifique pour firefox, non ? justement pour éviter cela, on a déjà un doublon ...
            Ce n'est pas "pour ou contre" je me demande juste si les backports ce n'est pas une réponse qui finalement ne convient pas à FireFox et OpenOffice ? Alors qu'elle est gage de qualité pour d'autres logiciels 'endusers' ?

            (ce n'est qu'une question)
        • [^] # Re: Raisons

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

          >Chromium a une approche propriétaire de la mise à jour
          ouch ça c'est du beau gabarit !
          un autre de beau gabarit : à moins que soit les distributions qui voudraient que la terre entière tourne autour d'elles ?
          Chromium est libre.
          Ils fournissent code et binaire.
          Libre à chacun de s'en servir (moi je commence à m'en méfier, bien que je sois utilisateur de nombreux services google)

          c'est quant même sacrément gros de justifier le fait que le packaging a un problème dans de nombeuses distros en disant que c'est le projet libre qui a un comportement proprio. Non ?
          • [^] # Re: Raisons

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

            problème est un terme déplacé.
            le mode de fonctionnement du packaging de nombreuses distros, et uniquement pour les logiciels tiers, est à l'origine de problème pour passer à l'échelle supérieure.

            sans y mettre les formes :
            je ne vois pas pourquoi je ferai plus confiance a des re-lecteurs et packageurs qui ne veulent pas travailler upstream, préférant faire leur truc dans leur coin pour leur distro, plutot que de faire confiance au projet libre lui même.

            La MoFo a un comportement proprio, aussi ? Les développeurs de l'installeur Debian également ? Ca ne tiens pas la route comme discours, on cherche juste à justifier du pouvoir et une position.
            • [^] # Re: Raisons

              Posté par  . Évalué à 3.

              ben propose tes services de mainteneur expert de ces 5 ou 6 millions de lignes (ou alors c'était 13 ?), oh grand maître !

              Le packageur est fort démuni si les conventions de dev de sa distro sont incompatibles avec celles de l'upstream du logiciel et qu'il n'a pas la force suffisante pour combler les deltas pendant la période de maintenance...

              Après il y a d'autres distro de dispo qui apportent d'autres qualités, c'est pas comme si Debian était un espèce de monopole malsain qui tentait d'imposer sa manière de faire à toute l'humanité.
              • [^] # Re: Raisons

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

                Ouhaip, c'est complètement déplacé de questionner sur ça sur un post de Debian. Désolé.
                En plus, effectivement, j'ai oublié plein de points d'interrogations partout.
            • [^] # Re: Raisons

              Posté par  . Évalué à 5.

              > La MoFo a un comportement proprio, aussi ?

              ouais. tu te fais insulter si tu fournis un mozilla avec pas pile poil les mêmes libs qu'eux ou pas patchées pareil ou pas les mêmes options de compilation, ça se résume en un "seule notre version binaire est la bonne" "n'appelez pas la votre 'Firefox'" et ça a donné les gueguerres avec Debian qu'on a connu, avec des débordements de très grosses têtes de cons de part et d'autres.

              vouloir interdire d'autres versions que les siennes est un comportement proprio. voir Ion3 par exemple. (et même problèmatique générale d'ailleurs)

              > Ca ne tiens pas la route comme discours, on cherche juste à justifier du pouvoir

              t'as oublié de faire comme ouin-ouin et crier à la censure.
              • [^] # Re: Raisons

                Posté par  . Évalué à 6.

                > vouloir interdire d'autres versions que les siennes est un comportement proprio.

                Ils ne veulent pas interdire une autre version, ils ne veulent pas voir leur nom associé aux expérimentations des autres. C'est très différent.

                Une base de code de la taille de firefox, avec des dépendences critiques (ils s'amusent pas à patcher par ce qu'ils s'emmerdent le dimanche) c'est juste un enfer niveau QA. Il faut avoir pas mal de connaissance du produit et de son historique pour pouvoir tripatouiller le tout en relative sérénité. Ils écrivent le code, ils te le donnent, ils t'assurent que ca fonctionne avec une configuration donnée. Et tout ce qu'ils demandent c'est que si tu veux faire joujou avec le build tu n'utilises pas leur nom.

                Ca evite de se faire pourrir sa réputation par ce que des rigolos de packager ont foiré sur la QA.
          • [^] # Re: Raisons

            Posté par  . Évalué à 2.

            > c'est quant même sacrément gros de justifier le fait que le packaging a un problème dans de nombeuses distros en disant que c'est le projet libre qui a un comportement proprio. Non ?

            Chromium pose un problème de packaging pour TOUTES les distros mais Chromium n'a évidemment rien à se reprocher ... Rien que la gestion fantaisiste des bibliothèques tierces dans Chromium est problématique (ça mériterait une tribune de J-P Troll), je vais pas répéter tout ce qui a déjà été dit. Oui, le code de chromium est libre mais la gestion du projet est tout ce qu'il y a de plus fermé.

            Ce qui est gros, c'est de nier que Chromium n'a de libre que son code ...

            > à moins que soit les distributions qui voudraient que la terre entière tourne autour d'elles ?

            Entre faire la sourde oreille aux empaqueteurs/rapporteurs de bogues et ça, il y a un monde.
          • [^] # Re: Raisons

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

            c'est quant même sacrément gros de justifier le fait que le packaging a un problème dans de nombeuses distros en disant que c'est le projet libre qui a un comportement proprio. Non ?

            Ce qui serait pas mal c'est que tout le monde cherche à travailler ensemble, et la, je jette la pierre à Google qui me semble (je ne connais pas assez pour être sûr) fournit un gros truc énorme "démerdez-vous". Ce n'est certes pas obligatoire dans le libre, mais c'est dommage. Bon, pour leur défense, vu le monde que ça leur apporterait de consacrer du temps à faire les choses propres, je peux les comprendre. Bref pas tout le monde noir, mais pas blanc non plus.
            • [^] # Re: Raisons

              Posté par  . Évalué à 2.

              > Ce qui serait pas mal c'est que tout le monde cherche à travailler ensemble,
              > et la, je jette la pierre à Google qui me semble (je ne connais pas assez pour
              > être sûr) fournit un gros truc énorme "démerdez-vous". Ce n'est certes pas
              > obligatoire dans le libre, mais c'est dommage. Bon, pour leur défense, vu le
              > monde que ça leur apporterait de consacrer du temps à faire les choses
              > propres, je peux les comprendre. Bref pas tout le monde noir, mais pas blanc
              > non plus.

              Que lise-je ?? Zenitram qui dit qu'il faudrait que les acteurs du libres
              devraient collaborer entre eux ? Pourtant la GPL ne l'oblige pas.

              Je pense que pendant ses quelques jours d'absence il a été enfermé dans une
              pièce sans eau ni nourriture ni déodorant avec RMS.
              • [^] # Re: Raisons

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

                Tu pourrais relire STP : la licence ne l'oblige pas, c'est un fait, et je continuerai à le dire. C'est juste dommage. Je râlerai toujours contre les gens qui osent affirmer que l'esprit du libre dit que Canonical *doit* contribuer. C'est dommage, c'est tout, mais autant Canonical que Google ne sont pas obligés et on n'a pas à critiquer qu'ils ne le fassent pas.
                Mais tu lis ce que tu veux lire et non pas ce que j'écris quand je réagis à une chose...
                • [^] # Re: Raisons

                  Posté par  . Évalué à 2.

                  Dis donc tu pars au quart de tour, c'était une blague.
                  • [^] # Re: Raisons

                    Posté par  . Évalué à 1.

                    Ce n'est jamais que la deuxième fois en moins de 20 posts:
                    https://linuxfr.org//comments/1162442.html#1162442

                    A cran Zenitram?
                    • [^] # Re: Raisons

                      Posté par  . Évalué à 4.

                      Il ne s'est pas encore fait au fait (oui, bon) qu'il fait maintenant partie du folklore dlfpien, au point d'avoir un fan-club et être régulièrement invoqué telle une divinité païenne.

                      DLFP >> PCInpact > Numerama >> LinuxFr.org

                      • [^] # Re: Raisons

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

                        Il faut un certain temps pour s'habituer à cette célébrité :).
                        • [^] # Re: Raisons

                          Posté par  . Évalué à 1.

                          y'en a qui ont essayé, ils ont eu des problèmes.
                          • [^] # Re: Raisons

                            Posté par  . Évalué à 1.

                            Ceci dit il est très rapide.
                            • [^] # Re: Raisons

                              Posté par  . Évalué à 8.

                              C'est ce que sa femme dit aussi.

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

  • # Données personnelles....

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

    Ceci est une vrai question, et pas un appel au troll (ce n'est pas vendredi !)

    La lecture de ceci me rend un peu perplexe http://linuxfr.org//comments/1161641.html#1161641 :


    bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée)


    N'étant ni un utilisateur de Chome ni de Chromium, j'aimerai savoir ce qu'en pense les utilisateurs de Chromium : Est-il vrai que ce dernier fait comme son "grand frère", et qu'il communique lui aussi avec Google ? Mise à part peut-être pour les mises à jour des bases de données anti-phishing ?

    J'avoue que je ne suis que moyennent motivé par utiliser un navigateur qui communique avec son créateur, même si c'est de nature (parfaitement ?) anonyme (envoie des URL visitées par exemple).
    • [^] # Re: Données personnelles....

      Posté par  . Évalué à 1.

      Je viens de regarder avec wireshark sous Archlinux, si tu désactives les suggestions rien n'est envoyé à Google.
      Mais ça ne veut pas dire que rien n'est jamais envoyé, je sais plus où j'avais vu que Chromium envoit un récapitulatif de tes recherches toutes les 24h ou un truc du genre.
      Il faudrait analyser sur une période de 2/3 jours pour être sûr en fait.
      • [^] # Re: Données personnelles....

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

        Ce qui est marrant, c'est qu'on parle de logiciel libre, avec un code source disponible, et qu'au final, l'analyse (avec wireshark) se passe exactement de la même manière qu'avec un logiciel propriétaire, comme si c'était une boîte noire :)
        • [^] # Re: Données personnelles....

          Posté par  . Évalué à 3.

          Bah ahma, pour savoir si un programme envoie ou non des données personnelles sur le réseaux c'est plus simple d'utiliser wireshark que de regarder le code source.

          Car si on ne fait pas confiance au programme, on n'a pas non plus confiance dans le programmeur, et donc rechercher une hypothétique fonction, certainement obfuscée qui envoie des trucs pas net ça doit pas être facile ...
        • [^] # Re: Données personnelles....

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

          Pour se faire un avis rapide sur le soft, sans avoir à se pallucher des heures de lecture de code (et encore faut-il en avoir les connaissances), d'autant pour Chromium qui semble particulièrement "lourd", il est en effet plus rapide de faire appel aux applis externes (strace, tcpdump/wirshark, etc...).

          Evidement, ce n'est qu'une première approche rapide du problème. Mais si il s'agit comme ici de savoir si oui ou non Chromium discute avec Google, cela s'avère suffisant.

          Après, il est toujours possible (je n'ai pas dit "facile") de patcher/forker Chrominum pour éliminer les codes de discussion avec Google. Mais c'est du gros boulot.

          Personnellement, je préfère utiliser un autre navigateur, même si celui-ci est plus lent (dixtit le journal de Patrick G : http://linuxfr.org/~patrick_g/30163.html )
  • # Ça ne mérite pas une dépêche.

    Posté par  . Évalué à -2.

    Tout est dans le titre.
    • [^] # Ça ne méritaitpas un commentaire

      Posté par  . Évalué à 10.

      Tout est dans le titre.
    • [^] # Re: Ça ne mérite pas une dépêche.

      Posté par  . Évalué à 5.

      Moi je trouve cette dépêche instructive.

      Moi par exemple, je suis sous Sid et j'aurais très bien pu continuer à ignorer que chromium-browser ne serait pas dispo sous Squeeze. Or, il se trouve que j'utilise ce navigateur pour consulter certains sites mal gérés par mon navigateur préféré (uzbl en l'occurence). Donc cette dépêche m'a incité à rechercher un autre navigateur secondaire. J'ai cherché un peu, et j'ai trouvé 'arora'. Bizarrement ce browser fonctionne avec WebKit comme uzbl, mais il gêre mieux les sites problématiques sus-mentionnés.

      Du coup, grâce à cette dépêche, j'ai pu faire un : "apt-get remove chromium-browser". Avec un certain ouf de soulagement, compte tenu de ma profonde méfiance envers Google.
      • [^] # Re: Ça ne mérite pas une dépêche.

        Posté par  . Évalué à 2.

        Si Sid marche bien pourquoi changer ?
      • [^] # Re: Ça ne mérite pas une dépêche.

        Posté par  . Évalué à 6.

        chromium ==> webkit/chromium
        uzbl ==> webkit/Gtk+
        arora ==> webkit/Qt

        Pour faire court, WebKit c'est un kit de construction de moteur de rendu, et chaque port doit brancher un moteur réseau, de dessin, javascript, multimédia, etc ... donc il y a quelques différences entre les "ports". Sans compter que chaque port embarque sa copie de WebKit (à des révisions différentes, avec des patchs spécifiques etc ...), pour le moment, il n'est pas possible d'avoir une seule installation de WebKit sur laquelle viendrait se brancher les ports (mais ça avance)
  • # Ça ne mérite pas une dépêche.

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

    je suis bien de cette avis car sous debian on s'en sort pas sinon il n'y a pas la derniere version de firefox, thunderbird, mldonkey, gnome, kde ect... chromium fait partie d'une longue liste qui vient de la politique de debian qui préfère stabilité que nouveauté... et ceci vaut doudeblement pour chromium vu l’enchaînement de version, en 1 mois il y a plusieurs versions, alors que debian stable est la pour 3ans... donc debian ne peut se permette autant de changement a part dans volatile ou backport...
    • [^] # Re: Ça ne mérite pas une dépêche.

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

      par exemple, sous ubuntu, c'est pareil et donc c'est pour ça que le PPA chromium a été ouvert...
    • [^] # Re: Ça ne mérite pas une dépêche.

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

      >>> il n'y a pas la derniere version de firefox, thunderbird, mldonkey, gnome, kde ect.

      Il y a une différence entre ne pas avoir la dernière version et virer carrément le logiciel.
      Mais bon tant que c'est dans backports les utilisateurs de Chromium-browser s'y retrouveront.
    • [^] # Re: Ça ne mérite pas une dépêche.

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

      Je ne comprends pas cette opposition stabilité et nouveauté.

      Lorsque le but est d'avoir un serveur stable, y a pas photos. Cette politique met une énorme claque à tout autre système. En même temps celui qui lance chrome sur un serveur stable (ou qui se sert d'un serveur web/mail/whatever mais pas d'appli, pour lancer openoffice), ben heu comment dire, faut aller voir s'il reste du goudron et des plumes...

      Lorsque le but est d'avoir un bureau grand public, y a pas photos. Cette politique est celle, lorsqu'elle est appliquée de a à z, qui met une énorme claque à l'utilisateur lambda. Et l'utilisateur lambda, il se casse. Bon pour Debian, probable qu'ils s'en fichent. (l'important étant ici l'aspect pédagogique ainsi que le cheminement pour une personne afin qu'elle se fasse la main sur un truc secondaire dans ce système, avant de devenir 'productive' : ceci a une importance sans commune mesure avec un mr michu)

      Lorsque le but est d'avoir un bureau grand public, secondo :p il va être difficile de tenir le même discours. Aller expliquer au projet libre x "qu'il pue du cul" d'une part, et de l'autre aller expliquer à l'utilisateur qui souhaiterait faire des rapports de bugs sur la version beta de x, ben que c'est pas possible parcequ'il a pas le niveau et que dans le système c'est la version stable, sinon tout est cassé !

      Un système visant le bureau grand public doit s'ouvrir plus tout d'abord aux projets eux mêmes, en permettant des relations plus étroites avec leurs utilisateurs, si ces projets le demandent. Et s'ouvrir aussi aux demandes utilisateurs, qui ne réclament souvent que de pouvoir suivre les gros projets comme eux ils le souhaitent. En plus, nos systèmes permettent des configurations assez velues assez facilement, rien n'empêche de prévoir une sécurité, une prison, un environnement restreint, pour ces binaires venus d'ailleurs mais libres...

      Un exemple un peu bancal, la politique de Fedora vis à vis de Kde : de super packages, une super intégration, mais c'est bien le bugzilla de Kde qui est sollicité s'il y a problème, pas celui de Fedora. Parfait. Pour oter l'adjectif 'bancal' il pourrait y avoir la même chose mais pour FireFox, OpenOffice, VLC, bref les projets libres indépendants. Moins de travail de packaging, plus d'utilisateurs satisfaits parcequ'ils ont la dernière version de logiciel 'vitrine' important, et plus de retours directement fait aux projets.

      Je ne dis pas qu'il faille vider les bugzilla des distributions de tout rapport de bugs qui ne concerne pas les fichiers spec, bien spur, je ne tombe dans l'autre extrème. Je dis juste que ça me semblerait intéressant de lacher du lest aux projets indépendants, qu'ils puissent avoir des retours directs de leurs utilisateurs plus facilement. Donc préparer un système stable à être en capacit" d'accueillir une version beta de firefox, si l'utilisateur, et le projet!, le désirent. Protéger le système pour plus de liberté à l'utilisateur et aux projets indépendant.

      mes deux cents.
      • [^] # Re: Ça ne mérite pas une dépêche.

        Posté par  . Évalué à 2.

        Comme tu dis, il faut de tout, et d'ailleurs... tout existe!
        Il n'y a pas si longtemps on débattait sur le trop grand nombre de distros suivant toutes les préférences techniques, politiques, idéologiques, etc.
        Là tu vas presque nous dire que finalement il n'y en a pas assez?
        Des distros qui ne patchent pas (ou très peu) et proposent des choses très à jour, y'en a!
        Je pense à Archlinux en premier, mais ce n'est pas la seule.
        • [^] # Re: Ça ne mérite pas une dépêche.

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

          C'était plus une question sur la pertinence d'appliquer des recettes de serveur et de système d'entrerprise pour un système orienté grand public. (je comprends que le sysadmin devienne un peu dictateur avec ses usagers, je le comprends moins lorsque le sysadmin et l'usager sont une seule personne : utilisateur unique ou familial d'une machine personnelle, et que c'est la distro qui endosse ce rôle)
          Dans ce petit cadre d'utilisation personnelle et familale, n'y a t il possibilité de laisser l'usager pouvoir suivre facilement directement les projets eux-mêmes, pour quelques grands softs "vitrines" ? Est ce qu'une politique de packaging unique ne devient pas contradictoire, au final, parfois, avec le but de l'utilisation personnelle facilité ? Qu'est ce que le système, la distro, craint il vraiment, de voir ses utilisateurs pouvoir facilement utiliser firefox 4 beta, sans déstabilisé tout leur système, ni encombrer son bugzilla avec un problème uniquement à firefox 4 beta ? Est ce que le système de packaging n'atteinds pas là ses limites ?
          • [^] # Re: Ça ne mérite pas une dépêche.

            Posté par  . Évalué à 5.

            Réponse courte: non

            Réponse longue:
            Tu veux introduire un logiciel béta qui va potentiellement foutre un bronx pas possible dans le système.

            Sous windows:
            J'ai mes deux Firefox, 3.6 et 4béta installés par l'installeur.

            Sous Debian (enfin une distro GNU/Linux, tu vas voir que ça revient au même!)
            J'ai mon Firefox 3.6 installé par ma distro. (enfin, Iceweasel, mais on se comprend).
            J'ai mon Firefox 4.0béta obtenu sur le site de Mozilla, compilé en statique, installé dans mon répertoire utilisateur, ce qui va éviter de foutre le bronx dans le système.
            Le jour où est il est stable et mâture, je peux installer le paquet de ma distro et virer la béta de mon rép. utilisateur.

            Comme ça, les bugs dans 3.6 passent d'abord par Debian au cas où ça viendrait de leurs patches.

            Les bugs de 4.0béta, je peux les envoyer directement à Mozilla en disant que ça vient de leur binaire compilé en statique, sur leur site (on ne peut pas faire plus "pur" pour éviter qu'ils corrigent des trucs de chez Debian).

            Elle est pas belle la vie?
            • [^] # Re: Ça ne mérite pas une dépêche.

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

              Pil Poil !!!!

              Seule la réponse "non" est inadaptée car elle ne concerne que le cas où un soft beta viendrai foutre le bronx dans mon système. Plus un. Mais inadaptée car elle n'entre pas en contradiction avec cette légitime volonté d'un utilisateur de vouloir firefox beta 4 sur son système stable, mais sans installer un paquet venu de n'importe où, sans foutre le bronx dans son système.

              Tu viens d'illustrer à merveille l'enfermement de l'utilisateur.
              S'il ne sait pas compiler correctement Firefox, alors qu'il creuve ou change de distro. C'est dommage, visiblement l'utilisateur lui il veux à la fois avoir un système stable, en suivant la doc, en écoutant, bref... et à la fois, pour quelques softs pouvoir les avoir en version beta sans remettre en cause le premier point.

              J'ai volontairement laisser de côté l'aspect technique (n'ayant pas la prétention de dire "c'est ça qu'il faut faire", perso je compile et je chroot, tu vois c'est pas la panacée non plus) pour ne m'interessé qu'à l'aspect théorique. L'utilisateur il écoute Debian, il comprends pourquoi Chromium se sera pas intégrer par exemple. Actuellement, la seule solution facile qui lui possible c'est ... de foutre le bronx dans son système :( :( :(
              Or il comprends que saymal, et aimerai bien avoir à la fois, comme tu le fais, un système stable et un firefox beta dans un coin. Pour le projet c'est bien aussi : un même binaire chez tout le monde, des remontées directes. Sans heurter les politiques des distros.

              Une petite concession permettant :
              1. éviter de foutre le bronx sur un système stable
              2. au projet un rapport direct avec leurs utilisateurs quant il le demande
              3. à l'utilisateur de pouvoir avoir firefox 4 beta

              C'est il me semble une bien petite concession au regard de ce que cela apporte.
              Techniquement, doit on se contenter d'un howto ? En sachant que peu le suivront et finiront par mettre le bronx sur leur système ? Ou est ce possible d'avoir une solution correcte pour tous ?
              • [^] # Re: Ça ne mérite pas une dépêche.

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

                Euh tu mélanges tout. En quoi l'utilisateur est enfermé et en quoi installé chromium ou tout autre logiciel en beta risque de foutre le bronx dans son système ?

                C'est à ça que sert /opt

                http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA(...)
                • [^] # Re: Ça ne mérite pas une dépêche.

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

                  Tout à fait, c'est cela aussi que je ne comprends pas.

                  Le système a tout ce qu'il faut, intrinsèquement, pour permettre cet accueil (/opt, mais aussi /usr/games et le compte associé, hein). Le système propose des outils franchement géniaux aussi pour ce type de cas (de la configuration par défaut des autotools, qui font attention par défaut au système, jusqu'aux possibilités de restrictions diverses). Les projets se décarcassent souvent pour finir un .spec dans leurs sources, voir même parfois passent des heures à construire plein de paquets, ou propose des binaires statiques [pas mal pour les versions beta]

                  Le seul point bloquant, c'est le packaging, ou plutot cette politique forcenée de packaging. N'est il pas possible de se dire simplement que le système ne devrait pas être en danger si l'utilisateur choisi firefox 4 beta ? Ne peux t on donc faire aucune concession sur la propreté théorique du système afin d'éviter des conneries pires, et de permettre (bis) aux utilisateurs d'avoir firefox 4 beta et de faire leur remontées avec l'outil prévu par la MoFo ?
                  • [^] # Re: Ça ne mérite pas une dépêche.

                    Posté par  . Évalué à 1.

                    d'où sort ce /usr/games ? pourquoi pas /usr/poney ?
                  • [^] # Re: Ça ne mérite pas une dépêche.

                    Posté par  . Évalué à 5.

                    Bon, disons que de MON expérience de mettre des linux sur les postes des michus (mme, m. et kevin), je suis très très perplexe sur le cas des versions récente des logiciels.

                    Je travaille avec debian, donc naturellement c'est un système que je connais bien, et c'est un système à base de debian que j'installerais, cela fait gagner du temps à la maintenance.

                    Avant je mettais pas mal de buntu, gnome pour faire le "simple" et des kde pour faire plus complexe. Avec le recul, je me suis aperçu,à l'usage des utilisateurs que j'avais, c'est que le besoin de la dernière version du logiciel est très très surfait : tu compiles la version 2 en mettant 4 dans le à propos et ils sont contents. Les michus utilisent seulement le "socle" de base du soft, et les nouveautés sont très très à la marge de leurs besoins. Et de plus en plus pour les grands parents michu, je mets un fluxbox. ou c'est chiant de faire le menu à la main, mais ils sont très content de s'y retrouver facilement. et je scripte un maximum de choses.

                    De plus mon _ressenti_ sur buntu, c'est que c'est assez bien fini en gros mais avec plein de petit trucs qui merdent à la marge. Alors si tu ne tombes pas sur le truc à la marge c'est cool, sinon c'est la merde. Je me souviens d'un buntu ou l'applet network-manager ne fonctionnait pas et qu'il fallait changer le réseau "en console", j'avais fait un script avec un lien dans le menu, mais c'est très chiant tous ses petits trucs qui viennent à l'utilisation, en découvrant au fur et à mesure de l'utilisation. Si en plus tu laisses ton utilisateur pouvoir faire des mises à jour tout seul, c'est le drame.

                    Maintenant je mets des debian stable, en expliquant que ce ne sont pas les dernières versions, mais des versions "stabilisées" qui seront maintenues 3 ans. Pour ceux que cela ne peut pas aller, je mets un testing et ceux qui aiment le risque je un "unstable", mais le unstable est figé sauf si je suis dans un rayon très proche.
              • [^] # Re: Ça ne mérite pas une dépêche.

                Posté par  . Évalué à 2.

                Euh... franchement je vois pas où tu veux en venir.

                La volonté légitime de l'utilisateur d'avoir un système stable avec des logiciels béta... c'est encore plus fort que les distros "grand public" (quoi? KDE4.6 est pas intégré alors qu'il est sorti au moins 2 jours avant la release??).
                Le beurre, l'argent du beurre...

                Si tu appelles ça une limite, OK, il y a une limite au système de paquet: on n'arrivera jamais à faire des paquets pour toutes les versions de dév, toutes les "nightly builds", etc.

                Enfin, quand je dis "foutre le bronx dans le système", je parle bien des bugs restants dans la béta.

                Si elle marche au poil, elle marchera tout aussi bien dans le répertoire de l'utilisateur, mais ne sera pas bien intégrée au système AVANT que le paquet soit validé.

                Si elle est foireuse, système de paquet ou pas, elle foutra le bronx...

                (Et merci au passage pour le rappel sur /opt dans l'autre commentaire, effectivement ce serait plus propre!!).
                • [^] # Re: Ça ne mérite pas une dépêche.

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

                  Là où je veux en venir, en essayant de résumé une idée non-finie :

                  Le système ne devrait pas contraindre l'utilisateur. (ne pas être obliger d'avoir tout son système en instable juste parcequ'il souhaite utiliser une version beta d'un soft mineur pour le système mais majeur pour lui)
                  Le système devrait savoir se protéger. (ne pas laisser un rpm de chrome faire ce qu'il veut en %pre %post et autre... seul le binaire et un menu sont intéressants...)
                  L'utilisateur devrait pouvoir installer firefox 4 beta sur son système stable, de manière simple (ne pas se contenter de coller le binaire, et ses libs, dans son ~/bin : c'est sale)
                  La distribution ne devrait pas avoir 'la responsabilité' de l'usage de ce binaire (pas de rapports de bugs à la distro valide pour ça, renvoyant ainsi la balle au projet quant il refuse des rapports parceque le binaire vient pas de chez eux.)

                  L'utilisateur il est tout jouasse : il a un système stable avec son fifi beta 245, même si ce fifi consomme plus de ram et est moins propre que celui livré de base.
                  L'adminisatreur, il est rassuré : le système n'est pas impacté. Si bronx il y a ça sera chez l'utilisateur, dans son home, sous sa responsabilité.
                  Le projet, il est content : il a des remontées directes de ses utilisateurs pour ses versions beta.
                  J'imagine la distribution rassurée : finie les requêtes incessantes "bouh firefox openoffice vlc sont antédiluvients", fini les rapports merdiques du gars ne disant pas que son truc il a installé depuis un dépôt obscur.
                  • [^] # Re: Ça ne mérite pas une dépêche.

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

                    Bonus : Quant fifi beta 245 merde, l'utilisateur pourra pas dire "debian merde" : il saura bien que c'est son fif beta 245, là. Ca ne vient pas de la distro.
                  • [^] # Re: Ça ne mérite pas une dépêche.

                    Posté par  . Évalué à 2.

                    Ça confirme un peu ce que je craignais: tu veux tout!

                    Le système doit prendre en charge des trucs venus de l'extérieur, mais sans les toucher (sinon on pourra plus faire les rapports de bugs), et tout en les empêchant de faire des trucs sales, le tout sans les avoir fait préalablement vérifier par un responsable de paquet.
                    Ça me semble impossible...

                    Si je comprends bien, ce que tu veux, c'est que la distribution arrive à prendre en charge en tant que paquet n'importe quel binaire qu'on lui soumettra?
                    Quel intérêt? Le but des paquets est de gérer des logiciels, gérer les dépendances, etc.
                    Quel intérêt de gérer les dépendances d'un binaire statique?

                    Autant installer les binaires fournis avec l'alerte "hé! nouvelle version dispo! t'en veux?" dans /opt.
                    Je ne vois pas ce qu'il y manque en dehors d'une prise en charge par la distribution pour laquelle tu es d'accord pour dire que ça ne devrait pas être sa responsabilité.

                    Un tel système va réinstaurer le fameux "logiciel téléchargé n'importe où sur internet" qu'on reproche au monde Windows.
                    Comment vas-tu éviter ça?
                    • [^] # Re: Ça ne mérite pas une dépêche.

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

                      Ca semble impossible... et pourtant.
                      Je le fais, tu le fais, et ça m'étonnerai que quiconque plus proche du code s'enquiquine à utiliser les packages de sa distribution pour le code sur lequel il participe.

                      Impossible ? hum ... bizarre.
                      • [^] # Re: Ça ne mérite pas une dépêche.

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

                        Je grossi le trait exprès oeuf2course.

                        Comme ajout, je le répête, je ne sais ce qu'il faut, ce qui est bon ou pas. Peut être simplement ajouter un compte adm par défaut, intermédaire, qui ai droit sur un rep particulier ? Simplement un howto ? La seule chose dont je sois sûr c'est que la situation bloque : Les utilisateurs veulent firefox / openoffice / vlc en version beta, parfois, souvent. Le bon côté c'est qu'ils font les remontées directement aux projets, ça tombe bien, des projets le demande. Et actuellement comme solution on a un "demerdez toi" ou un "utilise tout un système instable". C'est pas super, ni pour les projets, ni pour les utilisateurs. On va pas nous demander de devenir expert en c/lisp/c++/whatever, et exiger tout un système instable, pour rapporter que y a un bug de la gestion du presse-papier dans firefox, quant même ?

                        >où s'arreter ?
                        Là où la distro le décide.
                        • [^] # Re: Ça ne mérite pas une dépêche.

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

                          On peux prendre le problème par l'autre boût, aussi.
                          Y a très certainement des statistiques sur le nombre (voir mieux, un tri qa?) de rapports de bugs, afin de comparer entre : stable, testing et instable.
                          Y a que moi que ça choque autant de rapport de bugs sur la version stable ?

                          Et si on fait un tri plus fin, si c'est possible (?), je prends le parie que les rapports de bugs sur la version stable concernent en majorité... ce type de softs.
                          • [^] # Re: Ça ne mérite pas une dépêche.

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

                            (une fois les bugs triés entre bugs d'experts [suivant la sécurité, les correctifs du projet, etc] et bug de users [presse papier dans firefox par exemple] bien sûr. )
                  • [^] # Re: Ça ne mérite pas une dépêche.

                    Posté par  . Évalué à 1.

                    Tout a fait d'accord - Etre en 2010 et ne pas être en mesure d'installer deux versions du même logiciel (via le système de paquets) sur un même système (ou bien choisir l'emplacement ) m'a toujours étonné
                    • [^] # Re:Ça ne mérite pas une dépêche.

                      Posté par  . Évalué à 2.

                      En fait, il y a des logiciels pour lesquels tu peux, genre gcc ou le kernel.

                      Mais bon ce sont des cas isolés, il faut que ce soit prévu par la distribution,
                      du coup c'est limité.
                • [^] # Re: Ça ne mérite pas une dépêche.

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

                  Merci aussi à tous de vos réponses.

                  Je tenterai de mettre tout ça au clair pour moi, dans un nourjal prochain, avec ces nouvelles lumières.
      • [^] # Re: Ça ne mérite pas une dépêche.

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

        Lorsque le but est d'avoir un bureau grand public, y a pas photos.

        Comme beaucoup de gens dans le monde libre, tu as une vision totalement biaisée du grand public. Tu penses que le grand public, ce sont des geeks comme toi qui veulent la dernière nouveauté à la mode tous les 15 jours.

        Le grand public, il utilise même Windows 2000 si on lui donne un Windows 2000 sur son PC. Le grand public, il ne change pas d’OS tous les 6 mois.

        Il suffit de regarder la durée des cycles de release chez Microsoft : 3 ans, avec une maintenance qui s’étale sur presque 10 ans. Ne crois pas que cette durée soit calculée au hasard : c’est la durée de vie des produits informatiques en général, en particulier des matériels. Avec leurs 18-24 mois, Debian et RHEL ont déjà des cycles trop courts pour le grand public.
  • # Mauvais conseil

    Posté par  . Évalué à 7.

    Il est surprenant que l'auteur de la dépêche conseille l'installation de Chrome pour remplacer Chromium, pour au moins 2 raisons :

    * Il est très facile d'obtenir un paquet debian de Chromium pour squeeze.
    * Les conditions d'utilisation de Chrome sont parfaitement inacceptables.

    Pour le premier point :
    En tant que root :
    aptitude install devscripts pbuilder
    echo "deb-src ftp://ftp.fr.debian.org/debian/ sid main" >> /etc/apt/sources.list.d/src_sid.list
    apt-get update

    En tant qu'utilisateur:
    apt-get source chromium-browser
    cd chromium......
    sudo /usr/lib/pbuilder/pbuilder-satisfydepends-aptitude
    debuild -b

    On risque de devoir compiler de la même manière 1 ou 2 dépendances, mais rien de bien compliqué.

    Pour le second point :
    6.2 Vous acceptez que vos données soient traitées conformément aux règles de confidentialité de Google.
    Sachant que les règles de confidentialité sont susceptibles de changer sans préavis/

    7.3 Google se réserve le droit, sans toutefois s'y engager, de pré-visualiser, réviser, marquer, filtrer, modifier, refuser ou retirer tout ou partie du Contenu issu de tout Service.
    • [^] # Re: Mauvais conseil

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

      * Il est très facile d'obtenir un paquet debian de Chromium pour squeeze.

      J'éclate de rire quand je lis ton mode d'emploi "facile".
      Nous n'avons définitivement pas la même définition du mot "facile".

      Peux-tu fournir une version facile de comment obtenir chronium pour argumenter sur la facilité?

      On risque de devoir compiler de la même manière 1 ou 2 dépendances, mais rien de bien compliqué.

      Pour toi peut-être, pas pour beaucoup de monde.

      Pour le second point, entre télécharger un rpm et cliquer dessus avec un truc sur la vie privée qui dérange pas plus que ça et un mode d'emploi incompréhensible, le choix est rapide pour beaucoup de monde : pas celui que tu proposes.
      • [^] # Re: Mauvais conseil

        Posté par  . Évalué à 7.

        Tu n'as pas tout à fait tort.

        Cependant, l'une des beautés du logiciel libre est la notion de partage, et puisque je trouve facile de faire un paquet de chromium, je peux partager cela avec toi : http://jpinon.free.fr/make_chromium_for_zenitram.sh

        Voilà, plus qu'à lancer le script sous squeeze et attendre un peu, et tu auras de beaux paquets de chromium.

        De plus, dès qu'il aura fini de tourner chez moi, je pourrais proposer un joli dépot de paquets chromium pour squeeze.

        Le logiciel libre c'est bien , ça permet d'aider les copains.
      • [^] # Re: Mauvais conseil

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

        >>> J'éclate de rire quand je lis ton mode d'emploi "facile".
        Nous n'avons définitivement pas la même définition du mot "facile".


        Bah oui mais avec son pseudo tu t'attendais à quoi ?
      • [^] # Re: Mauvais conseil

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

        >J'éclate de rire quand je lis ton mode d'emploi "facile".

        pas moi.
        su -
        CTR-C CTR-V
        exit
        CTR-C CTR-V

        C'est pas la mer à boire.
        • [^] # Re: Mauvais conseil

          Posté par  . Évalué à 2.

          ben le truc que que zenitrounet, il sait que faire avec la souris en cliquant.

          :-)
          • [^] # Re: Mauvais conseil

            Posté par  . Évalué à 2.

            Je me rappelle avoir essayé Chrome en cliquant sur un .deb, pour Ubuntu. C'est pas possible avec Chromium et Debian ?

            DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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