cosmocat a écrit 2100 commentaires

Ouais, en même temps, dire que c'est de la diffamation, c'est un peu exagéré.

Pour diffamer, il faut qu'il y est volonté de nuire alors que c'était juste un constat, genre tableau de comparaison…

Parce que des infos fausses ou pas claires ou incomplètes, y'en a plein le web et s'il y a diffamation à chaque fois, les avocats vont être encore plus riche que ce que je pensais…

A oui et j'ai oublié, je me suis exercé au RegEx Golf : http://regex.alf.nu/
issu d'un xkcd : http://xkcd.com/1313/

Le principe c'est qu'il faut trouver une regex qui match un ensemble de valeurs tout en excluant un autre ensemble (et trouver la meilleur permet de gagner plus de points)

sinon, en plus dur, il y a : http://nedbatchelder.com/blog/201302/a_regular_crossword.html

Je connaissais pas donc je suis allé voir. Le mainteneur le dit lui même, il est tout seul donc ça joue largement pas en la faveur de cette forge :(

En plus y'a pas encore le support de git (c'est dans la version en développement). Le support de Mercurial est assez récent également il me semble…

Je sais pas si il peut lutter face aux autres forges et ça donne pas trop envie d'y mettre son projet par soucis de pérennité…

Pour ceux qui utilisent encore windows et qui veulent un système d'installation (facile) se rapprochant (vaguement) de ce que permet un dépot comme sous linux, il y a :
http://chocolatey.org/

ça marche avec les principaux logiciels libres et d'autres propriétaires…

Les avantages:
- plus besoin d'aller de parcourir le web pour trouver le site de téléchargement
- installation silencieuse (quand possible) avec évitement des crapwares
- gère aussi la mise à jour (donc on peut enfin! mettre à jour ses logiciels sous windows)

Moi, je dis que c'est moins bien! Sur Chrome, on se retrouve très rapidement à ne voir que les favicons des onglets car on ne peut plus lire le texte dès qu'on a plusieurs onglets d'ouvert. Et ceci en partie à cause de cette forme qui gâche de la place. Mais, bon pour le côté marketing, c'est plus vendeur…

Donc je serais toi, je ne m'attendrais pas à des miracles. Si déjà dans le cadre de jboss (qui est poussé par redhat & tutti quanti) les devs sont pas foutu de faire un fichier d'init à peu près propre pour leur propre distrib, que dire d'un dev lambda qui devra gérer trois système d'init différent.

Il me semble que ta façon de juger un système d'init est un peu foireuse…

Si j'ai bien compris, faire un fichier .unit pour systemd est plus facile que faire un script d'init. Tu peux donc juste t'estimer heureux que les développeurs (qui ne sont pas forcement des packageurs et que ça fait donc chier de faire les fichiers d'init et qui n'ont peut-être pas les compétences) ne t'aient pas pondu un script d'init encore pire!

En plus, le gros avantage que j'y vois est que le fichier de conf de systemd étant upstream, il suffit que t'aillant aperçu que le fichier est bancal, tu pousses la correction au projet pour que toutes les distributions en profitent. Tu n'auras pas à corriger tous les scripts d'init foireux (et différents) que les différentes distributions auront du écrire! De même, il suffit qu'un mainteneur d'une distribution écrive un bon fichier d'init et le propose au projet pour que TOUTES les distributions en profitent.

Quant à ton avis sur la documentation, si tu t'en ai aperçu, c'est qu'il y a peut-être un besoin et la doc pourra être améliorée. Il me semble qu'améliorer une documentation est bien plus facile qu'améliorer l'architecture foireuse d'un logiciel, non?

Pour moi, un sel doit avoir les même caractéristiques qu'un mot de passe : contenir des chiffres, des lettres en minuscules et majuscules, contenir des caractères autres et d'être d'une certaine taille ( en plus tu n'es pas contraint par la mémoire d'un utilisateur alors tu peux te lâcher!! 100 caractères si besoin…). Comme ça tu invalides TOTALEMENT les rainbow tables et il ne reste que le brute force pour l'attaquant.

SHA1(username)

