Laurent J a écrit 2948 commentaires

je ne vois pas ce que tu entends par données personnelles. Si tu parles du code/issues/wiki, dans ce cas c'est contradictoire avec le fait que tu veuille rendre public tes données dans gitlab. Si tu parles du profil utilisateur, je ne vois pas vraiment ce qu'il y a comme données personnelles. Dans Github, je n'ai pas de données personnelles dans mon profil, à part mon mail et mon nom/prénom. Mais tu peux très bien fournir un pseudo et une adresse mail anonymisée…

j'aimerais juste pouvoir l'installer sur mon serveur

comme je l'ai dit, à cause de leur infrastructure, il est fort possible que l'architecture de leur application ne soit pas évident à installer ça sur son petit serveur chez soi.

Par contre, si tu veux un Github like chez toi, regarde du coté de Gitlab. C'est une copie quasi conforme.

mais que j'aime avoir mes données chez moi

même avec github, tes données sont chez toi. Ton dépôt git est sur ta machine. Tu peux aussi avoir le depot git du wiki sur ta machine. Et tu peux rapatrier les issues via des api..

Le modèle propriétaire : le code du service n'est pas fourni, il est très difficile voire impossible d'exporter les données.
Le modèle libre : le code du service est fourni, il est souvent possible d'exporter ses données facilement.

Ce qui est totalement faux. La possibilité de récupérer ses données dépends seulement des fonctionnalités du service, pas du fait que le code du site soit ouvert ou fermé.

La boite qui offre un service reposant à 100% sur du libre ne va pas pour autant ouvrir ses bases de données ou son système de fichier à tout vent. L'export de tes données va donc dépendre des API qu'elle propose, qu'elle ouvre.

Imagine que demain j'ouvre une plateforme wiki basé sur Dokuwiki, je peux très bien ne pas vouloir ouvrir l'API XMLRPC de dokuwiki pour diverses raisons : sécurité, "emprisonner" l'utilisateur, ou encore faire payer l’accès à cet API.

Qu'est ce que cela va changer pour l'utilisateur, par rapport à un service dont le code source est proprio ? Rien. Absolument rien.

Ça fait plusieurs fois que je lis sur linuxfr cet argument "contre" pour les services reposant sur des logiciels proprio. ARRETEZ DE L'UTILISER, c'est totalement bidon, du coup, ça décrédibilise le reste de votre argumentaire.

Les fournisseurs de service misent sur la qualité de service

Oui, mais ça a un coût. Il faut donc payer quelque part (infrastructure, réseau…). Que le soft soit ouvert ou fermé ne change pas grand chose au final. Si on veut de la qualité de service, il faut payer, et c'est tout à fait normal. Maintenant, à qualité égale, on peut effectivement choisir de mettre ses sous dans la boite qui utilise des logiciels libres.

les clients qui n'ont pas la compétence en interne pour installer ce service

Ou pas envie et/ou pas le temps de gérer un service "interne".

Les parties les moins importantes de leur service sont libres, par exemple Gollum leur moteur de wiki utilisant un dépôt git. Mais le cœur de l'application est entièrement propriétaire.

En même temps, ça ferait une belle jambe à tout ceux qui utilisent github, d'avoir le coeur de l'application.

Un paramètre semble être oublié dans l'argumentaire : github héberge des centaines de milliers (millions?) de projets. Donc le coeur de l'appli est architecturé pour une infrastructure spécifique, à forte charge. Ça doit être certainement la plaie à installer et à configurer, parce que très spécifique. Très franchement, j'en voudrais pas pour l'installer sur un intranet en entreprise par exemple, ce serait prendre un marteau pour écraser une mouche.

Si on veut un outil similaire, autant prendre un des outils que tu as cité, ça sera certainement plus simple à installer, et certainement plus adapté à des petites structures. puisque si on veut du github chez soit, en entreprise, c'est qu'à priori, on a une petite infrastructure réservée au développement par rapport à chez github. Je doute qu'il existe une boite qui ait des centaines de milliers de projets à gérer comme sur Github.

