Arg

• [^]Re: Arg

  Posté par imalip (page perso, ) le 25/04/2008 à 16:13. (lien). Évalué à 0.

  Tu peux toujours, pour le moment, il dit juste "un jour on distribuera". Ca reste donc a l'état de promesse, tout en confirmant que Launchpad a été a la base concu pour etre une plateforme centralisée.

  --
  "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

  [ Répondre ]

  • [^]Re: Arg

    Posté par IsNotGood () le 25/04/2008 à 16:46. (lien). Évalué à 2.

    > Tu peux toujours, pour le moment, il dit juste "un jour on distribuera". Ca reste donc a l'état de promesse
    
    Certes. M'enfin, il faut lire le thread. Au début Mark parle de Gobuntu. Puis au fil de la discussion vient le "problème" launchpad. Ça ne semble pas un coup marketing mais véritablement une prise de conscience du "problème".
    Mais t'as raison, et le titre du journal est juste : "Launchpad, enfin Libre ?"

    [ Répondre ]

    • [^]Re: Arg

      Posté par ribwund () le 25/04/2008 à 19:05. (lien). Évalué à 4.

      Genre il avait pas conscience du problème avant... Ça fait 3 ans au moins que il dit que tant que launchpad est pas indispensable il peut pas ouvrir le code sinon ca fragmenterait. Le but c'est d'être la plate-forme incontournable et de ne liberer que si aucun concurrent ne peut se mettre à l'égal.

      [ Répondre ]

      • [^]Re: Arg

        Posté par IsNotGood () le 25/04/2008 à 19:41. (lien). Évalué à 2.

        Ok, je vois l'idée.

        [ Répondre ]

        [^]Re: Arg

        Posté par herodiade () le 26/04/2008 à 11:29. (lien). Évalué à 4.

        > Ça fait 3 ans au moins que il dit que tant que launchpad est pas
        > indispensable il peut pas ouvrir le code sinon ca fragmenterait.
        >
        > Le but c'est d'être la plate-forme incontournable et de ne liberer
        > que si aucun concurrent ne peut se mettre à l'égal.
        
        Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.
        
        Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.
        
        En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.
        
        Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.
        
        Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.
        
        Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).
        
        Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.
        
        Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...

        [ Répondre ]

        • [^]Re: Arg

          Posté par IsNotGood () le 26/04/2008 à 11:42. (lien). Évalué à 4.

          Red Hat lance des projets (dont l'infrastructure Fedora) et met le tout en libre sans attendre que tout soit finaliser. C'est aussi ça le libre, partager/discuter/décider aussi lors de la concèption et avec tout ceux qui sont intéressés.
          Des exemples d'initiatives toutes fraiches :
          http://ovirt.org/
          http://freeipa.org/
          http://cobbler.et.redhat.com/
          http://cft.et.redhat.com/
          
          NB: on n'a pas vu de fork etc...

          [ Répondre ]

          [^]Re: Arg

          Posté par CrEv (page perso, ) le 26/04/2008 à 13:42. (lien). Évalué à 4.

          Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données,
          Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
          
          Moi ce que je me demande, c'est surtout s'il n'aurait pas été bénéfique, surtout en terme de temps, de passer sur un mode de développement ouvert tout de suite (y compris avec une roadmap stricte, c'est pas le problème) pour bénéficier justement de la "force de frappe" du libre : le nombre de développeurs.
          
          Si ce projet est si intéressant, alors il n'aurait pas eu de mal à trouver des développeurs pour s'y mettre et donc gagner du temps.
          
          Parce que tout ça, moi je le vois surtout comme une volontée de contrôle bien plus important que dans les autres distribs.
          Si je ne me trompe pas, la majorité des développements de red hat sont en open source, tous les dev de mandriva sont en gpl (pour novel, suse, je me prononcerai pas je ne sais pas)
          
          M'enfin tout ça pour dire que je suis content que launchpad se libère enfin mais je trouve très domage cette volonté constante d'emprisoner les utilisateurs / développeurs chez ubuntu, ce qui est à mon avis contraire aux intérêts et aux buts du Libre.

          [ Répondre ]

          • [^]Re: Arg

            Posté par Spyhawk () le 26/04/2008 à 19:14. (lien). Évalué à 3.

            [...] la majorité des développements de red hat sont en open source, tous les dev de mandriva sont en gpl (pour novel, suse, je me prononcerai pas je ne sais pas)
            
            Moi je sais, alors je réponds :)
            
            Tous les developpements et toute l'infrastructure d'openSUSE est libre (GPL) et disponible, tout le developpement est ouvert et accessible (mailing lists des dev, svn, etc.). Pour le côté SUSE Entreprise, seuls les correctifs (rpms binaires et sources) des correctifs ne sont pas disponible publiquement (au contraire de RH qui fournit les sources rpm).
            
            
            A noter, un exemple, qui ressemble _extrement_ au cas de Lauchpad de Canonical, est le Build Service d'openSUSE.
            
            Le Build Service à pour vocation de créer, de façon centralisée et simplifiée, des paquets RPM/DEB pour plusieurs distribution à partir du même code source (un seul fichier .spec). Il permet de lier des projets entre eux et d'augmenter l'interaction et le dynamisme des projets, pas forcément lié à la distribution openSUSE.
            
            Très récemment, une nouvelle fonction de distribution p2p est apparue (soit, exactement ce que Canonical veut/est en train d'implémenter) est disponible. On peut ainsi installer une version locale du Build Service et faire la synchronisation vers un autre Build Service.
            
            Dès le départ, les sources (en rpm/tar.gz) du Build Service étaient disponibles.
            
            Que Mark Shuttleworth prétende que Lauchpad est closed source pour le bien des projets est du foutage de gueule royal. Je pense que ce n'est que par la pression des "Libristes" (entre autres ceux de GoButuntu et GNewSense) que Shuttleworth va ouvrir les sources (bientôt? ça fait 2 ans qu'il nous sort la même salade), et que Launchpad a été pensé à la base comme pièce maitresse de la stratégie de Canonical pour se rendre indispensable.

            [ Répondre ]

    [^]Re: Arg

    Posté par zero heure (Jabber id, page perso, ) le 25/04/2008 à 20:11. (lien). Évalué à 3.

    The roadmap for Launchpad does get it to the point where it will more graciously handle that distributed nature, and at that point I will be more comfortable distributing it.
    
    je comprends peut-être mal, mais ne dit-il pas au contraire qu'il le distribuera quand il pourra être décentralisé?

    --
    J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm

    [ Répondre ]

    • [^]Re: Arg

      Posté par imalip (page perso, ) le 25/04/2008 à 21:32. (lien). Évalué à 4.

      Ouais, et ce sera decentralise quand ? Elle est ou la roadmap ? Le Monsieur a aussi dit a debconf "There is no behind the scene agenda, there is no ubuntu-private". Et que LP avait ete fait explicitement pour centraliser les infos faire en sorte qu'on passe par lui. Il faut croire quoi dans tout ca ?

      --
      "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

      [ Répondre ]

      • [^]Re: Arg

        Posté par ribwund () le 26/04/2008 à 14:58. (lien). Évalué à 1.

        Ptet qu'il a changé son business plan, mais bon à la base launchpad était très central dans ce plan, et un des moyens les plus prometteur de faire de l'argent (c'est un service qui peut se vendre pour les trucs proprietaires, le bugtracker universel, toussa).

        [ Répondre ]