Si tu permet à tes utilisateurs de changer son login (par exemple le login est en fait leur adresse mail), tout ta stratégie (en plus d'être déjà mauvaise) tombe encore plus à l'eau…

Plus que d'accord! Quand tu as choisi un toolkit graphique, tu ne reviens (presque) jamais en arrière car le cout de migration est trop conséquent. Cela ne veut pourtant pas dire que s'il devaient refaire le choix aujourd'hui, ils referaient le même. Chaque toolkit peut avoir de nouveaux avantages et de nouveaux inconvénients et l'un être devenu mieux alors qu'avant il était moins bien…(suivant tes critères de choix, qui peuvent aussi varier en fonction du projet).

Car, en effet, les différents toolkit ont surement évolués et conviendraient peut-être maintenant à leur besoin alors qu'avant non. Mais surtout maintenir son propre toolkit graphique a un cout énorme!

Je crois que LibreOffice voudrait se débarrasser de son vieux toolkit historique mais que l'effort est très (trop?) important.

Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.

Dans ce genre de contrôleur de code source, merger devient un enfer!

Il faut bien comprendre que quelque soit le contrôleur de source utilisé, brancher n'est JAMAIS un problème. C'est merger (ou reporter des commits) qui devient un problème.

Et ceux qui ont cette stratégie de "early branching" où on recopie l'ensemble des fichiers dans un autre "répertoire" ont plus de difficultés à retrouver les modifications et à faciliter la gestion des branche (après branchement donc).

Je sais pas si ça peut t'aider : Best 2013 KDE Ditribution

Euh… je croyais avoir été clair pourtant. Je disais que c'était pas possible car tu peux pas vraiment travailler avec (puisque tu ne peux pas faire de 'push') et c'est l'objet du débat. Avoir une vrai solution pour pouvoir travailler, non?!?

Sinon, le clone --depth fait exactement ce que je décris et on se retrouve avec des sha1 différents, donc un dépot local qui sert à pas grand chose à part la consultation (et la collaboration à base de patchs).

Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.

Le point 1 n'est pas possible avec Git car on obtient un sha1 différent car le sha1 est dépendant du commit parent (qui ici n'est pas présent). Apparement, c'est juste pour la consultation. Contrairement, apparement, à Mercurial qui permet de le faire?

Le point 3 ne me parait pas possible également.

Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).

Apparement, reposurgeon peut faire çà.

L'article sur InfoQ sur le sujet apporte un peu plus d'infos :
http://www.infoq.com/news/2014/01/facebook-scaling-hg

…ainsi qu'une petite blague:
Facebook a choisi Mercurial car c'est écrit en Python et donc plus facilement extensible et au moins un des patch conséquent fourni a consisté a réécrire en C la fonction de détection du statut des fichiers. Encore quelques patch et Mercurial sera entièrement en C…comme git ;)

Tu as raison, il faut faire des cpold des répertoires .git et .hg…