Conclusion : tout le monde s'en fout que le coeur de Github soit proprio. sauf les aigris, les intégristes et les empêcheurs de tourner en rond.

Merci sinon pour ta liste d'alternatives. Mais sans troll, ça aurait été mieux.

D'après cette info, l’émission n'est pas arrêtée, en tout cas pas en 2013. Par contre France 3 demande à ce qu'elle coute moins cher.

Ensuite, les moteurs de recherche ont défini des best practices

Ouai enfin, ce n'est pas qu'une "best practice" pour les moteurs de recherche. C'est surtout pour n'importe qui le contenu !

Parce que bon, être interrompu dans sa lecture tout les 4 mots par des URLS dans un texte, c'est plutôt pénible.

mais qu'est ce qui fait que sur des trucs aussi sensibles les personnes ne soient pas obligé à rentrer une clé genre OTP.

je confirme que certaines applications (de la défense tout du moins), même des cms etc, ont ce genre de clé d’accès. Mais peut-être pas toutes..

Le nouveau "plugin" en question est entièrement en Javascript, et repose sur HTML5 (balise video pour les videos par exemple, et probablement canvas pour le reste).

Il n'utilise donc pas les mêmes technos que les autres (C/C++), il y a beaucoup moins de chance que ça crash (null pointer etc, ça n'existe pas en JS :-).

Coté perf, c'est à voir. Ils doivent certainement faire usage des Arrays spécialisés sur les entiers/flottants etc pour les manipulations de matrices ou de bytecode (ce qui est TRÈS performant par rapport à un Array normal).

et c'est aussi transparent

ah non pour moi, une machine à voter, c'est une belle boite noire qui fait des choses que je (ou n'importe quel quidam) ne comprends pas. Elle a beau me sortir un ticket machin chose, au final, pour être sûr qu'elle a bien compté, il faudrait recompter "à la main".

Résultat : une machine à voter ne sert à rien, sauf à remplir les poches des vendeurs de machines à voter.

et bientôt Firefox OS.

comment ça pour Firefox OS ??

