Journal Le danger github

Posté par  . Licence CC By‑SA.
Étiquettes :
10
26
fév.
2016

Un petit journal bookmark du vendredi pour mettre en avant un billet sur le site de Carl Chenet, à propos de Github :

http://carlchenet.com/2016/01/22/le-danger-github/

Bien sûr, ce thème a été largement débattu dans le passé sur Linuxfr, mais c'est bien écrit et ça contient des informations intéressantes, comme la lettre de doléances de 1340 signataires, beaucoup étant des développeurs de gros projets genre jquery, nodejs, qui se trouvent bloqués dans les fonctionnalités de github au lieu de travailler sur des forges ouvertes comme gitlab.

Les réflexions soulevées dépassent d'ailleurs le cadre de GitHub, et cela peut concerner également d'autres réseaux centralisés (twitter, facebook, linuxfr).

  • # service...

    Posté par  . Évalué à 10. Dernière modification le 26 février 2016 à 13:35.

    il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

    J'ai arrêté de lire après ça. Github n'est pas un logiciel mais un service. Cette question a été discuté il y peu dans un journal.

    Donc en utilisant github,vous n'utilisez pas un logiciel propriétaire mais un service basé sur un logiciel libre dont vous n'êtes jamais captif (git remote set-url). Bref… Râler pour râler quoi…

    • [^] # Re: service...

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

      Si tu as les sources du « service » comme tu dis, tu peux le reproduire chez toi (ou ailleurs) à l'identique, si tu n'as pas les sources tu ne peux pas, du moins pas trivialement (tu peux toujours essayer de reproduire).

      Avoir tes données sur une machines que tu ne maîtrise pas est un autre problème, qui dépend beaucoup de la confiance que tu as en la personne ou l'organisme qui maîtrise la machine.

      Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

      À ça s'ajoute que github exploite ou peut exploiter tes données (je ne connais pas le modèle exacte de github, mais ça ne m'étonnerait pas qu'il utilise les données pour des offres d'emplois par exemple, après on aime ou pas c'est une autre question).

      Il y a tout un tas d'autre problèmes liés à la centralisation et à l'uniformisation, bref c'est un débat tout à fait pertinent.

      À titre perso, je suis particulièrement gêné que la XSF soit passé à github, car ça arrive de plus en plus souvent que des commentaires se fassent là bas au lieux d'être sur la liste de diffusion dédiée. Mais bon on s'éloigne de la problématique du logiciel propriétaire que tu citait.

      • [^] # Re: service...

        Posté par  . Évalué à 10.

        Si tu as les sources du « service » comme tu dis, tu peux le reproduire chez toi (ou ailleurs) à l'identique, si tu n'as pas les sources tu ne peux pas, du moins pas trivialement (tu peux toujours essayer de reproduire).

        Non. Tu peux très bien monter un pataquès trop complexe pour qu'un particulier puisse jouer avec.

        Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

        La majorité des données sont exportables. Dans un format très largement utilisé quand c'est possible (les sources et le wiki). Il n'y a tout simplement pas de forge libre qui propose d'exporter autant/aussi facilement ses données.

        Il y a tout un tas d'autre problèmes liés à la centralisation et à l'uniformisation, bref c'est un débat tout à fait pertinent.

        Se plaindre de l'uniformisation de github en prônant gitlab, c'est ridicule. L'uniformisation c'est mal quand ça empêche la créativité. Rien empêche de faire une autre forge (ou d'utiliser ce qui existe comme codendi, redmine ou autre).

        Mais tout ça c'est surtout ridicule parce que les gens qui se plaignent ne veulent pas révolutionner le monde des forges, ils veulent juste quelques fonctionnalités en plus. Ça n'a rien avoir avec tout ce que vous racontez. Vous faites dire n'importe quoi à cette lettre.

        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...

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

          Non. Tu peux très bien monter un pataquès trop complexe pour qu'un particulier puisse jouer avec.

          J'ai dis « tu peux le reproduire chez toi (ou ailleurs) à l'identique », évidemment tu peux chercher le cas tordu où on va chercher à rendre le truc difficile à installer, mais ça ne change rien au fait que tu peux le reproduire à l'identique, alors que si tu n'as pas les sources tu ne peux pas.

          La majorité des données sont exportables. Dans un format très largement utilisé quand c'est possible (les sources et le wiki). Il n'y a tout simplement pas de forge libre qui propose d'exporter autant/aussi facilement ses données.

          Dans le cas présent (github), si tu dis « la majorité », ça veut dire qu'il y a des données non exportables. Et dans tous les cas tu as un effort d'export à faire, avec risque de perte de fonctionnalités si tu n'as pas le même logiciel en face.

          Se plaindre de l'uniformisation de github en prônant gitlab, c'est ridicule.

          C'est possible, sauf que je n'ai pas plus « prôné Gitlab » comme tu dis qu'une autre solution, si tu réponds à l'auteur de l'article original, c'est pas à mon commentaire qu'il faut répondre. Je réponds uniquement au commentaire qui dit que ça n'a pas d'intérêt d'avoir le code source d'un « service », et j'explique pourquoi c'est faux.

          Mais tout ça c'est surtout ridicule parce que les gens qui se plaignent ne veulent pas révolutionner le monde des forges, ils veulent juste quelques fonctionnalités en plus. Ça n'a rien avoir avec tout ce que vous racontez. Vous faites dire n'importe quoi à cette lettre.

          Merci de ne pas m'inclure dans ce « vous », je n'ai ni lu, ni mentionné cette lettre (et pour tout dire, je me cogne pas mal de ce qu'il se passe chez Github, sauf quand ça me concerne directement comme dans le cas de la XSF).

          • [^] # Re: service...

            Posté par  . Évalué à 3.

            Non. Tu peux très bien monter un pataquès trop complexe pour qu'un particulier puisse jouer avec.

            J'ai dis « tu peux le reproduire chez toi (ou ailleurs) à l'identique », évidemment tu peux chercher le cas tordu où on va chercher à rendre le truc difficile à installer, mais ça ne change rien au fait que tu peux le reproduire à l'identique, alors que si tu n'as pas les sources tu ne peux pas.

            Bis repetita… L'important ce n'est pas d'avoir le code du serveur (tu ne sais jamais si tu as vraiment le code du serveur), mais d'avoir des données utilisables.

            Dans le cas présent (github), si tu dis « la majorité », ça veut dire qu'il y a des données non exportables. Et dans tous les cas tu as un effort d'export à faire, avec risque de perte de fonctionnalités si tu n'as pas le même logiciel en face.

            Tu sais qu'on peut être piégé par un logiciel tout ce qu'il y a de plus libre ? Si tu fais de la photo et que tu as déjà changé de logiciel de gestion de photo, tu dois voir de quoi je parle. Chaque logiciel créer son propre silo de données que tu alimente fièrement et qui n'ai pas interopérable dommage. Me faire avoir par un service ou par un logiciel (qu'il soit libre ou non) ça laisse le même arrière goût.

            […] si tu réponds à l'auteur de l'article original, c'est pas à mon commentaire qu'il faut répondre. Je réponds uniquement au commentaire qui dit que ça n'a pas d'intérêt d'avoir le code source d'un « service », et j'explique pourquoi c'est faux.

            Pfff rhétorique… Je croyais que tu répondais au commentaire qui disait que l'article n'était pas intéressant (c'est vachement intéressant de se renvoyer la balle comme ça tu ne trouve pas ?….)

            Merci de ne pas m'inclure dans ce « vous », je n'ai ni lu, ni mentionné cette lettre (et pour tout dire, je me cogne pas mal de ce qu'il se passe chez Github, sauf quand ça me concerne directement comme dans le cas de la XSF).

            Désolé de faire un rappel de contexte.

            De manière très général, je trouve que critiquer n'est pas très intéressant, c'est souvent pas très constructif. Il est bien plus intéressant pour tout le monde et bien plus efficace pour lutter contre l'uniformisation de présenter son alternative et pas comme un St Graal (ça met sur la défensive), mais en expliquant en quoi ça te convient.

            Du coup je viens d'aller voir où est hébergé « Salut à toi » et c'est de l'hébergement spécifique. Il y a tout de suite moins de choses à en dire :)

            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...

              Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 février 2016 à 15:44.

              Bis repetita… L'important ce n'est pas d'avoir le code du serveur (tu ne sais jamais si tu as vraiment le code du serveur), mais d'avoir des données utilisables.

              Pour moi, à partir du moment où tu as décidé d'aller voir ailleurs, et problématiques de confiance mises de côté, il y a 2 facteurs majeurs:

              • le code source, pour reproduire à l'identique
              • et les données

              tu peux avoir l'un sans l'autre, mais les 2 sont importants.

              Si tu n'as pas le code source, tu devras trouver (ou écrire) un logiciel compatible, et tu risques de perdre des fonctionnalités.

              Si tu n'as pas les données, tu vas devoir passer par des méthodes détournées comme le scrapping, là encore, du temps et des efforts pour migrer. Et il y a possiblement des cas où c'est même pas possible ou extrêmement difficile de migrer (par exemple une vidéo avec DRM)

              Tu sais qu'on peut être piégé par un logiciel tout ce qu'il y a de plus libre ? Si tu fais de la photo et que tu as déjà changé de logiciel de gestion de photo, tu dois voir de quoi je parle. Chaque logiciel créer son propre silo de données que tu alimente fièrement et qui n'ai pas interopérable dommage. Me faire avoir par un service ou par un logiciel (qu'il soit libre ou non) ça laisse le même arrière goût

              Même pour le libre il y a une question de confiance, la licence est un élément majeur mais pas suffisant. Si l'éditeur du logiciel ajoute volontairement des données difficiles à transférer, il vaut mieux l'éviter, si c'est juste un manque d'outil de migration, c'est l'occasion de contribuer. Dans tous les cas, c'est bien plus simple si tu as les sources (et le droit d'y toucher).

              Pfff rhétorique… Je croyais que tu répondais au commentaire qui disait que l'article n'était pas intéressant (c'est vachement intéressant de se renvoyer la balle comme ça tu ne trouve pas ?….)

              Je reproche juste de me faire dire des choses que je n'ai pas dites. Je ne connais pas suffisamment Gitlab pour le conseiller, et j'essaye d'éviter la centralisation autant que possible (ce qui ne m'empêche pas d'être sur DLFP ou SeenThis). Et pareil pour la remarque suivante, rappeler le contexte c'est une chose, me mettre dans le « vous » c'est me faire dire des choses que je n'ai pas dite. Enfin pas la peine de s'étendre dessus, je voulais aussi d'éviter d'avoir à défendre ou réfuter des arguments qui ne sont pas les miens.

              De manière très général, je trouve que critiquer n'est pas très intéressant, c'est souvent pas très constructif. Il est bien plus intéressant pour tout le monde et bien plus efficace pour lutter contre l'uniformisation de présenter son alternative et pas comme un St Graal (ça met sur la défensive), mais en expliquant en quoi ça te convient.

              Critiquer (quand c'est pas gratuit et que c'est argumenté), ça permet de réfléchir, et peut-être de déboucher sur une solution.

              • [^] # Re: service...

                Posté par  . Évalué à 1.

                Si tu n'as pas le code source, tu devras trouver (ou écrire) un logiciel compatible, et tu risques de perdre des fonctionnalités.

                Non, c'est si tu n'a pas de logiciel compatible avec les données. C'est très différents. Au niveau fonctionnalité même en gardant le même logiciel, tu peut perdre (pour les services une part de leurs fonctionnalités vient du fait que ce soit des services, donc l'accessibilité depuis n'importe où, la performance, le nombre d'utilisateurs,…).

                Si l'éditeur du logiciel ajoute volontairement des données difficiles à transférer[…]

                Pourquoi un « éditeur » qui ajoute « volontairement » ? Ça peut très bien être Jules qui implémente ce qu'il a dans la tête sans prendre le temps de regarder l'état de l'art.

                Critiquer (quand c'est pas gratuit et que c'est argumenté), ça permet de réfléchir, et peut-être de déboucher sur une solution.

                Non. Ou dans des cas suffisamment particulier pour considérer que non. Pour déboucher sur une solution, il faut :

                • vouloir en trouver une
                • être suffisamment peu dans la discussion
                • que les gens s'écoutent sans être trop sur la défensive
                • qu'il y ai des oppositions d'idées
                • …

                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...

                  Posté par  . Évalué à 3.

                  Critiquer quelque chose c'est pas forcément en dire du mal, on peut aussi en dire du bien (et ça reste une critique).

              • [^] # Re: service...

                Posté par  . Évalué à 4.

                Même pour le libre il y a une question de confiance, la licence est un élément majeur mais pas suffisant. Si l'éditeur du logiciel ajoute volontairement des données difficiles à transférer, il vaut mieux l'éviter, si c'est juste un manque d'outil de migration, c'est l'occasion de contribuer.

                Sur ce sujet Benjamin Bayart avait écrit (il y a longtemps dans un très lointaine galaxie) un très bon texte, il y développe la notion de logiciel libérateur (qui est donc distinct d'un logiciel libre) :

                OpenOffice.Org, Pourquoi pas ? - Benjamin Bayart - 2004

                http://edgard.fdn.fr/liberateur/

                Pour les PDF du texte :

                http://edgard.fdn.fr/liberateur/liberateur.pdf

                http://framasoft.net/IMG/liberateur.pdf

              • [^] # Re: service...

                Posté par  . Évalué à 2.

                Si tu n'as pas le code source, tu devras trouver (ou écrire) un logiciel compatible, et tu risques de perdre des fonctionnalités.

                Certes. Parce que tu devras écrire ou trouver un soft compatible.

                si c'est juste un manque d'outil de migration, c'est l'occasion de contribuer

                Mais il te faut tout de même avoir une infra compatible, et des outils supportés par le logiciel en question.

                Si le soft est pensé pour une arch 64 bits big endian, sans se prendre la tête avec les conversions (parce que, de toute façon, ça tourne que sur du BE), et que toi tu veux l'utiliser sur une arch litlle endian 32 bits, et que, pour ne rien arranger, il se base sur des bibliothèques fermées (et non dispo gratuitement), laisses-moi te dire que malgré que tu aies le code source, tu vas en chier pour le faire tourner chez toi. Ouvert ou pas.

                Dans les 2 cas que j'ai cité, tu as de bonnes chance d'avoir "l'occasion de contribuer" du coup.

                Bref, la seule chose qui me semble réellement importante c'est d'avoir d'ensemble des données. Et le code source est bien moins parlant pour une migration de logiciel que la documentation du format de données, que l'on peut, certes, extraire des sources, mais c'est un travail long, chiant et difficile. Surtout dans le cas d'un logiciel complexe et/ou mal écrit. Peu importe que ce soit ouvert ou non (dans le cas d'un logiciel libre, c'est plus simple, ceci dit).

                L'intérêt de l'open-source, au final, c'est quoi?
                C'est de pouvoir adapter le logiciel à ses besoins et d'avoir une chance de vérifier qu'il ne fait pas de blagues salaces dans ton dos (envoi de données à des tiers non désirés, générer des bitcoins pour les filer à d'autres, etc).
                Ceux qui utilisent une forge (service) qu'ils n'hébergent pas eux-même n'ont de toute façon aucune chance d'adapter le logiciel et l'infra (j'inclue dans l'infra la version du logiciel déployée) à leurs besoins, et du coup, on pourrais même dire que celui hébergeant ses projets sur les logiciels de github mais sur son infrastructure privée (qu'il contrôle, il me semble qu'il est possible d'acheter des licences) est bien plus libre (de faire évoluer le service) que celui qui utilise gitlab hébergé par autrui (parce qu'il ne contrôle que dalle).
                D'ailleurs, un logiciel libre utilisé comme serveur peut très bien être modifié à l'insu de l'utilisateur final, s'il n'est pas en AGPL. gitlab l'est-il? redmine l'est-il?

                Ma conclusion personnelle: que le logiciel derrière github soit libre ou pas: on s'en fout, c'est pas ça qui compte.
                Ce qui compte, quand on utilise une forge, c'est de pouvoir publier son code et d'avoir des retours facilement, en diminuant/supprimant le coût d'hébergement (argent et temps).
                Avoir le source du logiciel qui expose ça, ne sera important que le jour ou tout le monde hébergera ses projets chez lui, mais ce jour la les dev seront bien plus coûteux, et il y aura moins d'open source, ou les projets aurons moins de contributeurs.

          • [^] # Re: service...

            Posté par  . Évalué à 10.

            ça me fait penser à Firefox Accounts et Firefox Sync. Deux services dont le logiciel est distribué sous licence libre.

            Maintenant que le service est mort, il faut survivre à 12 milliards d'étapes compliquées (la 7e va vous étonner) pour mettre en place le bouzin chez soi.

            Pourtant on peut difficilement faire à Mozilla le procès d'intention de l'obfuscation volontaire.

            BeOS le faisait il y a 20 ans !

            • [^] # Re: service...

              Posté par  . Évalué à 4.

              Pourtant on peut difficilement faire à Mozilla le procès d'intention de l'obfuscation volontaire.

              C'est un exemple que j'avais en tête, mais il n'y a pas que ça. Mettre en ligne un service comme github avec des millions d'utilisateurs ça n'est pas vraiment la même chose qu'héberger un gitolite sur son raspberrypi. Il y en a un qui n'utilise potentiellement 2 ou 3 bases de données en plus de la persistance fournie par git, probablement des files des messages pour lisser/répartir la charge et des batchs pour consolider ses données,… Très peu d'utilisateurs vont se monter un tel système.

              Exchange ne vie que parce qu'office365 n'existait pas, maintenant les entreprises migrent d'exchange à office365, ça marche mieux.

              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...

                Posté par  . Évalué à 4.

                Pour utiliser Gitlab sur une installation locale, la complexité est très bien cachée par leur paquet 'Omnibus', qui intègre de fait tous les softs nécessaires et la conf adéquate.

                C'est assez étonnant, mais Ça Juste Marche. Y compris les màj qui font des migrations de la BDD.

            • [^] # Re: service...

              Posté par  . Évalué à 0.

              Le service n'est pas mort, il a évolué, et en plus, il s'est - un peu - simplifié en passant sur des plateformes modernes.

      • [^] # Re: service...

        Posté par  . Évalué à 10.

        Avoir tes données sur une machines que tu ne maîtrise pas est un autre problème, qui dépend beaucoup de la confiance que tu as en la personne ou l'organisme qui maîtrise la machine.

        Non, c'est en fait le sujet principal. Si on remplace "Github" par "Gitlab", on aurait exactement les mêmes problématiques principales: centralisation des données, possibilité de tout exporter, exploitation des données par un tiers, viabilité du service, etc.

        Ces personnes râlent parce que Github, qui propose un service de qualité et souvent gratuitement, n’exauce par leurs 4 volontés. Ce serait certainement pareil si tout le monde était chez Gitlab. Bizarrement, monter leur propre hébergement Gitlab ne les intéresse pas…

        Que Github soit libre ou non est totalement secondaire.

        • [^] # Re: service...

          Posté par  . Évalué à -2.

          Si on remplace "Github" par "Gitlab", on aurait exactement les mêmes problématiques principales: centralisation des données, possibilité de tout exporter, exploitation des données par un tiers, viabilité du service, etc.

          GitLab est un logiciel libre auto-hébergeable. Tu peux utiliser GitLab.com, ou un autre tiers (comme Framasoft), ou héberger les données sur une de tes machines. Il n'y a donc clairement pas nécessairement de centralisation des données, ça dépend de l'utilisation commune que l'on en a. Pour ce qui est de l'exportation, c'est comme même mieux d'avoir un accès direct à la base de données, ce qui est possible avec un GitLab auto-hébergé et impossible avec GitHub ou BitBucket.

          • [^] # Re: service...

            Posté par  . Évalué à 6.

            c'est comme même mieux

            Aie ><

            avoir un accès direct à la base de données

            Non ! Tu connais quoi de la pérennité de ce format ? Si tu veux utiliser redmine, tu fais comment ? Est-ce que la notion d'intéropérabilité a vraiment disparue d'une partie des logiciels libres ?

            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...

              Posté par  . Évalué à 3.

              Merci pour la correction sur "quand même".

              Le format de la base de données n'a pas être stable, mais avoir un accès à la base de données est l'assurance d'avoir accès à toutes les données (même si l'export via ce biais est plus compliqué), ce qui n'est pas forcément le cas avec une API JSON et/ou XML.

              • [^] # Re: service...

                Posté par  . Évalué à 7.

                Le format de la base de données n'a pas être stable, mais avoir un accès à la base de données est l'assurance d'avoir accès à toutes les données (même si l'export via ce biais est plus compliqué), ce qui n'est pas forcément le cas avec une API JSON et/ou XML.

                Bon ca va, faut arreter d'enculer les mouches 2 secondes.
                Leur export est documente, tu regardes la doc, tu vois si ca inclue tout ou pas, et puis voila. En l'occurence, il manque les etoiles, certes, mais d'un autre cote, c'est peu normal, c'est une propriete des autres utilisateurs, pas du repo. Savoir que t'as n etoiles est pas tres pertinent si ces etoiles viennent des utilisateurs d'un autre systeme qui n'a rien a voir avec le nouveau. Au pire, tu copies manuellement le nombre d'etoiles et pis c'est marre.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: service...

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

                  va falloir un jour arrêter la sodomie de drosophiles (pov' bêtes).

                  exporter ses données c'est bien, savoir les importer c'est mieux :-) de l'importance de se poser la question : le service que j'utilise est-il pérenne, en ai-je la maîtrise (là du logiciel libre aide un peu pour l'installer chez soi), puis-je demander des évolutions pour mieux correspondre à mon utilisation ?

            • [^] # Re: service...

              Posté par  . Évalué à 2.

              Est-ce que la notion d'intéropérabilité a vraiment disparue d'une partie des logiciels libres ?

              Elle n'en a jamais vraiment fait partie… La plupart des logiciels libres fonctionnent comme des silos, exactement comme les logiciels propriétaires. L'idée que le logiciel libre soit favorable aux utilisateurs est en large partie une fable. En réalité le logiciel libre est un outil au service des développeurs (les promoteurs du LL étant eux-mêmes en général développeurs, ils oublient de faire la différence).

          • [^] # Re: service...

            Posté par  . Évalué à 5.

            GitLab est un logiciel libre auto-hébergeable. […]

            Vu sur la page d'accueil de github:

            Want to use GitHub on your servers?

            Puis dans la FAQ:

            How is GitHub Enterprise different from GitHub.com?
            GitHub Enterprise includes the same great set of features as GitHub.com but packaged for running on your organization's local network. All repository data is stored on machines that you control, and access is integrated with your organization's authentication system (LDAP, SAML, or CAS). Use GitHub Enterprise when you need complete control over repository and project information.

            À priori github aussi, est "auto-hébergeable".

            Pour ce qui est de l'exportation, c'est comme même mieux d'avoir un accès direct à la base de données, ce qui est possible avec un GitLab auto-hébergé et impossible avec GitHub ou BitBucket.

            Cf. plus haut. Au passage, bitbucket fait la même. En fait, pourquoi les entreprisent fournissent-elle un service gratuit aux dev libres? Parce que ça permets de se faire connaître, et ensuite de vendre aux pro.
            Dans le cas de bitbucket, ils fournissent même un service gratuit limité aux très petites structures (enfin, ils le faisaient avant, j'ai pas regardé depuis bien longtemps). Pas sûr de ce qu'il en est chez github.

      • [^] # Re: service...

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

        Tu peux certainement récupérer tes données brutes sur Github, mais ça ne veut pas dire que tu pourras les réutiliser facilement, parce que si tu n'as pas le logiciel qui va avec tu vas devoir adapter (si c'est dans un format standard ça peut déjà grandement faciliter la tâche). Et Github ça n'est pas que git (qui lui est libre et décentralisé), c'est le système de revue, de bugs etc.

        Pour les données, je ne pense pas que l'on puisse se faire du souci en ce qui concerne Github, tant à l'export (à partir de github), qu'à l'import (vers un autre outil).

        • pour le code : c'est git. Donc tu as toujours l'historique sur ta machine. Export/Import : aucune difficulté
        • issue/pull request : une api permet de tout récupérer au format Json. Un parser pour l'importer dans un autre outils n'est pas très compliqué. Et en cherchant, il doit déjà y en avoir pour certaines forges. Par exemple j'en utilise un qui rapatrie les issues sur ma machine et les mets en forme en html, ce qui me permet de les consulter offline. Sans parler du contenu textuel qui est en markdown, syntaxe prise en charge par de plus en plus d'outils (au pire, le markdown reste tout à fait lisible si il n'est pas interprété).
        • wiki : c'est un dépôt git rempli de fichiers en syntax markdown. Pour exporter, un simple git clone suffit. Et à importer vers un autre outils, là encore, développer une moulinette ne serait à priori pas bien compliqué. D'autant plus que Github a libéré le code de leur système wiki (je n'ai plus le nom en tête). Suffit de l'installer donc.
        • pages perso : le contenu est dans ton dépôt git (branche gh-pages), donc les données sont là. Pour la re-publication sur un autre serveur, installer jekyll et voilà.

        Bref : récupérer les données, aucune difficulté, et pour les importer dans d'autres outils, non plus. Elles sont dans des formats standards (markdown..) ou parfaitement utilisable (structure json pour les issues) et très facile à exporter dans une base de donnée.

        Le seul blocage qui pourrait y avoir, serait le blocage par Github des API, empêchant de récupérer les issues. Ça peut se régler par l'installation dès maintenant d'un script aspirant régulièrement les données, et si un jour github ferme son api, il sera temps de fermer son compte et d'aller s'installer ailleurs ;-)

        • [^] # Re: service...

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

          belle défense de github :-)

          comme quoi le syndrôme de Stockholm touche beaucoup de monde :/

          Dans tout ce que tu décris, pourquoi ne pas être sur gitlab au lieu de github ?

          • [^] # Re: service...

            Posté par  (site web personnel) . Évalué à -3. Dernière modification le 28 février 2016 à 11:38.

            Je te retourne la question : pourquoi ne pas être sur github au lieu de gitlab?
            N'ose quand même pas me sortir que c'est parce qu'ils filent un petit bout en plus de libre que github… C'est assez mineur (rappel : ce qui est bankable dans le logiciel est non libre, et le service centralisé n'est pas plus libre)

            Pourquoi github donc?
            - effet de masse, prime au premier arrivé
            - préférer l'original à la copie (a toi de me dire ce que gitlab apporte en plus), donc si il n'y a rien de plus, pourquoi migrer?

            bref, la question est tournée comme une accusation, perso je demande pourquoi on devrait préférer un service fermé à un autre comme ça, surtout quand il est moins répandu. Quand des gens attaquent un service en négatif, c'est souvent signe quand l'alternative proposé n'apporte rien.
            A toi donc de me dire ce que GitLab m'apporte en plus, pas des trucs qui te plaise, mais ce qui pourrait me plaire, car c'est moi qui doit être convaincu, pas toi.

            PS : ca commence mal quand tu attaque les gens avec "syndrôme de Stockholm" juste parce qu'ils ne pensent pas comme toi, mauvais signe pour croire que tu auras une argumentation honnête (au pire, tu as juste rien compris a ce qui fait le succès de GitHub, pas très positif)

          • [^] # Re: service...

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

            Je n'ai absolument pas le syndrome de Stockholm. Je sais juste reconnaître les qualités. Et github me convient, d'autant plus que, comme je viens de le montrer on peut récupérer les données et les réutiliser sans problème. Faut vraiment être aveuglé par son idéalisme pour ne pas voir que ce ne sont pas des problèmes.

            Figure toi que j'utilise Github, mais aussi Gitlab. Le premier pour mes projets perso et open-source, le deuxième pour mes besoins professionnels, pour les projets de mes clients, en mode privé, parce que ces projets n'ont rien à faire sur github, même en dépôts privés.

            Mais je n'utilise pas Gitlab pour mes projets perso parce que Github facilite le coté social et contributeur.

            Et je n'ai pas toujours utilisé Github : pendant bien longtemps j'avais ma propre forge (sous Trac). Mais au bout d'un moment, maintenir tout ça (les mises à jour, le spam etc) me prenait trop de temps et les fonctionnalités ne correspondaient pas tout à fait à ce que je voulais… (bon, maintenant j'ai un gitlab à maintenir mais comme il est privé, j'ai moins de souci avec le spam ou autre).

    • [^] # Re: service...

      Posté par  (site web personnel) . Évalué à -4. Dernière modification le 26 février 2016 à 13:59.

      Perso, j'ai essayé d'aller un peu plus loin, mais ce n'est pas mieux.
      Par exemple, il utilise un mot stupide "privateur" alors que justement GitHub apporte quelque chose, il ne prive pas. Rappel : Linux utilisait avant git un SCM non libre… Ca en défrise certains, mais on est passé à Git sans problème même avec ce SCM non libre.
      Ensuite il se plaint de l'uniformisation, mais sérieux pourquoi apprendre 10 commande différent pour faire exactement la même chose. L'uniformisation n'est pas le mal, au contraire.
      Quand à la centralisation, c'est ce qui fait la force de GitHub : l'effet de masse fait qu'on se retrouve dans la communauté. Et comme avec Sourceforge, le jour où GitHub l'entreprise déconne on migrera (car c'est basé sur du libre comme Git, donc pas bien compliqué).

      3 points "critiques", 3 avantages ou indifférences en fait. Il n'a rien compris à ce qui fait la force de GitHub, et les intérêts qu'ont les gens (pour la majorité des gens faisant du libre, le libre n'est pas un but mais un moyen).

      GitHub, ça juste marche, et c'est ce qu'on lui demande.

      • [^] # Re: service...

        Posté par  . Évalué à 3.

        Quand à la centralisation, c'est ce qui fait la force de GitHub : l'effet de masse fait qu'on se retrouve dans la communauté. Et comme avec Sourceforge, le jour où GitHub l'entreprise déconne on migrera (car c'est basé sur du libre comme Git, donc pas bien compliqué).

        Exactement ! Et c'est ce qu'on constate très largement ces temps. Un certain nombre de développeurs n'apprécient pas trop la politique de l'entreprise Github en ce moment, alors ils se tournent vers d'autres services utilisant git. Gitlab, par ex., voire Gogs, pour un service auto-hébergé.

      • [^] # Re: service...

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

        GitHub, ça juste marche

        Du moment que tu n'offense pas ses employés, ce qui semble être de plus en plus difficile.

        • [^] # Re: service...

          Posté par  . Évalué à 4.

          Mais c'est comme tout : Si tu utilises un service externe ou de la sous-traitance, il faut un minimum de confiance en ton prestataire. S'il n'y a pas de confiance, peut-être qu'il est temps d'aller voir ailleurs…

          À mon avis c'est plutôt là qu'est l'enjeu, dans l'interopérabilité : est-ce qu'un projet peut migrer facilement de github à quelque chose d'autre ? Le fait que github soit libre ou pas est un problème mineur à côté, sachant qu'il existe des alternatives.

          • [^] # Re: service...

            Posté par  (site web personnel) . Évalué à 5. Dernière modification le 26 février 2016 à 16:00.

            Je pense que l'intérêt de GitHub pour ses utilisateurs est dans le nombre d'étoiles ; ça ne s'exporte pas.

            • [^] # Re: service...

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

              Mais sur une forge comme utilise Goffi sur son propre serveur, les étoiles n'existent pas (sans parler que ça me gonfle de créer un compte par projet).
              Je préfère un truc centralisé qui existe à un truc décentralisé qui n'existe pas.
              A Goffi et l'auteur de la critique de GitHub de proposer (développer?) la version décentralisée si ils veulent montrer que le décentralisé est mieux (ou que GitHub c'est un danger, mais danger de quoi sachant qu'ils ne proposent pas d'alternatives viables?), et surtout que c'est possible.

              • [^] # Re: service...

                Posté par  . Évalué à -1.

                Tout ce qu'apporte GitHub est de la convivialité, on peut donc s'en passer, il n'y a pas de nécessité absolue à ce qu'il existe un ou des outils similaires (GitHub n'est pour moi pas une "alternative"). Pratiquer et/ou encourager à la centralisation et au contrôle pour de la convivialité, c'est un choix de société, il en est bien entendu idem pour l'inverse.

                Il y a beaucoup de projets qui visent l'inclusion numérique pour promouvoir la participation de tout le monde dans la société numérique. Mais est-ce que ce but est bon ou mauvais ? Ça dépend si la société numérique est juste ou injuste. Si la société numérique est injuste, il faut lutter pour notre extraction numérique et pas pour l'inclusion numérique, pas pour l'inclusion dans l'injustice.

                Richard Stallman https://www.april.org/enregistrements-audio-et-video-de-la-conference-de-richard-stallman-lors-des-30-ans-du-projet-gnu

                • [^] # Re: service...

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

                  convivialité, on peut donc s'en passer

                  Voila toute l'explication sur pourquoi certain logiciels libres sont "super mais je ne comprend pas pourquoi personne ne veut utiliser".

                  Pratiquer et/ou encourager à la centralisation et au contrôle pour de la convivialité, c'est un choix de société, il en est bien entendu idem pour l'inverse.

                  Le masochisme est un hobby peu répandu.
                  Choix de société? tu vas loin…

                  Richard Stallman

                  C'est qui? J'avoue que je me fou un peu d'un perdu idolâtré par certains. Je dirai même que ça confirme qu'il y a un soucis si c'est le seul que tu peux avoir comme personne en parlant. J'espère que tu as d'autres références.

                  "alternative"

                  Pitié, pas l'intégrisme anti-logiciel proprio, c'est un peu dépassé comme délire…
                  Si tu veux argumenter, évite ce genre de lien sur des discours d’extrémistes.

                  Merci, en fait tu confirmes par l'absurde que GitHub c'est bien et qu'on a bien raison de l'utiliser, les autres nous disant "la convivialité on peut s'en passer" donc qu'ils ne proposent pas de choix en fait, ils critiquent juste sans proposer d'alternative.

                • [^] # Re: service...

                  Posté par  . Évalué à 5.

                  Tout ce qu'apporte GitHub est de la convivialité, on peut donc s'en passer,

                  C'est vrai, même que c'est pour ça que je code en asm x86. En plus, c'est plus performant. Un jour, je vais me mettre au brainfuck d'ailleurs: après tout, less is more.

                  • [^] # Re: service...

                    Posté par  . Évalué à 4.

                    C'est vrai, même que c'est pour ça que je code en asm x86.

                    Espèce d'accro à la convivialité. Coder pour un processeur RISC des années 80 te ferait le plus grand bien !

                    • [^] # Re: service...

                      Posté par  . Évalué à 4.

                      Ces jeunes qui ne savent plus ce que c'est qu'un petit effort!
                      Moi j'écris directement en hexadécimal!!

                      • [^] # Re: service...

                        Posté par  . Évalué à 2. Dernière modification le 27 février 2016 à 21:57.

                        Il n'y a que les faibles qui n'écrivent pas directement leurs binaire à la main.

                        • [^] # Re: service...

                          Posté par  . Évalué à 10.

                          Mais non, les vrais utilisent des papillons !

                          (je mets quand même le xkcd de rigueur :)
                          xkcd real programmers

                    • [^] # Re: service...

                      Posté par  (Mastodon) . Évalué à 3.

                      Coder pour un processeur RISC des années 80 te ferait le plus grand bien !

                      Je confirme, j'ai déja fait ça, sur un Archimedes :)

                • [^] # Re: service...

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

                  convivialité

                  Une interface web frustrante et limitée plutôt.

                  Je préfère de loin git send-email pour contribuer et tig pour naviguer dans l'historique.

    • [^] # Re: service...

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

      ah c'est bien dommage que tu aies arrêté de lire à ce moment, j'explique justement plus bas pourquoi tu es captif de ce SAAS. C'est d'ailleurs l'un des principaux arguments que je développe dans l'article revu et augmenté que je vais bientôt publier (teaser!).

      • [^] # Re: service...

        Posté par  . Évalué à -1.

        Sauf qu'il y a véritablement un problème de raisonnement à la base en n'étant pas capable de faire la différence entre un service et un logiciel.

        Ce que github a apporté et apporte encore aujourd'hui à la communauté du libre, au fait qu'un pan absolument gigantesque de l'économie de l'IT soit basé sur du code libre, tout en ayant un comportement éthique et une politique d'ouverture forte (oui github publie également du code libre), me donne juste l'impression d'être face à des gens bornés, incapable de mettre leur raisonnement en perspective, "triggered" dans leurs petits principes dont ils peinent eux-mêmes à trouver la cohérence. Un peu comme ces vegans qui refusent de manger du miel parce que ça exploite les abeilles en oubliant un peu vite que sans abeilles, ils n'auraient sans doute pas masse de légumes à manger (j'en connais).

    • [^] # Re: service...

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

      Moi, j'ai arreté de lire quand j'ai vu un autre billet sur un nouveau soft hosté sur github:

      http://carlchenet.com/2016/01/11/feed2tweet-0-2-power-of-the-command-line-sending-your-feed-rss-to-twitter/

      J'ai un compte github car les projets ou je contribue sont dessus, mais plus ça va, et plus je vois que le problème n'est pas purement théorique et pose des soucis de pouvoir adapter le workflow de contribution au logiciel (example, ansible, ou le manque de templates et le fait de pas pouvoir trier les bugs sans avoir de droits de commits, et l'impossibilité de bouger un bug d'un dépot à un autre pose de vrais soucis)

      • [^] # Re: service...

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

        les templates sont apparues il y a quelques jours …

        • [^] # Re: service...

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

          Oui, le jour de l'ansiblefest, après avoir discuté en réunion que c'était relou de pas avoir le support. A la fin de la réunion, l'idée était de faire une surcouche à github pour les bugs.

          Mais même si un template est une addition intéressante, je pense que ça ne remplace pas vraiment une UI. Déjà, tu va rentrer les informations, mais tu peux pas être que que les gens ont mis l'information, tu es obligé de parser le markdown si tu veux agir dessus, ce qui est fragile et risqué. Et bien sur, chacun va devoir faire sa propre solution, et tu ne peux pas vraiment agir sur l'UI de github pour diriger les gens vers la ou tu veux.

          • [^] # Re: service...

            Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 29 février 2016 à 00:25.

            Github ne peut pas vraiment proposer une UI pour ça : ça ne collera jamais avec les besoins de chacun. Il y en aura toujours pour se plaindre qu'ils n'ont pas besoin de tel ou tel champs, et d'autres qu'ils n'ont pas tel ou tel champs.

            • [^] # Re: service...

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

              Tu peux assez facilement créer des formulaires avec une interface graphique. C'est le cas avec Wordpress pour les formulaires de contact : tu as une grosse dizaine de briques de base (ligne de texte, date, courriel, heure, bloc de texte, choix de valeurs, …) que tu choisis pour créer ton formulaire personnalisé et qui est validé automatiquement.
              Certes, ça ne plaira pas à 100% des gens, mais peut-être à 95% (voire davantage).

            • [^] # Re: service...

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

              C’est pourtant pas dur de faire une page d’administration où tu peux ajouter toi-même les champs (tu choisis le label, le type, la liste des valeurs possibles si besoin, si le champs est obligatoire, et c’est torché).

              C’est le genre de features qui font que pour l’instant je reste sur redmine et que je passe pas sur le bugtracker de gitlab.

    • [^] # Re: service...

      Posté par  . Évalué à 5.

      Le système de ticket est propriétaire.

      Mais le danger d'un système centrale pour moi est la propriété des identités des utilisateurs. Ce que je déteste les gens qui me demande mon facebook ! J'ai une adresse mail bordel ! Pareil pour github, tu ne peux pas contribuer avec une identité externe.

  • # Gitlab

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

    Je n'utilise que gitlab qui me convient parfaitement. Je n'ai jamais utilisé Github.
    Pourriez-vous m'indiquer les avantages de github par rapport à gitlab ?

    • [^] # Re: Gitlab

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 26 février 2016 à 14:06.

      Il y a plus de monde qui est sur Github. Github était là avant. C'est plus populaire.

      Mais par contre, c'est vrai que Gitlab fait un taf remarquable et que son interface est de plus en plus sympa.

      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

    • [^] # Re: Gitlab

      Posté par  . Évalué à 2. Dernière modification le 26 février 2016 à 17:31.

      Pourriez-vous m'indiquer les avantages de github par rapport à gitlab ?

      La partie sociale (étoiles, etc)
      La centralisation (je peux forker n'importe quoi sans devoir me ré-inscrire sur un enième serveur).
      Facilité de mise en place (j'ai tenté d'installer un gitlab sur un ordinosaure il y a quelques mois, résultats : pas compatible 32bit).
      Moins chers (gitlab nécessite une bonne poire pour entretenir le serveur et le financer).
      Résistance (plus difficile de DDOS Github qu'un serveur auto-hébergé).
      Par contre sur Github c'est payant de faire des projets privé.

      Après en ré-utilisant des technologies déjà existantes (je pense surtout au F2F), on pourrait faire un truc dé-centralisé avec exactement les mêmes avantages.

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: Gitlab

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

        Tu peux aussi utiliser le service d'hébergement proposé par gitlab qui est assez proche de ce que propose Github.

        Il y a par contre moins de projets mais tu peux avoir des dépôts privés.

        La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

      • [^] # Re: Gitlab

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

        Tu pars du principe qu'il faut installer gitlab sur son propre serveur. Mais il suffit de créer son dépôt sur gitlab.com et on a les mêmes avantages, avec, en plus la possibilité de tout ramener le jour ou il y a un problème !

        • [^] # Re: Gitlab

          Posté par  . Évalué à 2.

          Quelles sont les différences entre le service GitLab et le service GitHub (j'ai été zieuter le lien poster par Thom mais ne me suis pas inscris)?

          en plus la possibilité de tout ramener le jour ou il y a un problème !

          Github ne m'empêche à aucun moment de re-télécharger l'entièreté de mes projets.

          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

          • [^] # Re: Gitlab

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

            Github ne m'empêche à aucun moment de re-télécharger l'entièreté de mes projets.

            as-tu essayé de les placer ailleurs ?
            L'exercice te semble facile : autant essayer :-)

            Le jour où github ne sera plus joignable, tu seras content d'avoir tes données à disposition en local pour les remettre en ligne.
            Ce n'est pas l'export qui compte, c'est la capacité à restaurer (et savoir le faire).

            • [^] # Re: Gitlab

              Posté par  . Évalué à 0.

              as-tu essayé de les placer ailleurs ?

              Ouaip => owncloud :) (+ copie sur les pc de dev)

              Je trouverais d'ailleurs génial la création d'un module permettant d'intégrer une sorte de GitLab directement a owncloud, histoire de pouvoir coder via ma tablette en utilisant l'interface web :)

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • # Pagure

    Posté par  . Évalué à 6. Dernière modification le 26 février 2016 à 15:41.

    À essayer:

    Pagure is a git-centered forge, python based using pygit2.
    With pagure you can host your project with its documentation, let your users report issues or request enhancements using the ticketing system and build your community of contributors by allowing them to fork your projects and contribute to it via the now-popular pull-request mechanism.

    https://pagure.io/pagure

  • # Le non-danger Github

    Posté par  . Évalué à 9.

    Un contrepoint intéressant:
    http://agateau.com/2016/github-lock-in/

    L’essentiel est de dire que tu as (aujourd’hui) accès à tes données (comme d’autres le disent ici.), et que la migration entre différentes plateformes(libres ou pas) est toujours complexe. Github ne verrouille pas comme on pourrait le penser.

    • [^] # Re: Le non-danger Github

      Posté par  . Évalué à 5.

      Mais ta communauté de contributeurs appartient à Github.
      C'est le propre des réseaux sociaux privées aujourd'hui.
      Si Github ferme ou si tu n'es plus satisfait du service, tu perds et dois reconstruire ta communauté.
      Un jour, un système fédéré vaincra, I hope.

  • # On refait le match

    Posté par  (Mastodon) . Évalué à 10.

    J'ai l'impression de lire les mêmes arguments qu'il y a 10 ans sur Sourceforge. Ne vous inquiétez pas, si Github déconne trop, il y aura une autre forge propriétaire qui viendra la remplacer pour héberger tous les projets libres.

    • [^] # Re: On refait le match

      Posté par  . Évalué à -1.

      Que veux-tu, il y en aura toujours pour se lancer dans une partie de branle-couille.

  • # Une perte de valeurs ?

    Posté par  . Évalué à 8.

    Vous me faites marrer quand même sur lfr.

    Vous êtes censés promouvoir certaines valeurs du genre:

    • si ce qui existe ne te plait pas, fais-le toi-même
    • le tout centralisé, c'est mal
    • l'auto-hébergement
    • la confidentialité
    • la pensée unique
    • etc.

    Promouvoir github et dire que gitlab n'est pas une alternative viable, c'est tout le contraire de ces principes.

    Sans compter que non seulement gitlab est une alternative parfaitement viable techniquement, en plus d'étendre de façon considérable les fonctionnalités de github. Il y a toute une panoplie d'outils satellites, d'import, etc. que github n'aura jamais.

    Moi, ce que je retiens de cet article que j'ai par ailleurs trouvé excellent, c'est le doigt pointé sur l'ostracisation des Libristes, de ceux qui ont encore des valeurs. C'est 100% vrai, et c'est absolument déplorable. Mais ce que je trouve de plus triste, c'est que même entre Libristes on trouve le moyen de se livrer des guerres de clocher, alors qu'on œuvre tous dans un même but: la promotion de nos valeurs.

    • [^] # Re: Une perte de valeurs ?

      Posté par  . Évalué à 2.

      Vous me faites marrer quand même sur lfr. Vous êtes censés promouvoir certaines valeurs du genre:

      Rien à la consultation ou l'inscription du site web ne demande pas cela.

      Moi, ce que je retiens de cet article que j'ai par ailleurs trouvé excellent, c'est le doigt pointé sur l'ostracisation des Libristes, de ceux qui ont encore des valeurs. C'est 100% vrai, et c'est absolument déplorable. Mais ce que je trouve de plus triste, c'est que même entre Libristes on trouve le moyen de se livrer des guerres de clocher, alors qu'on œuvre tous dans un même but: la promotion de nos valeurs.

      LinuxFr est avant tout un site web technique. Il y a clairement une partie politique, mais elle passe en deuxième, il ne faut donc pas s'étonner que certains points de vue politiques soient divergents d'une manière significative.
      De plus, il ne faut pas oublier qu'une grande partie des sujets techniques abordés sont liés au logiciel libre et à l'open-source . L'open-source est un fork du logiciel libre avec l'éthique, c'est d'ailleurs pour ça que Stallman déteste qu'on lui dise qu'il est un pro logiciels open-source ou pire qu'il a créé le concept.

    • [^] # Re: Une perte de valeurs ?

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

      Vous êtes censés promouvoir certaines valeurs du genre:

      ???????????

      Promouvoir github et dire que gitlab n'est pas une alternative viable, c'est tout le contraire de ces principes.

      Zut alors, dire ce qu'on analyse est interdit, si ça ne va pas dans le sens que tu as décidé.

      non seulement gitlab est une alternative parfaitement viable techniquement

      Merci de la démonstration, tu dis clairement que GitLab n'est pas une alternative viable, tu t'es senti obligé de mettre "techniquement".
      Spoiler : justement, c'est la partie non technique qui fait sa force.

      c'est le doigt pointé sur l'ostracisation des Libristes (…) c'est que même entre Libristes on trouve le moyen de se livrer des guerres de clocher, alors qu'on œuvre tous dans un même but: la promotion de nos valeurs.

      Je suis bien d'accord sur l'ostracisation : faudrait absolument que les libristes soient "purs", et n'utilisent pas de non libre. Pas de chance, le libre marche surtout grâce à des utilisateurs de Mac et GitHub.
      Sérieux, qui fait dans l'ostracisation entre les gens acceptant le non libre quand c'est mieux et les gens refusant le non libre (enfin, bizarrement ils acceptent leur CPU et BIOS non libres, mais font la morale sur GitHub, la bonne blague, c'est juste de faux-cul ayant décidé que leur limite arbitraire de non libre devait être celle de tout le monde)?

      GitHub, c'est comme ton BIOS (je parie que tu l'acceptes non libre, pourquoi donc? il y a des BIOS libres!) : il y a des alternatives libres, mais pas foule les utilises, pour des raisons bien claires.

      l'ostracisation est parfois du côté de l'accusateur.

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à 5.

        C'est encore bizarre, cette manie de reprocher aux autres de ne pas être parfait par rapport à ce qu'ils promeuvent, alors qu'ils cherchent à faire de leur mieux avec ce qu'ils ont (en temps, en énergie, en compétence…), et vu l'environnement dans lequel ils vivent.

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à 3.

        ???????????

        Quoi ? C'est "valeur" que t'as pas compris ?

        tu dis clairement que GitLab n'est pas une alternative viable

        Ouh, mais tu persiste à faire dire aux gens ce qu'ils n'ont pas dit. Relis-moi bien :)

        Par contre, je te cite:

        A Goffi et l'auteur de la critique de GitHub de proposer (développer?) la version décentralisée si ils veulent montrer que le décentralisé est mieux (ou que GitHub c'est un danger, mais danger de quoi sachant qu'ils ne proposent pas d'alternatives viables?)

        Or, au moins une alternative est proposée, je te le donne en mille: Gitlab. Tu n'as même pas lu l'article à propos duquel tu viens cracher ton venin. Faut oser…

        Je suis bien d'accord sur l'ostracisation : faudrait absolument que les libristes soient "purs"

        Tu te méprends, je ne suis pas un intégriste du Libre, mais si une solution alternative Libre existe, elle devrait être promue et utilisée, préférentiellement aux logiciels privateurs (ne t'en déplaise).

    • [^] # Re: Une perte de valeurs ?

      Posté par  . Évalué à 5.

      Vous êtes censés promouvoir certaines valeurs du genre:

      Ah bon… selon qui ? Es-tu l'autorité en matière de "valeurs du libre" ? Je n'ai pas vu que tu aies été élu pour cela, et même si tu l'avais été, cela serait à mon avis une justification insuffisante.

      Il faut arrêter de se moquer du monde : je ne vois pas en quoi "pensée unique", "confidentialité", etc. seraient des mots-clés pour comprendre le logiciel libre. Que cela fasse plaisir à certains militants de se réclamer de tels mots d'ordre, tant mieux pour eux (cela tient de l'activité de production de slogans, pauvre politiquement mais sentimentalement réconfortante, c'est-à-dire que l'on s'assigne symboliquement au camp des gentils), mais qu'ils ne viennent pas dire à tous les autres comment ils doivent se comporter pour être dignes de leurs idées.

      Quant au fait même d'invoquer des "valeurs", c'est-à-dire des choses que l'on se défend de discuter car cela serait une insulte aux conventions ou à la tradition, c'est un discours de type religieux. Je ne dois pas être le seul à qui ça pose problème…

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à -2.

        Ah bon… selon qui ?

        https://linuxfr.org/informations

        Membre de l'APRIL, tout ça. Mais bon si ça n'a pas de valeur, moi ce que j'en dis…

        • [^] # Re: Une perte de valeurs ?

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

          L'association LinuxFr est membre de l'April.
          L'association LinuxFr gère le site LinuxFr.org qui accueille des visiteurs qui ne sont pas forcément membres de l'April ou en accord avec les idées de l'April.
          Parce que sinon les régions Île-de-France, Provence Alpes Côte d’Azur et Rhone-Alpes sont membres de l'April…

          • [^] # Re: Une perte de valeurs ?

            Posté par  . Évalué à -4.

            Bien sûr, mais je croyais qu'il était raisonnable de penser que sur un site appelé linuxfr et de surcroît membre de l'April, avec des "publicités" (terme non péjoratif ici) interstitielles consacrées à la promotion du Libre on aurait tendance à (ne) trouver (que) des militants pour le Libre. Je m'étonne donc d'en voir certains promouvoir github aux dépends de solutions alternatives viables, surtout à la vue du contenu de leurs propres articles passés. Je ne fais que relever une dissonance, une inconsistance entre les propos de ces personnes en commentaire à ce journal, par rapport à leur propre vision des choses dans d'autres contextes.

            Le lien vers la page d'informations du site ne servait qu'à répondre à une attaque sur la légitimité de mes propos. Car si l'on me pose la question "Es-tu l'autorité en matière de "valeurs du libre"", bien sur que non. Mais en tant que militant, comme le site que je visite, il me semble que cela me confère un certain droit à la parole.

            • [^] # Re: Une perte de valeurs ?

              Posté par  . Évalué à 3. Dernière modification le 28 février 2016 à 14:16.

              GitHub est un service, pas un logiciel.
              Pour utiliser le service GitHub on se sert de logiciel libre.

              C'est comme comparer Thunderbird à Gmail, ce n'est pas logique.

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

            • [^] # Re: Une perte de valeurs ?

              Posté par  . Évalué à 7.

              Si ça se trouve, le logiciel utilisé par Github est sous licence GPL, même si c'est peu probable. Mais comme ce logiciel n'est utilisé que chez eux, bah on n'en sait rien.

              Encore une fois, quand il s'agit de service, ce n'est pas le logiciel qui tourne sur le serveur qu'il faut regarder, c'est la donnée.

            • [^] # Re: Une perte de valeurs ?

              Posté par  . Évalué à 4.

              Je m'étonne donc d'en voir certains promouvoir github aux dépends de solutions alternatives viables

              1. Il faut distinguer promouvoir et relever des erreurs dans les critiques.
              2. « viables » justement certains ici, le remettent en cause
              3. Certains remettent en cause, le fait même que ce soit une alternative :)

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

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à -4.

        c'est un discours de type religieux

        Dans ce cas l'April, la Quadrature du Net, la fondation Linux, la fondation GNU, l'EFF, sont des organismes à caractère religieux ? Ce sont des sectes ?

        Ils œuvrent pour la protection de ta vie privée. Et ça passe par la promotion du Libre.

        Ah mais peut être que tu n'avais rien demandé… Désolé, je viens d'apprendre que j'appartiens "au camp des gentils" :)

        • [^] # Re: Une perte de valeurs ?

          Posté par  . Évalué à 4.

          C'est la pensée "marabout de ficelle" : on prend un bout de mon message, on le cuisine à sa propre sauce, on extrapole indûment et on en conclut que j'aurais affirmé que l'APRIL est une secte.

          Pas envie de répondre à ce genre de conneries, désolé. Que les zozos dans ton genre apprennent d'abord à échanger sérieusement au lieu de se croire dans une réunion de parti politique…

    • [^] # Re: Une perte de valeurs ?

      Posté par  . Évalué à 0.

      La seconde oû j'ai vu le mot "pensée unique" j'ai compris que tu étais un guignol à tendance dictatoriale.

      Ce qu'il y a d'heureux c'est que les clowns dans ton genre sont une infime minorité qui n'aura jamais aucun poids dans le monde réel. Vous serez toujours une poignée à vous branler en cercle sur vos pensées délirantes en vous demandant pourquoi le monde ne vous comprend pas.

    • [^] # Re: Une perte de valeurs ?

      Posté par  . Évalué à 9.

      on œuvre tous dans un même but: la promotion de nos valeurs.

      Non. D'une part une bonne partie des libristes ne cherchent pas à faire d'entrisme et considére que la morale n'a rien avoir là dedans. C'est par exemple le cas de Linus Torvald. D'autres part on ne défend pas tous les même valeurs et les valeurs que tu avance ne me parlent pas. D'ailleurs tu es contre la pensée unique tout en voulant nous faire marcher droit ?!

      Pour ta réponse en-dessous, je ne suis pas membre de l'association linuxfr et mon inscription sur le site ne m'engage qu'à respecter les lois et les règles de bienséance sur le site.

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

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à -2.

        Tu arbore le logo debian sur ton avatar et tu prétends ne pas te reconnaitre dans les valeurs que j'indique ?

        Tu te préoccupe de la notion de service ouvert et tu ne te reconnais pas dans les valeurs que j'indique ?

        • [^] # Re: Une perte de valeurs ?

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

          (aparté : cet avatar Debian en jpg est moche, il bave, il est flou, etc. Ça serait mieux de le remplacer par un PNG propre.)

        • [^] # Re: Une perte de valeurs ?

          Posté par  . Évalué à 9.

          Ok alors tu as un gros problème mon gars. Mais un vrai sacré foutu gros problème !

          Debian est un projet communautaire autour du logiciel libre. Rien avoir avec des services (il propose aussi des services, mais ce n'est pas le cœur de la communauté). La communauté Debian n'est pas un ensemble compact et uniforme. C'est hétéroclite et la seule chose qui doit à peu près mettre tout le monde d'accord c'est le contrat social Debian (strictement rien avoir avec ce dont tu parle) et la définition du LL selon Debian (qui recoupe sur certains point ce dont tu parle et s'en écarte sur d'autre).

          Tu n'a pas du comprendre ma définition de service ouvert, je ne peux que te recommander de lire le journal, les commentaires associés.

          Je pense que tu devrait songer au fait qu'il y a (au moins) 2 façons de voir le logiciel libre :

          • une collectivisation des ressources qui se rattache à des idées très à gauche
          • l'expression la plus pure de la concurrence libre et non faussée qui se rattache à un libéralisme pas vraiment de gauche

          Bref ce n'est pas parce que tu as une façon de voir les choses que c'est la seule façon de les voir.

          Encore une fois tout le monde, ne se veut pas être militant. Puisque tu aime bien aller regarder l'historique du site, on a une super interview de Linus Torvalds :

          La première réponse, très négative, c’est que je méprise complètement les gens qui tentent de pousser la GPL comme étant de type « éthique ». Je pense que c’est de la pure connerie. Pourquoi ? Parce que l’éthique, pour moi, c’est quelque chose de privé. Chaque fois que vous l’utilisez dans un argument pour dire pourquoi quelqu’un d’autre devrait faire un truc, alors vous n’êtes plus éthique. Vous devenez juste une tête de con moralisatrice.

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

        • [^] # Re: Une perte de valeurs ?

          Posté par  . Évalué à -6.

          Debian supporte la "pensée unique" comme valeur ?

          Stalin et Hitler le faisaient, j'étais pas au courant pour Debian.

          • [^] # Re: Une perte de valeurs ?

            Posté par  . Évalué à 5.

            Ouais, ouais, il a lu ca sur le site web de debian.
            Il a approve le cert tls lui meme, a la main, alors c'est bien la preuve que c'etait le bon site debian.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Une perte de valeurs ?

          Posté par  . Évalué à 7.

          Tu es au courant que Debian n'est pas reconnue franco par la FSF parce que Debian favorise l'installation de logiciel non libres?
          Tu es au courant que Debian considère certaines licences créées par la FSF comme non-libre (notamment celle utilisée pour la doc de GCC)?

          Bref, va revoir ta copie.

    • [^] # Re: Une perte de valeurs ?

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

      Promouvoir le logiciel libre, c'est avant tout y contribuer, pas se branler la nouille sur Linuxfr parce que on est plus intégriste que les autres…

      • [^] # Re: Une perte de valeurs ?

        Posté par  . Évalué à 6.

        En effet et c'est un élément qui rend le LL difficile à appréhender pour les organisations politiques (même si le LL lui-même peut être politique) : sa logique est éloignée de celle du militantisme politique traditionnel qui fonctionne par slogans, revendications, proclamations doctrinales.

        Là l'auteur du message du dessus fait du militantisme au carré, puisqu'il nous enjoint d'adhérer aux « valeurs » qui l'arrangent lui… Démarche qui peut fonctionner dans un collectif militant (à condition d'avoir du bagout, de la gueule, du prestige ou des amis pour faire la claque), moins dans une communauté LL.

        • [^] # Re: Une perte de valeurs ?

          Posté par  . Évalué à 3.

          (à condition d'avoir du bagout, de la gueule, du prestige ou des amis pour faire la claque)

          Tu as oublié de l'argumentation. Il en faut un minimum, que ce soit pour convaincre ou pour persuader. Hors, là on est proche du 0°K…

  • # Gitlab / Gog / Redmine /Trac

    Posté par  . Évalué à 3.

    Au passage quelqu'un a compris la différence entre Gitlab / Gog / Redmine /Trac ?

    • [^] # Re: Gitlab / Gog / Redmine /Trac

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

      Alors en gros (évidemment, c’est mon avis subjectif personnel rien qu’à moi) :

      Redmine c’est très souple, le bug tracker est très bien, par contre c’est vieillissant, ça n’évolue quasiment plus, et il n’y a pas de truc de Continous Integration.

      Gitlab c’est moderne, ça évolue rapidement, y’a un truc de Continous Integration, mais le bug tracker est calqué sur celui de github donc il est très limité. Ça ressemble beaucoup plus à github (le point central étant le dépôt git et le reste est un peu optionnel à côté) plutôt qu’à une forge « traditionnelle » (où le dépôt des sources n’est qu’un module parmi d’autres).

      Trac c’est un peu comme redmine mais en moche et dès que t’écris en camelCase un truc ça te fout un lien pété donc c’est super nul.

      Gog j’ai pas essayé.

      • [^] # Re: Gitlab / Gog / Redmine /Trac

        Posté par  . Évalué à 2.

        Redmine c’est très souple, le bug tracker est très bien

        Je confirme, le bugtracker est vraiment propre. L'intégration de git, par défaut, laisse à désirer par contre, dans le sens ou on ne peut pas coder via browser, mais il me semble qu'il y a des plug-in pour l'améliorer.

        Perso j'aime bien aussi le système de roadmap de redmine, je le trouve clair. Le reste des modules, je ne les ai pas trop testés. Ah, et aussi LE gros avantage de redmine sur toutes les forges modernes: pas besoin de javascript et donc c'est juste… instantané. Ici, pour aller voir les bugs sur, par exemple, glfw, en venant de github, ça me prend au pifomètre 2s. Et c'est une fonctionnalité basique, aller voir les bugs.

        Trac c’est un peu comme redmine

        Parce que redmine est un fork de trac, il me semble.
        Sinon dans le genre vielles forges abandonnées (concurrents à trac quoi), il y a aussi savane que j'ai utilisé un peu via gna et savanna.nongnu à une époque, mais c'est… primitif, je dirais, à moins que ça aie changé mais j'en doute (doute confirmé par un rapide coup d'œil sur savannah.nongnu).

        Pareil, Gog je connais pas par contre.

        • [^] # Re: Gitlab / Gog / Redmine /Trac

          Posté par  . Évalué à 4.

          Parce que redmine est un fork de trac, il me semble.

          Non, l'un est en ruby (ror), l'autre en python.

          Redmin est bien sur beaucoup de point. Le fait de pouvoir modifier le code en ligne est AMHA très secondaire. Redmine a un bon gestionnaire de bug, que l'on peut encore améliorer avec un affichage en post-it. Il a une gestion des fichiers décent et il son wiki est pas mal.

          Après si vous voulais tester la Rolls des gestions de bug, il y a JIRA, c'est pas libre, mais tu peux TOUT faire (définition des cycles de vie de tes tickets, avec gestions des rôles et interface différentes pour chaque étape, création de champs personnalisé - tu peux aller jusqu'à coder tes propres champs calculé - et LA killer-feature une intégration de très bonne facture à balsamiq).

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

          • [^] # Re: Gitlab / Gog / Redmine /Trac

            Posté par  . Évalué à 2.

            Non, l'un est en ruby (ror), l'autre en python.

            Autant pour moi.

            Je me suis mélangé les pinceaux avec de vieux souvenirs, après un rafraîchissement mémoire sur wikipedia, il semble qu'il ne soit que inspiré par l'interface. C'est redmine qui à été forké (bluemine/chiliproject, mort forké à nouveau en openproject). Et le fork de trac c'est apache bloodhound.

            Reste à voir ce que valent les fork.

            • [^] # Re: Gitlab / Gog / Redmine /Trac

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

              C'est redmine qui à été forké (bluemine/chiliproject, mort forké à nouveau en openproject).

              Oh, je connaissais chiliproject mais pas openproject, je vais voir ça d’un peu plus près.

              (Par contre, paye ton nom à la noix)

              • [^] # Re: Gitlab / Gog / Redmine /Trac

                Posté par  . Évalué à 2.

                Oh, je connaissais chiliproject mais pas openproject, je vais voir ça d’un peu plus près.

                Moi non plus, à la base. Merci wikipedia :)

                (Par contre, paye ton nom à la noix)

                On sent les mecs super inspirés oui…

  • # Fossil

    Posté par  . Évalué à 7.

    Un peu HS, mais je suis toujours un peu surpris de voir à quel point git est prépondérant parmis les gestionnaires de version, alors que sous certains aspects ça ne semble pas le truc le plus simple à déployer. Fossil a moins de fonctionnalités donc ne peut convenir à tous les projets probablement (plus adapté a des projets de petite ou moyenne envergure), mais propose par contre de lui-même (pas un truc externe) gestion de bugs et wiki de façon décentralisée (le tout stocké dans un seul fichier sqlite), et des options par défaut qui me semblent plus adaptées aux petits projets (push automatique après commit par exemple), donc je suis surpris qu'il n'ait pas plus d'utilisateurs.

    • [^] # Re: Fossil

      Posté par  . Évalué à 4.

      Fossil a moins de fonctionnalités […] mais propose […]

      Il a, en fait, plus de fonctionnalités, mais moins avancées. J'ai testé très rapidement a un moment, le fait d'avoir le wiki et le bugtracker intégrés me plaisaient bien.

      Mais, voila, quand je l'ai testé, le bugtracker nécessitait pas mal de bidouillages pour avoir un truc correct, et je n'avais pas réussi a rendre l'interface en ligne de commande aussi agréable (pas trouvé a l'époque comment mettre la couleur, et je ne peux pas me passer de ça).

      Autres inconvénients majeurs à mes yeux: celui qui veut utiliser un autre gestionnaire de projet (et non de code) se retrouve du coup avec du bloat (code inutile) en la présence justement du wiki et du bugtracker intégrés. Et pour finir, je ne connais pas de forge (service) proposant fossil, hors, ce dont on parle quand on parle de forge, c'est le plus souvent du service de forge, et non des logiciels derrière. Parce que perso, je n'ai strictement jamais aimé l'interface de github, que je trouve trop bordélique et lourde (je préférai SF.net quand c'était pas infesté, d'ailleurs SF à toujours des fonctionnalités que je ne vois pas chez les nouveaux acteurs), chez les nouveaux je préfère bitbucket. Pas encore testé gitlab.

      push automatique après commit par exemple

      Je ne comprend pas… tu veux dire qu'à chaque commit, tout est balancé sur le web sur un répo central? Ça casse un des arguments majeurs en faveur des DVCS, qui est de pouvoir coder dans le train (entres autres). Et ce comportement ne me semble pas favoriser l'usage de commit nombreux et atomiques (si je dois attendre que ma connection se synchronise avec un serveur, je vais avoir tendance à faire de gros commit regroupant plusieurs modifications, comme à l'époque de SVN).

      Bref, j'aime bien l'idée de fossil, qui est d'être une forge (et non juste un DVCS) simple à déployer, mais en fait quand j'ai testé (il y à 3 ans, +/-) ce n'était pas encore ça. Le truc le plus utile du bouzin (je veux dire le gros avantage) nécessitait de bidouiller du SQL brut, et moi, le SQL c'est un truc que j'évite de toucher, j'aime pas, c'est comme ça (ça vous pète à la tronche au moindre relâchement j'ai l'impression).
      Au fond, redmine est certes plus complexe à déployer, mais me semble plus utilisable out of the box. Pire, les devs n'ont que rarement un seul projet, alors le coût de déploiement du redmine se divise par le nombre de projets, tandis que celui de fossil se multiplie (configuration à refaire à chaque fois, notamment pour les ticquets).
      Jamais testé les autres forges ou couples bugtracker+wiki.

      • [^] # Re: Fossil

        Posté par  . Évalué à 5.

        (pas trouvé a l'époque comment mettre la couleur, et je ne peux pas me passer de ça).

        Pas de couleurs maintenant non plus, ça n'a pas changé sur ce point il me semble (perso, ça ne me gêne pas trop dans ce cas).

        Autres inconvénients majeurs à mes yeux: celui qui veut utiliser un autre gestionnaire de projet (et non de code) se retrouve du coup avec du bloat (code inutile) en la présence justement du wiki et du bugtracker intégrés.

        Fossil est distribué comme un unique binaire, bien plus petit que celui de git (chez moi 1.6M contre 1.9M pour git et 2.2M pour libgit.a, sans compter d'autres binaires et fichiers qui viennent avec git comme la doc (qui est incluse aussi dans le binaire dans le cas de fossil)), donc « bloat » c'est vraiment pas le mot que j'emploierais pour ce logiciel.

        Et pour finir, je ne connais pas de forge (service) proposant fossil, hors, ce dont on parle quand on parle de forge, c'est le plus souvent du service de forge, et non des logiciels derrière.

        Il y a Chisel, qui utilise du logiciel libre en plus.

        Le truc le plus utile du bouzin (je veux dire le gros avantage) nécessitait de bidouiller du SQL brut

        Je n'ai jamais eu à utiliser de requêtes SQL manuellement (d'ailleurs c'est déconseillé fortement : c'est la seule façon de risquer de corrompre le dépôt ou de faire une bêtise). Parce que pour le reste, les dépôts fossils sont très fiables, en partie du fait justement d'utiliser sqlite qui a fait ses preuves (probablement la base de données la plus déployée), et de l'utilisation de checks d'intégrité supplémentaires lors des opérations (ce qui ne fait peut-être par contre pas de fossil le plus rapide des DVCS).

        • [^] # Re: Fossil

          Posté par  . Évalué à 0.

          Pas de couleurs maintenant non plus, ça n'a pas changé sur ce point il me semble (perso, ça ne me gêne pas trop dans ce cas).

          C'est à dire que pour faire des diff avant un commit, je trouve ça bien pratique la couleur, sachant que je passe le plus clair de mon temps dans mon terminal.

          donc « bloat » c'est vraiment pas le mot que j'emploierais pour ce logiciel.

          J'ai utilisé celui-la parce que je ne voyais pas quel autre mot utiliser.
          Ceci dit, s'il faut comparer les binaires, soyons complets:

          Sur une Debian stable:

          Le binaire fossil importe (ldd $(which fossil) | cut -f1 -d' '):

              linux-vdso.so.1
    libsqlite3.so.0
    libssl.so.1.0.0
    libcrypto.so.1.0.0
    libz.so.1
    libreadline.so.6
    libdl.so.2
    libc.so.6
    libpthread.so.0
    libtinfo.so.5
    /lib64/ld-linux-x86-64.so.2

          Celui de git:

              linux-vdso.so.1
    libpcre.so.3
    libz.so.1
    libresolv.so.2
    libpthread.so.0
    librt.so.1
    libc.so.6
    /lib64/ld-linux-x86-64.so.2

          J'avoue être surpris la.
          Bon, les tailles de binaires:

          fossil:

          • libsqlite3.so.0: 802Ko
          • libssl.so.1.0.0: 384Ko
          • libcrypto.so.1.0.0: 2Mo
          • libreadline.so.6.3: 291Ko
          • libdl-2.19.so: 19Ko
          • libtinfo.so.5.9: 168Ko
          • fossil: 1.3Mo

          total: 4.925Mo (en considérant les Ko comme Kio, c'est à dire en les divisant par 1024).

          git:

          • libpcre.so.3.13.1: 438Ko
          • libresolv-2.19.so: 83Ko
          • librt-2.19.so: 32Ko
          • git: 1.7Mo

          total: 2.24Mo (idem, Ko=>Kio).

          Vainqueur: git. Du simple au double, quand même, bien que je n'aie pas intégré les lib communes (la flemme).
          Je suis le premier surpris, je ne m'attendais pas a ça, et il ne faut pas oublier qu'on est en train de comparer des torchons et des serviettes.
          Pire, c'est de l'édition de liens dynamique, si ça se trouve la moitié du code dans les lib chargées par fossil n'est pas utilisé. Il faudrait des binaire liés en statique, pour en avoir vraiment le cœur net.

          La seule chose que tout ça prouve, c'est que comparer la taille du binaire exécutable et d'une seule lib est super partiel. Et que les dépendances des paquets Debian sont foireuses, parce que dans aptitude j'ai pas vu la moitié de ces libs pour fossil…

          PS: libgit.a, c'est pour les outils qui utilisent git, git lui-même ne s'en sert pas. Édition de liens statique, d'ailleurs, si je me trompe pas.

          • [^] # Re: Fossil

            Posté par  . Évalué à 8.

            Oh mon dieu, 2.7Mo de code en plus, c'est vraiment le bout du monde!
            Ta machine va s'ecrouler devant tant de bloat.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Fossil

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

              640 ko devrait être suffisant a dit un mec, un jour, il y a longtemps visiblement…

              • [^] # Re: Fossil

                Posté par  . Évalué à 2.

                En fait il ne l'a jamais dit. C'est une citation apocryphe.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Fossil

              Posté par  . Évalué à 2.

              2.7M de code plus, c'est 2.7M ou tu peux avoir des bugs de plus. Donc, il se pourrait bien que si, comme il se pourrait que non.

          • [^] # Re: Fossil

            Posté par  . Évalué à 4.

            Pire, c'est de l'édition de liens dynamique, si ça se trouve la moitié du code dans les lib chargées par fossil n'est pas utilisé. Il faudrait des binaire liés en statique, pour en avoir vraiment le cœur net.

            Ce n'est pas une méthode de mesure idéale, non :) Ceci dit, chez moi fossil n'importe pas autant de trucs (en particulier pas readline), et git par contre importe libcryto (qui semble faire presque toute la différence chez toi). Enfin, peut-être que mesurer le nombre de lignes de code ou un autre truc serait plus utile, mais dans les deux cas ça ne me semble pas être des logiciels particulièrement lourds au point que ça puisse être un critère pour en choisir un ou l'autre ;)

            • [^] # Re: Fossil

              Posté par  . Évalué à 3.

              donc « bloat » c'est vraiment pas le mot que j'emploierais pour ce logiciel.

              J'ai utilisé celui-la parce que je ne voyais pas quel autre mot utiliser.

              dans les deux cas ça ne me semble pas être des logiciels particulièrement lourds

              Ce n'est pas vraiment le poids, mais je n'aime pas avoir des programmes qui font doublon, ou dont je sais qu'il y a peu de chances que j'utilise la moitié des fonctionnalités de base.

              Ceci dit, chez moi fossil n'importe pas autant de trucs (en particulier pas readline)

              Le problème de Debian: à force de vouloir être universels, ils compilent en full-options.

              • [^] # Re: Fossil

                Posté par  . Évalué à 2.

                Ce n'est pas vraiment le poids, mais je n'aime pas avoir des programmes qui font doublon, ou dont je sais qu'il y a peu de chances que j'utilise la moitié des fonctionnalités de base.

                Dans l'idée je suis d'accord, mais en même temps, c'est un peu inévitable (je ne connais pas de loin la moitié des fonctionnalités de git non plus, ni de beaucoup de programmes que j'utilise). Et il faut voir aussi est-ce que certains composants sont très réutilisés ailleurs ou non (par exemple sqlite et libcrypto, il y a de bonnes chances que tu en aies besoin pour pas mal de logiciels), donc je pense qu'il faut relativiser suivant les cas.

                • [^] # Re: Fossil

                  Posté par  . Évalué à 2.

                  (je ne connais pas de loin la moitié des fonctionnalités de git non plus

                  Pour ça que je parlais bien des fonctionnalités de base, je ne prétend pas maîtriser git non plus. Il ne faut pas se voiler la face, git est très, très complet(xe) et perso, je n'en utilise en gros qu'une petite 10aine de commandes.

                  je pense qu'il faut relativiser suivant les cas.

                  C'est sûr. Après, si j'ai utilisé l'argument du poids des libs, c'est surtout parce que tu as parlé de la légèreté du binaire en incluant juste une seule des dépendances, ce qui n'avait du coup que peu de sens.
                  Franchement, je ne m'attendais vraiment pas à ce que git et ses dépendances soient plus léger que fossil et les siennes, je pensais plutôt que la différence se réduirait drastiquement et que ça se vaudrait… raté. Tu noteras d'ailleurs que le ratio que j'ai indiqué est faux, puisque je n'ai pas pris en compte la glibc6 (qui est loin d'être légère: 1.7M sur ma machine, rien que ça).

                  Pour ce qui est de sqlite, je n'ai que 5 paquets qui en dépendent directement, et ceux qui en dépendent indirectement sont surtout des paquets qui dépendent de python (genre blender, zenmap, iotop, ce genre de choses… et je suis quasi certain qu'ils n'ont pas besoin des fonctionnalités de sqlite3): aptitude, firefox (mon navigateur fallback), libnss3, libpython(2.7/3.4)-stdlib et c'est tout. libnss3 ne fait que recommander (selon LFS) sqlite. firefox et aptitude sont "en attente de remplacement". Reste python*-stdlib, la je ne sais pas, peut-être qu'il n'y a pas le choix, je ne me suis pas penché sur le cas.

                  Donc au final je pense que ça dépend beaucoup des logiciels que l'on utilise. J'ai pris l'exemple de sqlite, on va finir par croire que je déteste, mais promis, pas du tout, c'est juste que cet outil n'a que très peu d'intérêt sur mon système, avec les outils que j'utilise. Et je crains que ça soit trop souvent utilisé pour juste stocker de la configuration (n'est-ce pas firefox?)… quant à aptitude, je n'arrive pas à trouver de BDD dans /var/lib/aptitude alors je me pose des questions sur le bien fondé de la dépendance.

                  Après, si on veut vraiment mesurer l'impact mémoire, une mesure plus honnête serait ps -p $(pidof git) -p $(pidof fossil) -o rss,vsz,comm quand ils tournent, ou une mesure plus utile en l'occurrence, la bande passante consommée lors d'un clonage. Mais bon, git n'inclue pas de serveur, contrairement a fossil il me semble. Donc s'il faut ajouter un apache dans la balance, avec le redmine qui va bien, c'est sûr que fossil devrait gagner. Mais bon, httpd+redmine, ça ne sert pas que pour un seul projet, donc il me semble vraiment que ça fait au final moins de temps à passer à configurer les mêmes choses.

                  • [^] # Re: Fossil

                    Posté par  . Évalué à 2.

                    Et je crains que ça soit trop souvent utilisé pour juste stocker de la configuration (n'est-ce pas firefox?)…

                    J'apprécie en général quand la configuration est dans un fichier texte, mais il faut voir qu'une base de données peut avoir ses avantages parfois : plus facile de faire des requêtes plus compliquées, on est sûrs que les modifications sont atomiques, que l'état de la configuration va être consistant tout le temps, et on est un peu protégés d'un crash ou d'une coupure d'électricité au moment d'écriture (en l'occurrence, ça n'empêche pas de faire des backups, bien sûr, mais c'est quand même des propriétés intéressantes qui sont pourvues par un truc fiable et très testé). Et puis sqlite c'est quand même une base de donnée avec un seul fichier et zéro configuration à faire, c'est plutôt sympa comme fichier de stockage, je trouve. Après, c'est bien quand le logiciel propose d'exporter et d'importer facilement à partir d'un format texte compréhensible par un humain (ce qui n'est peut-être pas tout à fait le cas avec firefox).

                    • [^] # Re: Fossil

                      Posté par  . Évalué à 3.

                      plus facile de faire des requêtes plus compliquées, on est sûrs que les modifications sont atomiques, que l'état de la configuration va être consistant tout le temps, et on est un peu protégés d'un crash ou d'une coupure d'électricité au moment d'écriture

                      Faire des requêtes compliquées sur de la configuration? Je vais t'épargner mon laïus par la preuve en regardant les fichiers sqlite de FF, mais il y a plus d'un fichier qui ne contiens qu'une seule table (oh allez, des exemples quand même: cookies.sqlite…sigh…, permissions.sqlite). Que veux-tu faire de complexe avec une seule table?

                      La configuration, ce n'est pas le truc que l'on est censés charger au démarrage, et qui doit donc être assez simple pour être chargé vite (autrement dit l'opposé d'une requête compliquée)?
                      Très franchement, je pense que quand on commence à utiliser une base de données relationnelle pour stocker de la configuration (qui est typiquement soit un script, mais je ne trouve pas non plus cette solution élégante, soit une BDD clé-valeur, l'idéal, après, je peux encore accepter que le format ne soit pas du texte brut, pourquoi pas, ça peut nécessiter de la compression par exemple… admettons.) c'est qu'il y a un problème de sur-ingénierie. Et même si certains logiciels en souffrant sont excellents et même si je les utilise, ça ne veut pas dire que je le cautionnerai.

                      L'intérêt majeur d'un SGBDR c'est le côté relationnel des données, pas spécialement la consistance ni l'atomicité: ces points sont partagés par plein d'autres SGBD. Penses-tu que berkeleydb (libdb, le truc qui gère entres autres /etc/passwd) ne soit pas consistante ni atomique? Et les SGBD NoSQL (not only, pour rappel)? Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.

                      Pour ce qui est des modifications d'écriture et de la protection contre un arrêt au pire moment, c'est très facile avec des fichiers bruts (pas juste texte, tu noteras): on crée un fichier, on écrit dedans, on swap les noms (d'ailleurs, dommage qu'il n'y ait aucune commande shell pour le faire) et on vire le fichier de backup. Voire on le garde, pour future comparaison.
                      Ah, tiens, une fonctionnalité que les SGBDR n'ont pas, et qui est utile pour de la configuration ça: le versionning. Enfin, je mens, on pourrait versionner les CVS… mais niveau lisibilité c'est pas top.

                      Et puis sqlite c'est quand même une base de donnée avec un seul fichier et zéro configuration à faire, c'est plutôt sympa comme fichier de stockage, je trouve.

                      Non mais sérieusement, je le pensais quand je disais que j'aime bien sqlite. Cet aspect est très sympa, je suis d'accord. D'ailleurs, je ne connais qu'un seul autre SGBDR qui le permette: firebird.
                      Maintenant, si je reprend le cas FF (le seul installé sur mon système dont j'aie trouvé les fichiers sqlite, désolé si je donne l'impression de m'acharner) il n'y a justement pas qu'un seul fichier.
                      Je parle bien dans ce message d'une critique des logiciels configurés par sql, pas des logiciels qui utilisent le sql pour des formats de données (par exemple dans le cas de fossil je pense que c'est pertinent, il y a un wiki, un bug tracker, et un DVCS. Pour le wiki et le DVCS c'est évident que c'est utile, et compte tenu de l'intégration du BT avec le DVCS, pourquoi pas).

                      • [^] # Re: Fossil

                        Posté par  . Évalué à 2.

                        Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.

                        Je suis bien d'accord, c'est juste que parfois utiliser une base de données (relationnelle ou pas) qui fait ce genre de travail, et même si c'est pas très compliqué en soi, c'est plus simple que de le refaire soi-même pour un cas particulier, mais peut-être qu'aller jusqu'à une base relationnelle que pour ça est exagéré, je ne vais pas de contredire sur ce point (ceci dit, ce n'est pas forcément parce qu'un programme propose des fonctionnalités que tu n'utilises pas, qu'il y a plus de bugs dans celles que tu utilises, ça dépend de beaucoup de facteurs: comment les fonctionnalités interagissent entre elles, combien elles sont testées, etc.).

                        Personnellement, la seule fois où j'ai utilisé sqlite c'est pour écrire un petit moteur de forum (où pour le coup c'est bien pratique). Après, je suis totalement d'accord qu'une base de données relationnelle uniquement pour remplacer un unique fichier de clé = valeur c'est très exagéré. Ça se comprend mieux s'il y a au moins plusieurs tables (ou si l'utilisation d'index est utile). Après, je ne vais pas te défendre le cas particulier de firefox, dont je n'ai pas forcément une très bonne expérience: la seule fois où j'ai voulu récupérer mes bookmarks, je me suis aperçu que l'export en JSON ne donnait pas un résultat particulièrement simple, au point que je me suis contenté d'un export en html puis de substitutions et macros avec vim pour pouvoir les réutiliser avec un autre navigateur.

                        • [^] # Re: Fossil

                          Posté par  . Évalué à 3.

                          Que le support final soit un fichier texte n'a rien à voir avec la résilience, l'important c'est comment ce fichier est manipulé.

                          Je suis bien d'accord, c'est juste que parfois utiliser une base de données (relationnelle ou pas) qui fait ce genre de travail, et même si c'est pas très compliqué en soi, c'est plus simple que de le refaire soi-même

                          Berkeley DB, c'est ce qui manipule le fichier /etc/passwd des UNIX-like. Le fichier reste un fichier texte, mais c'est une base de données.
                          Les bases de données, à l'origine, c'était des dossiers avec des fichiers, mais c'était inefficace, à l'époque les systèmes de fichiers étaient moins bien faits que de nos jours, et avec des contraintes différentes. Donc ils ont fini par tout coller dans un fichier, géré par un seul logiciel en daemon (SGBD), et de fil en aiguille ça a fini par faire des SGBDR, puis le relationnel a fini par péter, et on est (re?)passé au NoSQL (Not only SQL) comme si c'était une nouveauté, alors qu'en fait c'est juste comme ça qu'on faisait avant…
                          Il ne faut pas oublier que les systèmes de fichier sont des bases de données. En fonction des réglages, ils sont plus efficaces pour des entrées de tailles variables, et la doc (pour les régler) n'est pas forcément simple à trouver, c'est vrai, mais je pense que dans pas mal de situations ils sont plus efficaces que des logiciels userland (déjà, eux sont potentiellement intégrés au noyau, rien que ça… sans parler du fait qu'ils soient administrables avec des outils classiques).

                          ceci dit, ce n'est pas forcément parce qu'un programme propose des fonctionnalités que tu n'utilises pas, qu'il y a plus de bugs dans celles que tu utilises, ça dépend de beaucoup de facteurs: comment les fonctionnalités interagissent entre elles, combien elles sont testées, etc.

                          Non, mais plus il y a de fonctionnalités, plus la complexité est élevée, et plus le risque de bugs non-triviaux est élevé. Et cela inclue les effets de bords des fonctionnalités non utilisées sur celles qui le sont.
                          Ce n'est pas pour rien que KISS est très plébiscité (parfois trop d'ailleurs) dans le libre.

                          j'ai utilisé sqlite c'est pour écrire un petit moteur de forum (où pour le coup c'est bien pratique).

                          C'est le genre de choses pour lesquelles un SGBDR est conçu, et malgré mon désamour du SQL je suis bien content de le trouver dans ces moments la.
                          En fait, dès lors qu'il y a de nombreuses relations entres les objets à manipuler, les SGBDR sont très, très utiles. Malgré que je trouve le SQL absolument horrible.

                          Après, je ne vais pas te défendre le cas particulier de firefox

                          Je n'ai pris que le seul exemple qui reste sur mon système, en même temps. C'était juste histoire de prouver que ce n'est pas parce que l'on utilise des logiciels bien fichus (j'ai tendance à penser que sqlite l'est) que l'on produit un logiciel lui-même bien foutu.
                          Ceci dit, je suis persuadé que c'est loin d'être limité à Firefox. Par exemple, je ne serai pas surpris que Gnome ou KDE stockent leurs configuration dans des fichiers sqlite. Un peu comme… regedit (sauf qu'il reste a prouver que regedit soit un SGBDR, hein).

                          Si j'avais la motivation je pourrais faire une analyse des logiciels avec une dépendance directe à sqlite présents dans le dépôt Debian, mais j'ai choisi la facilité: quand j'installe un logiciel, je regarde de quoi il dépend, et s'il m'ajoute plus de 5 lib, je cherche une alternative (parfois il n'y en a pas, mais c'est quand même relativement rare).
                          Je regarde aussi si les dépendances me semblent pertinentes, par rapport au job du soft. Ces vérifications nécessitent une chose par contre: garder tout le temps un système relativement simple. Ma Debian n'a du coup rien à voir avec une Debian par défaut…

                          • [^] # Re: Fossil

                            Posté par  . Évalué à 2.

                            Globalement d'accord avec toi (à part que je trouve pas le langage SQL horrible :) ).

                            Ma Debian n'a du coup rien à voir avec une Debian par défaut…

                            Je n'en doute pas, mais il y a des chances qu'il te reste pas mal de « bloat » : des programmes de base (ls, find, cp, awk, etc.) pleins d'options que tu n'utiliseras jamais, peut-être même un systemd tout puissant, un méga shell (bash, zsh ? À moins que tu n'utilises que dash)… :) Blague à part, c'est une des raisons pour lesquelles j'utilise OpenBSD : tous les programmes de base ont moins d'options (mais le fait que celles qui sont là sont mieux documentées a plus joué probablement que le fait qu'il y en ai peu en soi). Mais malgré tout, je ne me sens pas trop mal lorsque je dois installer tout Qt et que sais-je d'autre pour utiliser un logiciel intéressant. J'essaie juste d'éviter au maximum les dépendances pour mon serveur (qui n'utilise que le système de base [qui a sqlite :)] et quelques modules Perl), mais pour le reste, je ne me pose pas autant de questions.

                            • [^] # Re: Fossil

                              Posté par  . Évalué à 2.

                              ls

                              Lui je le hais… mais alors vraiment. Sortie tout ce qu'il y a de plus horrible, amhà. Faudra que je pense a écrire le mien un jour. Ou a utiliser un remplaçant. Parce que le ls installé par défaut avec Debian et dans la config par défaut, c'est vraiment une galère à utiliser.

                              peut-être même un systemd tout puissant

                              Lui n'a jamais eu sa place sur mes systèmes. Je n'en vois pas l'intérêt… Démarrer les services en parallèle sert juste à rien quand il n'y a que 3 services. À la base, j'aimais bien l'idée derrière (parce que je ne connaissais que sysvinit et ses horribles scripts indébugables) mais le projet ne sait même pas ou il finira: niveau code ça ne laisse rien présager de bon, alors je préfère anticiper et le remplacer par un truc avec des contours moins flous (je teste runit. Simple, efficace, ne fais qu'une chose, portable. J'aime bien, il ne choque pas mes opinions et me laisse libre de changer de kernel. ).

                              Blague à part, c'est une des raisons pour lesquelles j'utilise OpenBSD : tous les programmes de base ont moins d'options

                              Je pense sérieusement à changer de crèmerie.
                              J'en suis arrivé à recompiler certains paquets pour virer la moitié des dépendances… pas logique. Ajoutes à ça le fait que pour avoir un système propre après install il faut virer un gros nombre de paquets, que pour virer systemd (pas le choix de l'avoir par défaut) il faut rebooter… ça me rappelle un peu trop l'époque ou j'utilisais windows 98 (j'ai mis des années avant de passer à XP, je l'ai toujours trouvé trop lourd et buggué. L'install nécessitait d'ailleurs encore plus de nettoyage que celle de w98 ainsi qu'un reboot de plus, mais bon…)

                              Je ne sais pas trop dans quelle direction aller: je pensais à NetBSD surtout (avec un collègue, on avait comparé un peu le source d'un outil de base pour GNU, FreeBSD, OpenBSD et NetBSD: GNU super bloat, Free moyen, Open et Net au coude à coude mais j'avais préféré le style de Net), ou au moins changer de distro (voidlinux) histoire d'avoir un changement moins violent et voir un peu si le problème viens vraiment de Linux, ou juste de l'objectif de Debian (être universel à un coût, c'est logique).

                              Le problème, c'est qu'il me manque un p'tit bout de bloat dont je me suis entiché: aptitude.
                              Aptitude c'est un truc gros, lourd, lent, au code douteux (j'avais regardé il y a 2 ans le code pour corriger certains défauts, j'ai vite lâché l'affaire…) qui fait pleins de trucs inutiles et ne fais pas certains trucs super utiles, mais quand on arrive sur un système ou l'on est obligé de chercher sur le net pour savoir quoi installer, aptitude permets de sauver quelques chatons en permettant de naviguer dans une liste de logiciel tout en indiquant leurs dépendances.
                              Et comme c'est du ncurses, quand t'as foutu en l'air le serveur graphique (true story, à l'époque ou je débutais sous Debian il m'a sauvé plus d'un système avec une violente purge/reinstall! ), tu peux quand même t'en servir, magique :) donc oui, je veux changer de système, mais je suis coincé sur les Debian-like à cause de mon amour d'aptitude… triste. Mais je suis en train d'y remédier.

                              Mais malgré tout, je ne me sens pas trop mal lorsque je dois installer tout Qt et que sais-je d'autre pour utiliser un logiciel intéressant.

                              J'ai bien des logiciels qui dépendent de GTK (surtout gparted, mais aussi zenmap et wireshark --qui a une version Qt, mais très limitée--) et d'autres de Qt (xxdiff notamment, et virtualbox). À choisir entre les deux, je préfère Qt d'ailleurs.

                              Donc oui, je fais aussi des concessions, mais j'aime faire attention à ce que mon système ne pourrisse pas de lui-même. Typiquement, je n'installe aucun logiciel gnome ou kde, parce qu'ils tirent juste tout le bureau avec eux (la faute à Debian, peut-être, je sais pas).
                              Après, je pense que l'usage d'aptitude (encore) est la raison qui fait que ça ne me prend pas trop de temps, justement (malgré son solveur inefficace hyper lent lancé dès qu'on change la position du curseur…).

                              J'essaie juste d'éviter au maximum les dépendances pour mon serveur

                              Me suis amusé récemment avec une VM Debian, à la réduire au maximum (sans compiler, juste en bidouillant la config et en changeant les logiciels).
                              Install toute fraîche: 89M/39M utilisés (avec/sans cache/buffers/etc).
                              Après divers remplacements et un peu de nettoyage, c'est passé à 63M/30M.
                              Niveau du temps de boot, au pifomètre, je dirai qu'il y a 5s d'écart (oui, en faveur du système qui n'utilise PAS systemd).

                              Juste changé l'init, le login, le ssh et le getty, viré exim et dbus, remplacé bash par zsh. En gros.
                              C'est sûr que ça n'est rien compte tenu du fait qu'il n'y a qu'un seul shell de lancé (j'ai mesuré à partir de TTY1) mais le résultat est quand même flagrant. À fonctionnalités égales, de mon point de vue (voire supérieures, zsh que je découvre me semble quand même vachement plus puissant que bash).

                              Sur un desktop, ce qui pompe c'est surtout Xorg lui-même (ps m'indique 66M de mémoire résidente, je pense que Debian inclue pas mal de bloat) et bien sûr les navigateurs… mais ce domaine est juste catastrophique.

                              Après, la raison pratique de faire ça…
                              Garder mon système simple, c'est aussi histoire d'être capable de le maintenir et de comprendre ce qu'il s'y passe en fait. Voire de pouvoir intervenir. Typiquement, j'utilise i3status. Le code est relativement simple (bien que ce soit un sacré foutoir pour ajouter un truc) et du coup il m'a été relativement simple d'ajouter une zone qui indique l'usage de ma RAM. J'ai aussi pompé un bout de code pour le support de mpd. Je me vois mal faire un module pour la barre de statut de jenesaisquelwm, le jour ou j'aurai un besoin qui n'a pas encore été codé.
                              Et puis avoir un système qui obéit au doigt et à l'œil, instantanément, malgré une machine tout sauf performante (pour les standards actuels du moins) n'est pas désagréable.
                              Sans compter que je trouve ça agréable de jouer à qui la plus courte :-)

                              • [^] # Re: Fossil

                                Posté par  . Évalué à 4.

                                Sans compter que je trouve ça agréable de jouer à qui la plus courte :-)

                                C'est rigolo 3 minutes, puis un jour tu va commencer à utiliser ta machine (pour faire autre chose que la faire fonctionner) et tu n'aura plus le temps de faire ce genre de choses. Tu va comprendre que ce n'est pas le code d'un logiciel qui va te permettre de le configurer, mais ça configuration. Tu va découvrir que tu introduit des petits bugs en changeant des choses plus ou moins profonde de ton système. Tu fini par te dire que gagner 3Mio et 5s de boot est plus proche de la somatisation qu'autre chose. Au final utiliser un système qui te convient (que ce soit Debian, un autre linux, un BSD ou encore autre chose) dès le départ c'est cool et ça permet de faire autre chose de son temps que de maintenir son système ;-)

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

      • [^] # Re: Fossil

        Posté par  . Évalué à 3. Dernière modification le 27 février 2016 à 17:12.

        Je ne comprend pas… tu veux dire qu'à chaque commit, tout est balancé sur le web sur un répo central? Ça casse un des arguments majeurs en faveur des DVCS, qui est de pouvoir coder dans le train (entres autres).

        Tu peux aussi (s'il n'y a pas de connexion il fera juste un commit local), et c'est juste un paramètre. Ceci dit, sur des petits projets c'est assez pratique de pouvoir parfois adopter un style de commit sur un dépôt central, pour éviter de faire des forks inutiles qui rendent les merges plus compliqués par la suite.

        • [^] # Re: Fossil

          Posté par  . Évalué à 2.

          Ceci dit, sur des petits projets c'est assez pratique de pouvoir parfois adopter un style de commit sur un dépôt central, pour éviter de faire des forks inutiles qui rendent les merges plus compliqués par la suite.

          Je ne vois pas en quoi.

          Les forks, c'est juste pour bosser sur le projet d'autrui. D'une manière ou d'une autre, tu dois cloner le repo, non?

          • [^] # Re: Fossil

            Posté par  . Évalué à 2. Dernière modification le 27 février 2016 à 21:56.

            Je ne sais pas si j'ai été clair : tout le monde a un repo complet en local. C'est juste que par défaut, si tu fais un commit en local, tu fais aussi un push automatiquement vers le dépôt à partir duquel tu as cloné (si c'est possible), ce qui incite les développeurs à synchroniser plus souvent leur travail, tester le code des autres plus souvent et pas trop diverger (mais ce n'est pas un paramètre à activer dans toutes les configurations, bien sûr).

            Une autre particularité de fossil, est que par défaut les branches sont publiques (donc clonées automatiquement par tout le monde). Il faut être explicite pour une branche privée.

            • [^] # Re: Fossil

              Posté par  . Évalué à 2.

              C'est juste que par défaut, si tu fais un commit en local, tu fais aussi un push automatiquement vers le dépôt à partir duquel tu as cloné (si c'est possible), ce qui incite les développeurs à synchroniser plus souvent leur travail, tester le code des autres plus souvent et pas trop diverger

              Je vois le truc. Je ne suis pas super convaincu mais bon… pourquoi pas.

              autre particularité de fossil, est que par défaut les branches sont publiques

              Ça par contre c'est sympa.

            • [^] # Re: Fossil

              Posté par  . Évalué à 1.

              C'est juste que par défaut, si tu fais un commit en local, tu fais aussi un push automatiquement vers le dépôt à partir duquel tu as cloné (si c'est possible), ce qui incite les développeurs à synchroniser plus souvent leur travail, tester le code des autres plus souvent et pas trop diverger (mais ce n'est pas un paramètre à activer dans toutes les configurations, bien sûr).

              Du coup si tu comptais rebase/squash tes commits avant de push c'est mort ? Ou le force-push fait partie de l'usage normal ?

              • [^] # Re: Fossil

                Posté par  . Évalué à 2.

                Il n'y a pas de rebase en fossil. C'est possible de réussir à faire la même chose avec des efforts, mais c'est contraire à la philosophie du logiciel (tout les artifacts doivent être immutables et l'historique est censé représenter le plus possible la réalité, pas ce qu'on aurait voulu qu'elle soit).

    • [^] # Re: Fossil

      Posté par  . Évalué à 2.

      Un peu HS oui, car on ne parle pas de Git mais de GitHub, du gestionnaire de conf en SaaS.
      Donc il faudrait le comparer à une Fossil en SaaS.
      Or, ça n'existe pas à ma connaissance.
      J'avais songé un jour à automatiser l'exposition de mes repositories Fossil derrière un nginx. Mais j'ai pas poursuivi faute de temps.

  • # C'est un problème depuis longtemps

    Posté par  . Évalué à 5.

    C.f. le très bon article de Benjamin Mako Hill, qui date de 2010 quand même : https://mako.cc/writing/hill-free_tools.html
    C'est dommage qu'on retrouve dans les commentaires de ce journal des arguments qui ont été démontés par Mako depuis tout ce temps.

Suivre le flux des commentaires

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