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 fredix . É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 ...
[^] # Re: Service libre
Posté par CrEv (site web personnel) . É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).
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 Grammairator . Évalué à 8.
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 windu.2b . Évalué à 10.
Il y a aussi (dans le journal) :
[^] # Re: Service libre
Posté par CrEv (site web personnel) . É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 windu.2b . É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 Internaciulo . Évalué à -2.
Mallernu, forgesu, kabeu, fek al esperanto :)
[^] # Re: Service libre
Posté par CrEv (site web personnel) . É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 fredix . É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 , ...
[^] # Re: Service libre
Posté par fyah . Évalué à 3.
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 DLFP est mort . Évalué à 2.
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 barmic . Évalué à 2.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Service libre
Posté par DLFP est mort . É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 Matthieu Moy (site web personnel) . É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 Laurent J (site web personnel, Mastodon) . Évalué à 5.
tu peux manipuler toutes les données de ton projet via leur api http://developer.github.com/v3/ , et donc récupérer toutes les issues, les données du repo etc..
[^] # Re: Service libre
Posté par Grunt . Évalué à 10.
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 geb . Évalué à 5.
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 WaterCooled . É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 devnewton 🍺 (site web personnel) . É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...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Et si...
Posté par stopspam . Évalué à 2. Dernière modification le 05 septembre 2011 à 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 :
Dans tout ce bordel des fausses manips ne sont pas impossibles et ça peut faire mal.
[^] # Re: Et si...
Posté par stopspam . É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 Bruno Michel (site web personnel) . Évalué à 5.
Non, mais il faut laisser une ligne pour avant la liste à puces.
[^] # Re: Et si...
Posté par Zenitram (site web personnel) . Évalué à 4.
D'où l'utilité du bouton "Prévisualiser" ;-)
[^] # Re: Et si...
Posté par BAud (site web personnel) . Évalué à 7. Dernière modification le 05 septembre 2011 à 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 Zenitram (site web personnel) . Évalué à 7.
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".
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 BAud (site web personnel) . Évalué à 3.
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)
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.
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 Thomas Douillard . Évalué à 2.
Conclusion, il y a du taf' sur le wysiwig de Drupal ?
[^] # Re: Et si...
Posté par Marotte ⛧ . Évalué à -10.
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 Thomas Douillard . É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 Marotte ⛧ . Évalué à -1.
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 Thomas Douillard . É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 Marotte ⛧ . É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.
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 Thomas Douillard . É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 DLFP est mort . É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 Thomas Douillard . É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 DLFP est mort . É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 BFG . É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 Thomas Douillard . É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 Zenitram (site web personnel) . Évalué à -7.
Une implémentation (ou plusieurs) est mauvaise fait que le principe est mauvais?
[^] # Re: Et si...
Posté par DLFP est mort . É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 Thomas Douillard . É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 DLFP est mort . Évalué à 3.
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.
Tu n'as toujours rien compris ? Je me tue à expliquer que c'est lié.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Et si...
Posté par Thomas Douillard . Évalué à 2.
Tu n'expliques rien du tout, tu balance seulement wysiwig = code crade.
[^] # Re: Et si...
Posté par Thomas Douillard . É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 Thomas Douillard . É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 Zenitram (site web personnel) . Évalué à 2.
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.
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 pasScott pasForstall . É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 yellowiscool . É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 Zenitram (site web personnel) . Évalué à 1.
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 barmic . Évalué à 3.
Kaum là gramèr é lautografe ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et si...
Posté par Altor . É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 Marotte ⛧ . É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 Zenitram (site web personnel) . Évalué à 6.
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?
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 Altor . Évalué à 4.
Le principe ils l'ont compris et trouvent ça génial (ma grand-mère était instit).
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.
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 claudex . É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.
« 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: Et si...
Posté par Altor . Évalué à 2.
Cf. ma réponse plus bas.
[^] # Re: Et si...
Posté par claudex . Évalué à 2.
Oui, je l'ai vue juste après avoir poster le commentaire.
« 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: Et si...
Posté par B16F4RV4RD1N . É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 Marotte ⛧ . É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 JGO . É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 Altor . É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 Zenitram (site web personnel) . Évalué à 3.
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 stopspam . Évalué à 0.
[^] # Re: Et si...
Posté par Kerro . Évalué à 2.
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  
;en début de ligne[^] # Re: Et si...
Posté par Larry Cow . É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? ;)
[^] # Re: Et si...
Posté par flagos . Évalué à 5.
Aucun doute. On retrouve sur sa page github le logiciel de plongée dont Linus parle sur son compte "certifié" Google+ !
D'une fiabilité a toute épreuve donc... ;-)
[^] # Re: Et si...
Posté par CrEv (site web personnel) . Évalué à 3.
Ca voudrait dire aussi que quelqu'un c'est fait passé pour lui sur la lkml... et là j'ai comme un doute.
Bon la première fois que j'ai vu la news il est vrai que je me suis sérieusement posé la question d'un fake. Mais vu que c'est Torvalds lui même qui le dit.
Allez, je remet le lien en clair, peut-être n'était-ce pas simple à cliquer sur le bon lien
http://article.gmane.org/gmane.linux.kernel/1187888
[^] # Re: Et si...
Posté par j_kerviel . Évalué à 4.
C'est vrai qu'un mail garanti l’authenticité de son expéditeur.
http://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00030.html
http://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00060.html
# déçu je suis
Posté par CrEv (site web personnel) . É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.
[^] # Re: déçu je suis
Posté par Thomas Douillard . É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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 CrEv (site web personnel) . É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...)
{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 Gui13 (site web personnel) . É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 Laurent J (site web personnel, Mastodon) . Évalué à 3.
Oui c'est ce que j'ai expliqué. De mon point de vue, Github est beaucoup mieux foutu que gitorious.
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.
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 CrEv (site web personnel) . É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.
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 Gui13 (site web personnel) . Évalué à 2.
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 William Steve Applegate (site web personnel) . Évalué à 8.
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 pasScott pasForstall . É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 William Steve Applegate (site web personnel) . Évalué à 2.
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.
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.
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 pasScott pasForstall . Évalué à -2.
Les lois senegalaise s'appliqueront.
De meme que si tu es européen et que tu héberges au senegal.
sony est pas debile, ils t'enverront une notice EUCD et paf le serveur.
Super!
Ton contenu sera toujours supprime.
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.
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 Zenitram (site web personnel) . Évalué à 2.
Pas les ayant droits de video ont bien envoyé une tonne de lettre DMCA à Pirate Bay...
[^] # Re: déçu je suis
Posté par Matthieu Moy (site web personnel) . É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 William Steve Applegate (site web personnel) . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 0.
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 pasScott pasForstall . É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 hervé Couvelard . É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 Guillaume Knispel . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.