La limitation de Twitter n'est pas technique, mais ergonomique.
C'est bien pour ça que Twitter pourrait utiliser les liens HTML pour afficher moins de 140 caractères, sans pour autant utiliser les URL raccourcies. Le fait que le source HTML soit long ou pas, ça ne change rien à l'ergonomie ...
Je ne sais plus si c'est encore le cas, mais à une époque, la tribune de linuxfr avait une raccourcissement automatique des URLs, quand tu rentait http://example.com, ça écrivait pour toi <a href="http://example.com">[url]</a>. Côté utilisateur, ça n'occupe pas plus de place que tinyurl.com/blabla, par contre, quand on passe la souris dessus, ça affiche l'URL dans la barre de status du navigateur, donc l'info est plus facilement accessible qu'avec les URLs raccourcies.
Forwarder un port n'est pas un trou de sécu en soi.
Euh, où tu vois parler de forward de port dans le mail ? Il parle de « forward SSH », ce qui est ambiguë en effet, mais le forward de port, c'est toi qui a extrapolé un peu vite.
Ensuite, il faut que le démon ssh soit activé sur la machine locale.
Bah, c'est un peu ce qui est écrit dans le mail, non ?
Git ne gère que le bit « executable ». Le format de stockage permettrait de stocker les bits r et w, mais en pratique, il n'utilise que les modes 755 et 644, puisque c'était plutôt contre-productif de gérer r et w dans un outil prévu pour gérer des sources (je crois que les toutes premières versions le faisaient, et ça a été supprimé).
Le propriétaire, là, je demande à voir, y'a rien qui permette de stocker ça dans les structures « tree » de Git.
En fait, la plupart des ces arguments s'appliquent aussi à « git grep » (pour peu qu'on utilise Git, mais franchement, qui utiliserait autre chose de nos jours ;-) ) :
Il ne cherche que dans les sources (i.e. dans ce qui est référencé par l'index de Git), donc ni dans les *~, ni dans les *.o, ni dans le .git par défaut
La mise en couleur des résultats est là par défaut si on a color.ui=true dans ~/.gitconfig.
Pour le nombre de caractères à taper, cf. ci-dessus, les alias c'est fait pour ça ;-).
Ceci dit, y'a l'air d'y avoir des trucs rigolos dans ack, comme le --perl qui regarde le shebang du fichier pour savoir si c'est du perl, ou
Pour faire court : le mot clé « volatile » en C et C++ spécifie le comportement du compilateur, mais il n'empêche pas le hardware de réordonner les accès. Et si tu poses la question, oui, le hardware moderne réordonne les accès.
Le « volatile » de Java est un peu plus utile, mais celui du C ou du C++ ne fait pas ce que tu penses.
Je ne sais pas si le contenu du bugtracker est récupérable dans le cas que tu donnes si tu n'en avait pas de copie locale avant.
Mais pour le dépôt de sources proprement dit, tu n'en a pas grand chose à faire que GitHub tu zappe ton projet. Changer d'hébergeur, c'est "git remote add [...]; git push --all" et on n'en parle plus, vu que par définition, tu as déjà l'historique complet dans toutes les copies locales. Typiquement, dans le cas de Linux : kernel.org down, ça n'a pas du prendre bien longtemps à Linus pour migrer vers GitHub, et ça ne lui prendra pas plus de temps de re-migrer vers kernel.org en temps voulu.
Si ça avait été SVN ou CVS, ça aurait été différent : il aurait fallu faire un "svnadmin dump" ou un truc du genre, mais le faire sur une machine compromise c'est moyen bof, donc il aurait surtout fallu prier pour avoir des backups dont on sait qu'ils ne sont pas compromis, restaurer le backup sur un autre serveur, ...
Mais Github utilise beaucoup Git, même pour les choses autres que l'hébergement de sources. Par exemple, on peut faire un "git clone" de son wiki, et un "git push" ailleurs (le moteur de wiki est open-source). Pour le bugtracking, je ne sais pas si c'est facile de récupérer ses données et de les réutiliser ailleurs par contre.
Oui, mais raler lors d'un push, c'est quasi normal: suffit que quelqu'un d'autre ait laché un commit sur la meme branche, et hop on y voit que du feu.
Relis le lien que j'ai posté ci-dessus. Les devs du noyau n'utilisent pas de dépôts partagés, donc si ça rale sur un push, c'est pas normal dans leur manière de fonctionner.
Et en plus cette sécurité n'existe que si le binaire de git n'a pas été modifié.
Le binaire sur le serveur ?
Non, justement. Même avec un serveur compromis, on ne peut pas éditer un commit dans l'historique sans ré-écrire tout ce qui vient après. Le serveur envoie juste des objets, et c'est le client qui fait un "git pull" qui recalcule les sha1 à la réception. Le serveur ne peut pas tricher. Et les tags signés avec GPG (et donc tout l'historique qui est derrière) ne sont pas falsifiables sans avoir compromis la clé GPG de Linus et/ou trouvé des conflits dans sha1.
Bien sûr, les gens qui sont un clone nouveau peuvent récupérer n'importe quoi (sauf les tags signés avec GPG) par contre.
Le « La conception même de git, avec les sommes de hachage SHA-1 calculées pour chaque commit et chaque fichier source, empêche d'implanter une backdoor. » de la news est un peu optimiste. Ce que Git empêche très bien, c'est de réécrire un commit loin dans l'historique et sans qu'on s'en aperçoive. Mais ajouter des commits à une branche existante, ça n'est effectivement pas Git qui va l'empêcher.
La démarche est discutable, mais ça n'empêche pas forcément le projet d'aboutir. Git a une bonne dose de « réinvention de la roue » (moteur de diff, parseur d'options en ligne de commande parse_option, bibliothèque de manipulation de chaînes strbuff, ...), mais une bonne partie des roues réinventées par Git sont de bonne qualité, et le fait de les avoir inclus dans le code de Git fait qu'il est relativement simple de recompiler Git soi-même (j'ai déjà essayé de recompiler une vieille version de SVN, il fallait plus ou moins recompiler tout Apache avec, c'était pas une partie de plaisir).
Si c'était moi qui avait écrit Git, je n'aurais sans doute pas fait comme ça, mais je suis bien obligé d'admettre que le résultat reste bon (et je ne suis pas le seul à apprécier Git je crois ;-) ).
Maintenant, est-ce que veracity réussira à se faire une place à côté de solutions relativement bien établies comme Git et Mercurial, ça reste à voir ...
Ça dépends à qui tu t'adresse. Si tu veux installer une forge pour tes besoins persos, tu auras sans doute meilleur jeu d'installer un truc minimaliste et qui te conviens. Mais pour un organisation qui veut offrir une forge à un grand nombre d'utilisateurs très différents, fusionforge est un très bon choix.
Par exemple : https://gforge.inria.fr/ ou http://forge.imag.fr/. La plupart des projets n'utilisent qu'un très petit nombre de fonctionnalité, mais à peu près quelle que soit la fonctionnalité, tu aurais des gens qui raleraient si elle n'était pas là !
Pour gitorious, il y a aussi un module Wiki (avec possibilité d'édition en ligne ou via Git). Ce qui me manque avec Gitorious, c'est tout bête : des mailing-lists (oui, on peut en avoir ailleurs, mais c'est sympa d'avoir tout au même endroit) !
Il me semble que Kmail fait ça : en stockant les contacts dans des mails, dans une boite IMAP spécifique (et idem pour les événements calendrier et je sais plus quoi d'autre)
Euh, oui, l'OS essaye en IPv6 d'abord, mais normalement, ça marche aussi bien qu'IPv4. Le timeout+fallback IPv4, c'est si la couche IPv6 ne marche pas, et j'ai du mal à croire que ça soit parce que le protocole IPv6 est mauvais, mais plutôt parce qu'il y a des hacks sur le chemin entre toi et la machine distante.
You don’t have IPv6, but you shouldn’t have problems on websites that add IPv6 support.
Allez comprendre comment sans ipv6 on n'aura pas de problemes pour les sites ipv6. Un tour de passe-passe de free?
Il n'est dit nulle part « websites that remove IPv4 support » hein ...
Je ne suis pas un expert, mais si j'ai bien compris, le problème avec IPv6, c'est que souvent, c'est supporté via des hacks (tunnels, NAT, ...) pas toujours bien débuggés. Donc il est tout à fait possible que ta machine soit dual-stack mais fasse de l'IPv4 aujourd'hui parce que le site que tu visites est IPv4-only, et que le jour où le site ajoute du support pour IPv6, tu te mette à avoir des problèmes parce que ton FAI a un support IPv6 cassé. D'où les sites qui te préviennent si tu risques d'avoir des problèmes avec l'ajout d'IPv6.
Il parait que Google gère ça avec une whitelist de FAI qui donnent un accès IPv6 correct, et free en fait partie (j'y accède en IPv6 depuis bien avant le fameux IPv6 day). Pour les autres, google fait simplement croire qu'il n'est qu'IPv4 (sauf hier).
On voit qu'il contribue effectivement beaucoup moins ces dernières années. Comme il le dit très bien dans l'interview, il a été un excellent architecte pour Git (bon, il n'a pas tout inventé non plus, il connaissait très bien bitkeeper de l'extérieur, et a repris beaucoup d'idées de Monotone). Mais quand l'effort sur Git a commencé à arriver sur l'interface utilisateur, la portabilité & co, il a vraiment passé la main parce que ce n'est pas là qu'il est bon (et qu'il a un autre projet qui l'occupe un peu). Les patchs qu'il a écrit ces derniers temps sont en général des trucs écrits parce qu'il en avait besoin pour le kernel.
Ce n'est pas ça la tivoisation. Distribuer un binaire de Linux modifié sans distribuer les sources, c'est interdit par la licence, que ce soit GPLv2 ou GPLv3. La tivoisation, c'est :
Un logiciel est sous GPL
Un constructeur distribue ce logiciel (ou une version modifiée) sur une plateforme matérielle fermée
Légalement, tu peux modifier le logiciel, mais techniquement, si tu le fais, le matériel refuse de l'exécuter.
Linus ne dit pas que c'est bien, il dit que ce n'est pas l'affaire du logiciel de s'occuper de ça.
Dans le papier, j'étais limité par le nombre de pages, donc je ne me suis pas étendu sur la question.
Dans le polycopié pour les étudiants, il y a un paragraphe qui explique rapidement ce qu'est le logiciel libre avec quelques pointeurs pour ceux qui veulent en savoir plus.
[^] # Re: twitteur
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mysql : piratage du site mysql. Évalué à 2.
C'est bien pour ça que Twitter pourrait utiliser les liens HTML pour afficher moins de 140 caractères, sans pour autant utiliser les URL raccourcies. Le fait que le source HTML soit long ou pas, ça ne change rien à l'ergonomie ...
Je ne sais plus si c'est encore le cas, mais à une époque, la tribune de linuxfr avait une raccourcissement automatique des URLs, quand tu rentait http://example.com, ça écrivait pour toi <a href="http://example.com">[url]</a>. Côté utilisateur, ça n'occupe pas plus de place que tinyurl.com/blabla, par contre, quand on passe la souris dessus, ça affiche l'URL dans la barre de status du navigateur, donc l'info est plus facilement accessible qu'avec les URLs raccourcies.
[^] # Re: ssh forward?
Posté par Matthieu Moy (site web personnel) . En réponse au journal kernel.org, le retour !. Évalué à 2.
Euh, où tu vois parler de forward de port dans le mail ? Il parle de « forward SSH », ce qui est ambiguë en effet, mais le forward de port, c'est toi qui a extrapolé un peu vite.
Bah, c'est un peu ce qui est écrit dans le mail, non ?
[^] # Re: twitteur
Posté par Matthieu Moy (site web personnel) . En réponse au journal Mysql : piratage du site mysql. Évalué à 5.
C'est bien ça la question ...
Mais si l'URL finale est "up", un lien direct reste valable, alors qu'un lien raccourci ne l'est plus. Pour les détails, cf par exemple
http://hugeurl.geeks.org/?NTAwMmYxNGUxZTM0NGI2NTcyNDYzNWE0Y2EwMGMxZjEmMTImVm0wd2QyUXlVWGxXYTJoV1YwZG9WVll3Wkc5alJsWjBUVlpPV0Zac2JETlhhMUpUVmpGYWMySkVUbGhoTWsweFZqQmFTMk15U2tWVWJHaG9UVmhDVVZadGVGWmxSbGw1Vkd0c2FsSnRhRzlVVjNOM1pVWmFkR05GZEZSTlZUVkpWbTEwYTFkSFNrZGpTRUpYVFVad1NGUlVSbUZqVmtaMFVteFNUbUY2UlRGV1ZFb3dWakZhV0ZOcmJGSmlSMmhZV1d4b2IwMHhXbGRYYlVaclVsUkdXbGt3WkRSVk1rcElaSHBHVjJFeVVYZFpWRVpyVTBaT2NscEhjRlJTVlhCWlZrWldhMVV5VW5OalJtUllZbFZhY1ZscldtRmxWbVJ5VjI1a1YwMUVSa1pWYkZKRFZqQXhkVlZ1V2xaaGExcFlXa1ZhVDJOdFNrZFRiV3hYVWpOb1dGWnRNSGRsUjBsNFUydGthVk5GV2xSWmJHaFRWMVpXY1ZKcmRGUldiRm93V2xWb2ExWXdNVVZTYTFwWFlrZG9jbFpxU2tabFZsWlpXa1prYUdFeGNGaFhiRnBoVkRKT2RGSnJhR2hTYXpWeldXeG9iMWRHV25STlNHaFBVbTE0VjFSVmFHOVhSMHBJVld4c1dtSkhhRlJXTUZwVFZqRmtkRkp0ZUZkaWEwcElWbXBKZUUxR1dsaFRhMlJxVWtWYVYxWnFUbTlsYkZweFUydGthbUpWVmpaWlZWcHJZVWRGZUdOR2JGaGhNVnBvVmtSS1QyUkdUbkphUmxKcFZqTm9XVlpYY0U5aU1rbDRWMjVTYWxKVk5YQlVWbFpYVGtaa2NsWnRkRmhTTUZZMVZsZDRjMWR0U2tkWGJXaFhZVEZ3VkZacVJtdGtWbkJHVGxaT2FXRXdjRWxXYlhCS1pVVXhSMWRzYUZSaVJuQnhWV3hrVTFsV1VsWlhiVVpyWWtad2VGVnRkREJoYXpGeVRsVnNXbFpXY0ROWlZXUkdaV3hHY2sxV1pGZE5NRXBKVm10U1IyRXhaRWRWYmtwb1VqSm9WRmxZY0Zka01WcDBZMFYwYVUxWFVraFdNalZUVkd4T1NHRkdRbFpoYTFwSVZGUkdVMVl5UmtaUFZtUnBWbGhDU2xac1pEUmpNV1IwVTJ0a1dHSlhhRmhaVkVaM1pXeHJlV1ZJWkZOV2ExcDVWREZrYzFVd01WWmlla1pYWWxSRk1GWlVSbHBsUm1SWldrVTFWMVpzY0ZWWFYzUnJZakZzVjFWc1dsaGliVkp6V1d0YWMwMHhXWGxOVldSV1RXdHdSMVJzYUhkV01WbDZZVWhLV2xaWFVrZGFWV1JQVTBkR1IyRkhiRk5pU0VKMlZqSjBVMUl4VFhsVmEyUlVZbXR3YjFWcVRtOVdSbXhaWTBaa2EwMVdjRmxhVldNMVZXc3hjbUpFVWxkTlYyaDJWMVphUzFJeFRuVlJiRlpYWWtoQ1dWWkhkR0ZaVm1SSVZXdG9hMUp0VW5CV2JHaERUbFphU0dWSFJtcE5WMUl3VlRKNGMxWldaRWhoUjBaVlZteHdNMWxWV25kU2JIQkdUMVU1YVZKWVFYZFhiRlpoWVRKR1dGSllaR3BTVjNoWVdWZDBkbVF4YkhGVGExcHNVbTFTZWxsVldsTmhSVEYwWVVab1dGWnNTa3hXVkVaYVpVWldjMkZGT1ZkbGJYaFFWa1phWVdReVZrZFdibEpyVWtWS2IxbFljRWRsVmxKelZtNWtWMkY2UmpGWlZWcHZWMnhhVjFacVVsZE5WbkJJV1hwR1lXTXhjRWhpUm1oVFZsaENTMVpxU2pCVk1VbDRWRmhzVlZkSGFIRlZiR1EwVmpGc2MyRkZUbGRTYlhoYVdUQmFhMkpIU2toVmJHeGhWbGROTVZsV1ZYaFhSMVpIWVVaa1RtRnNXbFZXYTJRMFdWWktjMVJ1VG1oU2JGcFlWRlJLYjFOV1draGtSMFphVmpGS1NWWlhkRzloTVVsNVlVaENWbUpIYUVSV01uaHJWakZhYzFkck9WZGlSM2N4VmxSS05HTXhXbGRhUldob1VtMW9WbFp0ZUhkTk1XeFdWMjVrVTJKSVFrZFVNVlUxWVZaS1dWRnFWbGRTTTJob1ZrUktSMVl4Y0VaYVJrNW9Za2hDV1ZkV1pEQmtiVkY0WWtab2FtVnJXbGhVVm1oRFVqRmtjbGRzVG1oV01GWTJWVmMxYjFZeFdqWlNWRUpoVWtWYWNsVnFTa3RUVms1ellVZG9UazFWY0ZoV2JHTjRUa2RSZVZaclpGZGlSMUp2Vlc1d2MySXhVbGRYYms1T1RWWnNOVnBGYUd0V01ERkZVbXBHV2xaWGFFeFdNbmhoVjBaV2NscEhSbGROTW1oSlYxaHdTMU14U1hoalJXaG9VakpvVDFVd1ZrdE5iRnAwVFZSU1ZrMVZNVFJXVm1odlYwWmtTR0ZIYUZaTlJuQm9WbXhhYzFkWFRrbFViR2hUWWxob05sWnFTakJOUmxsNFYyNU9hbEpGU2xaV2JGcExVMFphV0dNemFGTldiSEI1V1ZWYWExUnNXWGxoUkVwWFRWWndhRlY2UmtwbFJsSjFWbXhLYVZKc2NGbFdSbEpIVXpBMWMxZHJaRlpoTWxKWFZGZHplRTVXVm5Sa1IwWldVbXh3TUZaWE5VTldNa3BIWTBkR1ZWWnNjSEpXYWtaaFl6RmtjazlXWkdsU00yTjRWbXhTU2sxV1dYaFdibEpVWW14YVUxbHJaRzlXTVd4VlVtMUdhRkpzYkROV01qVkxZa1pLZEZWdWJGaGhNbEYzVm1wS1MyTnNUbkppUm1oWFlrWndiMWRXVWt0U01XUkhVMnhzWVZJelFsUldNR1J2VjFaYVIxZHRkRlpOUkVJMFZqSjBWMVpIUlhoalNFNVdZbGhvTTFwWGVHdGpiR1IwWkVkb1YyRXpRalpYVkVKaFVURlplRmRZY0ZaaWEzQm9WbXBPVGsxV1dsaGxSVTVYVmxSR1JsUlZVWGRRVVQwOQ==
Bon, enfin je crois que tu as juste mal lu le commentaire auquel tu réponds ;-)
[^] # Re: RCS, sinon quoi ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 2.
???
Git ne gère que le bit « executable ». Le format de stockage permettrait de stocker les bits r et w, mais en pratique, il n'utilise que les modes 755 et 644, puisque c'était plutôt contre-productif de gérer r et w dans un outil prévu pour gérer des sources (je crois que les toutes premières versions le faisaient, et ça a été supprimé).
Le propriétaire, là, je demande à voir, y'a rien qui permette de stocker ça dans les structures « tree » de Git.
# git grep
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 8.
En fait, la plupart des ces arguments s'appliquent aussi à « git grep » (pour peu qu'on utilise Git, mais franchement, qui utiliserait autre chose de nos jours ;-) ) :
Ceci dit, y'a l'air d'y avoir des trucs rigolos dans ack, comme le --perl qui regarde le shebang du fichier pour savoir si c'est du perl, ou
qui fait grosso-modo un
[^] # Re: Il fallait y penser
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche ack 1.96 — mieux que grep. Évalué à 8.
ZSH supporte depuis longtemps le wildcard ** qui permet de faire des choses comme
qui marchent nickel avec des espaces, évitent de créer un processus supplémentaire, et répondent à la plupart des besoins courants.
La bonne nouvelle, c'est que bash a la même chose maintenant (depuis la 4.0 je crois), si on utilise « shopt -s globstar ».
[^] # Re: templates variadiques
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 1.
« The volatile keyword is basically worthless as a portable threading construct.[2][3][4][5][6] »
http://en.wikipedia.org/wiki/Volatile_variable
(je te laisse suivre les liens [2][3][4][5][6], y'a pas que du kernel. En particulier, http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/)
Pour faire court : le mot clé « volatile » en C et C++ spécifie le comportement du compilateur, mais il n'empêche pas le hardware de réordonner les accès. Et si tu poses la question, oui, le hardware moderne réordonne les accès.
Le « volatile » de Java est un peu plus utile, mais celui du C ou du C++ ne fait pas ce que tu penses.
[^] # Re: déçu je suis
Posté par Matthieu Moy (site web personnel) . En réponse au journal Le pragmatisme à la Torvalds, ou, Linux sur Github. Évalué à 2.
Je ne sais pas si le contenu du bugtracker est récupérable dans le cas que tu donnes si tu n'en avait pas de copie locale avant.
Mais pour le dépôt de sources proprement dit, tu n'en a pas grand chose à faire que GitHub tu zappe ton projet. Changer d'hébergeur, c'est "git remote add [...]; git push --all" et on n'en parle plus, vu que par définition, tu as déjà l'historique complet dans toutes les copies locales. Typiquement, dans le cas de Linux : kernel.org down, ça n'a pas du prendre bien longtemps à Linus pour migrer vers GitHub, et ça ne lui prendra pas plus de temps de re-migrer vers kernel.org en temps voulu.
Si ça avait été SVN ou CVS, ça aurait été différent : il aurait fallu faire un "svnadmin dump" ou un truc du genre, mais le faire sur une machine compromise c'est moyen bof, donc il aurait surtout fallu prier pour avoir des backups dont on sait qu'ils ne sont pas compromis, restaurer le backup sur un autre serveur, ...
[^] # Re: Service libre
Posté par Matthieu Moy (site web personnel) . En réponse au journal Le pragmatisme à la Torvalds, ou, Linux sur Github. Évalué à 2.
Mais Github utilise beaucoup Git, même pour les choses autres que l'hébergement de sources. Par exemple, on peut faire un "git clone" de son wiki, et un "git push" ailleurs (le moteur de wiki est open-source). Pour le bugtracking, je ne sais pas si c'est facile de récupérer ses données et de les réutiliser ailleurs par contre.
[^] # Re: Cle ssh corrompu ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les serveurs de kernel.org ont été compromis. Évalué à 3.
Relis le lien que j'ai posté ci-dessus. Les devs du noyau n'utilisent pas de dépôts partagés, donc si ça rale sur un push, c'est pas normal dans leur manière de fonctionner.
[^] # Re: Cle ssh corrompu ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les serveurs de kernel.org ont été compromis. Évalué à 2.
Non, un commit ajouté à une branche existante, c'est le scénario normal pour un rebase ou un pull.
Push va raler (non-fast-forward) par contre.
[^] # Re: Cle ssh corrompu ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les serveurs de kernel.org ont été compromis. Évalué à 2.
Le binaire sur le serveur ?
Non, justement. Même avec un serveur compromis, on ne peut pas éditer un commit dans l'historique sans ré-écrire tout ce qui vient après. Le serveur envoie juste des objets, et c'est le client qui fait un "git pull" qui recalcule les sha1 à la réception. Le serveur ne peut pas tricher. Et les tags signés avec GPG (et donc tout l'historique qui est derrière) ne sont pas falsifiables sans avoir compromis la clé GPG de Linus et/ou trouvé des conflits dans sha1.
Bien sûr, les gens qui sont un clone nouveau peuvent récupérer n'importe quoi (sauf les tags signés avec GPG) par contre.
[^] # Re: Cle ssh corrompu ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Les serveurs de kernel.org ont été compromis. Évalué à 3.
Une lecture intéressante sur le sujet :
http://git-blame.blogspot.com/2011/08/how-to-inject-malicious-commit-to-git.html
(l'auteur est le mainteneur de Git)
Le « La conception même de git, avec les sommes de hachage SHA-1 calculées pour chaque commit et chaque fichier source, empêche d'implanter une backdoor. » de la news est un peu optimiste. Ce que Git empêche très bien, c'est de réécrire un commit loin dans l'historique et sans qu'on s'en aperçoive. Mais ajouter des commits à une branche existante, ça n'est effectivement pas Git qui va l'empêcher.
[^] # Re: fermer une session http
Posté par Matthieu Moy (site web personnel) . En réponse au journal Et pourquoi pas un nouveau modèle de sécurité pour le web ?. Évalué à 2.
Je pense qu'il fait référence au fait que Firefox garde le mot de passe HTTP en cache jusqu'à la fermeture du navigateur.
C'est assez pénible quand un site utilise l'authentification HTTP et qu'il n'y a pas de moyen de se délogger.
[^] # Re: Pourquoi C ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Veracity, un nouveau gestionnaire de versions décentralisé. Évalué à 10.
La démarche est discutable, mais ça n'empêche pas forcément le projet d'aboutir. Git a une bonne dose de « réinvention de la roue » (moteur de diff, parseur d'options en ligne de commande parse_option, bibliothèque de manipulation de chaînes strbuff, ...), mais une bonne partie des roues réinventées par Git sont de bonne qualité, et le fait de les avoir inclus dans le code de Git fait qu'il est relativement simple de recompiler Git soi-même (j'ai déjà essayé de recompiler une vieille version de SVN, il fallait plus ou moins recompiler tout Apache avec, c'était pas une partie de plaisir).
Si c'était moi qui avait écrit Git, je n'aurais sans doute pas fait comme ça, mais je suis bien obligé d'admettre que le résultat reste bon (et je ne suis pas le seul à apprécier Git je crois ;-) ).
Maintenant, est-ce que veracity réussira à se faire une place à côté de solutions relativement bien établies comme Git et Mercurial, ça reste à voir ...
[^] # Re: Positionnement par rapport à la concurrence ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Fusionforge 5.1 & sa communauté. Évalué à 5.
Ça dépends à qui tu t'adresse. Si tu veux installer une forge pour tes besoins persos, tu auras sans doute meilleur jeu d'installer un truc minimaliste et qui te conviens. Mais pour un organisation qui veut offrir une forge à un grand nombre d'utilisateurs très différents, fusionforge est un très bon choix.
Par exemple : https://gforge.inria.fr/ ou http://forge.imag.fr/. La plupart des projets n'utilisent qu'un très petit nombre de fonctionnalité, mais à peu près quelle que soit la fonctionnalité, tu aurais des gens qui raleraient si elle n'était pas là !
[^] # Re: Positionnement par rapport à la concurrence ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Fusionforge 5.1 & sa communauté. Évalué à 3.
Pour gitorious, il y a aussi un module Wiki (avec possibilité d'édition en ligne ou via Git). Ce qui me manque avec Gitorious, c'est tout bête : des mailing-lists (oui, on peut en avoir ailleurs, mais c'est sympa d'avoir tout au même endroit) !
[^] # Re: synchronisation des instances
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Thunderbird 5 est sorti. Évalué à 1.
Il me semble que Kmail fait ça : en stockant les contacts dans des mails, dans une boite IMAP spécifique (et idem pour les événements calendrier et je sais plus quoi d'autre)
[^] # Re: Complètement imbitable...
Posté par Matthieu Moy (site web personnel) . En réponse au journal astuce bash: de l'usage du elif. Évalué à 1.
Heureusement ;-)
Tu voulais dire $?, je suppose.
[^] # Re: icanhazip.com
Posté par Matthieu Moy (site web personnel) . En réponse au journal free.fr et IPv6. Évalué à 1.
Euh, oui, l'OS essaye en IPv6 d'abord, mais normalement, ça marche aussi bien qu'IPv4. Le timeout+fallback IPv4, c'est si la couche IPv6 ne marche pas, et j'ai du mal à croire que ça soit parce que le protocole IPv6 est mauvais, mais plutôt parce qu'il y a des hacks sur le chemin entre toi et la machine distante.
[^] # Re: icanhazip.com
Posté par Matthieu Moy (site web personnel) . En réponse au journal free.fr et IPv6. Évalué à 1.
Il n'est dit nulle part « websites that remove IPv4 support » hein ...
Je ne suis pas un expert, mais si j'ai bien compris, le problème avec IPv6, c'est que souvent, c'est supporté via des hacks (tunnels, NAT, ...) pas toujours bien débuggés. Donc il est tout à fait possible que ta machine soit dual-stack mais fasse de l'IPv4 aujourd'hui parce que le site que tu visites est IPv4-only, et que le jour où le site ajoute du support pour IPv6, tu te mette à avoir des problèmes parce que ton FAI a un support IPv6 cassé. D'où les sites qui te préviennent si tu risques d'avoir des problèmes avec l'ajout d'IPv6.
Il parait que Google gère ça avec une whitelist de FAI qui donnent un accès IPv6 correct, et free en fait partie (j'y accède en IPv6 depuis bien avant le fameux IPv6 day). Pour les autres, google fait simplement croire qu'il n'est qu'IPv4 (sauf hier).
# Pas de débogueur alternatif ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Linux ou bien GNU/Linux ?. Évalué à 6.
... sauf http://lldb.llvm.org/ quand même, qui a l'air prometteur (j'ai pas testé)
[^] # Re: merci
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 10.
Euh, ça, c'est un miroir (non-officiel) sur Github. Si j'ai bien compris, ça ne liste que les gens qui ont un compte sur github.
Pour une liste plus précise, cf. http://git-scm.com/about où tu peux voir que Linus est bon troisième contributeur.
Pour plus de détails :
$ git log --date=short --format='%ad' --author=Linus Torvalds | cut -d - -f 1 | sort -k 2 | uniq -c
680 2005
162 2006
110 2007
81 2008
48 2009
16 2010
3 2011
On voit qu'il contribue effectivement beaucoup moins ces dernières années. Comme il le dit très bien dans l'interview, il a été un excellent architecte pour Git (bon, il n'a pas tout inventé non plus, il connaissait très bien bitkeeper de l'extérieur, et a repris beaucoup d'idées de Monotone). Mais quand l'effort sur Git a commencé à arriver sur l'interface utilisateur, la portabilité & co, il a vraiment passé la main parce que ce n'est pas là qu'il est bon (et qu'il a un autre projet qui l'occupe un peu). Les patchs qu'il a écrit ces derniers temps sont en général des trucs écrits parce qu'il en avait besoin pour le kernel.
[^] # Re: Torvalds vs Stallman
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Linus Torvalds : l’interview anniversaire des 20 ans du noyau. Évalué à 6.
Ce n'est pas ça la tivoisation. Distribuer un binaire de Linux modifié sans distribuer les sources, c'est interdit par la licence, que ce soit GPLv2 ou GPLv3. La tivoisation, c'est :
Linus ne dit pas que c'est bien, il dit que ce n'est pas l'affaire du logiciel de s'occuper de ça.
[^] # Re: Licences des ressources
Posté par Matthieu Moy (site web personnel) . En réponse au journal Unix-training: des outils pour enseigner Unix ludiquement. Évalué à 1.
Dans le papier, j'étais limité par le nombre de pages, donc je ne me suis pas étendu sur la question.
Dans le polycopié pour les étudiants, il y a un paragraphe qui explique rapidement ce qu'est le logiciel libre avec quelques pointeurs pour ceux qui veulent en savoir plus.