Quelques informations trouvées ça et là sur Internet à propos de ReiserFS4 :
- l'auteur principal de ReiserFS4 est en prison, je suppose que la société (dont le business reposait sur ReiserFS??) qui lui appartient n'est pas au meilleur de sa forme
- ReiserFS4 utilise une structure de données appelée « dancing trees » (arbres dansants) qui sont un genre de B-Tree avec des optimisations pour un système de fichier. Cette structure de donnée rend la restauration d'un système malade délicate. D'ailleurs, je crois qu'il y a peu/pas d'outil de restauration pour ReiserFS4.
- La majorité ou l'ensemble des nouveautés de ReiserFS4 sont maintenant reprises dans les nouveaux systèmes de fichier comme HAMMER, btrfs, tux, etc. Du coup, ReiserFS4 n'est plus aussi intéressant qu'à ses débuts.
- Côté performance, reiserfs4 n'est pas/plus le meilleur.
- Le système de greffon est complexe et ne sera jamais intégré dans le noyau Linux car les développeurs noyau veulent conserver un petit noyau qui ne fait que le strict minimum (voir l'exemple dans la dépêche de patrick avec le décodage vidéo des webcams déplace du noyau vers l'espace utilisateur avant l'inclusion d'un gros patch)

ReiserFS4 n'a jamais été inclu dans le noyau car son auteur, Hans Reiser, n'accepte pas les critiques, n'a jamais voulu faire de concession (ex: abandon du système de greffon) et avait plutôt tendance à fâcher les développeurs noyaux, ce qui n'est pas une bonne idée. On préfère donc un système un peu plus lent et moins innovant qu'un système avec un technologie récente et mal maitrisée (bugs d'implémentations).

Rappel : un système de fichier doit être parfait. On peut tolérer des bugs graphiques (suffit de relancer X), mais pas de bugs dans un FS (un fichier perdu est vraiment perdu).

Apparament, ReiserFS4 a provoqué plus de bruits (trolls) que n'a fait avancé la recherche sur les systèmes de fichier...

[ Répondre ]

Pour finir l'expérience a montré que le confinement des défaillances qu'on pensait être une des killer feature des micro-noyau n'est pas si effectif que cela (le système peut tout de même s'effondrer par effet domino dans de nombreux cas)

De quoi tu parles ? Les publications de Tanenbaum sur MINIX3 sont très positives. J'avais lu un papier qui montrait qu'on pouvait tuer les pilotes de la carte réseau toutes les 5 secondes tout en téléchargeant un image ISO : le téléchargement se fait sans aucun problème (wget). Papier qui explique un peu mieux les problèmes résolus par l'isolation des pilotes dans des processus indépendants :
http://www.cs.vu.nl/~jnherder/ir-cs-018.pdf

Aucun système n'est parfait, mais j'ai quand même tendance à penser que la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.

[ Répondre ]

Quand j'écris une dépêche je lis toujours attentivement les commentaires pour y réagir. J'ai passé toute une nuit à écrire cette dépêche. Alors quand je vois vieux troll (Microsoft, ISO, ECMA, FUD, etc.) totalement dénué d'intérêt (c'est du déjà vu, revu et rerevu), je trouve ça vraiment minable.

C'est une excellente chose qu'il existe différentes implémentations de Python. Si Microsoft (IronPython) ou Sun (Jython) sponsporise la sienne pour que Python s'intègre mieux à leurs environnement (resp. .NET et Java), je trouve ça bien. D'une manière ou d'une autre, ils contribuent à Python (ex: ça permet à plus de gens d'utiliser Python). Si la licence ne vous plait pas, passez-vous en ou recodez votre implémentation. Pour IronPython, je suppose que ça fonctionne sur Mono. Si ce n'est pas le cas, patchez Mono plutôt que de nous faire perdre du temps.

[ Répondre ]

Avec Metacity : (...)

C'est pourri Metacity, l'image est tout floue ! Ou alors c'est peut-être ton écran qui est sale ?

[ Répondre ]

— Hurd joue déjà la Free Software Song chaque fois qu'un translator est relancé (après un plantage).
— Il bluffe.
— Meuh, non.
— Moi j'dis qu'il bluffe.
— Ah merde, y'a pas de pilote pour les cartes sons sous Hurd /o\
— Si si, c'est prévu, dès qu'on a fini de changer le micro-noyau et de réimplementer la gestion mémoire en dehors du noyau.

[ Répondre ]

Je pense qu'il a un problème avec DOS. T'as essayé chkdsk ?

[ Répondre ]

À mon avis il faudrait unifier Windows et Linux.

Si tu veux polémiquer sur Python3, utilise plutôt la liste python-3000 et relit les long threads récent sur les noms de fichier unicode ou pas.

[ Répondre ]

Je pense quand même que le coup des bytes n'est pas forcement une amélioration

Python2 et la grand majorité des langages de programmations n'utilisent que des octets, même s'ils nous mentent en utilisant des noms comme « char » (character) en C ou « str » (string) en Python. Bien qu'en Python2, on peut travailler en unicode, mais il faut le faire explicitement en utilisant le préfixe « u » (u'unicode').

En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup.

Un outil de backup utilisera le type bytes sous Linux, et unicode (str) sous Windows. Les outils de backup représente qu'un faible pourcentage des applications. Les autres utiliseront unicode à tous les étages, ce qui simplifie énormément de choses (évite les horribles problèmes de mélange de charset).

sauf si on décide que tout le monde utilise UTF-8 en locale

C'est quand même de plus en plus le cas : UTF-8 est la locale par défaut sous Debian, Ubuntu, Mac OS X, etc.

Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?

[ Répondre ]

Je suis en partie à l'origine de ce merdier :-) J'ai écrit le document suivant pour faire l'état de Python3 :
http://wiki.python.org/moin/Python3UnicodeDecodeError

