Victor STINNER a écrit 1632 commentaires

Mouais, rien de bien intéressant. La bonne URL c'est http://web.archive.org/ qui archive tout Internet depuis plusieurs années. Pour linuxfr, c'est donc :
http://web.archive.org/web/*/http://linuxfr.org

Les archives linuxfr débutent en 1999 avec plusieurs versions pour chaque année. Ce site est vraiment génial et j'espère qu'il reste toujours librement disponible. J'espère aussi qu'ils ont des sauvegardes /o\ Ils ont plusieurs giga-octets de données. En fait, c'est plutôt des péta-octets chez eux.
http://fr.wikipedia.org/wiki/Internet_Archive

Attention à ne pas se tromper de débat : un micro noyau ne corrige pas les bugs. Un micro noyau permet d'isoler les bugs et offre la possibilité de relancer une pilote en cas de problème. Après, tout dépend de la panne, de la criticité du pilote, etc.

Tu sembles faire une fixation sur la pilote « qui gère toutes données ». Il me semble qu'un bug dans un pilote de la carte son ou même de ta souris va figer toute la machine, aussi bien sous Linux que sous Windows. Si la machine est figée, tu perds aussi « toutes tes données ».

/me retourne fuzzer sa souris USB avec Python 3000

En pratique, il n'y a aucune info pour l'instant...

Pour Qt 4.5, relire les journaux précédents en attendant :
http://linuxfr.org/~tanguy_k/27239.html
http://linuxfr.org/~tanguy_k/27173.html

Ce n'est pas le bon endroit pour poser une question OpenOffice. Va au moins sur le forum linuxfr, ou plutôt un forum dédié à OpenOffice.

Quand ton pilote FS s'est craché, redemarrage (de la machine) ou pas, je ne ferais pas trop confiance quant à la cohérence de ce qui reste sur ton disque dur...

Dans un micro noyau, il est possible de redémarrer un pilote qui gère un système de fichier. Bien sûr, il est possible de détecter si le pilote est redémarré parce qu'il a craché. Dans ce cas, le pilote peut décider de faire les opérations appropriées comme lancer fsck.

Avec Linux, il n'est pas possible de faire ça : si un pilote plante, on ne peut rien faire et souvent on perd le contrôle de la machine. Bien que j'ai l'impression que Linux est capable d'attraper les erreurs et afficher un joli backtrace dans les logs du noyau, donc il pourrait très bien faire certaines opérations en cas de bug (ex: tuer le pilote, le relancer, etc.).

J'ai patché Python3 pour pouvoir gérer des noms de fichier sous forme de chaîne de caractères. Il suffit d'utiliser le type bytes (ex: b'pouet' au lieu de 'pouet') et les bonnes fonctions (ex: os.getcwdb() au lieu de os.getcwd()).

Mon père m'a donné sur téléphone SPV C500. C'est du Windows CE qui prend environ 3 min (à vue d'œil) à booter. Et même quand le fond d'écran et les menus sont affichés, tout n'est pas encore chargé :-p Bien sûr, une petite animation rendra le temps d'attente moins long ;-)

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...

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.

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.

Avec Metacity : (...)

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

— 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.

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

À 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.

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 ?

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

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ù ?)

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.

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.

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.

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 ;-)

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.

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.

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.

« 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 !