Journal Le pragmatisme à la Torvalds, ou, Linux sur Github

Posté par (page perso) .
21
5
sept.
2011

Salut les trolls

oups :-)

Bon, je sais qu'on est pas vendredi, mais la news ne pouvait tout de même pas passer inaperçu à l'élite Free Software donc voici :
Linus Torvalds utilisé désormais github pour partager ses sources de Linux !

Il y aurait très vite matière à troller, mais bon faut dire que l'effet n'est que temporaire et est causé par le petit problème des serveurs de kernel.org.

Par contre, il est intéressant (finalement un peu comme l'histoire Bitkeeper) de voir que Linus choisi un outil qui fonctionne bien mais qui n'est pas libre plutôt qu'un outil libre qui fonctionnerait moins bien (bon je met au conditionnel car je n'en ai jamais utilisé, tels que gitosis).

Encore une victoire de l'Open Source sur le Free Software ?

++
Plop

note : d'aucun diraient par contre qu'une des raisons est qu'il fallait bien trouver des machines existantes, déjà installées, près à recevoir une charge de travail correct et que dans ce cas une solution toute faite indacloud s'avère sympa

  • # Service libre

    Posté par (page perso) . Évalué à  10 .

    Il ne faut pas mélanger service propriétaire (github) et logiciel libre (gitosis) c'est n'est comparable.
    Une bonne comparaison aurait été de dire que Linus aurait pu utiliser le service libre gitorious entre autre utilisé par Qt.

    D'ailleurs c'est à mon avis symptomatique du libre qui ne perçoit toujours pas l'intérêt des services et focalise sur les logiciels auto-hébergés ...

    http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

    • [^] # Re: Service libre

      Posté par (page perso) . Évalué à  4 .

      farpaitement raison, il est vrai que j'ai confondu gitosis et gitorious (donc relire en réalité le journal avec gitorious en tête).

      symptomatique du libre qui ne perçoit toujours pas l'intérêt des services et focalise sur les logiciels auto-hébergés

      Ha ben ça...
      Mais c'est aussi parce que service ça pause un problème : qui paie les machines, la bande passante, etc ?
      Faire un soft à héberger c'est "facile". Mettre en place une infra pour de la charge (de le vrai hein, pas 50 visites par jour), avoir de la redondance, du temps de rétablissement, toussa, ben ça coûte et même ça coûte très cher (et je parle pas d'offres de serveurs basiques).

      Donc l'intérêt, je pense que certains le voient, mais avoir les capacités de le faire c'est un autre problème.

      • [^] # Re: Service libre

        Posté par . Évalué à  8 .

        ça pause un problème

        Aïe, "ça pose un problème", du verbe poser, et non pas du verbe "mettre en pause [un problème]" :-) (qui serait d'ailleurs un néologisme).

        • [^] # Re: Service libre

          Posté par . Évalué à  10 .

          Il y a aussi (dans le journal) :

          Linus Torvalds utilisée
          Linus choisit un outil
          je mets au conditionnel
          d'aucuns diraient
          des machines existantes, déjà installées, prèêtes à recevoir

          • [^] # Re: Service libre

            Posté par (page perso) . Évalué à  -10 .

            Nan mai sérieu, vous vous relisé lorsque vous fêtes un journalle ?
            Moa pa toujour...

            (/me cours se planquer...)

            • [^] # Re: Service libre

              Posté par . Évalué à  9 .

              Je me relis toujours, quoi que j'écrive : un journal, un commentaire, un mail, un SMS...

              Le français (et n'importe quelle langue en fait) est un protocole de communication entre plusieurs personnes. Déjà que ce protocole est blindé de règles, d'exceptions à ces règles, de cas tordus, ... (à croire que c'est MS qui l'a écrit /o), si en plus on se met à tolérer des entorses dans la grammaire, l'orthographe, la conjugaison, c'est un coup à voir nos analyseurs syntaxiques partir en vrille !
              Bref, c'est un standard "de fait" merdique, mais on n'a pas trop le choix !

              /me milite pour l'usage d'un protocole de communication bien construit : l'esperanto !

        • [^] # Re: Service libre

          Posté par (page perso) . Évalué à  -3 .

          ça c'est parce que j'étais déjà en avance rapide du troll ORM ou non en PHP :-)

      • [^] # Re: Service libre

        Posté par (page perso) . Évalué à  4 .

        Désolé je pensais que tu avais volontairement mis l'accent sur gitosis. C'est juste que j'ai le sentiment que des linuxiens ne jurent que par l'auto-hébergement et que même des services libres seraient considérés comme "impurs"...

        Quant au coût qu'implique du service libre, l'infra n'est pas forcément gratuite : http://gitorious.com/subdomain/ http://gitorious.com/consulting/ http://shapado.com/plans http://status.net/packages , ...

        http://nodecast.github.com/ncs/ bitmessage : BM-2DCNWJomzSWRQ54WcuVGF7XvKEybhdmLJ9

        • [^] # Re: Service libre

          Posté par . Évalué à  3 .

          et que même des services libres seraient considérés comme "impurs"

          Désolé, mais je prends mon cas particulier, concernant l'utilisation d'indefero: je me sers des deux version, "service" et j'ai également quelques instances ici ou là.

          Ca me permets au contraire de vérifier la "pureté" du service ....

          • [^] # Re: Service libre

            Posté par (page perso) . Évalué à  2 .

            Ca me permets au contraire de vérifier la "pureté" du service ....

            Intéressant comme point de vue — je suis naturellement peu intéressé par les versions services de logiciels libres car il y a souvent des variations, ou qu'on se rend compte que le truc est une horreur à mettre en place. Ou pire, que même si c'est libre, comme on est pas maître de ses données (export/import possible facilement), on reste enfermé.

            DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: Service libre

              Posté par . Évalué à  2 .

              […] même si c'est libre, comme on est pas maître de ses données (export/import possible facilement), on reste enfermé.

              Ouai mais bon quand on parle de DCVS, on a de toute manière toutes les sources et leur versions sous le coude (je sais dans une forge il n'y a pas que ça).

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: Service libre

                Posté par (page perso) . Évalué à  2 .

                Tout à fait, c'est d'ailleurs pour ça que je me préoccupe peu de là où c'est hébergé dans ce cas. Par contre certains projets utilisent bien les autres services de Github (gestion de tickets, poule ricouèste, etc.).

                DLFP >> PCInpact > Numerama >> LinuxFr.org

                • [^] # Re: Service libre

                  Posté par (page perso) . Évalué à  2 .

                  Mais Github utilise beaucoup Git, même pour les choses autres que l'hébergement de sources. Par exemple, on peut faire un "git clone" de son wiki, et un "git push" ailleurs (le moteur de wiki est open-source). Pour le bugtracking, je ne sais pas si c'est facile de récupérer ses données et de les réutiliser ailleurs par contre.

      • [^] # Re: Service libre

        Posté par . Évalué à  10 .

        Faire un soft à héberger c'est "facile". Mettre en place une infra pour de la charge...

        Oui, mais le raisonnement est biaisé étant donné la situation actuelle.

        L'Interweb propriétaire a pour conséquence que les gens ont des logiciels et des accès Internet peu conçus pour héberger des données: NAT, filtrage de tout sauf le Web, IPv6 peu répandu, parefeu bien restrictif sur le Windows..

        Parce que bon: le modèle collaboratif du libre, appliqué à Internet, c'est le P2P. Ça voudrait dire que, pour proposer un système "libre" d'hébergement de code, on le ferait héberger par chaque personne qui en récupère une copie. Avec la même hiérarchie que pour un projet libre: une poignée de contributeurs/seeders qui investissent du temps/de la bande passante, pas mal d'amateurs plein de bonne volonté qui rapportent les bugs/seedent avec leur ADSL, et une longue traîne d'utilisateurs anonymes/de leechers. Et ça marcherait pas trop mal.

        Faire du service Internet libre, ça peut aussi impliquer aussi de décentraliser une partie du calcul sur les clients et de demander à l'utilisateur de faire un petit effort d'adaptation.

        Exemple pour illustrer ce dernier point, héberger un Etherpad demande de la puissance CPU (java), pas mal de bande passante, de la maintenance.. bref, c'est une appli Web lourde. L'utilisateur final se contente de lancer son navigateur et de mettre à genoux le serveur.

        Il suffit de passer à Gobby pour diminuer les contraintes sur le serveur et rendre l'installation/administration plus aisées. En contrepartie, l'utilisateur final devra installer le client "lourd" et sortir sur un autre port que le 80..

        Comparer "service" et "logiciel" sous l'angle des libertés n'est pas très judicieux dans le contexte actuel des usages d'Internet.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Service libre

          Posté par . Évalué à  5 .

          Faire un soft à héberger c'est "facile". Mettre en place une infra pour de la charge...

          pas mal d'amateurs plein de bonne volonté qui rapportent les bugs/seedent avec leur ADSL, et une longue traîne d'utilisateurs anonymes/de leechers. Et ça marcherait pas trop mal.

          Si pour toi, mettre en place une infra qui marche et soit capable de tenir la charge de kernel.org , c'est faire joujou avec de l'autohebergement ... c'est pas gagné ;)

        • [^] # Re: Service libre

          Posté par . Évalué à  0 .

          Les systèmes de "cloud distribué" libres — parce qu'au final ça revient à ça —, ça existe déjà! cf SlapOS.org.

    • [^] # Re: Service libre

      Posté par (page perso) . Évalué à  9 .

      D'ailleurs c'est à mon avis symptomatique du libre qui ne perçoit toujours pas l'intérêt des services et focalise sur les logiciels auto-hébergés ...

      Vraiment? Quand j'installe un apache ou un ejabberd, la documentation s'adresse à des admins de gros parcs, pas à un gus qui monte un serveur dans un coin...

      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

  • # Et si...

    Posté par . Évalué à  2 . Dernière modification : le 05/09/11 à 19:24

    ...au final le but n'était pas la compromission des serveurs ou des sources mais les conséquences et autres effets de bords :

    • 400 développeurs vont changer leurs clés
    • ré-installation complète des serveurs
    • linus sur github

    Dans tout ce bordel des fausses manips ne sont pas impossibles et ça peut faire mal.

    • [^] # Re: Et si...

      Posté par . Évalué à  -5 .

      c'est quoi encore ce bordel avec les listes à puce ! J'ai pourtant utilisé des "*".

      Le parser qui traite la syntax est une vraie merde ou quoi ?

      • [^] # Re: Et si...

        Posté par (page perso) . Évalué à  5 .

        Le parser qui traite la syntax est une vraie merde ou quoi ?

        Non, mais il faut laisser une ligne pour avant la liste à puces.

      • [^] # Re: Et si...

        Posté par (page perso) . Évalué à  4 .

        D'où l'utilité du bouton "Prévisualiser" ;-)

        • (sinon, oui, Markdown machin chose, c'est incompréhensible pour le commun de mortels)
        • [^] # Re: Et si...

          Posté par (page perso) . Évalué à  7 . Dernière modification : le 05/09/11 à 21:15

          Aide-Edition est si incomplet que ça, que les commentateurs de LinuxFr (bon, ok, pas forcément le « commun des mortels ») n'ont pas tout en main pour utiliser un simple langage de wiki ?

          question subsidiaire : mais comment font les contributeurs de wikipedia ? (dont je trouve le langage un cran plus abscons, que ce soit pour les liens, les listes à puce, les encarts de version de logiciel... même si je m'y adapte, hein :D).

          • [^] # Re: Et si...

            Posté par (page perso) . Évalué à  7 .

            Aide-Edition est si incomplet que ça,

            Certains (dont moi :) ) te répondront que de nos jours, à partir du moment où il y a besoin d'une page d'aide, c'est qu'il y a un problème. Surtout quand le bouton "liste" ne met pas cette ligne vide.

            Juste pour mémoire : dans l'aide-mémoire, il est indiqué comment faire des listes à puce, sauf qu'il manque "attention c'est con mais c'est comme ça, faut mettre une ligne vide avant".

            question subsidiaire : mais comment font les contributeurs de wikipedia ?

            Ils quittent Wikipedia ;-).
            Plus sérieusement, le fait de ne pas avoir de WYSIWYG, est une barrière qui me semble connue même pour Wikipedia. Wikipedia vit avec, certes, mais il y a une sacré différence entre le nombre de lecteurs et le nombre de rédacteurs (ce n'est pas que à cause de la syntaxe Wiki, je sais, mais ça ne doit pas aider).

            Et sinon, Wikipedia n'utilise pas Markdown, donc bon, c'est bien la le soucis : on a 50 langages "wiki" différents, vachement pratique, faut se coltiner les bizarretés de chaque langage. Après, ben LinuxFr fait comme il veut, je moule toujours quand même ici mais en "version texte simple".

            Note que je sais que c'est pas simple, par exemple avec HTML je me passe de WYSIWYG qui fait du HTML illisible, pour faire de l'édition de texte à la mano. Pas de solution parfaite.

            • [^] # Re: Et si...

              Posté par (page perso) . Évalué à  3 .

              Surtout quand le bouton "liste" ne met pas cette ligne vide.

              moui, ça c'est sans doute un bug, à ouvrir ; je n'utilise pas cette barre (pour moi, la syntaxe est plus simple au clavier, plutôt que de prendre la souris pour atteindre cette barre quand je tape mon commentaire)

              sauf qu'il manque "attention c'est con mais c'est comme ça, faut mettre une ligne vide avant".

              oui, je l'avais déjà indiqué à NoNo< ; à défaut, il y a la précision « penser à mettre une ligne blanche avant pour les utiliser » dans Aide-Edition justement.

              Et sinon, Wikipedia n'utilise pas Markdown, donc bon, c'est bien la le soucis : on a 50 langages "wiki" différents, vachement pratique

              Entre wikkawikki, wikini, dokuwiki, Twiki, tikiwiki, MoinMoin, PmWiki, trac, le wiki de github, Markdown de LinuxFr, je n'ai pas trop de souci... je m'adapte, un peu comme les langages de programmation. Avec mediawiki, j'ai souvent un souci :/ (surtout les liens, un peu les listes à puces, d'où l'utilisation de la pré-visualisation).

              Je ne commenterai pas plus le wysiwyg, celui de drupal m'ayant quasiment définitivement fâché avec ce mode d'édition (pour ceux qui ont un drupal, essayer sur des textes de 10000 caractères, un peu comme les dépêches kernel, à s'arracher les cheveux de ne pas pouvoir le désactiver tant c'est lent et que ça ne fait pas ce que ça devrait ; et, à se flinguer, quand ceux qui l'ont demandé à cors et à cris indiquent qu'ils le trouvent inutilisable, 'fin un nième argument pour rien foutre quoi :/ rha, je suis adepte de la prétérition moi /o\).

            • [^] # Re: Et si...

              Posté par . Évalué à  -10 .

              Ils quittent Wikipedia ;-)

              Les gens incapables de faire l'effort intellectuel d'apprendre un nouvel outil, et n'ayant pas l'intelligence pour maîtriser un langage un tout petit peu abstrait, je préfère qu'ils ne contribuent pas à Wikipedia...

              • [^] # Re: Et si...

                Posté par . Évalué à  7 .

                Je suis mais alors pas du tout sur que la qualité (potentielle) du contributeur dans son domaine soit corrélée avec son envie d'apprendre l'outil.

                En tout cas je suis pas du tout certain que de nos jours le nombre d'édition wikipedia soit vraiment à son plus haut niveau. Dommage de laisser une telle barrière si elle est un frein à des utilisateurs qui ont quelque chose à apporter au contenu et pas simplement une maîtrise de wikipedia (la technique pure mais aussi les rouages internes qui ne doivent pas être simple a saisir pour le simple contributeur)

                • [^] # Re: Et si...

                  Posté par . Évalué à  -1 .

                  En tout cas je suis pas du tout certain que de nos jours le nombre d'édition wikipedia soit vraiment à son plus haut niveau. Dommage de laisser une telle barrière si elle est un frein à des utilisateurs qui ont quelque chose à apporter au contenu et pas simplement une maîtrise de wikipedia.

                  Je suis d'accord mais faut pas rêver, il y aura toujours les contributeurs, capables de maîtriser l'outil en plus de leur domaine de compétences, et les autres. Le wikiwikiweb, bien qu'une petite révolution, ne change rien à cela. Il y aura toujours certains intermédiaires pour propager le savoir.

                  Il y a trois siècle, si un jardinier analphabète et solitaire pouvait partager son savoir avec ne serait-ce qu'une centaine de gens, c'est qu'une personne l'avait interrogé et avait transcrit ses propos, à l'aide d'outils tels que la grammaire française, dont on pourrait comparer la complexité à celle d'un dialect wiki... Qu'une personne ensuite avait imprimé un livre. Oh ! Mais peut-être cette personne avait déjà un domaine de compétence avant d'apprendre les techniques d'imprimerie... Bref, je suis d'accord avec toi, c'est dommage que certaines personnes ne souhaitent/puissent/veuillent pas apprendre la syntaxe wikipedia alors qu'elles sont par ailleurs de véritables puits de science. Mais c'est comme ça. LE WYSIWYG ne changera absolument rien. C'est toujours un savoir de plus, et pas forcement meilleur qu'une simple syntaxe, qu'il faudra maîtriser.

                  • [^] # Re: Et si...

                    Posté par . Évalué à  6 .

                    Tu as la fierté déplacée de quelqu'un qui tire gloire de simplement savoir maîtriser un outil, ce qui n'est pas une fin pour le commun des mortels.

                    Ce qui est important dans wikipedia, ce n'est pas la syntaxe wiki.

                    • [^] # Re: Et si...

                      Posté par . Évalué à  1 .

                      J'ai bien dit qu'il fallait maîtriser l'outil et le ou les domaines de compétences auxquels on souhaite contribuer.

                      Je maîtrise les bases de la syntaxe wiki mais je ne maîtrise pas la photographie ou d'autres langues étrangères, ou les rouages internes (politiques) de wikipédia, ou encore le dessin et la mise en page. Je ne pourrai pas contribuer à ces niveaux (sauf si j'apprends...) c'est peut-être en peu dommage mais c'est comme ça.

                      Wikipedia a ses défauts mais les on peux mieux faire et c'est pas au top pour un projet aussi réussi c'est un peu gros.

                      Ce qui est important dans wikipedia, ce n'est pas la syntaxe wiki.

                      Si quand même. C'est bien le concept de wiki qui a permis cet essor aussi rapide.

                      Sinon pour en revenir à github et à la compromission d'un serveur de kernel.org : Est-ce que ce ne pourrait pas être un contributeur, qui se voyant refuser nombre de ses patches car il ne maîtrisait pas assez les règles d'écriture du code ou bien les rouages internes de la communauté des contributeurs principaux, soit devenu aigri et ait lui même attaqué le serveur en question ? Saura-t-on quelle clé a servi à l'attaque ?

                      Et github n'est surement qu'un solution temporaire.

                      • [^] # Re: Et si...

                        Posté par . Évalué à  2 .

                        Le truc important du wiki c'est pas la syntaxe, c'est l'édition collaborative. La syntaxe de ce point de vue c'est un détail d'implémentation.

                        • [^] # Re: Et si...

                          Posté par (page perso) . Évalué à  5 .

                          La syntaxe wiki permet de faire des diff propres, ce qui est très important dans Wikipédia pour suivre l'évolution d'un article, particulièrement avec le nombre de « vandales » qui peuvent arriver avec l'édition anonyme. De plus elle est facilement lisible.

                          C'est bien pour ça que le WYSIWYG serait une mauvaise idée.

                          DLFP >> PCInpact > Numerama >> LinuxFr.org

                          • [^] # Re: Et si...

                            Posté par . Évalué à  1 .

                            Je vois pas d'obstacle à garder la syntaxe wiki pour le stockage des articles, ça change rien.

                            Je dirai même que pour les diff un "vrai" éditeur pourrait être plus malin et garder trace des déplacement de paragraphe par exemple, ce que l'outil de diff fait assez salement en alignant bêtement les textes.

                            • [^] # Re: Et si...

                              Posté par (page perso) . Évalué à  2 .

                              Parce que les WYSIWYG ont tendance à faire du gros caca.

                              Quand on voit ceux qui se vantent pourtant d'être bien sur ce point, ça fait peur : https://imgur.com/1nZfG

                              DLFP >> PCInpact > Numerama >> LinuxFr.org

                              • [^] # Re: Et si...

                                Posté par . Évalué à  4 .

                                Le problème que je suppose avec Mashable est que le WYSIWYG génère directement une sortie qui est utilisée par le navigateur, or le code pour le navigateur est souvent très laid en raison des compatibilités et du fait que HTML+CSS est une usine à gaz extrêmement laide.
                                Un WYSIWYG pourrait au contraire générer du Markdown (un exemple) qui est minimaliste, qui serait donc bien plus facilement propre. Ce Markdown serait stocké, et l'horrible génération en HTML+CSS pourrait se faire uniquement pour le navigateur au dernier moment.

                              • [^] # Re: Et si...

                                Posté par . Évalué à  2 .

                                Dans le cadre d'une syntaxe assez pauvre comme celle de wikipedia il y a moyen d'éviter ces travers amha.

                                Paragraphes, listes, figures, niveaux de titres, tableaux pour une édition basique.

                                Les trucs un peu plus complexes comme les modèles sont probablement largement plus embêtants à gérer cela dit.

                              • [^] # Re: Et si...

                                Posté par (page perso) . Évalué à  -7 .

                                Parce que les WYSIWYG ont tendance à faire du gros caca.

                                Une implémentation (ou plusieurs) est mauvaise fait que le principe est mauvais?

                                • [^] # Re: Et si...

                                  Posté par (page perso) . Évalué à  3 .

                                  Le fait qu'il n'y a pas de couple diff/wysiwyg corrects disponibles justifie le choix de ne pas en faire sur Wikipédia. C'est ça et uniquement ça.

                                  Ce choix est fait « parce que c'est techniquement mieux », et dire ouinouin madame michu c'est de l'intégrisme. Surtout que tu peux éditer Wikipédia sans connaître la syntaxe complète (ma mère a corrigé des fautes par exemple, et elle ne la connaît pas du tout). Et pour le reste, il y a en plus une barre d'outil qui permet d'ajouter les symboles les plus communs : pas besoin de les retenir !

                                  Bref j'ai l'impression que les gens ici parlent une fois de plus de ce qu'ils ne comprennent pas, et qu'ils ne doivent pas vraiment contribuer à Wikipédia.

                                  DLFP >> PCInpact > Numerama >> LinuxFr.org

                                  • [^] # Re: Et si...

                                    Posté par . Évalué à  3 .

                                    wikimedia édite ses propres outils non ? Et on parle principalement d'éditeur wisiwyg pour l'édition ici, pas pour le diff.

                                    • [^] # Re: Et si...

                                      Posté par (page perso) . Évalué à  3 .

                                      wikimedia édite ses propres outils non ?

                                      Oui, et ils devraient ne plus rien faire tant qu'ils ont pas révolutionné le monde du WYSIWYG, en supposant même que ce soit possible ? On se demande où sont les intégristes.

                                      Et on parle principalement d'éditeur wisiwyg pour l'édition ici, pas pour le diff.

                                      Tu n'as toujours rien compris ? Je me tue à expliquer que c'est lié.

                                      DLFP >> PCInpact > Numerama >> LinuxFr.org

                                      • [^] # Re: Et si...

                                        Posté par . Évalué à  2 .

                                        Tu n'expliques rien du tout, tu balance seulement wysiwig = code crade.

                                      • [^] # Re: Et si...

                                        Posté par . Évalué à  3 .

                                        Sinon curieusement il y a une page dédiée chez mediawiki. Il semble que les problèmes ne soient pas ceux que tu énonces.

                                        http://www.mediawiki.org/wiki/WYSIWYG_editor

                                      • [^] # Re: Et si...

                                        Posté par . Évalué à  3 .

                                        Il y a déja des trucs très intéressants, par exemple http://allievi.sssup.it/jacopo/mwsvn/index.php?title=Sandbox&action=edit

                                        C'est loin d'être parfait mais on sent du potentiel.

                                      • [^] # Re: Et si...

                                        Posté par (page perso) . Évalué à  2 .

                                        Oui, et ils devraient ne plus rien faire tant qu'ils ont pas révolutionné le monde du WYSIWYG,

                                        Personne n'a dit ça. Ils font comme ça, et ça a bien marché pendant un moment. C'est bien qu'il aient pu faire sans.
                                        On dit juste que ça élimine l'accès à un plus large panel de gens.

                                        Et on parle principalement d'éditeur wisiwyg pour l'édition ici, pas pour le diff.
                                        Tu n'as toujours rien compris ? Je me tue à expliquer que c'est lié.

                                        Tu n'as toujours rien compris ? On se tue à expliquer que e n'est pas lié, le format de stockage pouvant être complètement différent de la façon de présenter. d'ailleurs, c'est utilisé ailleurs ce système : on lit des lettres, alors que des 0 et des 1 sont stockés. Ben on peut très bien présenter en WYSIWYG et stocker en syntaxe wiki.

                                        On peu, c'est pas fait, je sais. Mais le fait que ce ne soit pas fait ne veut pas dire que c'est pas possible.

                                      • [^] # Re: Et si...

                                        Posté par . Évalué à  2 .

                                        Marrant ce que tu dis, confluence a un wysiwyg et pourtant utilises une syntaxe wiki.
                                        Le wiki genere n'a rien de crade.

                                        Apres, si tu te bases sur un screenshot (!) de l'output d'un soft adobe cense creer du contenu tres riche et dynamique, sans meme savoir ce que le mec a la base a fait, pour affirmer que le wysiwyg de wiki statique genere du code crade, on va aller tres loin.

                                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                    • [^] # Re: Et si...

                                      Posté par (page perso) . Évalué à  2 .

                                      Les outils wysiwyg en html sont très liés aux navigateurs. En fait, les éditeurs wysiwyg sont de simples interfaces à une API proposée par les navigateurs.

                                      Rentre ça dans la barre d'url de ton navigateur javascript:document.body.contentEditable=true et tu pourras modifier la page courante.

                                      Le problème, c'est que les navigateurs génèrent un code horrible, voir très horrible. Il est envisageable que la situation s'améliore un jour, mais il restera toujours des navigateurs pour massacrer tout un article même si on remplace juste une lettre.

                                      La plupart des bons éditeurs wysiwyg intègrent un lot d'astuces pour améliorer le code, mais je ne pense pas que ces éditeurs soient matures pour une encyclopédie.

                                      Envoyé depuis mon lapin.

                          • [^] # Re: Et si...

                            Posté par (page perso) . Évalué à  1 .

                            C'est bien pour ça que le WYSIWYG serait une mauvaise idée.

                            Ton argument a juste absolument rien à voir. Il y a une différence entre l'interface homme machine et le format de stockage.

                        • [^] # Re: Et si...

                          Posté par . Évalué à  3 .

                          Kaum là gramèr é lautografe ?

                          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: Et si...

                Posté par . Évalué à  4 .

                Je peux prendre l'exemple de mes grands-parents qui se sont mis à l'informatique à 75 ans et qui sont incapables de participer à Wikipedia. Pourtant ils en auraient des choses interessantes à dire sur l'histoire du Béarn et des Pyrénées (droit d'aînesse qui s'appliquait aux femmes, l'histoire de la place Verdun à Pau …).

                • [^] # Re: Et si...

                  Posté par . Évalué à  -7 .

                  Peut-être qu'il n'ont pas cherché à contribuer même s'ils avaient compris le principe. Il préfèrent peut-être utiliser leur temps sur l'outil informatique pour d'autres choses que contribuer au savoir de l'humanité toute entière[1]. Pour aller dans le cliché : pour communiquer par mail et faire de la visioconférence avec leur dernier petit-enfant de 4 mois et demi.

                  Mais si de leur apprentissage des bases du langage wiki avait dépendu quelque chose de vraiment important pour toi, n'auraient-ils pas été capable de maîtriser ces bases ? Si ça avait été leur seul choix ? Si bien sûr ils ont été à l'école un minimum et qu'ils, ce que je leur souhaite, n'ont pas le cerveau qui est parti en sucette.

                  [1] Je suis persuadé que cette vocation s'estompe avec l'âge...

                  • [^] # Re: Et si...

                    Posté par (page perso) . Évalué à  6 .

                    Il préfèrent peut-être utiliser leur temps sur l'outil informatique pour d'autres choses que contribuer au savoir de l'humanité toute entière[1]. Pour aller dans le cliché : (...)

                    Oui dans le cliché. Bien pourri aussi.
                    Pourquoi les "vieux" de 75 ans auraient moins envie que les "jeunes" de 20 ans?
                    Pourquoi les arguments bidons que tu sors s'appliquent aux vieux et pas aux jeunes? Les jeunes n'ont pas de vie au point de ne pas avoir d'amis et avoir seulement Wikipedia à faire?

                    Si bien sûr ils ont été à l'école un minimum et qu'ils, ce que je leur souhaite, n'ont pas le cerveau qui est parti en sucette.

                    Rien que ça... Ou alors, c'est juste toi qui connait rien. Parce que les vieux, ils en ont certainement plus que toi comme apprentissages de choses, et pourraient te dire aussi "pas be bras, pas de chocolat" comme seule réponse plutôt que "pas de bras, attend on va adapter".

                  • [^] # Re: Et si...

                    Posté par . Évalué à  4 .

                    Le principe ils l'ont compris et trouvent ça génial (ma grand-mère était instit).

                    contribuer au savoir de l'humanité toute entière[1]

                    Vu qu'ils adorent raconter l'histoire de leurs vallées à tout le monde, ils auraient bien contribué. Ils arrivent à envoyer des mails qui ressemblent à des lettres, mais le chat et la visioconf ce n'est vraiment pas ça.

                    n'auraient-ils pas été capable de maîtriser ces bases ?

                    Est-ce que tu as déjà travaillé avec des personnes âgées qui n'avaient jamais vu un ordinateur de leurs vies ? Ce sont des personnes qui ont déjà du mal à comprendre pourquoi est-ce que l'on peut faire un copié-coller avec le menu édition, le clic droit et avec un raccourci clavier. Alors comprendre la syntaxe d'un wiki …

                    • [^] # Re: Et si...

                      Posté par (page perso) . Évalué à  2 .

                      Et s'ils avaient pu contribuer, leurs contribution se serait fait rejetée parce qu'elle manquait de source fiable. Ça n'aurait donc rien changer à la situation.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Et si...

                  Posté par . Évalué à  4 .

                  oui mais s'ils n'ont pas de sources fiables pour prouver leurs dires, wikipedia refusera d'héberger leur savoir, ce n'est pas un bug mais une fonctionnalité parait-il.

                  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: Et si...

                    Posté par . Évalué à  -2 .

                    Un témoignage audio, enregistré en public, d'une personne reconnu pour avoir un forte probabilité de connaître le sujet pour lequel elle s'exprime, est à mon avis une source sinon fiable, considérable.

                    • [^] # Re: Et si...

                      Posté par . Évalué à  7 .

                      L'interview de personnes ayant directement vécu les évènements qu'ils décrivent n'est pas une source fiable pour Wikipédia. Voir WP:Travaux inédits et WP:SOURCES

                      Wikipédia n'exige aucune compétence, expertise, diplômes... pour participer à un sujet. Les opinions personnelles et idées nouvelles ne sont pas autorisées. Des livres de spécialistes doivent être cités à la place. D'autant plus pour l'Histoire, où chacun pense être compétent pour parler des choses qu'il a vécues, sans pourtant avoir jamais étudié la méthodologie de la science historique (à l'inverse de la physique des particules, où la plupart des gens savent reconnaitre qu'ils n'y connaissent pas assez pour écrire tout seuls un article d'encyclopédie sans utiliser un livre spécialisé comme source).

                  • [^] # Re: Et si...

                    Posté par . Évalué à  1 .

                    Je ne pensais pas à leurs histoires, c'est juste qu'ils ont lu énormément de bouquin d'histoire et qu'ils font pas mal de généalogie et donc ont lu énormément d'acte de notaires.

              • [^] # Re: Et si...

                Posté par (page perso) . Évalué à  3 .

                Les gens incapables de faire l'effort intellectuel d'apprendre un nouvel outil, et n'ayant pas l'intelligence pour maîtriser un langage un tout petit peu abstrait, je préfère qu'ils ne contribuent pas à Wikipedia...

                Si les gens ne sont pas capables d'utiliser des feuilles perforées (utiliser une ligne de commande est déjà faciliter trop les choses) pour utiliser un ordinateur, je préfère qu'il n'utilise pas un ordinateur... Attend, si, je préfère les avoir car sinon il y aurait 10 contributeurs de Wikipedia qui n'auraient jamais fait d'encyclopédie.

                Bref : argument élitiste tout pourri. Ce qui est intéressant dans les contributeur Wikipédia, c'est leur connaissances, pas leur envie d'apprendre un langage utilisé à de très rares endroits, surtout quand on peut faire plus simple.

                Le seul hic dans ton raisonnement est que les gens peuvent apprendre, mais n'on pas forcément envie de se faire chier à apprendre surtout quand il faut se coltiner 10 langage "un peu abstrait" différents quand on peut faire plus simple (on est bien passé de la feuille perforée à la ligne de commande, puis à l'interface graphique, avec ta logique on serait resté à la feuille perforée car c'est juste un langage un peu plus abstrait à apprendre et qu'il faut donc mériter)

            • [^] # Re: Et si...

              Posté par . Évalué à  0 .

              Certains (dont moi :) ) te répondront que de nos jours, à partir du moment où il y a besoin d'une page d'aide, c'est qu'il y a un problème.

              • Pas faux ^^
          • [^] # Re: Et si...

            Posté par . Évalué à  2 .

            Aide-Edition est si incomplet que ça

            Oui. Par exemple il n'est pas indiqué comment souligner un mot.
            Ni comment insérer des lignes vides (bien pratiques pour séparer des blocs sans rapport entre eux). Et d'autres choses auxquelles je ne pense pas.

             

             

             

            note: l'astuce pour les lignes vides est de mettre un &nbsp; en début de ligne

    • [^] # Re: Et si...

      Posté par . Évalué à  4 .

      Est-on au moins certains que c'est bien Linus, et pas une tentative foirasse de pousser tout le monde à pull-er un dépôt corrompu? ;)

  • # déçu je suis

    Posté par (page perso) . Évalué à  5 .

    Etrange, assez peu de réactions (si on enlève le blabla autour de wikipedia / syntaxe wiki).
    Vraiment, je ne comprend pas. Il n'y a pas si longtemps, lorsque quelqu'un posait les sources d'un logiciel libre sur github on lui faisait comprendre que github c'est pas libre, que c'est le mal, que c'est git mais que c'est quand même pas bien. Qu'il vaut mieux utiliser gitorious, ou l'héberger sur sa machine, etc. Et ce même pour un projet de 2 gars dans un garage.
    Et là, c'est juste les sources de Linux qui sont sur github. Et ça n'a l'air d'intéresser personne.

    • Est-ce parce que github est juste mieux que tous les autres ?
    • Est-ce parce que finalement du moment qu'on peut accéder aux données la forge on s'en fiche ? (l'avantage des DCVS et de leurs clones)
    • Est-ce parce que quelque soit le type de projet tout le monde fini tôt ou tard sur github, même dans le monde open source ?
    • [^] # Re: déçu je suis

      Posté par . Évalué à  7 .

      Un mélange de tout ça je pense ... github est une plateforme assez populaire de nos jours, pas tant trollesque que ça. Sourceforge l'a été bien plus vu de ma lorgnette.

      Linu(x/s) a été bien plus loin dans l'utilisation d'outils de gestion de version, pas libres du tout pour le coup, et on a vu que le problème (pratique) avait été principalement la non interopérabilité de l'outil avec d'autres gestionnaires de version ... là c'est un DVCS libre, et github n'est qu'un simple hébergeur.

    • [^] # Re: déçu je suis

      Posté par (page perso) . Évalué à  4 .

      Est-ce parce que github est juste mieux que tous les autres ?

      clairement oui. Github est vraiment au top pour favoriser les contributions, et donc favoriser le développement de logiciels... libres. le système de code review, les pull request et cie, c'est tout simplement bien foutu. gitorious est loin derrière en terme de fonctionnalité.

      Tient, d'ailleurs, il n'y a qu'à regarder https://github.com/torvalds/linux/network pour se rendre compte que github est apprécié. Fini les patchs ou pull request par email. En un clic, tu demandes un merge. En deux-trois cliques, tu intègres une contribution dans ton dépôt, sans taper une ligne de commande.

      Tout le processus de développement peut être géré par github, tout est intégré. Ça améliore clairement la productivité, et je dirais même, ça améliore l'ouverture.

      Alors oui, le code de github n'est pas libre, mais je peux récupérer mes données sans problème, que ce soit le wiki, les issues ou autre. Leur API est plutôt complète.

      • [^] # Re: déçu je suis

        Posté par (page perso) . Évalué à  4 .

        Mais dans ce cas, pourquoi ne pas utiliser gitorious par exemple ? Github est-il vraiment meilleur que gitorious ? (je n'utilise ni l'un ni l'autre donc j'ai pas d'avis dessus...)

        Fini les patchs ou pull request par email. En un clic, tu demandes un merge. En deux-trois cliques, tu intègres une contribution dans ton dépôt, sans taper une ligne de commande.

        {HS}
        Est-ce pour ça que tu as passé jelix sous git ? Je veux dire, est-ce en partie pour github ? (j'avais d'autant plus l'impression que tu étais plutôt un défenseur de mercurial). Si le même type d'outil existait pour hg serais-tu partis pour github ? Bitbucket ne fait d'ailleurs pas tout ça ?
        (c'est un peu HS, mais peut-être as-tu un avis)
        {/HS}

        Mais avec les réponses, je note surtout avoir l'impression que c'est pas si important grâce aux DCVS qui permettent de changer de fournisseur n'importe quand. Et ce serait mine de rien une sacré évolution.

        • [^] # Re: déçu je suis

          Posté par (page perso) . Évalué à  3 .

          Franchement, pour avoir pas mal browsé sur gitorious dans les sources de Qt, je préfère très largement Github: la recherche est mieux foutue, la présentation est bien plus claire, tu peux avoir des logs plus facilement sur un fichier, et pas seulement sur un commit, etc.

          Gitorious est sympa, mais très en dessous de GitHub, AMHA.

        • [^] # Re: déçu je suis

          Posté par (page perso) . Évalué à  3 .

          Mais dans ce cas, pourquoi ne pas utiliser gitorious par exemple ? Github est-il vraiment meilleur que gitorious ?

          Oui c'est ce que j'ai expliqué. De mon point de vue, Github est beaucoup mieux foutu que gitorious.

          Est-ce pour ça que tu as passé jelix sous git ?Je veux dire, est-ce en partie pour github ? (j'avais d'autant plus l'impression que tu étais plutôt un défenseur de mercurial). Si le même type d'outil existait pour hg serais-tu partis pour github ? Bitbucket ne fait d'ailleurs pas tout ça ?

          Je suis passé à Git, pour deux principales raisons : la gestion des branches de git, plus souple que Mercurial, et pour Github (pour les détails, voir mon blog http://ljouanneau.com/blog/post/2011/09/01/Jelix-de-Mercurial-a-Git ). J'ai en effet une préférence pour Mercurial, plus simple d'utilisation pour pas mal de chose, pour son extension MQ etc. Mais au niveau des branches, c'est moins souple. Bitbucket est pas mal, mais évolue moins vite que Github, et est un peu moins "sexy". J'ai attendu le code review dans Bitbucket depuis des lustres, et ce n'est jamais venu.

          Donc je suis allé voir ailleurs, et github propose tout ce que je veux, en mieux.

          Mais avec les réponses, je note surtout avoir l'impression que c'est pas si important grâce aux DCVS qui permettent de changer de fournisseur n'importe quand

          Tout à fait. Passer de Bitbucket à Github a pu se faire facilement grâce à hg-git qui m'a permis de convertir mon dépôt hg vers git. Et si demain gitorious dépasse Github, je n'aurais pas de souci à aller voir du coté de gitorious.

          • [^] # Re: déçu je suis

            Posté par (page perso) . Évalué à  2 .

            Ha, la gestion des branches !

            En tout cas ça fait plaisir de voir des migrations hg -> git pour cette raison.
            Je me souviens que, lorsque j'ai eu a choisir un DCVS pour ma boite, le problème des branches existait. En clair, git a une bonne gestion de branches, mercurial moins. On me disait alors que non, qu'on peut faire ce qu'on veut en hg, qu'il faut utiliser les bookmarks, etc.
            Bon, j'ai quand même choisi hg pour une raison simple : le suport multi-os / eclipse.
            Mais reste que les branches de git sont bien meilleures.
            Un bémol tout de même concernant les branches, sous git il est vrai qu'on va créer des branches tout le temps, et à priori. Sous hg j'ai plutôt l'impression qu'on développe dans default et qu'on crée les branches à postériori (en se plaçant sur la bonne révision, le bon bookmark).
            La différence en terme de workflow est assez différente (les deux sont par contre possible en git...) et j'ai l'impression que pour du développement "centralisé" la méthode à postériori est la meilleure.

            Donc je suis allé voir ailleurs, et github propose tout ce que je veux, en mieux.

            Bon sinon je note qu'au final le choix du DCVS se fait de plus en plus par les fonctionnalités de l'outil d'hébergement, et dans le cas présent on se rend compte que github passe devant (et donc git) juste parce qu'il y a plus de feature que le reste. Sous entendu que si bitbucket avait les mêmes fonctionnalités que github beaucoup pourraient être sous hg.

            Quelqu'un pour comparer github / gitorious / bitbucket / indefero ? (les fonctionnalités pas le DCVS)

            • [^] # Re: déçu je suis

              Posté par (page perso) . Évalué à  2 .

              La différence en terme de workflow est assez différente [...]

              Moi aussi je trouve cette différence très différente des différences que j'ai l'habitude de voir. ~~~~~> []

      • [^] # Re: déçu je suis

        Posté par (page perso) . Évalué à  8 .

        Alors oui, le code de github n'est pas libre, mais je peux récupérer mes données sans problème, que ce soit le wiki, les issues ou autre.

        Même lorsque GitHub te zappe ton projet parce que, disons, Sony leur a demandé ? C'est une vraie question, mais c'est aussi un avertissement : se reposer sur une boîte externe dans un pays aux lois différentes du votre (par exemple, sur l'ingénierie inverse), ça peut poser des problèmes que vous n'auriez pas avec un serveur sous votre contrôle dans votre juridiction de résidence.

        Envoyé depuis mon PDP 11/70

        • [^] # Re: déçu je suis

          Posté par . Évalué à  1 .

          Le problème aurait été le meme en europe, l'Europe ayant eu la bonne idée de rajouter le meme genre de disposition dans la loi.

          C'est pas parce que tu auto héberges que tu n'es pas soumit a la loi de la meme façon que github.
          Dans le cas présent, l'auto hébergement aurait simplement change le destinataire de la requête de sony, et l'auteur aurait bien été oblige de le supprimer.

          Ton exemple est au contraire un argument POUR les services externes, héberges dans des pays avec des lois plus souples.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: déçu je suis

            Posté par (page perso) . Évalué à  2 .

            Le problème aurait été le meme en europe, l'Europe ayant eu la bonne idée de rajouter le meme genre de disposition dans la loi.

            Et si j'étais Sénégalais ? :-) Je n'ai pas dit dans mon post que l'Europe était mieux lotie (encore que je n'aie pas connaissance en France de flopées de lettres-types DADVSI amenant des fermetures de sites, alors que le DMCA c'est la fête au village), mais qu'il valait mieux être dans sa propre juridiction pour ne pas prendre de risques avec des lois méconnues.

            Dans le cas présent, l'auto hébergement aurait simplement change le destinataire de la requête de sony, et l'auteur aurait bien été oblige de le supprimer.

            Euh ? Si un quelconque zozo (fut-il gros comme Sony) envoie une notification DMCA à postmaster@mon.domaine, je ne compte pas effacer mes propres fichiers, il resteront bien au chaud sur mes disques, merci beaucoup. Pas plus que je ne vais les retirer du Net, d'ailleurs : au mieux, sa missive partira chez Dave Null, et au pire, il aura droit à un « ici tes lois s'appliquent pas, alors ta note tu te la mets au c.l, et tu te torches avec ! »¹. S'il a vraiment envie de me les voir retirer, il pourra toujours déposer une plainte en bonne et due forme.

            Ton exemple est au contraire un argument POUR les services externes, héberges dans des pays avec des lois plus souples.

            Je le répète : si le serveur est à vous, dans votre pays, tant qu'un juge de votre pays n'y voit pas un problème, vous êtes tranquille (sauf si vous êtes États-Uniens, pas d'bol). Si vous êtes hébergés par une entreprise ailleurs, la loi locale peut permettre aux zozos de vous causer du tort avec une simple lettre (et la boîte ne prendra de risques pour vous : elle vous zappera allègrement).

            ¹ À prononcer bien sûr avec l'accent pied-noir de rigueur

            Envoyé depuis mon PDP 11/70

            • [^] # Re: déçu je suis

              Posté par . Évalué à  -2 .

              Et si j'étais Sénégalais ?

              Les lois senegalaise s'appliqueront.
              De meme que si tu es européen et que tu héberges au senegal.

              Euh ? Si un quelconque zozo (fut-il gros comme Sony) envoie une notification DMCA à postmaster@mon.domaine,

              sony est pas debile, ils t'enverront une notice EUCD et paf le serveur.

              S'il a vraiment envie de me les voir retirer, il pourra toujours déposer une plainte en bonne et due forme.

              Super!
              Ton contenu sera toujours supprime.

              je ne compte pas effacer mes propres fichiers, il resteront bien au chaud sur mes disques

              Mon petit doigt me dit qu'un certain nombre de personnes avait fait un git clone, ceux la gardent leur contenu sur leur disque dur, bien au chaud aussi.
              Note que le contenu étant une infraction a l'EUCD, t'es censé le supprimer de ton disque hein.
              Ou te mettre hors la loi, c'est toi qui choise.

              Je le répète : si le serveur est à vous, dans votre pays, tant qu'un juge de votre pays n'y voit pas un problème, vous êtes tranquille (sauf si vous êtes États-Uniens, pas d'bol)

              Ou européen.
              En gros tu prends un exemple très particulier, ou du code enfreint DMCA et tu en conclu que les service hostes sont mauvais.
              Le raisonnement est totalement biaise, parce que le problème serait le meme en europe, et dans un certain nombre de pays.

              Si on suit ton raisonnement, ce qu'il faut faire pour être sur d'avoir aucun problème, c'est de mettre son contenu sur un service hosté dans un pays qui n'a pas de loi de ce genre, donc ça va très précisément a l'encontre de l'auto hébergement.
              Sans compter que bon, on va ptetre arrêter de déconne 5 minutes, mais un depot git sur une box perso, ça va quoi. Branlez vous la nouille avec l'autohebergement si vous voulez, a tenir la charge phénoménale de 5 clients simultané avec des latence supérieur a la demi seconde, c'est cool, mais yen a qui veulent monter des services de qualité, ça va pas se faire sur une ligne adsl.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: déçu je suis

                Posté par (page perso) . Évalué à  2 .

                sony est pas debile, ils t'enverront une notice EUCD et paf le serveur.

                Pas les ayant droits de video ont bien envoyé une tonne de lettre DMCA à Pirate Bay...

        • [^] # Re: déçu je suis

          Posté par (page perso) . Évalué à  2 .

          Je ne sais pas si le contenu du bugtracker est récupérable dans le cas que tu donnes si tu n'en avait pas de copie locale avant.

          Mais pour le dépôt de sources proprement dit, tu n'en a pas grand chose à faire que GitHub tu zappe ton projet. Changer d'hébergeur, c'est "git remote add [...]; git push --all" et on n'en parle plus, vu que par définition, tu as déjà l'historique complet dans toutes les copies locales. Typiquement, dans le cas de Linux : kernel.org down, ça n'a pas du prendre bien longtemps à Linus pour migrer vers GitHub, et ça ne lui prendra pas plus de temps de re-migrer vers kernel.org en temps voulu.

          Si ça avait été SVN ou CVS, ça aurait été différent : il aurait fallu faire un "svnadmin dump" ou un truc du genre, mais le faire sur une machine compromise c'est moyen bof, donc il aurait surtout fallu prier pour avoir des backups dont on sait qu'ils ne sont pas compromis, restaurer le backup sur un autre serveur, ...

          • [^] # Re: déçu je suis

            Posté par (page perso) . Évalué à  1 .

            Mais pour le dépôt de sources proprement dit, tu n'en a pas grand chose à faire que GitHub tu zappe ton projet.

            Oui, là, entièrement d'accord, les DVCS ça roxxe :-) Mais mon souci, c'est que GitHub, c'est une plate-forme de collaboration, pas juste un dépôt Git : perdre les contenus de ton wiki et ton bugtracker, ça fait râler, donc s'assurer qu'on peut vraiment les récupérer quand ça va mal, ce n'est pas inutile (la question se pose encore plus pour des sites comme SourceForge qui hébergent en plus les ML, le site du projet, etc.).

            Envoyé depuis mon PDP 11/70

    • [^] # Re: déçu je suis

      Posté par (page perso) . Évalué à  0 .

      Vraiment, je ne comprend pas.

      Bah c'est simple : plus le libre devient "mature", plus il y a de gens qui utilisent le libre parce que c'est techniquement mieux (quand ça l'est, sinon le logiciel libre a beau être libre, il ne sera pas utilisé), et pas parce que c'est libre. On en revient aux sources (pas celles de Richard, mais d'autres sources) : le libre est un moyen, pas une fin.

      En fait : comme Linus T. depuis 20 ans.

      Donc : moins de gens en proportion pour hurler "ça pue c'est pas libre" quand le libre est incapable de proposer mieux.
      Si les libristes voulaient que Linus T. mette son petit projet sur un repo libre, ben fallait qu'ils se bougent le cul et proposent mieux que github. En attendant, github est le top pour la coopération GIT, comme Sourceforge (pas libre non plus) l'a été un moment.

    • [^] # Re: déçu je suis

      Posté par . Évalué à  0 .

      Github est devenu les facebook des developpeurs.
      C'est la bas que tout se passe, il se doit d'avoir un compte github avec contributions a qq projets important dans son domaine pour mettre sur son cv, bref c'est in the place to be.

      Ca aurait pu etre bitbucket ou autre, c'est tombe sur github pour je ne sais quelle raison (meilleur techniquement, ou pas, effet reseau, ou pas, que sais je encore).

      Quoi qu'en disent les chantres de l'autohebergement, les humains apprecient la centralisation, ce qui fait que tout le monde se concentre a un endroit, endroit qui a su trouver le juste milieu entre ouverture/libre et proprietaire/ferme pour vivre tout en conservant ses utilisateurs.
      Bon, s'ils avaient pu aussi utiliser un outil utilisable par des humains avec une UI decente, comme mercurial, ca aurait ete au poil, mais ca reste mon avis perso ca (comment ca, moi, lanceur de troll?).

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: déçu je suis

        Posté par (page perso) . Évalué à  4 .

        non, les humains sont grégaires : ils aiment bien vivre en groupe, cela ne veut pas dire qu'ils aiment la centralisation.

        Je dirais même ils "acceptent" la centralisation par paresse : la preuve lorsqu'un bureau de poste (ou une école) ferme à coté de chez eux (décentralisé), pour un/une dans la ville à coté (centralisé) ils gueulent.

        Ils préfèrent décentralisé mais aiment bien vivre en groupes (décentralisés)

    • [^] # Re: déçu je suis

      Posté par . Évalué à  4 .

      La manière dont github est utilisé dans ce cas là ne pose aucun problème. Rien n'a changé dans les méthodes de développements, juste une adresse. Il n'y a aucune dépendance engendrée, et Linus pourra se passer de github pour l’hébergement de référence de Linux du jour au lendemain, ce qu'il compte faire.

Suivre le flux des commentaires

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