Compliqué !

• [^]Re: Compliqué !

  Posté par Stéphane P. () le 03/11/2009 à 16:50. (lien). Évalué à 3.

  Effectivement, en 32 bits c'est souvent très simple mais en 64 bits je comprend vos difficultés. Un des développeurs du projet a préparé des packets 64 bits pour debian et ubuntu mais qui ne concernent que les modèles mis à jour récemment (packages "opale3.1", "opalesup3.1" et "dokielguide2.3" par exemple).
  
  SCENARIdiscovery qui est juste un programme de démo suit les évolutions avec plus de retard et cela ne marche pas "out of the box" sur une distribution 64 bits. Bien qu'en remplaçant le répertoire java embarqué dans le programme par un lien symbolique vers une JVM 64 bits et en ayant les librairies d'émulation 32, cela devrait marcher en attendant. Je conçoit que cette solution ne soit pas idéale.
  
  On serait aussi intéressé s'il y avait des volontaires pour maintenir des packages ou des scripts de packaging pour d'autres distributions qui ne sont pas assez utilisés par notre petite équipe.
  
  Dans tous les cas notre rêve est que l'installation soit le plus simple possible pour tous les OS en toutes les versions sur toutes les architectures de toutes les distributions de toutes les chaînes éditoriales en toutes les langues... Mais le concept "temps disponible" est un des obstacles du monde réel qui fait que les choses avancent pas à pas.
  
  Stéphane