C'est pas comme ci Firefox OS avait un environnement très spécifique, des API exotiques, son propre langage, son propre environnement graphique ou que sais-je encore. Non. Firefox OS, c'est un OS reposant sur des standards (ou en passe de l'être).

Une appli pour Firefox OS, c'est du HTML/JS/CSS, avec des API étendues qui sont TOUTES en train d'être spécifiés et standardisés (donc en train d'être adoptées par les autres navigateurs).

Que Firefox OS n'arrivera pas au niveau de IOS et Android en terme de part de marché, c'est probable, on verra bien, et d'ailleurs, ce n'est pas le but de Mozilla que "d'écraser" la concurrence. Mais de là à dire que c'est un futur système agonisant, je n'y crois pas une seconde, surtout avec les contrats déjà passés avec des opérateurs télécoms, ou les contributions d'autres fabricants/opérateurs…

En tant qu'arrivant, personne me connait, je fourni un patch qui n'est pas dans les regles de l'art, il est rejeté comme un mal propre, et résultat je me casse.

Parce que tu t'y prend mal.

On n'arrive pas sur un projet avec ses gros sabots "tiendez, vla mon patch". C'est comme si tu étais un nouveau commis en cuisine dans un restaurant, que le chef te demande de faire le "gateau au chocolat" star du resto, et que tu en fasses un sans demander la recette (et qu'il y a donc de forte chance que ce ne soit pas le gateau attendu, parce que tu n'aura pas mis la crème qu'il faut, pas utiliser le bon chocolat etc).

Bref, quand on arrive sur un projet, on essaye de se renseigner :

• chercher le bon canal de communication pour les contributeurs : forum / IRC / mailing list etc…
• se présenter : "bonjour, j'ai vu tel bug, je voudrais contribuer", suivi d'un "quel est la procédure à suivre s'il vous plait"

Et là, il y a de forte chance qu'on te réponde, "va lire la doc ici" (quand elle existe :-) ), ou "faut faire comme-ci comme ça"..

Ensuite tu peux commencer ton patch et le proposer en suivant la procédure, le coding style etc…

Pour toi :
- tu ne refais pas 15 fois ton patch pour que ça soit accepté
- ta contribution est plus vite intégrée : ça flattera ton ego
- tu seras mieux vu et plus vite accepté
- les autres contributions n'en seront que plus facile

N'oublie pas que ce sont des êtres humains. Il ne faut donc pas oublier les rêgles sociales traditionnelles :-)

sans oublier :

• pain au chocolat ou chocolatine ?

Si j'ai bien compris, c'est pas l'envie de contribuer qui te manque.

Ne cherche pas à te dire tout seul "qu'est ce que je pourrais bien faire sur ce projet". Tu ne trouveras pas.

Par contre, va voir les développeurs, et demande leur. Commence par leur demander des trucs qui sont faciles à faire. Cela a plusieurs avantages :

• cela te fait découvrir l'intérieur du code source
• cela fait avancer ENORMEMENT le projet. En effet, les trucs trop simple à corriger, il y en a des tonnes, parce que justement, c'est trop simple et que les développeurs déjà en place sont trop occupés à développer les trucs les plus compliqués.
• cela rend le logiciel mieux fini, donc plus agréable pour l'utilisateur.

Par exemple, corriger une faute d'orthographe dans un menu :
- tu apprends où est le code des menus (ou alors comment et où sont stockées les chaînes de traduction)
- tu libères 5 minutes de temps pour les développeurs (et 5 min + 5 min + 5 min +… ça leur en fait du temps de gagner pour dev les trucs les plus durs)
- tu rends le logiciel moins agaçant pour les utilisateurs pour qui cette faute les choquent.

Tu commences donc par ces trucs anodins, et au fur et à mesure des patchs, tu passes à des bug fix ou des fonctionnalités plus compliquées. Et au bout de quelques mois ou année, tu finis par devenir un core-developper, code reviewer etc :-)

Une chose est sûre : tu ne pourras jamais arriver dans un projet et pouvoir proposer une grosse évolution tout de suite. C'est comme tout, il faut apprendre comment il fonctionne, de l'interieur et de l'exterieur. Bref, de la motivation, du courage, et de l'huile de coude.

Pour prendre l'exemple de Mozilla, dans la liste des choses à faire, il y a les bugs marqués "good first bug". Facile à faire en principe pour un nouveau venu. Pioche ! ;-) (tu peux aussi affiner la recherche en fonction des composants ou applis qui correspondraient plus à tes compétences/envies, le projet Mozilla ne se résume pas à Firefox ;-) )

pour un truc aussi bête que de la lecture d'EPUB.

Je te recommande d'aller lire la spec de epub3 par exemple, pour te rendre combien cette spec est complexe et contenant de nombreux trucs mal foutu, voir le blog de Daniel Glazman à ce sujet.

en ce qui me concerne, non, ce n'est pas une question de génération (put** je vais sur mes 40 balais). J'ai vu plusieurs fois des épisodes de la 7ième compagnie (mais ça fait très longtemps), et j'adore la série kaamelott. Comme quoi, on peut aimer les vieux trucs et les trucs récents à la fois :) Et dans les deux oeuvres, il est excellent :-) (faut reconnaitre aussi que les dialogues de kamelott sont écrits aux petits oignons, en particulier donc avec son rôle de césar)

bon par contre, "cordier juge et flic", jamais pu accroché.

Je viens de me balader sur le site de typematrix. Et que vois-je, dans la section "Dans les nouvelles" d'une page ? Un lien vers un article de ploum sur linuxfr :-)

Okay merci :-) J'essaierai ça ce week-end

Merci pour l'astuce. Je crois que je vais configurer mon laptop comme ça :-)

Maintenant, juste une question de newbie en utilisation des niveaux d’exécution (disons que je ne me suis jamais amusé avec) : le fait d'appeler une commande init, ça ne va pas te déconnecter ou relancer certains programmes ? On peut lancer ça quand on est sous gnome/kde par exemple ? ça ne va pas redémarrer gnome/kde ?

PS: j'imagine bien que ça va arrêter les services qui sont en K dans le nouveau level, mais pour les services qui sont communs à l'ancien et au nouveau ?

Beaucoup préfèrent un github tout joli avec des effets javascript à un gitweb (ou carrément l'utilisation de git en ligne de commande).

mmm… tu n'as pas dû regarder ce qu'était github.

gitweb, ce n'est qu'un navigateur pour un dépôt Git. Github ça comporte quand même beaucoup plus de fonctionnalités.

Après je ne vois pas l'utilisation de github en contradiction avec l'utilisation de git en ligne de commande.

J'utilise git tout les jours, en ligne de commande, et pour partager, j'utilise github. ça m'évite de monter un serveur git, ça évite à mes contributeurs de monter eux aussi leur serveur git pour que je puisse récupérer leur contributions, et ça me permet de faire de la review de code plus facilement.

Bref, tu compares des choux et des carottes.

Et utiliser des applis web/gui desktop, n'est pas en contradiction avec utiliser des outils en ligne de commande. Ils sont tout les deux complémentaires.

oups. oui en effet désolé. Je me suis mélangé les pédales. Les vacances, c'est décidément trop fatiguant.

On utilise pas des dénominations différentes pour désigner une voiture en fonction de son pays d'origine.

Bah, si, en anglais, voiture se dit "car". En allemand "wagen" etc..

Donc pourquoi faudrait-il avoir le même mot dans toutes les langues pour désigner un être humain qui va dans l'espace ?

J'ai été déçu quand la France a eu ses premiers cosmonautes, grâce à l'Union soviétique avec Jean-Loup Chrétien et grâce aux États unis d'Amérique avec Patrick Baudry, et qu'elle s'est crue obligée de forger un nouveau terme sans justification autre qu'un orgueil national mal placé

Il y a peut-être un orgeil national mal placé, mais je crois qu'il y a plutôt une autre raison. Il faut se replacer dans le contexte : à cette époque, surtout avec Jean-Loup Chrétien, nous sommes en pleine guerre froide. Avec ce partenariat (proposé par les russes), la France est prise en sandwich : d'un coté, allié des américains, et de l'autre, cette opportunité d'envoyer un français dans l'espace, avec l'aide de "l'ennemi" qui est de l'autre coté du mur. Si, officiellement, on avait appelé Mr Chrétien, un "astronaute", ça aurait probablement déplu aux russes. Si cela avait été "cosmonaute", cela aurait déplu aux américains. Bref, diplomatiquement, d'un coté comme de l'autre, cela aurait été tendu. Alors hop, appelons le, un "spationaute", cela ne va froisser personne. Et en plus c'est plus logique dans notre langue.

D'ailleurs si on suit ta logique, pourquoi tout le monde n'a pas appelé une voiture "voiture" dans les autres pays. Pourquoi d'ailleurs tout le monde ne parles-t-il pas la même langue ?

bof, c'est pas l'économie des salaires de 4-5 gars qui vont permettre de payer toutes ces pubs…

et un os qui t'interdit d'installer autre chose que ce qui est fourni par une boutique unique

à priori, tu as encore quelques libertés sur Mac : tu n'es pas obligé de passer par cette boutique pour installer un logiciel.

parfois/souvent ( rayer la mention inutile)

il faut que je raye les deux. Il manque le choix "toujours".

Elles sont toutes innovantes ?

à toi de voir..

Joost, Zoomcreator, Etna etc, oui c'était innovant. De mon point de vue en tout cas…