Pareil! Au moment de choisir un DVCS, j'ai regardé un peu Mercurial et git pour au final opter pour git (car l'ecosystème est plus florissant).
Mais lire çà : http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
me fait un peu tiquer (il faut réfléchir à quoi choisir avant de faire une branche :( et le "branching with clone" me parait une aberration alors que c'était ce qui était plutôt conseillé à l'époque il me semble ), là où la notion de branches de git me semble limpide…

Ce qui me dérange également avec Mercurial est, paradoxalement, le système de plugins : tout le monde n'a pas le même set de fonctionnalités, il faut bucher la liste des plugins pour pouvoir faire des trucs qui me semblent devrait être disponible par defaut, …

Si j'ai bien compris la problématique de facebook, ils ont des "millions" de commits sur des branches, et git est très très mauvais en performance de ce côté là

Dans git, et c'est cela qui est bien pensé, avoir des "millions" de commits dans un branche n'influe pas sur le temps de checkout. Ce qui influe c'est le nombre de différences entre la version actuelle et celle que tu vas "checkouter".

Et là, je ne comprends pas ce que Mercurial peut faire de mieux. Je souhaiterais une explication…

Si c'est juste qu'ils gèrent leurs branches avec Mercurial en faisant des clones (une des méthode proposé par Mercurial au lieu de faire des branches), tu peux aussi bien le faire avec git. C'est juste que c'est pas conseillé car tu dois alors bosser dans un autre répertoire, ce qui n'est pas pratique (surtout si tu dois relancer un IDE)

Lorsque j'ai lu l'article il y a quelques jours, j'en suis en fait sorti moins passionné que toi ;)
Le (presque) seul point positif que je tire de cet article c'est que du fait que Mercurial soit écrit en Python et qu'il est bien architecturé, il est facilement extensible.

Pour ce qui est de la solution mise en place par facebook, je pense qu'elle n'apportera RIEN à presque tous les utilisateurs de Mercurial. Outre le fait que cela s'applique à des dépots dont la taille est rencontré que très peu souvant, la solution adopté a été de couper avec la spécificité des DVCS d'être, justement, distribués et d'utiliser des serveurs memcache . Une architecture que presque personne n'utilisera…car s'il faut maintenant installer des serveurs memcache pour pouvoir avoir des meilleurs perfs avec mercurial, on est pas sorti de l'auberge.

Donc j'ai vine peur que la plupart des utilisateurs ne voient aucune amélioration en ce que le concerne…

L'idée derrière Watchman pour détecter les changements est par contre plutôt bonne mais pourrait aussi être utilisé par git…

au vu du nombre de serveurs en activité, y'a-t-il ENCORE un besoin pour se genre de serveur en Europe? Le besoin est plutôt dans le reste du monde, non?

Surtout que dans la page "join", ils indiquent que les serveurs sont faiblement sollicités…

Dans OSX, y'a un truc qui est vachement bien (bon OK, c'est pas dans l'interface), c'est leur système d'init très similaire à systemd!

(Comme je suis en vacances ce soir, c'est comme si on est vendredi…)

Je ne sais pas vraiment à quoi c'est dû (enfin, c'est surtout que je veux pas lancer de troll) mais j'ai l'impression qu'on a affaire à une "clientélisation" du logiciel libre (pour le pire comme pour le meilleur)

Je ne peux pas donner un avis car je n'ai pas assez d'informations en main mais, pour modérer tes propos, il ne faut pas oublier que toute personne peut être "client" pour certains logiciel (où elle n'a pas les compétences ou le temps pour s'investir) et contributeur sur d'autres. Perso, en ce qui concerne les distrib, je suis un parfait "client" par contre je contribue à au moins 3 logiciels libres et je fais des rapports de bugs sur pas mal d'autres…

Après, c'est vrai qu'il ne faut pas cracher sur le travail des autres et savoir que quand on contribue pas, il vaut mieux rester humble (mais il est vrai que certains ne savent pas faire…).

J'ai essayé mais j'ai maintenant des problème de clé PGP :(

Dans ce lien donné précédemment : http://forums.fedoraforum.org/showthread.php?p=1680574#post1680574
des message indiquent d'utiliser l'option --nogpgcheck …
Je ré-essaierais dans 15 jours lorsque je rentrerais chez moi…

Ce genre de commentaire condescendant et sans aucun soupçon d'empathie (dans le sens, essayer de se mettre à la place de l'autre et ne pas voir le problème qu'avec tes yeux) me fera toujours rire…

Si tout n'est pas rose sur ce point chez Fedora, tu devrais tout de même te poser quelques questions je pense.

Ben, justement, je m'en suis posé. J'ai une install PARFAITEMENT standard sans changement de config ni dépot exotique. Donc mis à part cela, je vois pas…

Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.

L'argument, par ce que j'arrive à le faire sans problème n'implique pas forcement que ça marche tout le temps…

Il suffit de deux choses: lire la doc correctement

J'ai fait et justement, c'est le cas nominal qui marche pas!

et éventuellement ne pas upgrader 2h après l'annonce histoire que les éventuels bugs restant soient trouvés.

C'est ce que je fait d'habitude mais il s'avère que j'ai pas trouvé le temps de mettre à jour vers la version précédente et j'ai profité du temps libre que j'avais avant de partir en vacances pour essayer. Il s'avère que j'ai pas réussi, d'où mon message…

Et si tu penses que la QA c'est de la merde, tu les as testé les beta ?

c'est bien de citer que les parties d'un commentaire qui permet de faire avancer ses idées. Le titre et la 1ère ligne du commentaire aurait du te permettre de comprendre que je n'ai peut-être pas le niveau de tester un beta car si ça foire, je ne pense pas pouvoir remettre le système d'aplomb. Et également que je ne suis peut-être pas en mesure de faire un rapport de bug intéressant (même s'il m'arrive d'en faire sur d'autre logiciels).

Et un commentaire comme cela :

Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.

me fait doucement rire lorsqu'il arrive après la bataille et qu'on sait maintenant que c'est un bug dans fedup qui fait que l'install ne marche pas…

PS : j'espère que ce commentaire t'auras au moins appris à prendre les gens un peu moins de haut…

j'avais pas installé fedup-dracut, mais après un nouvel essai, ça change rien…