Amélioration en vue pour l'installation de logiciel sur GNU/Linux.

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes : aucune
0
4
jan.
2007
Technologie
Qui n'a jamais été déçu de ne pas pouvoir installer la dernière mouture d'un logiciel annoncé ici même ?

Les systèmes de gestion de paquet que nous trouvons couramment dans nos distributions - comme apt-get ou urpmi - ont certes de nombreux avantages mais aussi des limitations. Il n'est par exemple pas simple d'avoir les dernières versions des logiciels et on se retrouve limité à la sélection des paquets de sa distribution ; or aucune ne propose l'ensemble des Logiciels Libres existants.

La nécessité de fournir des paquets binaires multi-distribution est encore plus demandée par les éditeurs de logiciels propriétaires désireux de fournir une version GNU/Linux.

Partant de ce constat, un groupe de travail a été formé au niveau du projet LSB (Linux Standard Base) et de son organisation parente le FSG (Free Standard Group) afin de rendre la vie plus facile aux utilisateurs et aux développeurs.
Des personnes-clés se sont rencontrées à Berlin le mois dernier pour discuter du futur système de packaging. L'approche retenue est de se baser sur l'existant et d'ajouter des ponts entre les systèmes de paquets habituels et les besoins des développeurs.

L'idée de base est d'ajouter une API commune dans les différent systèmes de paquets. Cette API permettrait à un logiciel de pouvoir s'enregistrer auprès du système de paquets.

Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.

Ainsi, si un projet cible une version donnée de la LSB et qu'il existe un installeur multi-distribution, la seule contrainte pour un utilisateur sera d'avoir une distribution qui supporte cette version de la LSB.

Tout n'est pas réglé car le problème n'est pas simple. Pour ceux qui sont intéressés, le FSG a créé un groupe de travail sur le sujet et vient de relancer une liste de discussion.