• [^]Re: Compliqué !

  Posté par ganymede () le 03/11/2009 à 16:52. (lien). Évalué à 3.

  Il me semble que ce problème vient du fait qu'il est très difficile de trouver comment construire soi-même les programmes de la suite scenari depuis leurs sources.
  Si la marche à suivre était indiquée clairement, il y a fort à parier que des packageurs externes au projet scenari viendraient se proposer et effectueraient ainsi un travail qui, il est vrai, n'a pas forcément à retomber sur les développeurs du logiciel. C'est plutôt le boulot des distributions et de leurs contributeurs.
  Pour l'instant, les seuls paquets disponibles sont pour ubuntu et debian (apparemment en 32 bits seulement ?), ce qui est dommage en effet.

  • [^]Re: Compliqué !

    Posté par Stéphane P. () le 03/11/2009 à 18:06. (lien). Évalué à 2.

    La compilation, c'est documenté sur le wiki "développeur", les commandes sont indiquées pour une ancienne version mais la procédure reste très similaire :
    http://scenari-platform.org/trac/dev-core/
    (partie Système de build de Scenari)
    
    Comme vous pouvez le voir, la difficulté de compilation ne viens pas forcément de Scenari lui même mais de la recompilation des dépendances si on souhaite les fournir en version statiques (pour xulrunner nous n'avons pas le choix...). En bref : avant de vous lancer dans le coté compilation, je vous conseil vraiment d'essayer le coté utilisateur pour comprendre comment le tout fonctionne.
    
    Si vous rencontrez des soucis, après avoir cherché par vous même, le forum est assez réactif pour vous aider à les résoudre.
    
    Comme je l'ai dit, on vient de rajouter des scripts pour compiler nos programmes sous formes de .deb 64 bits mais on ne l'a pas appliqué aux programmes les plus anciens (ceux qui sont présenté dans l'article s'installent aussi nativement et simplement en 64 bits : opale, dokielguide et optimoffice).
    
    Pour les autres distributions on met bien sûr a disposition un package binaire tar.gz, pour l'instant uniquement 32 bits et qui s'installe très facilement sur les mandriva et redhat que j'ai pu tester, qu'il est aussi possible de faire tourner sur une distribution 64 bits avec quelques efforts (cf mon poste précédent).

    • [^]Re: Compliqué !

      Posté par ganymede () le 03/11/2009 à 18:27. (lien). Évalué à 3.

      L'avantage de pouvoir compiler soi-même le programme est non seulement de permettre de fabriquer assez simplement des paquets installables pour n'importe quelle distribution (ce qui est déjà pas mal), mais aussi de les lier dynamiquement aux dépendances, telles qu'elles existent dans chacune des distributions. On obtient ainsi des programmes plus légers et nettement mieux intégrés, tout en évitant les contorsions parfois nécessaires pour exécuter un binaire 32 bits sur une plateforme 64 bits. Au passage, je viens de regarder pour Opale (celui des projets qui m'intéresse le plus) : le binaire sous linux (compilé statiquement, si je comprends bien) pèse pas moins de 50 Mo !
      Je ne sais pas précisément ce qu'apporte votre patch pour xulrunner qui oblige à inclure celui-ci statiquement dans les exécutables scenari, mais :
      - S'il apporte quelque chose qui vous est utile, l'avez-vous proposé aux développeurs de xulrunner pour en faire bénéficier tout le monde ? Dans ce cas, si le patch est adopté, la nécessité d'inclure xulrunner statiquement disparaîtra.
      - En quoi est-il indispensable d'inclure d'autres dépendances statiques, comme imagemagick par exemple, pourtant déjà présent dans toutes les distributions ?

      • [^]Re: Compliqué !

        Posté par Stéphane P. () le 03/11/2009 à 21:56. (lien). Évalué à 2.

        patchs xulrunner : je n'ai pas le niveau technique suffisant pour en parler en détail, je sais que l'on avait par exemple ce bug qui a été corrigé : https://bugzilla.mozilla.org/show_bug.cgi?id=366682 , je n'ai pas d'idée exacte pour le reste.
        
        Le principe d'embarquer le xulrunner est aussi d'être sur qu'on ne se base pas sur une version peu testé ou trop ancienne, par exemple sauf erreur de ma part, pas de xulrunner 1.9.1 dans lenny. De toute façon on doit l'embarquer sous windows et mac, si tout le monde utilise exactement la même version on évite les mauvaises surprises.
        
        
        "l'embarquement" des autres dépendances : pour imagemagick tu as raison, on n'a jamais eu de problème avec à ma connaissance, on ne l'embarque pas dans les .deb. Mais si ma mémoire est bonne il est présent dans les .tar.gz, car cela permet d'éviter de demander à l'utilisateur de l'installer lui même (il est très courant mais pas installé partout par défaut). Pareil pour la JRE, pour les .deb les dépendances fonctionnent très bien, pour le .tar.gz "toutes distributions 32bits" on l'embarque.
        
        L'objectif est de vraiment simplifier l'installation pour l'utilisateur final, il faut garder à l'esprit que la discussion ici est un peu élitiste... Pour beaucoup d'utilisateurs "tu l'installes et ça marche" c'est mieux que "tu l'installes, tu installes imagemagick s'il n'est pas installé, tu vérifies que tu as bien la JVM de sun et si tu en as plusieurs installées qu'elle est bien en première dans ton path, tu installes la version X.Y.Z du xulrunner, et ça marche", là ce serait comme le titre de ton message : "compliqué" :) On est prêt à sacrifier 40Mo de téléchargement pour être dans le 1er cas.
        
        Cela ne change pas le fait que les sources sont a la disposition avec suffisamment d'instructions et de disponibilité du forum pour que les grands aventuriers de la compilation puissent jouer avec si besoin. Mais Scenari est un vaste univers et il y a largement de quoi s'aventurer sans se lancer dans cette direction en premier.
        
        L'ordre le plus naturel que je recommande vivement :
        - écrire des documents dans un programme auteur (ceux de l'article par exemple).
        - sous réserve de besoins et compétences techniques il existe un outil "SCENARIbuilder" pour modifier la structure et la charte graphique des modèles sans avoir besoin de changer le code source du noyau.
        - et si vraiment besoin, le code source du noyau est la.
        
        Bonne soirée, et j'espère qu'Opale pourra te rendre service.
        
        Stéphane

        • [^]Re: Compliqué !

          Posté par ganymede () le 04/11/2009 à 00:11. (lien). Évalué à 3.

          Le principe d'embarquer le xulrunner est aussi d'être sur qu'on ne se base pas sur une version peu testé ou trop ancienne, par exemple sauf erreur de ma part, pas de xulrunner 1.9.1 dans lenny. De toute façon on doit l'embarquer sous windows et mac, si tout le monde utilise exactement la même version on évite les mauvaises surprises. Pour windows je veux bien, mais sous linux ce n'est clairement pas la meilleure approche... D'ordinaire, les développeurs se contentent d'indiquer que leur programme fonctionne / doit être construit avec telle ou telle version de telle ou telle dépendance ; ensuite, charge aux packageurs de créer des paquets viables à partir de ces informations.
          
          L'objectif est de vraiment simplifier l'installation pour l'utilisateur final, il faut garder à l'esprit que la discussion ici est un peu élitiste... Pour beaucoup d'utilisateurs "tu l'installes et ça marche" c'est mieux que "tu l'installes, tu installes imagemagick s'il n'est pas installé, tu vérifies que tu as bien la JVM de sun et si tu en as plusieurs installées qu'elle est bien en première dans ton path, tu installes la version X.Y.Z du xulrunner, et ça marche", là ce serait comme le titre de ton message : "compliqué" :) On est prêt à sacrifier 40Mo de téléchargement pour être dans le 1er cas. Pour la plupart des distributions linux, c'est très contestable ! Le plus simple et le plus habituel pour les utilisateurs est d'installer un programme depuis leur gestionnaire de paquets préféré, qui s'occupera automatiquement des dépendances.
          
          Je salue le travail que vous faites sur le projet scenari, mais je trouve que sur le point précis du packaging, vous vous compliquez un peu trop la vie - et aussi celle de l'utilisateur, du moins sous linux. Au passage, le titre « compliqué » n'est pas de moi, mais d'un autre utilisateur... qui a renoncé à utiliser scenari précisément pour cette raison.

          • [^]Re: Compliqué !

            Posté par lasher () le 04/11/2009 à 07:33. (lien). Évalué à 1.

            En même temps, on parle de 50 Mo à l'ère des PC avec 1 Tio de disque et 4Gio de RAM... Non, je n'ai pas ça chez moi, mais même mon PC vieux de 7 ans a 768 Mio de RAM et plusieurs dizaines de giga-octets ...

        • [^]Re: Compliqué !

          Posté par ganymede () le 04/11/2009 à 10:33. (lien). Évalué à 2.

          L'objectif est de vraiment simplifier l'installation pour l'utilisateur final, il faut garder à l'esprit que la discussion ici est un peu élitiste...
          C'est apparemment ici que le bât blesse : sous prétexte de simplicité, on en vient à faire les choix à la place de l'utilisateur. C'est un vieux débat...
          
          En gros cela aboutit à :
          
          1. Masquer certains aspects du logiciel. Je viens de télécharger le binaire générique d'Opale pour linux : une archive de 51 Mo, qui « pèse » 147 Mo une fois décompressée. À quel moment l'utilisateur qui télécharge et installe ce programme est-il informé qu'il contient, en plus d'une version patchée de xulrunner et imagemagick (compilés statiquement), rien moins que le JRE (Java Runtime Environment) de Sun ? À quel moment est-il informé, par ailleurs, que toute cette usine à gaz n'est prévue que pour une architecture 32 bits ? La plupart des utilisateurs de linux connaissent pourtant la notion de dépendances logicielles et savent choisir la version d'un programme qui correspond à leur architecture matérielle et leur distribution.
          
          2. Restreindre les possibilités de choix pour l'utilisateur. Prenons l'exemple du JRE de Sun. Pourquoi imposer celui-là plutôt que de permettre à l'utilisateur d'utiliser scenari, s'il le souhaite, avec openjdk, qui est l'implémentation libre du JRE de Sun, soutenue par l'entreprise Sun elle-même, et que de nombreuses distributions considèrent maintenant comme le JRE par défaut ? Serait-ce parce que l'équipe de développement de scenari n'a pas pu tester ses programmes avec d'autres JRE que celui de Sun ? Je doute fort pourtant que ce qui fonctionne avec Sun JRE ne fonctionne pas avec openjdk. Pourquoi ne pas laisser la communauté des utilisateurs tester scenari avec différents JRE, et ainsi pouvoir profiter des différents retours d'expérience ?
          
          Au bout du compte, je crois que les programmes de la suite scenari gagneraient à s'appuyer davantage sur la communauté des utilisateurs de logiciels libres, au moins pour tester ces programmes dans différents environnements et pour construire des packages destinés aux différentes distributions. Profiter des apports de la communauté, c'est bien l'un des avantages de développer un logiciel libre, non ?

          • [^]Re: Compliqué !

            Posté par lasher () le 04/11/2009 à 17:21. (lien). Évalué à 3.

            « La plupart des utilisateurs de linux connaissent pourtant la notion de dépendances logicielles et savent choisir la version d'un programme qui correspond à leur architecture matérielle et leur distribution. »
            
            Parce que la plupart des linuxiens sont des power users. Ce que je comprends de tout ça, c'est que justement, la cible du binaire est les utilisateurs « normaux » -- c'est-à-dire : les même utilisateurs que sous Windows ou Mac. Ces utilisateurs, ils ont un nom : « mon papa », « ma maman », « ma tante », mais aussi « mes copains technophobes ». Ceux-là on besoin d'un binaire qui juste marche.

            • [^]Re: Compliqué !

              Posté par ganymede () le 04/11/2009 à 18:55. (lien). Évalué à 1.

              Rien n'empêche de proposer un binaire « toutes dépendances incluses » pour Windows ou Mac - ce qui, en effet, conviendra à la plupart des utilisateurs - tout en permettant aux différentes distributions linux d'intégrer le programme suivant leurs propres standards.
              
              C'est tout bonnement ce que proposent la plupart des logiciels « grand public » présents à la fois sur windows, mac et linux ! Un petit exemple : sur le site de VLC tu peux télécharger un binaire complet pour windows ou mac sans avoir besoin de gérer toi-même les dépendances (ex : Qt4 pour l'interface graphique) ; mais si tu installes VLC sous linux, le gestionnaire de paquets de ta distribution te proposera d'installer automatiquement toutes les dépendances nécessaires, et le logiciel qu'il installera chez toi aura été spécialement compilé pour ta distribution.
              
              Procéder ainsi, ce n'est pas forcément plus de travail pour les développeurs du logiciel. C'est plutôt la construction d'un exécutable complet avec les dépendances incluses qui représente un travail supplémentaire.
              
              Un dernier aspect : ce n'est pas par hasard que beaucoup de logiciels libres sont conçus comme des « briques » qui peuvent être assemblées avec d'autres pour fournir aux utilisateurs les outils dont ils ont besoin. C'est le fameux principe_KISS, qui a fait le succès de nombre d'entre eux. Vouloir forcément « tout » inclure sans laisser le choix va à l'encontre de cette philosophie. (Mais c'est vrai qu'on s'écarte du sujet initial...)

            • [^]Re: Compliqué !

              Posté par hervé Couvelard (Jabber id, page perso, ) le 05/11/2009 à 11:27. (lien). Évalué à 2.

              Ouais, mais le binaire qui juste marche, ben ca juste marche pas forcément et s'il y a des voix dissonantes, c'est qu'il y a des problématiques réelles.
              
              Le soucis majeur avec les logiciels qui sont 'obligés' de fournir des binaires compilés statiquement c'est qu'ils veulent absolument utiliser les dernières versions des derniers logiciels à la mode, plutôt que d'utiliser les fonctions de bases des logiciels classiques, fonctions que l'on retrouvera facilement dans 5 versions consécutives différentes du logiciel en question. Alors si c'est une démarche adaptée pour les power user "bleeding edge" elle ne l'est clairement pas pour les utilisateurs normaux qui n'ont pas les dernières versions.
              
              Par exemple c'est le même problème avec moulin (le truc pour wikipedia hors ligne) ils ont un 'binaire' compilé statiquement avec un xulrunner fournis, sauf que le xulrunner a besoin d'une certaine version d'une lib et que cela ne marche plus avec dernière mise à jour de sid. Donc le projet ne marche plus.
              
              Ensuite, les utilisateurs "normaux" avec sénari et la mise en place de modèles, je rigole doucement, car les pré-supposés de connaissances sont hors de porté de ces utilisateurs 'normaux'.
              
              Enfin, ce que je regrette dans scénari, c'est que l'on retrouve presque la totalité des technos dispo : du c++, du java, du xul, du C et je dois en passer des pelles...
              
              Pour ceux qui veulent l'intégrer c'est du no-way. c'est pour cela que sorti des milieu universitaires et des boites qui paient les extensions, après 10 ans, ben scénari n'est allé aussi loin que l'on pourrait s'y attendre. C'est pour cela que personne ne se presse pour l'intégrer, car il y a trop de choses à 'tirer' avec, on choisit alors une solutions moins optimale, mais bien plus gérable.

              • [^]Re: Compliqué !

                Posté par Stéphane P. () le 05/11/2009 à 19:22. (lien). Évalué à 2.

                </troll-technique>
                
                Ce qui me surprend c'est qu'à chaque fois que j'entends parler de Scenari même parmi les militants du libre que je connais, j'entends avant tout parler du service rendu à l'utilisateur. Ici, certains "commentateurs" semblent oublier que en dehors du fait que le programme utilise le langage X ou Y et qu'il est compilé de la manière Z ou T, un programme existe avant tout pour rendre service a l'utilisateur (et pas seulement faire plaisir au geek).
                
                Pour être honnête avec vous, dans la population des utilisateurs Scenari, il y a bien plus de windoziens qui ne savent pas extraire des fichiers d'un .zip ou qui ont du mal avec les drag & drop que de linuxiens poweruser. Ce sont aussi ces débutants vont sortir grâce à Scenari des documents HTML 4.01 valid et des fichiers ODT. Avant de connaître Scenari ils n'avaient jamais rien fait d'autre que du MS word (sans utiliser les styles) et du powerpoint et ignorent toujours ce qu'est le W3C. Et aujourd'hui, ils écrivent des contenus XML en respectant les principes de la séparation fond/forme et de source unique sans même le savoir. Demain peut être, ou plus précisément quand sera venu "the year of the linux desktop" ces utilisateurs pourront continuer à utiliser ce logiciel libre car il fonctionne aussi sur un OS libre :)
                
                Dans ce précédent paragraphe, je parle bien de l'utilisateur final (par exemple la personne qui rédige un document avec Opale ou DokielGuide présenté dans cet article) et pas du concepteur de nouveaux modèles ou de l'intégrateur. Ce sont deux rôle clairement différent, faire un modèle demande un grand investissement personnel, des compétences techniques et n'est justifié que si vous avez un vrai besoin. Mais reste clairement plus efficace par Scenari que de rebidouiller soit même un éditeur WYSIWYM qui respecte un schéma évolutif et d'écrire toutes les XSL à la main, et d'implémenter tous les traitements particuliers pour chaque support (redimensionnement d'images, exercices interactifs, menus de navigation...).
                
                
                Il y a 10 ans, certes ce n'étais pas un mélange de technologie mozilla pour l'interface + un backend java, mais ce n'était pas non plus avec une édition XML brute sans interface et une architecture permettant tout juste de lancer 3 XSL que l'on pouvais imaginer rendre un tel service à l'utilisateur...
                
                
                Si dans le monde du libre tout le monde pouvait mettre ses préjugés de coté et faire preuve d'un peu d'ouverture d'esprit, s'intéressait plus à ce qui concerne les novices en informatique (comme l'explique très justement Jasher), passait plus de temps à encourager les usages des logiciels libres qu'a les dénigrer par des prétextes... Peut être que la communauté du libre aurait encore plus d'adeptes.
                
                
                Stéphane
                
                
                
                PS: Hervé j'ai bien aimé la transition "les utilisateurs débutants qui n'ont pas les dernières versions" avec "par exemple sous debian sid" :)

                • [^]Re: Compliqué !

                  Posté par ganymede () le 06/11/2009 à 01:29. (lien). Évalué à 1.

                  ces utilisateurs pourront continuer à utiliser ce logiciel libre car il fonctionne aussi sur un OS libre :)Ah bon, même sur une distribution linux 64 bits autre que debian / ubuntu ? En tout cas, pas sans quelques contorsions qui demandent des connaissances techniques supérieures à la moyenne. Et de la chance.
                  
                  passait plus de temps à encourager les usages des logiciels libres qu'a les dénigrer par des prétextesCe n'est pas parce qu'on émet des critiques (argumentées) sur le logiciel que tu développes qu'on « dénigre » les logiciels libres en général, et encore moins « par des prétextes » ! Ceux qui me connaissent savent que je m'efforce de populariser les logiciels libres autour de moi, à commencer par les utilisateurs novices. Si la critique te gêne, ce n'est pas une raison pour tomber dans le faux procès et l'amalgame.
                  
                  Peut être que la communauté du libre aurait encore plus d'adeptes.Vous développez un logiciel libre, c'est très bien. Ce logiciel convient à un certain nombre d'utilisateurs, c'est très bien aussi. Mais en tant qu'utilisateur (dans mon cas : ex-utilisateur) d'un logiciel, on a bien le droit de dire ce qu'on en pense, y-compris de relever certains problèmes rencontrés. À plus forte raison s'il s'agit d'un logiciel libre qui prétend fédérer une communauté. Mais je remarque qu'au lieu de répondre à ces critiques (en particulier la quasi-impossibilité de packager scenari pour toutes les distributions), tu préfères « dénigrer » les personnes qui les émettent (rien que des geeks et des power-users, qui ne comprennent pas les besoins de l'utilisateur « normal », n'est-ce pas !).

                  • [^]Re: Compliqué !

                    Posté par Stéphane P. () le 06/11/2009 à 10:37. (lien). Évalué à 2.

                    Je m'excuse. Vous avez raison sur le 64 bits. Comme je vous l'ai dit, nous avons commencé a travailler sur le sujet, nous allons continuer et je suis compréhensif et réceptif a cette critique.
                    
                    En ce qui concerne la méthode de packaging, vous avez raison aussi : un package spécifique a chaque distribution, c'est mieux qu'un ensemble de binaires statiques, qui n'est la qu'en solution de rechange. Malheureusement on n'a pas les moyens de fournir, maintenir et tester sérieusement tous les packages pour les autres distributions, d'où ce binaire.
                    
                    Et pour la compilation ou le repackaging, tu fais passer ça pour l'horreur absolue mais je ne pense pas que Scenari soit si exceptionnellement compliqué comparé à d'autres applications courantes.
                    
                    Ma réponse concernait surtout le poste d'Henri : c'est facile de critiquer Scenari sur le nombre de technologies utilisées, mais on ne va pas abandonner le XUL ou le java juste pour avoir moins de dépendances. C'est sur ce point précisément que j'ai trouvé la critique un peu gratuite.

                • [^]Re: Compliqué !

                  Posté par hervé Couvelard (Jabber id, page perso, ) le 06/11/2009 à 15:23. (lien). Évalué à 3.

                  Je croyais avoir fait un poste plutôt équilibré et pas trop trolesque, mais cela ne semble pas faire passer le message. Alors, je vais être plus direct et plus trolesque encore.
                  
                  Il y a deux choses exactement dans un logiciel :
                  1 - ses services rendus aux utilisateurs
                  2 - le logiciels en lui même.
                  
                  Si je ne veux pas prendre part aux discutions sur la partie 1, parce que cela ne me concerne pas, je puis en revanche parler de la partie 2.
                  
                  J'ai d'ailleurs abordé de cette partie pour 2 raisons :
                  1 - L'utilisateurs scénari est globalement un utilisateur windows , donc sur linuxfr, c'est pas le meilleur médium.
                  2 - ce n'est pas comme si il n'y avait pas un appel au troll technique avec :
                  >>On serait aussi intéressé s'il y avait des volontaires pour maintenir des
                  >>packages ou des scripts de packaging pour d'autres distributions qui ne sont
                  >>pas assez utilisés par notre petite équipe.
                  
                  Dans la totalité de mon post j'essaie d'expliquer pourquoi il y a si peu de "volontaires" pour faire ce travail. Et on m'explique que je devrais regarder le service utilisateur et pas la fabrication du logiciel : on se fout clairement de ma gueule.
                  
                  C'est d'ailleurs ce manque d'écoute qui m'a fait lacher l'affaire avec scénari, il y a 2 ou 3 ans : manque d'écoute récurrent dès que l'on sort du chemin balisé de "ce qui doit être fait" ©
                  
                  Maintenant si on veut bien regarder le "paradoxe scénari" (puisque on m'a amené sur le sujet de la compétence des gens et des 'services rendus' par le logiciel) :
                  C'est un logiciel qui permet une chaine éditoriale (comprendre écrire une fois, imprimer plein de fois sous différentes forme), et donc, forcement complexe.
                  
                  Maintenant, prenons un utilisateurs normal (celui qui ne sait pas ouvrir un zip) : il peut faire quoi ? juste utiliser les modèles livrés (comme un feu publisher)
                  et dans le cadre de ces utilisateurs, il est plus simple de faire une page formulaire avec xslt derrière plutôt que de mettre en oeuvre un si lourd marteau pillon.
                  Tirer partie de la force scénari, c'est gérer sa chaine éditoriale, ce qui est hors de porté de l'utilisateur normal, qui doit donc se tourner vers un power user pour faire les modèles et les filtres de sortie, power user qui va le vouloir sur sa machine, qui va donc devoir le compiler, la boucle est bouclée.
                  
                  Dans MON cas particulier, je désirais mettre en place un "filtre" LLSOLL pour scénari et intégrer scenari à la "distribution llsoll" pour permettre aux professeurs de langue de faire en même temps que leurs cours, td, polycopiés, interros, leurs exo de labo de langues. j'ai laissé tombé à cause de l'impossibilité de l'intégrer facilement dans une debian stable. Et à ce propos, le jour du "the year of the linux desktop", je doute que scenari soit inclus dans les distributions pour les même raisons.
                  
                  >>PS: Hervé j'ai bien aimé la transition "les utilisateurs débutants qui n'ont pas
                  >>les dernières versions" avec "par exemple sous debian sid" :)
                  
                  
                  Pour celle là, je ne veux pas croire que vous manquiez d'intelligence et que vous n'ayez pas compris mon propos, peut être trop "éliptif", mais dans le doute je vais le refaire en plus détaillé.
                  
                  Prenons un logiciel qui utilises des fonctionnalités particulières de logiciels autres, à tel point qu'il faille les dernières versions de ceux-ci (même pas dans débian stable) et même certains avec des options de compilations peu usités : il propose alors un binaire statique lié statiquement avec un binaire statique de sa dépendance. (c'est pour les user normaux qui s'en moque de télécharger 300 Mo de logiciels). Lorsque l'équipe ne s'occupe plus de ce logiciel, il ne peut plus marcher lorsque le binaire statique de la dépendance ne fonctionne plus sur la machine (pas la même version de la libc) et que le binaire dynamique ne fait pas l'affaire. C'est exactement le cas de moulin qui ne marche plus sur la dernière sid alors qu'il marchait sur sid il y a 1 ans. En clair : à cause de vouloir le faire marcher pour les utilisateurs débutant sans se prendre le choux, : il ne marche plus pour la machine de mes enfants qui sont débutant et sous sid : ils ont fait un mauvais choix technologique et demain il ne marchera pour plus personne.
                  
                  C'est toujours la problématique majeure : plus j'utilise de bibliothèque externe, plus je développe vite, mais plus c'est compliqué à packager & plus le logiciel est puissant, plus il est complexe à manier. Chaque logiciel place le curseur ou il veut, mais ces choix ont des répercusions sur la diffusion du logiciel. Mon opinion, c'est que le curseur technique compilation est trop loin sur la ligne pour scénari.
                  
                  Lorsque j'ai cherché un truc à intégrer dans un projet que je prototypais, je cherchais un produits que j'étais capable de monter moi même parce que le jour ou notre utilisation divergeais trop des "utilisateurs normaux" , il faudrait que je me débrouille tout seul pour en assurer la pérénité. Je ne l'ai pas trouvé dans scénari.
                  
                  Mais cela n'enlève pas la foultitude d'utilisateurs normaux windowsiens (ou ubuntiste) contents.