Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC

Posté par  . Modéré par Bruno Michel. Licence CC By‑SA.
Étiquettes :
36
4
sept.
2011
Technologie

GNU MediaGoblin

Ce projet en devenir se veut une alternative libre pour héberger et partager ses photos et vidéos (un concurrent de Flickr et Picasa). Le but est de lutter contre la centralisation des services Internet, il est annoncé pour septembre / octobre 2011, vous pouvez y contribuer via les ML et irc ou en essayant le code en développement.

Le projet est réalisé en Python et est disponible sous licence AGPL.

CloudStack devient opensource

CloudStack est un gestionnaire de machines virtuelles, basé sur libvirt. Il permet d'utiliser la ligne de commande, une interface web ou une API RESTful. Il prend en charge les machines suivantes : KVM, Xen, Oracle VM et VMWare.

L'entreprise a été rachetée par Citrix en juin et le logiciel qui est distribué sous deux versions dont une était propriétaire est désormais entièrement libre sous licence GPL. Il est développé en Java.

Walt Disney libère ses outils

Les studios Walt Disney mettent à disposition une partie des logiciels qu'ils utilisent pour leurs réalisations. On retrouve évidemment des logiciels dédiés au graphisme mais aussi un générateur de tests unitaires Python et un gestionnaire de paquets pour Mac OS.

Les licences dépendent des logiciels mais on retrouve Apache, BSD et MIT.

GREYC's Magic Image Converter (G'MIC)

G'MIC (GREYC's Magic Image Converter) est un projet proposant à la fois un outil en ligne de commande, un greffon pour GIMP et une bibliothèque C++, pour le traitement générique des images 2D ou 3D. La dernière version 1.5.0.2 de ce framework vient de sortir, apportant de nouveaux filtres et commandes, et renforçant la stabilité de l'interpréteur du langage de script intégré. Le greffon pour GIMP est aujourd'hui la partie du projet la plus visible et la plus utilisée, mais elle est aussi la plus limitée, puisque GIMP ne gère ni les images 3D volumiques, ni les images à valeurs flottantes ou à grand nombre de bits (16 ou 24), ce que la version en ligne de commande peut faire.

G'MIC est développé dans l'équipe Image du GREYC (unité de recherche CNRS), à Caen / France.

Merci à dtschump pour son aide lors de la rédaction de cette dépêche.

Aller plus loin

  • # Cloudstack != libvirt

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

    Non, CloudStack se base sur libvirt ( cf la liste des deps sur le wiki de Fedora : http://fedoraproject.org/wiki/Cloudstack ). C'est un logiciel au dessus de libvirt, dont le but est de déployer et manager à un niveau plus haut. Par exemple, CloudStack a un concept de zones et de pod, pour gérer les ips ( avec ip fixe, et des ips spécifiques pour des vms "guest", ie non provisionnés ), il a besoin d'un agent , il configure les vms ( genre le dns, etc ).

    De surcroit, la doc parle encore de version libre et de version premium :)

    • [^] # Re: Cloudstack != libvirt

      Posté par  . Évalué à 4.

      Je pertinente, je rajouterais que cloudstack est un concurrent direct à openstack et opennova, deux autres frameworks permettant de construire un cloud privée ou hybride de type IaaS

  • # MediaGoblin, une petite demo n'aurait pas ete de trop

    Posté par  . Évalué à 2.

    Je me demande qui va s'embeter a installer ca sans avoir pu l'essayer avant ?
    Generalement sur ce genre de projets, ils mettent en ligne une demo, ou au minimum une page de screenshots.
    Si il y en a une, elle n'est en tout cas pas du tout mise en evidence.

    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

      Posté par  . Évalué à 4.

      apparemment ce n'est encore qu'à l'état de projet. Ça aurait pu être précisé dans la dépêche.

      Is it ready for me to use?
==========================

