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 Anonyme . Évalué à 10. Dernière modification le 26 février 2016 à 13:35.
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 Goffi (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 barmic . Évalué à 10.
Non. Tu peux très bien monter un pataquès trop complexe pour qu'un particulier puisse jouer avec.
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.
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 Goffi (site web personnel, Mastodon) . Évalué à 10.
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.
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.
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.
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 barmic . Évalué à 3.
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.
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.
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 ?….)
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 Goffi (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 février 2016 à 15:44.
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:
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)
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).
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.
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 barmic . Évalué à 1.
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,…).
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.
Non. Ou dans des cas suffisamment particulier pour considérer que non. Pour déboucher sur une solution, il faut :
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 Lutin . É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 Gastlag . Évalué à 4.
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 freem . Évalué à 2.
Certes. Parce que tu devras écrire ou trouver un soft compatible.
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 dinomasque . É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 barmic . Évalué à 4.
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 woopla . É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 Richard Dern . É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 Christophe . Évalué à 10.
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 RyDroid . Évalué à -2.
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 barmic . Évalué à 6.
Aie ><
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 RyDroid . É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 groumly . Évalué à 7.
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 BAud (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 Antoine . Évalué à 2.
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 freem . Évalué à 5.
Vu sur la page d'accueil de github:
Puis dans la FAQ:
À priori github aussi, est "auto-hébergeable".
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 Laurent J (site web personnel, Mastodon) . Évalué à 10.
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).
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 BAud (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 Zenitram (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 Laurent J (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 Zenitram (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 rdhlnn . Évalué à 3.
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 laurentb (site web personnel) . Évalué à 5.
Du moment que tu n'offense pas ses employés, ce qui semble être de plus en plus difficile.
[^] # Re: service...
Posté par Adrien . É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 laurentb (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 Zenitram (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 RyDroid . É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.
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 Zenitram (site web personnel) . Évalué à -4.
Voila toute l'explication sur pourquoi certain logiciels libres sont "super mais je ne comprend pas pourquoi personne ne veut utiliser".
Le masochisme est un hobby peu répandu.
Choix de société? tu vas loin…
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.
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 freem . Évalué à 5.
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 Antoine . Évalué à 4.
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 Maclag . É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 Parleur . É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 Ytterbium . Évalué à 10.
Mais non, les vrais utilisent des papillons !
(je mets quand même le xkcd de rigueur :)
[^] # Re: service...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Je confirme, j'ai déja fait ça, sur un Archimedes :)
[^] # Re: service...
Posté par Michaël (site web personnel) . Évalué à 2.
Frimeur. :)
[^] # Re: service...
Posté par laurentb (site web personnel) . Évalué à 1.
Une interface web frustrante et limitée plutôt.
Je préfère de loin
git send-emailpour contribuer ettigpour naviguer dans l'historique.[^] # Re: service...
Posté par Carl Chenet (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 Anonyme . É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 Misc (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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
les templates sont apparues il y a quelques jours …
[^] # Re: service...
Posté par Misc (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 Laurent J (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 flan (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 louiz’ (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 steph1978 . É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 Cyprien (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 Thom (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 Anonyme . Évalué à 3. Dernière modification le 26 février 2016 à 15:57.
Et en plus on peut activer l’authentification avec GitHub via OAuth, ce qui évite d’avoir à se trimbaler quarante comptes, un pour chaque projet. Bien entendu, je parle de ça en ayant en tête « Github était là avant ».
La doc sur ce sujet : https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md
[^] # Re: Gitlab
Posté par EauFroide . Évalué à 2. Dernière modification le 26 février 2016 à 17:31.
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 Thom (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 Cyprien (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 EauFroide . É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)?
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 BAud (site web personnel) . Évalué à 1.
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 EauFroide . Évalué à 0.
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 Yuul B. Alwright . Évalué à 6. Dernière modification le 26 février 2016 à 15:41.
À essayer:
https://pagure.io/pagure
# Le non-danger Github
Posté par Aissen . É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 steph1978 . É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 rewind (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 Anonyme . É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 Richard Dern . Évalué à 8.
Vous me faites marrer quand même sur lfr.
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.
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 RyDroid . Évalué à 2.
Rien à la consultation ou l'inscription du site web ne demande pas cela.
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 Zenitram (site web personnel) . Évalué à 0.
???????????
Zut alors, dire ce qu'on analyse est interdit, si ça ne va pas dans le sens que tu as décidé.
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.
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 Parleur . É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 Richard Dern . Évalué à 3.
Quoi ? C'est "valeur" que t'as pas compris ?
Ouh, mais tu persiste à faire dire aux gens ce qu'ils n'ont pas dit. Relis-moi bien :)
Par contre, je te cite:
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…
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 Antoine . Évalué à 5.
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 Richard Dern . Évalué à -2.
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 Benoît Sibaud (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 Richard Dern . É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 EauFroide . É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 Christophe . É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 barmic . Évalué à 4.
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 Richard Dern . Évalué à -4.
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 Antoine . É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 pasBill pasGates . É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 barmic . Évalué à 9.
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 Richard Dern . É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 Benoît Sibaud (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 barmic . É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 :
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 :
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 pasBill pasGates . É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 groumly . É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 freem . É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 gnumdk (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 Antoine . É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 freem . Évalué à 3.
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 Gastlag . Évalué à 3.
Au passage quelqu'un a compris la différence entre Gitlab / Gog / Redmine /Trac ?
[^] # Re: Gitlab / Gog / Redmine /Trac
Posté par louiz’ (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 freem . Évalué à 2.
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.
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 barmic . Évalué à 4.
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 freem . Évalué à 2.
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 louiz’ (site web personnel) . Évalué à 1.
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 freem . Évalué à 2.
Moi non plus, à la base. Merci wikipedia :)
On sent les mecs super inspirés oui…
# Fossil
Posté par anaseto (site web personnel) . É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 freem . Évalué à 4.
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.
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 anaseto (site web personnel) . Évalué à 5.
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).
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.
Il y a Chisel, qui utilise du logiciel libre en plus.
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 freem . Évalué à 0.
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.
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' '):Celui de git:
J'avoue être surpris la.
Bon, les tailles de binaires:
fossil:
total: 4.925Mo (en considérant les Ko comme Kio, c'est à dire en les divisant par 1024).
git:
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 groumly . É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 BAud (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 xcomcmdr . É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 freem . É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 anaseto (site web personnel) . Évalué à 4.
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 freem . Évalué à 3.
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.
Le problème de Debian: à force de vouloir être universels, ils compilent en full-options.
[^] # Re: Fossil
Posté par anaseto (site web personnel) . Évalué à 2.
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 freem . Évalué à 2.
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.
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,commquand 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 anaseto (site web personnel) . Évalué à 2.
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 freem . Évalué à 3.
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.
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 anaseto (site web personnel) . Évalué à 2.
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é = valeurc'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 freem . Évalué à 3.
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).
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.
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.
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 anaseto (site web personnel) . Évalué à 2.
Globalement d'accord avec toi (à part que je trouve pas le langage SQL horrible :) ).
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 freem . Évalué à 2.
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.
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. ).
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.
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…).
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 (
psm'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 barmic . Évalué à 4.
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 anaseto (site web personnel) . Évalué à 3. Dernière modification le 27 février 2016 à 17:12.
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 freem . Évalué à 2.
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 anaseto (site web personnel) . É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 freem . Évalué à 2.
Je vois le truc. Je ne suis pas super convaincu mais bon… pourquoi pas.
Ça par contre c'est sympa.
[^] # Re: Fossil
Posté par peikk0 . Évalué à 1.
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 anaseto (site web personnel) . É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 steph1978 . É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 benoar . É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.