guppy a écrit 345 commentaires

Parce que l’œil est sensible aux formes. Chaque image sera une bouilli grisâtre, identique à toutes les images de bouillis grisâtre.

Je viens d'essayer ça rapidement, effectivement c'est pas terrible.

Le premier c'est "linuxfr.org" (un o latin), le second c'est "linuxfr.org" (un o grec, copié collé depuis le commentaire de Thomas DEBESSE).

Le script pour ceux que ça intéresse :

#!/bin/bash

function to_bin()
{
        declare -A tab=([0]="0 0 0 0" [1]="0 0 0 1" [2]="0 0 1 0" [3]="0 0 1 1" [4]="0 1 0 0" [5]="0 1 0 1" [6]="0 1 1 0" [7]="0 1 1 1" [8]="1 0 0 0" [9]="1 0 0 1" [A]="1 0 1 0" [B]="1 0 1 1" [C]="1 1 0 0" [D]="1 1 0 1" [E]="1 1 1 0" [F$

        echo ${tab[$1]}
}

echo "P1"
echo "32 16"

for line in $(echo "linuxfr.οrg" | sha512sum | cut -d\  -f1 | fold -w 8 | tr '[:lower:]' '[:upper:]')
do
        for char in $(echo $line | fold -w 1)
        do
                printf "$(to_bin $char) "
        done
        printf "\n"
done

Ca s'utilise comme ça :

./monohash > test2.pbm
convert test2.pbm test2.png

Mes excuses, j'avais effectivement pas lu le readme. Ceci dit ce que tu viens de rajouter aurait eu sa place dans le journal nan ? ;)

Peux-tu expliciter les 3 hashs ? Le premier ok, j'imagine que tu fabriques les autres à partir du premier ?

Admettons que tu obtiennes un hash correct de 22 nombres. Tu les transformes ensuite en une seule image, mais y a-t-il quelque chose qui te fait dire qu'on ne peut pas faire facilement de collisions graphiques approximatives à part tes tests ? Je suis pas spécialiste du domaine, mais ça me parait identique en terme de risque à faire sa fonction de hashage perso. Enfin je suis peut-être à côté de la plaque et te vexe pas, c'est que des questions ;)

Par contre, ça me donne une idée avec un résultat moins joli mais peut-être moins risqué. Tes 3 hash t'amènent 512 x 3 = 1536 bits. Pourquoi ne pas tout simplement s'en servir pour créer une image monochrome de 48 x 32 pixels par exemple ?

Je pense pour ma part que le point que tu soulèves est le vrai problème. Pour faire de la cryptographie on ne doit pas penser on doit savoir.

Sinon ce n'est qu'une question de temps pour que des mathématiciens qui eux savent trouvent comment tout casser…

Les hashes de 2 chaines identiques visuellement mais pas binairement (vive utf8) seront bien différents on est d'accord. Mais tu les transformes ensuite en image. Le sens de la vue a plein de spécificité chez l'homme (c'est ce qui permet par exemple les compressions destructives). 2 images complètement différentes au niveau binaire peuvent être à l’œil considérées comme parfaitement identiques. Prend n'importe laquelle de tes images et inverse tous les bits de poids faible par exemple. A l’œil tu verras aucune différence mais pourtant au niveau binaire tout aura changé.

A mon avis ça donne un boulevard aux spécialistes du sujet pour qu'il puisse tout casser.

Et tout ça sans parler du fait que tu appliques en plus un algo supplémentaire (multiplication de julia si j'ai bien compris). Plus tu fais de trucs, plus tu risques de faciliter les collisions.

Tu vas me dire que sur plein d'exemple ça fonctionne et c'est vrai, c'est d'ailleurs pour ça que c'est intéressant. Mais le mainteneur debian qui il y a quelques années à corriger le code d'openssl a du aussi penser que ça fonctionnait parfaitement (http://linuxfr.org/news/d%C3%A9couverte-dune-faille-de-s%C3%A9curit%C3%A9-critique-dans-openssl-de-deb).

Bien meilleure dépêche que la précédente.

Mais si je puis me permettre il faudrait encore travailler la clarté. L'améliorer permettrait d'éviter des recherches au lecteur…

Exemple :

À l'occasion de la sortie par Hypra d'une nouvelle synthèse vocale, plus naturelle et plus intelligible, il m'a semblé utile de vous présenter le contexte. Car cette sortie, c'est surtout un module supplémentaire pour speech-dispatcher,

Ok vous avez écrit un module libre.

la plateforme libre de synthèses vocales sous GNU/Linux.

Speech-dispatcher est donc une plateforme libre.

Malheureusement le module, libre, ne marche qu'avec la synthèse, qui n'est pas libre.

Qu'est-ce que cette synthèse qui n'est pas libre ? Comment s'articule votre module, cette synthèse, speech-dispacher ?

Mais sait-on jamais, l'Université pourrait y venir avec le temps.

Que vient faire l'université là dedans ?

Bref, c'est pas très clair pour quelqu'un qui ne connaît pas déjà le sujet et je pense que c'est à améliorer.

Ok, mais dans ce cas à part "Félicitations" que veux-tu entendre ? Difficile de discuter de trucs techniques intéressants si tu ne parles pas de la machinerie.

De ce que je comprends de ton projet et de ta capture d'écran, ça aurait pu se faire avec munin par exemple. Un démon munin-node qui tourne sur le raspberry pi, et un munin sur le serveur de supervision. Il "suffisait" d'écrire un script basé sur un template munin pour lire ta sonde physique.

Le libre est bien placé pour ce type de projet je trouve, il y a pléthore de solutions de supervision fonctionnelles.

Ca donne envie effectivement, mais même le lien n'en dit pas tellement plus.

nous détournons l'usage d'un logiciel libre pré-existant

Lequel précisément ? Et en quoi vous détournez son usage ?

Félicitations au passage pour amener le libre dans nos mairie.

Ta solution initiale suppose que le manque de mémoire sera temporaire et que le gros consommateur n'est pas toi. Dans ce cadre elle est très intéressante.

Mais si tu lui rajoutes une limite temporelle, il va y avoir des cas où elle va aborter alors qu'il aurait suffit d'attendre un peu plus.

Donc pour la rendre résistante au dead lock tu l'affaiblis.

En fait l'approche de pasBill pasGates est plutôt valide dans un cas : un poste client (mono utilisateur donc) qui utilise une seule application à la fois et où il y a une myriade de processus systèmes qui tournent. Si un de ces processus (Cortana par exemple) a besoin d'un énorme espace mémoire quelques instants et qu'il reste plus rien pour les autres, c'est pas idiot qu'ils attendent un peu (mais c'est basé sur l'espoir que le gros demandeur a besoin de son allocation très peu de temps, ce qui n'est pas forcément vrai).

Au fond c'est peut-être ça la morale de l'histoire : ce problème n'a pas de solution générale. Certains choix seront meilleurs que d'autres uniquement dans un contexte précis.

Il y a peut-ête le cas des limites dépassées (ulimit, cgroup), limites fixées par avance. Du coup ça sort du cardre de la discussion (ben oui, si on connaît d'avance la mémoire nécessaire, on n'a qu'à faire une allocation statique au début du programme…)

Avec la config de son conteneur LXC, il a spécifié la RAM disponible pour tout son conteneur. Il doit y avoir plein d'autres trucs qui tournent, donc la mémoire dispo pour un soft particulier est non déterminable.

Quand un malloc échoue, la moindre des choses, c'est de logger un truc avant d'exploser en vol. Parce qu'un programme qui s'arrête d'un coup sans prévenir et sans aucun message, ça fait pas sérieux.

Effectivement ça fait pas sérieux on est d'accord. Le truc c'est qu'il est difficile de garantir qu'on puisse logger par exemple. Si malloc a échoué, c'est qu'il y a moins d'espace disponible que ce qui a été demandé. Comment être certain que l'action qui va être utilisée pour avertir l'utilisateur va fonctionner ? Je pense qu'on peut pas. Si c'est une allocation d'1 Go qui a échoué, c'est peut-être parce qu'il reste 500 Mo disponible, avec ces 500 Mo on pourra signaler facilement effectivement. Mais c'est peut-être aussi parce qu'il reste 4 octets, et est-ce qu'on peut encore faire quelque chose avec ça ? De plus on pourra peut-être être certain que sur tel OS ça va fonctionner, mais comment être certain que ce soit portable ?

D'ailleurs plus j'y réfléchi plus je me dis que les langages "modernes" sont désavantagés au final. Oui une exception va être déclenchée. Mais si il reste 4 octets disponibles, il faut avoir des notions pointues sur le fonctionnement des allocations mémoires pour que le soft survive. Or ne pas avoir à se soucier de ces concepts est une des raisons d'être des langages managés.

Ton approche est intéressante, mais après réflexion elle va n'être pertinente que dans le cas que tu décris : un soft qui fait éventuellement des grosses allocations pendant pas longtemps. Effectivement, les autres à côté peuvent patienter un peu jusqu'à la RAM soit libérée.

Mais imaginons un autre cas. Ta technique se répand, tous les softs s'y mettent. Sur un serveur, on a par un exemple un serveur web qui lance un processus par connexion. Chaque processus consomme pas grand chose, mais consomme régulièrement. Il y a beaucoup de connexion, on commence à toucher les limites en terme d'allocation mémoire :
- système "classique" qui segfaulte ou aborte : le processus qui va vouloir franchir la limite va claquer, ce qui va libérer un peu de RAM pour les autres qui vont continuer. Si d'autres connexions arrivent, le système va certes tuer quelques processus, mais il en fera toujours tourner à la limite de ses capacités.
- ton système : le processus qui va franchir la limite va partir en boucle infinie, les autres qui continuent d'allouer un peu vont aussi partir en boucle infinie. Un bon gros dead lock en somme.

Ceci dit, je suis parfaitement d'accord avec ça :

Perso c'est simple, je considère que ne pas gèrer un NULL retourné par malloc est une faute grave si malloc peut retourner NULL.

Mais en C je vois pas comment faire sans utiliser la méthode canonique qui consiste à vérifier le retour de malloc() à chaque appel et avoir architecturé le soft pour qu'il soit capable de gérer un NULL proprement.

La spécification de malloc (http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html) indique :

Upon successful completion with size not equal to 0, malloc() shall return a pointer to the allocated space. If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. Otherwise, it shall return a null pointer.

Si malloc peut pas allouer, elle va donc renvoyer un pointeur nul. Je pensais qu'y accéder allait forcément entraîner un segfault, mais visiblement ce n'est pas le cas, tu as raison (voir http://stackoverflow.com/questions/12645647/what-happens-in-os-when-we-dereference-a-null-pointer-in-c). Apparemment ça a même permit des exploits fonctionnels pour récupérer les droits root.

Je vois pas pourquoi tu imagines que les utilisateurs de "langages modernes" peuvent se passer de ce genre de considération. Que fera la jvm (par exemple) si elle exécute un algo qui a besoin d'allouer 1 To si la machine peut pas lui fournir ? C'est pas une question rhétorique d'ailleurs, j'en sais rien, mais ce que je sais ce qu'elle fait pas de magie, donc elle y arrivera pas.

Personnellement, dans mes softs (c++), je ne capture pas std::bac_alloc. Le prof qui m'a enseigné C++ disait à tort ou à raison que c'était inutile, parce si cette exception était déclenchée, on pouvait plus faire grand chose qui est un sens. Juste créer la std::string qui va contenir le message à destination de l'utilisateur risque fortement d'échouer par exemple (selon l'implémentation et l'espace restant par exemple) Quelques (trop ;p) années plus tard, je sais que cette affirmation doit être nuancée, mais dans mon cas précis (développement de softs dits "de gestion") elle reste vraie je trouve : les algos que j'écris ne doivent pas la déclencher, tout simplement parce qu'ils ne doivent utiliser que des quantités ridicules de mémoire. Imaginez je ne sais pas moi un crm. Si un std::bad_alloc est déclenché sur une machine moderne avec plusieurs Go de RAM, c'est qu'il y a un gros problème de conception. Faut pas chercher comment capturer et repartir, faut surtout chercher les fuites.

J'imagine que les avis vont être différents sur ce journal. Les types qui développent par exemple des outils de calcul dans la recherche vont peut-être avoir besoin d'allouer des Go, et captureront std::bad_alloc. Les types qui écrivent des applis de gestions (qui en général délèguent les opérations coûteuses à un SGBDR) ne s'en soucieront sûrement pas.

Ceci dit, je trouve ce journal très intéressant, car même si dans mes softs je ne m'en soucie pas (par pragmatisme), il y a toujours ce petit truc qui gratte. Je préférerai bien évidemment qu'ils marchent coûte que coûte.

Dernière chose, je vais quand même décrire une technique que j'utilise depuis quelques années pour résoudre une partie du problème : j'utilise le RAII au maximum. Une classe qui va allouer le fera dans son constructeur. Si ça échoue, un std::bad_alloc va donc être déclencher. Vu que j'utilise le RAII, je m'attends déjà à ce que le constructeur échoue et le code appelant capture déjà les exceptions, donc si jamais std::bad_alloc était déclenchée elle serait capturée par le niveau du dessus qui gère déjà l'échec de la construction. Je pense donc que même un std::bad_alloc serait géré proprement, même si c'est pas garanti (pas impossible que le code du catch alloue des trucs et du coup relance un std::bad_alloc).

A vrai dire et en conclusion, mes softs sont utilisés un peu partout en France depuis 10 ans par des centaines ou des milliers de gens, si des std::bad_alloc avaient été déclenchés, je serai déjà au courant et on m'aurait demandé de trouver une solution. Ce n'est pas le cas.

Je les change tous. Le tarif d'un condensateur se compte en dizaine de centimes. Sur la dernière tv que j'ai réparé, il y en avait une grosse dizaine, ça m'a coûté 4 €.

Personnellement j'ai déjà réparé plusieurs TV LCD pour des amis distincts. Quand ça tombe en panne au bout de quelques années c'est souvent des condensateurs de mauvaises qualité qui ne remplissent plus leur office. Je pense notamment à un vieux 82 cm LCD que j'ai réparé il y a environ 5 ou 6 ans pour un ami proche, et que je vois toujours régulièrement fonctionner quand j'y vais.

Ca coûte quelques euros de condos et il faut avoir un fer à souder à pane fine (une vingtaine d'euros pour le mien). C'est pas très compliqué, et si jamais ça ne fonctionne pas, ça ne fait que quelques euros de perdus. J'ai pas eu d'échecs pour l'instant.

Lancez-vous c'est plus facile que ça a l'air.

A noter que j'ai entendu parler il y a quelques années de gens qui le faisaient sur des cartes mères, mais j'ai jamais essayé.

En tout cas l'initiative va dans le bon sens.

Je vous félicite en tout cas pour ce projet.

Un petit paragraphe sur les technologies utilisées aurait été un plus. Quel ocr utilisez-vous ?

Comme l'indique http://www.linuxfr-france.org.invalid/article/man-fr/man1/ls-1.html, ls -A fait ce que tu désires.

Le modèle précis du nas pourrait être intéressant. Et tu sauvegardes où ?

Un backup c'est normalement une opération qui est "simple". Utiliser 258 Go de ram pour un backup de 2000 Go (rapport 1/8) ça me parait être le signe que ce n'est pas la bonne méthode.

De plus 1 an et demi ça fait une cinquantaine de millions de secondes. 1,2 To / 50 millions de secondes : 24 ko/s ? Là aussi ça ne me semble pas être la bonne méthode.

Sans le -H la consommation de ram est plus classique ?

Et le -S ?

Tu devrais essayer différentes combinaisons sur une petite volumétrie pour trouver une meilleure combinaison.

As-tu la possibilité d'utiliser un simple cp -al ?

Tu peux également acheter ce genre de truc :

http://www.partsdata.fr/cables-usb-und-accessoires/cable-usb/adaptateurs-usb-mecaniques/k-001/usb-adapter-a-maennlich-auf-4-stifte

Ou alors tu peux tout simplement le fabriquer en sacrifiant une vieille rallonge usb par exemple.

Pour la licence j'ai pas vraiment réfléchi à la question. GPL admettons.

Quant au git public, tout simplement parce que ça prendrait du temps (trop pour un script plus petit que sa licence).

Effectivement, voici les 2 lignes incomplètes :

normal=$(ocrad -l "$pbmfile" | iconv -f iso8859-15 | hunspell -G | grep -v '[0-9]' | grep '[a-zA-Z]\{4\}' | wc -l)
flipped=$(ocrad --transform=rotate180 -l "$pbmfile" | iconv -f iso8859-15 | hunspell -G | grep -v '[0-9]' | grep '[a-zA-Z]\{4\}' | wc -l)

Il y a quelques temps j'ai eu besoin d'écrire un script qui détectait l'orientation d'un document scanné et le remettait automatiquement "dans le bon sens".

Simple à faire, un passage d'ocr sur le document initial puis un second sur le document retourné à 180°. Le résultat comportant le plus de mots existants de plus de 4 lettres (pour éviter les artefacts) gagne.

Du coup j'ai installé une bonne partie des ocr disponibles. Le meilleur (dans ces conditions précises) a été ocrad :
- très peu de dépendances sous debian (libc6 libgcc1 libstdc++6, qui sont très probablement déjà installées)
- très rapide (de l'ordre de la seconde pour une image de 3 millions de pixel en 300 dpi)
- résultats parfait pour l'usage.

Testé sur une vingtaine de milliers de document, il fonctionne impeccablement.

Voici le script pour ceux que ça intéresse :

#!/bin/bash
# this script determines whether an image must be flipped by comparing the results
# of OCR on the image and the flipped image


show_help()
{
        echo "${0##*/} image1 [image2]..."
        exit 1
}

topbm()
{
        mimetype=$(file --brief --mime "$1" | cut -d';' -f1)
        case "$mimetype" in
                "image/x-ms-bmp")
                        bmptopnm --quiet "$1"
                        ;;
                "image/jpeg")
                        jpegtopnm --quiet "$1"
                        ;;
                "image/png")
                        pngtopnm --quiet "$1"
                        ;;
                * )
                        >&2 echo ${file}: Mime type "$mimetype" not supported
                        return 1
                        ;;
        esac
}

verbose=0
while getopts ":vh" opt
do
        case $opt in
                v)
                        verbose=$((verbose + 1))
                        ;;
                h)
                        show_help
                        exit 0
                        ;;
                \?)
                        >&2 echo "Invalid option: -$OPTARG"
                        show_help
                        exit 1
                        ;;
        esac
