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.
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.
[^] # Re: Compliqué !
Posté par hervé Couvelard . En réponse à la dépêche Les 10 ans de Scenari. Évalué à 3.
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.