Jérôme Flesch a écrit 379 commentaires

'fectivement, j'avais manqué quelques autres dépendances (GTK, GdkPixbuf notamment). C'est rectifié.

Bien vu. C'est rajouté.

J'en profite pour clarifier un truc rapidement: Même si le scan échoue, IronScanner vous laisse soumettre un rapport de scan. Personnellement ça m'arrange si vous le soumettez quand même. Le site openpaper.work présente les informations d'une façon plus pratique pour moi et fournit des statistiques sur ce qui marche et ce qui ne marche pas.

il semble que ce soit un problème de droits

Je suppose que c'est cette trace qui t'as fait pensé ça: source->get_value() failed: 0x40000008, Access denied ? Mais en fait c'est un peu plus fourbe que ça.

Si c'était un problème de droit, il ne verrait même pas le scanner.

Là il le voit, mais n'arrive pas à accéder à la valeur de l'option source. Quand le programme tente de sélectionner la source, un des composants de la Libinsane cherche à s'assurer que la valeur qu'on veut y mettre n'est pas déjà la valeur courante (certains pilotes crash dans ce cas …). Quand il tente d'accéder à la valeur de source, un autre composant vérifie qu'on a le droit de demander cette valeur au pilote (certains pilotes crashent si on cherche à lire une valeur d'option dans une option inactive …). Ici le pilote a indiqué qu'on n'a pas le droit de lire la valeur de l'option source (probablement une erreur …), et donc le composant Libinsane qui vérifie les droits renvoie "Access denied".

Tout ça pour dire que le problème est après: Faute d'avoir pu consulter la valeur courant de l'option source, le composant Libinsane autorise l'écriture. Et là paf, le backend répond genesys:libusb:003:002->source->sane_control_option(SET_VALUE) failed: 0x40000003, Invalid value. Pourtant la valeur passée me semble correcte.

Est-ce que tu parviens à scanner avec un autre programme type simple-scan ?

Ça c'est toujours une bonne question :-)
Parce-que si ça ne marche pas avec simple-scan, le problème ne vient sûrement pas de la Libinsane.

Le binaire IronScanner est construit pour amd64 uniquement. Tu ne serais pas en i386 sur ta machine par hasard ?

Si c'est le cas, il reste la possibilité de lancer IronScanner à partir de ses sources.

Effectivement, dans les instructions, il manquait le paquet virtualenv. Merci de me l'avoir signalé. C'est rectifié.

Je vais jeter un coup d'œil au code de Gsane, des fois que tu avais des fixs que je n'ai pas encore :)

D'ailleurs, SANE2 n'est jamais sortie, non ?

Il ne me semble pas. Et ce n'est pas une mince affaire parce-que je suppose que ça implique de refaire une passe sur tout les backends/pilotes, et comme il y en a certains qui sont propriétaires (Brother par exemple) …

AttributeError: module 'PIL' has no attribute 'Image'

Arf. Je note que selon la version de PIL, on peut accéder à PIL.Image sans faire import PIL.Image :-)
C'est rectifié. Merci de me l'avoir signalé.

Ah, c'est .. gênant. Sur un scanner à plat, il devrait s'arrêter après la première page. Sur un scanner à bac d'alimentation, il devrait s'arrêter une fois le bac vide.

Lorsque IronScanner est lancé depuis un terminal, il indique qu'il met ses traces dans un fichier temporaire. Pourrais-tu m'envoyer ce fichier à jflesch@openpaper.work s'il-te-plaît ? (deux ou trois pages de scans suffiront ;).

Elles sont complémentaires.

Libsane = Librairie pour accéder aux scanners sous GNU/Linux (et FreeBSD, etc). Elle fait partie du projet Sane et fait elle-même appel aux sane-backends: les pilotes. Elle a toutefois un défaut: Le design de la libsane fait qu'elle laisse beaucoup de libertés aux pilotes des scanners, ce qui implique des comportements parfois différents d'un pilote de scanner à un autre.