done

shift "$((OPTIND-1))"

pbmfile=$(mktemp)

for file in $*
do
        topbm "$file" > "$pbmfile"

        if [ $? -eq 0 ]
        then
                normal=$(ocrad -l "`{mathjax} pbmfile" | iconv -f iso8859-15 | hunspell -G | grep -v '[0-9]' | grep '[a-zA-Z]\`
                flipped=$(ocrad --transform=rotate180 -l "`{mathjax} pbmfile" | iconv -f iso8859-15 | hunspell -G | grep -v '[`
                if [ $flipped -gt $normal ]
                then
                        if [ $verbose -gt 0 ]
                        then
                                echo "$file : flip needed ($normal / $flipped)"
                        fi
                        mogrify -flip -flop "$file"
                fi
        fi
done

if [ -e "$pbmfile" ]
then
        rm "$pbmfile"
fi

Après avoir simplifié l'accès à GNU/Linux et avant d'y avoir implémenté des synthèses vocales de haut niveau, la société Hypra a résolu la question de l'OCR

Quand je lis une rodomontade de ce genre, publiée sans filtre en première page, le site baisse d'un cran dans mon estime.

rodomontade? Cette phrase est fausse? Ou est-ce l'alergie à la mise en valeur du travail d'une équipe qui vous gêne? Si j'avais écrit ça et dit qu'une asso en était à l'origine, ça passerait mieux? Aller pour vous rassurer: aucun des actionnaires n'est payé depuis 1 an.

Oui cette phrase est fausse. Vous pensez vraiment avoir résolu la question de l'ocr sous linux ? Vous avez fait avancer les choses pour un public bien précis, c'est déjà très bien.

Les gens ici savent déterminer d'eux mêmes les mérites de votre travail, vous n'avez pas besoin d'exagérer les choses et un langage trop commercial vous dessert sur cette plateforme.

%SYSTEMDRIVE%\ProgramData\LibreSSL aurait suffit.

Même %PROGRAMDATA%\LibreSSL.

pour la version Windows, le répertoire de configuration par défaut est maintenant c:\LibreSSL\ssl ;

Je sais bien que Windows est pas le coeur de cible, mais c'est quand même curieux ce choix de dossier. C'est un peu comme si sous linux la conf par défaut était dans /LibreSSL/ssl.