Not yet!  We're working on it and we hope to have a usable system by
September / October 2011.

      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

      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

        J'ai précisé le point, c'est un appel standard à débugguer, essayer la version de dév', compléter... pour un projet qui a du code qui commence à devenir utilisable, cf. http://docs.mediagoblin.org/contributinghowto.html

      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

        Ils feraient mieux de contribuer à l'existant (Piwigo par exemple)

        http://piwigo.org/

        • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

          Posté par  . Évalué à 7.

          Pourquoi ? C'est pas les même technologies, ni la même licence et l'orientation n'a pas l'air d'être la même.

          La diversité c'est bien.

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

          • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

            Je suis le fondateur de Piwigo.

            En effet, la licence est différente : GNU MediaGoblin = AGPL, Piwigo = GPL.

            La technologie est différente : GNU MediaGoblin = Python/?, Piwigo = PHP/MySQL. Là je souhaite bonne chance à GNU MediaGoblin pour 1) faire une appli véloce qui ne consomme pas 130% du CPU sur le serveur 2) réussir à distribuer une application qui a des prérequis assez peu disponibles (PHP est largement plus disponible que Python sur les serveurs mutualisés)

            L'orientation en revanche, me semble assez similaire. En quoi est-elle différente selon toi Michel ?

            Mais oui, la diversité c'est bien et cela ne fait pas de mal. Piwigo fêtera ses 10 ans en 2012 et n'a jamais évolué autant qu'en ce moment. Les "grosses pointures" dans le domaine des logiciels libres du partage de photos sont Menalto Gallery (le plus ancien), Piwigo, Zenphoto (le plus jeune).

            Pour ceux que ça intéresse, voici un récent concurrent openphoto http://theopenphotoproject.org/ (qui selon moi a pour critère de différentiation principal qu'il fait les choses à l'envers par rapport à de nombreux logiciels libres : d'abord le marketing, les promesses et les finances, ensuite le développement; et ce n'est pas forcément une mauvaise voie)

            • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

              Pour ceux que ça intéresse, voici un récent concurrent openphoto http://theopenphotoproject.org/ (qui selon moi a pour critère de différentiation principal qu'il fait les choses à l'envers par rapport à de nombreux logiciels libres : d'abord le marketing, les promesses et les finances, ensuite le développement; et ce n'est pas forcément une mauvaise voie)

              Ca me fait penser à un petit projet peu connu du nom d'ubuntu. Ils sont arrivé avec une distribution qui n'était pas loin d'une recompilation de debian mais surtout avec des finances et du marketing. Bref le développement on l'a vraiment vu après.

            • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

              Posté par  . Évalué à 6.

              faire une appli véloce qui ne consomme pas 130% du CPU sur le serveur

              Trolldi c'est passé, des applications web performantes en Python ça existe. De plus, l'interpréteur python est nettement plus performant que l'interpréteur php, pour le web. La grosse différence se situe dans la qualité des connecteurs aux serveurs, la maturité de mod_php jouant en faveur de php, mais si tu utilises autre chose que PHP ou que tu utilises le mode worker, tu es obligé de passer à fastcgi, et php revient à égalité avec python. Sans compter WSGI qui permet de booster les perfs pour servir une application python.

              réussir à distribuer une application qui a des prérequis assez peu disponibles (PHP est largement plus disponible que Python sur les serveurs mutualisés)

              Oui et non, en mutualisé "gratuit", en général, tu as du php5 (avec des limitations à la con comme chez free) et une base, en mutualisé "payant", c'est assez courant d'avoir une stack python complète (et largement suffisante pour GNU MediaGoblin).

            • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

              Posté par  . Évalué à 4.

              Puisque tu commence à troller gratuitement, je vais te suivre.

              La technologie est différente : GNU MediaGoblin = Python/?, Piwigo = PHP/MySQL.

              Là pour moi, il y a un problème. Pourquoi obligé à utiliser un SGBDR particulier ? Même en PHP il existe des bibliothèques pour pouvoir facilement faire abstraction du SGBDR. Si j'ai envie d'utiliser Postgresql, sqlite ou firebird, pourquoi est ce que le logiciel m'en empêche ?

              Là je souhaite bonne chance à GNU MediaGoblin pour 1) faire une appli véloce qui ne consomme pas 130% du CPU sur le serveur

              Ça c'est gratuit. D'une part il n'est pas avéré que python soit plus lourd que PHP (c'est pas parce qu'un langage est pauvre qu'il est léger). D'autre part l'algorithme mis en place est dans l'énorme majorité des cas nettement plus important pour les performances que le langage lui même.

              2) réussir à distribuer une application qui a des prérequis assez peu disponibles (PHP est largement plus disponible que Python sur les serveurs mutualisés)

              Ça c'est l'histoire du serpent qui se mord la queue, si tout le monde fait des application en PHP pourquoi est ce que cela changerais ? Il me semble qu'il y a un « marché » important qui ont un serveur virtuel, un serveur dédié ou qui sont autohébergé. C'est cool parce que comme le dis la dépêche :

              Le but est de lutter contre la centralisation des services Internet, il est annoncé pour septembre / octobre 2011, vous pouvez y contribuer via les ML et irc ou en essayant le code en développement.

              Donc il s'adresse plus précisément à ce genre de personne.

              L'orientation en revanche, me semble assez similaire. En quoi est-elle différente selon toi Michel ?

              Piwigo ne gère que les photos, MediaGoblin veut à terme traiter divers types de média (vidéo et audio).

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

              • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                Même en PHP il existe des bibliothèques pour pouvoir facilement faire abstraction du SGBDR. Si j'ai envie d'utiliser Postgresql, sqlite ou firebird, pourquoi est ce que le logiciel m'en empêche ?

                En partie parce que PHP est l'un des temples du Not Invented Here. Ce qui fait que tout le monde faisant des applications PHP utilise sa propre lib d'accès aux SGBD, à chaque fois avec les mêmes bugs / limitations / ...

                Par contre :

                Pourquoi obligé à utiliser un SGBDR particulier ?

                d'après le trunk de piwigo il y a mysql, pgsql et sqlite

                • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                  Même en PHP il existe des bibliothèques pour pouvoir facilement faire abstraction du SGBDR. Si j'ai envie d'utiliser Postgresql, sqlite ou firebird, pourquoi est ce que le logiciel m'en empêche ?

                  En partie parce que PHP est l'un des temples du Not Invented Here. Ce qui fait que tout le monde faisant des applications PHP utilise sa propre lib d'accès aux SGBD, à chaque fois avec les mêmes bugs / limitations / ...

                  Aaaahhh… Oui, c'est la faute à PHP, ce langage tout pourri qui n'est utilisé que par des Mickeys qui ne connaissent pas les bibliothèques d'abstraction. Si seulement ils voyaient la lumière et utilisaient $langage_a_la_mode, ça se passerait beaucoup mieux : sa bibliothèque magique comprendrait que, lorsque j'écris SELECT * FROM coincoin LIMIT 10, je veux en réalité dire à mon MS SQL Server SELECT TOP 10 * FROM coincoin ; que lorsque j'écris SELECT a||b, je veux en réalité écrire SELECT CONCAT(a,b) (ou est-ce SELECT a+b ? Ah, les joies des standards) ; et ainsi de suite. Vrai ?

                  Bon, trêve de plaisanteries : comme tout le monde en PHP, j'utilise une bibliothèque d'abstraction (ADOdb, pour ne pas la nommer, plus un ORM rudimentaire basé sur la classe ADODB_Active_Record), mais je cible principalement MySQL. Pourquoi ? Tout simplement parce que c'est celui que j'ai le plus de chance de retrouver si mes applis doivent tourner sur une plate-forme d'hébergement tierce. Si un client me demande (PostgreSQL|SQL Server|DB²|Oracle|.*), ma réponse sera invariablement : sans problème, je vous fais un devis supplémentaire pour les tests et adaptations que ça va nécessiter. Ce n'est pas du NIH, c'est juste qu'il faut justifier le temps passé à adapter le code (c'est moins vrai pour des projets libres, mais quand même : est-il plus intéressant d'ajouter des fonctionnalités, ou de porter vers un autre SGBD ? Personnellement, je me concentrerais sur les features et j'attendrais que quelqu'un en ayant le besoin vienne me proposer un patch pour son SGBD de prédilection).

                  Envoyé depuis mon PDP 11/70

                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                    c'est la faute à PHP, ce langage tout pourri qui n'est utilisé que par des Mickeys

                    Si tu relis tu verra que je ne tape pas sur PHP (pour une fois) mais sur les personnes qui font du php, sur l'ecosystème php.
                    Ce n'était peut-être pas assez clair mais c'est pourtant ce que je visais.
                    PHP en lui même a peu à voir avec ça.

                    Si seulement ils voyaient la lumière et utilisaient $langage_a_la_mode, ça se passerait beaucoup mieux

                    Aucun rapport, avec tous les langages (même à la mode) je peux faire du NIH

                    sa bibliothèque magique comprendrait que, lorsque j'écris SELECT * FROM coincoin LIMIT 10, je veux en réalité dire à mon MS SQL Server SELECT TOP 10 * FROM coincoin ; que lorsque j'écris SELECT a||b, je veux en réalité écrire SELECT CONCAT(a,b) (ou est-ce SELECT a+b ? Ah, les joies des standards) ; et ainsi de suite. Vrai ?

                    Faux.
                    En fait non, c'est même possible comme fonctionnement, avec un parseur SQL -> SQL. Mais bon.
                    Par contre, que lorsque tu écris select(concat(a,b)) il te le traduise en SELECT a||b ou SELECT CONCAT(a,b) suivant la cible, ben oui c'est possible, et pire, ça existe.
                    Donc il n'y a pas de problème avec ça.

                    comme tout le monde en PHP, j'utilise une bibliothèque d'abstraction

                    Ha oué mais justement non.
                    C'est bien ça qui est décrié, c'est que tout le monde n'utilise pas de lib d'abstraction d'accès aux bases.

                    Ce n'est pas du NIH

                    C'est du NIH si tu réimplémente une nième vois un ORM qui existe déjà dans la nature, qui aurait déjà été testé, qui soit fiable, etc.
                    Si c'est autre chose comme test / dev / ... alors oui ça peut ne pas être du NIH.

                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                      En fait non, c'est même possible comme fonctionnement, avec un parseur SQL -> SQL. Mais bon.

                      Et ça existe ? Parce que, sinon, tout est possible, certes, mais on n'a pas forcément le temps ni les capacités de l'implémenter.

                      Par contre, que lorsque tu écris select(concat(a,b)) il te le traduise en SELECT a||b ou SELECT CONCAT(a,b) suivant la cible, ben oui c'est possible, et pire, ça existe.

                      Oui, donc en fait, à ce point, je n'écris plus du SQL, j'écris dans un langage qui est ensuite interprété en SQL (je pense au DQL de Doctrine, par exemple). Très peu pour moi, merci, j'aimerais éviter de multiplier les indirections.

                      C'est bien ça qui est décrié, c'est que tout le monde n'utilise pas de lib d'abstraction d'accès aux bases.

                      Oui, et ce que je dis en écrivant que je fais « comme tout le monde », c'est que ton assertion est à mon sens erronée : la plupart des projets ou des développements spécifiques un peu sérieux ont une couche d'abstraction (et la plupart du temps, c'est ADOdb ou PDO, quand ce n'est pas un ORM tel que Propel ou Doctrine). C'est même un des points que je vérifie en premier lorsque j'évalue un soft PHP.

                      C'est du NIH si tu réimplémente une nième vois un ORM qui existe déjà dans la nature, qui aurait déjà été testé, qui soit fiable, etc.

                      Mon critère de base était que ce soit basé sur ADOdb justement parce qu'elle est testée et fiable, et il y avait déjà une classe qui faisait 80 % de ce que je voulais. Pourquoi aurais-je été changer complètement de bibliothèque ? Autant tirer avantage du fait qu'on a accès aux sources, non ? Le point important reste pour moi le rapport entre temps nécessaire pour l'adaptation et avantage retiré d'un outil plus proche de ce que je souhaite.

                      Envoyé depuis mon PDP 11/70

                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                    est-il plus intéressant d'ajouter des fonctionnalités, ou de porter vers un autre
                    SGBD ? Personnellement, je me concentrerais sur les features [...]

                    Quelqu'un de pragmatique. Ca fait plaisir à lire !

                    Ton cas, c'est du développement spécifique apparemment, tu ne parle pas de développement d'un logiciel "largement" distribué à destination d'un public plutôt novice. La problématique est donc un peu différente.

                    Quelqu'un s'est déjà demandé pourquoi WordPress n'était compatible qu'avec MySQL ? qu'on ne me dise pas que WordPress c'est nul : WordPress c'est libre, c'est gratuit, c'est correct niveau performances, c'est énormément utilisé et incroyablement populaire. Je n'ai jamais lu de critique du style "WordPress c'est nul, ça tourne pas sur PostgreSQL" (en cherchant on doit en trouver, mais d'emblée je n'en ai jamais lu). Il faut croire que ses autres qualités surpassent ce léger inconvénient. Peut-être que s'ils étaient multiSGBD, ils n'auraient pas pu avoir un "ecosysteme" aussi gigantesque car le "ticket d'entrée" aurait été trop coûteux (faire un plugin compatible multiDB est plus compliqué que juste MySQL).

                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                      Je n'ai jamais lu de critique du style "WordPress c'est nul, ça tourne pas sur PostgreSQL" (en cherchant on doit en trouver, mais d'emblée je n'en ai jamais lu)

                      WordPress c'est nul, ça ne tourne pas sur PostgreSQL /o\
                      (et WP c'est troué, c'est en php, ça fait un bon vecteur d'intrusion pour les crackers et autres connards de script-kiddies quand ce n'est pas à jour :/)

                      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                        Je croyais que les trolls c'était vendredi uniquement. Je regarde mon calendrier, on est pourtant lundi :-)

                        WP c'est troué

                        Comme toutes les applications web. C'est attaqué parce que c'est extrêmement populaire donc lorsqu'on trouve une faille sur WordPress, on a des millions de cibles potentielles. (attention troll poilu des cavernes en approche) si tu trouves une faille sur Dotclear, tu divises par 10000 le nombre de cibles potentielles, mais il y en a quand même, des failles(/attention)

                        c'est en php

                        C'est en PHP, donc c'est mal ? Je te recommande de ne plus utilisé Wikipedia par exemple... ben oui, l'encyclopédie tourne avec PHP.

                        ça fait un bon vecteur d'intrusion pour les crackers et autres connards de
                        script-kiddies quand ce n'est pas à jour :/

                        Oui, mais si on fait bien les choses normalement, on ne touche pas au core de WordPress (idem Piwigo) et les mises à jour sont très simples (2 clics sur WordPress ou Piwigo)

                        L'argument du "c'est plein de failles, on va se faire hacker" n'est pas ridicule du tout, mais il faut faire un compromis, sinon on serait obligé de ne faire que du code spécifique pour chaque site pour éviter au maximum ce genre de désagrément.

                        • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                          et les mises à jour sont très simples (2 clics sur WordPress ou Piwigo)

                          comme drupal ?

                          L'argument du "c'est plein de failles, on va se faire hacker"

                          je pense que tu aimerais bien que piwigo se fasse un peu plus hacker, surtout si tu y trouves des contributeurs :-) J'ai parlé à raison de « un bon vecteur d'intrusion pour les crackers » ce qui est bien différent àmha :-)

                          • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                            comme drupal ?

                            sans doute. Je connais moins drupal.

                            je pense que tu aimerais bien que piwigo se fasse un peu plus hacker [...]

                            Pas d'inquiétude, on se fait régulièrement hacker. Moins ces derniers temps, mais à une époque c'était "fréquent" (plusieurs failles découvertes par an). Dans ce genre de cas, il y a les gentils qui nous contactent en privé et attendent qu'on sorte le correctif pour publier la faille et les méchants qui publient (parfois à tort) sans nous avertir.

                            Et je ne suis pas du tout certain que les chercheurs de failles fassent de bons contributeurs. En tout cas, à part un excellent retour d'une personne qui travaille aussi sur Dotclear qui nous a aidé à éviter les CSRF, en général les personnes ne s'intéressent pas à l'application et à ce qu'on peut en faire, ils craquent pour "l'exploit", pour avoir leur pseudo sur un site de sécurité.

              • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                Là pour moi, il y a un problème. Pourquoi obligé à utiliser un SGBDR particulier ?

                Piwigo 2.2, la version stable actuelle, est compatible avec MySQL et expérimentalement compatible avec PostgreSQL et SQLite. Après plus d'un an "d'expérimentation", de récentes discussions au sein de l'équipe de développement nous amènent à la conclusion que Piwigo ne supportera bientôt plus PostgreSQL et SQLite. Pourquoi ? parce qu'être compatible avec PostgreSQL apporte des contraintes pénibles de développement, empêche d'optimiser les requêtes efficacement et globalement les développeurs ne suivent pas : de nombreux bugs spécifiques à PostgreSQL ne sont pas corrigés et la quasi totalité des plugins n'est compatible qu'avec MySQL. Les utilisateurs testeurs sur PostgreSQL ne peuvent pas utiliser les plugins voire même certains thèmes et c'est très frustrant. C'est dommage, mais nous allons nous reconcentrer sur MySQL, qui présente de nombreux avantages : disponibilité, libre, gratuit, performant. (le jour où MySQL ne présentera plus ces avantages, il sera temps de changer)

                Vouloir être compatible avec plusieurs SGBD, c'est bien en théorie mais en pratique, c'est une charge de travail supplémentaire et au final, il faut être réaliste : les utilisateurs s'en moquent complètement. Les utilisateurs, ils veulent que ça marche, pas que les contraintes d'intégrité référentiel soient gérées de telle ou telle façon. Désolé si c'est trop pragmatique mais c'est mon expérience.

                Enfin ce que je voulais dire, c'est que je n'ai pas trouvé l'info du SGBD qu'ils utilisaient pour MediaGoblin. Enfin si, avec un peu plus de recherche, j'ai trouvé qu'ils utilisaient MongoDB, qui n'est pas un SGBD. Donc tu ne pourras pas utiliser PostgreSQL, mais à mon sens cela n'a rigoureusement aucune importance.

                [à propos de la vélocité de Python] Ça c'est gratuit. D'une part il n'est
                pas avéré que python soit plus lourd que PHP

                Encore une fois, je constate de manière empirique sur des exemples concrets (probablement pas assez nombreux pour en tirer une conclusion générale), mais lorsque j'ai fait tourner du Ruby On Rails ou du Python, le serveur avait vraiment du mal à suivre et la conséquence était une dégradation rapide de la qualité de service pour les visiteurs du site. Les applications équivalentes en PHP n'avaient quasiment pas d'incidence sur la consommation CPU/RAM du serveur.

                J'adore Trac, mais c'est bien parce que je n'ai pas trouvé d'équivalent en PHP que je le garde.

                Il faudrait sans doute que je me penche sur des solutions d'optimisation des performances de Python pour le web, mais "out of the box" avec apt-get, mon expérience c'est Python = lent et PHP = rapide. Cela ne signifie pas que Python = nul et PHP = génial. Cela veut plutôt dire que je réserve PHP à certains usages et Python à d'autres.

                Donc il s'adresse plus précisément à ce genre de personne [ceux qui] ont
                un serveur virtuel, un serveur dédié ou qui sont autohébergé

                OK, alors effectivement ça change tout, ils visent une niche vraiment petite (pour le moment, dans 5 ans, ce sera peut-être la majorité)

                J'ai vu une démo grâce à un lien trouvé un peu plus haut et effectivement, l'orientation me semble un peu différente de Piwigo. Avec Piwigo, tu créés ta galerie photo perso (que tu personnalises). Piwigo permet de faire du multisite, mais chaque "site" est indépendant des autres. Avec MediaGoblin, tu créés un compte sur un site de partage de medias. C'est un niveau "au dessus", une meta-galerie. Le concept est intéressant. Du coup, avec MediaGoblin, il y a 2 publics : d'abord celui qui installe le logiciel, il faut quelqu'un d'assez technique avec des prérequis pas triviaux, ensuite les utilisateurs qui se crééent un compte sur la plateforme, et là je dirais que c'est "monsieur tout le monde" (et ça c'est bien => populariser les services décentralisés).

                Celui qui installe MediaGoblin devient un hébergeur de galeries photos, avec les contraintes que cela impose quand même : quelle est la responsabilité de l'hébergeur sur le contenu de ses utilisateurs ? qui supporte les coûts d'hébergement ? Bref, c'est une problématique différente de celle de Piwigo (mais qu'on retrouve en revanche sur Piwigo.com = plateforme d'hébergement de galeries Piwigo)

                Piwigo ne gère que les photos

                C'est le métier principal et prioritaire de Piwigo. Mais on peut aussi y déposer des vidéos et n'importe quel type de document.

                • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                  MySQL, qui présente de nombreux avantages : disponibilité, libre, gratuit, performant.

                  Oué enfin c'est pas le seul a avoir ces avantages... ça n'a rien de mieux sur ce point par rapport à du postgresql (qui me parait par contre beaucoup plus robuste par exemple)

                  Vouloir être compatible avec plusieurs SGBD, c'est bien en théorie mais en pratique, c'est une charge de travail supplémentaire

                  Y'a aucune lib php qui permet d'abstraire les accès aux bases ?

                  lorsque j'ai fait tourner du Ruby On Rails ou du Python, le serveur avait vraiment du mal à suivre

                  Et pourtant on est en train de commenter sur un site fait en Rails. Et le moins qu'on puisse dire c'est que ça tourne quand même plutôt convenablement, non ?

                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                    Posté par  . Évalué à 5.

                    Et le moins qu'on puisse dire c'est que ça tourne quand même plutôt convenablement, non ?

                    Et la charge du serveur est même égale (ou moindre, je ne sais plus) à la version précédente en PHP.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                      Et la charge du serveur est même égale (ou moindre, je ne sais plus)
                      à la version précédente en PHP.

                      Voilà qui dément mes expériences passées. Tant mieux. J'avais du mal à croire que RoR soit si populaire (ait été plutôt, c'est moins la "mode" qu'il y a 3 ans) sans avoir les performances qui allaient avec. Il faut croire que soit je n'avais pas trouvé les optimisations nécessaires pour faire tourner RoR sur mon serveur, soit que l'application que j'utilisais était mal codé du point de vue performances.

                      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                        Posté par  . Évalué à 3.

                        Peut-être qu'il faut une charge minimal pour que ça vaille la peine aussi.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                    Oué enfin c'est pas le seul a avoir ces avantages... ça n'a rien de mieux sur
                    ce point par rapport à du postgresql (qui me parait par contre beaucoup plus
                    robuste par exemple)

                    Attention, je ne dis pas que PostgreSQL n'est pas bien. Personnellement, pour avoir travaillé avec MySQL énormément, Oracle beaucoup, PostgreSQL pas mal aussi et SQLite un peu : pour moi le meilleur techniquement parlant c'est PostgreSQL, sans conteste. La doc est excellente, les messages d'erreurs sont très bien faits, la gestion de l'intégrité référentielle est "incluse", les types de données sont simples. MAIS c'est moins disponible que MySQL. Donc pour une application distribuée comme Piwigo, c'est un critère majeur.

                    Y'a aucune lib php qui permet d'abstraire les accès aux bases ?

                    Il y a plusieurs stratégies pour faire du code indépendant du moteur de base de données. Grosso modo :

                    1) on peut déléguer l'intégralité de la gestion du code SQL à une librairie et réinventer le "select url from photos where id=123" en quelque chose du genre "sqlget(arary('id'), 'photos', array('id'=>123))". L'inconvénient de cette méthode, c'est qu'elle semble sympathique sur des exemples triviaux, mais c'est ingérable sur des exemples "de la vraie vie". Au final, je trouve que ça complique le code et ça génère des requêtes SQL génériques, pas du tout optimisées.

                    2) ou bien fait des requêtes SQL qui marchent théoriquement partout. L'inconvénient de cette méthode, c'est que les moteurs de base de données ont beau être compatible avec les normes ANSI SQL92 par exemple, en pratique, c'est faux. Il arrive souvent qu'une même requête soit incorrecte en PostgreSQL voire pire, ne donne pas les mêmes résultats en MySQL et en PostgreSQL (testé et approuvé malheureusement).

                    Dans notre cas, les requêtes SQL de Piwigo sont assez travaillées côté optimisation des performances. Ce n'est pas forcément un critère important pour tous, mais pour nous c'est assez critique.

                    Et pourtant on est en train de commenter sur un site fait en Rails. Et le moins
                    qu'on puisse dire c'est que ça tourne quand même plutôt convenablement, non ?

                    Tout dépend de la machine que tu mets derrière. Si tu as un petit espace sur du mutualisé, il y a à mon avis plus de chance que ton appli RoR soit coupée que ton appli PHP. Sauf si tu as choisi une appli PHP codée avec les pieds, et il y a en probablement beaucoup, et le "codé avec les pieds" est très subjectif de toute façon.

                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                      L'inconvénient de cette méthode, c'est qu'elle semble sympathique sur des exemples triviaux, mais c'est ingérable sur des exemples "de la vraie vie".

                      Mouai... Alors ça je le nuancerais fortement. Mais très fortement hein.
                      Evidemment tu peux avoir des libs moisies, qui ne font rien.
                      Mais tu peux aussi avoir le contraire, et pour utiliser des choses du genre dans mon boulot ça peut fonctionner sans problèmes, justement car tu n'as pas a faire une requête magique qui fonctionnera partout.
                      Il est justement possible (si on code bien son accès) d'exploiter au contraire les points forts de chaque sgbd car on le délègue à un objet qui sait le faire et qui sait qu'il tape uniquement sur tel ou tel sgbd.
                      Et même si le SQL varie parfois, la logique qui est derrière très rarement en réalité.

                      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                        Je veux bien te croire. Peux-tu donner des exemples de librairies qui font ça super bien ?

                        Dans le cas de Piwigo, on ne partait pas de rien, mais d'un existant dans lequel les requêtes SQL étaient au milieu du code PHP (certains trouvent ça horrible, moi pas du tout, bien au contraire). Pour éviter de réécrire 98% du code on a choisi la méthode 2, qui minimisait l'impact sur le code.

                        Peut-être qu'on aurait dû choisir la méthode 1 en trouvant une super librairie, au prix d'un chantier énorme et donc très long et qui allait apporter obligatoirement des régressions. Sauf que "est-ce que cela valait le coût ?". Je ne pense pas. Pour l'énorme majorité du public utilisateur de Piwigo, le moteur de base de données n'a pas d'importance. Il faut juste que ça marche. Les utilisateurs préfèrent qu'on passe du temps à améliorer l'interface utilisateur par exemple plutôt qu'à refaire Piwigo pour des questions techniques qui leur passent complètement au-dessus.

                        Si aujourd'hui je devais refaire une application web, non distribuée, la question serait tout autre et faire du PostgreSQL ou utiliser une librairie d'abstraction, pourquoi pas !

                        • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                          Posté par  . Évalué à 2.

                          Dans le cas de Piwigo, on ne partait pas de rien, mais d'un existant dans lequel les requêtes SQL étaient au milieu du code PHP (certains trouvent ça horrible, moi pas du tout, bien au contraire). Pour éviter de réécrire 98% du code on a choisi la méthode 2, qui minimisait l'impact sur le code.

                          Une architecture multi-tière ou MVC, c'est pas juste du buzzword qui ne sert à rien. Ça permet de regrouper au même endroit des choses qui ont la même utilité.

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

                          • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                            L'architecture MVC, il y a quelques temps (quelques années) un membre de l'équipe ne jurait que par ça et pour lui c'était évident qu'il fallait adopter ce type d'architecture. Il a fait un prototype tout simple pour voir ce que ça donnait avant de lancer le gros chantier. Résultat sans appel : une catastrophe en terme de performances. La page était entre 5 et 10 fois plus longue à générer côté serveur. Il a tenté ce qu'il pouvait pour améliorer les performances, mais il est arrivé à la conclusion qu'on ne pouvait pas rivaliser en terme de performances avec du code moins "abstrait" (avec moins de couches). Et ce projet et assez vite retourné dans les cartons.

                            Evidemment, on peut me répondre qu'il s'y est mal pris, qu'il n'a pas pris la bonne lib, qu'il faut réessayer en 2011. Sans aucun doute. Mais je ne vois pas bien ce que cela peut nous apporter. Piwigo est très performant, plutôt facile à maintenir et à étendre. L'ajout de couche pourrait rapidement rendre le tout ingérable.

                            Donc pour moi, séparer le "métier" et "l'accès aux données", je comprends l'intérêt mais je n'applique pas sur Piwigo. Par contre, on a clairement séparé le "métier" et la génération du HTML. On utilise Smarty pour cela. C'est plus propre et plus performant que la génération de HTML directement depuis le PHP.

                            • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                              Posté par  . Évalué à 2.

                              Piwigo est très performant, plutôt facile à maintenir et à étendre.

                              Quand changer de SGBDR, prend un temps pas possible et arrive à faire casser certains thème, j'ai un doute sur ce dernier point.

                              Sinon vous avez eu temps de problème de performance pour que ça soit si primordiale ? Tu nous en parle depuis le début et à toutes les sauces, c'est une contraintes qui a était si forte que ça ? et dure à tenir ? Il ne faut pas voir un troll dans mes questions, c'est juste que ce n'est (il me semble) pas mis en avant par le projet et que je ne m'en doutais pas.

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

                              • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                                [sur la facilité à maintenir et étendre Piwigo] Quand changer de SGBDR,
                                prend un temps pas possible et arrive à faire casser certains thème,
                                j'ai un doute sur ce dernier point.

                                Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/

                                Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.

                                J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.

                                Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.

                                "Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.

                                Sinon vous avez eu temps de problème de performance pour que ça soit si
                                primordiale ? Tu nous en parle depuis le début et à toutes les sauces,
                                c'est une contraintes qui a était si forte que ça ? et dure à tenir ?

                                Disons que le premier retour que l'on a de la part de ceux qui passent de Coppermine ou Menalto Gallery à Piwigo, c'est la performance : avec Piwigo, quelque soit la quantité de photos, ça va vite. Bon, on a un utilisateur avec plus d'un million de photos qui nous a dit avoir des soucis pour synchroniser. Mais ceux qui sont à plusieurs centaines de milliers sont très contents et nous on dit qu'il n'existait pas d'autre galerie open source qui en soit capable. Je n'ai pas tout testé, je les crois sur parole, d'autant que ça fait plaisir à lire :-)

                                Oui, tenir la perf c'est difficile à tenir. Désolé d'en parler à toutes les sauces. Je vois tellement d'applications web qui prennent 100% du CPU pendant 2 secondes (grâce à une tripotée de framework MVC et multiple couche d'abstraction) pour afficher une page vide que j'ai à coeur de ne pas reproduire la même chose avec Piwigo.

                                • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                                  Posté par  . Évalué à 7.

                                  Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/

                                  Faut s'en foutre des cliques ça fait juste parti du folklore local.

                                  Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.

                                  En fait c'est plus de la structuration de code. Si tu sais que pour tout ce qui touche à la base de données il faut aller toucher à l'objet DAO c'est nettement plus simple que d'aller voir avec grep toutes les utilisations de l'API SQL. Si en plus on a un moteur de template qui ne s'occupe que de la présentation des données et qui ne s'intéresse pas de savoir ce qu'elles représentent ni comment elles doivent être modifiées, alors tu as une application 3 tiers. C'est pas ajouter des milliards d'indiréctions, c'est juste avoir structuré son application de manière cohérente. Le sur-coût existe (on a plus de classes/objets, on appel des fonctions), mais à coté de ça l'application est nettement plus maintenable. Ça simplifie le travail collaboratif car chaque contributeur travailleras sur un sous ensemble du code qui s'utilisent entre elles avec le principe des boites noires.

                                  J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.

                                  Tu as raison l'un des grands principes de scrum est de ne pas hésiter à réécrire pendant chaque sprint. Cela n'empêche pas d'avoir une structuration de son code pour simplifier son développement (et simplifier les tests lorsque l'on fait des tests unitaires).

                                  Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.

                                  C'est même très bien. Prévoir la possibilité de créer des thèmes et celle d'avoir des plugins est un travail très complexes.

                                  "Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.

                                  Une méthode consiste à utiliser un paterne DAO. Pour chaque moteur, on hérite du DAO_MySQL et on réécris les méthodes qui en ont besoin. Ça ne me semble pas très couteux.

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

                                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                                    ah, tiens, pour MVC, je l'aurais dit plus simplement :
                                    Initialement, j'étais très dubitatif (pour rester poli), genre « mais quel bordel, j'ai 3 fichiers à éditer pour ajouter un champ partout ? » ; j'ai été convaincu le jour où on m'a dit, « rha c'est cool, les designers HTML sont super contents d'avoir pu tout remettre en forme simplement, sans avoir à demander aux développeurs de faire des pieds et des mains pour revoir toute la présentation du site ».
                                    Et, là tu te dis (en voyant le résultat sans rapport avec la mise en forme initiale), « ah ouais, mixer présentation et langage de dév', yen a qui ne vont pas aimer » et c'est un premier intérêt, de faire venir des non-développeurs et ainsi travailler à plusieurs, chacun son approche (et ensuite pour les développeurs, ya des IDE pour simplifier cela à l'édition et présenter les trois couches, qui restent tellement logiques une fois comprises que ça en vaut le coup pour un projet un peu gros et facilement éditable même pour un petit projet).

                                    Pour la maintenance, dans la durée (2-3 ans par exemple), mieux vaut tout de même prévoir les évolutions :/ Tout n'est pas que correction de bug, loin de là et prendre en compte un changement du stockage est un classique (rien qu'une montée de version par exemple, sans impact dans un cas, avec grosse refonte dans l'autre si trop d'optimisé^Wspécifique a été retenu à une époque plutôt que le standard qui aurait pu être écrit en même temps en plus, plutôt que de s'y replonger 2 ans après).

                                    Note : concernant LinuxFr.org, le code est relativement simple même pour quelqu'un ne programmant pas en RoR, justement grâce au MVC (et cela reste visiblement efficace en terme de performance). J'avais fait une page sur github, je pense avoir tout récupéré sur Participer-à-LinuxFr et Organisation-Code-LinuxFr mais ce n'est pas forcément clair pour tout le monde :/

                                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                                      Posté par  . Évalué à 2.

                                      ah, tiens, pour MVC, je l'aurais dit plus simplement :

                                      Je galère à présenter simplement les choses (par exemple je parlais de modèle 3-tière au dessus... :-)

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

                    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                      Posté par  . Évalué à 3.

                      Il arrive souvent qu'une même requête soit incorrecte en PostgreSQL voire pire, ne donne pas les mêmes résultats en MySQL et en PostgreSQL (testé et approuvé malheureusement).

                      O_o
                      On pourrait avoir un exemple, stp ? Qu'on ne se casse pas les dents alors que quelqu'un a déjà rencontré le problème...

                      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                        L'exemple très pénible pour les erreurs de syntaxe, c'est le "select fieldA from tableA group by field2". Cela ne fonctionne pas en PostgreSQL. Il faut que tous les champs du select soit dans le group by. Mine de rien, ça nous oblige à changer pas mal de requêtes ce genre de chose.

                        Pour l'exemple de requête qui ne retourne pas la même chose avec PostgreSQL, ce que je retrouve sur notre bugtracker, c'est surtout des changements faits pour PostgreSQL qui ont pour conséquence de casser ce que MySQL retournait, par exemple sur une requête comme :

                        SELECT c.uppercats, COUNT(DISTINCT i.id) AS img_count
  FROM '.IMAGES_TABLE.' i INNER JOIN '.IMAGE_CATEGORY_TABLE.' AS ic ON i.id=image_id
    INNER JOIN '.CATEGORIES_TABLE.' c ON c.id=category_id
  '.$where_sql.'
    AND date_available=\''.$dates[$i]['date_available'].'\'
  GROUP BY category_id, c.uppercats
  ORDER BY img_count DESC
  LIMIT '.$max_cats.'
;';

                        en Postgresql ça retourne des lignes sans doublons, mais en MySQL on a des doublons. Donc on rajoute un DISTINCT, mais alors ça ne marche plus avec PostgreSQL : un peu galère.

                        • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                          Posté par  . Évalué à 4.

                          select fieldA from tableA group by field2

                          Postgres: select distinct on (field2) fieldA from tableA; -- ça n'est pas du SQL standard, mais ta requête MySQL ne l'est pas non plus

                          Donc on rajoute un DISTINCT, mais alors ça ne marche plus avec PostgreSQL : un peu galère.

                          Tout à fait logique, MySQL ne respecte pas le standard SQL donc c'est la faute à Postgresql !
                          C'est pas moi qui le dit, mais la doc de MySQL: http://dev.mysql.com/doc/refman/5.1/en/group-by-hidden-columns.html

                          en Postgresql ça retourne des lignes sans doublons, mais en MySQL on a des doublons. Donc on rajoute un DISTINCT, mais alors ça ne marche plus avec PostgreSQL : un peu galère.

                          Soit tu tiens absolument à maintenir un seul jeu de requêtes pour chaque base de données et tu te limites au sous-ensemble fonctionnel, soit tu découples les requêtes SQL du reste du code (un peu comme la génération du HTML avec smarties), et tu adaptes celles-ci au dialecte supporté par la base. C'est typiquement le cas d'utilisation de PDO, je fournis un API commune pour manipuler divers SGBDR, et j'adapte mes requêtes SQL en fonction (une implémentation naïve serait de stocker mes requêtes SQL dans un fichier par base de données ou un poil plus malin, de cacher celles-ci en mémoire). Si tu me dis, que même çà à un coût signicatif niveau performances, j'aurais beaucoup de mal à le croire.

                          • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                            Je ne dis pas que MySQL est parfait et que les autres devraient faire pareil que lui. Ce n'est vraiment pas mon propos. Je dois vraiment mal m'exprimer si c'est ainsi qu'on me comprend :-/

                            Les normes SQL, il faut être réaliste : le développeur s'en moque un petit peu. Il consulte la documentation de son SGBD, celui avec lequel il travaille quotidiennement et qui lui importe le plus pour son projet et il adapte les exemples de la documentation pour son besoin de l'instant. Comme beaucoup ici, j'ai appris à l'école toutes ces normes théoriques, qu'on essayait d'appliquer ensuite en TP. Et puis ensuite tu arrives en entreprise, tu as du Oracle partout et exclusivement, tu regardes le modèle et tu te dis "quels guignols, ils ne respectent pas telle ou telle formale...", tu vas voir un développeur expérimenté qui te remet rapidement en place parce qu'ici c'est la vraie vie avec des vraies contraintes de performances et que si on duplique telle ou telle donnée, ça divise par 3 le temps de traitement. C'est juste un exemple, afin de démontrer qu'il y a souvent des écarts entre la théorie et la pratique et que c'est justifiable.

                            soit tu découples les requêtes SQL du reste du code [...] Si tu me dis, que même
                            çà à un coût signicatif niveau performances

                            Je pense que niveau performances, ce serait aussi efficace voire peut-être un poil mieux que ce qu'on fait actuellement. Le soucis, c'est que cela signifie un chantier énorme, pour une finalité pas si énorme que ça.

                            • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                              Posté par  . Évalué à 1.

                              le développeur s'en moque un petit peu. Il consulte la documentation de son SGBD, celui avec lequel il travaille quotidiennement et qui lui importe le plus pour son projet et il adapte les exemples de la documentation pour son besoin de l'instant

                              Mon coeur de métier n'étant pas le web, j'ai plutôt une expérience différente, j'ai du travailler avec du SQLite, MySQL, postgres, firebird (heureusement, j'ai toujours pu éviter les machins propriétaires). Les ORM peuvent constituer une solution mais pas toujours, heureusement qu'il existe des couches d'abstractions comme PDO en PHP, après pour les requêtes SQL, chacun sa méthode (partir d'une implémentation générique puis on optimise pour chaque base, implémentation base par base etc ...)

                              Le soucis, c'est que cela signifie un chantier énorme, pour une finalité pas si énorme que ça

                              Pour l'utilisateur qui a déjà une instance de Postgres, c'est un gain appréciable. Après, personne ne vous oblige à maintenir un backend postgres si vous n'en avez pas l'envie/le temps/les compétences etc ..., c'est du logiciel libre, libre à chacun d'apporter sa pierre. Dans l'écosystème libriste, le consommateur "passif" n'a pas voix au chapitre, soit il met la main à la pate (pas forcément dans le code, ça peut être de la traduction, documentation, promotion, packaging etc ... un échange de bons procédés), soit il met la main au porte-monnaie.
                              En découplant cette partie, ça vous permettra d'être un peu plus souple à l'avenir (par exemple, supporter un autre fork de MySQL comme Drizzle ou MariaDB), faciliter les contributions externes (tout est prêt pour supporter votre base préférée, y a plus qu'à coder les requêtes SQL qui vont bien et tester -pour caricaturer), découpler les requêtes SQL du code, ça peut même faire l'objet d'un Google SoC.

                • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

                  Posté par  . Évalué à 1.

                  Pourquoi ? parce qu'être compatible avec PostgreSQL apporte des contraintes pénibles de développement, empêche d'optimiser les requêtes efficacement

                  Tiens je serais curieux de connaître ces optimisations.

                  Les utilisateurs testeurs sur PostgreSQL ne peuvent pas utiliser les plugins voire même certains thèmes et c'est très frustrant.

                  Je me demande ce qui peut entraîner une tel incompatibilité.

                  C'est dommage, mais nous allons nous reconcentrer sur MySQL, qui présente de nombreux avantages : disponibilité, libre, gratuit, performant.

                  Disponibilité je comprends, mais libre, gratuit et performant il est loin d'être le seul.

                  (le jour où MySQL ne présentera plus ces avantages, il sera temps de changer)

                  Et ça sera une galère monstre vu comme il semble difficile de gérer postgre actuellement (on parle quand même d'un SGBD qui a était racheté par Oracle et qui a connu au moins un fork plus quelques alternatives l'an dernier juste à cause de ça).

                  Vouloir être compatible avec plusieurs SGBD, c'est bien en théorie mais en pratique, c'est une charge de travail supplémentaire et au final, il faut être réaliste : les utilisateurs s'en moquent complètement. Les utilisateurs, ils veulent que ça marche, pas que les contraintes d'intégrité référentiel soient gérées de telle ou telle façon. Désolé si c'est trop pragmatique mais c'est mon expérience.

                  Tu trouveras rarement un logiciel Java qui limite à une base de données (le seul que je connais c'est Oracle SQL Developer), c'est tout l'avantage de JDBC, Perl a DBI, python a SQLAlchemy, PHP a ses équivalents. Quand ils sont utilisé le coût de l'abstraction est nul. Les administrateurs (ceux qui installent ces solutions) sont sensibles à ça (et même free.fr propose Postgre).

                  Enfin ce que je voulais dire, c'est que je n'ai pas trouvé l'info du SGBD qu'ils utilisaient pour MediaGoblin. Enfin si, avec un peu plus de recherche, j'ai trouvé qu'ils utilisaient MongoDB, qui n'est pas un SGBD. Donc tu ne pourras pas utiliser PostgreSQL, mais à mon sens cela n'a rigoureusement aucune importance.

                  MongoDB est un SGBD, c'est juste pas un SGBDR. Oui du coup il n'y a pas de choix possible, mais en même temps ça n'existe pas encore d'abstraction autour des bases de données orientés document.

                  Encore une fois, je constate de manière empirique sur des exemples concrets (probablement pas assez nombreux pour en tirer une conclusion générale), mais lorsque j'ai fait tourner du Ruby On Rails ou du Python, le serveur avait vraiment du mal à suivre et la conséquence était une dégradation rapide de la qualité de service pour les visiteurs du site. Les applications équivalentes en PHP n'avaient quasiment pas d'incidence sur la consommation CPU/RAM du serveur.

                  Comme déjà dis tu es ici sur un site en Ruby on Rail qui est un peu plus léger que sa précédente version en PHP qui utilisait un moteur de template réputé très optimisé.

                  OK, alors effectivement ça change tout, ils visent une niche vraiment petite (pour le moment, dans 5 ans, ce sera peut-être la majorité)

                  Petite par rapport à quoi ? Ils cherchent à répondre à un besoin.

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

                  • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

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

                    Tiens je serais curieux de connaître ces optimisations.

                    On ne peut tout simplement plus utiliser des fonctionnalités spécifiques à MySQL. Il ne faut pas chercher plus loin que cela. Les grosses optimisations, c'est la capacité de faire de l'update en masse par exemple, mais ça ça marche bien avec PostgreSQL. J'explique l'algorithme dans un vieux billet sur mon blog http://le-gall.net/pierrick/en/blog/index.php?post/2007/11/29/108-mysql-bulk-update-with-talend-open-studio

                    Je me demande ce qui peut entraîner une tel incompatibilité.

                    Il suffit qu'un thème utilise un REPLACE INTO et hop, il n'est pas compatible avec PostgreSQL ou SQLite. On a des fonctions dans Piwigo pour simplifier ce genre de cas très basique de mise à jour d'une valeur de configuration en base de données, mais tous les développeurs de plugins/thèmes ne les utilise pas.

                    Disponibilité je comprends, mais libre, gratuit et performant il est loin d'être le seul.

                    Je me suis mal exprimé. Ce sont ses points forts, il n'est pas le seul à les avoir. Son réel avantage par rapport à PostgreSQL, c'est la disponibilité.

                    [a propos d'un changement vers MariaDB] Et ça sera une galère monstre
                    vu comme il semble difficile de gérer postgre actuellement

                    Non, je ne pense pas. Je serai étonné que les créateurs de MySQL, qui ont créé MariaDB suite au rachat Oracle il me semble, ne fassent pas en sorte que MariaDB soit syntaxiquement compatible avec MySQL (ou alors ce serait stratégiquement un peu bête...)

                    (on parle quand même d'un SGBD qui a était racheté par Oracle et
                    qui a connu au moins un fork plus quelques alternatives l'an dernier
                    juste à cause de ça).

                    Lors du rachat par Oracle, j'ai cru que les jours de MySQL étaient comptés et je me suis intéressé aux forks de l'époque. Et puis en pratique, rien n'a changé : cela reste libre et gratuit, disponible partout. A ma connaissance, le développement est aussi fermé qu'avant. Bref, pas de changement particulier. Donc pas de quoi s'inquiéter pour le moment.

                    Perl a DBI

                    J'ai quelques années de développement Perl derrière moi et je ne vois pas en quoi DBI fait de l'abstraction. DBI prend des requêtes SQL en entrée, donc potentiellement compatible avec un seul SGBD. On a strictement le même système dans Piwigo. Cela ne rend pas le code miraculeusement compatible avec tous les SGBD.

                    [à propos de la taille du public visé par MediaGoblin] Petite par rapport
                    à quoi ? Ils cherchent à répondre à un besoin.

                    Petite par rapport à Piwigo. Ce n'est pas péjoratif. J'espère bien qu'ils cherchent à répondre à un besoin (sinon c'est un peu du temps perdu ;-).

                    Je répète ce que j'ai dit dans un autre message : il y a 2 niveaux pour les "utilisateurs" de MediaGoblin à mon avis. D'abord ceux qui installent puis ceux qui ouvrent un compte. Ce ne sont a priori pas du tout les même profils. Dans le cas de Piwigo en revanche, celui qui utilise est aussi celui qui installe. Donc le public est assez différent je pense.

    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

      Posté par  . Évalué à -5.

      Il se veut une alternative mais quel nom ringard.

      Flickr, Picasa indique au moins la nature/orientation du service en plus d'être stylisé.

      Je vais presque finir par croire que l'existence de "marketeux" se justifie à force de voir des LL aux noms qui piquent les yeux.

      Ou que simplement, les libristes n'ont aucuns goûts, par exemple lorsqu'on prête attention aux noms des projets Walt Disney - jadis proprio - on ne peut nier le soucis d'originalité et de cohérence qui y a été porté*.

      • Ptex
      • Se-Expr
      • Reposado
      • Partio
      • Munki
      • Dynamica
      • Pythoscope

      Ça a tout de suite une autre gueule.

      *ça ne veut pas nécessairement dire qu'il y a eu 20 tempêtes de cerveaux™ derrière ^_-

      • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

        Posté par  . Évalué à 5.

        Les gouts les couleurs toussa... je ne trouve pas que Ptex soit plus joli que MediaGoblin par exemple.

        Et perso, pour ce qui est des logiciels Disney que tu cites, je n'ai franchement pas la moindre idée de leurs utilités respectives en regardant simplement leurs nom.

    • [^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop

      Posté par  . Évalué à 2.

      http://omgmg.dyndns.org:6543/

  • # gmic

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

    Pourquoi ne pas proposer un mode de traitement flottant pour le plugin gimp voir même un mode "quart de pixel" pour certaine fonction?

    "La première sécurité est la liberté"

    • [^] # Re: gmic

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

      C'est déjà le cas. Le plug-in travaille de manière interne avec des images flottantes. Le goulot d'étranglement provient du fait que les entrées-sorties de données images de/vers GIMP doivent se faire en 8 bits (limitation de l'API de GIMP). Tous les traitements effectués par les filtres de G'MIC utilisent donc des flottants, et peuvent même gérer des images volumiques.

      • [^] # Re: gmic

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

        Et l'interaction avec Krita ? (ça semble avoir déjà été abordé car j'ai vu un de tes posts).

        Car il me semble que celui-ci a moins de limitations pour ce qui concerne la résolution des images.

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

        • [^] # Re: gmic

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

          Oui effectivement, mais Krita se développe de telle façon que son architecture ne va probablement pas proposer d'API simple pour la création de plug-ins externes, ce qui implique que pour ajouter des fonctionnalités telles que celles proposées par G'MIC, il faudrait devenir un contributeur direct du projet Krita, et le rendre peut-être dépendant de G'MIC, ce qui ne me semble pas vraiment souhaitable (ni les développeurs de Krita d'ailleurs, ils utilisent déjà leur propre bibliothèque donc ça ferait des fonctionnalités doublons, et puis cela demanderait un temps important de développement sans être sûr qu'il soit finalement intégré au projet).
          Je trouve que le système de plug-in est idéal, car G'MIC forme un ensemble indépendant et complet qu'on peut donc théoriquement utiliser un peu partout (il suffit d'adapter les entrées-sorties des logiciels concernés).
          J'avais demandé à tout hasard sur la liste de dev de Krita, mais les quelques liens qu'ils m'ont donné me laisse l'impression que ça n'allait vraiment pas être facile, ni perenne, vu qu'ils sont en train de changer pas mal de choses sur leur architecture.
          J'ai essayé aussi de voir si je pouvais pas envisager de faire un plug-in pour Pinta, mais c'est du C#, et c'est pareil , ils n'ont pas vraiment prévu d'API pour faire des plug-ins.

          • [^] # Re: gmic

            Posté par  . Évalué à 0.

            Et avec digikam/showfoto ? C'est un logiciel très adapté pour la retouche photo sur 16 bits, qui supporte des modules externes (au moins Liquid Rescale et les kipi-plugins).

            • [^] # Re: gmic

              Posté par  . Évalué à 2.

              Il y a de plugins kipi qui utilisent gmic mais je ne sais pas quel version.

Suivre le flux des commentaires

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