freem a écrit 4965 commentaires

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.

Le truc, c'est que tu ne mérites même pas d'être moinssé. Je ne moinsse pas quand j'ai pitié.

Et la je me sens con… effectivement, il y a une grosse quantité de données, contrairement aux autres tests rapides que j'ai fait, du coup le fils ne pouvais pas tout envoyer…

Le terme message est a prendre au bas niveau, j'ai l'impression, genre un message UCP (pas TCP, vu que c'est des flux). Tu balances tes données au serveur, les applications qui comprennent de quoi il s'agit les récupèrent quand elles veulent. Si j'ai bien compris.
Si tu aimes les buzzwords, c'est le genre de gadget qui aide à vendre les applications REST.

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.

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

Sur le site officiel ils parlent de 5 clients, chacun avec des techno différentes et qui cible donc différents systèmes (un Qt pour les amateurs de gros bureaux et de windows, un X11 pour ceux qui font leurs bureaux eux-même, 1 curses pour les amateurs de terminaux, et les 2 autres pour les mobiles…) rien de si exceptionnel.
Surtout, "même compilé pour BSD", ce n'est pas très difficile, il suffit de ne pas utiliser de GNUisme, ce que pas mal de développeurs font au final, pour diverses raisons, dont le fait que GNU a tendance à faire des outils sacrément bloatés et le fait que GNU publient beaucoup avec des licences restrictives (GPL n'est pas compatible avec les licences BSD, notamment…enfin, ça l'est, mais a sens unique).

Quant à libav, c'est juste une bibliothèque multimédia. Jamais utilisée, mais je serais surpris que ça casse 3 pattes à un canard, surtout que c'est codé en C, donc probablement pas de structures tarabiscotées comme savent si bien le faire les fanatiques des framework (quoique, les dev de gnome sont pas mauvais dans ce délire et pourtant, c'est du C… mais ce sont des exceptions.).
Là ou ça doit être plus intéressant a mettre en œuvre, c'est côté protocole, mais justement, il semblerait que tox, c'est principalement une lib qui implémente le protocole, et que les gens peuvent réutiliser, de ce que j'ai lu. Bon, j'ai pas regardé l'API, pas trouvé de doc (déjà un bon point noir côté dev).

D'ailleurs, en fouillant un peu dans la doc, on peut voir que c'est encore en alpha tout ça. Enfin, je connais des projets en alpha qui sont super stables, il faut juste ne pas être trop à cheval sur la sécurité et la performance.

… je doute que quelqu'un puisse comprendre le problème.

Ce que moi je comprend, c'est juste que tu as réussi à installer Linux Mint 17 (Mate est le bureau, ce n'est pas important, mais je comprend que tu sois confus) sur un netbook à partir d'une clé USB et que tu voudrais l'installer sur un PC qui a 2 disques durs.

Par contre, le reste, c'est brouillon… tu parles de machine avec 2 disques durs, et de disque dur externe… le disque dur externe est-il l'un des deux disques en question?
Quelle est la capacité de chacun de tes disques, et quel est leur taux (%) d'utilisation imputé aux données que tu veux sauvegarder?
Comment tes disques durs sont-ils partitionnés?

A priori, le "pinning" par défaut ne permet que les maj et les installations, pas les installations par dépendance.

Exact, pour éviter de backporter tout le système par accident, seuls les paquets backport installés volontairement et explicitement sont installés et où mis à jour (à noter que ça n'a rien à voir avec le marquage manuel/automatique).
C'est pour ça qu'avoir un paquet installé en stable n'est pas mis à jour vers sa version backportée automatiquement, malgré que la version soit plus récente.

M'enfin, le système de priorités et de pinning de Debian est pas simple a comprendre, perso a un moment je jouais avec mais maintenant j'évite autant que possible: trop de prise de tête pour pas grand chose, c'est limite plus simple de faire les paquets soi-même à partir du paquet source (sauf que du coup les MàJ auto on les a plus, bien sûr, d'où le "limite")…

Ca passe bien les routeurs je me demande d'ailleur par quel exploit technique.

À priori, au niveau technique, c'est le même principe que pour tor:

Does Tox rely on central servers?

No. That said, in some situations a client will choose to use publicly listed bootstrap nodes to find their way into the DHT.

What is stopping people from tracking me through the public DHT?

Tox generates a temporary public/private key pair used to make connections to non-friend peers in the DHT. Onion routing is used to store and locate Tox IDs

Je ne connaissais pas le projet, ça à l'air intéressant.

(à 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…

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.

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.

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.

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?

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.

Note que tu peux faire quelque chose de proche avec les exceptions dans de nombreux langage, mais ce n'est pas aussi propre car l'exception n’apparaît pas dans le type de la fonction et n'est pas forcement vérifiée par le compilateur.

Accessoirement, les exceptions ont un coût à l'exécution nul, mais augmentent la taille du binaire, coûtent cher quand elles sont lancées, et, en C++, nécessitent tout un tas de glue, tout en ne pouvant pas transiter entre deux binaires correctement, sans parler du fait qu'une exception pas rattrapée semble être un comportement indéfini.
Bref, je n'aime plus les exceptions, que l'on a trop vendues comme la panacée à mon goût.

Au passage, cette histoire de taille de binaire augmenté pour de bonnes performances CPU, c'est un truc qui commence à me titiller en C++: tout est axé sur la performance de calcul, mais on n'a que peu de contrôle sur la performance mémoire je trouve (typiquement, estimer la taille d'un std::map est complexe, et nécessite une connaissance de l'implém sous-jacente). Sauf que le cache augmente moins vite que la vitesse de calcul, donc je ne suis pas sûr que l'approche "tout pour le CPU" soit idéale.

C'était les exemples de compositions.

Merci.

Oui ;) Et si on pouvait avoir des vrais enums typés (i.e: pas de faux int) ce serait mieux ;)

