La différence entre une indexation de texte et nepomuk est qu'on lie les informations entre elles. On peut donc créer de nouvelles informations lorsqu'une requête est soumise. Exemple :
- Paris est une capitale
- Paris est en France
Si on cherche la capitale de la France, le moteur sera lier les informations pour trouver Paris.
Avec la compilation JIT, les langages interprétés doivent pouvoir etre plus rapide que leur equivalent compilé dans certains cas.
Hum, je pense que ce n'est sûrement pas vrai dans tous les cas. Je pense plutôt qu'étant donné qu'un programme Python est bien plus court (en nombre de lignes), on peut passer plus de temps à réécrire l'algorithme / faire des tests.
2- pypy est pour l'instant lancé avec cpython, donc il est forcément plus lent :)
Non, c'était justement quand PyPy était interprété par CPython qu'il était plusieurs centaines de fois plus lent. Maintenant PyPy est traduit en C puis compilé par gcc pour arriver à être "à peine" 3x plus lent que CPython. La page suivante présente les perfs selon le mode de compilation (C, LLVM, etc.) : http://tuatara.cs.uni-duesseldorf.de/benchmark.html
Le premier gros apport, c'est facilité la maintenance/evolution de python. Python est codé en C, et l'ajout de fonctionnalités/evolutions commence à devenir un petit cauchemar dans certains cas.
De par sa nature très modulaire, PyPy permet également des changements majeurs dans l'implémentation de Python. CPython utilise par exemple un ramasse miette à générations. C'est un choix, mais PyPy en permet d'autres, ce qui permet de comparer les performances et de choisir une alternative qui serait plus rapide dans un cas précis. D'ailleurs, PyPy a déjà des outils pour supprimer des malloc().
La mémoire n'était qu'un exemple, mais la gestion des processus concurrents est également remise en question : thread, greenlets, proxy d'objet fonctionnant sur réseau, clonage de générateur... PyPy apporte encore une fois un air frais dans ce domaine.
Et alors que CPython n'optimise peu ou pas, PyPy fait de l'inlining, a un annotateur de type, permet de compiler dans de nombreux langages, etc. Il offre la possibilité d'optimisations très complexes qui seraient impossibles avec CPython.
CPython ne permet pas de faire de la programmation logique et Stackless Python est moins poussé en programmation concurrente. PyPy apporte également la fonctionnalité de « clonage de générateur », outil très utile dans le calcul distribué. Et on pourrait encore trouver une longue liste de fonctionnalités qu'apporte PyPy.
Le problème des performances va peu à peu s'effacer et je pense qu'à terme PyPy sera plus rapide.
J'avais comparé Wormux 0.4 et 0.7(.0) et il était flagrant que le jeu était plus rapide, plus animé et plus fun. Mais ce commentaire laisse penser qu'il reste du boulot :-) Wormux est de plus en plus complexe. Il est difficile de régler les constantes, c'est un travail de longue haleine. Accéler le déplacement va changer le style de jeu, il faut changer pas mal de choses en conséquences (ex: durée avant l'explosion d'une dynamite).
Wormux est un jeu à part entière, n'utilise aucun graphisme de Wormux
Un jeu qui n'utilise même pas ses propres graphismes, pas mal.
Sinon pour information, Lawrence Azzoug (le fondateur du jeu Wormux) a codé Wormux car il ne pouvait pas jouer à Worms sur Linux. Effectivement, ce jeu légendaire n'est jouable que sur Windows (je parle sur ordinateur, sinon il a été porté sur un paquet de consoles de jeu). Mais depuis l'objectif a changé car on ne peut pas jouer avec les données du jeu original. Wormux a ses propres données (images, sons, terrains, etc.).
Il existe des logiciels portables, des virus portables, (téléphone portable, ordinateur portable, ...) à quand les pilotes portables ? Bien sûr, un pilote qui utiliserait au mieux chaque noyau, c'est un doux rêve, mais s'il pouvait prémacher le boulot ça serait déjà pas mal. Il faudrait pour ça des API très haut niveau pour la gestion du DMA, du temps, des interruptions, etc.
Ah on me souffle dans l'oreillette qu'en fait on en est encore à se disputer pour des questions de licence. Ok, j'ai rien dit.
J'ai en effet involontairement écrasé les 512 premiers octets d'une partition LUKS
Alors là... pas de bol. C'est un peu comme faire tomber ses clés dans une bouche à égoux. Ça me rappelle un fait divers : un mec dont la tête était coincée dans une bouche d'égoux, je ne me souviens plus s'il s'était noyé ou pas... L'accident bête qui fait gagner 10 points Darwin. http://www.darwinawards.com/
Tout ça pour dire que 32 octets de sel... faut être patient pour les retrouver, cf. "PHDR layout" dans les annexes de http://luks.endorphin.org/LUKS-on-disk-format.pdf
---
Ca serait bien de contacter les auteurs de LUKS pour leur parler de ton problème. S'il n'existe aucune copie du PHDR, il faudrait en prévoir une copie (ou plusieurs) dans la prochaine version de LUKS. Dans ton cas, c'est une erreur de manipulation, mais il arrive aussi que le disque dur déconne (secteur illisible). EXT2, par exemple, conserve un grand nombre de copie de l'entête (superblock), 13 sur un disque de 60 Go par exemple.
---
Sauvergarder ses données, c'est bien.
À noter que NTFS-3G tourne en espace utilisateur avec FUSE et qu'il a été développé en à peine... euh depuis Juillet ou Août 2006 (pas sûr de la date).
Contrairement à Linux-NTFS (qui ne tourne que sous Linux), NTFS-3G tourne sur Linux 2.4, 2.6, FreeBSD, Mac OS X et Haiku.
Attention à ce point de la FAQ : « Why is the CPU usage sometimes very high? NTFS-3G is not fully optimized yet ».
Maintenant ce que j'aimerai savoir c'est d'où sort NTFS-3G ? Il a été écrit à partir de zéro ? Autres projets NTFS pour Linux :
- http://www.linux-ntfs.org/ (pilote noyau pour Linux) <= ne supporte pas l'écriture
- http://www.jankratochvil.net/project/captive/ <= la solution très sale qui utilise un DLL (une bilbiothèque Windows !) Microsoft
- http://www.ntfs-linux.com/ <= Paragon, quelqu'un a la moindre info dessus ?
Sinon, je trouve que NTFS est un très bon système de fichier. Il utilise des B+ tree (qui ne dansent pas), supporte les "fork" (à ce que j'ai compris : genre de métadonnées stockées avec chaque fichier, comme sous Mac ou ReiserFS4), gestion des ACLs, supporte le chiffrement, nom de fichier en UTF-16 (255 caractères), limite : 2**32 fichiers, 16 TiB / fichier et 16 EiB au total, et les dates sont stockées sur 64-bit en nanoseconde (ouais !). http://fr.wikipedia.org/wiki/New_Technology_File_System
En comparaison : EXT2 utilise des chaînes binaires pour les noms de fichier (bon, ça "passe" en UTF-8) (255 octets), limites : 10**18 fichiers, 2 TiB / fichier, 16 TiB au total. Encryption : non, ACL en option, date sur 32-bit (ça va péter en 2038 alors que pour NTFS il faut attendre l'année 60056).
Je trouve aMSN très moche et peu convival, pas très il ressemble beaucoup à MSN Messenger. J'ai installé ça à ma copine et elle ne m'a plus rien demandé depuis (4 mois).
Enfin si, hier elle m'a montré une boîte de dialogue pour choisir entre deux boutons ratios... ben on sait pas lequel est coché :-/ Au pif, j'ai dit le blanc (car quand on clique ça devient blanc), et c'était ça ~~~> Au chiotte Tk !
C'est très tendant de replonger dans le troll "un fichier de 13000 ça pue des fesses", mais je vais juste corriger une erreur qui m'a fait tomber de me chaise.
La STL c'est loin d'être *un* fichier ! Pour commencer, chaque "composant" a son fichier :
$ ls /usr/include/c++/4.1.2
algorithm
deque
iostream
...
Ensuite, quand on ouvre ces fichiers, on ne trouve que d'autres includes vers des fichiers (a) "bits/(...).h" et "bits/stl_(...).h" (ex: bits/basic_string.h) et des (b) "bits/(...).tcc".
Les fichiers (a) ne contiennent que les prototypes, et bien documenté comme il faut. Fichiers courts, synthétiques, facile à lire.
Les fichiers (b) contiennent l'implémentation, le code gruiiik que seuls les gourous arrivent à lire :-)
Il y a donc 4 profondeurs de découpage :
- par composant
- include global pour simplifier la vie
- prototype
- implémentation
----
Pourquoi découper prototype et implémentation ? Ben le fichier prototype sert de documentation.
Pourquoi découper par composant ? Ben parce que les fichiers de 13.000 lignes ça pue de fesses (*plouf*, désolé).
Quelques suggestions pour l'améliorer :
- Intégrer du code à Linux suppose qu'il soit sous licence GPL ou compatible GPL non ? Est-ce le cas ?
- Lien vers les autres nouveautés de FreeBSD7
- Lien vers les autres dépêches FreeBSD récentes (?)
"Le site vit avec les dépêches que vous proposez ou que vous contribuez à rédiger."
J'ai écrit peu de dépêches et j'ai gagné par deux fois deux livres (4 au total donc). C'est un investissement rentable ;-)
En lisant les questions, j'en comprend une peur injustifiée. Il existe déjà pour chaque distribution une équipe de sécurité qui surveille de près les annonces de faille et corrigent les distributions au plus vite. Page d'information sur quelques distributions :
Ce que j'en ai compris de la sécurité dans les distributions Linux/BSD :
- Chaque distribution choisit une version d'un logiciel lors de la publication d'une nouvelle version de la distribution
- Les failles sont publiées sur des sites tels que le Common Vulnerabilities and Exposure de mitre.org, exemple : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6101
- Un choix est fait entre prend la nouvelle version en upstream ou alors isoler le bug et faire un patch.
Debian étant très conservateur, ils écrivent des patchs. Ubuntu fait pareil.
Pour information, le choix d'une version de logiciel pour une distrbution s'explique par les faits des incompatibilités. Lorsqu'on change la version du noyau Linux par exemple, il faut vérifier que tous les modules soient toujours disponible et que tous les outils proches du noyaux soient compatibles (FUSE, udev, hotplus & co).
J'en ai fait l'expérience : passer du noyau 2.6.17 à 2.6.19 sur Ubuntu m'a changé le nom de mon disque dur (/dev/sda* => /dev/hda*). C'est pas négligeable comme modification, Grub m'a refusé de booter... (bon pour info, Ubuntu utilise désormais des UUID pour identifier les disques dur, ce qui évite ce genre de problème mais j'ai fait mon boulet)
Je connais très peu ces projets, mais je dirai qu'ils ne partagent pas/peu de code. C'est bien dommage car il serait facile de séparer chaque projet en composant et surtout de réutiliser les composants. On peut imaginer une programme d'extraction de métadonnée en Python ou .NET, un serveur d'indexaction en C, un serveur pour les requêtes en Ruby, etc.
Ceci éviterait d'avoir des projets "bon en support de fichier", "lent en indexation", "moyen en consommation de CPU" :-/
Moi je verrai même ça comme un système multi-agents. Pour que le tout fonctionne ensemble, il faut juste qu'ils parlent la même langue (encodage des informations). Par contre, l'implémentation (langage, architecture, agent local/distribué, ...) en s'en fout.
« je charge un autre module python, qui en charge un autre etc et dans le paquet y'en a un qui se dit "et si je faisais un setlocale pour bien causer la langue de l'autochtone?" . Et il le fait ce con. »
Seul le programme principal doit changer de locale car :
- c'est pas thread safe
- vaut mieux ne changer qu'une seule fois de locale (à cause de trucs vaudou, cherchez pas)
- un module n'a pas à imposer sa locale
Corrige le module en question pour éviter une 3e guerre mondiale.
Il manquait le fichier hachoir_subfile_regex.py. Ce fichier est encore tout frais. hachoir-subfile génère maintenant une expression régulière pour accélérer la recherche du début des fichiers.
[^] # Re: Jusqu'ou ira-t-on ?
Posté par Victor STINNER (site web personnel) . En réponse au journal nepomuk. Évalué à 5.
- Paris est une capitale
- Paris est en France
Si on cherche la capitale de la France, le moteur sera lier les informations pour trouver Paris.
Le langage de requête est http://fr.wikipedia.org/wiki/SPARQL ; et le format de stockage : RDF (ou http://fr.wikipedia.org/wiki/RDF_Schema ?).
# Fallait aller à FOSDEM
Posté par Victor STINNER (site web personnel) . En réponse au journal nepomuk. Évalué à 3.
http://www.fosdem.org/2007/schedule/events/kde_semantic
Je pense que les documents seront bientôt (ou le sont déjà) en ligne.
[^] # Re: Impossible?
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche PyPy, le serpent qui se mord la queue, sort en version 0.99. Évalué à 1.
Hum, je pense que ce n'est sûrement pas vrai dans tous les cas. Je pense plutôt qu'étant donné qu'un programme Python est bien plus court (en nombre de lignes), on peut passer plus de temps à réécrire l'algorithme / faire des tests.
[^] # Re: Lent ...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche PyPy, le serpent qui se mord la queue, sort en version 0.99. Évalué à 3.
Non, c'était justement quand PyPy était interprété par CPython qu'il était plusieurs centaines de fois plus lent. Maintenant PyPy est traduit en C puis compilé par gcc pour arriver à être "à peine" 3x plus lent que CPython. La page suivante présente les perfs selon le mode de compilation (C, LLVM, etc.) :
http://tuatara.cs.uni-duesseldorf.de/benchmark.html
PyPy .NET est 70x plus lent que CPython :-p
[^] # Re: un très bon exemple
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche PyPy, le serpent qui se mord la queue, sort en version 0.99. Évalué à 5.
De par sa nature très modulaire, PyPy permet également des changements majeurs dans l'implémentation de Python. CPython utilise par exemple un ramasse miette à générations. C'est un choix, mais PyPy en permet d'autres, ce qui permet de comparer les performances et de choisir une alternative qui serait plus rapide dans un cas précis. D'ailleurs, PyPy a déjà des outils pour supprimer des malloc().
La mémoire n'était qu'un exemple, mais la gestion des processus concurrents est également remise en question : thread, greenlets, proxy d'objet fonctionnant sur réseau, clonage de générateur... PyPy apporte encore une fois un air frais dans ce domaine.
Et alors que CPython n'optimise peu ou pas, PyPy fait de l'inlining, a un annotateur de type, permet de compiler dans de nombreux langages, etc. Il offre la possibilité d'optimisations très complexes qui seraient impossibles avec CPython.
[^] # Re: Lent ...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche PyPy, le serpent qui se mord la queue, sort en version 0.99. Évalué à 2.
Le problème des performances va peu à peu s'effacer et je pense qu'à terme PyPy sera plus rapide.
[^] # Re: La critique est facile
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Version 0.7.9 de Wormux. Évalué à 4.
[^] # Re: Version Windows
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Version 0.7.9 de Wormux. Évalué à 2.
Un jeu qui n'utilise même pas ses propres graphismes, pas mal.
Sinon pour information, Lawrence Azzoug (le fondateur du jeu Wormux) a codé Wormux car il ne pouvait pas jouer à Worms sur Linux. Effectivement, ce jeu légendaire n'est jouable que sur Windows (je parle sur ordinateur, sinon il a été porté sur un paquet de consoles de jeu). Mais depuis l'objectif a changé car on ne peut pas jouer avec les données du jeu original. Wormux a ses propres données (images, sons, terrains, etc.).
# Rêvez un peu
Posté par Victor STINNER (site web personnel) . En réponse au journal FreeBSD manque de driver ? pas grave, on prend ceux de linux. Évalué à 5.
Ah on me souffle dans l'oreillette qu'en fait on en est encore à se disputer pour des questions de licence. Ok, j'ai rien dit.
# Pas de chatte
Posté par Victor STINNER (site web personnel) . En réponse au journal LUKS et forensics. Évalué à 4.
Alors là... pas de bol. C'est un peu comme faire tomber ses clés dans une bouche à égoux. Ça me rappelle un fait divers : un mec dont la tête était coincée dans une bouche d'égoux, je ne me souviens plus s'il s'était noyé ou pas... L'accident bête qui fait gagner 10 points Darwin.
http://www.darwinawards.com/
Tout ça pour dire que 32 octets de sel... faut être patient pour les retrouver, cf. "PHDR layout" dans les annexes de http://luks.endorphin.org/LUKS-on-disk-format.pdf
---
Ca serait bien de contacter les auteurs de LUKS pour leur parler de ton problème. S'il n'existe aucune copie du PHDR, il faudrait en prévoir une copie (ou plusieurs) dans la prochaine version de LUKS. Dans ton cas, c'est une erreur de manipulation, mais il arrive aussi que le disque dur déconne (secteur illisible). EXT2, par exemple, conserve un grand nombre de copie de l'entête (superblock), 13 sur un disque de 60 Go par exemple.
---
Sauvergarder ses données, c'est bien.
# Complément d'information
Posté par Victor STINNER (site web personnel) . En réponse au journal NTFS-3G en RC1. Évalué à 8.
Contrairement à Linux-NTFS (qui ne tourne que sous Linux), NTFS-3G tourne sur Linux 2.4, 2.6, FreeBSD, Mac OS X et Haiku.
Attention à ce point de la FAQ : « Why is the CPU usage sometimes very high? NTFS-3G is not fully optimized yet ».
Maintenant ce que j'aimerai savoir c'est d'où sort NTFS-3G ? Il a été écrit à partir de zéro ? Autres projets NTFS pour Linux :
- http://www.linux-ntfs.org/ (pilote noyau pour Linux) <= ne supporte pas l'écriture
- http://www.jankratochvil.net/project/captive/ <= la solution très sale qui utilise un DLL (une bilbiothèque Windows !) Microsoft
- http://www.ntfs-linux.com/ <= Paragon, quelqu'un a la moindre info dessus ?
Sinon, je trouve que NTFS est un très bon système de fichier. Il utilise des B+ tree (qui ne dansent pas), supporte les "fork" (à ce que j'ai compris : genre de métadonnées stockées avec chaque fichier, comme sous Mac ou ReiserFS4), gestion des ACLs, supporte le chiffrement, nom de fichier en UTF-16 (255 caractères), limite : 2**32 fichiers, 16 TiB / fichier et 16 EiB au total, et les dates sont stockées sur 64-bit en nanoseconde (ouais !).
http://fr.wikipedia.org/wiki/New_Technology_File_System
En comparaison : EXT2 utilise des chaînes binaires pour les noms de fichier (bon, ça "passe" en UTF-8) (255 octets), limites : 10**18 fichiers, 2 TiB / fichier, 16 TiB au total. Encryption : non, ACL en option, date sur 32-bit (ça va péter en 2038 alors que pour NTFS il faut attendre l'année 60056).
Je crois bien qu'EXT4 veut étendre les limites de taille (par fichier / totale), mais je crains qu'ils n'autorisent toujours pas plus de 255 octets/nom de fichier et des dates sur 32-bit :-(
http://www.haypocalc.com/blog/index.php/2006/06/14/5-quelle-(...)
# aMsn
Posté par Victor STINNER (site web personnel) . En réponse au journal les IM et la population non-geek.... Évalué à 3.
Enfin si, hier elle m'a montré une boîte de dialogue pour choisir entre deux boutons ratios... ben on sait pas lequel est coché :-/ Au pif, j'ai dit le blanc (car quand on clique ça devient blanc), et c'était ça ~~~> Au chiotte Tk !
[^] # Re: Une vraie bibliothèque.....
Posté par Victor STINNER (site web personnel) . En réponse au journal GREYCstoration : Appel à contribution. Évalué à 1.
La STL c'est loin d'être *un* fichier ! Pour commencer, chaque "composant" a son fichier :
Ensuite, quand on ouvre ces fichiers, on ne trouve que d'autres includes vers des fichiers (a) "bits/(...).h" et "bits/stl_(...).h" (ex: bits/basic_string.h) et des (b) "bits/(...).tcc".
Les fichiers (a) ne contiennent que les prototypes, et bien documenté comme il faut. Fichiers courts, synthétiques, facile à lire.
Les fichiers (b) contiennent l'implémentation, le code gruiiik que seuls les gourous arrivent à lire :-)
Il y a donc 4 profondeurs de découpage :
- par composant
- include global pour simplifier la vie
- prototype
- implémentation
----
Pourquoi découper prototype et implémentation ? Ben le fichier prototype sert de documentation.
Pourquoi découper par composant ? Ben parce que les fichiers de 13.000 lignes ça pue de fesses (*plouf*, désolé).
Victor
# Ce texte mérite d'être proposée comme dépêche
Posté par Victor STINNER (site web personnel) . En réponse au journal ZFS porté sur FreeBSD 7. Évalué à 3.
- Intégrer du code à Linux suppose qu'il soit sous licence GPL ou compatible GPL non ? Est-ce le cas ?
- Lien vers les autres nouveautés de FreeBSD7
- Lien vers les autres dépêches FreeBSD récentes (?)
"Le site vit avec les dépêches que vous proposez ou que vous contribuez à rédiger."
J'ai écrit peu de dépêches et j'ai gagné par deux fois deux livres (4 au total donc). C'est un investissement rentable ;-)
# C'est déjà le cas !?
Posté par Victor STINNER (site web personnel) . En réponse au journal Une simple idée sur la sécurité. Évalué à 5.
http://www.debian.org/security/
http://www.gentoo.org/security/en/index.xml
http://www.slackware.com/security/
http://www.openbsd.org/security.html
Ce que j'en ai compris de la sécurité dans les distributions Linux/BSD :
- Chaque distribution choisit une version d'un logiciel lors de la publication d'une nouvelle version de la distribution
- Les failles sont publiées sur des sites tels que le Common Vulnerabilities and Exposure de mitre.org, exemple :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6101
- Un choix est fait entre prend la nouvelle version en upstream ou alors isoler le bug et faire un patch.
Debian étant très conservateur, ils écrivent des patchs. Ubuntu fait pareil.
Pour information, le choix d'une version de logiciel pour une distrbution s'explique par les faits des incompatibilités. Lorsqu'on change la version du noyau Linux par exemple, il faut vérifier que tous les modules soient toujours disponible et que tous les outils proches du noyaux soient compatibles (FUSE, udev, hotplus & co).
J'en ai fait l'expérience : passer du noyau 2.6.17 à 2.6.19 sur Ubuntu m'a changé le nom de mon disque dur (/dev/sda* => /dev/hda*). C'est pas négligeable comme modification, Grub m'a refusé de booter... (bon pour info, Ubuntu utilise désormais des UUID pour identifier les disques dur, ce qui évite ce genre de problème mais j'ai fait mon boulet)
Haypo
[^] # Re: Jolies images
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Sunflow 0.07.1. Évalué à 3.
http://hof.povray.org/mouille.html
Je sais pas combien d'heures il a passé juste pour cette image, mais ça doit être énorme :-p
Son site web :
http://www.oyonale.com/
Morceaux choisis :
http://www.oyonale.com/ldc/francais/souris.htm
http://www.oyonale.com/ldc/francais/grandrue_ouest.htm
http://www.oyonale.com/ldc/francais/champs.htm
http://www.oyonale.com/ldc/francais/citadelle.htm
http://www.oyonale.com/ldc/francais/prisonniers.htm
http://www.oyonale.com/ldc/francais/recolte.htm
http://www.oyonale.com/ldc/francais/lilith.htm
http://www.oyonale.com/ldc/francais/pingouin.htm (spécial linux ;-))
Victor
# Jolies images
Posté par Victor STINNER (site web personnel) . En réponse au journal Sortie de Sunflow 0.07.1. Évalué à 2.
http://sunflow.sourceforge.net/gallery/v0064/pool.png
http://sunflow.sourceforge.net/gallery/v0055/bronzefigure.pn(...)
http://sunflow.sourceforge.net/gallery/v0053/diablo.png
[^] # Re: Hachoir
Posté par Victor STINNER (site web personnel) . En réponse au message Editer un fichier binaire à l'aide de templates. Évalué à 2.
http://hachoir.org/wiki/Install/snapshot
(pas besoin d'installation : on décompresse et ça fonctionne)
Ou alors attend un peu, un gros travail sur les paquets Debian sont en cours (c'est pour ça que je viens de sortir 4 versions stables :-)).
# Résumé perso de la discussion
Posté par Victor STINNER (site web personnel) . En réponse au journal Bonnes pratique pour le développement. Évalué à 2.
Haypo
# Pourquoi en faire des concurrents ?
Posté par Victor STINNER (site web personnel) . En réponse au journal Etatde l'art des outils de recherches pour le bureau. Évalué à 6.
Ceci éviterait d'avoir des projets "bon en support de fichier", "lent en indexation", "moyen en consommation de CPU" :-/
Moi je verrai même ça comme un système multi-agents. Pour que le tout fonctionne ensemble, il faut juste qu'ils parlent la même langue (encodage des informations). Par contre, l'implémentation (langage, architecture, agent local/distribué, ...) en s'en fout.
Haypo
[^] # Re: mon fichier
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-subfile : extrait les fichiers contenu dans un autre fichier. Évalué à 2.
Qu'aucun fichier connu valide n'a été trouvé.
Si c'est le cas pourquoi et comment y remédier ?
Me dire où il est et comment le reconnaître que je puisse patcher.
J'ai regardé vite fait, et je ne vois effectivement aucun format connu. Par contre, je dirai que le fichier est fortement compressé...
Haypo
[^] # Re: rapports de bugs
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-subfile : extrait les fichiers contenu dans un autre fichier. Évalué à 3.
[^] # Re: rapports de bugs
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-subfile : extrait les fichiers contenu dans un autre fichier. Évalué à 2.
# T'embales pas
Posté par Victor STINNER (site web personnel) . En réponse au journal Pourquoi je hais les locales. Évalué à 8.
Seul le programme principal doit changer de locale car :
- c'est pas thread safe
- vaut mieux ne changer qu'une seule fois de locale (à cause de trucs vaudou, cherchez pas)
- un module n'a pas à imposer sa locale
Corrige le module en question pour éviter une 3e guerre mondiale.
[^] # Re: Très bonne initiative.
Posté par Victor STINNER (site web personnel) . En réponse au journal hachoir-subfile : extrait les fichiers contenu dans un autre fichier. Évalué à 4.
http://www.digitalforensicssolutions.com/Scalpel/
Effectivement, il vaut mieux travailler sur une image du disque car plus on lit un disque malade, moins en va en tirer de bonnes choses.
Bien sûr, rien ne vaut une bonne sauvegarde :-)
---
Je viens de regénérer le snapshot du jour : http://hachoir.tuxfamily.org/snapshot/hachoir-snapshot-2007-(...)
Il manquait le fichier hachoir_subfile_regex.py. Ce fichier est encore tout frais. hachoir-subfile génère maintenant une expression régulière pour accélérer la recherche du début des fichiers.