Libinsane = Librairie pour accéder aux scanners GNU/Linux et Windows. Sous GNU/Linux, elle utilise la Libsane (d'où son nom). L'objectif, en plus d'être cross-platform, est de fournir un comportement cohérent quelque-soit le système d'exploitation, l'API (Sane, WIA, TWAIN, etc), ou le pilote utilisé.

Je construit les binaires sur une Debian stable et je ne la teste pas avec des librairies plus vieilles que celles dans Debian stable / Ubuntu LTS. Ça serait trop de travail pour moi.

Dans ton cas, il reste la possibilité de lancer IronScanner à partir des sources.

Yep désolé, le serveur s'est pris les pieds dans le tapis. C'est réparé.

Une autre façon de voir ça, c'est que Zsh a fait une grosse erreur en ne choisissant pas la GPLv3.

À vue d'œil:

• Plus de facilité pour faire de l'orienté-objet ;
• Pas mal d'outils supplémentaires pour éviter de faire des boulettes (RIAA, smart_ptr<>, etc) ;
• Pas mal d'outils supplémentaires pour pouvoir faire des boulettes (bizarreries sur certains trucs genre unique_ptr<>, etc) ;
• Quelques outils pour faire moins de code et/ou plus optimisé (exceptions, etc) ;
• Quelques outils pour faire plus de code (templates de templates de templates, etc).

(PS: J'ai 10 ans de C derrière moi, mais clairement pas autant en C++)

Snowflake

(…)

Pauvre chou

(…)

la violence verbale n'est plus acceptée

Sérieusement ?

Aller, c'est pas vendredi, mais un troll bien gras comme ça, je peux pas résister ^^

Je suis le seul qui voit pas le problème avec la pub Gillette ? (je mets un lien vers l'original pour que chacun puisse se faire sa propre idée :P). Perso, je vois juste une pub qui dit "on peut sûrement faire mieux, alors faisons mieux". De façon générale, ça me semble plutôt une bonne approche dans la vie.

(Operation 'troll' is a go. I repeat, operation 'troll' is a go")

À mon avis, pas forcément si inutile.

Par exemple, imaginons une société de plus de 100 employés dont le PDG serait raciste. C'est très facile pour lui d'aller voir le programmeur du site web et lui mettre la pression pour avoir ce qu'il veut (-> un seul employé). Par exemple, le formulaire pourrait bazarder automatiquement tout ceux qui ne répondent pas qu'ils sont blancs. Qui irait vérifier ?

Avec la loi française, il faudrait qu'il passe à la consigne à tout les RH qui font les entretiens (-> souvent plusieurs personnes), donc plus de risque qu'il y ait une fuite. On peut rajouter à ça le risque qu'il y ait un mot de travers ou une bavure lors de l'entretien en face-à-face. Bref, nettement plus risqué.

Par courrier papier, c'est un peu la même chose: Il y a souvent juste une ou deux personnes qui trient les CVs.

Là je parle de racisme affiché/ouvert, mais il y a aussi un racisme plus "subtil": le préjugé. Le RH reçoit le formulaire de candidature ou le CV, voit une ethnicité autre que blanche ou un nom typé autre que franco-français --> De par son propre passé (son éducation par exemple), son jugement se retrouve tout de suite biaisé, consciemment ou non. C'est malheureusement naturel comme biais. Du coup, le candidat n'aura peut-être même pas l'opportunité de contre-balancer ces préjugés par un simple face-à-face. Or, basé sur mon expérience personnelle, quand les gens "existent" au lieu d'être un simple nom écrit sur une feuille, notre perception d'eux change immédiatement.

Ceci dit, les préjugés peuvent s'étendre aux CV anonymes. À mon avis, ça pourrait justifier de les rendre obligatoires et systématiques.

PS: Et ce n'est parce-que les chinois font n'importe-quoi n'importe-comment que nous devrions faire pareil :P

En France, c'est totalement interdit: https://www.cnil.fr/fr/cnil-direct/question/352 . Mais effectivement, c'est légal aux États-Unis à partir du moment où ils arrivent à justifier la question par une utilisation légale: https://work.chron.com/ask-race-job-applications-31050.html . Par exemple, ils peuvent la justifier en disant que c'est juste pour vérifier qu'ils ne discriminent pas.

Personnellement, je trouve ça quand même très douteux. C'est trop facile à justifier et de quand même s'en servir pour discriminer. Même en offrant la possibilité de ne pas répondre, ça reste trop simple: Par exemple, « Il a pas voulu répondre ? On va supposer qu'il n'est pas blanc ».
D'un autre coté, je suppose que ce genre de question peut aussi permettre de sélectionner son employeur. Étant moi-même blanc mais n'ayant pas envie de bosser avec des racistes, je me ferais un plaisir de répondre "ne souhaites pas répondre".

Quelques bonnes nouvelles:

Les critiques concernant les problèmes de compatibilité dans GTK+ 3 ont été entendues par les développeurs de GTK+: « GTK+ 4.0 ne sera pas GTK+ 4 ».

Pour le support des scanners, pour avoir un truc plus propre et multiplate-forme, je travaille actuellement sur une bibliothèque: Libinsane. Je ne suis plus très loin de sortir la version 1.0 (fin du mois j'espère).

Un peu dans la même idée, j'ai deux machines:

• Dédié chez OVH
• Olinuxino A20 chez moi

Mes documents perso:

• Tout mes documents sont synchronisés par Syncthing sur toutes mes machines perso, avec une copie sur mon dédié.
• Toutes les nuits, le dédié fait une sauvegarde dans un .tar.gz de tout mes documents. Il .tar.gz aussi mes mails (ceux-là ne sont pas synchronisés).
• Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi les .tar.gz de la nuit d'avant.

Les services hébergés sur mon dédié (site web perso, openpaper.work, etc):

• Là, je peux me permettre 1 semaine de perte sans que ce soit trop grave. C'est surtout les installations et configurations que je veux sauvegarder plus que les données elles-même. La plupart des donnés sont soit sur Git soit je m'en fiche un peu (flux RSS, etc).
• Chaque service tourne dans son propre conteneur LXC (--> plusieurs Apache, 2 MariaDB, etc).
• Une fois par semaine, un à un, un script les arrête, en fait un .tar.gz, et les relance.
• Quelques heures plus tard, un script sur le Olinuxino vient récupérer tout ça par rsync. Il garde aussi une copie des .tar.gz de la semaine précédente.

À l'occasion, il faudra que je regarde pour utiliser duplicity pour faire des sauvegardes incrémentales.

Il y a sûrement moyen de faire plus efficace. Par exemple je pourrais éviter la coupure temporaire des conteneurs LXC. Mais pour l'instant c'est la solution la plus simple que j'ai trouvée. Avec cette approche, je n'ai pas à me soucier si un service tourne et pourrais corrompre la sauvegarde, ni à faire de méthode de sauvegarde spécifique à chaque service (cf MariaDB).

Bien vu !

Comme je travaille en QWERTY, je n'y avais pas fait attention. Mais ça peut peut-être se rattraper. Par exemple, le firmware du clavier et du trackpad est open-source, ce qui peut sûrement permettre de rajouter des combinaisons Fn- pour mapper '<' et '>'.

Les deux ont des configurations identiques.

Ceci dit, il y a quand même divers points à prendre en compte :

• Le Pinebook semble avoir quelques coût cachés. Le Teres a aussi des frais de port non-négligeables et le prix affiché est HT. Dans mon cas par exemple, le prix de base du portable + pièces supplémentaires : 277€ ; frais de port : 23€ (UPS) ; TVA : 60€ ; Total: 360€
• Le Pinebook est vendu assemblé. Le Teres est vendu en kit.
• Le Pinebook n'est pas openhardware. Pour le Teres, les schémas et PCBs sont libres (Apache 2.0). Par contre, les composants individuellement restent des boites noires (documentées mais fermées).
• Armbian ne supporte que le noyau 3.10 pour le Pinebook. Armbian supporte le noyau 4.18 pour le Teres.
• Le support du Pinebook a commencé à être ajouté au kernel mainline à partir du 4.19. Le support du Teres a commencé à être ajouté au kernel mainline à partir de 4.17. (ça laisse penser qu'il sera complètement supporté un peu avant)
• Le Pinebook est vendu depuis Hong-kong. Le Teres est vendu depuis la Bulgarie.
• Pour avoir du support concernant le Pine64, c'est sur leur site de support (on notera que les tickets ne sont pas accessibles au public). Pour avoir du support concernant le Teres, c'est par mail, sur IRC ou sur leur forum.
• Il y a une file d'attente pour le Pinebook. Le Teres, malgré ce qui est mentionné sur leur site, m'a été envoyé le lendemain de ma commande.

Non, aucune. Le composant AllWinner A64 est le cœur de ce portable. De ce que j'en ai compris, il est limité à 3Go. Olimex a regardé pour monter à 3Go, mais il ne semble pas simple de trouver les bons composants.

Attention toutefois. En me relisant, je réalise que j'ai omis de mentionner deux choses:

• Les pilotes Allwinner sont propriétaires, d'oú le fait que la distribution founie par Olimex est coincée en Ubuntu 16.04 avec un kernel 3.10. L'effort pour le support du kernel 4.x implique le passage à des pilotes libres.
• Le clavier est QWERTY. Il est toujours possible de le passer en AZERTY avec avec des autocollants achetés sur Amazon, mais c'est clairement moins classe.

J'y avais pensé. Mais je pensais attendre que le support Armbian et kernel 4.x avance encore un peu plus. Parce-que niveau logiciel libre, ça ne fait pas encore rêver pour le moment :/

Personnellement il me faudrait juste le contrôle de la luminosité de l'écran pour le rendre utilisable avec Armbian. Le support de l'indicateur de batterie serait un bon plus. Je songe de plus en plus à regarder si je ne pourrais pas le faire moi, mais pour le moment je suis un peu confus par rapport à quel variante du code kernel utiliser comme base (Armbian ? Sunxi ? Torvalds ? ..). Il va falloir que j'aille discuter sur les forums Armbian pour mettre ça au clair. (et manque de temps, tout ça … :/)

J'en ai acheté un Teres il y a quelques mois. À première vue, pour un développeur/geek, ce portable a peu d'intérêt: Petit processeur, peu de RAM, architecture un peu exotique et relativement chère pour cette configuration. Du coup, ma justification pour cet achat était "parce-que j'en ai envie".

C'est du DIY, avec des pièces de rechange clairement disponibles. Donc je me suis fait plaisir en mélangeant pièces noires (intérieur) et pièces blanches (extérieur) et en repeignant les pièces blanches en bleu. Comme dirait Bob Ross, il n'y pas d'erreur, juste d'heureuses coïncidences … J'ai aussi peint la plupart des touches en noires. (je peux poster des photos s'il y a des curieux :-)

Le montage:
Globalement pas de problème. Le manuel est clair. Si vous savez assembler un PC fixe, vous savez assembler ce portable. Le seul truc qui m'a posé problème: le câble d'antenne Wifi/Bluetooth fait pile poil la longueur nécessaire. Donc en gros bourrin, au premier montage, je l'ai cassé --> portée du Wifi: 1 mètre. Après une 2ième commande et un démontage/remontage, tout est en ordre.
Encore une fois, c'est du DIY. J'en ai donc profité pour ne pas mettre la webcam ni les enceintes.

Niveau logiciel:
Il est fourni avec Ubuntu 16.04 et un vieux kernel 3.10-préhistoire et des pilotes Allwinner tout-moisis-mais-qui-fonctionnent. Le passage en Ubuntu 18.04 est possible mais cause quelques bugs concernant les indicateurs de batteries et le décodage vidéo. Personnellement j'ai finalement préféré rester en 16.04 et utiliser un schroot contenant une debian testing à coté.
La bonne nouvelle, c'est qu'il y a un travail qui est en cours pour moderniser et libérer tout ça. Le résultat est déjà prometteur (meilleures perfs de la eMMC interne notamment).

Niveau matériel:
- 11,5 pouces ;
- ARM 4 coeurs, 2GB de ram, 16GB de mémoire interne ;
- J'ai rajouté une carte SD de 128Go ;
- Avec la distribution officielle: Mémoire interne: 20Mo/s. Carte SD: 20Mo/s. USB: 30 à 40Mo/s ;
- Avec Armbian: Mémoire interne: 40Mo/s. Carte SD: 20Mo/s ;
- La batterie tient sans problème plusieurs heures. Elle tient plus de 10h au repos ;
- La dalle est du 1366x768 (qualité largement suffisante à mes yeux) ;
- Très léger: < 1kg.

Au final je suis entrain de prendre l'habitude de développer dessus. L'idée est que si mes développements fonctionnent correctement sur cette machine, ils fonctionneront partout. Je suppose aussi que travailler dessus mettra plus en évidence les bouts de code qui ont besoin d'optimisations.

Au final, je trouve que son autonomie et sa légèreté le rendent très agréable à utiliser. Par contre, c'est sûr que je ne ferais pas tourner une VM Windows dessus.

Le problème, c'est qu'Olimex, c'est des électroniciens. Ils ne s'y connaissent pas en moulage plastique. Ils ont donc choisi d'utiliser un châssis déjà existant.

Je crois me souvenir qu'ils avaient étudié la possibilité de faire du spécifique, mais que ça augmenterait considérablement le cout.