Un peu comme ça:

enum class Enumeration {
    Val1,
    Val2,
    Val3 = 100,
    Val4 // = 101
};

?

Oui reste à savoir quel profondeur de copie est fait.

Si je ne m'abuse, c'est une copie totale des objets stockés. Sauf que si ton objet stocké est un pointeur, seul le pointeur est copié, pas le contenu pointé par. En même temps, c'est le rôle des pointeurs, on pourrait dire.

À noter par contre que xbacklight est un workaround, pas une solution. Si ça baisse en effet la luminosité de l'écran, ça ne diminue pas la consommation de l'écran. Par contre, cet outil est, contrairement aux outils spécifiques des PCs portables, utilisable sur n'importe quel écran, y compris fixe. Je m'en sers la nuit pour l'écran qui sers à afficher le navigateur…

Livrer une application qui bug est moins gênant (pour la ssii) que le fait que le système (du client) tombe en rade. Et le grrr montre mon agacement face à cette façon d'agir que j'ai pu constater.

Je réponds juste au "le standard ne peut être ésotérique". Oui, j'ai pris un exemple de code obfusqué, mais ce code est-il standard, ou non?
J'ai vu des scripts shell très difficiles a lire, tout comme de l'asm lisible, pourtant l'asm n'est pas un langage standardisé, contrairement au shell.
Si on doit parler de langage informatique ésotérique, je trouve que le shell se pose bien, même si la doc abonde (encore faut-il trouver, parce que les moteurs de recherches tendent à me corriger quand je tape sh, et si je tape bash j'ai pas de preuve que l'on ne parle pas de bashisme, justement…). Et certaines instructions du shell, telles que ": > toto" sont justement tout sauf lisible.
Si je demande à ma mère… oh, allez, à mon père, il a fait un peu d'asm motorola au lycées… de me dire ce que fait cette ligne, ou ce que fait une ligne de C équivalent qui ne montrerait pas ma mauvaise foi, je parie qu'il galérera moins à lire la ligne de C. Pourtant, c'est le shell qui est censé manipuler le mieux le système de fichiers (le C est conçu pour être bas niveau, d'ailleurs les outils C pour manipuler le système de fichier ne sont pas dans le standard iso me semble). À côté, en shell, on peut utiliser touch toto. Bon, toujours pas parlant, mais au moins, c'est lisible, et il y a même un man.
Donc, oui, : > toto est ésotérique, malgré que ce soit standard.

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.

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.

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.

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.