Victor STINNER a écrit 1639 commentaires

Question sécurité, ils devraient essayer le modèle boîte noire qui a déjà fait ses preuves ! En plus, c'est une couleur dans l'air du temps.

Au sujet de VeriSign, pour ceux qui ne connaissent pas l'affaire : VeriSign qui gère (gérait ?) le serveur DNS de l'extension ".com" renvoyait vers leu site web (truc publicitaire) plutôt que de répondre "domaine inexistant". http://fr.wikipedia.org/wiki/VeriSign

Haiku supporte les dernières cartes Wifi, l'accélération 3D NVidia/ATI ou encore les webcams Philips ?

C'est normal qu'il n'y ait pas de dépêche si personne n'en a proposé une !? Propose une dépêche en enlevant le paragraphe de troll et en détaillant un peu plus les fonctions de SciLab. Est-ce qu'on peut faire des graphiques ? Y'a un outil de simulation ? J'en sais rien, si pour toi ça parait évident, ça l'est pas pour quelqu'un qui ne connait pas SciLab. Et quid est des nouveautés de la version 5 ?

C'est un logiciel aidant pour réaliser des mesures physiques, en particulier calculer les trajectoires (ex: une balle qui tombe). On voit la vidéo image par image et on place des points. Un étalonement est nécessaire pour conserver l'échelle.

--

J'ai noté un bug très gênant : on peut pas placer deux points trop proches (moins d'un cm sur mon écran, genre 10 à 40 pixels). Or c'est nécessaire sur une vidéo comme "principe d'inertie.avi".

On ne peut pas corriger un point mal placé : il faut tout recommencer :-/

Parfois j'ai une aide qui zoome sur le curseur, des fois non.

Ah j'ai compris : il faut rester appuyé sur le clic pour avoir le zoom. J'aurai préféré l'avoir toujours. Par contre, ça marche jamais le nouveau point est trop proche de l'autre : il faut cliquer loin, resté appuyé et déplacé le curseur.

Je pense que ce programme rendra les cours au lycée plus attrayant :-) Surtout si l'élève fait la capture vidéo lui-même ;-)

Copier les données dans le presse papier n'est pas très utile. Il voudrait mieux ne conserver que l'export en CSV.

Ah quand l'intégration de gnuplot ou calcul automatique de la trajectoire (càd que l'élève n'a plus rien à faire, yahoo !).

$ python ./__init__.py
...
File "/home/haypo/pymecavideo-2.1-alpha/__init__.py", line 62, in __init__
self._dir()
File "/home/haypo/pymecavideo-2.1-alpha/__init__.py", line 264, in _dir
copy_commands='cp -R '+pymecavideo_rep_install+'/icones/* '+pymecavideo_rep_icones
NameError: global name 'pymecavideo_rep_install' is not defined
Erreur de segmentation (core dumped)

Oups, du Python qui plante :-) En relaçant le script, ça se lance.

Si tu lis l'email « Re: glibc-2.8 tarballs? » :
http://sourceware.org/ml/libc-alpha/2008-05/msg00074.html

Tu verras que l'expéditeur est Ulrich Drepper. Il est connu pour ses... sautes d'humeur.

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.