En gros :
- Sous Windows n'utilisez que des chaînes Unicode
- Sous Linux et BSD (Mac OS X est un BSD) utilisez de l'Unicode si vous êtes fainéants (et vous avez raison ! « Sois fainéant, sois fainéant, tu vivras longtemps ! » chantait Coluche). Si vous voulez vraiment gérer les cas de merde (fichiers encodés n'importe comment, machine mal configurée), utilisez le type bytes (et des fonctions comme os.getcwdb()).

Pour info, svn refuse les fichiers dont le nom est encodé n'importe comment :
$ svn stat
(rien)
$ touch $(echo -e "oups\xff")
$ svn stat
(hex: 6f 75 70 73)
suivies par une séquence UTF-8 invalide
(hex: ff)

J'ai écrit un patch pour Python3 qui a été appliqué hier qui permet d'utiliser des noms de fichier sous forme de chaînes d'octets.

Finalement, Python3 simplifie le bordel car il passe TOUT en unicode (par défaut). Ce n'est que si vous voulez absolument gérer les cas de merde, que -comme dans tout langage- vous allez avoir des soucis en mélangeant octets et caractères.

http://www.paroles.net/chanson/22017.1

[ Répondre ]

IronPython n'utilise pas de GIL ? Si c'est vrai, c'est une excellente nouvelle. PyPy utilise encore le GIL. On voit là l'intérêt d'avoir plusieurs implémentations différentes de Python, chacune a ses qualités et ses défauts : CPython, IronPython, Jython, PyPy, etc. (tiens, et Python pour Parrot ça en est où ?)

[ Répondre ]

Tu peux consulter la documentation en local en l'installant chez toi. Exemple pour Debian / Ubuntu : « apt-get install python2.5-doc ». Oui, il y a eu un petit clash pour la màj de la doc sur python.org. C'est corrigé maintenant.

[ Répondre ]

Pour les alternatives aux threads, je te conseille de regarder du projet PyPy. Il a déjà intégré une partie de (ou tout ?) Stackless Python.

[ Répondre ]

Il existe un greffon greystoration pour GIMP. Pour la déformation, tu parles de la géométrie ? Pour les yeux rouges, il doit exister des greffons externes. Une des forces de GIMP réside aussi dans son extensibilité avec les extensions écrites en C, Perl, Python, etc.

[ Répondre ]

J'avais lu qq. part que GEGL permettra les effets de calque. Le truc que j'aime le plus dans GEGL est la possibilité de travailler sur une image en basse résolution, puis de faire un rendu sur l'image en taille réelle. D'ailleurs, GEGL supporte les images d'une taille supérieure à la mémoire de la machine ;-)

[ Répondre ]

Pour info, Harald Welte a également travaillé pour Open Moko. Il est maintenant passé chez VIA :
http://laforge.gnumonks.org/weblog/linux/openmoko/index.html

C'est l'ancien mainteneur de Netfilter (parefeu Linux). J'ai cru comprendre qu'il bossait sur le réseau dans OpenMoko.

[ Répondre ]

J'avais peur en voyant le paté en première partie, puis l'énorme paté en deuxième partie. Finalement, ça se lit très bien, ce n'est pas technique et orienté fonctionnalités. On voit bien que les trolls « Gtk3 va tout casser » ou « Gnome c'est nul, regardez un peu la qualité de KDE » motivent les développeurs Gtk+/Gnome à prouver que Gnome est toujours là ! Tant qu'il y a des commits, il y a de la vie. Et alimentez les trolls pour motiver les développeurs !

J'ai longtemps utilisé Gnome, puis j'ai donné sa chance à KDE. J'ai migré mes deux postes à KDE. Ensuite, j'ai réessayé Gnome car Ubuntu est mieux fini dans sa saveur Gnome. Finalement, je suis revenu à KDE partout, je trouve Gnome trop limité. Exemple : on peut pas redimensionner une fenêtre avec ALT+clic droit+déplacement de la souris. Autre exemple : Nautilus n'affiche pas le débit lors d'une copie de fichier (soit-disant c'est inutile, seul l'estimation du temps restant est suffisante). Peut-être que KDE aime les geeks alors que Gnome les renie.

[ Répondre ]

Autre conseil pour tester un logiciel : utiliser ./configure --prefix=/opt/logiciel. Comme ça, un rm -rf /opt/logiciel suffira pour le renvoyer d'où il vient. Ça marche sur la grande majorité des logiciels. Parfois, il faut jouer avec PATH, PYTHONPATH ou LD_LIBRARY_PATH pour que ça passe.

[ Répondre ]

« il est possible de résoudre le problème en updatant ou en reflashant le BIOS de votre carte mère. » dit le blog Mandriva.

Et n'oubliez pas votre serviette !

[ Répondre ]

Tu peux retrouver ce que tu as installé avec « history|apt-get install » ou « dpkg -l|grep 'lib.*-dev' » puis supprimer la pollution (tu devrais pouvoir supprimer tous les -dev sans risque). C'est aussi ça l'intérêt de Debian : installation simple, mais aussi désinstallation simplissime !

Au passage, pour ceux qui ne connaissez pas : « apt-get build-dep awesome ». C'est super utile pour recompiler un paquet Debian, ou même pour compiler une version plus récente à partir d'un tarball.

[ Répondre ]

http://www.rockbox.org/twiki/bin/view/Main/SoundCodecs

En bref : MP3, Ogg/Vorbis, AAC et WMA gérés à merveille, mais en plus ça gère des formats moins populaires tels que FLAC, Speex, MOD, MIDI, etc. C'est quoi cette histoire de format NES 8 bits par contre ? C'est pour réécouter le musique de Tetris ?

[ Répondre ]