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.
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).
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).
…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 ;)
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…
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…).
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…
Je suis un utilisateur de cette distrib sans grande connaissance technique de linux.
Et j'ai toujours trouvé que les mises à jours pour fedora, c'est un peu le bordel. Il y a plusieurs façon de faire (fed up, preupgrade, yum) et on sait pas quelle est la bonne.
Depuis que je suis sur fedora (la 13, je crois), j'ai toujours eu une bonne raison de refaire une install complète.
Seulement, pour le passage de la 18 vers la 19, je souhaitais faire une mise à jour pour faciliter le passage à la version. N'ayant pas cherché la solution plus que çà, je n'ai finalement pas mis à jour.
La sortie de la 20 étant un bon moment pour me lancer, j'ai essayé :
fed up. Tout se passe bien (màj des dépot, téléchargement des paquets, …) jusqu'au reboot pour faire la mise à jour et là y'a surement un problème qui fait que ça reboot aussitôt sans rien faire et je me retrouve avec mon ancienne version. Je sais pas où trouver les logs :(
preupgrade (ensuite) qui me dit qu'il n'y a pas de version plus à jour (surement à cause de fed up).
Du coup, je suis bloqué sans savoir quoi faire et la mise à jour ne fonctionne pas…
Pourquoi pas, ça peut être utile pour mieux comprendre le brol.
Je suis pas certain. Quand tu veux comprendre un outil, il faut des fois rechercher des messages d'erreur sur le web. Et si ton message est localisé, t'as du mal à trouver.
Pour moi, la traduction est SEULEMENT pour ceux qui ne parlent pas DU TOUT l'anglais.
PS : Et pourtant, je suis le traducteur français d'une des IHM de Git. Je continue à l'utiliser en anglais (et le conseille fortement à mes collègues) même si je suis l'auteur de la traduction française.
[^] # Re: OpenRC
Posté par cosmocat . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 8.
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?
[^] # Re: niveau -0.5
Posté par cosmocat . En réponse au journal L'art de stocker des mots de passe. Évalué à 4.
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.
[^] # Re: niveau -0.5
Posté par cosmocat . En réponse au journal L'art de stocker des mots de passe. Évalué à 6.
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…
[^] # Re: Uchronie
Posté par cosmocat . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
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.
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
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).
[^] # Re: KDE : Quel distrib ?
Posté par cosmocat . En réponse à la dépêche KDE SC 4.12, 4.11.5 et Frameworks 5. Évalué à 1.
Je sais pas si ça peut t'aider : Best 2013 KDE Ditribution
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
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).
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 1.
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.
Apparement, reposurgeon peut faire çà.
[^] # Re: Mercurial vu par Facebook
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 8.
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 ;)
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Tu as raison, il faut faire des cpold des répertoires .git et .hg…
[^] # Re: c'est une question de philosophie
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 5.
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, …
[^] # Re: Investissement de facebook dans mercurial
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 7.
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)
[^] # Re: Mercurial vu par Facebook
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 9.
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…
# J'ai rien compris, mais...
Posté par cosmocat . En réponse au journal Blague : Plouf le serveur. Évalué à 3.
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…
[^] # Re: GNOME Shell est laid
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 9.
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…)
[^] # Re: Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 4.
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…).
[^] # Re: Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 2.
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…
[^] # Re: Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 3.
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…
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…
L'argument, par ce que j'arrive à le faire sans problème n'implique pas forcement que ça marche tout le temps…
J'ai fait et justement, c'est le cas nominal qui marche pas!
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…
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 :
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…
[^] # Re: Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 2.
j'avais pas installé fedup-dracut, mais après un nouvel essai, ça change rien…
[^] # Re: Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 5.
En tout cas, pour moi, elle porte bien son nom :(
# Utilisateur lambda...
Posté par cosmocat . En réponse à la dépêche Fedora 20, dite Heisenbug, est disponible et le Projet Fedora fête ses 10 ans !. Évalué à 3.
Je suis un utilisateur de cette distrib sans grande connaissance technique de linux.
Et j'ai toujours trouvé que les mises à jours pour fedora, c'est un peu le bordel. Il y a plusieurs façon de faire (fed up, preupgrade, yum) et on sait pas quelle est la bonne.
Depuis que je suis sur fedora (la 13, je crois), j'ai toujours eu une bonne raison de refaire une install complète.
Seulement, pour le passage de la 18 vers la 19, je souhaitais faire une mise à jour pour faciliter le passage à la version. N'ayant pas cherché la solution plus que çà, je n'ai finalement pas mis à jour.
La sortie de la 20 étant un bon moment pour me lancer, j'ai essayé :
fed up. Tout se passe bien (màj des dépot, téléchargement des paquets, …) jusqu'au reboot pour faire la mise à jour et là y'a surement un problème qui fait que ça reboot aussitôt sans rien faire et je me retrouve avec mon ancienne version. Je sais pas où trouver les logs :(
preupgrade (ensuite) qui me dit qu'il n'y a pas de version plus à jour (surement à cause de fed up).
Du coup, je suis bloqué sans savoir quoi faire et la mise à jour ne fonctionne pas…
[^] # Re: Vue isométrique
Posté par cosmocat . En réponse à la dépêche Ned et les maki 0.1. Évalué à 2.
Effectivement, c'est un GROS problème de jouabilité çà…
Il y a pas très longtemps, un doodle de Google avait ce problème là : http://www.google.com/doodles/doctor-whos-50th-anniversary
[^] # Re: Vue isométrique
Posté par cosmocat . En réponse à la dépêche Ned et les maki 0.1. Évalué à 7.
Peut-être faudrait-il changer l'angle de vue pour voir un peu plus d'au dessus sans pour autant être complètement en haut, non?
[^] # Re: C'est vrai que c'est assez drôle
Posté par cosmocat . En réponse au journal traduction git. Évalué à 10.
Je suis pas certain. Quand tu veux comprendre un outil, il faut des fois rechercher des messages d'erreur sur le web. Et si ton message est localisé, t'as du mal à trouver.
Pour moi, la traduction est SEULEMENT pour ceux qui ne parlent pas DU TOUT l'anglais.
PS : Et pourtant, je suis le traducteur français d'une des IHM de Git. Je continue à l'utiliser en anglais (et le conseille fortement à mes collègues) même si je suis l'auteur de la traduction française.
# Vue isométrique
Posté par cosmocat . En réponse à la dépêche Ned et les maki 0.1. Évalué à 4.
Avant même d'avoir lu la dépêche, je me suis dis que la vue isométrique, c'est vraiment pas le bon choix…
Et, Oh!, grande surprise :