Ça fait des années que Reiser ne participait plus à ReiserFS, quand il a commencé Reiser4 (2004 ?) il a arreté le dev ReiserFS. C'est donc les distributions qui ont pris le relai (principalement SUSE et Mandriva, Chris Mason faisait partir de l'équipe de chez SUSE qui maintenait ReiserFS).
Et c'est plutot standard (et très utilisé dans la communauté python). D'ailleurs une adaptation de sphinx pour faire des feuilles d'exo ca roxerait, avec un joli html et le latex...
Un projet "facile" c'est de se greffer au travail de redhat sur network-manager pour proposer des fonctionnalités IPv6 (intégration avec ND-RDNSS, création de tunnel, etc). En plus la plupart des briques sont déjà la (la lib pour causer au kernel via netlink a deja le support pour l'IPv6), il manque surtout un travail d'ui.
Surtout que VMWare n'est pas entierement fermé au niveau open-source (un certain nombre de devs bossent sur gnome, et reviewboard http://code.google.com/p/reviewboard/ vient de chez eux).
Si c'est publié c'est pas brevetable normalement. Et ça profite à toute la communauté scientifique (parce que c'est super lourd de chercher quelque chose et de t'apercevoir que quelqu'un avait breveté le résultat sur lequel tu t'appuies).
Si j'ai bien compris le "smart protocol" (git://) ne passe pas par http (même si c'est possible d'interragir via http ou rsync, dans ce cas le protocole est "idiot").
Ça détaille pas pourquoi Mercurial est meilleur que Git (windows, taille du code, plugins, pas besoin de repack, protocole réseau firewall-friendly via http).
A ma connaissance non, il y a beaucoup de travail sur le 2-way avec subversion (avec hgsubversion qui commence à être bien avancé). Sur git il y a quelques efforts pour incorporer fast-import/fast-export mais pas beaucoup plus. Mais c'est vrai que c'est certainement beaucoup plus facile que le bidirectionnel svn.
Ah si, aussi pendant le Google Summer of Code mentor summit à l'automne, il y a eu pas mal de discussions pour voir si on pourrait rapprocher le protocole réseau des deux projets.
Merci pour les précisions, j'ai déjà commencé à corriger des warnings de python2.6 -3, y'a un guide qui explique comment porter ? Le plus embetant c'est les warnings qu'on ne peut pas corriger facilement en supportant toujours python2.3 (example le mot clé cmp pour le tri de liste).
Et c'est quoi la raison fondamentale pour que ce ne soit pas possible de mélanger les bytes et l'unicode à l'écriture ? C'est parce que ça empeche de faire un aller-retour (si on écrit des bytes mélangés à l'unicode, on ne peut pas le relire en garantissant le même résultat) ?
J'aimerais bien voir le mail, c'est sur une mailing-list ?
Perso j'ai plutot entendu Matt troller pour dire que il préférait encore Ruby à python3.
A moins qu'une version majeure soit un redesign important (un futur hypothétique hg-ng), je ne pense pas que python3 sera supporté (même si des efforts sont fait pour faciliter la conversion avec 2to3.py), la compatibilité avec les anciennes versions python (2.3 à 2.6) restant prioritaire.
C'est comme pour les outils de backup, si un nom fichier n'est pas décodable depuis la locale utilisée vers unicode, on ne peut pas l'ignorer non plus, donc on considère les noms de fichiers comme des bytes.
Par exemple, si les noms de fichiers sont en UTF-8, mais que pour une raison ou pour une autre (par exemple ton programme est lancé depuis cron), mercurial est lancé avec la locale "C", alors si on considérait les noms de fichiers comme autre chose que des bytes, alors ça planterait (on ne peut pas ouvrir certains fichiers par exemple).
Maintenant le problème pour nous en dehors de transformer tous les open/listdir/etc en version bytes (bon a priori on est déjà en binary mode à cause de windows donc les open ça doit être bon) c'est que l'API bytes n'est pas complete, par exemple au niveau de sys.argv et os.environ.
Et à mon avis il y encore d'autres problèmes qui n'ont pas été résolus par exemple je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.
En gros tu veux que LANG=C mercurial, marche avec des noms de fichiers en utf-8, ça demande pas mal de changements avec python3 (où les noms de fichiers sont convertis en unicode).
À long terme, tous les systèmes utiliseront Unicode. Pour information, Windows utilise UTF-16 partout depuis très longtemps (Windows 98 je crois). Le problème est lorsqu'on mélange de vieilles partitions encodés avec des encodages différents. Il vaut mieux tout mettre en UTF-8 pour des raisons de simplicité. Python3 fait un pari sur l'avenir.
À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).
Non c'est un vrai problème (qui est en discussion sur python-devel et qui selon moi est fondamental).
$ ./python `printf '\xff'`
Could not convert argument 1 to string
tonfa@pirzuine:/tmp/Python-3.0$ PATH=`printf '\xff'`:$PATH ./python
Python 3.0 (r30:67503, Dec 6 2008, 11:42:46)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['PATH']
Traceback (most recent call last):
File "", line 1, in
File "/tmp/Python-3.0/Lib/os.py", line 389, in __getitem__
return self.data[self.keymap(key)]
KeyError: 'PATH'
On ne peut pas passer des arguments, et les variables d'environnement qui ne peuvent pas être décodées sont virées.
Dans le cas au dessus, l'unicode est mal encodé mais les mêmes problèmes arrivent si tu lance ton programme avec LANG=C. Dans ce cas les arguments unicodes ne peuvent être lus, et si une variable d'environnement contient de l'unicode elle est supprimée.
Personnellement je ne sais toujours pas comment acceder proprement à sys.argv et os.environ lorsque le contenu est arbitraire, par exemple pour que `find -print0 | xargs -0 monscript.py` marche avec des fichiers qui sont mal encodé.
[^] # Re: Reiserfs
Posté par ribwund . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 5.
[^] # Re: Snapshot ...
Posté par ribwund . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 4.
Git fait une duplication totale des fichiers. Tant qu'il n'y a pas eu de repack, chaque version de chaque fichier à sa propre copie sur le disque.
[^] # Re: Bien sûr
Posté par ribwund . En réponse au journal Un email authentifie-t-il une personne ?. Évalué à 4.
C'est "president elect" le bon terme.
Pareil itou pour le réveillon.
# RestructruredText
Posté par ribwund . En réponse au journal txt2TeX, un simple traitement de texte. Évalué à 3.
http://sphinx.pocoo.org/
Et c'est plutot standard (et très utilisé dans la communauté python). D'ailleurs une adaptation de sphinx pour faire des feuilles d'exo ca roxerait, avec un joli html et le latex...
[^] # Re: 3G ?
Posté par ribwund . En réponse à la dépêche Concours d'applications innovantes sur IPv6. Évalué à 2.
[^] # Re: Debug
Posté par ribwund . En réponse au journal voyages-sncf, tout s'explique.... Évalué à 5.
# Un example de projet
Posté par ribwund . En réponse à la dépêche Concours d'applications innovantes sur IPv6. Évalué à 4.
[^] # Re: sophisme
Posté par ribwund . En réponse au journal L'avenir de Gallium3D en question?. Évalué à 3.
# Pas tout compris le WSJ
Posté par ribwund . En réponse au journal Vers un Internet à deux vitesses ?. Évalué à 4.
http://www.boingboing.net/2008/12/15/wsj-invents-fictiona.ht(...)
[^] # Re: Boarf
Posté par ribwund . En réponse au journal Interdiction des ampoules à incandescence. Évalué à 2.
http://www.youtube.com/watch?v=pHrmvQKevfI
[^] # Re: Pour l'information comme pour le code, j'aime bien connaitre les sou
Posté par ribwund . En réponse au journal téléthon qui croyait tondre. Évalué à 7.
[^] # Re: Conversion transparente depuis et vers git ?
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
[^] # Re: Conversion transparente depuis et vers git ?
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
Je n'ai entendu que Matt dire ça, et c'était sous forme de boutade.
[^] # Re: Conversion transparente depuis et vers git ?
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
Ah si, aussi pendant le Google Summer of Code mentor summit à l'automne, il y a eu pas mal de discussions pour voir si on pourrait rapprocher le protocole réseau des deux projets.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 4.
Perso j'ai plutot entendu Matt troller pour dire que il préférait encore Ruby à python3.
A moins qu'une version majeure soit un redesign important (un futur hypothétique hg-ng), je ne pense pas que python3 sera supporté (même si des efforts sont fait pour faciliter la conversion avec 2to3.py), la compatibilité avec les anciennes versions python (2.3 à 2.6) restant prioritaire.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 1.
Par exemple, si les noms de fichiers sont en UTF-8, mais que pour une raison ou pour une autre (par exemple ton programme est lancé depuis cron), mercurial est lancé avec la locale "C", alors si on considérait les noms de fichiers comme autre chose que des bytes, alors ça planterait (on ne peut pas ouvrir certains fichiers par exemple).
Maintenant le problème pour nous en dehors de transformer tous les open/listdir/etc en version bytes (bon a priori on est déjà en binary mode à cause de windows donc les open ça doit être bon) c'est que l'API bytes n'est pas complete, par exemple au niveau de sys.argv et os.environ.
Et à mon avis il y encore d'autres problèmes qui n'ont pas été résolus par exemple je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
[^] # Re: Tout les bugs ? vraiment ?
Posté par ribwund . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 2.
À mon avis on en est très loin, les kernel hackers sont loin d'être convaincu par cette approche qui s'éloigne de la vision unix du FS (les noms de fichiers sont des bytes, seul '\0' et '/' sont interdits).
[^] # Re: Mercurial 2.0
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 2.
Disons que le passage à unicode pour la gestion des noms de fichiers ne fait pas que des heureux pour un logiciel comme mercurial.
# Les thèmes hgweb
Posté par ribwund . En réponse à la dépêche Gestion de configuration distribuée avec Mercurial. Évalué à 7.
monoblue: http://hg.xavamedia.nl/mercurial/crew/?style=monoblue
paper (nouveau thème par défaut): http://hg.xavamedia.nl/mercurial/crew/
coal: http://hg.xavamedia.nl/mercurial/crew/?style=coal
spartan (l'ancien thème par défaut, plutot moche): http://hg.xavamedia.nl/mercurial/crew/?style=spartan
gitweb: http://hg.xavamedia.nl/mercurial/crew/?style=gitweb
L'autre nouveauté c'est le graphe:
http://hg.xavamedia.nl/mercurial/crew-stable/graph/8625504f5(...)
[^] # Re: Tout les bugs ? vraiment ?
Posté par ribwund . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 4.
$ ./python `printf '\xff'`
Could not convert argument 1 to string
tonfa@pirzuine:/tmp/Python-3.0$ PATH=`printf '\xff'`:$PATH ./python
Python 3.0 (r30:67503, Dec 6 2008, 11:42:46)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['PATH']
Traceback (most recent call last):
File "", line 1, in
File "/tmp/Python-3.0/Lib/os.py", line 389, in __getitem__
return self.data[self.keymap(key)]
KeyError: 'PATH'
On ne peut pas passer des arguments, et les variables d'environnement qui ne peuvent pas être décodées sont virées.
Dans le cas au dessus, l'unicode est mal encodé mais les mêmes problèmes arrivent si tu lance ton programme avec LANG=C. Dans ce cas les arguments unicodes ne peuvent être lus, et si une variable d'environnement contient de l'unicode elle est supprimée.
# Tout les bugs ? vraiment ?
Posté par ribwund . En réponse à la dépêche Sortie de Python 3.0 version finale. Évalué à 4.