Aller plus loin

  • # Beurk

    Posté par  . Évalué à -1.

    "La nécessité de fournir des paquets binaires multi-distribution est encore plus demandée par les éditeurs de logiciels propriétaires désireux de fournir une version GNU/Linux."


    Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?

    Chaque distribution est libre de faire les risettes qu'elle voudra aux ogres qu'elle voudra séduire, mais je ne vois vraiment pas l'intérêt de standardiser dans ce secteur.

    Bonne chance à ceux qui essaieront : ils ne seront pas les premiers, ils ne seront sans doute pas les derniers.

    Au fait, Java, c'était pas sensé servir à ça aussi ?

    • [^] # Re: Beurk

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

      Le problème c'est qu'en embétant les logiciels propriètaire, on rend aussi la vie difficile aux utilisateurs de Logiciel Libres.

      Tu prend un logiciel, genre un jeu libre annoncé ici même. Il faut combien de temps avant de l'avoir dans les distros ? Il se passe des mois, voir des années.

      Donc bien sur tu t'en fou, probablement que tu compiles mais ici on parle bien d'utilisateur personnels qui n'ont ni l'envie, ni les compétences pour compiler.

      Donc contrairement à ce qu'on pense généralement, ce problème d'installation de logiciel sur GNU/Linux concerne aussi les Logiciels Libres.

      • [^] # Re: Beurk

        Posté par  . Évalué à 1.

        Je ne vois pas en quoi le fait de changer de format de paquetage binaire réduira le temps requis pour le réaliser ? Si personne ne veut faire le paquetage, le packetage ne sera pas fait. Dans le cas contraire, tout RPM est facilement adaptable sur la plupart des distributions essentiellement binaires, généralement basées sur RPM.

        Qui plus est, il ne faut pas avoir la mémoire courte : s'il existe autant de logiques de paquetages binaires que de distributions, c'est bien parce que, depuis que les distributions Linux à base de binaires existent, chacune d'elle, qu'il s'agisse de Redhat avec RPM (à l'origine du moins); de SuSE avec YAST ou de Mandriva avec ses trucs plus ou moins compatibles Redhat au débat et puis finalement non après ont essayé d'enfermer une partie des utilisateurs dans ses propres mécanismes.

        • [^] # Re: Beurk

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

          En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball. Sur windows, sur mac, c'est facile mais sur windows tu fais comment. Pour un petit projet c'est très compliqué que de fournir un paquet binaire ne serait-ce que pour les 5 distros les plus courantes.

          On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !

          • [^] # Re: Beurk

            Posté par  . Évalué à 6.

            En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball.

            Ben il suffit d'utiliser loki_setup (http://icculus.org/loki_setup/ ) jusqu'à ce que le projet devienne tellement intéressant que des volontaires se proposent pour créer des paquets.

            C'est ce qu'utilisent les éditeurs propriétaires sous Linux (Loki, id Software, Nvidia, Epic, Google, etc.) et ça marche sur pas mal de plates-formes (tous les Linux, FreeBSD, AIX, HP-UX, IRIX, SunOS/Solaris, Mac OS X, etc.).

          • [^] # Re: Beurk

            Posté par  . Évalué à 4.

            Une remarque : Firefox (les releases precoces, s'entend), Java, Flash-Téhème, etc, arrivent très bien à faire des paquetages binaires installables sur la plupart des distributions sans aller chercher à implanter leur gestionnaire de paquetages binaires à eux sur quelque distro que ce soit. Généralement, il suffit de compiler statiquement avec tout ce qui pourrait poser problème : c'est laid, mais ça marche. Mais il est vrai que la liberté qu'offre Windows à l'utilisateur de jouer à l'insu de son plein gré avec les librairies ne sera probablement pas atteignable avec un nunux.

            Ceci dit, si, concrètement, un auteur sympa de logiciels libres a du mal à réaliser un paquetage pour une dustribution donnée, ce qui se comprend tout à fait, ne pas hésiter à faire passer une petite annonce sur linuxfr (ou, au pire, s'adresser aux usual suspects, comme par exemple Mathias Saou de http://freshrpms.net/ pour Redhat/Fedora)

          • [^] # Re: Beurk

            Posté par  . Évalué à 9.

            tu n'as toujours pas compris le coeur du problème depuis http://linuxfr.org/~Zezinho/23367.html

            si l'auteur du projet/logiciel Bidule n'a PAS LE TEMPS ou SE FOUT de proposer des binaires plus ou moins prêts à l'emploi et si personne d'autre ne le fait à sa place, oui, il pourra rester "en souffrance" des années. et ça ne sert à rien de lui dire "mais utilise donc le format de paquets universel ABC" puisqu'il n'a déjà PAS LE TEMPS de le faire ou S'EN FOUT.

            tu as l'air de poser comme une évidence que c'est au développeur de faire ce sale boulot. soit. ce n'est peut-être pas son avis, ou alors il se fout - tout simplement - que monsieur ToutLeMonde ne puisse pas installer simplement son soft : les gens qui l'interessent y arrivent, il est content comme ça. les autres sont priés d'aller demander des paquets à leur distribution chérie, il estime qu'il a fini son boulot, il a une vie, tout ça.

            oui, ça peut surprendre, oui, ça peut choquer, mais c'est comme ça. les distributions règlent effectivement parfois directement ou indirectement (sections "contrib") le problème, mais pas toujours, certes.

            l'utilisateur final pleurniche ? la belle affaire, visiblement il ne sait faire que ça d'ailleurs. s'il veut que quelqu'un lui fasse un joli paquet cadeau de tel ou tel soft, et que l'auteur ne le fait pas, il pourra pleurnicher encore longtemps, ça ne va pas changer grand chose.

            tu pleurniches que l'utilisateur final pleurniche ? au boulot, bonhomme ! toi tu peux faire quelque chose. et si tu ne veux pas mettre la main à la pâte parce que EVIDEMMENT que c'est à l'auteur de le faire, je ne vois plus trop bien ce qui t'autorise à râler ainsi.

            • [^] # Re: Beurk

              Posté par  . Évalué à 2.

              En même temps si le truc s'intègre dans les autotools par exemple ça devient tout de suite plus simple.

              • [^] # Re: Beurk

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

                on voit rarement le mot "simple" associé avec les autotools :) alors que "bloatted","illisible" et "sux" ça revient beaucoup plus souvent

              • [^] # Re: Beurk

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

                Pour autoconf, pourquoi pas, mais automake je ne pense pas.

            • [^] # Re: Beurk

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

              Tu n'as pas compris que si certains projet Libre ne fournissent pas de paquets binaires pret à l'emploi c'est parce-qu'il n'y a pas de solution simple sur la plate-forme GNU/Linux pour faire ça.

              Si c'était simple à faire, et que ça marche bien tous les projets le ferait.

              • [^] # Re: Beurk

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

                Pas de solutions simples ? Qu'est-ce qu'il ne faut pas entendre...

                • [^] # Re: Beurk

                  Posté par  . Évalué à 2.

                  Ceci dit, abus de tutoriaux nuit rarement.

              • [^] # Re: Beurk

                Posté par  . Évalué à 1.

                Tu n'as pas compris que si certains projet Libre ne fournissent pas de paquets binaires pret à l'emploi c'est parce-qu'il n'y a pas de solution simple sur la plate-forme GNU/Linux pour faire ça.

                je vais t'aider :

                s'ils ne le font pas, c'est qu'ils ne le peuvent pas, ou bien encore qu'ils ne le veulent pas.

                je te rassure, il n'y a pas de solution compliquée^Wévoluée non plus qui puisse marcher. tout ce que klik et autres arriveront à faire c'est se transformer en solutions de distributions de logiciels prêts à l'emploi, comme Cygwin sous Windows, une distribution dans le système. ce n'est pas une totale idiotie, mais il y a des désavantages aussi et des problèmes prévisibles dès maintenant.


                et d'ailleurs tu sais très bien que les éditeurs de logiciels propriétaires arrivent à faire des bidules binaires prèts à l'emploi et qu'en fait ça se révèle être de la poudre aux yeux si tu grattes un peu le vernis de la réalité : là tu vois en fait que non, tu as des contraintes et des prérequis et que si ton Linux est un peu trop vieux il vaudra mieux en installer un plus récent sans trop chercher à comprendre. bouh ! pourtant eux ont les ressources qu'il faut. que passa ?


                Si c'était simple à faire, et que ça marche bien tous les projets le ferait.

                non. c'est un voeux pieux, ça, une prospective indigne de toi. et ce n'est même pas dit qu'ils trouvent que ça soit une bonne idée, tout simplement.

                d'ailleurs j'ai dit "pieux". tu as remarqué qu'il y a plusieurs religions du Verbe ici bas ? une seule ça serait plus pratique, je ne comprends pas pourquoi ces cons ne se mettent pas d'accord pour avoir une base commune avec des rites standardisés au maximum entre les trois religions et harmoniser, rendre compatibles leurs croyances, on économiserait sûrement beaucoup de papier en ayant un seul livre saint au lieu de trois. enfin bon, pour commencer il faudrait qu'on se mette tous à l'esperanto...

                pour commencer il faudrait faire le tour de tous les projets similaires, klik, autopackage et tous les autres. en choisir un au hasard et réunir les têtes pensantes de tous les autres dans une salle et balancer une grenade dedans. boum !

                parce que dans le genre "efforts dupliqués", ça pourrait être très marrant aussi : si une nouvelle version plus complète et pas trop bancale de la LSB sort (parce que Alan Cox avait ralé sur une version précédente, entre autres), et que tu te retrouves avec une demi-douzaine d'initiatives similiaires dans le genre de klik ou autopackage et que rien ne les distingue vraiment en terme de popularité ou de fonctionnalités, laquelle, toi développeur isolé, vas-tu choisir et donc soutenir ? et tous les autres projets vont faire le même choix que toi ?

                si tu crois qu'ils ne sont pas assez bêtes pour en arriver à ce genre de désastres pour des bêtes raisons de conflits internes, de politiques, de c'est moi le chef, de ta solution elle pue, de on n'a pas les mêmes objectifs donc deux projets c'est viable, tu te trompes lourdement.

          • [^] # Re: Beurk

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

            > On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !

            Sauf que la plate-forme propriétaire (windows) n'existe qu'avec 6 variations possibles (95, 98, 2000, ME, XP, Vista), avec une ABI relativement homogène et une compatibilité ascendante marquée.

            Tu retires toutes les distributions du monde sauf redhat, tu vires de celle-ci tous les noyaux sauf celui de base (et tu empeches bien sur de recompiler le sien), et tu auras une situation a peu près comparable...

            C'est la diversité le problème ici. Pas un seul producteur de logiciel ne peut gérer l'ensemble de la diversité des cibles Linux à lui seul (ou alors il faut faire plein de compromis, genre compilation statique par exemple). L'ensemble du système est basé sur une distribution des taches entre les producteurs de logicels, et les intégrateurs finaux qui publient les distributions. Quand les premiers cherchent à faire le travail des seconds, par exemple parce qu'ils refusent le droit de redistribuer a des tiers (cas des logiciels propriétaires), on aboutit a des résultats au mieux médiocre, au pire non-fonctionnels.

            • [^] # Re: Beurk

              Posté par  . Évalué à 3.

              (t'as oublié NT 4 et 2003, hin hin hin)

            • [^] # Re: Beurk

              Posté par  . Évalué à 3.

              En même temps pour continuer à utiliser des Windows 9x, il faut vraiment être un peu maso ou obligé de nos jours...

              • [^] # Re: Beurk

                Posté par  . Évalué à 7.

                s/9x//

              • [^] # Re: Beurk

                Posté par  . Évalué à 2.

                W9x ça marche super bien dans un émulateur ou sur un P166 : ideal pour les vieux jeux (ou pour tester des logiciels en environnement jetable). C'est presque un système léger de nos jours.

            • [^] # Re: Beurk

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

              Tu fais une bonne analyse de la situation, c'est la diversité qui pose problème. Il existe deux solutions :
              - on attend que le 'marché' décide et qu'une seule distribution devienne omnipotante. Tous le monde package pour celle là seulement les autres se retrouvent marginalisées. Ce n'est pas vraiment ce qui ce passe et ce n'est pas de mon point de vue souhaitable. La diversité c'est aussi notre richesse.

              - on définit une plate-forme logiciel que toutes les distributions auront à minima. Ensuite les projets peuvent cibler cette version et fournir un binaire qui s'installe partout. Rien n'empeche chaque distribution d'évoluer, d'innover, de faire mieux mais il fait une base commune fiable et bien définie.

              Par contre je ne suis pas d'accord avec toi sur le role obligatoire des tiers packageurs. C'est une option, c'est bien mais ne doit pas être un point de passage obligé, ni pour le logiciel libre, ni pour le propriétaire. Ce système à des avantages mais aussi de nombreux inconvénients qu'on cherche tous à se masquer. Un projet libre ou propriétaire doit fournir un paquet binaire prêt à être installé, quelque soit la plate-forme, c'est indispensable.

              • [^] # Re: Beurk

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

                Par contre je ne suis pas d'accord avec toi sur le role obligatoire des tiers packageurs. C'est une option, c'est bien mais ne doit pas être un point de passage obligé, ni pour le logiciel libre, ni pour le propriétaire. Ce système à des avantages mais aussi de nombreux inconvénients qu'on cherche tous à se masquer. Un projet libre ou propriétaire doit fournir un paquet binaire prêt à être installé, quelque soit la plate-forme, c'est indispensable.


                Je suis désolé mais c'est un non-sens complet.
                Tu n'es pas d'accord avec lui sur le rôle des tiers packageurs ? Donc, d'après les distributions ne servent à rien, il faudrait laisser le boulot d'installation binaires aux seuls développeurs des projets libres ?
                N'est-ce pas justement par manque de temps et de personnel compétent que tu trouves la situation déplorable, alors même que tu bénéficies pour GCompris d'un support largement supérieur à la majorité des projets libres !
                Un peu de décence et de cohérence ferait du bien...
                Tu ne peux pas vouloir défendre la diversité quand tu demandes précisément aux éditeurs de distributions de Linux de ne faire plus qu'un ou peu s'en faut.

                • [^] # Re: Beurk

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

                  Tu n'as pas compris ce que je veux dire. Bien sûr que les distributions sont importantes, indispensable même. Ce que je dis c'est que la distribution de logiciel à travers le système de paquet ne doit pas être la seule et unique façon de délivrer nos logiciels à nos utilisateurs.

                  Non ce n'est pas par manque de temps que la situation est déplorable, c'est parce que l'on a pas de solution qui permette la distribution de paquet binaire multi-distro. Au lieu de se plaindre du temps qui manque, il est bien plus efficace de mettre en place des solutions pour éviter les taches fastidieuses.

                  Je ne parle pas ici au nom de GCompris mais à travers mon expérience sur ce projet. J'explique en toute liberté les problèmes que je rencontre et des solutions qui me semble prometteuses. Mes arguments sont constructifs, dans l'objectif d'améliorer la plate-forme GNU/Linux, rien de plus.

                  La diversité c'est bien, je suis pour mais je suis aussi pour la simplicité. Ce qui est proposé par le LSB ne limite en rien les possibilités de différenciation et d'innovation des distributions, pour preuve c'est que les distributions majeures respectent déjà ce standard.

                  • [^] # Re: Beurk

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

                    Le problème est que cela semble encore à l'initiative d'Ian Murdock pour faire avancer Progeny qui ne décolle toujours pas et cela risque surtout, au vu des acteurs actuels, tourner surtout autour du format RPM sans aller voir plus loin.
                    Laissons leur donc le temps de travailler sur ce sujet mais j'ai bien peur qu'il ne s'agisse qu'une forme déguisée d'un vieux débat sur la compatibilité binaire contre la compatibilité source.

                  • [^] # Re: Beurk

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

                    Qu'est-ce qui t'empêche de renvoyer l'utilisateur auprès de celui qui a créé le paquet binaire, surtout s'il s'agit d'une distribution ? Voire de contacter directement le responsable en plaçant l'utilisateur en copie ?

          • [^] # Re: Beurk

            Posté par  . Évalué à 3.

            > En général les projets ne demandent pas mieux que de fournir des paquets
            > binaires en plus de leur tarball.

            En général les projets ont une vision centrée sur leur bébé, et sont prêts à massacrer le reste du système du moment que leur application fonctionne¹.

            Ceux qui sont prêts à prendre le recul nécessaire à une intégration sans douleur n'ont pas de problèmes avec les écosystèmes de paquets actuels.

            ¹ Phénomène évident sous Windows, entrainant des coûts monstrueux tant pour les utilisateurs finaux (qui doivent réinstaller périodiquement leur système sans raison) et les entreprises (qui dépensent des sommes monstrueuses juste pour vérifier que les installeurs fournis par leur fournisseurs ne vont pas mettre le boxon sur leurs postes de travail)

        • [^] # Re: Beurk

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

          https://www.redhat.com/archives/fedora-announce-list/2006-De(...)

          pour info, urpmi ça roxe sévère

      • [^] # Re: Beurk

        Posté par  . Évalué à 3.

        bien sur que compiler peut faire peur, mais si on change le mot compiler par installer c'est mieux non ?

        Ce que je veux dire, c'est que la partie compilation est de plus en plus simple, le configure vérifie tout, puis make et make install. Tout est quasi transparent si le boulot est bien fait et les progs installés dans /usr/local/. Après ça marche pas à tout le temps du premier coup, et parfois ça ne marche pas. Et c'est dans ce sens qu'il faut chercher.

        Je pense qu'il serait plus simple de travailler à faire des install.sh standards. Et un outil ou un script en plus du configure permettant de déterminer les librairies manquantes ainsi que leur place dans les distribs voir de les installer.
        Par exemple j'ai besoin d'un truc comme libjpeg.so, bah une simple recherche sur le site de debian me permet de trouver le paquet. (J'imagine que c'est la même chose pour les autres distribs).

        Après est-ce au LSB de définir ces principes, aux distributions d'offrir les outils ou à chaque développeurs de faire les leurs ?

        • [^] # Re: Beurk

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

          Ben voyons, on parle de grand public ici. Un compilateur n'a pas à être installé sur un PC grand public.

          • [^] # Re: Beurk

            Posté par  . Évalué à 7.

            On peut aussi se retrouver avec des problèmes de dépendances : la libtrucmuche qui manque, elle même dépendante de la libmachin qui n'existe pas dans la bonne version sur ma distrib.
            On en vient au final à rechercher/compiler tout un tas de bibliothèques (ça m'est récemment arrivé pour installer mumble). Je ne dis pas que c'est infaisable, mais ce n'est pas à la portée de tout le monde.

          • [^] # Re: Beurk

            Posté par  . Évalué à 6.

            ah c'est nouveau ça ?
            J'ai manqué un fondement fondamental de l'utilisation d'un PC par le grand public ?

            Je croyais qu'on parlait de la transparence d'installation d'un logiciel non disponible en paquet dans une distribution.

            Après que cette transparence soit effectuée à l'aide d'un compilateur, d'un aspirateur, ou d'un defibrillateur, quel est le problème ?

            En quoi un "bon" install.sh est différent d'un install.exe ?

            • [^] # Re: Beurk

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

              Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?
              Et des raissons que ça marche pas la compilation, c'est pas ça qui manque...

              • [^] # Re: Beurk

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

                Et puis c'est long... trop long pour par exemple, faire "juste un petit test"

                • [^] # Re: Beurk

                  Posté par  . Évalué à 0.

                  monsieur tout-le-monde il va être déçu-déçu-déçu quand on lui expliquera que pour faire un bébé il faut 9 mois et que ça sera pas "juste un petit test"

              • [^] # Re: Beurk

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

                >Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?

                Il remonte le problème au developpeur, comme il remonte le problème à sa distribution pour un paquet.

                • [^] # Re: Beurk

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

                  Non, si Ninux se "démocratise", 99,99% des utilisateurs diront "ça marche pas" et n'irons pas voir plus loin.

                  Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                  • [^] # Re: Beurk

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

                    >Non, si Ninux se "démocratise", 99,99% des utilisateurs diront "ça marche pas" et n'irons pas voir plus loin.

                    Donc c'est bon alors, pas besoin de s'embeter ;)

                  • [^] # Re: Beurk

                    Posté par  . Évalué à 1.

                    bah euh qu'ils crèvent ? si mon téléphone est coupé et que je me contente d'attendre que ça marche, ça risque d'être long si c'est un incident sur la ligne parce qu'un guignol a débranché la mauvaise boucle.

                • [^] # Re: Beurk

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

                  Ce serait normalement le rôle du responsable du paquet de la dite distribution de remonter le problème aux développeurs amonts s'il s'avère que le problème n'est pas propre à la distribution. Là, ce responsable est quand même mieux placer que l'utilisateur pour en déterminer la pertinence.
                  En outre, il suffirait que les développeurs amonts n'attendent pas que les responsables de paquets les contactent pour régler des problèmes et se pré-occupent davantage de la qualité de communication entre eux (du moins, pour ceux qui se pré-occupent déjà de leurs utilisateurs).

              • [^] # Re: Beurk

                Posté par  . Évalué à 3.

                Pourquoi dis tu que compiler doit etre une opération réalisée par des spécialistes?
                Comme le dis hokata, quelle est la difference entre un bon install.sh et un install.exe, moi j'en vois une des difference.
                La premiere, c'est une installation d'un logiciel via un intrepreteur, la seconde c'est l'instalation d'un logiciel par un executable.
                La premiere solution me parait mieux adapté, tous du moins d'un point de vue philosophique, puisque sur un systeme libre il peut etre interesant de pouvoir ( l'utilisateur lambda, n'est pas olbligé) controler le traitement d'installation complétement.
                Avec la solution binaire d'installation, qui arrive au meme résultat, la seulle difference reside dans le fait que personne ne sais ce qui ce passe.
                Je pense donc que la compilation, si elle est réalisé par un bon script, est une solution tous au moins aussi valable que l'instalation par un package binaire.
                Le problème reside plus dans le nombre de distribs differentes.
                Qui a dis que l'installation etais plus facile sous l'os proprio de redmond?
                Une experience sous cet os (obligé de metre un SP pour installé un anti-virus, j'install le SP, l'anti-virus s'install correctement, mais l'appli metier ne fonctionne plus).
                Je dis peut etre des betisses, mais un soft libre doit etre livré avec son code source. c'est peut etre pas plus mal, si ce code source est utilisé pour installer ce logiciel.

                • [^] # Re: Beurk

                  Posté par  . Évalué à 5.

                  Tu ne peux pas penser ce que tu dis...

                  - Compiler c'est long. Très long. Beaucoup plus long qu'une installation de binaires, à volume égal de logiciel. Les gens normaux n'ont pas que ça à faire.

                  - La compilation peut rater pour tout un tas de raisons (parceque c'est une compilation, c'est un bouclier anti-erreurs donc c'est bien à ce niveau que les problèmes sont censés apparaître), ou même donner un binaire foireux même quand elle réussit, et l'utilisateur lambda est alors TOTALEMENT LARGUÉ sur ce qu'il faut faire pour que ça marche. Tu n'apprendras jamais à madame Michu à utiliser un débugueur...

                  Philosophiquement, oui, le code source est le moyen idéal de distribuer un logiciel libre. Mais se limiter à ce point de vue c'est aussi limiter l'audience potentielle du logiciel à ceux qui partagent son point de vue. Tout le contraire de l'ouverture, c'est une fermeture.

                  • [^] # Re: Beurk

                    Posté par  . Évalué à 0.

                    "chez moi ca marche, lance ce compile.sh chez toi"
                    (...) "ca marche pas, ca dit que lib not found"
                    "bah installe ton systeme comme le mien sinon on ne va pas y arriver"
                    "non je peux/veux pas" <--- là ! bug !
                    "bon ben débrouille toi je ne peux rien faire de plus"

                    madame Michu elle est bien gentille mais il faut bien qu'elle mette sa bécane en phase avec le reste du monde, tant mieux si c'est transparent pour elle.

                    • [^] # Re: Beurk

                      Posté par  . Évalué à -1.

                      La bonne démarche dans ce cas serait plutôt de ne pas lui faire compiler quoiquecesoit (surtout si toi tu l'as déjà fait !) mais de lui donner un beau paquet bien propre que tu lui feras gentiment partager (par exemple un .deb généré les doigts dans le nez par checkinstall).

                      Si pour toi mettre sa bécane en phase avec le reste du monde signifie s'installer tout un environnement de développement qui mouline pendant de longues minutes, participe activement au réchauffement planétaire et envoie des messages d'erreur bizarres (car la configuration de madame michu n'est pas une configuration de développement par définition, c'est une distribution orientée poste de travail...) que seul un initié peut comprendre... Alors bonjour la duplication des efforts, et bonjour le boulot pour le pauvre zigue qui accepte de se taper le support technique et des remarques telles que "c'est quoi cette histoire de libmachin ??? Moi je veux juste XXX ! je comprends rien, c'est tout un foutoir pour installer un tout petit logiciel, c'est nul ton linux, [...]".

                      Je maintiens que la compilation n'est pas une opération à faire réaliser à tous les utilisateurs, seulement à ceux que ça intéresse (et éventuellement ceux qui n'auraient pas le choix, mais c'est un autre problème : il est extrêmement dommage de ne pas avoir le choix, quand il s'agit de logiciel libre...).

                      • [^] # Re: Beurk

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

                        Les libertés des utilisateurs s'arrêtent là où commencent celles des développeurs, sachant que ce sont ces derniers, via les licences libres, qui accordent des droits et libertés sur les logiciels libres qu'ils développent.

                      • [^] # Re: Beurk

                        Posté par  . Évalué à 1.

                        là c'était pour le cas où madame Michu tenait à garder un bidule pas très répandu ou resté à une vieille version, contrairement à toi et au reste du monde. installé par son fiston et qui a le malheur de marcher juste assez bien pour elle. sauf que son Iceturd est troué, par exemple.

                        là tu parles d'un .deb, fort bien, et si elle n'a pas Debian ou clone ? tu vas lui dire d'installer le même système de toi puisqu'elle vient te demander ton expertise et sinon tu lui diras que tu ne peux pas l'aider plus que ça, même si oui tu l'aimes bien

                        que ça pête à la compilation parce que libmoisi.a n'est pas là ou que ça pête à l'installation ou l'utilisation parce que libmoisi.o n'est pas là, c'est pareil. c'est juste plus ou moins rapide - et pénible - pour s'en rendre compte.


                        par contre je note un énorme problème de compréhension chez toi ou plutot une bonne prise de vessies pour des lanternes, parce qu'on parle de logiciel libre ou d'une plateforme libre il serait extrement dommage qu'un utilisateur lamba ne puisse pas en profiter sans le moindre effort de sa personne, de quelque nature que ce soit (financière, discernement dans le choix du matériel ou de son Linux, acquisition d'un minimum de connaissances même de base comme "tu cliques là pour éteindre l'ordinateur, pas sur le bouton on/off"). oui, ça serait dommage. mais bon.

                        j'ai l'impression qu'une fois que quelqu'un code 3 lignes dans son coin et que ça marche chez lui, ça devient magiquement un droit divin pour lui que le reste du monde puisse automatiquement en profiter sans que lui fasse le mondre effort supplémentaire - après tout, il est un codeur, il ne va pas perdre son temps avec des détails bassement matériels comme savoir si ses utilisateurs peuvent utiliser son logiciel - et que ça marche partout tout seul sans jamais aucun problème.

                        100 balles et un Mars aussi ?

              • [^] # Re: Beurk

                Posté par  . Évalué à 0.

                Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?
                Et des raissons que ça marche pas la compilation, c'est pas ça qui manque...

                les utilisateurs de Gentoo sont des spécialistes, CQFD...

                ou pas. donc il y a un problème dans ton raisonnement.

                • [^] # Re: Beurk

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

                  Même pour Gentool il y a un travail à faire avant de pouvoir compiler. c'est pas la même méthode que pour rpm et dpkg mais ça change rien au problème. Comment fait un utilisateur si personne n'a fait ce travail.

                  Ensuite demander à tout le monde de recompiler tout n'est pas une option car c'est trop long.

          • [^] # Re: Beurk

            Posté par  . Évalué à 10.

            Pourquoi? Parce que c'est un outil trop compliqué pour lui? On ne lui demande pas de s'en servir, ni même de l'installer volontairement, on suggère simplement qu'il soit installé par défaut (ainsi que les includes des librairies les plus courantes) pour simplifier au maximum l'installation de paquets sources. Et, effectivement, c'est peut-être une des meilleures solutions : si on arrive à empaqueter toute la procédure du configure/make/makeinstall dans une seule commande (voire une interface graphique), on offre ainsi la possibilité à tout utilisateur de Linux d'installer du bleeding-edge sans se casser le c*l. Si en prime on ajoute à ça un système efficace de remontée des bugs, c'est la fête du slip.

            Si on peut faire cela sans rien changer aux tarballs (il suffit d'avoir un wrapper un peu malin sur la machine qui sache détecter un projet autoconfé et appeller les bonnes commandes au bon moment), ça pourrait valoir le coup de rajouter un petit fichier descriptif, genre LSM, qui indiquerait les différentes options utilisables, l'adresse e-mail pour remonter les bugs, etc.

            En fait, tout ça ressemble violemment à un .ebuild (les scripts de compilation de Gentoo), mais l'idée serait de dissocier cela d'un système de port pour l'intégrer dans la tarball. Comme ça, un outil fait pour (et personnalisé pour coller à la distro - qu'elle soit compatible LSB ou pas, c'est son problème) pourra facilement détecter que la tarball est utilisable, proposer éventuellement à l'utilisateur de configurer quelques options (s'il le souhaite, par exemple via un mode "expert") et lancer la compilation et l'installation. Dans l'idée, un tel système pourrait aussi reprendre d'autres idées de Gentoo, comme la sandbox à la compilation, pour éviter qu'une tarball malicieuse ne sème la pagaille.

            Pour moi, la principale difficulté (hors le fait de définir ce que l'on veut, mais il est toujours possible de partir d'un .ebuild simple et d'affiner le système avec le temps) vient de la gestion des dépendances. Il faudrait effectivement un moyen pour ce système de savoir ce qui est disponible sur la machine, ce qui peut-être fait via les gestionnaires de paquetages, mais pas de manière portable.

            En revanche, ça n'apporte aucune aide aux paquets propriétaires. Mais pour aider à la diffusion de paquets libres, ça pourrait le faire, non?

            • [^] # Re: Beurk

              Posté par  . Évalué à 3.

              Je vais faire mon vieux con ©. Un profane qui ne programme pas sur sa machine ne devrait pas avoir à y installer un compilateur, ne serait-ce que d'un point de vue sécurité : compiler un rootkit quand le compilateur est déjà accessible est quand même bien plus facile que s'il faut d'abord faire tout un tas de contorsions pour récupérer les droits root.

              Pour le coup du « bleeding edge », je n'y crois pas du tout : par définition, sauf à avoir vraiment blindé le programme pour pouvoir s'installer partout (et à ce moment-là, s'agit-il encore de « bleeding edge » ?), il y a *toujours* un risque de plantage lors de la compilation. Et ton utilisateur, il se retrouve toujours très bête.

              • [^] # Re: Beurk

                Posté par  . Évalué à 3.

                GCC disponible sur la machine d'un profane ça permet de compiler dynamiquement des modules kernels sans lui broyer les noix (ex: dkms)

              • [^] # Re: Beurk

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

                gcc ne fournit pas des tarballs binaires de gcc à des fins de bootstrapping ?

                • [^] # Re: Beurk

                  Posté par  . Évalué à 1.

                  si, si, mais la premiere chose à faire avec c'est le recompiler (ou un plus récent)

              • [^] # Re: Beurk

                Posté par  . Évalué à 4.

                Pour la sécurité, autant je trouve ça important sur un serveur, ou de manière général un système en production (disposant d'un administrateur capable de réfléchir un tant soit peu sa politique de mise-à-jour), autant c'est limite de l'enculage de mouche sur une machine personnelle. Typiquement, sur un système dont le propriétaire est potentiellement capable d'éxécuter n'importe quel script en root (parce qu'on le lui a demandé et qu'il a le moyen de le faire, mais pas de savoir si c'est raisonnable ou non), s'interdire d'avoir un compilateur me paraît un peu vain. Si la chose est inutile, c'est toujours mieux de s'en passer, mais de là à refuser les solutions source-based sous prétexte que le compilateur représente un risque...

                Quant au plantage à la compilation, sur des vraies releases (je parle pas non plus de faire ça sur du CVS/SVN), ça me paraît relativement fiable. Il suffit de voir le nombre de paquets Gentoo qui compilent très bien partout. Après tout, c'est le mainteneur du logiciel qui serait chargé de définir les caractéristiques de son bébé, et c'est probablement le plus apte à le faire. Au pire, il peut toujours indiquer dans son paquet un niveau de "fiabilité" de la chose, qui pourrait même être évalué automatiquement par un système de remontée automatique et anonyme des erreurs de compilation.

                • [^] # Re: Beurk

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

                  Par plantage, il faut souvent comprendre « problème de dépendances de compilation » que l'utilisateur débutant a du mal à cerner aux vues des nombreuses questions sur le sujet qui pollue les listes et autres forums.

                  • [^] # Re: Beurk

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

                    Ca peut même être assez vicieux, du genre la librairie X est bien là, et dans la bonne version, mais manque de chance elle a été compilée avec une option incompatible avec le soft Y que l'utilisateur veut installer...

                    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

                • [^] # Re: Beurk

                  Posté par  . Évalué à 1.

                  Typiquement, sur un système dont le propriétaire est potentiellement capable d'éxécuter n'importe quel script en root (parce qu'on le lui a demandé et qu'il a le moyen de le faire, mais pas de savoir si c'est raisonnable ou non), s'interdire d'avoir un compilateur me paraît un peu vain

                  d'autant que les rootkit ne s'embetent pas et téléchargent un compilateur pour continuer leurs conneries...

                  • [^] # Re: Beurk

                    Posté par  . Évalué à 1.

                    Vouiche. En plus, même pas besoin de se traîner le gros GCC : un simple TCC fait aussi bien l'affaire, et pour largement moins lourd.

                • [^] # Re: Beurk

                  Posté par  . Évalué à 2.

                  > Pour la sécurité, autant je trouve ça important sur un serveur, ou de manière
                  > général un système en production (disposant d'un administrateur capable de
                  > réfléchir un tant soit peu sa politique de mise-à-jour), autant c'est limite de
                  > l'enculage de mouche sur une machine personnelle.

                  Je vois que le monsieur n'a jamais reçu de SPAM émis par les machines personnelles des défenseurs des mouches.

                  • [^] # Re: Beurk

                    Posté par  . Évalué à 4.

                    Je ne dis pas que la sécurité est inutile sur une machine personnelle, je dis juste que se priver de l'usage d'un compilateur sur un tel système alors que des tonnes d'autres failles potentielles (à commencer par l'utilisateur) existent, c'est du FF (fly-fucking, oeuf corse).

                    Si le pirate veut compiler du code sur ta plateforme, il n'a qu'à balancer un binaire de TCC, et c'est parti. Tu n'arrêteras pas grand monde en ne mettant pas GCC. Encore une fois, mettre un compilo là ou il ne sert à rien, c'est ballot. Mais se priver des services qu'il peut apporter pour des questions de sécurité, ça l'est autant.

    • [^] # Re: Beurk

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

      Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?
      Certes, c'est demandé par les distributeurs de logiciels propriétaires, mais ca serait aussi un grand confort pour tous les utilisateurs de logiciels libres : l'utlisateur lambda de mandrake, ubuntu ou fedora il a une distribution à base de binaire, et qu'ils soient proprio ou pas, le problème est le même.
      Et puis bon franchement, voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.

      • [^] # Re: Beurk

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

        voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.

        Mais est-ce que ce n'est pas ça qui fait la différence entre un logiciel "posé là" avec une entrée de menu sans icône dans "Autres" et un logiciel bien intégré à la distro ?

        • [^] # Re: Beurk

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

          Il existe déjà un mécanisme standardisé par le freedesktop pour qu'une application précise ou son menu doit être placé. Les différentes catégorie sont déjà définie. Je ne vois pas trop la valeur du packaging de la distro la-dessus.

          C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !

          • [^] # Re: Beurk

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

            C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !


            Si le logiciel fourni un fichier .desktop alors l'entrée sera toujours dans le même menu, quelque soit la distro et quelque soit l'environnement.

            D'ailleurs, il faut absolument penser à valider les fichier .desktop car c'est souvent la faute à l'auteur si l'entrée est mal faite.
            http://www.freedesktop.org/wiki/Software/desktop-file-utils

          • [^] # Re: Beurk

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

            Oui, mais c'est recent, au cours des 10 années précédentes chaque distib avait fait son système et je ne pense pas que toutes aient fait la migration vers le support des .desktop...
            De plus, tous les Window Manager ne supportent pas encore les menus freedesktop.

  • # Difficile

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

    Le problème est qu'on parle toujours des dépendances sans réellement réaliser qu'elles sont complètement différentes d'un système à un autre. Certains gestionnaire de paquetages peuvent "suggérer" l'installation d'autres paquetages. Des logiciels ont été divisés en plusieurs parties dans certaines distro (libifiés, par exemple), dans d'autres non. Je ne vois vraiment pas comment on peut résoudre tous ces problèmes sinon en contraignant toutes les distros à se ressembler complètement.

    • [^] # Re: Difficile

      Posté par  . Évalué à -1.

      C'est bien là tout le problème.

      Dans les systèmes de paquets actuels, chaque paquet informe des capacités qu'il fournit, et de celles dont il a besoin.

      Il suffirait d'avoir un système de description des capacités standard, entre deb et rpm.

      Le problème c'est qu'il y a surement trop de boulets intaigristes pour y parvenir.

      • [^] # Re: Difficile

        Posté par  . Évalué à 7.

        C'est un peu plus compliqué que ça.

        Les distributions proposent par exemple des granularités différentes : pour une même application (par exemple PHP) certaines vont par exemple fournir un gros paquet fourre-tout alors que d'autres vont proposer un paquet de base et un ensemble de paquets complémentaires (paquet de headers, pour tel ou tel module, etc.).
        Le choix de granularité est un choix fort de chaque distribution. Le leur retirer serait pénalisant.

        De manière plus générale, la valeur ajoutée apportée par chaque distribution est l'un des gros points forts du monde du logiciel libre. Tout standardiser en gommant leurs spécificités poserait le problème de la création d'une distribution de Linux/*BSD/autres unique qui proposeraient toutes la même chose.

        C'est un peu le même problème que le monde UNIX a pu affronter sauf que la compatibilité au niveau sources a déjà rendu la situation beaucoup plus saine.

        En tout cas, je souhaite bien du courrage au groupe de travail LSB qui s'attèle à un problème bien compliqué.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Difficile

          Posté par  . Évalué à 2.

          Il suffit de faire un système de description standardisé, que tel ou tel paquet fournisse telle ou telle capacité importe peu.

          Le problème c'est que pousser le découpage trop loin rendrait caduc les systèmes de capacités définis.

          Comme je disais, ce genre de choses nécessiterait un minimum de compromis entre les différents acteurs, et quand on voit les trolleurs que compte la communauté on est pas rendu, et c'est bien dommage. Il suffit de lire la suite des commentaires.

          Rendre inter-opérable deb et rpm est simple du point de vue technique, le choix de l'inter-opérabilité est un choix purement politique qui doit être fait par les développeurs principaux de Debian, Gentoo, Redhat, Mandriva, Ubuntu et Suse. Il suffirait que Debian et Redhat se mettent d'accord pour que les autres suivent.

          En tant qu'entreprise, Redhat y a tout intérêt. Debian a l'air de sortir de son extrémisme depuis peu (a mauvais escient je trouve, mais c'est le cas). On peut espérer que ça arrive un jour.

          J'ai du mal à comprendre que d'un côté la communauté gueule pour l'inter-opérabilité des formats de fichiers, et que d'un autre côté elle ne fait pas de même avec ses paquets.

      • [^] # Re: Difficile

        Posté par  . Évalué à 1.

        Ne serait-il pas possible d'avoir un paquet dans une sorte de format intermédiaire contenant les sources et une descriptions des bibliothèques requises, qui pourrait être transformé en rpm ou deb ou... adaptés à chaque distrib ? Cet outil de "transformation" serait à développer par la distrib.

      • [^] # Re: Difficile

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

        À noter que le système Debian se trouve actuellement confronté (ou le sera très bientôt) à un problème de pertinences avec les outils de recherche se basant uniquement sur les noms et descriptions de paquets.
        À tel point qu'un développeur Debian, Enrico Zini, a décidé de mettre en application les travaux d'un mathématicien et bibliothécaire indien, Shiyali Ramamrita Ranganathan[1], avec DebTags[2]. Si le format RPM pouvait adopter ce système de tags (tout comme celui de Debconf d'ailleurs), il y a gagnerait en fonctionnalité et les deux systèmes y gagnerait en harmonie.
        Il n'y a pas qu'APT qui soit un bon système chez Debian.

        Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.

        [1]: http://fr.wikipedia.org/wiki/Shiyali_Ramamrita_Ranganathan
        [2]: http://debtags.alioth.debian.org/

        • [^] # Re: Difficile

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

          Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.

          Heu tu exageres un peu. RPM _supporte_ les dépendances sur des fichiers mais c'est très rarement utilisé et c'est fortement déconseillé.

          Je sais que sur Mandriva ca arrive dans un cas : quand ton cas contient des scripts, à la construction du package ca regarde les shebang et ca ajoute les interpretaurs comme dépendance. Quand l'interpréteur est présent sur la machine de build ca met une dépendance vers son package, sinon ca met vers le fichier. Donc on se retrouve avec une dépendance vers le fichier si on a oublié de mettre l'interpréteur comme dépendance de build et pas mis la dépendance à la main en ajoutant un ignore sur celle là.

          Le seul cas ou je ne sais pas comment éviter c'est dans les scripts de pre/post/... ou rpm met tout seul un require sur le fichier de l'interpreteur. La plupart des packages ont donc une dépendance vers /bin/sh, et en plus elle apparait plusieurs fois par packet (pour dire qu'on a besoin de lui en pre, en post, ...).

          Sur les 1789 installés sur ma machine :
          [pterjan@plop tmp]$ rpm -qa --requires | grep / | sort | uniq -c | sort -nr
          969 /bin/sh
          878 /sbin/ldconfig
          41 /sbin/install-info
          26 /usr/sbin/update-alternatives
          8 /usr/bin/perl
          4 /sbin/chkconfig
          3 /usr/sbin/groupadd
          3 /bin/awk
          3 /bin/ash
          2 /usr/sbin/update-ldetect-lst
          2 /usr/bin/tr
          2 /usr/bin/python
          2 /etc/pam.d/system-auth
          2 /etc/init.d
          2 /bin/sed
          1 /usr/share/autotools/ac-wrapper.pl
          1 /usr/sbin/useradd
          1 /usr/sbin/glibc-post-wrapper
          1 /usr/sbin/chkfontpath
          1 /usr/sbin/arping
          1 /usr/bin/run-parts
          1 /usr/bin/ruby
          1 /usr/bin/rrdcgi
          1 /usr/bin/env
          1 /usr/bin/cmp
          1 /usr/bin/chage
          1 /sbin/service
          1 /sbin/pidof
          1 /sbin/ip
          1 /sbin/fuser
          1 /etc/libuser.conf
          1 /bin/touch
          1 /bin/rm
          1 /bin/grep
          1 /bin/gawk
          1 /bin/egrep
          1 /bin/csh
          1 /bin/bash


          Quelques un sont des bugs mais la plupart ne sont que du bruit vu que c'est fourni dans le basesystem.

          • [^] # Re: Difficile

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

            J'exagère à peine : il n'y a qu'à regarder les require de la majeure partie des paquets RPM. Il suffit souvent de disposer du fichier adéquat pour que le RPM accepte de s'installer. Ce n'est pas simplement rare, c'est largement utilisé.
            Et quand on donne le choix aux utilisateurs, c'est comme des électrons, ils choisiront le chemin le plus court (comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).

            • [^] # Re: Difficile

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

              Ben justement j'ai regardé tous les packages de ma machine. Et il ne suffit pas que le fichier existe pour que le rpm accepte de s'installer, il faut qu'il soit fourni par un rpm installé !
              La dépendance ne se fait pas sur la présence de fichiers sur le système, c'est juste que en quelque sorte les rpm provident tous les fichiers qu'ils contiennent. rpm n'utilise que sa db pour résoudre les dépendances, pas la présence physique de fichiers...

              [root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
              erreur: Dépendances requises:
              /tmp/foo est nécessaire pour test-1-1mdv2007.1.i586
              [root@plop SPECS]# touch /tmp/foo
              [root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
              erreur: Dépendances requises:
              /tmp/foo est nécessaire pour test-1-1mdv2007.1.i586

              • [^] # Re: Difficile

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

                Hummm, au temps pour moi, c'est à la génération du paquet RPM qu'il exploite le ldd et les shells utilisés. Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.

                • [^] # Re: Difficile

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

                  Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.
                  Oui c'est pourquoi il existe des systèmes de build. SUSE en a un, Mandriva aussi, je suppose que Fedora aussi mais je ne sais pas.
                  Tu donnes un src.rpm ou un spec + des fichiers sources et ca te rebuild et check le package avant de l'uploader.
                  Celui de Mandriva actuellement, tu commites tout dans le svn et quand ton package te parait OK tu demandes à ce qu'il soit uploadé, ca sort les trucs du svn, genere un chroot, installe les dependances de build et génère le package. Si tout c'est bien passé en i586 et x86_64 et que rpmlint n'indique pas d'erreur bloquante, c'est uploadé.

            • [^] # Re: Difficile

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

              comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).
              Et j'avais oublié de répondre à cette partie.
              Ca serait con de faire un ldd à la main pour ajouter des dépendances vers des fichiers quand mieux est déjà fait automatiquement.
              C'est fait lors du build du rpm par des scripts d'ajout de dep automatique, et ils mettent pas le nom de fichier de la lib mais son soname. Quand on package des libs ça ajoute aussi automatiquement la fourniture du soname des libs inclues dans le package (les dépendances vers les modules perl sont aussi automatiques ainsi que quelques autres choses...)

              Donc pourquoi les gens s'embeteraient ils à faire à la main des dépendances vers des fichiers plutot que d'avoir de dépendances automatiques propres ?

    • [^] # Re: Difficile

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

      Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.


      Donc les dépendances sont relatives à ce qui est défini dans la LSB, pour le reste, faut packager avec l'application.

      Ca risque de faire de gros packages, des duplications de librairies sur la machine, une utilisation plus importante de la mémoire... mais ça retire le "dll hell" - d'ailleurs il me semble que c'est sur cette voie que se sont lancés MacOS et Windows.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Difficile

        Posté par  . Évalué à 6.

        Hormis le fait qu'os X est contrôlé par une seule entité (apple) :

        mac os X met à disposition un "framework" de développement très complet

        (le fameux "cocoa" et sa myriade de kit/core associés et Carbon)

        du coup, c'est très rare qu'un développeur sur os X ait subitement besoin d'une bibliothèque exotique

        quand c'est le cas, il est en effet d'usage de l'intégrer DANS le "bundle" de l'application
        (une application os X est un dossier qui peut contenir en plus du binaire des éventuelles bibliothèques, icones, etc)

        il arrive donc que des programmes os X intègrent la même bibliothèque populaire parce qu'Apple ne propose rien encore d'équivalent. Un cas classique c'est quand les développeurs veulent imiter un aspect des logiciels d'Apple qu'Apple n'a pas encore standardisé dans os X.

        dans les faits c'est rare (cocoa/carbon est tout de même très complet) et d'expérience, je n'ai pas ressenti que les programmes Mac prenaient une taille démentielle en comparaison de ceux de Linux.
        Cela dit, si vous en êtes encore à compter les octets, oui os X n'est pas optimisé pour économiser le disque dur, mais conçu pour simplifier la vie des utilisateurs et des développeurs sans pour autant tomber dans un délire à la windows.

        il faut bien réaliser qu'apple ,à chaque version d'os X, a agrandit "cocoa" , pour que tous les besoins des créateurs de programmes soient couverts. du coup, les développeurs n'ont pas eu besoin de partir dans le "dll hell" de windows.

        un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc


        (j'ai utilisé le terme "cocoa" dans son sens le plus large, les puristes sépareront peut être Webkit, webcore , core-data, core-image, core-bidule etc de "cocoa" , mais dans la pratique , le tout forme une plateforme couvrant presque tous les usages ce qui limite le besoin d'une gestion de paquetages provenant de multiples sources)


        bref, vla pourquoi os X n'a pas dégénéré en dll hell malgré son manque d'un véritable système de paquetage et dépendance.

        • [^] # Re: Difficile

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

          un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc


          Bha KDE fait ça.

          Qt et les kdelibs fournissent un "framework" de développement très complets.

          Les programme kde n'ont en général pas besoin d'autres dépendances.

  • # .

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

    Il existe http://autopackage.org qui marche déjà pas trop mal. Avec interface graphique et tout. En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers.

    • [^] # Re: .

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

      "En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers."

      Hum, c'est pas si évident malheureusement. Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr donc autopackage est obligé de se mettre dans /usr au milieu des logiciels de ta distro.

      Le problème vient principalement des menus et des type mime. Il y a des répertoires centralisés pour eux donc obligation de les respecter.

      Mais oui clairement autopackage n'est pas la panacée mais c'est mieux pour un projet de livrer ça que juste un tarball. Au moins un utilisateur lambda à une chance de pouvoir utiliser ton logiciel.

      • [^] # Re: .

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

        > Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr

        Ah bon ? Pourquoi ?

        Normalement il est prévu qu'on puisse installer des logiciel ailleurs. C'est à ça que servent les variables d'environnements $PATH, $LD_LIBRARY_PATH, $XDG_DATA_DIRS (cette dernière est justement utilisée pour les menus et les types mimes)

        • [^] # Re: .

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

          La réponse en anglais sur le site de autopackage http://autopackage.org/faq.html#2_3

          En gros, ça marche pour certaines distro, pas pour d'autres. Ils ont dont choisi de se fixer sur /usr ca c'est ce qui marche le mieux.

          • [^] # Re: .

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

            Oui mais c'est ce qui présente également le plus de risque de conflits avec le système installé et la gestion de paquets.
            Je préfère encore que les utilisateurs compilent leurs logiciels à la ./configure; make; make install, au moins, ça ira tout droit dans /usr/local
            Si AutoPackage utilise /usr par défaut parce qu'ils n'ont pas de solutions pour ajouter les chemins de /usr/local dans la configuration système, excuse-moi, mais c'est de la pure fainéantise : il suffirait d'ajouter /usr/local/lib dans /etc/ld.so.conf et de modifier le $PATH dans un /etc/profile. Et s'ils ne sont pas capables de deviner le shell utilisé par le système...
            Utiliser /usr parce que /usr/local n'est pas intégré dans les chemins par défaut sur la majorité des distributions est une mauvaise excuse.

        • [^] # Re: .

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

          > Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr

          et /opt, c'est pour ranger les pizza /opt ?
          Bon, ok, toutes les distris n'ont pas de /opt mais c'est facile à arranger mkdir /opt. pouf-pouf.

          • [^] # Re: .

            Posté par  . Évalué à 1.

            Et /usr/local ? On m'a toujours dit que les bidules supplémentaires devaient s'installer dans /usr/local. On m'aurait menti ?

            BeOS le faisait il y a 20 ans !

            • [^] # Re: .

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

              Filesystem Hierarchy Standard 2.3 :
              http://www.pathname.com/fhs/
              « /opt is reserved for the installation of add-on application software packages. »

              « The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr »

              • [^] # Re: .

                Posté par  . Évalué à 5.

                Dans le contexte Desktop (le seul impacté par le problème des binaires passe-partout, j'en ai l'impression), l'administrateur est l'utilisateur de la machine (ou en tout cas l'utilisateur principal) et toute installation est locale.

                Je ne voit donc pas en quoi, dans un contexte Desktop toujours, /opt devrait être préféré à /usr/local selon la définition FHS. Et plus généralement, si on sort de la nomenclature FHS (qui n'est pas si standard que ça apparament) je vois encore moins la différence.

                J'ai oublié un détail ?


                PS: si quelqu'un a le background UNIX nécessaire pour m'expliquer à quoi correspond des "programs and data that are shareable amongst a group of hosts" je suis preneur

                BeOS le faisait il y a 20 ans !

                • [^] # Re: .

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

                  PS: si quelqu'un a le background UNIX nécessaire pour m'expliquer à quoi correspond des "programs and data that are shareable amongst a group of hosts" je suis preneur
                  Tu peux tout à fait imaginer qu'un parc homogène de stations de travail bootent par le réseau, ce qui permet d'avoir des "terminaux" évolués (et indifférenciés) ainsi qu'une gestion centralisée des mises à jour / ajouts de programmes pour tout le parc.
                  Le /usr/local permet de différencier les applications pour ton site : cela correspond à des applications qui sont adaptées à ton besoin (ou ceux de tes utilisateurs) mais qui n'ont pas vocation à être gérées de manière standard au niveau de la configuration. Par exemple, quand en admin' en central intervient en région, cela lui permet d'identifier directement ce qui est utilisé en spécifique (et d'être sûr de ne pas tout casser). Cela permet de partager les responsabilités.

                  • [^] # Re: .

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

                    Politique maison (je suis en mon poste) toute install qui n'est pas un paquet de la distrib -> /opt
                    Maintenant, si c'est une mauvaise idée et que quelqu'un me l'explique, je veux bien changer.

                    • [^] # Re: .

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

                      /usr/local ou /opt, c'est kif-kif pour ce genre de raisons.
                      Personnellement, c'est plutôt /usr/local mais ça revient au même.

              • [^] # Re: .

                Posté par  . Évalué à 2.

                Ouais mais sous la Slackware par exemple, c'est un peu là que KDE est rangé et on ne peut pas trop dire que ça soit spécialement un truc additionnel et optionnel... Enfin, tout dépend de l'usage que l'on fait de son Linux en fait.

    • [^] # Re: .

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

      Ce sujet a déja été ressassé moult fois.

      J'aime pas me repeter, donc je te reporte à ce test d'autopackage : http://linuxfr.org/comments/787791,1.html

      Pour faire short autopackage marche, mais il faut quand même utiliser le systéme de gestion de la distribution, il y a pas de vérification des signatures, pas de systémes de gestion des mises à jours, et ç'est relativement fragile et décentralisé.
      Grosso modo, ç'est comme sur windows. Si les gens veulent avoir les mêmes problémes que sur windows, pas besoin de venir pousser ça sur les os qui font les choses différements.

      • [^] # Re: .

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

        Autopackage est loin d'être idéal c'est clair mais le probléme n'est pas autopackage contre rpm/dpkg mais autopackage contre make install.

        Si ton logiciel est dans ta distro très bien, c'est l'idéal mais quand il n'y est pas tu fais quoi: make install.

        Et 'make install' c'est aussi: pas de vérification des signatures, pas de systémes de gestion des mises à jours, et ç'est relativement fragile et décentralisé.

        Mais aussi et surtout: inaccessible pour un utilisateur final.

        • [^] # Re: .

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

          Oui mais par défaut, ça s'installe dans /usr/local.
          Installer des fichiers directement sous /usr, c'est s'opposer aux systèmes rpm et dpkg car les risques de conflits sont loin d'être mineurs.

        • [^] # Re: .

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

          En général, soit je fait le paquet, et je l'uploade pour les autres, soit je tire un trait dessus.

          C'est comme les fonctionnalités dans les versions svn/cvs. le code est dispo, mais pas facilement utilisable par un utilisateur, et il faut attendre que le dev finalise le code pour l'utiliser, tout comme il faut attendre que les packageurs packagent le tarball pour l'utiliser.

          C'est une simple question de compétence. Soit l'utilisateur sait faire, soit il dépend des gens qui le font pour lui, rien de nouveau depuis les débuts de l'info.

          Toute les normes du monde ne vont pas changer cet état de fait, et je pense que le systéme de distribution n'a pas avancé vers les méthodes actuelles par une incompétence généralisé des gens impliqués ou le plaisir de ne pas correspondre aux utilisateurs de bases, mais plus qu'il s'agit de choix mûrement réfléchis, basé sur l'expérience des "systémes" précédents.

          La priorité de Microsoft pour imposer windows, ce fut de permettre un developpement commercial riche décentralisé, afin de faire jouer la compétition.
          Donc , le systéme a été fait en conséquence, car les dirigeants de microsoft savait pertinement qu'ils n'avaient pas les ressources pour tout offrir.

          Pour les distributions linux, ce fut le contraire. Il y avait un énorme potentiel d'intégration, grâce au respect des 4 libertés, et donc le choix du systéme actuel est arrivé naturellement.

          La distribution de binaire, c'est qu'une partie des problémes par rapport au reste ( les tests, l'intégration correct, la gestion des dépendances, la gestion des versions différentes, le choix de la plateforme de référence pour le dev, l'impact des patchs des distributions, les remontés de bugs et leur reproductibilité via un systéme centralisé )

          Rien que ce dernier point me fait rire d'avance.
          User A télécharge le binaire, le lance, et il y a une erreur , le dev teste, il ne la voit pas, il va dire que ça vient de la distribution. Possible, aprés tout.
          Ok, l'user A va aller raler sur la distro, la distro va prendre le paquet qu'elle distribue, ne reproduit pas, et va dire "c'est le type qui a fait le binaire, on fait pas le support de ça".

          Résultat des courses, le seul à l'avoir dans l'os, c'est l'utilisateur, car ni le dev, ni la distribution n'ont fondamentalement tort, même si, dans mon exemple, je pense que c'est au dev de s'occuper du probléme. Mais ils n'ont pas du temps à perdre pour faire des tests sur toutes les plateformes possibles.
          Bien sur, on peut imaginer se limiter, mais ça serait comme avoir un systéme à 2 vitesses, se dire que que "90% des linuxiens, c'est suffisant", c'est comme dire "90% des os suffisent, je vais donc faire du wmv"

          Et je pense aussi qu'une grande partie des devs se contentent trés bien d'avoir le code source, et de laisser les autres faire la distribution et le packaging.

          • [^] # Re: .

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

            Tout ceci abonde dans mon sens.
            Si le développeur veut aller plus loin pour faire plaisir à ses utilisateurs, qu'il s'occupe alors de préparer lui-même des paquets binaires pour plusieurs distributions, au moins celles qu'il connait ou que son équipe de développement connait. De nombreux projets libres le font ainsi comme Grisbi ou Net-SNMP pour n'en citer que deux disposant à chaque nouvelle version d'un nombre conséquent de binaires.
            En fait, ce problème se pose surtout pour les logiciels ludiques et bureautiques.
            Je pense que leurs distributions devraient peut-être sortir du cadre des distributions.

            • [^] # Re: .

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

              Si le développeur veut aller plus loin pour faire plaisir à ses utilisateurs, qu'il s'occupe alors de préparer lui-même des paquets binaires pour plusieurs distributions

              Avec plaisir! Je te mets mon adresse postale en privé pour que tu puisse m'envoyer un disque dur rapide 300GB et 4GB de mémoire (DDR-2, stp) pour pouvoir faire tourner 5 distros différentes dans des Xen?

              En fait si tu pouvais plutôt m'envoyer 5 laptops rapides (pour compiler des paquets c'est mieux), ce sera préférable, ça m'évitera de mettre du Xen partout.

              Merci!

              Sérieusement, je fais des paquets de mon projet pour deux versions de ma distro, ça me prend une à deux heures de temps à chaque release, et c'est autant de temps que je peux pas passer à coder. Et les gens me demandent encore des paquets x86-64 (j'ai qu'un i686)... Faut pas exagérer hein...

              • [^] # Re: .

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

                Dans une certaine mesure et uniquement pour compiler (pas pour tester) tu peux très bien te faire des chroots de compilation (installer des distribs dans un chroot), quelque soit la distrib.
                Pour ma part j'ai ça sur une mandriva essentiellement pour ne pas mélanger la compilation nécessitant des libs devel et l'utilisation classique. Sachant en plus que ça se compresse, ça me permet d'avoir une image toujours propre ce qui évite pas mal d'oublis de dépendances.

                Dans mon cas j'ai une machine 64 bits. J'ai donc 2 chroots pour ma version courante, un en 32 et l'autre en 64. Je peux aussi en installer d'autres pour les versions inférieurs.
                Mais il est aussi possible d'installer des versions d'autres distribs. J'avais installé une debian sur ma mandrivaet je crois qu'il y avait un article dans un glmf qui faisait le contraire.

                Ok c'est pas parfait mais pour builder ça suffit sans prendre trop de place.

              • [^] # Re: .

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

                Tu n'es pas tout seul non plus...
                Il suffit de ne pas non plus faire peur au moindre contributeur souhaitant faire un paquet binaire pour sa plate-forme particulière.
                Je sais bien qu'il est difficile d'avoir toutes les plate-formes existantes mais il existe des solutions logicielles (Xen que tu as cité, mais aussi Qemu quand il ne s'agit pas que d'x86 ou d'amd64) pour t'en sortir.
                Comme l'a dit « CrEv», un chroot ou sandbox suffit amplement. Sous Debian, on a l'excellent outil pbuilder qui nous permet de faire ça à la volée ce qui évite de conserver une image en permanence et d'automatiser tout ça.

                • [^] # Re: .

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

                  Je suis d'accord avec tout ça, mais ce n'est pas forcément pratique à mettre en oeuvre. Par exemple, j'ai un disque de 40Go, il est tout le temps plein, donc je suis forcé de faire mes paquets avec dpkg-buildpackage au lieu d'un pbuilder. Par chance je fais des paquets Ubuntu basés sur ceux de notre DD qui fait ceux pour Debian, du coup j'ai peu de choses à modifier dans debian/ ...

                  Sinon, en effet, il faut éviter de faire peur aux contributeurs potentiels. On fait de notre mieux pour guider les gens dans ce qu'il veulent contribuer, éviter de laisser trainer des patches sur lesquels quelqu'un a passé du temps, etc...

                  Le fait est qu'on a plein de contributeurs sur mon projet (Claws Mail), bien que la plupart soient contributeurs de code, on a aussi pas mal de traducteurs motivés et des packageurs géniaux pour la plupart des grosses distros (Mdv, Debian, Fedora, Novell), des packageurs qui nous remontent les bugs upstream et fournissent des patches si nécessaire. Donc en fait, mon message ci-dessus était à prendre dans le cas général.

          • [^] # Re: .

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

            C'est une simple question de compétence. Soit l'utilisateur sait faire, soit il dépend des gens qui le font pour lui, rien de nouveau depuis les débuts de l'info.

            Oui mais nous on veux bien le faire pour lui le paquet binaire mais à condition que le paquet marche pour toute les distros.

            Ok, l'user A va aller raler sur la distro, la distro va prendre le paquet qu'elle distribue, ne reproduit pas, et va dire "c'est le type qui a fait le binaire, on fait pas le support de ça".

            Je vois pas pourquoi il testerait pas avec le paquet de l'utilisateur mais bon supposons, c'est un cas de figure intéressant.

            C'est à dire que les distribution font un système d'exploitation fermée avec du logiciel Libre. Il n'est pas toléré d'installer des logiciels autres que ceux proposée par la distribution. C'est domage mais c'est bien ce qui ce passe.

            Mais je connais plutôt, et je vis tous les jours le problème inverse. Des gens viennent nous voir pour avoir du support sur un logiciel que nous n'avons pas compilé et que nous n'avons pas (il faudrait installer la distro). Bon courage pour trouver qu'avec la libxyz-2 ça marche bien, on a testé avec mais la libxyz que la distrib utilise pose un problème.

            Bien sûr, ton cas de figure c'est ce que je vis sur le binaire windows de GCompris. Personne ne va jamais se pleindre chez microsoft quand ça marche pas ;)

            • [^] # Re: .

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

              >Oui mais nous on veux bien le faire pour lui le paquet binaire mais à condition que le paquet marche pour toute les distros.

              Ce n'est pas le cas, donc ce n'est pas à vous de faire le paquet.

              >Ok, l'user A va aller raler sur la distro, la distro va prendre le paquet qu'elle distribue, ne reproduit pas, et va dire "c'est le type qui a fait le binaire, on fait pas le support de ça".

              Oui c'est normal, quand tu change d'autoradio, tu ne vas pas te plaindre au constructeur ou au concessionaire quand il a un disfonctionnement.

              >Je vois pas pourquoi il testerait pas avec le paquet de l'utilisateur mais bon supposons

              Parce que ce n'est pas la distribution qui a fourni le binaire, parce que le paquet peut avoir été fait n'importe comment etc... Par contre l'utilisateur peux à mon avis fournir le paquet source et faire demander une update.
              Sur Mandriva quand je voulais un soft plus à jour j'avais juste à faire un urpmi_build_update lenomdupaquet le.numero.de.version et il me faisait le binaire qui va bien en allant télécharger les sources sur le ftp ou le cvs.

              >Il n'est pas toléré d'installer des logiciels autres que ceux proposée par la distribution.

              Bien sûr que si c'est toléré mais ça ne peut pas être supporté.

              >Des gens viennent nous voir pour avoir du support sur un logiciel que nous n'avons pas compilé et que nous n'avons pas (il faudrait installer la distro).

              C'est pour ça que les distributions ont des bugzilla et compagnie, l'utilisateur d'un paquet fait le bugreport à la distribution, le mainteneur va regarder les changelog voir si qqun chose à ce sujet à été corrigé, eventuellement faire une update du paquet ou un backport.

    • [^] # Re: .

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

      Quand je développe une appli bien sympa et que j'ai envie que tout le monde puisse en bénéficier, je fais comment aujourd'hui ???

      Quand je dis tout le monde, il s'agit aussi de mamie qui se met à linux.

      Je n'ai qu'une solution propre et pratique : le paquet.

      Mais comme je passe déja beaucoup de temps à développer mon appli, je n'ai plus de temps pour faire un paquet pour chaque distro avec ses particularités.
      Et surtout les maintenirs ces packages !!

      Il faut vraiment que les distros arrivent à se mettre d'accord pour n'avoir qu'un type de package avec une seul entrée de menu que ce soit pour KDE, GNOME ou autre wm geek.

      Cela fera une économie d'espace disque sur les serveurs.
      Plus de serveurs disponible pour tout à chacun car il n'y aura plus un serveur pour les .rpm, un serveur pour les .deb, un pour les .mdk ou je ne sais quelle autre paquet exotique.
      Cela fera plus de remonté de bug sur ces fameux nouveaux package et donc des package beaucoup plus fiable.

      Que les distro mettent leur appli dans /opt ou /usr/local je m'en moque, ce que je veux c pouvoir diffuser librement au plus grand nombre, pour le plus grand plaisir de tous.

      C'est incroyable que chacun reste dans son coin depuis des années et que rien n'avance, ou en tous cas trop lentement.

      Bonne année ! ;-)

      • [^] # Re: .

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

        Cela fera une économie d'espace disque sur les serveurs.
        Plus de serveurs disponible pour tout à chacun car il n'y aura plus un serveur pour les .rpm, un serveur pour les .deb, un pour les .mdk ou je ne sais quelle autre paquet exotique.
        Il faudra toujours un package par distro dans la plupart des cas, à moins que tu ne compiles tout en statique et dans ce cas ca fera vraiment pas une économie d'espace disque sur les serveurs (ni sur les machines clientes).

        • [^] # Re: .

          Posté par  . Évalué à 2.

          Pas forcément, on pourrait imaginer une liaison entre le gestionnaire de package de la distrib (apt, rpm, ...) et le gestionnaire de package "standard". Ce dernier demanderais à son compère de la distrib d'installer les dépendances dont il a besoin.

          Une solution de ce type devrait être possible sur les libs les plus utilisées. Non ?

      • [^] # Re: .

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

        Tou a fait d'accord!

        J'ai le meme probleme: je fait des petites appli libres (GPL), mais tres specialisees (ce qui signifie que je suis tout seul et je le resterais pour les maintenir, packager, etc). Pour Windows ou Mac, pas de probleme: creer le "package" est simple et surtout je ne le fait qu'une seule fois pour chaque nouvelle version.

        Pour Linux, et bien je me contente de faire un RPM depuis ma Mandriva, mettre les sources dans un tarball et esperer que cela satisfasse a peu pres tout le monde (ce qui est evidement totalement faux et impossible)...

        Donc oui, je salue toute solution qui permettrait de distribuer (et aussi d'installer) des soft sous Linux de facon la plus universelle possible (et si apres quelqu'un veux optimiser son installation, c'est son probleme, au moins il y a une base qui marche).

        Mathias

        • [^] # Re: .

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

          La solution est pourtant simple : 1 seule distro linux de base pour tous.

          Ce que d'ailleurs canonical essaye de proposer, comme expliqué ici : http://www.zarb.org/~misc/ubuntu.txt .

          Aprés tout, un paquet basé sur une kubuntu devrait tourner sur une edubuntu, et sur les autres dérivés, car le core est commun.

          • [^] # Re: .

            Posté par  . Évalué à 4.

            euh c'est ironique ?

            non parce que la liberté de choix, tout ça...

            • [^] # Re: .

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

              Non, c'est pas ironique.
              j'ai pas dit que je suis pour cette solution, mais c'est ce qui résoud le probléme actuellement.

              Soit tu as une seule plateforme ( windows, osX ) homogéne, soit tu en as plusieurs avec des différences significatives ( distribution linux ).

              Prenons les différences entre les distributions :
              - les outils d'administrations. Dans un souci de simplification de la doc, il faut que cette partie soit unifié. Pas question de dire "si vous avez XX, ç'est tel appli, sinon, c'est tel autre".
              - les logiciels présent, aussi bien leur nom, que les versions.
              Si on continue à laisser les différences entre les versions, il y a des risques d'incompatiblités => donc on uniformise, au moins pour les libs de base.
              Ce qui, par le jeu magique des dépendances, fait que tout le monde à la même version de gnome et de kde, compatible de façon binaire.

              Du coup, si 75% des paquets sont les mêmes, si les outils d'admins sont les mêmes, les seules choses qui changent, c'est les fonds d'écrans ( super ), l'installeur, et les configurations par défaut ( modulo la compatiblité avec la norme ).

              Soit grosso modo, les trucs que l'user peut déja changer par lui même. Et il y a plus aucune différence dans les distributions, donc autant ne garder qu'une seule distro.

              • [^] # Re: .

                Posté par  . Évalué à 0.

                les gens qui poussent FreeBSD ou PC-BSD sont des gros malins : tout le truc est que tu te retrouves avec un seul système dans la nature au lieu d'en avoir une centaine et de te retrouver à devoir pondre des recommendations comme la LSB pour ramener tout le monde au bercail

              • [^] # Re: et Beastie alors ?

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

                Soit tu as une seule plateforme ( windows, osX ) homogéne, soit tu en as plusieurs avec des différences significatives ( distribution linux ).

                Sans compter les différents BSD... En ce moment je bricole sur Debian, Slackware et OpenBSD. C'est quand même trois mondes relativement différents au niveau de la gestion des packages...

        • [^] # Re: .

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

          Tu pourrais commencer par faire parler de tes logiciels pour espérer toucher plus de monde, non ?

          • [^] # Re: .

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

            Mais j'en fait (un peu) de pub ! je les annonce sur freshmeat, j'en fait de la pub dans la communaute d'utilisateurs potentiels, etc!

            Donc je vais de ce pas faire de la pub ici meme :-)
            *Un super soft pour la resolution de circuits RLC, quelques soient les parametres manquant (ie: a partir du signal mesure, en deduire le circuit), calculer les resistances, dimensionner les resistances liquides, les inductances etc: c'est PPTools http://freshmeat.net/projects/pptools/
            *Encore plus necessaire a votre survie, un pilote pour utiliser le detecteur de particules GM45 sous Linux: Gm4lin http://mathias.bavay.free.fr/software/gm4lin/

            Et tres prochainement quelques autres, enfin un peu plus utiles au commun des mortels...

            Mathias

            • [^] # Re: .

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

              euh t'as oublié de dire que les copies d'écran sont disponibles sur la page http://www.ivanhoe-technologies.com/products/pptools/pptools(...)
              tu aurais pu indiquer un petit teaser du genre "bientôt intégré à ktechlab (ou en add-on..." https://linuxfr.org/2006/03/11/20484.html et je n'ai pas vu de dépêche sur trollfr^Wlinuxfr pour la sortie de la v1.0... ;-) (/me adepte des copies d'écran pour booster la comm' : suffit de regarder les liens les plus cliqués sur les dépêches de linuxfr pour se rendre compte que je ne suis pas le seul :p)

              D'autre part, choisir un hébergement des sources sur https://gna.org (par exemple, sf et berlios souffrant de lenteurs AMHA...) peut permettre de "rassurer" sur la liberté de ton soft (on ne perd pas de temps à trouver le texte de la licence) ainsi que d'assurer que demain les sources ne vont pas soudain disparaître (cela permet aussi d'intégrer de nouveaux développeurs tout étant fait pour le travail collaboratif et pour ouvrir le projet à la communauté).
              Pour l'hébergement du site web, tu as aussi http://tuxfamily.org (qui peut permettre aussi de gérer ton source d'ailleurs, même si je suis plus habitué à gna pour cela), plutôt que free qui fait tout de même beaucoup "site perso" AMHA.

              En tout cas, pour le choix de freshmeat, c'est très bien, cela permet le tri par catégories déjà. J'ai eu à rechercher des logiciels par thème / évaluer leur niveau de maintenance pour http://cookerspot.tuxfamily.org/wikka.php?wakka=ProgramsScie(...) et c'est clair que les sites non raccrochés à une forge ne sont pas très lisibles (voire très difficiles à trouver déjà...).

      • [^] # Re: .

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

        Si les développeurs passaient un peu plus de temps à faire les paquets eux-mêmes de leurs applications, il y aurait sans doute moins de bogues car ils seraient bien obligé de se placer dans un contexte plus proche du réel que leur environnement de développement où « ça marche ».
        Le travail le plus ingrat dans le développement d'un logiciel sont justement les tests et l'intégration de celui-ci avec les autres logiciels déjà en place mais c'est au moins aussi important que le développement proprement dit.

        • [^] # Re: .

          Posté par  . Évalué à 1.

          Mais qui empêche les mainteneurs de paquets de faire ce travail d'intégration et de tests ?

          Un dev ne peut pas connaître toutes les distribs, faut être honnête, donc ce boulot est celui de l'équipe de la distrib... faut quand même pas tout laisser au développeur.

          Après, il est évident qu'il faut arrêter de faire semblant que "mainteneur" est un boulot pour tout le monde ...

        • [^] # Re: .

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

          On est d'accord et je veux bien passer du temps pour faire en sorte que mon logiciel marche bien sur la plate-forme GNU/Linux, pas sur 50 distributions.

      • [^] # Re: .

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

        Mais pourquoi ne pas simplement envoyer un mail sur les listes de dev des distros (ou sur irc, forums, ...) en disant que tu développe un soft qui pourrait intéresser d'autres personnes sauf que tu ne sais pas / n'a pas le temps / ne veux pas le packager pour cette distro ?
        Si le soft est intéressant à mon avis tu finira toujours pas trouver quelqu'un pour le faire (surtout si le soft est bien fait)
        Alors oui il faut convaincre les packageurs de s'occuper de ton soft mais le résultat et que les paquets existent au final...

        • [^] # Re: .

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

          Surtout que des distributions comme Debian prévoient précisément de signaler le besoin d'un logiciel qui n'est pas encore disponible sous forme de paquets : RFP (à ne pas confondre avec ITP qui signifie qu'on est en train de le réaliser).

          RFP : Request For Package
          ITP : Intent To Package

  • # Faux problèmes à mon sens.

    Posté par  . Évalué à 10.

    Je crois que c'est un peu 'politique marketing' car il y a un moyen de faire des binaires multi-plateforme : c'est de compiler en static et de fournir les libs dans un bon gros .tgz

    De nombreux jeux le font (par exemple http://www.landes-eternelles.com ) avec des binaires linux. D'autres 'gros'jeux ont été annoncés ici même avec des binaires universels) des petis émulateurs sortis il y a 3-5 ans et fournis en binaires fonctionnent encore, Openoffice, firefox, etc.... il y a autopackage .. (comment fait skype ou nero ?)

    Mainenant que certains veulent se faire mousser en révolutionnant encore une fois de plus le bouzin peut amener amélioration par effets de bords, mais ce n'est pas le désert non plus et ce ne sont pas des sauveurs du monde de l'univers.

    Ce que j'en voie avec ma mauvaise fois trollesque légendaires, c'est un moyen pour LSB (et ses principaux promoteurs) de 'reprendre un peu le devant de la scène' dans un univers linux libre qui s'éclate sous l'effet d'un nombre croissant de distributions communiquantes, et de positionnement, face au respect de la gpl, parfois divergents.

    Il est clair que les logiciels proprios qui veulent canibaliser le libre (prime au premier entrant) sont les premiers interessés d'une initiative comme cela. Par effet de 'renommé' ce groupe de travail communiquerait (peut être avec raison, question de goûts) facilement sur les grosses boites proprios qui porteraient des applis proprios sous linux, ce qui fragiliserait un peu le délicat écosystème (dans le sens économique) du libre.

    Maintenant je ne pense pas que cela n'apportera rien, mais je ne pense pas non plus que cela apportera plus que la sortie du dernier wormux ou de j'enveuxpas.
    Effectivement cela pourrait sembler permettre aux 'petits' de plus facilement de distribuer des package tout prêts, mais plutôt que
    -de réinventer la roue
    - aller à l'encontre de la philosophie linux, et aller vers un système windows clicliclic.exe fini
    - aller vers un moyens de standardiser le linux de base et donc le rendre plus sensible aux virus car 'génétiquement' plus proches les uns des autres ave une api exprès pour installer sur toutes les machines
    - donner aux distributions un point de fixation supplémentaire [ le driver graphique proprio nouvelle version qu'il faut attendre ET la nouvelle version du packageur miracle)

    ....il serait plus judiceux de mettre en place des 'fermes de compilation' pour préparer les binaires facilement.

    Par exemple ce qui pourrait être le plus smart dans mes fantasmes les plus torrides : Chaque destribution founirait un ou plusieurs machine de compilation. En tant qu'utilisateur, je choisie un logiciel Lambda. Je me connecte sur le site et je donne la config de ma machine (avec un script shell qui vérifie les versions de mes libs), le serveur fait un chroot avec les versions identiques aux miennes et lance la compilation, fait le package et me distribue le package (le stock pour ne pas refaire le même travail) en travaillant directement depuis les sources de l'applis. Ensuite il met ce package à dispo en téléchargement avec les infos qui vont bien. Et hop, plus de soucis de libs, plus de soucis de distribution pour les dév. On peut même penser qu'il puisse y avoir des machines qui prennent les sources et lancent une compilation sur toutes les distributions et 'centralisent' les erreurs pour faire des corrections générales. [ cela résoudrait une grande partie des soucis, laissant que les problèmes particuliers]. Comme l'utilisateur Lambda utilise une machine 'toute prête et pas tunée, cela marcherait pour 95% des cas, respecterais la philosophie linux, pas de static, compile from source etc...., et soulagerait les dev et les utilisateurs.

    • [^] # Re: Faux problèmes à mon sens.

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

      Tu dis que le problème est faux mais tu proposes une autre solution. Faut savoir !

      Ta solution ne marchera pas. Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ? Et des raissons que ça marche pas la compilation, c'est pas ça qui manque... (Déjà dit plus haut mais bon)

      En plus ton système pre-suppose que tout le monde à un accés haut-débit. Quid de la distribution de logiciel en paquet binaire dans les magazine. Ce serait pourtant pratique pour beaucoup.

      • [^] # Re: Faux problèmes à mon sens.

        Posté par  . Évalué à 3.

        Quid de la distribution de logiciel en paquet binaire dans les magazine. Ce serait pourtant pratique pour beaucoup.

        Qu'est ce qui empèche de le faire aujourd'hui avec un script d'install en ligne de commande ou graphique ?

        C'est un faux problème.

      • [^] # Re: Faux problèmes à mon sens.

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

        Il faut vite prévenir Debian que buildd [1] n'a aucune chance de marcher alors... On me dit dans mon oreillette que si...

        [1] http://buildd.debian.org/

        • [^] # Re: Faux problèmes à mon sens.

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

          Si je ne comprend bien, cet outil prend en entrée des "Debian source packages", pas des sources packages fournis directement pas le projet. Si tu préfères le travaille de packaging propre à la distribution est déjà commencé, l'utilisateur peut alors le terminer. Cela ne résoud en rien le problème.

          Commen tu fais pour livrer à tes utilisateurs GNU/Linux un programme qu'ils puissent installer simplement, quelque soit leur distribution.

          • [^] # Faut quand même pas trop pousser...

            Posté par  . Évalué à 2.

            Ebfin, bon, honnêtement, il y a un certain nombre de distributions l'inux qu'on peut négliger tellement leur diffusion est confidentielle : après tout, si ces micro-distributions se démerdent pour ne même pas fournir une compatibilité avec une distribution un peu plus visible que la leur, c'est un choix de leur part.

            Sinon, la question du support des versions "anciennes" (plus de 12 mois ?) de la plupart des distributions pourrait tout aussi bien se poser.

            Sinon, fabriquer des packages RPMs bien binaires pour un redhat/fedora/Suse à partir de "Debian source packages" n'est normalement pas très difficile et assez direct : le choix du format source de départ est donc plutôt bien pensé, et les grandes distributions sont désormais suffisamment semblables pour qu'il y ait "peu" de problèmes imaginables avec les applis desktop intéressant typiquement l'utilisateur néophyte.

            • [^] # Re: Faut quand même pas trop pousser...

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

              > Ebfin, bon, honnêtement, il y a un certain nombre de distributions l'inux
              > qu'on peut négliger tellement leur diffusion est confidentielle

              De la même façon qu'on peut négliger les os confidentielles comme les distributions linux, d'un point de vue général.

          • [^] # Re: Faux problèmes à mon sens.

            Posté par  . Évalué à 7.

            AMHA, on n'en a probablement pas envie.

            Je m'explique : avant de distribuer la toute dernière version de freeciv 3.0 par exemple, une distribution va faire faire un truc magique qui fait une grosse part de la valeur ajoutée d'une distribution : la gestion de configuration.

            Elle va vérifier que la toute dernière version de Freeciv marche bien avec la libtoto-7.2.134.21434-rev2 installée, que la libtiti-2.0 est bien disponible dans son catalogue de paquets, que la nouvelle version ne casse pas tout par rapport à la précédente, etc.

            Toute cette étape est perdue si on ne passe plus par la case packaging.

            Un binaire universel suppose que son créateur aie fait tout ce boulot de packaging à prori et pour toutes les distributions possibles et imaginables. Quand il s'agit de 4ou 5 versions de Windows ou MacOSX je veux bien lui faire confiance, mais quand il s'agit des dizaines (centaines ?) "flavors" de systèmes GNU/Linux/*BSD/? qui peuplent le monde des systèmes libres, je préfère largement faire confiance à un packageur spécialiste de ma distribution avant de taper "sudo ./install.sh" ou "sudo make install" (vécu avec la compilation de drivers webcam qui foiraient sur Ubuntu à cause du système de sudo tandis que les cripts magiques d'easycam2 marchaient tout bien).

            BeOS le faisait il y a 20 ans !

          • [^] # Re: Faux problèmes à mon sens.

            Posté par  . Évalué à 2.

            Commen tu fais pour livrer à tes utilisateurs GNU/Linux un programme qu'ils puissent installer simplement, quelque soit leur distribution.

            comment tu fais pour le livrer à un utilisateur :

            *utilisant un FreeBSD
            *utilisant un Linux tournant sur un processeur PasCommun (tm)
            *utilisant un Linux où il manque une librairie majeure indispensable à ton programme, pour une raison quelconque (comme... un manque de ressources ! parce que la distribution est le fruit de deux étudiants)
            *utilisant une distribution obsolète, abandonnée, plus à jour... comme une Mandrake de y'a juste un an (ou à peine plus)

            ne viens pas me dire "ah non ah non ! hors-jeu ! c'est débile comme cas de figure ! je parle d'utilisateurs normaux moi", tu viens d'imposer "quelque soit leur distribution", faudrait savoir...

      • [^] # Re: Faux problèmes à mon sens.

        Posté par  . Évalué à 2.

        Je t'accorde que ./configure; make; make install c'est pas trivial pour un utilisateur de base (le plus dur est d'ailleurs plutôt la gestion des dépendances). Et que c'est long...

        Mais de là à dire

        Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?


        Je ne vois pas bien en quoi compiler est une opération qui doit être réalisée par des spécialistes. Ça peut être automatisé (et la construction des paquets binaires l'est pour pas mal de distrib)... Et quand ça marche pas avec une install binaire, il fait quoi l'utilisateur ? Le rapport de bug (et la correction) sont souvent plus facile quand on sait à quelle ligne ça a foiré...

    • [^] # Re: Faux problèmes à mon sens.

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

      Ce que j'en voie avec ma mauvaise fois trollesque légendaires, c'est un moyen pour LSB (et ses principaux promoteurs) de 'reprendre un peu le devant de la scène' dans un univers linux libre qui s'éclate sous l'effet d'un nombre croissant de distributions communiquantes, et de positionnement, face au respect de la gpl, parfois divergents.


      Quand on sait qui est le principal instigateur (et « CTO » du LSB) de cette initiative, on comprend mieux : Ian Murdock.

      Il est clair que les logiciels proprios qui veulent canibaliser le libre (prime au premier entrant) sont les premiers interessés d'une initiative comme cela. Par effet de 'renommé' ce groupe de travail communiquerait (peut être avec raison, question de goûts) facilement sur les grosses boites proprios qui porteraient des applis proprios sous linux, ce qui fragiliserait un peu le délicat écosystème (dans le sens économique) du libre.


      Quand on voit quels sont les principaux acteurs (Progeny, RedHat et Novell), on comprend également mieux pourquoi il y aurait intérêt à créer un tel système afin de permettre une installation plus aisée des logiciels, fussent-ils propriétaires.

    • [^] # Re: Faux problèmes à mon sens.

      Posté par  . Évalué à 0.

      le serveur fait un chroot avec les versions identiques aux miennes et lance la compilation, fait le package et me distribue le package

      Pas mal comme idée mais à la sortie du dernier Froozenbubble ou Wormux que tu cites, j'imagine la bande passante du serveur.
      Et le pauvre mainteneur, il fait comment pour refroidir son petit serveur qui doit compiler à tout va (azote liquide?)

      • [^] # Re: Faux problèmes à mon sens.

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

        Il pourra toujours l'inscrire à un projet de calcul distribué ;-)

      • [^] # Re: Faux problèmes à mon sens.

        Posté par  . Évalué à 2.

        C'est pas tant la bande passante mais surtout le CPU qui va limiter. Si tu veut télécharger un logiciel "moyen" qui prend 10 minutes à compiler sur un PC "normal", et qu'il y'a 10 autres personnes qui le veulent en même temps que toi, tu vas devoir attendre (grosso modo) 2 heures avant que ton paquet ne soit près !

        Avantage du paquet binaire, une seul machine se tape les 10 minutes de compilation. Pour un utilisateur lambda, c'est pratique, rapide, et écologique en plus : 1 million de personne qui compilent 10 minutes = 19 années de CPU "économisées" (au profit de l'environnement, ou de BOINC).

    • [^] # Re: Faux problèmes à mon sens.

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

      > il y a un moyen de faire des binaires multi-plateforme : c'est de compiler en static et de fournir les libs dans un bon gros .tgz

      Et donc ça implique que les éditeurs qui distribuent le bon gros tgz le mettent à jour dès qu'une faille de sécu dans une de leur dépendance a été trouvée (libpng, openssl, ...). Ou pas, et alors c'est la fete du slip

      • [^] # Re: Faux problèmes à mon sens.

        Posté par  . Évalué à 3.

        oui, ou alors, il faut faire du dynamique et gérer toutes les situations possibes : c'est la fête du string (je prefère).

        Nan, il n'y a pas de solutions. Le paradigme linux c'est configure,make, make install. .. ou alors tout le monde sous la même distribution (mais la mienne alors) :-)

        Sinon, ils donnent les sources et ils auront des paquets pour redhat/fedora/debian/ubuntu/suze/gentoo/slackware sans soucis en très peu de temps.

        Faut pas oublier que la demande doit venir de ceux qui ne _veulent pas_ donner les sources de leurs applis, on va pas se faire chier pour leur simplifier la tache de faire du non libre quand même.

  • # happy

    Posté par  . Évalué à 4.

    Je suis content qu'on évoque les problèmes de situation et d'installation d'un programme hétérogènes selon les distro, et qu'on parle des nombreux systèmes de packaging.
    Alors, bien sûr, linux, libre, plein de distros, toussaaaa... OK.

    La prolifération de systèmes de packaging, de distros, etc... concurrents sous couvert de caractère libre et de diversité, est ce qui a permis à Linux de prendre l'envol qu'il a aujourd'hui.
    Le problème, c'est (ça va sans doute vous paraître totalement utopique ) si cette diversité, du fait que des milliers de programmeurs d'horizons différents (besoins différents, approches différentes,...), ne sert pas à une sorte de réunification positive à un moment donné, profitant de tous les bons éléments et bonnes idées de cette diversité, et éliminant les doublons inutiles et les faux pas (qui font que parfois faut 5 programmes pour faire 1 chose bien complètement), alors clairement on court vers un bordel absolument monstre. Ne serait ce qu'à l'heure actuelle, comment expliquer à quelqu'un qui débarque de windows, qu'il n'y a pas 1 "Linux" mais pleins de distributions, qui font toutes plus ou moins la même chose. L'utilisateur average Joe qui n'en a absolument rien à ciré de l'état d'esprit communautaire, de la philosophie (aussi louable soit elle), qui veut juste un système qui fonctionne, et pas avoir à payer une license Windows, et ben s'il a pas un informaticien sous le bras pour le guider vers une distribution newbie-enabled comme Ubuntu ou Mandriva, il est largué (=> "Linux" caytrocompliké => back2vinedause).

    Je parle en connaissance de cause, il y a deux jour, j'ai été confronté à une jeune femme (qui à 20 ans ne trouve pas naturel de dézipper un fichier à l'aide du menu contextuel clic-droit sous windows) qui m'a posé la question suivante:
    "Tu utilises Linucsee. Ah oui, mais c'est quoi ce truc? Ca doit être la dernière mode des informaticien ou quelque chose du genre? Pourquoi les gens quittent windows pour Linux???? M'enfin je comprend pas" (le plus naturellement possible)
    ...

    Après coup, pardonnez moi cette petite disgression

    • [^] # Re: happy

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

      Tout a un prix, il faut arrêter le délire.
      Le type qui ne veut pas payer sa licence Windows, qui ne veut pas chercher à comprendre comment son système fonctionne, et qui se permet d'éxiger quoi que ce soit peu bien aller se faire voir en ce qui me concerne(Roh là là, tout de suite, non je ne fais pas alusion aux Ubuntuiste :), il y a une communauté, de l'entre aide, et co. autour de cette distribution, et les utilisateurs y participent).

      Ce qu'il faut bien comprendre, c'est que les choses ne se feront jamais toutes seules. Tu veux un système qui fonctionne directement? Bin, prends Mandriva, par contre tu paiera(par le biais de l'achat de la boite ou de l'abo au club) quelqu'un pour "faire que ça marche". Tu ne veux pas payer? Bin, tourne-toi vers une édition communautaire, mais participe à faire en sorte que cela marche, et attends toi à devoir parfois mettre les mains dans le cambouis un peu plus souvent.

      Tout est question de compromis.

      Je réponds surtout ça par rapport à la description, du style "le type vient sous Linux uniquement pour ne pas payer sa Licence Windows, il s'en branle de la communauté (qui rend le système utilisable et qui participe à construire un système gratuit - vu que c'est ce qu'il cherche), tout ce qu'il veut c'est que ça marche". Mais bon, ce genre de mentalitées, en général, elle est plutôt Windows-XP-Pro-Kazaa-Powered.iso donc bon, pas à s'en soucier pour l'instant(on verra si VISTA change la donne...)

      • [^] # Re: happy

        Posté par  . Évalué à -2.

        C'est marrant, on peut créer un morphisme entre les débats de la communauté et les débats de la gauche en politique.

        Là t'es un peu crypto-stalinien.

  • # Ça n'arriveras jamais

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

    Trés franchement, plus je voit ce genre de choses, plus je doute que ça arrive.

    Pour le moment, la seule façon dont ce genre de choses est arrivé est
    1) une intégration proche de zéro avec la plateforme ( tarball binaire )
    2) un monopole sur le produit sous jacent ( windows )

    Imaginer que toutes les distributions linux et tout les distributeurs vont se mettre d'accord et sacrifier leur indépendance technologique pour respecter une norme arbitraire, c'est surréaliste.

    Les distributions innovent, changent des trucs. Soit elles vont renoncer à ça, et je pense que ça sera le début de la fin, soit elles vont continuer à le faire, et les distributeurs vont être moins intégrés.

    Exemple tout con ? Les scripts d'init parrallléles de Mandriva, à mettre en concordance avec upstrart chez ubuntu. Les 2 distributions devraient ne pas utiliser ça parce que ç'est potentiellement incompatible avec la lsb ?
    Et donc, dire non à leur utilisateurs qui réclament ça depuis longtemps ?

    Ou le faire, et donc avoir des bugs subtiles causés par les softs qui ne sont pas adaptés, ni testés avec ça ?

    Car il ne faut pas oublier une chose. Avoir une norme, ç'est bien. Mais ça implique aussi de faire des tests sur chaque plateforme, et chaque distribution. Sauf à vouloir proposer des softs non testés, en plus d'être moins intégré.

    De plus, comme j'ai déja dit dans la discussion précédente sur le sujet, ça va aussi limiter séverement les developpeurs dans l'usage des nouvelles libs.

    Et ça, je pense que ça va faire grincer des dents.
    On va se retrouver avec le probléme sauf qu'au lieu d'avoir des utilisateurs frustrés, ça sera des developpeurs frustrés. Frustrés de devoir garder des vielles libs pour faire du code pour les utilisateurs, frustrés de ne pas pouvoir utilisé le dernier truc trop fort de gstreamer, de cairo, car non dispo dans la norme.

    Et trés franchement, entre frustrer les gens qui codent et font avancer le libre, ou les gens qui se contente d'utiliser, mon choix est vite fait, surtout pour un truc aussi futile que l'utilisation du dernier soft à la mode.

    Et je ne parle pas du fait que si personne n'utilise les libs, les bugs ne seront pas remontés, donc le logiciel libre ira moins vite, avec du soft de moins bonne qualité, mais... avec des softs installables directement. Toute ressemblance avec la situation actuelle sur un os propriétaire est fortuite.

    • [^] # Re: Ça n'arriveras jamais

      Posté par  . Évalué à -3.

      Et trés franchement, entre frustrer les gens qui codent et font avancer le libre, ou les gens qui se contente d'utiliser, mon choix est vite fait, surtout pour un truc aussi futile que l'utilisation du dernier soft à la mode.

      i.e. "faire avancer le libre" <=> masturbation intellectuelle d'une communauté fermée d'informaticiens qui se créent des OSs et logiciels pour leur propre petite convenance, mais qui ne convient ni aux besoins (bcp trop technique) ni aux attentes (pas assez "à la mode") de l'utilisateur lambda qui voit l'ordi comme un simple outil (et pas un mode de vie, une passion, un ami, un compagnon, ...).

      C'est pas ce genre d'état d'esprit qui va participer à la démocratisation de Linux...

      • [^] # Re: Ça n'arriveras jamais

        Posté par  . Évalué à 5.

        Exact !!
        Et alors?

        Si j'avais besoin d'un OS qui fait tout a ma place avec des belles fenetres etc etc j'irai voir ailleurs.
        Linux n'a pas été créer pour faire du desktop et pour être populaire dans le foules.
        Linux a été créer par des informaticiens pour des informaticiens. Il y a des gens qui aimeraient en faire autre chose, pas de problème tant qu'ils exigent pas que l'on bride certaines parties de Linux pour pouvoir l'adapter au grand publique.
        Et fixer le format des paquets est une contraintes trop forte a mon sens.

        Quand Linus Torvalds refuse de fixer l'ABI des drivers et dit les autres ont qu'a ce debrouiller, ca aide pas les edieur de driver mais Linus ne fait pas ca juste pour les emmerder mais parce que ca briderer le devloppement de Linux.

        • [^] # Re: Ça n'arriveras jamais

          Posté par  . Évalué à 6.

          Ben merde alors!! je suis physicien...
          On m'aurait menti???

          Plus sérieusement, Linux, c'est avant tout une affaire de liberté, et la liberté c'est bon pour tout le monde, pas seulement pour les informaticiens.
          J'espère bien qu'un jour mes potes se mettront à Linux, et que ce jour là, il n'y aura pas de gens comme toi pour leur dire en substance: "va jouer ailleurs, c'est pas pour les amateurs ici!".

          On parle d'ouverture, de liberté, d'accès à la connaissance et de partage, et toi tu penses que c'est pas pour tout le monde? Je trouve ton attitude lamentable.

          • [^] # Re: Ça n'arriveras jamais

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

            Il y a suffisemment d'OS bridé pour satisfaire les utilisateurs de base.

            Si j'ai choisi Linux, c'est parce qu'il ne m'impose aucune limite.

            Brider Linux pour le rendre "accessible" à la masse en nivelant par le bas, NON MERCI.

            • [^] # Re: Ça n'arriveras jamais

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

              Qui te parle de brider quoi que ce soit !

              En quoi rendre l'installation de logiciel simple pour certains utilisateurs t'empèche de faire quoi que ce soit avec ton système ?

              Aujourd'hui, avec GNU/Linux, ce sont les utilisateurs qui sont bridés. On leur enlève la liberté d'installer des logiciels et tant qu'on ne leur rendra pas cette liberté, il n'y a aucune chance de progresser dans le grand public.

            • [^] # Re: Ça n'arriveras jamais

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

              Qui te parle de brider quoi que ce soit !

              En quoi rendre l'installation de logiciel simple pour certains utilisateurs t'empèche de faire quoi que ce soit avec ton système ?

              Aujourd'hui, avec GNU/Linux, ce sont les utilisateurs qui sont bridés. On leur enlève la liberté d'installer des logiciels et tant qu'on ne leur rendra pas cette liberté, il n'y a aucune chance de progresser dans le grand public.

              • [^] # Re: Ça n'arriveras jamais

                Posté par  . Évalué à 1.

                Rendre simple l'installation d'un logociel bride les possibilité de modiication d'une distribution.
                Par exemple où installé le programme pour qu'il apparisse dans les menu?
                Soit c'est tout le monde le même est alors c'est possible mais on peut plus changer cette emplacement c'est graver dans le marbre, on bride les changement. Soit c'est dynamique, on demande à l'OS ou il faut installé les programmes. Faire les paquetages seront alors difficile a faire generateur de Bug, si un progrtamme a deja installé tel lib mais que j'ai pas la même version qu'est ce que je dois faire.

                Simple pour l'utilisateur == Compliqué pour le programmateur c'est une constante de l'univers

                • [^] # Re: Ça n'arriveras jamais

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

                  Par exemple où installé le programme pour qu'il apparisse dans les menu?

                  ça existe déjà !
                  ça se nomme XDG (freedesktop.org) et c'est utilisé par les gros environnement ( KDE, XFCE, Gnome, ... )

          • [^] # Re: Ça n'arriveras jamais

            Posté par  . Évalué à 3.

            Relis ce que j'ai ecrit: Je n'ai jamais dit que les non informaticiens ne doivent pas utilisé linux.
            J'ai dit que la philosohie de developpement de Linux ne doit pas être decidé en fonction des gens qui veulent en faire un OS grand publique au detriment des fondamentaux de Linux.

            Linus n'a jamais bloqué le developpement de gnome alors qu'il deteste cet environement. Mais le jour où NVidia vient dire a Linus : "arrete de modié l'API de tes drivers, cela empeche Linux de devenir un OS grand publique" alors la je dis non (et Linus aussi).

            • [^] # Re: Ça n'arriveras jamais

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

              Il faudrait prendre le raisonnement inverse : personne ne peut forcer les utilisateurs à utiliser Linux. De même, personne ne peut obliger les divers acteurs du Logiciel Libre a utiliser un pseudo-standard.
              Les standards s'adoptent parce qu'ils s'inscrivent dans une certaine logique pour les utilisateurs (au sens large) mais on ne les impose pas (à moins d'être en position de monopole).
              Qu'Ian Murdock planche donc sur son problème et on verra bien ce qu'il en sortira mais à mon humble avis, ce sera sans doute sans suite.

          • [^] # Re: Ça n'arriveras jamais

            Posté par  . Évalué à 6.

            Bien sur que tous le monde à le droit à liberté.

            Le monde proprio, t'apporte confort, "tranquilité", facilité, etc. en édulcorant beaucoup de chose. Mais tu n'es pas libre, tu ne décides de presque rien, on t'impose tout. C'est de la dictature. Fait ce qu'on te dit comme on te dit où on te dit et tous ce passera bien pour toi.
            La liberté, ce n'est pas un truc qui te tombe tout cru dans le bec, ce n'est pas un truc qui se soutraite, ça dépend de chacun de nous.
            Bref la liberté c'est dur, c'est difficile, ça exige des sacrifices!
            Mais qu'est-ce que c'est bon!

      • [^] # Re: Ça n'arriveras jamais

        Posté par  . Évalué à 5.

        C'est pas ce genre d'état d'esprit qui va participer à la démocratisation de Linux...

        en même temps ce ne sont pas ces utilisateurs lambda qui vont faire de bons citoyens du libre puisqu'ils s'en battent complètement les couilles des détails techniques et autres accessoires idéologiques.

        comme par hasard, ça va être les premiers à vouloir continuer à warezer comme des petits fous et à pleurnicher de ne pouvoir jouer à leurs jeux Windows favoris.

        tu peux les considérer comme des bons gros cons de chasseurs si tu as du mal à voir ce que je veux dire. ou des esclaves, des otages de Windows.

        c'est beau, c'est bien, c'est Noble de vouloir leur remplacer leur Windows par un trouc Libre. rien que pour leur propre sécurité par exemple. ainsi tu vas les libérer, certes, mais tu ne vas pas les élever d'un chouia.

        • [^] # Re: Ça n'arriveras jamais

          Posté par  . Évalué à -1.

          en même temps ce ne sont pas ces utilisateurs lambda qui vont faire de bons citoyens du libre puisqu'ils s'en battent complètement les couilles des détails techniques et autres accessoires idéologiques.

          Tu peux m'expliquer le lien entre les accessoires idéologiques et les détails techniques?

          C'est n'importe quoi ton raisonnement! Sous prétexte que quelqu'un ne s'intéresse pas aux détails techniques, il ne peut pas devenir un bon citoyen du libre?

          Ton comportement est simplement xénophobe, c'est honteux.

    • [^] # Re: Ça n'arriveras jamais

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

      Euh, t'a entendu parler de macosx ?

      Ils font en sorte que l'installation des logiciels soit simple pour les utilisateurs et c'est le cas. Et je n'ai pas le sentiment que cela les ait emprêché d'innover.

      Donc, oui, il sauf une base commune à tous les GNU/Linux et le LSB est un bon candidat. Il manque ensuite un système simple pour l'installation des logiciels indépendant de la distribution ce que nous n'avons pas.

      • [^] # Re: Ça n'arriveras jamais

        Posté par  . Évalué à 2.

        Ils font en sorte que l'installation des logiciels soit simple pour les utilisateurs et c'est le cas

        C'est aussi le cas depuis toutes les distrib Linux.

        l manque ensuite un système simple pour l'installation des logiciels indépendant de la distribution ce que nous n'avons pas

        En a-t-on réellement besoin ? Est-ce réellement bloquant pour les éditeur de logiciels propriétaires ? Est-ce vraiment parce qu'il n'existe pas un installshield-like sous linux que la majorité des éditeurs ne propose pas de version Linux de leur soft/driver ?

        Est-ce vraiment ce manque qui empèche le petit développeur de proposer une procédure d'installation banalisé (a défaut de fournir un paquet pour chaque distrib, ce qui est avant tout le travail de chaque distrib).

        Certains se débrouillent très bien aujourd'hui (oracle, google, nvidia).

        • [^] # Re: Ça n'arriveras jamais

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

          Certains se débrouillent^W bidouillent très bien aujourd'hui (oracle, google, nvidia).

          Oui on peut y arriver aujourd'hui mais c'est pas simple, ni pour les developpeurs, les mainteneurs et les utilisateurs.

        • [^] # Re: Ça n'arriveras jamais

          Posté par  . Évalué à 2.

          "Est-ce vraiment parce qu'il n'existe pas un installshield-like sous linux que la majorité des éditeurs ne propose pas de version Linux de leur soft/driver ?"

          il existe un installsshield-like , c'est Loki installer (aka Loki Setup).
          Certains gros editeurs qui ont tout compris l'utilisent (IDSoftware,...)

          Donc la reponse a cette question est definitivement non

        • [^] # Re: Ça n'arriveras jamais

          Posté par  . Évalué à 3.

          C'est aussi le cas depuis toutes les distrib Linux.


          C'est aussi ce que je pensais en tant qu'utilisateur généralement.
          Pourtant, j'étais passer en gentoo puis en debian sid car je voulais tester plus rapidement certaines nouveautés.

          Je trouve très pratique le système d'installation des distributions Linux, et je ne veux en aucun cas un système d'installation entièrement à la Windows.

          Le problème, c'est pour installer/diffuser des versions très récentes. En tant que développeur, c'est vraiment le casse-tête...
          Pour Wormux par exemple, on a sorti une version récemment estampillée 0.7.9rc1, comme on pense sortir la vrai 0.7.9 dans pas longtemps, on s'est pas amusé à recontacter tous les packageurs de toutes les distributions pour qu'ils nous créent un paquet, résultat, on a juste le source disponible sur le site. En gros nos beta-testeur de l'archive sont les beta-testeurs de la version SVN, c'est bof!

          Au final, je pense qu'on va distribué un gros binaire statique...

          Je précise que nous sommes pourtant packagé officiellement par debian, ubuntu, mandriva, fedora, etc. Le problème, c'est que les versions évoluent vite, et comme on n'est pas synchro avec les distribs, c'est le bazar...

          • [^] # Re: Ça n'arriveras jamais

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

            De toutes façons, les versions rc n'ont pas leurs places dans les versions de développement de la plupart des distributions et notamment de debian.
            Par contre, rien ne t'empêche de créer ton propre dépôt pour les distribuer ou de passer par experimental si toi ou l'un de tes développeurs est un DD officiel.

            • [^] # Re: Ça n'arriveras jamais

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

              le problème principal n'est pas l'intégration d'une RC dans un dépôt officiel. Ce que nous constatons c'est que cette RC n'est pas testée parce qu'elle n'existe pas en version simple à installer, les gens ont finalement la flemme de compiler pour un test de jeu (ce que je comprends).

            • [^] # Re: Ça n'arriveras jamais

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

              Je sais que les version RC n'ont pas leurs place mais alors comment on demande à nos utilisateurs de tester un logiciel qu'il ne pourront avoir que lorsqu'ils l'auront testé. Ou alors, c'est juste les developpeurs qui testent et la qualité et mauvaise, c'est ce qui ce passe dans le cadre du développement de GCompris.

              • [^] # Re: Ça n'arriveras jamais

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

                En fournissant le même paquet mais pour experimental (dans le cas de Debian, à condition que son responsable veuille bien le faire) ou de en le proposant vous-même en reprenant légèrement le paquet source avec uupdate (merci aux responsables qui ajoutent le debian/watch).
                Si tu n'es pas satisfait de la réactivité des versions dans une distribution particulière ET que le gestion des dépendances d'un outil comme Autopackage laisse à désirer, il faut s'investir dans la création du paquet : il n'y a guère le choix.

                • [^] # Re: Ça n'arriveras jamais

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

                  Euh, t'as pas compris, mes utilisateurs, ils sont sur GNU/Linux, pas spécialement sur Debian. C'est assez amusant de poser un problème générique et d'avoir des réponse du genre voila comment on fait dans la distro x ou y.

                  • [^] # Re: Ça n'arriveras jamais

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

                    Et parce qu'avec les autres distributions, ce ne serait pas possible d'en faire autant ?

                    • [^] # Re: Ça n'arriveras jamais

                      Posté par  . Évalué à 1.

                      Tu sais combien il en existe des distributions ?

                      • [^] # Re: Ça n'arriveras jamais

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

                        Plus de 200. Pour autant, il n'existe pas plus de 10 distributions majeures. Personne ne lui demande de supporter toutes les distributions du monde (est-il prêt à supporter RedFlag Linux ?).
                        De toutes façons, c'est complètement surréaliste de vouloir atteindre un tel but.
                        Imaginons un seul instant que le produit Miracle 1.0 lui permette d'installer son logiciel en créant un seul paquet binaire pour Linux.
                        Soit. Il souhaite néanmoins ne pas surcharger inutilement son paquet binaire donc il ne devra pas utiliser compilation statique.
                        Soit. Dans ce cas, il faudra en plus télécharger ou fournir avec le précédent paquet binaire TOUTES les dépendances nécessaires et qui ne sauraient être fournies par la distribution cible (ce qui est le cas quand on fait des mises à jour fonctionnelles ayant besoin d'être testé). Et dans ce cas, je te laisse imaginer, même en prenant bien soin de les installer à l'écart, dans /usr/local ou /opt, les conflits que cela peut encore générer malgré tout avec les bibliothèques déjà présentes sur le système et notamment les logiciels qui en dépendraient. Dans le meilleur des mondes, ça ne devrait pas gêner.
                        Sauf qu'il va se retrouver à devoir quand même disposer de l'installation de l'utilisateur qui lui soumettra un problème après avoir installé SON paquet binaire et là, il ne pourra se retourner contre personne !

                        • [^] # Re: Ça n'arriveras jamais

                          Posté par  . Évalué à 3.

                          il faudra en plus télécharger ou fournir avec le précédent paquet binaire TOUTES les dépendances nécessaires et qui ne sauraient être fournies par la distribution cible

                          ça c'est l'inconvénient. Il convient donc de préciser plusieurs chose:

                          1) le binaire prêt à l'emploi, c'est pour un logiciel final "basique" ne dépendant de pas de trop de trucs en dehors d'une LSB 3.2. A partir du moment ou on aura une LSB 3.2 avec gtk, qt, python, beaucoup de logiciels destinés aux utilisateurs finaux pourraont fournir un binaire incluant les qualques libs qui manquent.

                          Dans le cas de gcompris, les dépendances ça doit être LSB 3.2 (gtk, python, pygtk) + SDL_mixer (et donc SDL) plus sqlite3 et pysqlite2 plus libgnomecanvas. J'en oublie peut-être une ou deux mais pas plus. Dans ces conditions ça reste raisonnable de penser fournir un bundle x86 prêt à l'emploi pour toute distribution compatible LSB 3.2

                          Si LSB n'a pas cet intérêt là, il ne sert à rien.

                          2) Et dans ce cas, je te laisse imaginer, même en prenant bien soin de les installer à l'écart, dans /usr/local ou /opt, les conflits que cela peut encore générer malgré tout avec les bibliothèques déjà présentes sur le système et notamment les logiciels qui en dépendraient. Dans le meilleur des mondes, ça ne devrait pas gêner.
                          La solution à laquelle je pense, c'est de ne pas installer les libs en questions mais les mettre dans un bundle. Avec un wrapper comme celui utiliser par autopackage pour positionner correctement LD_LIBRARY_PATH avant de lancer l'éxecutable.
                          En théorie on peut mettre comme ça même un truc aussi gros que GTK (si on a besoin d'une version différente de celle de la LSB en cours, ce qui n'est pas le but) sans casser le système hote.

                          Je crois savoir que Google Earth marche comme ça, en fournissant son QT (il ne peut pas utiliser le QT/GPL).

                          Mais le but, c'est d'avoir une solution efficace (le bundle) utilisable pour des logiciels finaux sans trop de complexité. Il y a beaucoup de projets qui dépendent de GTK < 2.8, qui n'ont pas besoin des dernières versions de gtk. Dans ce cas une bundle prêt à tourner sur toute distrib compatible LSB 3.2 est tout à fait envisageable.


                          3) le but n'est ni de se substituer à un packaging de distribution, bien meilleure solution. C'est de pouvoir proposer une version à utiliser facilement sans casser les distribution, sans devoir attendre que la distribution ait mis à jour les paquets, et sur laquelle ont puisse demander de tester les corrections de bugs rapportés.

                          En gros je peux faire un AppDir que Rox considère comme un programme à lancer en utilisant comme base le wrapper d'autopackage pour positionner LD_LIBRARY_PATH. Mais il n'y a que Rox avec lequel il suffise de poser ça dans ~/App pour que ça apparaisse dans les menus. C'est la solution NextStep (et donc osX) . L'idéal serait que freedesktop en fasse une norme que Kde et Gnome (et les autres) intègrent.

                          On peut même imaginer que l'installeur debian fasse le tour des Appdir à l'installation/MàJour d'un logiciel pour signaler par mail à root que des bundle du même programme trainent sur le système, ça peut être une info intéressante (nettoyage tout ça). Mais ça nécessite que les bundle soient les même pour tous.

                          Avec autopackage/OBCLICK/klik... on multiplie les solutions, preuve qu'un réel besoin existe. Un standard de travail pour tous les bureaux, c'est le but de freedesktop. Je trouve que le bundle d'application à la NextStep manque dedans. Et que ça serait une meilleure solution que celle proposée par Ian Murdoch.

                          • [^] # Re: Ça n'arriveras jamais

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

                            1) le binaire prêt à l'emploi, c'est pour un logiciel final "basique" ne dépendant de pas de trop de trucs en dehors d'une LSB 3.2. A partir du moment ou on aura une LSB 3.2 avec gtk, qt, python, beaucoup de logiciels destinés aux utilisateurs finaux pourraont fournir un binaire incluant les qualques libs qui manquent.

                            Dans le cas de gcompris, les dépendances ça doit être LSB 3.2 (gtk, python, pygtk) + SDL_mixer (et donc SDL) plus sqlite3 et pysqlite2 plus libgnomecanvas. J'en oublie peut-être une ou deux mais pas plus. Dans ces conditions ça reste raisonnable de penser fournir un bundle x86 prêt à l'emploi pour toute distribution compatible LSB 3.2

                            Si LSB n'a pas cet intérêt là, il ne sert à rien.


                            Pourquoi mais le LSB devra alors pouvoir évoluer régulièrement sans quoi aucune distribution n'aura envie de le respecter.

                            3) le but n'est ni de se substituer à un packaging de distribution, bien meilleure solution. C'est de pouvoir proposer une version à utiliser facilement sans casser les distribution, sans devoir attendre que la distribution ait mis à jour les paquets, et sur laquelle ont puisse demander de tester les corrections de bugs rapportés.


                            Le problème se poserait en ces points : pourquoi est-ce que l'utilisateur final continuerait à utiliser une distribution particulière s'il lui suffit d'en disposer d'une seule et d'installer les nouvelles versions de ses logiciels favoris via le système de bundle ?
                            Le risque de dérive n'est pas négligeable à mon sens et les outils de bundle risque de devenir une distribution à part entière à l'image de Cygwin pour Windows. Charge ensuite aux mainteneurs de fournir des versions à jour pour les failles de sécurité. La distribution pourra être facilement tenue à jour mais quid de la bibliothèque png fournie avec les bundle ?

        • [^] # Re: Ça n'arriveras jamais

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

          "Certains se débrouillent très bien aujourd'hui (oracle, google, nvidia)."

          Tu crois que nous sommes tous des dev nvidia ou oracle ?
          T'as pensé au développeur moyen qui fait un truc bien avec son c++ mais ne maitrise peut-être pas tout le reste ?

      • [^] # Re: Ça n'arriveras jamais

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

        > Euh, t'a entendu parler de macosx ?

        Oui, j'ai entendu parler de osx.

        Mais par contre, je voit pas en quoi c'est comparable.
        Il y a un seul macos X, fait par un et un seul éditeur. Si tu veut comparé osx à toutes les distros linux, tu fait une erreur. Compare plutot à un distribution, par exemple, rhel.

        Comme apple, rh propose un systéme avec une api figé, et ou tu peut facilement installé des binaires, sans passer par la lsb. La preuve, les paquets de oracle et compagnie sont souvent prévus pour rhel.

        Et si selon toi, osx est la panacée, tu peut me dire quel différence entre "le rpm s'installe que sur la distribution prévu pour" et "le .dmg s'installe que sur macosx"

        Il n'y a pas de systéme qui s'installe sur XP et Os X, qui sont quand même les 2 plateformes couvertes par les offres commerciales actuelles de la fnac.

        Et au passage, les .dmg d'osX ne gére pas les dépendances ( vu que c'est des trucs fournis tout prés) donc la gestion des mises à jours de sécu, c'est pas aussi simple que sur un linux, les composants sont peu liés entre eux donc de la redondance, ce qui entraine divers problémes, comme perte d'espace disque, perte de mémoire vive ( vu que les libs sont totalement séparés ).

        • [^] # Re: Ça n'arriveras jamais

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

          Tu as raison, je parlais de macosx hors propo, je voulais juste dire que sur un 'unix' on peut aussi faire des systèmes d'installation simples. Non je ne pense pas que macosx soit la panacée mais il apporte une solution élégante à ce problème.

          Pour la sécurité, il faut comparer ce qui l'est. Ici on parle d'application hors distribution. Si ton application est dans ta distro, quelle est à jour, aucun problème pour toi. C'est dans le cas inverse que ça ce gate. Tu crois qu'un 'sudo make install' en terme de sécurité c'est idéal, je ne pense pas.

          Pour les dépendances, c'est clair. Tous ce qui n'est pas fourni par le LSB doit être fourni par ton installation. Certe c'est loin d'être optimal en place disque et mémoire, mais au moins les gens peuvent utiliser ton logiciel !

          • [^] # Re: Ça n'arriveras jamais

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

            sur un 'unix' on peut aussi faire des systèmes d'installation simples
            euh tu veux dire comme des packages ?
            genre dispos pour solaris avec http://www.sunfreeware.com/ ? (pour AIX je ne me rappelle jamais du site...)

            ah tiens, z'ont même pas gcompris eux :/
            puis bon, z'ont un peu moins de packages que pas mal de distributions GNU/Linux aussi (si ça se trouve leur système d'installation doit être compliqué, flûte)

      • [^] # Re: Ça n'arriveras jamais

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

        Puisque tu prêches pour ton logiciel notamment, je ne comprends pas très bien ce que tu attends d'un tel système puisque tu as déjà des paquets binaires de ton logiciel pour la majorité des distributions actuelles (je fais fi de Mac OSX et Windows)...
        Quels sont donc les problèmes que tes utilisateurs rencontrent ?

        • [^] # Re: Ça n'arriveras jamais

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

          C'est vrai que GCompris est plutot bien supporté par les distributions et c'est une bonne chose mais c'est loin d'être parfait.

          D'abord le temps entre une release de GCompris et la disponibilité dans les distribution est très variable, impossible à déterminer ce qui nous éloigne de nos utilisateurs et de nos contributeurs. Pour un petit projet il nous est impossibe de maintenir 2 versions hors les distributions proposent des versions de GCompris en fonctions de leur date de sortie grosso-modo. Pour nous c'est ingérable d'un point de vu qualité. Les utilisateurs reportent des bug au packageurs qui connaissent mal le logiciel, remontent peut ou pas l'information au projet et quand ça arrive à nous on sait pas aider car la version est trop vieille ou ça dépend d'une distro qu'on a pas.

          Les problème de dépendance est bien géré sous GNU/Linux mais pose un vrai problème qualitatif. Les distributions supposent en gros que si ça compile avec la librarie 1.2.3-5, forcément ça marche. Hors nous on a bien testé avec la librairie 1.2.3-4 mais jamais avec la -5. C'est compatible, ça compile mais personne n'a jamais testé avec. Souvent ça marche mais parfois ce n'est pas le cas. Lorsque les développeurs mettent des require sur certaines librairies, le packageurs les modifient pour que ça compile mais comme il ne teste pas, il ne voient pas que dans certains cas ça marche pas.

          • [^] # Re: Ça n'arriveras jamais

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

            Ce qui tend à confirmer qu'il faudrait que vous vous occupiez vous-même de la création des paquets binaires des distributions majoritairement utilisées par vos utilisateurs ou d'assurer une co-maintenance du paquet officiel avec le ou les responsables tiers de manière à pouvoir faire un NMU (désolé pour le jargon Debian) uniquement sur tes paquets.
            Évidemment, le système de Debian se prête peu à cela car n'importe quel DD peut techniquement réaliser un NMU. Je dis bien techniquement car politiquement, certains DDs sont plutôt susceptibles et il vaut mieux avoir l'accord du responsable officiel pour en faire un. Heureusement, peu d'entre-eux s'en offuscent vraiment s'ils ont vraiment manqué de temps.
            Que les responsables de paquets ne testent pas leurs paquets, c'est leur ...responsabilités... et cela rejoint le premier paragraphe : il faut vous investir davantage dans la gestion du paquet en question.

            • [^] # Re: Ça n'arriveras jamais

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

              Et comment je sais quelles sont les distributions utilisées par mes utilisateurs ?
              Et si mes utilisateurs utilisent une distribution toute en chinois, je dois apprendre le chinois ?

              Non, sérieusement, ce que tu proposes est un non sens total, une surchage de travail inutile. Nous on veut développer des activités enrichissantes pour les enfants, pas passer notre temps à packager pour les différentes distros.

              • [^] # Re: Ça n'arriveras jamais

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

                Alors pourquoi proposer les paquets pour Mac OSX, Windows, plusieurs distributions Linux si tu ne sais pas toi-même quels sont les systèmes utilisés par tes utilisateurs ? Si tu n'as même pas la base de réflexion quant aux problèmes, ce n'est pas la peine d'aller plus loin : fais un sondage auprès d'eux et tu seras plus vite fixé.
                Je suis désolé mais si tu as un tant soit peu de soucis envers tes utilisateurs, la part de tests et d'intégration avec le système qu'ils utilisent est non négligeable et doit être intégré à ton processus de développement.
                Sinon, c'est que tu t'en fous ou que tu manques simplement de personnel compétent.

                • [^] # Re: Ça n'arriveras jamais

                  Posté par  . Évalué à 1.

                  Alors pourquoi proposer les paquets pour Mac OSX, Windows, plusieurs distributions Linux si tu ne sais pas toi-même quels sont les systèmes utilisés par tes utilisateurs ?


                  car les utilsiateurs utilisent souvent un panel important de ces sytèmes, quils ne répondent jamais aux sondages, surtout quand ceux ci sont sur une source différente que celle où l'on a choppé le programme, qu'on ne veut pas pénaliser les 3 utilsateurs d'un système particulier...

                  Je suis désolé mais si tu as un tant soit peu de soucis envers tes utilisateurs, la part de tests et d'intégration avec le système qu'ils utilisent est non négligeable et doit être intégré à ton processus de développement.


                  On parle de gcompris là ? si oui je ne crois pas qu'il y est une entreprise derrière qui paye les licenses de tous les os cibles. Même comme ça le nombre de version a testé est important (x windows + les sp, y distribs linux), cela prend énormément de temps, même si toute une partie est automatisé. De nombreuses sociétés préfèrent au final cibler qu'une ou 2 distribs, ou souvent qu'une ou 2 versions de win +sp spécifique.

                  Perso je pense que c'est le boulot de la distrib (ou de ces contributeurs), même s'il est vrai que je doute que même ceux ci testent réellement les produits packager, d'ou l'importance de bons jeux de tests.

                  • [^] # Re: Ça n'arriveras jamais

                    Posté par  . Évalué à 2.

                    Perso je pense que c'est le boulot de la distrib (ou de ces contributeurs), même s'il est vrai que je doute que même ceux ci testent réellement les produits packager, d'ou l'importance de bons jeux de tests.


                    C'est autant le boulot des distribs que celui de microsoft de fournir des installeurs pour tous les programmes.

                    Microsoft vend un OS avec un principe d'installation.
                    Chaque distrib fourni un OS avec un système de package. (ils fournissent en plus des programmes déjà packagés).

                    Après c'est aux développeurs de faire les .exe. Donc il serait logique que ça soit à eux de faire les .deb ou .rpm. Les contributeurs sont plus là pour aider les développeurs que faire leur boulot. Après les eusses et coutumes font que l'on arrive là ou on en est (et me demandez pas ou on en est)

                    • [^] # Re: Ça n'arriveras jamais

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

                      oui et non.
                      d'un point de vue développeur, effectivement ce serait à la distrib' de faire les paquets
                      d'un point de vue distrib', autant que les dévs maintiennent les packages,
                      ou alors que les développeurs trouvent des contributeurs en mesure de faire des paquets et gèrent leur intégration dans leur distrib' préférée (je sais pas pourquoi je suis plutôt pour cette dernière solution pour certains paquets...)

                      bon en fait, si, je sais pourquoi :
                      quand tu vois que pas mal de distribs ont aujourd'hui plus de 10 000 paquets (voire plutôt > 20000), qu'il n'y a pas forcément 100 employés dédiés à faire des paquets, une solution claire revient à faire appel "à la masse" des contributeurs (sans connotation négative), c'est à peu près un bon moyen de faire un tri dans les "logiciels valant le coup d'être packagés"
                      ainsi, c'est bien aux développeurs de motiver - parmi leurs utilisateurs - des contributeurs pour packager et aux distribs de simplifier la tâche aux contributeurs pour packager (je n'ai pas dit que c'était facile)

                      Après, il y a la politique de montée de version de chaque distrib' qui rentre en ligne de compte, l'obsolescence des "vieilles" distribs, le nombre limité de réels contributeurs... Pas mal de distributions proposent des backports, quand le logiciels n'a pas de dépendance à trop de libs structurantes, ça peut valoir le coup et le coût (pas encore pour Firefox, ni KDE ou Gnome sans vouloir lancer de troll, des backports déstabiliseraient un peu trop le système...).

                      Je comprends tout de même les développeurs qui chouinent contre les distribs et les packageurs qui chouinent après les développeurs (bon ya aussi les utilisateurs qui chouinnent, mais bon parfois il y a un merci tout de même...). Il s'agit AMHA de trouver un mode de fonctionnement qui convienne à tout le monde ; perso, le système de paquets me semble le plus intéressant : cela permet d'avoir plus de contributeurs "éclairés" pour les développeurs upstream ET pour les distributions (et moins d'utilisateurs qui cassent leur système à vouloir contourner le système de paquets de leur distrib'...).

                      • [^] # Re: Ça n'arriveras jamais

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

                        Et si les distro faisait moins de chose et en concéquence mieux. Au lieu de packager elle même 20000 logiciels, si elle faisait une vrai plate-forme ouverte qui permette à des tiers d'installer des logiciels sans passer par elle.

                        Tout le monde y gagnerait :

                        - Distro plus stable, plus intégré car elle se concentre sur un nombre de logiciel selectionné minimal.

                        - Les développeurs tiers peuvent fournir eux mêmes des logiciels directement à leurs utilisateurs. C'est très important, en tant que développeur, je n'ai pas dépendre d'un tiers pour livrer mes logiciels, je décide de quel version maintenir ou pas, j'ai un contact direct et rapide avec mes utilisateurs.

                        - Les utilisateurs trouvent plus de logiciels car tous les projets livrerons alors un binaire multi-distro pour GNU/Linux, comme ils le font pour windows ou macosx.

                        • [^] # Re: Ça n'arriveras jamais

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

                          C'est très joli tout ça mais...
                          Quels sont les logiciels minimaux qu'ils se doivent de fournir ou pas ?
                          Admettons qu'Ubuntu soit presque sur le bon chemin : ils fournissent Linux et Gnome. Mettons de côté OpenOffice.org et Firefox car ils entreraient presque dans le cadre d'applications tiers.
                          Pour autant, chaque distribution sera donc fournie avec de nombreuses bibliothèques par défaut dont des bibliothèques graphiques dont dépendent ces applications tiers.
                          Il faudra donc que les développeurs d'applications s'en tiennent aux seules ABI fournies ou qu'ils compilent tout en statique, point.
                          Évidemment, cela risque de te contrarier dans tes plans de développement mais, contrairement à ce qu'il se passe sous Windows où l'API est figée, celle des bibliothèques (sans même parler du noyau) ne l'est pas. Pourquoi est-ce que les autres développeurs mettraient-ils leurs développements en berne uniquement pour satisfaire les besoins de quelques autres ?
                          C'est une bien belle idée mais elle n'est pas non plus réalisable sinon, il y aurait longtemps que ce serait déjà fait.

                        • [^] # Re: Ça n'arriveras jamais

                          Posté par  . Évalué à 3.

                          duh !

                          des utilisateurs VEULENT ces softs AVEC leur systeme. pas en allant à la peche sur internet ! en cliquant sur un menu "installer des logiciels" puis en tapant un nom ou une description et pas en utilisant Google et fouiller parmi 5-20 résultats pour tomber sur le bon site et fouiller encore 5 liens pour trouver le bon lien de téléchargement parmi 10 foireux. et ensuite, avec un bon gros bouton "mettre à jour" DANS leur distribution.

                          dans le monde Windows tu vas trouver des gens qui se refont des "distributions" de Windows XP avec Office, Photoshop et des douzaines d'utilitaires divers comme Acrobat Reader, les dernieres versions des differents media players, des codecs et j'en passe, des Ultraedit, des décompresseurs...

                          ce n'est pas bien légal pour diverses raisons mais c'est pratique, rapide, efficace et j'en passe. enfin il parait. si tu livres un Windows nu à ce genre d'utilisateurs, ils vont passer une demi-journée à tout retrouver sur leurs CDs et sur Internet et à l'installer. je suis sûr que ton idée ne va pas leur plaire.

                          alors, ton "Tout le monde y gagnerait", voyons voir...

                          > - Distro plus stable, plus intégré car elle se concentre sur un nombre de logiciel selectionné minimal.

                          le but précis d'une "grosse" distribution par rapport à un noyau nu, une Linux From Scratch ou qui fournit Klik et juste de quoi se connecter à Internet est justement de founir un grand nombre de softs, tous les classiques d'un système Unix et un environnement de bureau. et un compilateur, oui monsieur, et quand les CD se sont répandus comme support on les farcissait à ras bord. je regrette d'y trouver 23 Tetris et trois fois les mêmes économiseurs d'écran et des fossiles comme LaTeX mais tant pis

                          ton truc serait tellement minimal que je vois mal ce qui pourrait distinguer une distribution d'une autre : en fait tu vas même les faire disparaitre.

                          ce que tu veux est techniquement possible et même surement malin, mais vraiment tu vas contre le sens du vent. va voir chez Mac OS ou PC-BSD si tu veux une telle base unique. et ne te retourne surtout pas. oublie les utilisateurs de cette plateforme impossible à supporter directement comme ceux de BeOS ou Amiga et pense par contre aux gens sur consoles, eux n'ont pas de problème de librairies pas à jour. parce que GNU/Linux est une base fragmentée et que... c'est ainsi.

                          > - Les développeurs tiers peuvent fournir eux mêmes des logiciels directement à leurs utilisateurs. C'est très important, en tant que développeur, je n'ai pas dépendre d'un tiers pour livrer mes logiciels, je décide de quel version maintenir ou pas, j'ai un contact direct et rapide avec mes utilisateurs.

                          ah, bah voila, les distributions qui fournissent des librairies qui ne sont pas les mêmes que les tiennes te font chier. et en temps de développeur, c'est très important qu'on ne te fasse plus chier une fois que ça marche chez toi.

                          parce que toi, tu veux du direct, du rapide, du controle, t'en occuper toi-même. c'est bien, ça permet d'être réactif, d'améliorer vite le bidule, c'est vrai.

                          comme pour le coup de livrer une version chinoise ou en thaïllandais, comment tu vas faire ? tu vas apprendre ces langues à la con, et en fait les 42 autres que par exemple Wikipedia gère aussi ? j'aimerai bien te voir dire maintenant qu'elles n'ont qu'à apprendre l'anglais ou l'esperanto, ces langues universelles.

                          tu te prétends développeur mais crois moi tu n'as fait que 30 % de ton boulot si ton truc ne marche que chez toi. si tu veux livrer directement ton travail à tes utilisateurs en court-circuitant leur distribution, il faudra te taper le sale travail que la distribution a fait en fournissant les 20 librairies que tu ne vas pas réutiliser.

                          (et ne me dis pas que ces librairies n'auront qu'à faire partie de la LSB ou d'une LSB étendue, leurs versions auront changé dès que tu auras tourné le dos, au nom de la sécurité et du progrès)

                          > - Les utilisateurs trouvent plus de logiciels car tous les projets livrerons alors un binaire multi-distro pour GNU/Linux, comme ils le font pour windows ou macosx.

                          bof. ils vont surtout trouver des paquets vérolés, compilés et packagés par des inconnus, qui vont annoncer leur ajouter des smileys pour leur client email et en faire trouer leur systeme de A à Z. ils ne vont pas forcément te dire merci. déjà que plusieurs équipes de packagers font vraiment du travail de porc au point d'être désavouées par les auteurs des distributions concernées...

                  • [^] # Re: Ça n'arriveras jamais

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

                    On parle surtout d'installation sur de multiples distributions Linux : que viennent faire les questions de licences payantes dans le lot hormis pour RHEL (par exemple) ?
                    La plupart de ces distributions ne nécessitent nullement de payer quoique ce soit pour disposer d'une version récente et stable ou de développement.
                    Il y a quand même un sacré gouffre entre le fait de bien vouloir passer du temps à construire un .exe pour des utilisateurs de ton Logiciel Libre sous Windows et rechigner d'en faire autant pour les différentes distributions sous prétexte qu'il y en a beaucoup. Il y a 2 systèmes de gestions de paquets binaires majeurs à maitriser, pour le reste, les différences entre les distributions tiennent à quelques « détails » si tu me passes l'expression.
                    Quand je vois l'éventail des paquets binaire proposés pour Gcompris, il est loin d'être mal lotis et j'ai encore plus de mal à comprendre où serait son problème pour savoir ce que ses utilisateurs utilisent, à moins qu'il ne s'agisse des systèmes utilisés par les développeurs ? Dans ce cas, la boucle est bouclée.
                    Pour finir, si tu doutes des tests effectués par les responsables des distributions et tu préfères t'en remettre à des RC alors tes utilisateurs sont loin d'être stupides et auront plutôt intérêt à savoir te remonter les problèmes correctement pour que tu puisses y voir clair. Dans ce cas, à toi de leur fournir un paquet pour les systèmes que tu vises dans ton « marché ».
                    Il s'agit franchement d'un faux problème...

                • [^] # Re: Ça n'arriveras jamais

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

                  tu manques simplement de personnel compétent.

                  C'est le lot commun de l'écrasante majorité des projets libres, hélas. (manque de personnel tout court, même).

                • [^] # Re: Ça n'arriveras jamais

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

                  La majorité de nos utilisateurs sont sur plate-forme windows. Il m'est assez facile de faire des tests avant de livrer un binaire qui je suis sûr sera utilisé avec les même librairie que moi car je les livre toutes, hors les dll windows bien sûr.

                  On a bien quelques utilisateurs sur Ubuntu et Mandriva mais pas assez pour que ça justifie de supporter officiellement ces plate-formes. Chez GCompris incorporated, on a un budget limité tu comprends ;)

                  Tu vois c'est le raisonnement logique et implacable qui amène à ne pas supporter GNU/Linux que nous renvoi systèmatiquement les logiciels propriétaires.

                  Personnellement, j'ai choisi mon camp, je veux que GNU/Linux marche pour tout le monde, et pour cela, il faut que la distribution des logiciels devienne aussi simple et efficace que sur les plate-formes propriétaires.

              • [^] # Re: Ça n'arriveras jamais

                Posté par  . Évalué à 0.

                Et si mes utilisateurs utilisent une distribution toute en chinois, je dois apprendre le chinois ?

                et si tes utilisateurs aux yeux bridés veulent avoir la documentation de ton soft en chinois, (j'ai bien dit en chinois, pas en anglais), l'entrée dans les menus Gnome ou KDE avec un "logiciel educatif libre pour les enfants" traduit en chinois, qui va le faire ?

                tu vas les envoyer chier sous prétexte que c'est un non-sens pour toi d'apprendre le chinois ? non. tu vas laisser un sinologue s'en charger, dans son coin ou au sein d'une distribution Bolderiz Linux.

                que tu le veuilles ou non, il y a 200 Linux dehors dans le vrai monde. ils ont autant à voir entre eux que des marques et modèles de bagnoles différentes. dès que tu soulèves le capot tu as une pièce sur deux qui est incompatible d'une voiture à l'autre. c'est pas bien, c'est ballot, efforts dupliqués tout ça, mais c'est ainsi.

                si ça te pose un problème insurmontable comme tu en donnes l'impression, tu t'es visiblement trompé de plateforme. il fallait viser Java par exemple si les détails de packaging t'emmerdent à ce point. ou COBOL, tiens. COBOL c'est *très* portable.

                comme je l'ai déjà dit et comme tu le dis toi-même ici, tu ne veux faire que ce qui t'interesse, développer. soit. ok. c'est pas un crime. mais si tu veux à coté que tes utilisateurs sous "GNU/Linux" puissent utiliser tes créations sans aucun effort il faudra que quelqu'un fasse le reste du boulot.

                et si ce n'est pas toi aujourd'hui, laisse les autres intervenants - ici les packageurs des distributions ou des porteurs sur CoinCoinBSD - prendre en charge cette partie s'ils jugent ton soft digne d'interet et arrete d'exiger qu'ils soient toujours à jour de ta version quitte à ne pas la tester ou qu'ils la packagent comme tu le désires puisque c'est à toi de faire le boulot et que toi tu ne veux pas.

                "C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !"

                beeeeep. là il faut clairement définir où commence et surtout où s'arrête le support, l'aide que tu peux proposer. tu n'as pas forcément vocation à acceuillir toute la misère des utilisateurs du monde. une partie, les cas classiques, mais guère plus : si par exemple l'utilisateur ne trouve pas ton application ajoutée dans les menus de son bureau, c'est qu'elle a fait du travail de goret.

  • # Beuh

    Posté par  . Évalué à 5.

    Je ne voudrais pas passer pour le crétin de service, mais qu'est-ce qu'on fait des gens comme moi qui n'en ont rien à taper des binaires, et aiment compiler leurs paquets aux petits oignons (pas pour les perfs, hein, mais pour pouvoir dégager les features qui ne servent à rien et éviter les dépendances alakon) ?

    /me voudrait un format modulaire, style petit fichier descriptif (j'ai pas dis ebuil) permettant au choix de compiler sois-même (à bin si j'ai dis ebuild) ou d'aller automatiquement pomper un binaire compatible avec la machine sur un ftp quivabien.

    On peut voir une interface simple:

    pkg_install --compile vim (le choix du package est fait dans un but de propagande :p)
    pkg_install --binary vim

    Et hop, tout le monde a ce qu'il veut.
    Gros avantage, on peut comme ça garder tous les descriptifs de paquets en local et faire des recherche rapide dessus (eix en force).

    J'ai tout faux ou pas ?

    • [^] # Re: Beuh

      Posté par  . Évalué à 2.

      Je plussoie.

      Par ailleurs j'en profite pour ajouter une commande:
      pkg_uninstall vim
      pkg_uninstall --clean vim (avec gestion des dépendances inutilisées)

      Je sais pas ce qu'il en est de la capacité d'apt-get (par exemple) de faire le ménage des packets installés en dépendance mais deviennent inutiles après désinstallation d'un packet ciblé...

      • [^] # Re: Beuh

        Posté par  . Évalué à 3.

        Je ne sais pas pour debian, mais sous Gentoo c'est assez sport. emerge --unmerge (je suis tout seul a pas aimer la gueule de la commande ?) ne dégage pas les dépendances non-utilisées, mais emerge --depclean si. Le prob c'est que le dit depclean a une sale tendance à dégager ce qu'il ne faut pas, du coup je ne l'utilise jamais.

        Accessoirement, emerge est immondément lent (normal c'est du python).
        Ok, c'était le troll du jour, mais rien à taper, j'ai trois bécannes sous gentoo, et j'en souffre tous les jours.

      • [^] # Re: Beuh

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

        >> Je sais pas ce qu'il en est de la capacité d'apt-get (par exemple) de faire le ménage des packets installés en dépendance mais deviennent inutiles après désinstallation d'un packet ciblé...

        Aptitude est ton ami.
        Ou alors si tu tient à utiliser apt-get ou synaptic tu peux aussi faire le ménage avec deborphan.

        • [^] # Re: Beuh

          Posté par  . Évalué à 3.

          apt-get autoremove me semble faire la chose désiré

  • # Tiens, Ian Murdock parmi les « personnes-clés »

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

    Comment ne suis-je pas étonné de voir le fondateur de Debian et surtout de Progeny venir encore une fois à l'assaut avec sa prétendue compatibilité binaire que Marck Shuttelworth a déjà maintes fois démonté.
    S'agissant principalement de Logiciels Libres, le modèle d'installation des logiciels sous Windows n'est guère applicable sous Linux.
    Pour ce faire, il faudrait que les éditeurs de logiciels tiers fournissent des paquets binaires compatibles comme le font actuellement les éditeurs tiers de logiciels sous Windows, point barre. Évidemment, ils devront le faire pour chaque distribution, le problème soulevé est toujours le même...
    Que ceux qui prétendent ainsi faciliter la vie de leurs utilisateurs fassent donc le nécessaire pour que ces derniers puissent trouver plus rapidemment des versions binaires des logiciels libres pour leurs distributions préférées au lieu d'ergoter sur un fumeux et éventuel « standard ».

  • # Et pourquoi que ?

    Posté par  . Évalué à 1.

    J'ai jamais compris ce qui empechait les distribs d'avoir une base commune de libs importantes (ex: libc, libstdc++-quiestjamaislabonneversion, x11, gtk, ...) mises à jour en même temps pour "tout le monde", et qui permettrait d'avoir des binaires universels sans pour autant tout lier en static...
    Autant les distributions permettent d'avoir une liberté de choix (de conception, enfin appelez ca comme vous voulez), mais sur des trucs de base comme ca, je vois pas le problème...
    Quelqu'un peut expliquer ?

    • [^] # Re: Et pourquoi que ?

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

      On revient à la situation des utilisateurs windows depuis 20 ans : l'enfer des DLL

      http://en.wikipedia.org/wiki/DLL_hell

      C'est pour résoudre ce problème que windows à fait son java (qui devait éviter ces problèmes : .net

      C'est fou comme en informatique on rebute souvent sur les mêmes problèmes.

      • [^] # Re: Et pourquoi que ?

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

        Le problème des DLL vient en grande partie du fait que les logiciels installent des DLL dans le répertoire système partagé, influant sur l'intégrité du système.

        Il n'est pas prévu je suspose de permettre ou d'encourager cette pratique mais par contre, bien sur, il faut que les logiciels fournissent les librairies dont ils ont besoin et qui ne sont pas intégrées dans le LSB.

        • [^] # Re: Et pourquoi que ?

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

          Ce que fait autopakage en installant dans /usr/, non ?

          • [^] # Re: Et pourquoi que ?

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

            Si tu mets des librairies système dans ton autopackage surrement mais c'est pas l'objectif. Je crois d'ailleurs que dans ce cas il garde une copie de la version ecrasée. Mais je ne tient pas autopackage comme une solution idéale, ni ceux qui le font d'ailleurs. C'est juste mieux que 'make install' pour des utilisateurs finaux.

            Sinon, tu peux aussi faire un 'sudo make install' qui ecrase des lib systèmes, il n'y a pas de différence.

        • [^] # Re: Et pourquoi que ?

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

          Il faut fournir aussi les versions des librairies qui sont sur le LSB pour le cas où l'upgrade des librairies est incompatbles avec les versions précédentes => explosion de l'espace disque et trous de sécurité en perspective.

          En plus je soupçonne des problèmes d'accès au hardware : quand l'API kernel change (exemple pour accéder au framebuffer), les librairies user space doivent changer. Donc les paquets binaires figeront les distributions à la windows. On devra maintenir les systèmes pour faire marcher le plus grand nombre de logiciels binaires et geler les mises à jour, et renoncer à installer de nouveaux paquets ou des mises à jour sécurité.

          Bref, bienvenue dans le monde windows en moins bien.

          • [^] # Re: Et pourquoi que ?

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

            Au moins, on pourra sortir Debian stable dans les temps impartis (3 ans pour Windows). ;-)

          • [^] # Re: Et pourquoi que ?

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

            Sans oublier les mailing listes développeurs inondées de rapport de bug déjà résolu liés à des librairies imaginons :

            ML KDE rapport de bug type : ksound system provoque une erreur 3128 le son marche pas.

            Bug corrigé il y a un an par la mise à jour de la lib trucsound.

            Oui mais avec kcompris 3 ça marche pas

            3 jours d'investigation après et de long logs épluchés

            Vous avez installé un paquet binaire contenant une version bugguée de la lib, veuillez vous plaindre au mainteneur du paquet

            Mainteneur du paquet : ben fallait chercher le paquet sur mon site d'origine on utilise pas pkg_add pour ce paquet binaire, comme on a maintenant un format unique de paquets, on les téléchargent tous au même endroit quelque soit la distro, c'est ça le progrès puis comme ça je suis sur que les paquets sont à jours si les gens les cherchent chez moi.

            (n paquets binaires => n manière de faire apt-get install ou pkg_add différentes : vive l'aspirine! Tirage de cheveux en perspective pour les mainteneurs de logiciels et ainsi de suite. On passe de 10 minutes de pkg_add apt_get pour les maj, à un script qui fait du wget dans tous les coins fait son install à sa manière, backup au cas ou => on croise les doigts pour que ça marche).

            Retour à la ML kcompris : Oui mais à cause de kassepied (plugin kcompris) qui a été compilé avec infernoX et vous qui avez fait l'upgrade de infernoY pour cette version à jour de kde, j'aurais besoin d'un version binaire avec la libKDE récente, mais une version libinfernoX c'est possible ?

            Et l'on passe d'une version de kcompris "mainstream" à xx versions en fonctions des spécificités d'install et des choix de librairies. Je rappelle que les combinatoires croissent plus qu'exponentiellement, donc on finira par voir des linux 2008 (avec toutes les libs figées), puis linux 2010 et pour passer d'une version à l'autre, il faudra tout réinstaller.


            Au final, je doute que cela sera plus simple, mais je suis sur que les utilisateurs windows se retrouveront moins dépaysés.

            • [^] # Re: Et pourquoi que ?

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

              Relis bien, ce qui est proposé c'est que chaque application livre l'ensemble des librairie dont elle à besoin, en dehors de ce qui est définit dans le LSB.

              Je me permet de te faire remarquer que la situation actuelle n'est pas idéal dans la gestion des dépendance. Les distributions supposent que si ca compile avec la librairie X alors ça marche. Je suis convaincu qu'aucun test sérieux n'est réalisé pas les packageurs en ce qui concerne GCompris.

              • [^] # Re: Et pourquoi que ?

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

                Si tu trouves qu'ils manquent de sérieux, retire les liens de ta page de download et, dans le cas des paquets intégrés aux distributions, assure toi-même le travail.

                • [^] # Re: Et pourquoi que ?

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

                  Je trouve que ça manque de sérieux oui, mais dans l'état actuel des choses c'est la meilleure façon de procéder pour distribuer notre logiciel à nos utilisateurs sur GNU/Linux. Autopackage n'est pas parfait et c'est pour cela que je trouve l'initiative du LSB très intéressante.

                  J'en ai un peu mare de l'auto-satisfaction autour de GNU/Linux, c'est en critiquant et en écoutant nos utilisateurs qu'on progresse.

                  • [^] # Re: Et pourquoi que ?

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

                    Si le packaging est dur à faire, c'est parfois aussi de la faute des concepteurs de logiciels et de leur choix d'outils. En tant que sysadmins, je suis un utilisateur de bsd et debian et parfois windows, j'ai eu à subir les paquets binaires, et les trucs mal packagés à la sauce HP, et je trouve que la solution du logiciel libre est la plus satisfaisante, même si je suis pour l'améliorer.

                    En tant que sysadmin, notamment sur BSD, les automakes autoconf et auto conneries ne m'ont apportés que des emmerdes. donc je suis loin d'être auto satisfait.

                  • [^] # Re: Et pourquoi que ?

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

                    Quels utilisateurs ? Ceux qui ne répondent pas aux sondages ?
                    Il ne s'agit pas d'auto-satisfaction mais de ne pas non plus faire table rase des acquis. J'ai l'impression que tu confonds un peu ton besoin particulier avec ton logiciel et l'ensemble des logiciels libres. Autopackage n'est pas la panacée mais dans ton cas, la seule solution serait pour toi de fournir un gcompris compilé en statique au mépris des règles de ces distributions qui ont l'air de te gêner...
                    Pour ce qui est des jeux libres, il y a sans doute un modèle de mise à jour à revoir.
                    Tu ne vas pas me dire que tu modifies le coeur de ton logiciel tous les jours ?

                  • [^] # Re: Et pourquoi que ?

                    Posté par  . Évalué à 2.

                    J'en ai un peu mare de l'auto-satisfaction autour de Météo-France, c'est en critiquant ces scientifiques et en écoutant nos agriculteurs et nos touristes qu'on progresse !

                    ON AURA DU BEAU TEMPS QUAND ON VOUDRA BORDEL ! ET IL NE PLEUVRA QUE LA NUIT POUR ARROSER NOS SALADES ! ENVOYEZ VOS PETITIONS A METEO-FRANCE, IL FAUT ARRIVER A LES FAIRE PLIER !

      • [^] # Re: Et pourquoi que ?

        Posté par  . Évalué à 2.

        On revient à la situation des utilisateurs windows depuis 20 ans : l'enfer des DLL.

        N'importe quoi!!! Le versionning des bibliothèques sous Linux (Unix...) empèche l'enfer des DLL de se produire depuis des lustres. C'est même scandaleux que MS ait réussi à concevoir leur windows à l'époque avec ce genre de problème que tout le monde croyait reglé.

        Pour faire bref, si on travail correctement (cad comme ca devrait TOUJOURS etre le cas) un numéro de révision identifiant la compabilité binaire est dans le nom du fichier (un ldd sur l'executable montre les versions des biblios utilisées) et quelques symlink permettent de retrouver les numéro de version mineurs (sans changement d'ABI) ainsi que de permettre un link avec une version par defaut au build time.

        Pour être plus clair (si j'y arrive) plusieurs versions de biblio cohabitent sans aucun problème et l'executable "choisi" la bonne automatiquement (le système choisi la bonne pour lui en fait).

        • [^] # Re: Et pourquoi que ?

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

          oui ;-) mais tu oublies le cas où la lib' nécessaire est dans la dernière version, qui - justement - n'est pas encore packagée par la distribution :/

          Puis bon, effectivement, les bonnes pratiques de gestion de version de libs existent, faut-il encore que la libification ait été faite correctement par les développeurs (gecko cause quelques petits soucis par exemple, ceci expliquant que le dernier firefox 2.0 n'est pas packagé par pas mal de distribs en backport vu que cela casse epiphany, galeon, yelp et d'autres trucs...).

          • [^] # Re: Et pourquoi que ?

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

            Puis bon, effectivement, les bonnes pratiques de gestion de version de libs existent, faut-il encore que la libification ait été faite correctement par les développeurs (gecko cause quelques petits soucis par exemple, ceci expliquant que le dernier firefox 2.0 n'est pas packagé par pas mal de distribs en backport vu que cela casse epiphany, galeon, yelp et d'autres trucs...).

            Lesquelles ?

  • # ça peut pas marcher ?

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

    Voici un certain nombre de cas qui me disent que cela pose problème :

    outils pour récupérer/manipuler en click a click des paramètres/réglages de la nouvelle carte trucmuche avec drivers proprio dans le kernel (au choix gadget HP sur cartes mères, overcloking/température sur nvidia, carte wifi ...) => J'aurais beau installé la partie user space en binaire si j'ai pas les drivers binaires je suis mal. Et l'on revient au fait qu'il fait résoudre les problèmes des blobs dans le kernel, et que cela ne marcherait peut être pas sur BSD x86 avec compatibilité binaire (qui est aussi un système libre), voire sur linux sparc64.... Donc la distribution de binaire pour ce secteur sera toujours moins intéressante que l'accès aux specs du hardware. (Cela coûtera en plus plus cher aux éditeurs).

    Autres choses, imaginons une IHM de haut niveau. Comme il faut compiler tout en static, le binaire va réintégrer les librairies genre gtk, expat, sdl, ... non seulement la taille des install va exploser, mais quid des interactions (pour une appli qt par exemple) entre le nouveau desktop (KDE) et le binaire avec ses anciennes librairies. N'y a t'il pas des risques de devoir régler son système sur les applis binaires ? Du genre j'ai une appli métier qui utilise tel mécanisme donc je peux plus upgrader mon serveur qui est en DMZ. En tant que sysadmin, je serais pas chaud.

    Pour les serveurs, (oracle par exemple) imaginons, c'est bien beau d'avoir les binaires, mais le sysadmin veut aussi une standardisation des emplacement de réglages (/etc/), des fichiers de log/pid, des scripts de démarrage, qu'en sera-t'il. Le démarrage sur un BSD (compatible binaire linux) qui se fait à la slackware, n'est pas le même que dans une RH ou une debian. De même pour la gestion des droits, il est parfois sain de créer un utilisateur local, avec toutes les contraintes et conventions par système, ça sent l'usiine à gaz.

    Et que se passe-t'il quand une librairie (dont on on ne sait pas qu'elle est intégrée si le binaire est strippé) souffre d'une vulnérabilité ? On ne remet plus à jour une librairie, mais n applications ? En plus comment peut on faire confiance à des éditeurs propriétaires pour bien vouloir jouer le jeu de la transparence nécessaire à la sécu, alors qu'il livre la forme la plus obfuscated possible du code, c'est à dire un binaire ?
    Ca va faire exploser le besoin en maintenance sur les serveurs (chic du boulot). Et déjà qu'on peut ne pas avoir confiance dans des logiciels même quand on a les sources, alors avec du binaire, faut être sacrément confiant. Vous vous sentez installer un logiciel sous forme binaire de gestion de DVD-rom fourni par sony vous ?


    Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle

    • [^] # Re: ça peut pas marcher ?

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

      Le choix le plus simple, le plus efficace serait quand même que les éditeurs comprennent que leur métier c'est le service et pas la vente de logiciels en boîte, et se mettent à faire du logiciel libre, et continuent à faire du service payant. Peut être même que ce serait plus rentable si on regarde les économies d'échelle

      Ramener le problème à l'aspect libre/propriétaire est une erreur. Ce sont 2 problèmes bien distinct. Je fais du logiciel Libre ET je désire que mes utilisateurs puissent l'installer simplement, quelque soit leur distribution.

      • [^] # Re: ça peut pas marcher ?

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

        Voir les DLL hells évoqués ci dessus.

        L'enfer de la gestion des dépendances est intimement lié à la distribution de logiciels binaires.

        Le prix de la "facilité de d'installation" sera le prix de la maintenance tant des paquets (générer autant de binaires que les dépendances l'éxigent, et de systèmes cibles) que du système.

        La qualité des paquets debian/bsd tient au fait que les dépendances et adaptations au système sont gérées à la main.

        Je soupçonne que vouloir des paquets binaires simplement multi OS est un problème équivalent à générer les paquets leur dépendances, leur acclimatation auto magiquement. Quand je vois autoconf/automake, l'ambitieux système rpm, je crains qu'ils ne vaillent mieux réflêchir en amont de la génération de paquet à la création de logiciel qui est :
        Quelles pratiques des développeurs et packageurs permettraient de générer plus facilement les paquets pour toutes les distros tout en alourdissant pas de manière rébarbative la création de logiciel ?

        J'entend presque la critique habituelle des openBSDistes aux codeurs "linux" qui est : il faudrait que les développeurs apprennent à coder proprement et plus sobrement sans multiplier les dépendances, les trucs plateformes/linux spécifiques et gadgets inutiles (aka gnueries).

        A mon avis la problématique de la distribution de binaire risque d'aboutir à une usine à gaz servant à corriger des problèmes en amont. Mais bon je fais ma Cassandre et j'attend pour confirmer mon opinion.

      • [^] # Re: ça peut pas marcher ?

        Posté par  . Évalué à 1.

        En plus, moi fournisseur officiel de malware et spyware, je serais enchanté d'avoir un mécanisme d'installation simple pour le profane, qui marche sur tous les linux et qui n'a pas besoin des distributions.

        Le mec qui fait du logiciel libre tout seul dans son coin, il a pas des millions de lignes de codes, alors la compilation se fait rapidement.

        tu fais un rpm et avec alien tu résouds 95% des distributions. Ah non, les versions gtk1.2 gtk2.4 blabla.... kde3.4 Kde4 libc6 2.35 libc6 2.45

        ben perdu ca peut pas marcher ou alors tout le monde le même windows .. euh ... lindows ... euh .. linagora ...euh... non je sais pas. Il faudrait que toutes les distributions aient les même lib. si si c'est bien windows.

      • [^] # Re: ça peut pas marcher ?

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

        Justement, pour Oracle, le service inclut de t'apprendre à installer leurs produits correctement. Tu penses bien qu'ils n'allaient pas te fournir un truc tout fait...

      • [^] # Re: ça peut pas marcher ?

        Posté par  . Évalué à 3.

        >Le choix le plus simple, le plus efficace serait quand même que les éditeurs
        >comprennent que leur métier c'est le service et pas la vente de logiciels en boîte

        zarb. j'aurai dit que le boulot des boites de service, c'est le service et que le boulot des editeurs, c'est la vente de logiciel.
        Et meme mieux : le modèle economique propriétaire peut etre bénéfique à l'utilisateur : la mutualisation des couts de developpement est possible avec un modèle vente de licence. Avec un modèle "vente de service", les possibilités sont les suivantes :
        - vendre le developpement prix coutant ( gasp pour le pigeo^Hclient )
        - vendre le developpement moins cher et esperer qu'on pourra le vendre plusieurs fois ( faut pas que ton client se mette à diffuser gratuitement ton soft ;-)
        - mettre les specs sur sourceforge et attendre que des types developpent le truc gratos pour toi ( bonne chance ;-)
        - bosser à l'oeil puis ouvrir un compte paypal et lancer des appels aux dons sur linuxfr ( ... ;-)

        Quant à la rentabilité du logiciel libre, j'en causerai à bill gates la prochaine fois que je le croiserai ;-)

        • [^] # Re: ça peut pas marcher ?

          Posté par  . Évalué à 4.

          Et meme mieux : le modèle economique propriétaire peut etre bénéfique à l'utilisateur : la mutualisation des couts de developpement est possible avec un modèle vente de licence.

          Attention, tu n'es pas loin de dire qu'il y a des logiciels qui n'existent que parce qu'ils sont propriétaires. Je me dois donc de te rapeller La Parole :

          But if that doesn't work for you, I would not consider it a great loss for the world if your products were not produced. They contribute something to the world if they are free software, but otherwise not. --Richard Stallman

  • # Euh....faire comme PC-BSD ????

    Posté par  . Évalué à -1.

    Euh, en fait ce que les gens souhaiteraient, c'est d'avoir sous Linux, un système d'installation désinstallation aussi simple que sous PC-BSD et son PBI : http://www.pcbsd.org/?p=learnpbi

    Je cliques, ça s'installe, et c'est tout.
    Je veux désinstaller, ça désinstalle, et c'est tout.

    Le mieux : MacOSX : je cliques, ça installe. Je mets à la poubelle, c'est désinstallé (même si je ne sais pas si sous MacOSX ça soit si bien désintallé que ça : reste de libs, etc...).

    On peut pas faire plus simple, et ça marche très bien.

    Les pro-gestion des dépendances, les "je m'amuse avec apt, smart, urpmi", etc...., n'ont aucun argument valables face à cette demande.

    Cela n'empêche d'ailleurs pas d'avoir des dépôts officiels, supportés, et d'autres genre "universals" ou "contrib".


    Donc le LSB peut former un groupe de réflexion, etc... : la réflexion est déjà faite par d'autres. Il "suffit juste" de l'adapter à linux, et de se grouiller de le faire MAINTENANT, si on veut réellement que Linux est une visibilité suffisante auprès du public, et surtout des développeurs de jeux et des contructeurs matériels.

    Beryl c'est bien.
    Pouvoir l'installer facilement, c'est mieux. :p


    Mes deux piécettes.

    • [^] # Re: Euh....faire comme PC-BSD ????

      Posté par  . Évalué à 0.

      Le soucis avec Mac OSX, c'est que, certe ça s'installe facilement puisque toute les librairies nécessaires sont fournies avec le programme, mais quel fouilli ensuite. On se retrouve avec des librairies installés en double, triple, quadruple, j'en passe et des meilleurs, exemplaires.

      L'espace disque n'étant pas encore illimité, voir même franchement limité dès qu'on touche à du matériel un peu ancien, je ne pense pas que ce système soit réellement adapté. Après tout, Linux n'est pas déstiné uniquement à des machines modernes comme l'est Mac OSX.

      • [^] # Re: Euh....faire comme PC-BSD ????

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

        Personne n'a dit qu'il fallait arreter rpm dpkg et consort. C'est une option supplémentaire, pour simplifier l'installation, pas une obligation.

        La question est toujours, si ton appli n'est pas packagé pour ta distro, comment tu fais. Tu préfères gagner quelques kilo octet de place disque et avoir ton logiciel ou attendre que quelqu'un fasse un paquet.

    • [^] # Re: Euh....faire comme PC-BSD ????

      Posté par  . Évalué à 0.

      Les pro-gestion des dépendances, les "je m'amuse avec apt, smart, urpmi", etc...., n'ont aucun argument valables face à cette demande.

      ils l'ont de manière neuneu-proof avec Ubuntu. vraiment. tes gens quand ils te disent Linux tu leur dis Ubuntu (ou autres distributions autant neuneu-proof) et le tour est joué.

      et pour ton exemple avec Beryl, comment aurais-tu fait si PBI ne le fournissait pas ? (parce que pas eu le temps/autre raison à la con...)

      • [^] # Re: Euh....faire comme PC-BSD ????

        Posté par  . Évalué à 0.

        Moi ce que je constate, c'est que les utilisateurs lambda aiment plutot bien le système de dépendances/packages de Linux, qui permet d'installer très simplement des logiciels, et tout ce dont ils dépendent.
        Mais dès que le logiciel n'est pas fourni en package pour la distrib, c'est le drame, et systèmatiquement, l'utilisateur laisse tomber Linux.

        Alors y serait peut-être temps que toutes les distributions aient une base suffisante de librairies équivalentes qui permettent de diffuser des programmes sous forme binaire, avec pourquoi pas un installateur, qui ira coller le programme dans /usr/local/ et qui enregistrera les informations de désinstallation grâve à la fameuse API...

        Franchement, je suis un utilisateur quotidien de Linux, mais c'est pareil: compiler, y'en a marre: ca prends du temps, quand ca marche pas c'est le gros merdier (allez chercher dans le code le nom de l'include qui manque, etc), faut installer des dépendances (qui avec un peu de chances seront aussi à compiler), on peut pas désinstaller après (oh si, je vais m'amuser à garder toutes les sources pour pouvoir faire make uninstall !),...

        S'il n'y a pas d'évolutions importantes dans ce domaine, Linux restera "trop compliqué". Il ne faut pas oublier que pour les "gens normaux" l'ordinateur est un outil.

        Pour ceux qui diront qu'en facilitant la diffusion de binaires on nuit à l'opensource, je pense que ce n'est pas vrai, et qu'il existe une dynamique libre au delà des utilisateurs de Linux, et que ce n'est surement pas par la contrainte (obligation de releaser des sources parce que sinon ca passe pas sur tel distro gnagnagna...) qu'on encourage le développement de l'opensource ("1/ je release un truc en binaire, j'ai pas envie de montrer mon code 2/ sous linux on peut pas 3/ y font chier mon programme sera que pour windows" != "1/ je release mon truc en binaire, j'ai pas envie de montrer mon code 2/ je le fait aussi sous Linux parce que qu'on peut 3/ les gens qui utilisent mon programme me demandent de releaser mes sources parce qu'ils ont aimé mon programme 4/ je release mes sources parce que mon programme a été apprécié").
        Ok, il y a encore le problème des logiciels commerciaux, mais là c'est autre chose.

        • [^] # Re: Euh....faire comme PC-BSD ????

          Posté par  . Évalué à 2.

          et ? comment tu fais sous Windows quand un soft bien bien tentant n'est disponible que sous Mac OS/X ou Linux ou un vrai Unix ? ou quand un jeu est disponible sur deux des consoles modernes du marché mais - manque de pot - pas la tienne ?

          ce n'est pas avec des discours et de longues phrases creuses barbouillées de gras comme "pour les gens normaux l'ordinateur est un outil" que tu vas changer certaines réalités physiques du monde réel comme "il faut bien que quelqu'un s'y colle pour le faire" et des problèmes de logistique qui t'échappent visiblement.

          "une base suffisante de librairies équivalentes". les librairies équivalentes, ah oui, vraiment. j'attends patiemment que des softs pour les bureaux KDE ou Gnome débarquent, comme Gambas, tiens, ou Quanta. ensuite j'aimerais que les versions de Qt, KDE et de ces softs commencent à bouger dans tous les sens. j'aimerai voir le sac de noeuds insondable que ça peut devenir si on décide d'en mettre un à jour mais pas l'autre...

          je dis pas que c'est infaisable, hein, je devine précisement ce que ca va donner. je dis juste que c'est pas la solution.

        • [^] # Re: Euh....faire comme PC-BSD ????

          Posté par  . Évalué à 7.

          >Ok, il y a encore le problème des logiciels commerciaux, mais là c'est autre chose.
          non c'est exatement le même problème.

          1/ tu releases tes sources et si ton programme est sympa, il se retrouvera packagé pour toutes les distros majeurs.

          1a/ tu ne veux pas releasé tes sources, tu te demerdes.point.
          Le libre c'est ca, linux c'est le libre, linux c'est ca.point.

          Si tu veux faire du shareware sous linux, ca va pas bien ensemble, enfin, si .. en cherchant bien, y doit y avoir des distribs......

          Ensuite, pour les problèmes des distribs, il va y avoir le problème des versions des libs, parce que ceux qui font des softs avec les toutes dernières versions des libs, le parc de machines avec les libs correspondants est limité aux dev des dites libs et aux fana du ultra-blleding-edge-nightly-build et on revient au même problèmes, ils savent faire avec le sources.

          il est etonnant que ceux qui défendent ici (oui oui bruno), sont ceux qui veulent un mode comparable avec windows. Pourquoi ceux qui sont sous linux ne sont pas sous windows, ca c'est la bonne question que personne ne se pose.

          Parce que c'est libre, donc pour faire libre (je me repète pff) ET binaires universels faut linké en static et fournir les libs : ca marche MAINTENANT et pas besoin de redéfinir des trucs.
          SI on veut pas linké en static, il faut que toutes les distribs fournissent les même libs, avec les même options de compils (en clair, il faut une seule distrib) et c'est ce qu'on ne veut pas.

          Il n'y a pas de solution. ce qu'il en sortira c'est probablement un nouveau truc top fashion qui marchera pas parce que personne ne voudra prendre le risque de foutre la merde sur sa machine en gérant 2 sortes de packages avec des versions de lib différentes, ou alors il réinstallera sa machine tous les ans (ca me rappelle quelque chose.....)

          • [^] # Re: Euh....faire comme PC-BSD ????

            Posté par  . Évalué à 2.

            tu releases tes sources et si ton programme est sympa, il se retrouvera packagé pour toutes les distros majeurs.


            Je pense qu'on peut assimiler sympa et "populaire auprès des geeks" dans ce contexte.

            Et si il est sympa mais genre ultra spécialisé et qu'il n'intéresse ou est utile qu'à quelques personnes dans le monde, et qu'en plus c'est des non geeks, amha c'est pas gagné pour qu'il soit intégré dans les distros.

            • [^] # Re: Euh....faire comme PC-BSD ????

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

              >Et si il est sympa mais genre ultra spécialisé et qu'il n'intéresse ou est utile qu'à quelques personnes dans le monde, et qu'en plus c'est des non geeks, amha c'est pas gagné pour qu'il soit intégré dans les distros.

              Dans ce cas l'utilisateur peut parfois mettre la main au porte monnaie ou offrir une bière à quelqu'un qui fera le paquet pour lui.

              • [^] # Re: Euh....faire comme PC-BSD ????

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

                En tant que packageur, je te répondrais la chose suivante : faire un package, c'est facile. Une heure ou deux pour les plus compliqués, quelques minutes pour les plus simples.
                Par contre, maintenir le package, le mettre à jour, corriger les bugs, l'adapter aux modifications du logiciel source pour toute l'éternité, ça, c'est nettement plus coton.

                Donc payer une bière à un mec pour qu'il te fasse le package, c'est jouable, mais c'est pas une solution viable à long terme. Ou alors faut avoir un sacré budget bières.

                Le mieux c'est soit :
                - de trouver un de ses utilisateurs (par distrib) qui sait faire des packages,
                - d'apprendre à un de ses utilisateurs (par distrib) comment faire des packages,
                - d'apprendre à faire des packages déjà pour sa distrib, ensuite pour les autres,

                Bref pour être packageur il faut être utilisateur de l'appli ET de la distrib.
                Apprendre le packaging en soi c'est pas très difficile pour un linuxien un peu geekeux, c'est du shell ou du Makefile, et beaucoup de lecture de guidelines.

                Donc il suffit de trouver un geek par distrib parmi ses utilisateurs ! Facile, non ?

                Sinon je voudrais signaler l'existance de mach, un outil qui va recompiler des rpms dans un "chroot" spécifique à chaque distrib : http://thomas.apestaart.org/projects/mach/
                Ca connaît Fedora, Red Hat, SuSE et il me semble Mandriva. Le gros avantage c'est qu'on peut facilement recompiler son package pour plein de versions de sa distrib, voire pour d'autres distribs.


                P.S.: j'accèpte les bières ;o)

            • [^] # Re: Euh....faire comme PC-BSD ????

              Posté par  . Évalué à 1.

              Et si il est sympa mais genre ultra spécialisé et qu'il n'intéresse ou est utile qu'à quelques personnes dans le monde

              bah dans ce cas je ne vois pas pourquoi tu fais tout un cinéma pour le voir disponible partout et pour tout le monde : tu vas même gaspiller des ressources précieuses alors que tu auras moins d'utilisateurs qu'il n'y a de distributions dans le monde...

        • [^] # Re: Euh....faire comme PC-BSD ????

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

          Alors y serait peut-être temps que toutes les distributions aient une base suffisante de librairies équivalentes qui permettent de diffuser des programmes sous forme binaire, avec pourquoi pas un installateur, qui ira coller le programme dans /usr/local/ et qui enregistrera les informations de désinstallation grâve à la fameuse API...


          Si tu tiens à bloquer l'ABI des bibliothèques, libre à toi mais tu m'expliqueras comment les développeurs d'applications tierces feront pour développer leurs logiciels sans ré-installer des versions supérieures des dites bibliothèques de façon concurrente et de façon harmonieuse ? Ce n'est déjà pas si simple au sein d'une même distribution alors avec de multiples tiers...

          S'il n'y a pas d'évolutions importantes dans ce domaine, Linux restera "trop compliqué". Il ne faut pas oublier que pour les "gens normaux" l'ordinateur est un outil.


          En même temps, l'outil qu'est l'ordinateur n'a guère évolué depuis des années et demeure pourtant trop compliqué pour certains utilisateurs.

          Pour enfoncer le clou avec les développements propriétaires, leur problème est justement qu'ils ne comptent pas suivre les évolutions des ABI au rythme suivi par les logiciels libres. Il faudrait donc freiner tous les développements juste pour satisfaire quelques entreprises commerciales ? Désolé mais là, on n'est pas d'accord et sur ce point, même Linus rejoint RMS. Si les entreprises commerciales veulent VRAIMENT disposer d'un bon support sous Linux sans toutefois libérer leurs sources, qu'ils s'investissent davantage. Après, ce sont eux les demandeurs, pas nous.

  • # Bon j'y vais aussi de mon petit commentaire

    Posté par  . Évalué à 4.

    Une partie de la force des systèmes unix viens de sa philosophie modulaire. On ne réinvente pas la roue, on la réutilise. C'est bien pour cela que l'on "s'embête" à gérer des dépendances.

    Certains disent "faut abandonner car ça rend linux plus compliqué que windows" (je schématise, mais l'idée est la).

    Dois-je leur rappeler que les applications windows aussi utilise des dépendances ? Qui n'a pas eu d'erreur pour une dll manquante ? la mauvaise version de MsNANANA.dll ? Une dépendance vers un DirectX version N.N ? Voir même se retrouver bloquer car son Windows 98 ne peut pas recevoir tel version de tel bibliothèque ?

    Alors, la modularité est plus poussées dans la communauté FLOSS, certe, et le problème ressort plus nettement, oui. Mais il n'est pas intrinsèquement différent selon les plateformes.

    Etre modulaire implique d'assembler des modules, ça me semble assez limpide. Et si l'assemblage peut paraitre laborieux, au vu du travail économiser par cet architecture, cela me semble être la bonne voie.

    A cela plusieurs solutions sont proposées. Et la liberté de choix est la. Personne n'interdit a un mainteneur souhaitant proposer son paquet au plus grand nombre, de faire un build static. Ceux qui trouvent cela malpropre s'en passerons, les autres seront heureux, devez vraiment vous tirer dans les pattes pour savoir qui a raison quand les deux, dans leur vision des choses, ont chacun raison ? N'est-ce pas la justement une expression de la liberté de nos système ? Si vous n'aviez pas le choix de la solution, et quelque soit cette solution imposée, vous la trouveriez adapté ! (voir les propos sur les installateurs windows, ça viens pas a l'idée de la personne de geuler car il a son logiciel sous une version compilé statiquement , puisqu'il n'y fait même pas attention)

    Par contre, juste une note a l'attention de ceux qui proposent des solutions "source". En dehors du débat "propriétaire/libre", prenont OpenOffice.org ou firefox. Qui vas expliquer a un utilisateur lambda que linux prend 12 heures pour installer un traitement de texte ou un navigateur ? (pas la peine de ma flammer, personnellement j'utilise gentoo, mais je pense juste que cette approche a ses limites...)

  • # autoriser l'installation sauvage de logiciels dans un répertoire prévu

    Posté par  . Évalué à 1.

    prenons /usr/local

    que les distributions se mettent d'accord et normalisent une organisation de comment y placer une nouvelle application (par exemple Firefox)


    /usr/local/firefox/share
    /usr/local/firefox/bin
    /usr/local/firefox/locale
    /usr/local/firefox/misc
    etc

    des trucs genre jboss continueront à faire /usr/local/jboss/<ce que veulent les développeurs> parce que jboss respecte la norme java enterprise et n'est pas une "application" utilisateur.

    bon

    si Firefox a besoin d'une lib jugé "exotique", c 'est à dire que les concepteurs savent que libexotique.so c'est pas fourni dans les dernières redhat, ubuntu, mandriva, debian etc, ils le fourniront au sein de leur paquet firefox (dans /usr/local/firefox/lib )

    si un développeur de firefox estime que , par exemple gtk 2.8, est devenu tellement banal et populaire (toutes les distribs depuis un bon moment l'intégrent) , il arrêtera de le fournir au sein de son propre paquet et fera confiance au système de dépendance de la distrib

    il écrira sur son site "Attention firefox 5 super-roxor nécessite Redhat 7, Ubuntu 2012.10, Mandriva Extreme 5 edition, autre distribs possible mais pas garanties" et voilà


    rien n'empeche la distrib de fournir eux même le firefox via son système de paquets

    mais il faut accepter qu'une seule solution ne permet pas de résoudre tous les problemes
    et il faut apprendre à consider Xlib, gnome, gtk, kde, qt, glib, libhal, udev etc comme UNE plateforme. si un truc est trop exotique pour l'époque, le developpeur DOIT la fournir au sein de sa super application.


    merci pour votre attention.

    • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

      Posté par  . Évalué à 2.

      "DOIT" ?

      s'il a des clients payants, il va le faire pour une raison évidente, se faire payer pour un truc qui marche

      s'il ne doit rien à personne... bienvenue dans le monde réel

      • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

        Posté par  . Évalué à 2.

        T'as aussi la version, il code un logiciel pour que personne ne l'utilise.

        • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

          Posté par  . Évalué à 3.

          Souvent, "il" code un logiciel parce qu'"il" en a besoin et "il" le met à la disposition de n'importe qui d'autre qui en aura suffisament besoin pour se démerder tout seul à l'installer. Enfin moi je dis ça ...

          • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

            Posté par  . Évalué à 5.

            J'en suis pas persuadé. Un jeu par exemple, tu le dev pas uniquement par besoin personnel, mais aussi pour qu'il soit joué par d'autres non ? Et peut être, selon le jeu, il devient intéressant si t'as un nombre d'utilisateur suffisant (jeu multijoueur en ligne, histoire que les serveurs soient pas perpétuellement vides). Des contributeurs pour des niveaux, ce genre de chose.

            Et là t'as intérêt à pas mettre trop de barrières pour rendre ton jeu intéressant à installer, sinon t'as aucune chance que ça marche. En fait, plus la destination du logiciel est un public potentiellement non technique, plus t'as besoin que ce soit simple. Si c'est des geeks, c'est pas un gros soucis.

            • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

              Posté par  . Évalué à 1.

              non. au départ tu le fais pour t'amuser toi, et précisément pour t'amuser à le coder, parce que ça te démange. (et quand tu l'auras un peu commencé il te lassera en général, bien avant d'avoir fini)

              et ensuite seulement si tu veux que tout le monde l'utilise (ou si tu vois très grand et que tu as déjà quelques expériences dans le domaine) tu vas commencer à penser aux autres. et là tu t'adaptes au milieu, à ton public. tu peux essayer d'adapter le milieu à tes vues mais c'est plus délicat : ils sont plus nombreux que toi. il faut alors de bons incitatifs, et pas juste de beaux discours et des bonnes idées (en gros parce que d'autres les ont eu avant aussi)


              vouloir viser directement les utilisateurs finaux - ou ici les parents non spécialistes les chtits nenfants - c'est souvent se tromper de cible : leur fournisseur de Linux, l'environnement dans lequel ils vont être confinés, qui va leur apporter des contraintes comme un cadre de référence, ça va être la distribution. c'est elle et les autres prescripteurs (les associations genre Framasoft, les divers annuaires de jeux ou softs pour Linux) qu'il faut conquérir, sinon - tada ! - ton travail restera inconnu, donc forcément inutilisé.

    • [^] # Re: autoriser l'installation sauvage de logiciels dans un répertoire pré

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

      >> libhal, udev

      ça existe sur tous les OS libres ou c'est du spécifique Linux ?

  • # Utilisation des applications sans 'installation'

    Posté par  . Évalué à 5.

    Est-ce que les approches comme klik (http://dot.kde.org/1126867980/) ou plus classiquement Java Web Start n'étaient pas imaginées pour simplifier l'instalation des applications pour l'utilisateur final ? Ca paraissait prometteur pour permettre justement de tester les versions dernier cri.

    Pourtant, on ne peut pas dire que le succès soit au rendez-vous. Le déploiement reste une préocupation pour les développeurs, et le recours a ce genre de solution est faible, j'ai l'impression. J'ai le sentiment de voir plus souvent des packages pour les principales distributions, et un tarball des sources pour les autres dans la section download des projets.

    La question est pourquoi ? Ce qu'il me vient à l'esprit, c'est que l'environnement proposé est trop limité, et que cela convient à faire des appliquettes, mais pas des logiciels ambitieux.

    Je serais interessé par d'autres avis.

    • [^] # Re: Utilisation des applications sans 'installation'

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

      Je connais mieux autopackage dont je vais répondre juste sur lui. Les développeurs sont très surpris pas le fait que pratiquement que des logiciels libres utilisent leur solution. C'est utilisé pour des projet simple mais aussi pour des projets concéquents comme inkscape.

      Le manque d'engouement pour ces solutions vient à mon avis d'une part qu'elle sont relativement récente et que aucune n'est parfaite.

      La seule conclusion qu'on puisse tirer est que le problème de la distribution de logiciel sur GNU/Linux est un sujet brulant et cela va aller en augmentant si l'on a, comme il faut l'espérer un afflux important de nouveaux utilisateurs grand public.

      • [^] # Re: Utilisation des applications sans 'installation'

        Posté par  . Évalué à 1.

        En plus autopackage, c'est peu connu, et ça nécessite d'installer un truc supplémentaire à télécharger sur le net. ça peut faire hésiter. Ce qui est bien c'est que ça marche sans avoir besoin des droits root.

        C'est pas très loin des bundle, en fait. Qu'est-ce qu'il manque à Linux pour qu'un truc comme les bundle de chez NextStep puissent fonctionner?
        http://en.wikipedia.org/wiki/Bundle_%28NEXTSTEP%29

        Un répertoire qui contient tout et qu'il suffit de poubelliser, c'est tout à fait compatible avec les sytème de paquets et ça permet de proposer les dernières versions d'un soft facilement.

        ça serait alors possible pour GCompris (au hasard) de faire un bundle utilisable sur toute distribution respectant la future lsb 3.2 (il faut gtk et python) et contenant sqlite, gnuchess, gnomecanvas et gnucap. ça fait un bon équilibre entre le résultat (fonctionne sur toute distribution lsb 3.2/i386) et le travail à fournir.

        il suffirait d'avoir un répertoire /bundle dans la lsb pour les mettre et un système de PATH qui aille chercher les exécutables là pour que ça puisse être accessible à tous les utilisateurs. non?

        En fait le problème actuel avec les distributions, c'est la taille et le nombre de paquets. Trop de travail, des délais importants, et du coup dans certains cas les distributions sortent avec des logiciels déjà un peu vieux. Si la distribution se met à jour tous les trois mois ça va, mais tous les trois ans...

        • [^] # Re: Utilisation des applications sans 'installation'

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

          Tous les trois mois signifierait que la distribution en passerait 8 par an pour stabiliser les différentes versions. Il existe des distributions qui sortent tous les 6 mois et c'est amplement suffisant.
          D'ailleurs, ces distributions (comme Ubuntu pour ne pas la citer) ont connu un succès immédiat auprès du public recherchant précisément une distribution dite « stable » avec des logiciels relativement et régulièrement à jour. Ubuntu dispose même de dépôts officiels de rétro-portage au cas où ce délai semblerait trop long pour proposer un nouveau logiciel à ceux qui le désirent.
          Cela convient néanmoins très bien pour les particuliers mais pas pour les professionnels (pour une fois, j'évite de diviser postes de travail et serveurs).
          Donc, les logiciels libres destinés au grand public devrait réduire leurs cibles et viser uniquement les distributions orientées grand public plutôt que vouloir imposer un système bancal à toutes les distributions. J'ai lu qu'on bridait les utilisateurs « grand public » à cause des prétendus problèmes d'installation mais là, on briderait les professionnels. Comme quoi il est difficile de contenter tout le monde.

          • [^] # Re: Utilisation des applications sans 'installation'

            Posté par  . Évalué à 1.

            les logiciels libres destinés au grand public devrait réduire leurs cibles et viser uniquement les distributions orientées grand public plutôt que vouloir imposer un système bancal à toutes les distributions.

            Entièrement d'accord. Mais ce ne sont pas les développeurs qui choisissent dans quelles distributions leurs logiciels sont inclus. Ce sont les distributions qui font leur marché parmis l'offre, en fonction de leur cible. Et la cible d'une distribution comme debian (par exemple) ne se limite pas aux professionnels, j'en suis un utilisateur satisfait depuis longtemps. Et ça nécessite de pouvoir proposer aux utilisateurs des distributions une installation hors circuit officiel de la distribution facilement.

            Je pense que les distributions devraient faire le choix de ne travailler en versionning ("stable") que sur un ensemble de logiciel réduit. Par exemple LSB + les logiciels serveurs important. Et proposer un ensemble de logiciels grand publics tournant sur cette base à date régulière. Un "debian core" tous les deux ans, avec un "debian applications" mis à jour tous les six mois, ça serait pas mal. Avec le système de build automatique de debian ça serait pas difficile à faire. Et c'est logique de penser que les applications finales ont besoin de moins de tests/stabilisation que la partie core. Il faudrait un système de backport officiel à date fixe, par exemple.

            • [^] # Re: Utilisation des applications sans 'installation'

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

              Et ça nécessite de pouvoir proposer aux utilisateurs des distributions une installation hors circuit officiel de la distribution facilement.


              Il n'y a aucun problème pour proposer un projet se basant sur Debian.
              Debian est devenue de fait une méta-distribution depuis longtemps et il est justement du rôle de distributions spécialisées de sélectionner les logiciels pertinents en fonction de l'usage qui est prévu.
              Un développeur n'aura pas les mêmes besoins qu'un administrateur système, un webmester, un infographiste ou encore un joueur.
              Hors, le projet Debian n'est pas opposé du tout aux projets s'appuyant sur sa riche logithèque : les exemples ne manquent pas.

              Ton "Debian core" et ton "Debian apps", pour ma part, ça existe déjà : c'est simplement Debian et Ubuntu. Tu parles de LSB et les logiciels serveurs importants : mais quels sont-ils ? Apache, OpenSSH ?
              Tout ce que tu proposes (dont le "Debian Core" est très proche du DCC d'Ian Murdock) est déjà proposé par Ubuntu. La compatibilité binaire reste un mythe là où la compatibilité source fonctionne.

              • [^] # Re: Utilisation des applications sans 'installation'

                Posté par  . Évalué à 2.

                Ton "Debian core" et ton "Debian apps", pour ma part, ça existe déjà : c'est simplement Debian et Ubuntu.

                Non. Ubuntu mets tout à jour tous les 6 mois, et en plus il "supporte" sa distrib au moins 18 mois. Voire 5 ans pour Dapper.

                Ce qui fait que dans 4 ans, Ubuntu continuera à supporter gcompris 7.2. Mais comme ils n'ont pas l'air de faire grand chose pour le fixer eux-même, et bien pendant 4 ans les utilisateurs de Dapper gardent les mêmes problèmes.

                Ce qui gonfle un peu les dev GCompris, comme idée.

                A moins qu'une mise à jour Dapper change la version de GCompris, mais justement non, c'est contraire à la politique. Que des patchs.

                Imagine que tous les 6 mois, les apllications utilsateurs de Dapper soient mises à jour (celles qui marchent avec le gtk/qt de dapper). Firefox, GCompris, OpenOffice, Tuxpaint backportés officiellement dans Dapper tous les 6 mois. C'est ça que je voulais dire.

                Pour Dapper/Sarge/Etch, GCompris a un gentil contributeur qui fait un dépot non officiel. Heureusement. C'est l'avantage de Debian, la grosse base de gens capable de faire ça. Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.

                Pour FC4 on a eu plein de plainte de gens qui arrivaient pas à compiler. Mais personne n'ayant de FC4 n'a fait de rpm compatible. Pour FC5 c'est dans les dépots, avec le décalage habituel entre la dernière version sortie et l'intégration.

                Et il y a 200 distributions.

                Pour un utilisateur final qui utilise pas testing/cooker, essayer un logiciel trouvé sur le net ça peut vouloir dire:
                - essayer la version déjà ancienne qui est dans sa distribution (ou dans klik). S'il y est.
                - essayer autopackage avec ses problèmes (manque machin, manque truc).
                - s'il a de la chance, mettre à jour la liste des dépots de sa distribution pour avoir la dernière version sous la bonne forme, via un dépot non officiel.
                - compiler lui même
                - rebooter sous windows et essayer l'installeur pour windows fournit par le projet.

                Et c'est quoi le plus simple? Le dernier. Et on se retrouve ridicule à défendre Linux et à vanter en même temps la dernière version du logiciel machin, qui ne sera disponible que l'année prochaine en mettant à jour sa distribution.

                En tant que développeur de logiciel, il faut bien constater que ce n'est pas complètement satisfaisant.

                • [^] # Re: Utilisation des applications sans 'installation'

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

                  Non. Ubuntu mets tout à jour tous les 6 mois, et en plus il "supporte" sa distrib au moins 18 mois. Voire 5 ans pour Dapper.

                  Ce qui fait que dans 4 ans, Ubuntu continuera à supporter gcompris 7.2. Mais comme ils n'ont pas l'air de faire grand chose pour le fixer eux-même, et bien pendant 4 ans les utilisateurs de Dapper gardent les mêmes problèmes.

                  Ce qui gonfle un peu les dev GCompris, comme idée.


                  Donc, si j'interprète correctement : ce qui "gonfle" les développeurs de GCompris, c'est de devoir supporter les anciennes versions.
                  Désolé mais dans les véritables environnements, tu auras toujours des utilisateurs qui utiliseront l'ancienne version et à qui la réponse "- faut passer à la dernière version" ne conviendra pas. GCompris est sans aucun doute un cas particulier mais votre mode de fonctionnement désiré ne peut pas s'appliquer à tous les logiciels.

                  A moins qu'une mise à jour Dapper change la version de GCompris, mais justement non, c'est contraire à la politique. Que des patchs.


                  Est-ce que cela signifierait que votre développement est incapable de corriger les bogues des versions précédentes en publiant les versions ultérieures ? Je ne crois pas. En outre, il existe tout de même des dépôts de rétro-portage, bien que non disponibles par défaut qui permettent d'avoir les dernières versions, au pire.

                  Imagine que tous les 6 mois, les apllications utilsateurs de Dapper soient mises à jour (celles qui marchent avec le gtk/qt de dapper). Firefox, GCompris, OpenOffice, Tuxpaint backportés officiellement dans Dapper tous les 6 mois. C'est ça que je voulais dire.


                  Tous les 6 mois, une nouvelle version de la distribution est publiée. Il suffit simplement pour l'utilisateur de changer de version. Après tout, il n'y a pas que GCompris dans la vie.

                  Je pense qu'il y a un problème entre votre désir de voir votre logiciel utilisé et testé par des utilisateurs. On en revient à ceci : plutôt que vous dispersez à vouloir que les 200 et quelques distributions soient toutes supportées, il n'y a guère que deux formats binaires importants (Debian et RPM), aussi il ne faut pas non plus trop attendre que quelqu'un d'autre que vous fasse un paquet binaire pour une distribution particulière (notamment FC4 : s'ils ont des problème pour le compiler, ils auront du mal à en produire des paquets).
                  Par contre, je ne comprends pas ce que tu entends par "Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.". En quoi est-ce des paquets différents ? D'ailleurs, tu as oublié de mentionner cette option : utiliser une source tierce pour disposer de la nouvelle version prévue pour SA distribution et si vous n'êtes pas en mesure pour les produire, il faut bien qu'un "gentil" contributeur s'en charge.

                  • [^] # Re: Utilisation des applications sans 'installation'

                    Posté par  . Évalué à 2.

                    Donc, si j'interprète correctement : ce qui "gonfle" les développeurs de GCompris, c'est de devoir supporter les anciennes versions.
                    Non. C'est de ne pas pouvoir le faire. Si on était une douzaine...
                    Et que ce ne soit pas fait correctement par les distributions. Comme ils ne remontent pas les bugs (ou rarement) on a l'impression de faire un logiciel parfait. Sans compter que j'ai du un jour engueuler le developpeur ubuntu pour que ça ne soit pas une version cvs dans dapper. S'il nous en avait parlé on aurait pu l'aider. Je m'en suis rendu compte par hasard.

                    Est-ce que cela signifierait que votre développement est incapable de corriger les bogues des versions précédentes en publiant les versions ultérieures ? Je ne crois pas.
                    C'est du temps, des gens. Toujours le même problème.

                    Tous les 6 mois, une nouvelle version de la distribution est publiée. Il suffit simplement pour l'utilisateur de changer de version. Après tout, il n'y a pas que GCompris dans la vie.
                    Alors il ne faut pas faire un support sur plus de 6 mois. Il faut que la mise à jour soit automatique comme pour les MàJ de sécurité.

                    Plus sérieusement, tu as un raisonnement franchement binaire: on change tout, ou on change rien.

                    Un peu de granularité, je trouve que ça serait bien. Par exemple changer juste les logiciels qui fournissent un .desktop (et qui restent compatible) tous les 6 mois, et ne changer la base que tous les deux ans, ça me conviendrait très bien.

                    Firefox/Openoffice/gcompris/inkscape pourraient surement tourner sur sarge dans leur dernière version. C'est FF 1.04; OOo 1..1.3, gcompris 6.5.2 et inkscape 0.41 qui sont dans sarge. Je n'ai pas besoin des nouvelles fonctionnalité de sarge le nouvel installeur m'indiffère, le gtk de sarge me convient, son gnome me va aussi. Ce sont les applications sur le bureau dont j'ai le plus besoin qu'elle soient à peu près à jour.
                    Mais c'est tout ou rien. Je suis donc en etch avec les inconvénients qui vont avec.

                    Et le nombre de projets pour pallier à ça (Murdoch, autopackage, klik, 0install) montre quand même que c'est un problème loin d'être anodin.

                    Par contre, je ne comprends pas ce que tu entends par "Mais attention, c'est à chaque fois des paquets différents. sarge, etch dapper, etch, breezy... et c'est un logiciel connu.". En quoi est-ce des paquets différents ?
                    ce sont les mêmes compilés sur chacune de ces distributions? Je ne sais pas moi, je ne suis pas DD. C'est là-bas. http://thomas.enix.org/DebianRepository

                    l n'y a guère que deux formats binaires importants (Debian et RPM),
                    Oui mais le rpm mandrale fournit par gcompris ne marche pas sur fedora, ni suse. Je ne sais pas pourquoi... Pour moi le rpm c'est du chinois. Il y a belle heurette que j'ai viré ma redhat 4.0 pour mettre une debian à la place. Dans la pratique chaque distribution a besoin de ses propres paquets (suse, mandrake, fedora, debian, ubuntu) à l'exception des sous-distrib (knoppix et dérivées qui utilisent ceux de debian).

                    tu as oublié de mentionner cette option : utiliser une source tierce
                    Non c'est ce que je voulais dire avec
                    - s'il a de la chance, mettre à jour la liste des dépots de sa distribution pour avoir la dernière version sous la bonne forme, via un dépot non officiel.

                    • [^] # Re: Utilisation des applications sans 'installation'

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

                      Non. C'est de ne pas pouvoir le faire. Si on était une douzaine...
                      Et que ce ne soit pas fait correctement par les distributions. Comme ils ne remontent pas les bugs (ou rarement) on a l'impression de faire un logiciel parfait. Sans compter que j'ai du un jour engueuler le developpeur ubuntu pour que ça ne soit pas une version cvs dans dapper. S'il nous en avait parlé on aurait pu l'aider. Je m'en suis rendu compte par hasard.


                      Tu rapportes là un problème de communication entre responsables et développeurs. Ce genre peut arriver, c'est humain après tout.
                      Je commence à mieux comprendre d'où vient cette rancoeur.

                      Alors il ne faut pas faire un support sur plus de 6 mois. Il faut que la mise à jour soit automatique comme pour les MàJ de sécurité.


                      Le support est nécessaire parce que les utilisateurs le demandent. Tout le monde n'a pas non plus envie de changer de versions tous les 6 mois ni tous les ans. Il n'y a pas que les particuliers pour utiliser Linux. Les mises à jour de sécurité sont différentes des mises à jour fonctionnelles. Quand on publie une version stable, on assure à l'utilisateur d'avoir réalisé des tests préliminaires pendant une période assez longue pour éviter les problèmes évidents. Les mises à jour de sécurité n'ont pas pour vocation de monter en version un logiciel mais uniquement de corriger le code responsable de la faille à l'aide d'un patch. Ce n'est pas un mode de fonctionnement cantonné aux Logiciels Libres.

                      Plus sérieusement, tu as un raisonnement franchement binaire: on change tout, ou on change rien.


                      Ce raisonnement binaire vient du système de bibliothèques dynamique, pas de moi. Comment veux-tu mettre à jour GTK+ et assurer la stabilité de la distribution et des applications qui en dépendent si tu n'y prêtes pas attention ? Je dirais plutôt que vous (les développeurs de GCompris) avaient une vision plutôt réduite des problèmes de cohabitation des logiciels sur un système. Une vision propre aux développeurs, centralisée sur leur projet à eux.

                      Un peu de granularité, je trouve que ça serait bien. Par exemple changer juste les logiciels qui fournissent un .desktop (et qui restent compatible) tous les 6 mois, et ne changer la base que tous les deux ans, ça me conviendrait très bien.


                      Oui mais au risque de me répéter, que fais-tu des dépendances des "logiciels fournissant des .desktop" ? Que fais-tu des logiciels tiers ayant implémenté la toute nouvelle fonctionnalité de la dernière version de GTK+ ? Il ne pourra pas le faire si GTK+ reste cantonner à la version de la distribution. La prétendue compatibilité binaire vantée par Murdock sera une atteinte à la l'innovation logicielle.

                      Firefox/Openoffice/gcompris/inkscape pourraient surement tourner sur sarge dans leur dernière version. C'est FF 1.04; OOo 1..1.3, gcompris 6.5.2 et inkscape 0.41 qui sont dans sarge. Je n'ai pas besoin des nouvelles fonctionnalité de sarge le nouvel installeur m'indiffère, le gtk de sarge me convient, son gnome me va aussi. Ce sont les applications sur le bureau dont j'ai le plus besoin qu'elle soient à peu près à jour.
                      Mais c'est tout ou rien. Je suis donc en etch avec les inconvénients qui vont avec.


                      Le problème, c'est que le GTK+ de sarge ne conviendrait certainement pas pour les dernières versions des logiciels que tu as mentionné. Donc, si c'est pour fournir les bibliothèques en sus, soit tu compiles en statiques, soit tu fais du cygwin pour Linux et tu crées donc une distribution par dessus la distribution. De là à créer une nouvelle distribution, il n'y a plus qu'un pas...
                      Pour continuer dans ton raisonnement, si tu n'as pas besoin des dernières fonctionnalités : tu n'as pas besoin des dernières versions.
                      Le problème ne se pose donc pas.

                      Et le nombre de projets pour pallier à ça (Murdoch, autopackage, klik, 0install) montre quand même que c'est un problème loin d'être anodin.


                      Des projets de logiciels libres, il en existe des milliers. La quantité de projets n'est pas forcément synonyme de grands besoins mais surtout d'un manque total de cohésions entre les divers projets.

                      • [^] # Re: Utilisation des applications sans 'installation'

                        Posté par  . Évalué à 2.

                        Le problème, c'est que le GTK+ de sarge ne conviendrait certainement pas pour les dernières versions des logiciels que tu as mentionné
                        Tous je ne sais pas. Mais les différences d'API entre gtk 2.6 (si c'est bien le 2.6 qui est dans sarge) et les suivantes sont assez faibles pour que ça puisse marcher dans la plupart des cas. On ne réécrit pas les soft à chaque nouvelle gtk. Le gros changement ensuite, c'est l'utilisation de cairo, mais c'est transparent si on n'utilise que gtk.

                        En particulier gtk 2.6 est le dernier à tourner sur win 9x. Donc si on veut garder cette compatibilité, on se limite à ça. GCompris compile très bien sur gtk 2.6, et sur tous les suivants. Quand on a sorti la première version qui demandait la 2.6 (une erreur de ma part), on a eu des récriminations. Tous le monde ne met pas à jour à chaque sortie de nouvelles versions, on en tient compte. Je pense que les autres projets doivent aussi faire de même. ça m'étonnerait que beaucoup de nouveaux softs sortis depuis soient incompatible avec sarge.

                • [^] # Re: Utilisation des applications sans 'installation'

                  Posté par  . Évalué à 2.

                  En tant que développeur de logiciel, il faut bien constater que ce n'est pas complètement satisfaisant.

                  et en tant que packageur de logiciels pour une distribution ou pour un parc informatique, tu n'aimerais pas pouvoir dire aux développeurs d'arreter de rajouter des nouveaux trucs dans leur super logiciel et de corriger pour de bon tous les bugs signalés, tout en restant sur les mêmes librairies que la version qu'ils t'ont livrée et que tu as déjà déployée ? ou au moins la prochaine que tu déploieras plus tard mais que tu as déjà choisie, modulo les bugs et correctifs de sécurité ?

                  et ben non, ça préfère ajouter des fehatchiures en même que corriger quelques bugs et utiliser de nouvelles versions des librairies que toi tu ne te peux changer tout de suite, ça bosse dans son coin, et ça vient pleurer ensuite que chez toi ça ne marche pas ou que tu es "en retard" alors que ton cycle de déployement est volontairement plus long parce que toi tu ne t'occupes pas d'un logiciel mais de 150 et que leur super logiciel il est bien gentil bien mignon mais niveau importance et criticité il est plutot 150ème que premier sur la liste.

                  de toute façon les distributions dites "stable" sont faites pour livrer des logiciels en version finale à des utilisateurs finaux.

                  je ne vois pas pourquoi monsieur Tout Le Monde devrait utiliser des versions en cours de développement. et si vous sortez vraiment des versions finales majeures tous les 15 jours, vous avez peut-être un problème de votre côté. ne pleurez pas que vous n'êtes pas dans les distributions si vous refusez de vous associer à leur cycle de distribution et comprendre leurs contraintes : voir ses créations être distribuées par d'autres personnes n'est absolument pas un droit divin.

                  pour des personnes qui doivent gérer l'installation de plus d'un soft, il faut bien constater que les développeurs en indépendant qui revendiquent une totale autonomie posent plus de problèmes qu'ils n'en résolvent par leur contribution de leur soft, surtout s'il est vraiment mineur : ce n'est pas complètement satisfaisant pour eux non plus.

                  • [^] # Re: Utilisation des applications sans 'installation'

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

                    Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.

                    Je trouve domage que tu tapes de la sorte sur les développeurs sans comprendre aussi leur difficulté. Il sont dans l'incapacité de cibler une version spécifique de librairie car personne ne défini une référence commune. Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux. Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.

                    La seule est unique solution pour avoir des logiciels stable sur une plate-forme stable c'est de ne pas tout mélanger comme nous le faisons actuellement. Il nous faut un coeur de librairies les plus courantes, bien définies et que les projets peuvent cibler. En dehors de cela, il faut que chaque projet livre ses librairies car il est sûr que son projet marche avec. Certe c'est pas optimisé et on ne va pas faire ça pour tous les logiciels mais ça doit être une option possible et simple à faire, à la fois pour les développeurs mais aussi pour les utilisateurs. Bien sûr on a besoin d'un bonne intégration dans la distro.

                    • [^] # Re: Utilisation des applications sans 'installation'

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

                      Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.


                      En quoi est-ce un problème ? Les cycles de publications des versions stables des bibliothèques sont plutôt longs, surtout pour les versions mineures et majeures : pour les versions de patchs, je ne pense pas que tu ai besoin d'être aussi à jour (et ton co-développeur l'a déjà dit, sauf erreur). En outre, les développeurs de bibliothèques maintennent généralement la version précédente même après que la nouvelle branche ait débuté, tout comme Linux.

                      Je trouve domage que tu tapes de la sorte sur les développeurs sans comprendre aussi leur difficulté. Il sont dans l'incapacité de cibler une version spécifique de librairie car personne ne défini une référence commune.

                      Les développeurs n'ont pas besoin d'une référence commune, ils ont simplement besoin d'ABI et API qui correspondent à leurs besoins de programmation. S'ils ne savent plus à quelles bibliothèques se vouer, c'est qu'ils ont mal défini leurs besoins.

                      Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux. Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.

                      Non, c'est faux. La plate-forme de développement de tout développeur, à moins qu'il ne soit parti d'une base de LFS, est fatalement une des nombreuses distributions qui existent déjà.
                      En outre, à moins qu'il ne se contruise un environnement protégé ("chroot", "jail", ce qu'il veut) pour faire son développement, il devra forcément composer avec les bibliothèques fournies par la distribution ou les compiler lui-même (ce qui rentre un peu dans le cas de l'environnement "protégé"). Et si son application a besoin d'une bibliothèque qui n'est pas encore disponible dans la distribution, il appartiendra aux responsables de paquets volontaires de faire le nécessaire pour combler le manque. Or : si ton application est bien censée fonctionner avec la version Y de bilbliothèque X, je ne vois pas pourquoi ils ne parviendraient pas à créer le paquet binaire eux-mêmes.
                      J'ai de plus en plus la nette impression que tu ne veux/peux pas nous dire quel est ton véritable problème et but dans cette histoire, comme si tu avais des clients un peu exigeants.

                      Es tu capable de me dire quelle est la 'bonne' version de SDL_Mixer à utiliser en ce moment, tu n'en sais rien et moi non plus. Enfin, si je sais que c'est pas la 1.2.7 qui est packagé dans la plupart des distros car elle fait planter GCompris.

                      Si ton logiciel plante avec une version particulière de la distribution, ce n'est pas la faute du mode actuel de distribution des logiciels libres mais plutôt entre GCompris et SDL. Sous Debian sid, c'est encore la 1.2.6 : tu devrais peut-être te demander pourquoi la 1.2.7 n'y est pas encore...

                      La seule est unique solution pour avoir des logiciels stable sur une plate-forme stable c'est de ne pas tout mélanger comme nous le faisons actuellement. Il nous faut un coeur de librairies les plus courantes, bien définies et que les projets peuvent cibler. En dehors de cela, il faut que chaque projet livre ses librairies car il est sûr que son projet marche avec. Certe c'est pas optimisé et on ne va pas faire ça pour tous les logiciels mais ça doit être une option possible et simple à faire, à la fois pour les développeurs mais aussi pour les utilisateurs. Bien sûr on a besoin d'un bonne intégration dans la distro.

                      Il y a un détail qui me choque dans ce paragraphe : à quoi servira-t-il d'avoir des distributions si la base LSB suffit amplement aux développeurs ? Et qu'adviendra-t-il le jour où les développeurs auront besoin d'une version à jour de la bibliothèque X parce qu'elle implément la toute nouvelle fonctionnalité Y ? Crois-tu qu'ils feront en sorte que la base LSB soit mise à jour ? On peut en douter et combien même serait-ce le cas, il est bien possible que la base LSB refuse de mettre à jour la dite bibliothèque pour des raisons de stabilité de la dite base qui sert de référence : chose que tu demandes aussi...
                      Je souhaite bien du plaisir à Ian Murdock.

                    • [^] # Re: Utilisation des applications sans 'installation'

                      Posté par  . Évalué à 0.

                      > Tu pointes du doigt un problème important, celui de la multiplication des version des librairies.

                      scoop : la même librairie avec le même numéro de version dans deux distributions ne sera en fait pas la même. parce que l'une aura mis le support du Zorglub et l'autre non. mais bref.

                      > Je trouve domage que tu tapes de la sorte sur les développeurs sans comprendre aussi leur difficulté. Il sont dans l'incapacité de cibler une version spécifique de librairie car personne ne défini une référence commune.

                      "sans comprendre leurs difficultés", vraiment ? j'ai fait le tour des rôles, là, tu vois, codeur packageur utilisateur documentation et assurer le support de personnes qui ne lisaient même pas le readme.txt qui était dans l'archive livrée et recopiée sur la page de téléchargement. pour du libre comme du commercial. depuis plus de 10 ans. ou 15.

                      à la bonne vieille époque il n'y avait pas de GNU/Linux mais une vingtaine d'Unix POSIX et on va dire que bien peu ont survécu. pour tenter d'installer des trucs comme unzip il fallait en général taper make lenomdelOS. et définir à la main quel compilateur on allait utiliser, parce que gcc était par endroit une vraie rareté.

                      > Je te rappelle que notre plate-forme de développement n'est pas une distro particulière mais GNU/Linux.

                      chaque fois que tu diras ça, fous-toi un bon coup de marteau sur les burnes. ça te passera vite.

                      la plateforme GNU/Linux n'existe pas plus que la plateforme Unix ou la plateforme POSIX. c'est une chimère. et tu oublies les gens sous processeurs G3, G4, G5 et les gens sur des mobiles avec des processeurs ARM ou autres.

                      tu auras beau sortir cette expression de "GNU/Linux" tous les matins en te rasant, ça ne changera rien au fait que tes utilisateurs "sous GNU/Linux" sont en fait "sous Linux Mandriva 2006.1 x86 32 bits" ou un autre truc souvent aussi long. et je ne parle pas des petits monstres sans version fixe comme Debian sid, Mandriva Cooker et autres Gentoo à jour. la preuve, toi même tu utilises SDL. donc c'est "GNU/Linux/SDL" et compagnie ta plateforme, au bas mot. sauf qu'elle est unique à chez toi ou tes quelques compères développeurs.

                      et pour tes problèmes de SDL_Mixer j'ai presque l'impression que tu découvres la vie. une mise à jour d'une librairie, une version trop différente pour pouvoir comparer facilement, et boum, ton logiciel plante, et tu ne sais pas pourquoi. tu remarqueras que quand ton logiciel fait des trucs bien plus importants et critiques pour tes clients tu peux mystérieusement commencer à imposer un environnement strict, précis et qui ne bougera plus - en y conditionnant le support, par exemple.

                      il y a 10 ans pratiquement chaque application Windows était livré avec sa version de mfc40.dll (et quelques autres). parce que en résumé la leur ils étaient sûrs qu'elle marchait sur leur machine de test et ils ne pouvaient pas prévoir laquelle aurait le client. normalement ils l'installaient dans le répertoire de leur application et ça allait à peu près, elle était prioritaire. sauf les 5 % de crétins qui l'installaient dans c:\windows et là, boum ! les ennuis commençaient. depuis, cette blague est connue, mais on a eu droit à d'autres depuis.

                      croire que c'est parce que tu as un Installshield (ou un clone) qui te fabrique un joli .exe avec tous les fichiers qui font que ça marche chez toi que ça va marcher tout seul chez les autres, c'est de la fumette. j'en connais qui utilisent en dur "c:\windows" pour indiquer le répertoire de Windows, c'est dire...

                      même avec une ribambelle de bibliothèques rajoutées à la LSB, tu ne seras pas à l'abri de problèmes de portabilité que tu ne découvriras que chez tes utilisateurs. ça a été exactement pareil pour Java, bien qu'il était censé être portable tout ça tout ça. oh, il fallait juste se battre avec les / et les \, entre autres...

    • [^] # Re: Utilisation des applications sans 'installation'

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

      mouais le "sans installation" ;-)
      je ne sais pas pourquoi ça me rappelle Oracle Application (un ERP ou PGI en français) dont la fameuse applet java faisait de l'ordre de 20 Mo (ou 80 Mo, j'ai un petit doute d'un coup...).
      Bon eh bien, quand tu as un parc de plus de 100 utilisateurs (même un peu plus généralement pour ce genre d'appli), tu n'as pas trop envie d'écrouler ton réseau en journée, donc tu fais quand même la gestion du déploiement (malgré cette vague promesse du "sans installation"...).
      Mieux vaut avoir un système maîtrisé, qui gère le retour arrière, gère les ressources, gère la configuration, ... que des "solutions de développeur" à la "yaka qu'à recompiler, yarien à installer ça se fait tout seul" qui ne gèrent pas la complexité d'une prod' réelle (mais qui effectivement marchent très bien en dév', avec un seul poste à déployer, en LAN en plus, toussa...).

      • [^] # Re: Utilisation des applications sans 'installation'

        Posté par  . Évalué à 2.

        Je ne suis pas pour un "sans installation" seul. Un système de paquet comme actuellement, doublé d'un fonctionnement en bundle pour permettre aux développeurs de proposer les dernières versions aux gens pressés et les RC aux testeurs, ça me semblerait bien.

        • [^] # Re: Utilisation des applications sans 'installation'

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

          C'est klik que tu decris.

          Je suis surpris de ne le voir mentionne nulle part, alors que ca repond exactement a la problematique evoquee, et ce avec succes, depuis plusieurs mois.

          • [^] # Re: Utilisation des applications sans 'installation'

            Posté par  . Évalué à 2.

            Mince je pensais justement en avoir parlé dans mon commentaire...
            Je profite de cette réponse pour redonner le lien vers klik, qui est mangé par la parenthèse fermante plus haut.
            http://dot.kde.org/1126867980/

          • [^] # Re: Utilisation des applications sans 'installation'

            Posté par  . Évalué à 4.

            Non. La preuve étant que le dernier klik proposé dans la liste pour gcompris est assez vieux. Et que firefox ne sait vraiment pas quoi faire avec une URL de type klik://drgeo. Pas assez universel. Il faudrait pouvoir charger un .zip, le dézipper, cliquer sur le résultat et ça roule. Au moins je peux télécharger le .package d'un autopackage et le lancer (c'est un script shell).

            Mais on trouve dans le wiki un tableau comparatif plus qu'intéressant:
            http://klik.atekon.de/wiki/index.php/Comparison

            Avec quelques projets intéresants:
            OBLISK: http://oblisk.codu.org/
            OBLISK packages are sent in an appdir-like package, so they can be ran entirely in place, but also have an installer, so they can be installed to /usr, or any other path.


            J'y découvre aussi que Rox qui a un système de bundle: AppDir. http://rox.sourceforge.net/phpwiki/index.php/Tutorials/Start qui semblerait convenir parfaitement. Pourquoi n'est-ce pas standardisé par freedesktop etr intégré à Gnome et Kde ?

            • [^] # Re: Utilisation des applications sans 'installation'

              Posté par  . Évalué à 2.

              J'y découvre aussi que Rox qui a un système de bundle: AppDir. http://rox.sourceforge.net/phpwiki/index.php/Tutorials/Start qui semblerait convenir parfaitement. Pourquoi n'est-ce pas standardisé par freedesktop etr intégré à Gnome et Kde ?


              Sur le site de comparaison filé plus haut ( http://klik.atekon.de/wiki/index.php/Comparison ), klik est compatible avec appdir :

              AppDir compliant (ROX specs)

              The software is contained in AppDirs that follow the open ROX specification. (Unpacking might be neccessary.)

              Perso c'est le système qui me séduit le plus actuellement.

              En mattant le site un peu plus, il est à prioris possible de telecharger un fichier cmg pour faire l'install (bon par contre c'est vrai que sur le site de klik je ne les ai pas trouvé), de plus, selon les forums, mozo gère très bien les urls en klik:// une fois klik installé

              • [^] # Re: Utilisation des applications sans 'installation'

                Posté par  . Évalué à 2.

                Oui mais non. à comparer avec autopackage:

                - klik a son propre site sur lequel les paquets sont mis à disposition. Alors peut-être qu'un projet peut proposer en téléchargement son propre fichier au format klik, mais ça n'a rien d'évident à priori. Ce qui en pratique en fait une sorte de distribution par dessus la distribution, dans lequel les développeurs continue à dépendre d'un système externe. Pour GCompris par exemple, la version du site klik est carrément vieille. Le wiki de klik parle de "upstream developpers", c'est le même vocabulaire que debian.

                - autopackage les paquets sont mis à dispo par le projet. Pour gcompris la version dispo est la dernière (c'est le gcompris team (i.e. Bruno) qui le fait). Mais la gestion des dépendances est... quasi-absente (je suppose que klik le fait).

                Pour moi autopackage n'est pas encore assez proche du bundle. En fait il installe dans une arborescence propre. Il y a une phase d'installation.

                Evidemment l'inconvénient de la mise à dispo de binaires en bundle/autopackage par les projets, c'est l'intégration de toute les dépendances non standard (mettons hors LSB 3.2). Mais l'avantage c'est de pouvoir proposer un binaire à jour. Et c'est tout sauf incompatible avec apt/yum/urpmi, puisque ça n'y touche pas.

                • [^] # Re: Utilisation des applications sans 'installation'

                  Posté par  . Évalué à 1.

                  Pis en fait, après recherche, le fichier cmg est une image cramfs qu'il faut monter en loopback... donc en effet cest pas le top...

                  bon j'aime quand meme bien le système, et l'idée de pas avoir à copier directement un fichier sur le dur, par contre le coté "centralisé" le rend pas très valable.

                  jessaierai surement ce we

                • [^] # Re: Utilisation des applications sans 'installation'

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

                  Je suis désolé mais installer un logiciel dont les dépendances en matière de bubliothèques peuvent à un moment ou à un autre interférer avec celles du système (ou vice-versa), c'est plus dangereux et vicieux que l'éventualité de toucher aux systèmes de paquets.
                  Il ne faut pas oublier que les systèmes dynamiques que sont les distributions sont des systèmes vivants et non pas statiques.
                  Il faudra donc que les tiers se contentent de fournir des binaires statiques ou rien. Il n'y a pas de solutions simples à ce faux-problème.

                  • [^] # Re: Utilisation des applications sans 'installation'

                    Posté par  . Évalué à 2.

                    Explique moi un peu plus le problème, ça m'intéresse.

                    Prenons un exemple:
                    http://fynl.free.fr/vrac/bundle/lbreakout.zip

                    C'est un programme (LBreakout) fournit dans Rox avec le système 0install. J'ai utilisé Zero2Bundle pour en faire un AppDir à la mode Rox. Il contient SDL, et normalement le lanceur (AppRun) Place LD_LIBRARY_PATH pour que ce soit le SDL fournit dans le bundle qui soit utilisé.

                    Sous Rox-Filer c'est vu comme une appli on clique et ça roule. Sous gnome il faut lancer le 'AppRun' qui est dedans. sous Kde je ne sais pas.

                    On est d'accord, un apt-get install lbreakout qui installe automatiquement sdl, c'est mieux, ça évite d'avoir 36 fois SDL sur la machine. Et ça permet de l'avoir en ppc/ia64/hurdx86/hurdppc/... automatiquement.

                    Mais pour aux utilisateurs de tester la dernière version sans attendre, ou une version RC, ça me semble intéressant, ou pour le tester lorsqu'il n'est pas inclus dans la distribution. Où est le problème avec le SDL inclus dans le bundle?

                    • [^] # Re: Utilisation des applications sans 'installation'

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

                      Les problèmes de mise à jour de sécurité ou de mise à jour tout court (bugfix notamment). Au départ, les bibliothèques dynamiques ont été mises en place pour gagner de la place. Elles ont été conserver pour faciliter les mises à jour des différentes parties qui compose un système.
                      Je me demande si le "problème" n'est pas uniquement lié aux jeux libres. J'ai l'impression que les développeurs de ces jeux attaquent le mode de distribution actuel uniquement parce que leurs jeux ne sont pas assez populaires au lieu de chercher s'il n'y aurait pas une autre raison. Quand on voit la diversité qu'il existe au niveau des jeux avec chacun sa propre API 3D ou peu s'en faut, il vaudrait mieux se pencher sur cette question avant de demander aux autres de mettre un peu d'ordre dans la cathédrale.
                      Tu veux que des tests soient réalisés ? Commence déjà par mettre en place des tests de régressions (autre sujet de discussion à propos des logiciels libres) et réunis autour de toi des utilisateurs relativement compétents et qui sont prêts à tester le logiciel. Mais il n'y a pas guère de solutions miracle et je refuse que ce soit les enfants de 3 à 10 ans (pour GCompris) qui en soient pour leur frais.

                      • [^] # Re: Utilisation des applications sans 'installation'

                        Posté par  . Évalué à 2.

                        Les problèmes de mise à jour de sécurité
                        Vrai. Et vrai pour Windows/OSX aussi puisqu'on est dans ce cas là. En même temps, cette lib n'étant utilisée que par le bundle, ça impacte peu. Sauf si on fait firefox qui a d'ailleurs mis en place sa propre mise à jour de sécurité. Et c'est toujours un risque pour l'utilisateur d'installer un binaire qui vient du net. utiliser des binaires hors distribution pose ce problème-là, quelle que soit la source.

                        Mais le reste de la distribution n'est pas mis en danger, au sens ou un bug dans une libpng fournie avec une bundle firefox 5 ne mettrait pas en danger le firefox 3 de la distribution ?

                        Je me demande si le "problème" n'est pas uniquement lié aux jeux libres.
                        Je ne pense pas, non. Pas seulement en tout cas. inkscape propose un autopackage. Oinstall vient du côté de chez rox. klik semble venir de kde, à mois que le k ne m'induise en erreur. Ce sont des solutions qui répondent à cette problèmatique. Sans venir des jeux.

                        J'ai l'impression que les développeurs de ces jeux attaquent le mode de distribution actuel uniquement parce que leurs jeux ne sont pas assez populaires au lieu de chercher s'il n'y aurait pas une autre raison. Quand on voit la diversité qu'il existe au niveau des jeux avec chacun sa propre API 3D ou peu s'en faut, il vaudrait mieux se pencher sur cette question avant de demander aux autres de mettre un peu d'ordre dans la cathédrale.
                        eu... ils utilisent pas tous OpenGL, les jeux 3D libres? Bon j'avoue, j'y connais rien. Ma nvidia/ppc ne fait pas la 3D, je connais assez peu ce domaine.

                        Non, le besoin est plus précis. Quand Pysycache a été anoncé ici, j'ai voulu le tester sous linux. La v2 marchait directement en dézippant et en lançant le fichier python. Dézippé et click. Et pouvoir l'utiliser sans attendre que debian l'intègre (ou que quelqu'un propose des deb, comme c'est le cas maintenant).

                        • [^] # Re: Utilisation des applications sans 'installation'

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

                          Mais le reste de la distribution n'est pas mis en danger, au sens ou un bug dans une libpng fournie avec une bundle firefox 5 ne mettrait pas en danger le firefox 3 de la distribution ?

                          Une faille de sécurité, quellequ'elle soit, mettra en danger l'intégrité de tout le système. Il est illusoire de croire que, parce qu'on a "cantonné" (parce que ce n'est même un chroot) l'application avec une ou deux variables d'environnement pour éviter les conflits entre versions concurrentes.

                          Je me demande si le "problème" n'est pas uniquement lié aux jeux libres.
                          Je ne pense pas, non. Pas seulement en tout cas. inkscape propose un autopackage. Oinstall vient du côté de chez rox. klik semble venir de kde, à mois que le k ne m'induise en erreur. Ce sont des solutions qui répondent à cette problèmatique. Sans venir des jeux.

                          Inkscape est le seul contre-exemple. La plupart des logiciels cités ici sont des jeux.
                          Quant à Klik, le K porte effectivement à confusion : ce projet n'a rien à voir avec le projet KDE. Quand on voit les logiciels présentés sur le page de garde du projet Klik, on peut se demander s'il ne s'agit pas là, en fait, un moyen pour que les éditeurs commerciaux puissent avoir leurs logiciels propriétaires (Opera, Skype, RealOnePlayer) installés sous Linux. Quant aux projets Google, pourquoi ne sont-ils pas encore packagés dans les distributions majeures s'ils sont "free" (comme Picaza) ? Sans doute parce la licence l'interdit (le logiciel est donc moins libres). Ou est-ce parce que la demande est devenue moindre parce que les utilisateurs peuvent l'installer sans "efforts" ?
                          Bientôt, si on continue dans cette voie, il n'y aura plus besoin de migrer de Windows à Linux parce que ce sera la même pagaille.

                          J'ai l'impression que les développeurs de ces jeux attaquent le mode de distribution actuel uniquement parce que leurs jeux ne sont pas assez populaires au lieu de chercher s'il n'y aurait pas une autre raison. Quand on voit la diversité qu'il existe au niveau des jeux avec chacun sa propre API 3D ou peu s'en faut, il vaudrait mieux se pencher sur cette question avant de demander aux autres de mettre un peu d'ordre dans la cathédrale.
                          eu... ils utilisent pas tous OpenGL, les jeux 3D libres? Bon j'avoue, j'y connais rien. Ma nvidia/ppc ne fait pas la 3D, je connais assez peu ce domaine.

                          Les jeux n'utilisent pas que la 3D et si c'est le cas, il ne faudrait pas non plus que ça dépende de nvidia (les problèmes pour avoir un support 3D correct sous Linux sont davantage la cause des problèmes de "démocratisation" de Linux que le mode de distribution des logiciels au sein des distributions) ou d'ati.

                          Non, le besoin est plus précis. Quand Pysycache a été anoncé ici, j'ai voulu le tester sous linux. La v2 marchait directement en dézippant et en lançant le fichier python. Dézippé et click. Et pouvoir l'utiliser sans attendre que debian l'intègre (ou que quelqu'un propose des deb, comme c'est le cas maintenant).

                          Et quelle version de Psysycache (encore un jeu) utilises-tu actuellement ?

                          • [^] # Re: Utilisation des applications sans 'installation'

                            Posté par  . Évalué à 2.

                            Pour pysycache, c'est toujours la v2 à l'école de mes filles. Je ne leur change pas en cours d'année scolaire et c'est les PS qui l'utilisent, ils n'ont pas besoin de la v3.

                            Mais la v3 a un script à lancer comme root pour l'installer, elle ne marche pas sans ça. Ou un deb sur le site d'ofset qui plante sur ubuntu (c'est ubuntu à l'école en question).

                            • [^] # Re: Utilisation des applications sans 'installation'

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

                              Si la v3 a besoin de droit root, c'est que son installation requiert davantage d'implications avec la distribution cible. Ubuntu ne va pas changer ses méthodes pour une seule application : c'est aux utilisateurs d'Ubuntu (au sens large : je pense surtout à ceux qui "l'administrent" au sein de l'école) de faire le nécessaire pour que ça fonctionne malgré tout, quitte à précéder l'exécution du script par la commande sudo. S'ils n'ont pas connaissance de ce mode de fonctionnement particulier, c'est qu'ils ont un problème.

                              En ce qui concerne les paquets prévus pour Debian, il n'a jamais été dit que l'installation de tels paquets sur une Ubuntu était conseillé mais qu'au contraire, cela pouvait PARFOIS fonctionner mais en aucun cas être généralisable. Il devrait néanmoins être facile de reconstruire les sources du paquet pour Ubuntu, notamment grâce à pbuilder[1]. Peux-tu me dire quel est le problème exact avec le paquet d'ofset ?

                              Pour finir, je suis ravi de voir qu'Ubuntu a été choisi pour leur école mais je me demande pourquoi ils n'ont pas pris plutôt Edubuntu, vu l'usage qu'il en est fait (par ignorance ?).

                              [1]: http://doc.ubuntu-fr.org/applications/pbuilder

                              • [^] # Re: Utilisation des applications sans 'installation'

                                Posté par  . Évalué à 2.

                                Le choix c'est moi qui l'ai fait. Non C'est bien edubuntu, j'ai dis ubuntu par un raccourci pratique.

                                C'est ubuntu-fr qui conseille d'ajouter les depots debian pour pysycache:
                                http://doc.ubuntu-fr.org/pysycache

                                Mais l'auteur sait que ce n'est pas la bonne solution.
                                http://forum.ubuntu-fr.org/viewtopic.php?pid=493163

                                Paramétrage de pysycache (3.0-1) ...
                                dpkg : erreur de traitement de pysycache (--configure) :
                                le sous-processus post-installation script a retourné une erreur de sortie d'état 2
                                Des erreurs ont été rencontrées pendant l'exécution :
                                pysycache
                                E: Sub-process /usr/bin/dpkg returned an error code (1)

                                J'ai juste signalé qu'il ne pâssait pas pour montrer à quel point ça pouvait être difficile pour un auteur de logiciel de proposer une solution d'installation à ses utilisateurs.
                                Utilisateur qui va donc se retrouver à faire un "sh install.sh" en root, pas top au niveau sécurité, pas top au niveau intégration dans une distribution. Pourtant c'est juste un programme en python au départ, pas le plus compliqué à installer non plus.

                                j'ai déjà vu des softs mettre des choses dans /usr et d'autres dans /usr/local, par exemple csound5 le dernier testé à me faire des trucs bizarre au sudo make install. Pas top au niveau intégration dans une distribution.

                          • [^] # Re: Utilisation des applications sans 'installation'

                            Posté par  . Évalué à 2.

                            Tu as raison sur la sécurité, et c'est de toute façon un problème général dès qu'on installe un soft hors distribution: On n'a pas de mises à jours automatiques ni les alertes.

                            On se retrouve donc coincés entre la solution distrbution seule et ses rafistolages (backports), et la prise de risque. sudo make install c'est aussi un risque. dpkg -i sur un deb venu d'on ne sait où, c'est aussi un risque.

                            Et si debian a mis en place backports.org, si ubuntu a eu tant de succès, si quasiment tous les projets libres fournissent des binaires, c'est bien pour répondre à un besoin. Et ce besoin, je trouve que tu en sous-estimes l'importance.
                            Si tous les projets libres, y compris les nouveaux et quelque soit leur notériété, étaient sûrs que debian/fedora/mandr* sortiront dans les trois mois une nouvelle version avec leur dernière mouture, la question n'aurait pas tant d'importance.

                            Alors non je ne suis pas d'accord avec toi. Je trouve fondamental pour linux qu'une solution de mise à disposition de binaire de type unzip and click, ou setup, qui ait une petite chance de marcher chez beaucoup de monde c'est essentiel. Et plus pour les projets libres que pour les propriétaires. Que l'absence ne gène de toutes façon pas beaucoup (java, realplayer, flash, nvidia...). Oui c'est un risque pour la sécurité.

                            Je pense qu'il y a des risques et des inconvénients qui sont acceptables. De toute façon la sécurité absolue n'existe pas et personne n'a jamais obligé un utilisateur de logiciel libre à utiliser les binaires fournis.

                            L'enfer est totalement sûr. Avez-vous envie de vivre en enfer?

                            • [^] # Re: Utilisation des applications sans 'installation'

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

                              Et si debian a mis en place backports.org, si ubuntu a eu tant de succès, si quasiment tous les projets libres fournissent des binaires, c'est bien pour répondre à un besoin. Et ce besoin, je trouve que tu en sous-estimes l'importance.

                              Je n'appelerais pas vraiment cela une besoin mais une demande.
                              Les utilisateurs qui demandent toujours la toute dernière version des logiciels ne savent pas toujours pourquoi ils veulent la toute dernière. Si encore, ils arrivaient à dire pour quelle raison ils ont absolument besoin de la toute dernière version, je ne dis pas. Mais force est de constater qu'ils ne le savent pas toujours eux-mêmes.
                              Petite précision : ce n'est pas le projet Debian qui a mis en place backports.org mais des utilisateurs et quelques développeurs Debian. De même pour Ubuntu, les paquets ne provenant pas de main ne sont pas officiellement supportés par Canonical. Les utilisateurs utilisent donc ces paquets binaires à leurs risques et périls. Dans le monde commercial, ils ne pourraient pas se retourner contre l'éditeur dans un pareil cas.

                              Si tous les projets libres, y compris les nouveaux et quelque soit leur notériété, étaient sûrs que debian/fedora/mandr* sortiront dans les trois mois une nouvelle version avec leur dernière mouture, la question n'aurait pas tant d'importance.

                              S'ils sont capables de développer des applications, pourquoi attendent-ils donc qu'un tiers veuille bien faire un paquet binaire pour la distribution X ? Pourquoi ne prennent-ils pas le temps de faire eux-même un paquet binaire pour Debian, Ubuntu, Fedora ou Mandriva (qui sont assez représentative) en fonction de la distribution qu'ils utilisent déjà, quitte à le proposer dans un premier temps hors distribution. Sous Ubuntu/Gnome, il existe un logiciel permettant d'installer un paquet deb en double-cliquant simplement dessus. Il gagnerait à être perfectionné (notamment en téléchargeant les dépendances manquantes si possible via APT).

                              Alors non je ne suis pas d'accord avec toi. Je trouve fondamental pour linux qu'une solution de mise à disposition de binaire de type unzip and click, ou setup, qui ait une petite chance de marcher chez beaucoup de monde c'est essentiel. Et plus pour les projets libres que pour les propriétaires. Que l'absence ne gène de toutes façon pas beaucoup (java, realplayer, flash, nvidia...). Oui c'est un risque pour la sécurité.

                              Force est de constater que les solutions autopackage, klik, etc. sont encore loin d'être aussi populaires. On mettra ça sur le compte de la possible jeunesse des dits projets. Mais visiblement, ces projets sont surtout là pour permettre à des logiciels propriétaires de prospérer sous Linux et tu ne peux pas demander aux utilisateurs de Logiciels Libres de souhaiter une telle chose. Il ne faut pas oublier que la première liberté accordée aux utilisateurs de Logiciels Libres, c'est précisément de ne plus dépendre du bon vouloir de l'éditeur concernant le développement du logiciel : le libre accès aux sources représente ce moyen.

                              • [^] # Re: Utilisation des applications sans 'installation'

                                Posté par  . Évalué à 3.

                                S'ils sont capables de développer des applications, pourquoi attendent-ils donc qu'un tiers veuille bien faire un paquet binaire pour la distribution X ? Pourquoi ne prennent-ils pas le temps de faire eux-même un paquet binaire pour Debian, Ubuntu, Fedora ou Mandriva (qui sont assez représentative) en fonction de la distribution qu'ils utilisent déjà, quitte à le proposer dans un premier temps hors distribution.

                                C'est bien ce qui se passe souvent dans la pratique. Mais ce n'est pas satisfaisant pour les développeurs non plus. Il y a trop de formats de paquets différents, et les distributions utilisant le même format arrivent à avoir des paquets incompatibles. Même lorsqu'elles sont aussi proches (synchronisées tous les 6 mois ?) que debian et ubuntu. Donc il faut faire un paquet sarge, un dapper, un edgy (quand on a, comme gcompris, la chance d'avoir un DD qui fait rentrer dans unstable les nouvelles versions très rapidement, sinon il faut aussi proposer un paquet pour etch et edgy+1). On ajoute les diverses versions de Mandriva encore utilisées et fedora et suse, côté rpm, ça devient ingérable. Il faut proposer une petite dizaine de paquets pour couvrir les cas les plus demandés. Et on n'a pas encore fait les paquets slackware ni arch ni gobolinux ni les builds gentoo ni les ports freebsd. Le temps à passer pour se documenter (comment je fais un deb? un rpm?) est rhédibitoire surtout que l'atomisation des distributions interdit de tester sur la majorité des cas.

                                Force est de constater que les solutions autopackage, klik, etc. sont encore loin d'être aussi populaires. On mettra ça sur le compte de la possible jeunesse des dits projets.

                                On peut aussi mettre ça sur les inconvénients de ces systèmes.
                                - klik ne fait qu'ajouter un système de paquets à dépots centralisé à côté de celui de la distribution, je ne vois pas trop l'intérêt pour ça.
                                - 0Install est un peu étrange comme concept, ça peut rebuter. Il faut installer lee système de launcher, il télécharge/vérifie la version à chaque lancement, c'est pas si simple.
                                - autopackage marche bien, mais gère mal les dépendances. Il en signale juste les absences. Il faut télécharger une partie supplémentaire la première fois.
                                - je présume que loki_setup gère les dépendances comme autopackage.
                                - OBLISK semble gérer son propre système de dépendance ou ne pas les gérer.
                                Bref pas de solution vraiment satsfaisante. Du coup chaque projet bidouille (ou pas) ses install.sh dans son coin, ou essaie de proposer des debs et rpm pour une ou deux distributions. Et ça devient galère pour les autres utilisateurs.

                                Les utilisateurs qui demandent toujours la toute dernière version des logiciels ne savent pas toujours pourquoi ils veulent la toute dernière.
                                Parce que OOo2 est mieux que le 1? parce que FF1.5 gère le svg et pas le 1? Parce que tuxpaint 0.9.16 gère les polices exotiques correctement? parce que gcompris 7.4 a système de menu qui est bien plus mieux (je le sais c'est moi qui l'ai fait...)? Parce qu'au train ou vont les choses on aura 00o2 FF1.5 dans debian stable lorsque OOo3 et FF2 seront sortis sous windows? Parce que l'innovation se trouve aussi dans le logiciel libre et qu'on aimerait pouvoir en profiter? Parce que l'informatique à disposition sur internet favorise ce genre de comportement consumériste et irrationnel?

                                • [^] # Re: Utilisation des applications sans 'installation'

                                  Posté par  . Évalué à 1.

                                  Le problème, c'est que trop souvent les développeurs font un effort d'empaquetage, pour quelques distributions, mais ne pensent pas à mettre le .spec ou le répertoire debian/ dans leurs sources, que ce soit dans le système de gestion de sources, ou dans les archives distribuées.

                                  C'est dommage, car si ils le faisaient, des paquets pour de nombreuses distributions fleuriraient assez vite, selon bien sûr le rayonnement du projet.

                                  • [^] # Re: Utilisation des applications sans 'installation'

                                    Posté par  . Évalué à 2.

                                    je ne sais pas trop si c'est utile. Je ne connais pas rpm, mais le debian/ officiel doit de toute façon être refait par le mainteneur du paquet, et si le soft contient un peu de données on va se retrouver avec une génération de plusieurs paquets (truc et truc-data).

                                    Imagine que tu as un projet et que tu fournisse un deb. Mettre le debian/ dans le cvs/svn/git ou pas?

                                    Si le soft est simple (un seul paquet, exécutable et pas librairie) dh_make fait ça très bien pas besoin de le mettre dans le cvs. S'il est plus complexe (plusieurs paquets, comme gcompris) il faut mettre en place un dépot apt-getable, c'est déjà moins facile, mais quand c'est fait il y a les sources et un apt-get source te donne le debian/ donc pas besoin de le mettre dans le csvngit non plus.

                                    • [^] # Re: Utilisation des applications sans 'installation'

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

                                      Je ne vois pas ce qui empêche un développeur dit amont (par opposition au "développeur" de la distribution) d'avoir son propre répertoire debian/ dans son archive et même dans son cvs/svn/arch.
                                      Le développeur du projet GOsa a choisi cette solution mais il faut dire qu'il est également le responsable debian du paquet en question.
                                      Ce n'est pas parce que le debian/ permet aussi de générer un paquet dit source qu'il est pour autant incongru de le stocker aussi dans un dépôt cvs/svn/arch. De nombreux développeurs debian en font ainsi, j'en veux pour preuve l'existence des wrappers {cvs|svn|arch}-buildpackage. Après tout, le développement d'un paquet ne se fait pas en un jour et ça reste du développement.

                                      Puisque tu as une debian, si tu faisais des paquets "expérimentaux" avec tes RC pour que des utilisateurs de debian puissent les tester et te remonter les anomalies qu'ils rencontrent, vous auriez ce que vous semblez finalement rechercher. La base logicielle de la plupart des distributions à jour est relativement cohérente, à quelques patchs près.

                                • [^] # Re: Utilisation des applications sans 'installation'

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

                                  S'ils sont capables de développer des applications, pourquoi attendent-ils donc qu'un tiers veuille bien faire un paquet binaire pour la distribution X ? Pourquoi ne prennent-ils pas le temps de faire eux-même un paquet binaire pour Debian, Ubuntu, Fedora ou Mandriva (qui sont assez représentative) en fonction de la distribution qu'ils utilisent déjà, quitte à le proposer dans un premier temps hors distribution.

                                  C'est bien ce qui se passe souvent dans la pratique. Mais ce n'est pas satisfaisant pour les développeurs non plus. Il y a trop de formats de paquets différents, et les distributions utilisant le même format arrivent à avoir des paquets incompatibles. Même lorsqu'elles sont aussi proches (synchronisées tous les 6 mois ?) que debian et ubuntu. Donc il faut faire un paquet sarge, un dapper, un edgy (quand on a, comme gcompris, la chance d'avoir un DD qui fait rentrer dans unstable les nouvelles versions très rapidement, sinon il faut aussi proposer un paquet pour etch et edgy+1). On ajoute les diverses versions de Mandriva encore utilisées et fedora et suse, côté rpm, ça devient ingérable. Il faut proposer une petite dizaine de paquets pour couvrir les cas les plus demandés. Et on n'a pas encore fait les paquets slackware ni arch ni gobolinux ni les builds gentoo ni les ports freebsd. Le temps à passer pour se documenter (comment je fais un deb? un rpm?) est rhédibitoire surtout que l'atomisation des distributions interdit de tester sur la majorité des cas.


                                  Trop de formats différents ? Il y a deux formats binaires principaux (je ne compte pas les ebuild de Gentoo/Gobolinux) : RPM et deb, point. Construire un paquet pour une distribution ou une autre s'appuyant sur l'un des deux formats consiste surtout à appliquer les régles (surtout avec les DFSG de Debian, du moins si tu veux que le paquet soit officiel) qui régissent la vie d'un paquet et de composer avec les dépendances qui sont disponibles. En gros, c'est tout. La documentation ne manque pas même si j'admets qu'elle est peut-être un peu prolixe .Il existe en effet au moins trois outils plus ou moins différents pour créer des paquets debian : dbs, debhelper, cdbs (pour ne citer que les plus répandus). Pour autant, la base demeure l'utilisation d'un Makefile par dpkg-buildpackage (qui peut être appelé par d'autres wrappers comme debuild ou pbuilder dont j'ai déjà parlé). La seule chose qu'un développeur rompu à l'utilisation des outils de compilation que sont les autotools et compagnie, finalement, c'est la façon dont le paquet se génère.
                                  Quant aux RPMs, c'est un peu plus simple puisqu'il n'y a que le fichier de spec utilisé par la commande rpmbuild. Il existe également des outils pour éviter les bévues classiques en utilisant des sandbox ou chroot notamment (voir les travaux de Dag Wieers, par exemple, que j'ai déjà cité).
                                  Si tu t'en tiens aux paquets binaires, tu n'as donc que deux formats... Évidemment, il faudrait plus que 40 Go pour être à l'aise avec des outils comme pbuilder mais, pour rassurer un peu ton co-développeur, je ne dispose pour ma part que d'un disque de 80 Go sur mon portable et ça suffit amplement. Quant au temps passé à apprendre ces outils, il n'est pas négligeable, certes, mais combien de temps as-tu passé à développer les applications et, si tu as fais toi-même les exécutables pour Windows, combien as-tu passé pour créer un .exe viable ? L'avez-vous testé sur toutes les versions de Windows disponibles ? Avoue que ce serait bien plus dispencieux à mettre en place qu'un "kit" de sandbox pour construire un paquet binaire pour chacun des distributions dites majeures (on s'intéresse au "top 5 de DistroWatch" : si tu parviens déjà à satisfaire les besoins pour RedHat/Fedora, Ubuntu, Debian, Mandriva et SuSE, tu en auras déjà bien fait le tour.

                      • [^] # Re: Utilisation des applications sans 'installation'

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

                        Tu es complétement à coté de la plaque. Je ne plaide pas pour GCompris qui n'a aucun problème de propularité.

                        Ce que j'aimerai c'est que tu te mette à la place de ceux qui ont passé des années à développer des logiciels et qui sont déçu par le modèle de distribution de GNU/Linux. Ce n'est pas un problème spécifique à GCompris, ce , n'est pas spécifique au domaine du jeu, mais à l'ensemble des logiciels libre ou pas qui désirent faire une version pour notre plate-forme.

                        Si tu prèfères, pourquoi les utilisateurs windows de Logiciel Libre sont mieux lotis que ceux qui sont sur GNU/Linux. Ils ont la version qu'ils désirent quand ils le désire, c'est eux qui choisissent la version, pas la distibution. Pourquoi les utilisateurs de windows ont plus de liberté que les notre dans le choix de leur logiciel ?

                        Je t'en prie, écoute les besoins des utilisateurs. Le système actuel n'est pas satisfaisant, ni pour les développeurs, ni pour les utilisateurs. Ce n'est pas en se masquant les problèmes qu'on va avancer. Ce n'est pas un débat contre les distributions qui on un rôle essentiel mais on ne peux pas ignorer la demande légitime des utilisateurs, je n'ai pas de solution, mais il y a un gros problème qu'il nous faudra bien traiter, tous ensembe.

                        • [^] # Re: Utilisation des applications sans 'installation'

                          Posté par  . Évalué à 4.

                          Si tu prèfères, pourquoi les utilisateurs windows de Logiciel Libre sont mieux lotis que ceux qui sont sur GNU/Linux. Ils ont la version qu'ils désirent quand ils le désire,

                          Ils l'ont parce qu'il n'y a pas de système de gestion de paquets sous Windows comme il en existe sous Linux. Dans Windows tout est installé n'importe où et n'importe comment, sans aucune cohérence, sans respect des autres logiciels installés et sans centralisation du code commun. Les systèmes de paquets sous Linux permettent d'unifier l'installation des logiciels, de garantir qu'il n'y aura pas de conflits entre les applications et de mutualiser l'utilisation de code commun.

                          Si tu veux que tes utilisateurs puissent installer ton logiciel sous Linux de la même façon que sous Windows, utilise un outil adapté, comme les Loki tools. C'est ce que font les éditeurs qui distribuent des logiciels propriétaires sous Linux (id Software, Epic, nVidia, Google, etc.).

                          Le système actuel n'est pas satisfaisant, ni pour les développeurs, ni pour les utilisateurs.

                          Le système n'est pas satisfaisant pour toi, c'est une chose, mais ne généralise pas. Moi il me convient très bien en l'état et ça a l'air d'être le cas pour pas mal de gens ici si on lit les commentaires.

                          • [^] # Re: Utilisation des applications sans 'installation'

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

                            Mais bien sûr qu'il me satisfait, dans 90% des cas, c'est génial. Mais parfois, j'ai besoin d'avoir une version récente ou particulière d'une application et là notre méthode de distribution de logiciel n'offre pas cette flexibilité (ou si mais au experts).

                            Ce système te convient, mais je suis curieux, as tu déjà eu besoin de compiler et d'installer un logiciel via 'make install'. Si ce n'est pas le cas, très bien, les logiciels proposé dans ta distribution te suffise. Mais si ce n'est pas le cas, penses tu raisonable de penser que les nouveaux utilisateurs, non expert, seront en mesure d'installer ces logiciels comme tu as du le faire.

                            Donc oui, le système est parfait pour moi, je sais compiler, mais je pense aussi aux autres, quelle liberté auront-ils s'ils sont réduit à l'installation de logiciel proposés par leur distro.

                            • [^] # Re: Utilisation des applications sans 'installation'

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

                              Je ne vois pas ce qu'un système plus "user-friendly" pour installer des logiciels dans /usr/local facilement apporterait aux utilisateurs.
                              Ce n'est pas parce que tu viens de publier ta toute dernière version estampilée "stable" parce que son état actuel te convient et que tu estimes avoir suffisament passé de temps pour corriger les bogues qu'elle sera complètement exempte de bogues ultérieurs (simplement parce que les utilisateurs utilisent d'autres distributions que toi, qu'ils utilisent un matériel forcément différent). Je ne pense pas qu'il appartienne à de charmants bambins de 5 ans d'essuyer les plâtres de ces éventuels bogues. Si c'est des testeurs dont tu as besoin, dis-le clairement mais ne viens pas nous que c'est de la faute au mode actuel de distribution (qui est davantage un garde-fou pour les utilisateurs, justement).

                            • [^] # Re: Utilisation des applications sans 'installation'

                              Posté par  . Évalué à 2.

                              Mais parfois, j'ai besoin d'avoir une version récente ou particulière d'une application et là notre méthode de distribution de logiciel n'offre pas cette flexibilité (ou si mais au experts).

                              Dans ce cas, utilise Loki Setup, c'est exactement fait pour ça. Il y a un installeur graphique simple à utiliser, ça ne pourrit pas le système, ça supporte les patches, les mises à jour et la désinstallation et ça s'intègre avec les environnements Gnome et KDE. Qu'est ce qu'il te faut de plus ?

                        • [^] # Re: Utilisation des applications sans 'installation'

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

                          Ce que j'aimerai c'est que tu te mette à la place de ceux qui ont passé des années à développer des logiciels et qui sont déçu par le modèle de distribution de GNU/Linux. Ce n'est pas un problème spécifique à GCompris, ce , n'est pas spécifique au domaine du jeu, mais à l'ensemble des logiciels libre ou pas qui désirent faire une version pour notre plate-forme.


                          Je ne peux pas me mettre à votre place, en effet mais ce mode de distribution ne date pas d'hier. J'ai davantage l'impression que les seuls développeurs vraiment intéressé par une telle main-mise sur la distribution sont/seront également davantage porté sur du code propriétaire sinon, c'est un problème d'égo (voir le cas DJB).

                          Tu écoutes les besoins de TES utilisateurs, c'est très bien et même plutôt une bonne chose mais essaie de comprendre que les autres utilisateurs ne sont pas forcément du même avis et j'en fais également partie. Nous sommes tous des utilisateurs de Logiciels Libres.

                          Pour finir, ton problème sera sans doute résolu par un compromis : l'intégration des outils comme autopackage, etc. sous forme de paquets binaires pour les distributions afin d'éviter qu'il ne fasse n'importe quoi (ainsi, la distribution pourra ajouter les chemins nécessaires aux logiciels, ce qu'autopackage ne sait pas faire par défaut). Je trouverais ça déplorable mais ça aura au moins le mérite de contenter certaines personnes.

                      • [^] # Re: Utilisation des applications sans 'installation'

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

                        Tu fais des mauvaises comparaisons, ce n'est pas les système de paquet qui posent problème, c'est le make install.

                        Hors, tu es obligé de faire du make install sur du poste client si tu veux des applications récentes non packagé. Et dans tous les cas, tu corompt l'intégrité du système.

                        Sauf qu'au moins, avec des paquets multi-distro, quelqu'un qui ne sais pas compiler peut aussi accéder a des logiciels récents ou non packagé.

                        La sécurité c'est important, mais c'est aussi un compromis entre les risques et les besoins des utilisateurs. De ce que j'endends sur les plates formes propriétaires, c'est plutot le coeur du système qui est touché et les applications phares hyper répandues.

                        • [^] # Re: Utilisation des applications sans 'installation'

                          Posté par  . Évalué à 2.

                          il y a plein d'application qui fonctionnent juste avec le make et pas le make install.

                          Ah oui, ........., le static.

                          Il faudra m'expliquer comment quelqu'un peut ne pas savoir compiler. il n'y a qu'a faire un lien configure & make & make install dans /usr/local avec droit pour le user ou dans ~/applis/.

                          ou cela pose problème c'est lorsque la compilation plante, ben oui ma brave dame défoi ca plante.. Ben cela ne changera pas, il ne sera pas possible de faire un paquet binaire pour une distribution ou la compilation aurait plantée (modulo la non-disponibilité des biblios-dev). Donc le travail sera identique pour les devs (et même pire car ils ne pourront plus se permettre de choisir la version des sdl_mixer, elle sera 'fournis' par les distribs [ mais non, le soft peut fournir la sienne : ah ah comme maintenant quoi ?].

                          Cette demande actuelle vient de dev de logiciels qui s'apperçoivent qu'ils ne sont pas au centre de la chaine informatique , mais à un bout (et l'utilsateur à l'autre). Il y a forcement un 'organisme' qui controle [ microsoft ou apple ou fedora ou redhat ou buntu ou debian..) C'est un fait. Point.

                          Il n'y a pas obligation pour un soft d'être distribué ou utilisé. Ok c'est plus facile sous winwin, avec un .exe tout pourrite on peut s'installer comme on veut (..pouvait.... car vista va changer la donne), c'est pas aussi facile sous linux, ben non et alors ?

                          Oui Gcompris n'a pas de problème, mais certaines applis en ont. et ? c'est la vie. Tu voudrais brider les dev de distributions pour quelques applis qui ont du mal à être distribuées ? Honte à toi [ nan je rigole, je voulais faire grandiloquent].

                          La technique de "distributions" permet de découpler le dev de l'utilisateur et donc de liberer l'utilisateur. En clair pour avoir un soft sur une distribution, il faut qu'il compile dessus (avec les sources et le how-to si c'est complexe). Demain quel sera l'avantage pour une applis de distribuer les sources, un bon binaire tout fait tout prêt ... ma brave dame ..... Comme windows en clair... non, pas "dans Claire". Ce que je comprends de ce que tu demandes c'est une remise en question d'une partie du libre, la liberté de choisir ses libs, ses versions, pour permettre à des devs (pratiquement tous proprio) de pouvoir se répandre dans le libre comme dans winwin sans travail et sans investissements.

                          On ne peut pas copier un modèle proprio pour arriver à un modèle de libre. Je te défis de trouver une seule applis utile et innovante, non dupliquée, n'utilisant pas des biblios exotiques et ne se trouvant pas dans les grande distributions.

                          • [^] # Re: Utilisation des applications sans 'installation'

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

                            Je suis désolé de te le dire comme cela mais tu n'as pas compris le problème.

                            Je le redis, la compilation est une affaire de spécialiste point barre. Ce point à déjà été largement évoqué plus haut.

                            Non microsoft ne controle en rien ce qu'installe les gens sur windows. Pour preuve, GCompris peut être installé sur windows simplement et je n'ai jamais été en contact avec eux. Ils fournissent une plate-forme ouverte, c'est tout.

                            Non, en simplifiant l'installation, en proposant des paquets multi-distribution on ne bride en rien ce qui font des distributions ou alors c'est qu'ils font une plate-forme fermée ou l'on ne peut installer que les logiciels qu'ils proposent eux. Cela n'est pas un modèle qui convient au grand public qui est habitué à avoir la liberté d'installation sur leur windows ou mac.

                            Je ne me pose pas la question de savoir si on copie ou pas le monde du propriétaire, ce qui est important, c'est de satisfaire les besoins de tout le monde ce qui n'est pas le cas aujourd'hui.

                            Ton défi est un non sens, ce que tu peux regarder, c'est que les applications majeures du libre fournissent des paquets binaire multi-distro ou des paquets binaire pour les différentes distros (firefox, openoffice.org, inkscape, gimp, ...).

                            • [^] # Re: Utilisation des applications sans 'installation'

                              Posté par  . Évalué à 4.

                              euh compilation affaire de spécialiste, repète le toi 250 fois chaque matin, cela doit te faire du bien et cela te donne de l'importance, TOI qui compile. Le fait que ce soi répété par 3 péquins n'en fait pas une vérité. C'est TON opinion.Point. Preuve : avant les drivers vidéo proprio se compilaient sur la machine (enfin la glue du noyeau pour le binaire proprio). Au moins c'était gpl-compatible. Maintenant cela ne l''est plus mais c'est plus simple, ca satisfait plus de monde, peut importe la gpl et le libre.

                              On peut trouve un terrain d'entente, :
                              - la compilation de soft mal fait ou excessivement complexe ou il est obligatoire d'avoir des directives de compilations particulières (pourquoi ?) ou il faut bidouiller parce que le soft est mal écrit, bidouille dans les libs, ou parce que le makefile est mal fait/pas complet/pas adapté etc... EST une affaire de spécialiste. (parfois certains logiciels libres ont des compilations particulièrement complexes sciemment pour vendre des binaires compilés.)

                              Il y a plein de softs qui compilent plus facilement que n'est l'installation 2/3 binaires. (une archive .bin qui s'extrait, se compile tout seul et s'installe tout seul. Eŧ qui peut juste s'extraire.)

                              >Je suis désolé de te le dire comme cela mais tu n'as pas compris le problème.

                              Euh... relis doucement mon post :

                              1/ microsoft controle (pas ce que les gens installe), mais ce qu'ils peuvent installer, il suffit de mettre à jour directX pour que toutes les applis utilisant le précédant se mettent à foncionner de manière ératique. Certes, il y a une compatibilité binaire ascendant partielle, mais regarde la manière de se répandent de chaque nouvelle suite office. Si tu penses que les gens achètent la nouvelle pour bénéficier de la très importante ombre grisé sur les boutons ou le support en lecture du nouveau fichier image que personne ne connait, tu est bien naïf. Ils l'installent parce qu'ils sont OBLIGES pour ouvir les fichiers qu'on leur fait parvenir.
                              Tu es d'ailleurs confonté au problème car sur win98, tu n'as pas le gcompris 8.2, pourquoi ?, tu verras avec vista ton gcompris 8.2 -> DTC. Microsoft controle bien ce que tu installes sur la machine gcompis 7 sur 98 gcompris 8 sur XP et gcompris 9 sur vista. Ok, il n'ont pas fait un truc EXPRES pour emmerder gcompris, mais la situation est identique : tu ne peux pas.
                              C'est d'abord LE problème de la vente lié, Microsoft controle ce qui peut (et ne peut pas) être distribué car il controle le système (et d'autant plus avec les update auto (obligatoire car internet).

                              2/ Non en simplifiant la distributions on ne bride pas les distributions, ou on bride les distributions c'est en créant un base OBLIGATOIRE commune pour simplifier la vie de quelques dev de logiciels qui ont décidé d'un seul coup que les distributions devaient être à leur bottes car merde, c'est bien eux qui font les logiciels quand même. Le libre existe depuis qu'un barbu à décidé de ne pas être lié à un fabriquant de logiciel/matériel et qu'un nordique à écrit des lignes qui permettent de faire un os. JE trouverais dommage de se trouver lié avec des bougres qui vont décider que gtk2-4 c'est bien™ et que la base des distros bien™ sera gtk2-4. pourquoi veux-u faire des installations multi distro (comme sous win) alors que tu peux pas sous win : gcompris 8.2 n'est pas dispo sous win98 (ca fait comme sous linux).

                              3/ la plate-forme n'est pas fermée car tu disposes des sources pour y compiler ton logiciel, elle t'es fermé car TU ne désires pas y compiler TON logiciel et que TU décides que cette distribution devrait suivre des lignes directrices exogènes pour TE permettre d'y distribuer TON logiciel, c'est bien quelque chose de très différents.

                              4/ NON la question n'est pas de satisfaire le besoin de tout le monde, c'est très très loin de la question, la question est : est-ce que l'on sera plus libre ou moins libre et c'est cette question dont beaucoup discutent (sauf ceux qui ne pense qu'a un meilleur distribution de LEUR logiciel). Cette question de satisfaction des besoins est exactement la même question que celle des drivers binaires (c'est marrant comme ce sont toujours les même questions qui reviennent), doit on fournir directement les binaires proprio pour satisfaire les "clients", enfin les besoins de tout le monde. Ce faisant quels sont les implications de telle ou telle décisions, mais là les satisfaiseurs de clients ne veulent plus jouer au jeux des question réponses et c'est un "trolleur-barbu-intaigriste" qui vient comme réponse. Est-ce que tu veux prendre le risque que dans 5 ans les distributions linux ne soient plus libre, juste pour pouvoir distribuer _plus_simplement_ ton soft ? Moi, non, très clairement.

                              [ Petit apparté; plus un programme dépend de lib externe, plus il est difficilement distribuable :
                              gcompris-data (= 6.5.2-4), vorbis-tools, libart-2.0-2 (>= 2.3.16), libatk1.0-0 (>= 1.7.2), libbonobo2-0 (>= 2.8.0), libbonoboui2-0 (>= 2.5.4), libc6 (>= 2.3.2.ds1-21), libgcompris-1-0 (>= 6.5.2-4), libgconf2-4 (>= 2.8.1), libglib2.0-0 (>= 2.6.0), libgnome2-0 (>= 2.8.0), libgnomecanvas2-0 (>= 2.6.0), libgnomeui-0 (>= 2.8.0), libgnomevfs2-0 (>= 2.8.3-7), libgtk2.0-0 (>= 2.6.0), libice6 | xlibs (>> 4.1.0), liborbit2 (>= 1:2.10.0), libpango1.0-0 (>= 1.8.1), libpopt0 (>= 1.7), libsdl-mixer1.2 (>= 1.2.6), libsdl1.2debian (>> 1.2.7+1.2.8), libsm6 | xlibs (>> 4.1.0), libxml2 (>= 2.6.16), python2.3 (>= 2.3), zlib1g (>= 1:1.2.1), python2.3-gnome2] Tu as de la chance d'etre présent sur autant de distribution.

                              Sur debian sarge la version de gcompris est 6.5.3-4 et je n'ai jamais réussi à compiler la dernière :
                              gcompris-data (= 8.2.2-1), libart-2.0-2 (>= 2.3.16), libatk1.0-0 (>= 1.12.2), libc6 (>= 2.3.6-6) [i386], libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2), libgcompris-1-0 (>= 8.2.2), libglib2.0-0 (>= 2.12.0), libgnomecanvas2-0 (>= 2.11.1), libgtk2.0-0 (>= 2.8.0), libogg0 (>= 1.1.3), libpango1.0-0 (>= 1.14.8), libpng12-0 (>= 1.2.15~beta5), libpopt0 (>= 1.10), libsdl-mixer1.2 (>= 1.2.6), libsdl1.2debian (>= 1.2.10-1), libsmpeg0, libsqlite3-0 (>= 3.3.8), libstdc++6 (>= 4.1.1-12), libvorbis0a (>= 1.1.2), libvorbisfile3 (>= 1.1.2), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxfixes3 (>= 1:4.0.1), libxi6, libxinerama, libxml2 (>= 2.6.2), libxrandr2, libxrender, libxxf86vm, python-gtk2, python-pysqlite2, python-xml, python2.4 (>= 2.3.90), vorbis-tools, zlib1g (>= 1:1.2.1). Pour ce faire, il faudrait que je change de distribution. CQFD. Ce que tu veux c'est que les distribs fournissent CES libs, sinon ca peut pas marcher.

                              5/ Les "gens" ont l'habitude d'installer sur win et mac ce qu'ils veulent, pour win cela permet une réinstallation complète régulièrement (c'est un choix), pour mac c'est la situation actuelle : les gens font du static dans une archive) Cela existe déja maintenant sous linux, c'est possible, tu peux le faire TOI demain sans changer RIEn qu'est ce que tu veux de plus ? Que linux change pour être comme windows ? pour quoi faire ?, juste installer plus facilement des logiciels , en passant par dessus les distributions qui ne font pas comme toi ? c'est une blague je suppose ?

                              6/ la question de la copie du monde proprio est, à mon sens, assez pertinente, car elle permet de se positionner "à terme" en regardant ce que l'on pense aujourd'hui. Ne peut-on pas penser aujourd'hui à ce que linux sera demain ? Tu sais des prospectives ou la philosophie du libre est au coeur du débat . Non, tu t'en fous, ce que tu veux c'est que ton Soft soit partout sur tous les linux
                              sans que cela te cause trop de soucis, peut importe les compromis que cela implique, ce qui est important c'est de satisfaire tout le monde (enfin surtout toi). Quel est le problème que je ne dispose que de Gcompris 6.5 alors que sous win c'est 8.2, celui-ci satisfait au besoin de mes enfants (même si il n'y a pas tout et si le menu est _moins_ bien ).

                              7/ si mon défis à un sens, mais un sens que TU ne veux pas comprendre, en clair : si un soft est bien, ils est distribué, si c'est une merde (ou sil il interesse 380 personnes dans le monde) il n'est pas distribué. Si l'objectif est de "normaliser" linux pour des merdes ou pour 380 personnes dans le monde, c'est débile.

                              > c'est que les applications majeures du libre fournissent des paquets binaire
                              >multi-distro ou des paquets binaire pour les différentes distros (firefox,
                              >openoffice.org, inkscape, gimp, ...).

                              DONC pas la peine de changer, cela marche déja comme tu veux : paquets binaires multi-distro. L'avantage de linux c'est le choix, *buntu, redhat, mandrake, *suse, *debian, gento, archlinux, slack, lfs, dsl, etc...... tu voudrais hamoniser (et gommer les changements) pour pouvoir distribuer des programmes (en plus des dizaines de milliers qui le sont déja) plus facilement. En fait tu voudrais faire un windows sous linux, avec tous les inconvénients (abscence de véritable choix, pas de pilotes libres, support matériel parfois hasardeux) sans les avantages (liberté, diversité). Ben ...... c'est un choix.

                              bon, ceci dit sans parler de TOI personnellement, mais du rôle que tu joues en demandant une normalisation (ce qui par defaut diminue la liberté). Cela n'empèche pas que j'aime bien gcompris.

                              • [^] # Re: Utilisation des applications sans 'installation'

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

                                Tu devrais te relire, c'est amusant, tu expliques que la compilation c'est facile mais tu te rend compte plus loin que toi même n'arrive pas à compiler GCompris (Je te rassure, tu n'es pas le seul ;). Donc je le re-redis, même si on peut dans certains cas blinder le truc et faire une compilation sure est simple, ce n'est pas un modèle viable à grande échelle. Autres inconvénients, le temps de compilation de certain logiciel et complètement disproportioné et il faut le faire sur chaque machine de ton parc.

                                C'est une erreur grossière de vouloir m'attaquer personnellement, je l'ai déjà dit, le support de GCompris par les différentes distributions est excellent en soit et je n'en attend rien de plus. Si je courrais après les parts de marché, ça fait longtemps que j'aurais arrété de supporter GNU/Linux. Comme pour les logiciels propriétaires, le coût surpasse de loin les bénéfices. Oui je critique le modèle global car il n'est pas satisfaisant et pose plein de problèmes aux utilisateurs et aux développeurs.

                                Ta remarque des 380 personnes ne me satisfait pas. C'est le même argument qu'utilisent ceux qui ne veulent pas supporter linux en fait. En maintenant un système qui favorise les gros projets, on tue la diversité que toi même prétant défendre. Contrairement à ce que tu penses, lorque les gros acteurs du propriétaires déciderons de venir sur GNU/Linux, ils auront bien plus les moyens que les projets communautaires pour distribuer des binaires qui marchent partout. Ils sera alors plus difficile d'utiliser du logiciel libre sur GNU/Linux que des soft proprios.

                                Pour ceux qui est de dire qu'un système de distribution multi-distro encourragerait le propriétaire, c'est possible, mais je préfère que les gens utilisent un système d'exploitation Libre avec quelques applications propriétaires plutot que ce que nous encourageons tous aujourd'hui, du logiciel libre sur un OS propriétaire.

                                Encore une fois, avoir une base commune n'est en rien limitant pour les distro qui d'ailleurs proposent déjà, pour les principales le LSB. L'autre possibilité qui ne me plait pas mais que tu défends s'en t'en rendre compte, c'est dire que la plate-forme commune c'est celle qui gagnera la guerre du desktop.

  • # 2 choses.

    Posté par  . Évalué à 6.

    - 217 commentaires et pas un pour se rendre compte que le monde ne se résume pas au x86, ce qui rend la distribution directe du développeur à l'utilisateur utopique.

    - La compilation d'un logiciel bien fait, ca peut prendre du temps, mais ca marche. C'est la diffusion de sources qui a fait que le logiciel libre existe, aussi pour une raison pragmatique : c'est le moyen le plus efficace et le plus simple de diffuser du logiciel pour des plateformes, des distributions non connues à priori.

    • [^] # Re: 2 choses.

      Posté par  . Évalué à 2.

      En même temps, de nos jours pour pas utiliser à x86 ça va devenir très compliqué, genre faut savoir addumer derrière. Tu conseillerais quoi à un non geek ?

    • [^] # Re: 2 choses.

      Posté par  . Évalué à 2.

      La question est intéressante, et comme tu le dis, il y a toujours les sources.

      Mais la question de l'architecture est indépendante de la question de paquetage. Aujourd'hui les projets fournissent des binaires sous forment de rpm, deb, .package compilés pour x86, rarement pour ppc. Je le sais, je suis toujours en ppc/g4.

      Qu'ils puissent fournir les binaires en un seul format qui marche sur tous les bureaux (autopackage, zéroInstall Klik... sont des tentatives pour ça) ne les empêchera pas de les fournirs en plusieurs architectures s'ils le souhaitent. Ou de ne les fournir qu'en x86 s'ils le souhaitent. Ou de ne les fournir qu'en source s'ils le souhaitent. En général les développeurs fournissent des binaires pour x86, et c'est tout.

      Cela amène quand même une autre question (indépendante de celle du paquetage). MacOSX permet aujourd'hui d'avoir des binaires compilés en format universel qui fonctionnent en ppc et en x86. Firefox est compilé comme ça maintenant. Comment ça marche? Et pourquoi ça existerait pas sous linux ?

      • [^] # Re: 2 choses.

        Posté par  . Évalué à 2.

        MacOSX permet aujourd'hui d'avoir des binaires compilés en format universel qui fonctionnent en ppc et en x86. Firefox est compilé comme ça maintenant. Comment ça marche?


        De ce que j'ai compris, il y a simplement 2 exécutables embarqués dans l'archive du logiciel et MacOsX fonctionne le bon en fonction de l'architecture. Faut pas oublier que sous mac os X, tu as l'illusion qu'un logiciel c'est un seul fichier, mais ce n'est évidemment pas le cas.

      • [^] # Re: 2 choses.

        Posté par  . Évalué à 1.

        Le format "universel" limité au x86 et au ppc me paraît limiter sacrément la taille de l'univers connu... Si tout le monde codait en langage interprété par une machine virtuelle, il n'y aurait pas trop de problèmes de changement d'architecture.

        • [^] # Re: 2 choses.

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

          Ça représente juste 99,9% des utilisateurs sur le poste client. Si on arrive à résoudre déjà leur problème à eux, ce sera pas mal non ?

          Dit autrement, sous prétexte de ne pas pouvoir aider 100% des utilisateurs, devons nous nous interdire d'aider 99,9% des gens.

          • [^] # Re: 2 choses.

            Posté par  . Évalué à 2.

            Les binaires "universels" ne résolvent pas vraiment le problème : puisqu'il faut de toute façon compiler deux fois, autant faire deux paquets différents. Ce n'est donc à mon avis pas une idée intéressante à retenir.

            Les langages utilisant une VM, en revanche, résolvent le problème de la diversité des OS et des architectures (en supposant que le problème des dépendances est déjà résolu) et on peut ainsi ajouter un 9 à ton 99,9% (pour les stations de travail et les gros serveurs à terminaux X).

          • [^] # Re: 2 choses.

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

            Puisque Windows représente toujours plus de 90% des utilisateurs potentiels, tu n'as qu'à fournir qu'un paquet msi pour eux et puis c'est tout.
            Dit autrement, sous prétexte de ne pas pouvoir fournir Gcompris à 100% des utilisateurs, devrais-tu t'interdire de le fournir à 95% d'entre-eux ?
            Je n'arrive pas à cerner ton problème finalement. Quels peuvent donc être ces utilisateurs si importants à tes yeux ?

    • [^] # Re: 2 choses.

      Posté par  . Évalué à 2.

      217 commentaires et pas un pour se rendre compte que le monde ne se résume pas au x86

      tu ne les as pas lu, on dirait.

  • # Y a quand même autre chose à faire que des paquets.

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

    Franchement, je préfererai souvent que les distros supportent moins de logiciels mais que l'intégration et les outils de configuration soient plus poussés.

    Avoir quinze serveurs de mail ça roxe, avoir Postfix/Cyrus bien configuré avec un outil puissant pour l'intégrer à son parc applicatif (LDAP, BDD, sécurité réseau, backup, toussa ...) c'est mieux.

    Avoir 36 solutions de HD, loadballancing c'est bien, mais moi je veux juste agréger quelques liens ethernet. Il est ou l'outil pour faire ça ?

    Avoir 295 environnement de bureau, c'est parfait. Moi j'aimerai bien pouvoir choisir à la création du compte utilisateur :
    Etes-vous :
    _ Un jean-kevin
    _ Un neuneu
    _ Un poweruser
    _ Un geek
    _ Un enfant

    Et avoir un truc configuré et intégré correspondant à l'usage que je vais en faire.

    Elle est ou la solution de controle parental dans l'environnement Desktop ? A oui faut installer squidguard ou privoxy ...

    Une solution d'installation "universelle" économiserai bien du travail, permettrait d'éviter d'avoir à packager sans arret et donc de faire d'autres choses.

    • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

      Il faudrait surtout arrêter de vouloir à tout prix tout mélanger.
      Les postes de travail, l'ordinateur personnel et les serveurs ont besoin de systèmes dont les besoins en terme logiciels sont totalement différents et parfois complémentaires.
      Ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus.
      Quant au poste de travail, il existe déjà des distributions qui se sont faits une spécialité en ne proposant qu'une voire deux maximum logiciels par type de logiciels (Ubuntu pour ne pas la citer). Les environnements comme Gnome et sans doute KDE proposent déjà des la définition de profils d'utilisateurs (avec sabayon pour Gnome).
      Pour le contrôle parental, pour l'heure, il n'y a guère de solution concrète et graphique mais à la rigueur, il vaudrait mieux prendre le temps d'éduquer ses enfants : c'est un peu comme vouloir mettre un casque à un bébé de 12 mois qui apprend à marcher. Quand il n'aura plus son casque, il n'aura jamais eu la conscience du danger : oui, tomber, ça fait mal alors il faut faire attention. Ça s'apprend, ce n'est pas inné.
      La solution "universelle" d'installation n'existe pas et encore moins au pays de Microsoft, il n'y a qu'à voir le nombre d'installateurs utilisables et différents pour s'en convaincre.

      • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

        >Il faudrait surtout arrêter de vouloir à tout prix tout mélanger

        tout à fait d'accord

        >ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus

        Qui parle d'un outil graphique ? Ce que je veux dire, c'est que l'installation d'un serveur aussi critique qu'un serveur de mail est loin d'être donné à tout le monde. La quantité de spam relayé en est la meilleure preuve. Le pire étant que beaucoup d'admins croient savoir le faire, alors que leur trucs sont de vrais passoires, mais ont-ils vraiment le choix ?

        Par outil puissant, j'entends un outil (peu importe sa forme) permettant d'intégrer une solution de mail dans sa boite sans être un gourou. Celà ne veux pas forcement dire graphique. Mais celà veux dire avec des tests, avec une analyse systématique des logs, avec la possibilité de déclarer l'existant, obligations en terme de backup ...

        Tu sais bien que ce n'est pas parcequ'un serveur marche, qu'il est correctement configuré.

        Alors pour reprendre l'exemple des serveurs de mail, tu peux toujours supporter exim, sendmail, postfix, qmail, courier, cyrus, teapop, uw ...
        Ceci dit faire des choix et les pousser le plus loin possible, c'est pas mal non plus. En ce sans pour revenir au sujet de départ, un systeme de paquet universel, permettrait aux distros de se concentrer sur quelques paquets tout en garantissant à l'utilisateur la diversité à laquelle il peut légitimement aspirer. Je ne donnais que quelques exemples de choses qui à mon sens auraient besoin d'être faites et qui ne le sont pas.

        L'idée générale c'est faire moins de paquets pour faire d'autres choses. Merci de me répondre la dessus.

        >il vaudrait mieux prendre le temps d'éduquer ses enfants

        Il vaudrait mieux éviter ce genre de réflexions qui peuvent être blessantes.

        Ma fille à 6 ans, elle apprends à écrire et à rechercher sur google.
        Hiers matin elle se lève vers 8h. J'étais déjà parti au boulot et ma femme dormait encore.

        Elle file sur un ordi, lance firefox, pour retrouver le jeu en flash avec lequel elle avait joué la veille et tombe sur un site de cul. C'est pas un drame, mais je trouve que c'est inapproprié.

        Quand on éduque ses enfants, on se rends justement compte a quel point l'image qu'ils ont de la sexualité est fragile et dévie facilement vers des idées fausses ou fantasmagoriques. Alors oui que ma fille de 6 ans tombe sur un site de cul, ça me fait profondement ch*.


        Moralité, je fais quoi pour éviter ça?

        Je met un écran de veille avec mot de passe pour éviter qu'elle surfe sans la présence d'un adulte ? Autrement dit, je bride son autonomie ? Ou alors je met un proxy filtrant pour éviter qu'elle tombe sur des sites pornos, ce qui me permet de lui dire qu'elle est grande maintenant, qu'elle peut utiliser l'ordinateur toute seule et que j'ai juste mis un truc afin d'empecher qu'elle tombe sur des choses inappropriées pour les enfants comme le site qu'elle à vue l'autre jour.

        • [^] # Re: Y a quand même autre chose à faire que des paquets.

          Posté par  . Évalué à 3.


          Hiers matin elle se lève vers 8h. J'étais déjà parti au boulot et ma femme dormait encore.

          Elle file sur un ordi, lance firefox, pour retrouver le jeu en flash avec lequel elle avait joué la veille et tombe sur un site de cul. C'est pas un drame, mais je trouve que c'est inapproprié.


          Bon, je vais passer pour un donneur de leçon mais tant pis:

          Ma fille a 7 ans, mais elle n'est pas autorisée à allumer un ordinateur seule. Et elle sait très bien qu'elle peut dire adieu à l'ordi si elle s'amuse à essayer. Quand elle se lève et que Papa et Maman ne sont pas encore disponibles, elle lit ou elle dessine ou elle écrit ou elle joue. Mais pas à l'ordi. ça a été dit et répété, et c'est intégré.

          L'erreur n'est pas dans l'absence d'un logiciel de contrôle parental (il n'y a aucun moyen d'avoir 100% de réussite) c'est dans l'absence d'une politique éducative qui ait pris en compte ce problème.

          Lorsque ma fille sera autorisée à utiliser le net seule (il n'y a pas de navigateur dans les menus de son compte), (et elle sera d'abord autorisée à utiliser l'ordi sans le net) il y aura au moins privoxy et dnsguardian, mais on lui aura aussi expliqué ce sur quoi elle risque de tomber, On attend juste qu'elle ait un âge plus adéquat pour ça.

          Je surprotège mes enfants, c'est probable.

          Pour paraphraser quelqu'un de connu, si tu crois que la technologie est une solution à tes problèmes de sécurité, tu n'as rien compris à la technologie, ni à tes problèmes de sécurité.

          • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

            Ma fille risque-t-elle de se blesser ou de mettre le feu à la maison ?
            Non
            Je ne vois dans ces conditions pas pourquoi je lui interdirai l'acces aux ordinateurs (dans la mesure ou ça reste en quantité raisonnable et dans les moments appropriés).

            Sur ce coup là, je me suis fait prendre de vitesse, ça arrive.

            Je n'ai absolument aucune raison de lui rajouter des contraintes à ce niveau. J'estime qu'elle en a déja assez : se lever, se coucher, faire les devoirs, aller a la douche, ranger sa chambre, ne pas regarder la télé en dehors des horaires impartits, soit polie ...

            Apres, je prefere que ça se soit passé à la maison que chez tatie, à l'école ou je ne sais ou.

            L'éductaion qui prévoie tout, désolé mais j'y crois pas trop

            • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

              >Ma fille risque-t-elle de se blesser ou de mettre le feu à la maison ?

              oui si elle tombe sur un site de cul ou autre.

              Donc tu peux :

              Lui autoriser l'acces à internet, dans ce cas il faut que tu lui explique sur quoi elle peut tomber, pourquoi c'est sur internet, pourquoi il ne faut pas qu'elle regarde etc... je ne suis pas sur qu'une enfant puisse comprendre, rien que l'acces au site porno, je ne pense pas que tu puisse "comprendre" avant l'adolescence et encore là c'est pas dis que ça ne choque pas.

              Lui brider l'acces à internet :

              Dans ce cas il faut que tu lui explique pourquoi tu bride, et là tu retombe dans les explications plus haut.
              Si tu lui bride automatiquement elle ne comprendra pas et sera probablement choqué le jour ou elle tombera sur un site pabien.
              Un peu comme lui autorisé l'acces à la télévision que sur une chaine qui diffuserais des dessins animés.

              Lui interdire l'acces à internet :

              Au moins tu evite toutes ces questions. =)

              Je pense que le mieux c'est d'être accompagné.

              (je n'ai pas d'enfants)

              • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

                Soyons clair,
                _ on parle de ce qui s'est passé, de ce qu'elle à vue.
                _ Quand elle surfe, géneralement elle est accompagné d'un adulte.
                _ J'ai mis un squidguard, je lui ai montré et expliqué à quoi ça servait
                _ devant la télé elle change de chaine quand il y a des pubs
                _ je ne veux pas lui interdire d'approcher de l'ordi.

                Pour la télé, on a imposé des règles. Pour l'ordinateur, on n'a pas pour l'instant besoin de le faire.

                Je ne comprends pas ce qui fait polémique dans ce que je dis. Si ce n'est que comme beaucoup, j'essaye de trouver les mots et l'attitude, qui lui permettra de grandir avec une image pas trop biaisée de ce qui l'entoure, une bonne capacité à se concentrer, à prendre des décisions et à avoir une activité sociale. Peut-être avez-vous un tas de certitudes en matière d'éducation. Moi je doute , je compose chaque jours, j'essaye de faire au mieux.

                Alors qu'un filtre parental puisse êrte à un moment un outil utile, ne me pose pas problèmes. Cela ne changera rien au fait qu'il y ait des enfants brimés ou livrés à eux même, d'autres encore qu'on prends pour des adultes ou pour des idiots.

                .

              • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

                Si devenir m'a bien appris une chose, c'est qu'il ne faut pas avoir de certitudes à ce sujet. Rien ne sera comme tu le pensais et pourtant, tu trouveras ça merveilleux de voir ton bout de chou essayer de marcher ou de dire ses premières syllables.
                On ne sait jamais ce qu'on fera vraiment sans être au pied du mur.

            • [^] # Re: Y a quand même autre chose à faire que des paquets.

              Posté par  . Évalué à 3.

              Je relève juste la différence:

              ne pas regarder la télé en dehors des horaires impartits
              Je ne vois dans ces conditions pas pourquoi je lui interdirai l'acces aux ordinateurs (dans la mesure ou ça reste en quantité raisonnable et dans les moments appropriés).


              et le fait qu'elle soit aller seule, sur internet, entre le départ du Papa et le lever de Maman. Justement parce que la quantité raisonnable et le moment approprié n'y sont pas.

              Si c'est pour dire: la télé c'est sous contrôle, mais le net, c'est quand tu veux mais pas trop, et que tu ne vois pas la contradiction dans l'attitude, alors tant pis. Accumule les filtres et engueule le monde à chaque fois qu'un site de cul passe à travers, mais surtout, répète bien fort que ça peut pas être de ta faute, parce que tu ne vas quand même pas brider ta gamine à 6 ans.

              Pourquoi la télé sous contrôle? Tu la brides ta gamine. Tu lui ôtes de l'autonomie, à ta gamine. Faut lui apprendre que quand elle sera grande, elle pourra même avoir la télé dans sa chambre. Mets la lui donc tout de suite, la télé dans sa chambre, il faut qu'elle apprenne l'autonomie et la télé.

              Rappel: les filtres filtrent les site de culs. Mais pas ceux des sectes. Les enfants doivent aussi être protégés de l'emprise des sectes.

              • [^] # Re: Y a quand même autre chose à faire que des paquets.

                Posté par  . Évalué à 1.

                Rappel: les filtres filtrent les site de culs. Mais pas ceux des sectes. Les enfants doivent aussi être protégés de l'emprise des sectes.


                En fait si : mon routeur est capable de faire du filtrage (pas testé, jai pas de gosse et cest payant à l'année, de plus ma copine considère que je suis assez grand pour pas en avoir besoin ;) ). L'outil en question permet de filtrer les sites par categories (politique, cul, chats, religion...). Comme j'ai précisé j'ai pas essayé, mais je doute néanmoins que ce genre de truc soit vraiment éfficace.

        • [^] # Re: Y a quand même autre chose à faire que des paquets.

          Posté par  . Évalué à 2.

          Je met un écran de veille avec mot de passe pour éviter qu'elle surfe sans la présence d'un adulte ? Autrement dit, je bride son autonomie ?

          Internet c'est pas plus difficile que de danser toute la nuit. Un enfant de 6 ans y arrive très bien. Faut-il le laisser le faire pour autant, sous prétexte d'autonomie?

          • [^] # autonomie =! n'importe quoi

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

            >Internet c'est pas plus difficile que de danser toute la nuit. Un enfant de 6 ans y arrive très bien. Faut-il le laisser le faire pour autant, sous prétexte d'autonomie?

            Bien sur qu'elle peut danser toute la nuit, mais sans boire trop d'alcool et si elle passe l'aspirateur le matin

            N'importe quoi.

            • [^] # Re: autonomie =! n'importe quoi

              Posté par  . Évalué à 2.

              Bien sur qu'elle peut aller sur internet quand elle veut, mais sans regarder de sites de culs et si elle passe l'aspirateur le matin.

              C'est quoi ton tire? autonomie != n'importe quoi ? Juste fais-le alors...

              • [^] # Re: autonomie =! n'importe quoi

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

                Je ne vois vraiment pas ce qui te fout en transe comme ça ? qu'essaye-tu de prouver ? t'es en manque de troll ou quoi ?

                Si tu essaye de dire qu'on est des parents négligeants, vas-y te prive pas. Au lieu d'essayer d'avoir raison. Eructe, mon grand ça fait du bien.

                Tu ne connais rien de notre vie, de notre façon d'éduquer notre fille. Tu ne connais rien à notre histoire.

                Tu porte des jugement péremptoire, tu es certain de toi. Je te laisse à tes certitudes.

                Salut

                • [^] # Re: autonomie =! n'importe quoi

                  Posté par  . Évalué à 4.

                  Tu ne connais rien à notre histoire

                  Ben je ne sais pas grand chose, mais dire que je ne sais rien, c'est un peu exagéré. je sais ce que tu as dit.

                  Je sais que ta fille de 6 ans va sur internet seule et que tu trouve ça normal.
                  je sais que la télé lui est limité et que tu trouve ça normal.

                  je sais aussi que ta fille de 6 ans s'est retrouvé sur un site de cul et que tu continues à trouver normal de la laisser aller seule sur internet, parce que tu crois qu'un proxy filtrant règlera le problème.

                  Moi je campe sur mes certitudes qui ne mettent pas mes filles devant la violence toutes seules. Je préfère mes certitudes aux tiennes.

                  Voilà dans mon campement de certitudes, un premier avis. Un proxy filtrant ne fait que limiter les dégats. Il n'y a pas de sécurité à 100%. Et ça ne filtre que ce qui est prévu par les gens qui en font les règles. Cette certitude là est partagée par le gouvernement.

                  Elle va rencontrer, souvent seule donc, et à supposer que ton proxy fonctionne bien, juste de la violence, de la guerre, des accidents, des blagues, du sexisme, de la pub et que sais-je encore. Le tout en vrac et sans prise de recul, puisqu'elle n'a que 6 ans. Je pense que ça sert pas à grand chose de contrôler ce qu'elle voit à la télé si c'est pour la laisser devant internet toute seule. Oui ça fait partie de mon campement.

                  Lui dire "Tu ne vas pas sur le net sans moi ou Maman"?
                  Lui bloquer l'accès par des listes blanches de sites autorisés?
                  C'est pas possible, c'est contraire à son autonomie, dis-tu?

                  Je continue mon campement ès certitudes:
                  L'autonomie? ça peut être progressif.

                  Mon ainée de 7 ans vient de finir un truc rose bonbon (les winx) et elle attaque "Harry Potter à l'école des sorciers". Elle va y rencontrer, comme dans beaucoup de contes, de la jalousie, de la violence, des morts, des salauds et des gentils (je viens de le lui emprunter pour le lire). Si elle est désoccupée elle a toujours ça a lire. Et si ça lui plait pas je trouverai d'autre livres qui lui plairont. Internet ne lui manquera pas de sitôt. Et quand elle ira dessus, elle aura un peu plus de recul et ne sera pas seule sans personne à proximité. Moi et sa mère sommes d'accord là-dessus. Si ça lui plait pas c'est pareil, c'est pas elle qui décide de ça.
                  Même si c'est pas la même chose chez ses copines. Tout le monde n'a pas les mêmes certitudes que nous.

                  Internet est pas plus dangereux que la route de l'école pour les enfants. On leur apprend les dangers de la route en les accompagnant à l'école. Il faut les accompagner sur internet. Oui c'est une autre de mes certitudes. J'aime bien camper.

                  à part ça je trolle. Et je campe. Sur mes certitudes. Toi non. J'admire ton adaptabilité. Vraiment.

        • [^] # Re: De l'utilisation d'outils dans l'éducation

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

          >il vaudrait mieux prendre le temps d'éduquer ses enfants

          Il vaudrait mieux éviter ce genre de réflexions qui peuvent être blessantes.


          Ce qu'il fallait comprendre dans cette phrase, au lieu de monter de suite sur tes grands chevaux, c'est qu'on ne doit pas se reposer entièrement sur un outil pour espérer éduquer ses enfants. D'où mon image du casque pour un enfant. Il y a aussi des cache-prises ou des protèges-coin mais il faut bien que l'enfant apprenne que tomber, ça fait mal, que l'électricité c'est dangereux, etc.
          Donc, oui, avoir un filtre parental, c'est bien gentil mais une fois que l'enfant ira utiliser un ordinateur dans un autre lieu (par exemple, chez sa tante puisqu'elle sait qu'elle peut utiliser les ordinateurs) et là, paf, elle tombera sur un site de cul, faute de filtre.
          C'est le rôle des parents d'accompagner l'enfant en évitant au mieux le pire. Mais on ne peut pas se reposer uniquement sur un artifice technique.

          Ma fille à 6 ans, elle apprends à écrire et à rechercher sur google.
          Hiers matin elle se lève vers 8h. J'étais déjà parti au boulot et ma femme dormait encore.


          Là, je suis désolé mais je rejoins l'avis de fleny68 : comment se fait-il que, sous prétexte d'autonomie, ta fille puisse allumer l'ordinateur familial alors que sa mère dort toujours ? Tu lui as interdit de regarder la télé avec pas mal de restrictions mais pas l'ordinateur, c'est plutôt incohérent... Autant la télévision est un monde plutôt aseptisé car ils évitent de choquer les enfants (à 7h du mat, y a plein de dessins animés, par exemple). L'Internet est un reflet numérique du monde réel : tout y est même ce que nous édulcorons d'habitude et que ça nous plaise ou non. Je ne vois pas donc pas pourquoi tu lui interdis la télé notamment la pub... Après tout, il y en aussi sur Internet.

          Elle file sur un ordi, lance firefox, pour retrouver le jeu en flash avec lequel elle avait joué la veille et tombe sur un site de cul. C'est pas un drame, mais je trouve que c'est inapproprié.


          Et quand elle va à l'école et qu'elle voit une publicité Aubade, n'est pas inapprorprié ? Tu ne pourras pas toujours être là pour lui bander les yeux.

          Quand on éduque ses enfants, on se rends justement compte a quel point l'image qu'ils ont de la sexualité est fragile et dévie facilement vers des idées fausses ou fantasmagoriques. Alors oui que ma fille de 6 ans tombe sur un site de cul, ça me fait profondement ch*.


          Comme leur apprendre que les garçons naissent dans les choux et les filles dans les roses parce qu'on élude toujours la question fatidique ?

          • [^] # Re: De l'utilisation d'outils dans l'éducation

            Posté par  . Évalué à 2.

            Comme leur apprendre que les garçons naissent dans les choux et les filles dans les roses parce qu'on élude toujours la question fatidique ?

            La pornographie est certainement la plus mauvaise réponse à cette question d'information, parce qu'elle met en scène des femmes soumises, banalise une sexualité basée sur la violence et remplace le désir et le plaisir par une sexualité tout à fait mécanique.

            Cela étant dit, et même si tu n'es pas d'accord avec elle, la loi impose de protéger les mineurs de la pornographie. Montrer, ou laisser ses enfants regarder de la pornographie est considéré comme un mauvais traitement. Fais changer la loi si tu en as envie (personnellement je suis contre), mais en attendant il faut la respecter. Ce qui ne signifie pas nécessairement filtrer, cela peut être accompagné lorsqu'ils sont sur internet. La bonne réponse n'est pas nécessairement technologique.

            • [^] # Re: De l'utilisation d'outils dans l'éducation

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

              Mais qui t'a donc parlé de les placer devant un film ou des photos pornographiques ? Pour ton information, les films X pourraient présenter tout autre chose que des femmes plus ou moins soumises si le sujet était moins tabou. Car, oui, c'est du commerce lucratif qui répond à un seul besoin : majoritairement celui des hommes.
              Pour autant, je n'ai pas dit de lui montrer des photos plus ou moins choquante mais de ne pas non plus édulcorer le sujet : en fait, que vais-je répondre à ma fille quand elle me posera la question "d'où viennent les bébés ?". Personnellement, je ne sais pas.
              Pour la conclusion : c'est précisément ce que je disais, la solution technique seule ne doit pas éluder l'éducation et l'accompagnement de l'enfant.

        • [^] # Re: Y a quand même autre chose à faire que des paquets.

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

          >ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus

          Qui parle d'un outil graphique ? Ce que je veux dire, c'est que l'installation d'un serveur aussi critique qu'un serveur de mail est loin d'être donné à tout le monde. La quantité de spam relayé en est la meilleure preuve. Le pire étant que beaucoup d'admins croient savoir le faire, alors que leur trucs sont de vrais passoires, mais ont-ils vraiment le choix ?

          Par outil puissant, j'entends un outil (peu importe sa forme) permettant d'intégrer une solution de mail dans sa boite sans être un gourou. Celà ne veux pas forcement dire graphique. Mais celà veux dire avec des tests, avec une analyse systématique des logs, avec la possibilité de déclarer l'existant, obligations en terme de backup ...

          Tu sais bien que ce n'est pas parcequ'un serveur marche, qu'il est correctement configuré.

          Alors pour reprendre l'exemple des serveurs de mail, tu peux toujours supporter exim, sendmail, postfix, qmail, courier, cyrus, teapop, uw ...
          Ceci dit faire des choix et les pousser le plus loin possible, c'est pas mal non plus. En ce sans pour revenir au sujet de départ, un systeme de paquet universel, permettrait aux distros de se concentrer sur quelques paquets tout en garantissant à l'utilisateur la diversité à laquelle il peut légitimement aspirer. Je ne donnais que quelques exemples de choses qui à mon sens auraient besoin d'être faites et qui ne le sont pas.

          L'idée générale c'est faire moins de paquets pour faire d'autres choses. Merci de me répondre la dessus.


          Puisque tu parlais d'un outil "desktop" donc graphique, j'ai donc extrapolé le besoin. Pour répondre à tes questions, le problème est qu'il existe des besoins bien différents et de nombreux outils pour réaliser les mêmes besoins si bien qu'il n'y a pas de solutions miracle. Toutefois, il est possible de créer des paquets pour disposer d'une configuration particulière à partir des paquets de la distribution initiale. Rien n'empêche de le faire et de créer une sous-distribution de Debian (par exemple) créant de toutes pièces l'outil dont tu as besoin. Ces solutions existent déjà : des solutions commerciales comme des solutions libres (je pense notamment à l'exemple d'OMA). N'oublie pas que les logiciels libres répondent à des besoins avant-tout égoïstes : ceux des développeurs/utilisateurs.
          Les distributions créent des paquets, c'est déjà un énorme pas pour pouvoir utiliser ces logiciels sans avoir à les compiler. D'autres part, ce n'est pas à la distribution de te dire qu'il faudrait utiliser une partition XFS pour stocker ton /var/spool/cyrus. En général, les entreprises qui veulent utiliser et intégrer de tels logiciels libres sans en avoir les compétences en interne font plutôt appel à une société externe : ainsi, si ça ne marche pas, ils peuvent se "retourner" contre le prestataire/fournisseur.

        • [^] # Re: Y a quand même autre chose à faire que des paquets.

          Posté par  . Évalué à 1.

          > > il vaudrait mieux prendre le temps d'éduquer ses enfants

          > Il vaudrait mieux éviter ce genre de réflexions qui peuvent être blessantes.

          Il vaudrait mieux éviter ce genre de réflexions qui peuvent être blessantes.

        • [^] # Re: Y a quand même autre chose à faire que des paquets.

          Posté par  . Évalué à 1.

          >>ce n'est pas parce qu'un outil sera graphique qu'il sera plus puissant que des fichiers textes pour configurer correctement ton Postfix/cyrus

          >Qui parle d'un outil graphique ? Ce que je veux dire, c'est que l'installation d'un serveur aussi critique qu'un serveur de mail est loin d'être donné à tout le monde. La quantité de spam relayé en est la meilleure preuve. Le pire étant que beaucoup d'admins croient savoir le faire, alors que leur trucs sont de vrais passoires, mais ont-ils vraiment le choix ?

          "ont-ils vraiment le choix ?"

          non mais quel argument de merde. si laisser en service un serveur de mail mal configuré était sanctionné pénalement d'une lourde amende (plus confiscation du matériel et évidement résilation de l'hébergement ou de l'abonnement chez le FAI, aka interruption du service) ou même d'une peine de prison, tu vas voir que les administrateurs du dimanche ils y réfléchiront à deux fois et feront toutes les vérifications nécessaires s'ils veulent vraiment installer un serveur de mail.

          la vérité est qu'une fois que ça marche chez eux ils s'arretent là et les détails comme les notions de relais à spam ils s'en branlent complet. tu peux mettre des garde-fous mais à la base ils sont irresponsables.

  • # un article sur le sujet

    Posté par  . Évalué à 2.

    un article sur le sujet :

    http://fr.news.yahoo.com/04012007/308/lsb-il-faut-simplifier(...)

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

Suivre le flux des commentaires

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