Damien Thébault a écrit 339 commentaires

À mon avis, tu devrais te tourner vers la RAM. Ce genre de soucis est assez typique d'un problème mémoire et se caractérise différemment en fonction des OS.

D'abord une petite vérification avec Memtest86+ (il me semble proposé sur le live-CD d'ubuntu, mais aussi une fois installé sur le disque dur, et sinon il y a une iso sur le site www.memtest.org ). Il faut attendre assez longtemps mais une nuit suffit à se faire un idée en général.

Si tout fonctionne bien, il faudra trouver autre chose.

Mais si il y a des erreurs, il faut changer les barettes de mémoire. Si il y en a plusieurs le mieux c'est de les tester une par une pour trouver le coupable. Une fois la barette défectueuse trouvée, il ne reste plus qu'à la remplacer et ça devrait repartir correctement (tester la nouvelle également!).

Pas besoin de ncurses pour cacher les touches et utiliser autre chose que entrée. Ça peut se faire avec tcsetattr(), en désactivant le mode 'canonical' et les différents ECHO.

Typiquement:

struct termios tios = {0};
tcgetattr(0, &tios);
tios.c_lflag &= ~(ECHO|ECHONL|ICANON);
tcsetattr(0, TCSANOW, &tios);
Si le but est d'être compatible windows, il faut cependant mettre ça sous ifdef (par exemple _MSC_VER) car c'est différent là-bas.

Le reste a très peu besoin de changer, mais un peu quand même.

Sinon le fichier main.c a des fins de ligne windows contrairement aux autres fichiers.

Bonjour,

D'après ce que hachoir remonte, ce petit fichier est un PNG 1bpp qui utilise une palette et est non transparent, pas forcément très courant.

Je reproduis le problème chez moi également avec LibreOffice 5.4.4.2 avec la méthode suivante:

• Ouvrir le fichier
• Supprimer la dernière page
• Enregistrer le fichier

Si on compare les deux .png appelés 100000000000002800000031FB2A5F08.png, on voit que dans la nouvelle version il manque le tag "IEND".

Au niveau de LibreOffice, ce tag "IEND" a l'air de ne pas être créé dans tous les cas, il y a donc peut-être un format qui passe au travers:
https://github.com/LibreOffice/core/blob/master/vcl/source/gdi/pngwrite.cxx

if (mbStatus)
{
ImplOpenChunk(PNGCHUNK_IEND); // create an IEND chunk
}
Il y a un bug un peu similaire ici, mais ne semble pas être exactement le même problème car le fichier n'est pas corrompu de la même manière:
https://bugs.documentfoundation.org/show_bug.cgi?id=75285

Et celui-ci mais c'est seulement depuis la 6.0 et ça semble affecter seulement l'export PDF:
https://bugs.documentfoundation.org/show_bug.cgi?id=115297

À mon avis ça vaut le coup de créer un bug avec le fichier d'origine et comment reproduire le problème.

Tout le monde a l'air d'accord sur le fait qu'un but existe chez Intel, le seul mystère reste quoi précisément.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Je dirais que gentoo est dans la catégorie "non décidée". J'ai un laptop en systemd et un serveur en openrc et les deux fonctionnent très bien, c'est au choix. Encore plus que Archlinux je dirais.

Comme alternative, j'utilise un peu attic mais j'aurais du mal à dire les différences avec zpaq.

Il y a des articles qui on essayé de comprendre ce qui s'était passé, à priori il y avait un commande "répète après moi" qui devait être utilisée pour les tests et qui n'avait pas été enlevée. Du coup il y avait moyen de lui faire assimiler des phrases beaucoup plus vite que la normale.
Et du coup certains se son amusés à envoyer ce genre de phrases.

Pas sûr, ils disaient justement que c'était le seul chip avec des spécifications disponibles, et donc qu'ils n'étaient pas prêts d'en changer.
(Mais quid de ARM Mali ?)

D'après l'article, je verrais deux raisons:

• l'auteur s'est aperçu que son logiciel comportait des failles suffisamment graves qu'un simple patch ne suffirait pas à le résoudre et qu'il valait mieux arrêter totalement le service et recréer un nouveau logiciel avec une architecture permettant une meilleure sécurité

• l'auteur s'est vu obligé d'installer une backdoor dans le logiciel par la justice, il a donc préféré couper le service (par contre je ne vois pas en quoi créer un nouveau logiciel changerait la donne)

Il me semble que déjà l'installation par virtualenv ne fonctionnait pas très bien (problème avec python3 sûrement, de code upstream pas stable, voire les deux), de plus ça ne permet d'après la page d'installation que de tester, j'ai donc suivi ensuite la page Deploying.

J'ai trouvé très compliqué de configurer uWSGI sur mon serveur apache qui avait déjà plusieurs services.
Faire un reverse proxy dessus a été très compliqué (à priori avec n'importe quel projet django), et je n'ai toujours pas bien compris ce qu'étaient celery et redis.

J'ai fini par passer par docker, mais j'ai mis un peu de temps à adapter la méthode docker pour mon postgresql local (et non dans un container).

Maintenant que ça fonctionne je ne veux pas trop y toucher (pas pratique pour les mises à jour vous me direz), mais cette page Deploying ne me semble pas très KISS. Peut-être que certains pourraient m'expliquer le pourquoi du comment de tout ça, il y a sûrement une raison j'imagine !

Ça se passe en local sur l'ordinateur (serveur?) où le logiciel a été installé, ça permet de gérer soi-même ses documents sans avoir à les confier à un tiers.

Après avoir entendu parler de unpaper il y a quelques temps, je me suis décidé il y a quelques mois de chercher un logiciel pour la dématérialisation de mes documents (mais qui fasse en plus l'OCR, l'indexation, la recherche et l'aperçu).

J'ai un peu galéré à trouver des solutions libres, j'avais déjà testé une version de paperwork dans le passé mais un accès en HTTP m'intéressait beaucoup afin d'accéder à mes documents de n'importe où. J'ai finalement trouvé Mayan EDMS (qui venait de sortir en version 2.0) et qui semblait correspondre à ce que je voulais.

Je l'ai installé (vraiment vraiment pas simple à installer d'ailleurs!) ; au final ça fonctionne vraiment pas mal. Les documents sont disponibles dans l'interface web, l'OCR est automatique et prise en compte dans la recherche, il y a une preview dans le browser, les tags sont gérés, ainsi que le multi-compte, on peu uploader pas mal de types de documents différents (PDF, images, documents doc/odt, …) et ça gère les watch directory.

C'est pas forcément le même usage que paperwork, mais je me permet d'en parler car c'est un peu le même domaine et qu'on en parle pas assez.

Au passage j'ai également fait l'acquisition d'un scanner de documents recto-version WiFi (en l'occurence un scanner Brother ADS-1100). Ça upload automatiquement un PDF sur un serveur FTP les documents (multi-pages) qui peuvent ensuite être indexés automatiquement, ça simplifie vraiment la vie !

Un patch ne serait-il pas un travail dérivé ? Il a clairement besoin du code de base pour fonctionner.

Je ne connaissais pas la fabrique de la loi, mais c'est déjà très complet comme outil ! Ça contient plusieurs des choses que tu demandes.

Ça mériterait d'être plus connu !

Le voici tel qu'il était le 22 Juillet 2014:
https://web.archive.org/web/20141226030217/https://canary.silentcircle.com
Exactement le même contenu, donc rien n'a changé depuis.

C'est aussi le cas sous Linux, en tout cas sur le Firefox 35.0.1 de ArchLinux:

OpenH264 Video Codec provided by Cisco Systems, Inc. 1.3

Merci pour ce journal, je ne savais pas que le TrimSlice était supporté par Fedora !
Du coup je vais peut-être installer ça plutôt que ça reste trainer dans un coin par faute de temps pour créer une distribution aux petits oignons :)

Juste une petite remarque non pas lié à fish mais à ceci :

sudo which fish >> /etc/shells

sudo lance seulement "which" avec les droits root, la redirection vers /etc/shells est toujours faite par le shell courant. Ce qui est souvent fait est :

which fish | sudo tee -a /etc/shells

Sinon pour fish, j'avais bien aimé la coloration syntaxique dynamique. Du coup j'avais trouvé un module zsh-syntax-highlighting qui permet de faire la même chose : https://github.com/zsh-users/zsh-syntax-highlighting (que j'avais configuré pour avoir les mêmes couleurs que vim par habitude)
Fonctionnalité bien sympa que j'utilise tous les jours !

Oui je trouve également que la méthode debian n'est pas à mon goût.

Une des choses qui me déplait le plus est de travailler dans les sources. J'ai fait pas mal d'ebuilds et les information d'empaquetage sont bien séparées des données upstream, ça offre une bonne transparence.

Du côté de debian, c'est beaucoup moins clair, c'est à mon avis plus difficile de voir les différences avec l'upstream et de vérifier si l'archive sur laquelle est basée le paquet est la bonne, alors qu'avec d'autres systèmes on dispose de sha-2 voire de signature gpg !

Du coup à choisir une distribution binaire, debian ne m'a jamais vraiment attiré alors que archlinux est placé plus haut dans mon estime.

Après je ne crache pas dessus non plus, la communauté debian est importante et on arrive à trouver des informations intéressantes sur des bugs dans certains paquets, mais niveau technique des paquets je suis pas trop fan.

Sur mon laptop (où je n'ai que linux), j'ai voulu utiliser uefi/efibootmgr pour pouvoir choisir mes kernels, et j'ai eu sensiblement le même problème. En fait les modifications faites par efibootmgr ne sont pas prises en compte par l'uefi du laptop.

Alors je ne sais pas si c'est efibootmgr qui ne fait pas ce qu'il faut ou si c'est l'implémentation de l'uefi mais ça ne fonctionne pas.

Du coup je suis passé par rEFInd qui va chercher les kernels et qui les démarre. Il se met dans /boot/efi/boot/bootx64.efi (ce qui est prioritaire sur les entrées affichées par efibootmgr)

À priori rEFInd est capable de démarrer windows ou macosx également donc tu devrais pouvoir y arriver comme ça.

Si tu utilises déjà grub2 l'autre solution serait d'utiliser grub2 en tant que bootx64.efi et démarrer windows depuis là (je ne sais pas si grub2 est capable de démarrer un windows UEFI mais peut-être bien).

Ma conclusion c'est que efibootmgr ça ne semble pas très bien marcher mais je ne sais pas (encore?) bien pourquoi, et qu'il faut donc utiliser un bootloader UEFI placé dans /boot/efi/boot/bootx64.efi pour avoir les mêmes fonctionnalités qu'un bootloader classique.

P.S: il y a juste un truc qui m'embête avec rEFInd c'est qu'il reste affiché 1s (minimum non diminuable puisque la valeur 0 c'est illimité) avant de lancer le kernel, du coup ça augmente d'autant le temps de boot, mais bon c'est pas si grave que ça.

On sort en quarts.

À moins que tu ne sois dans l'équipe de France de football, tu devrais dire que l'équipe de France perd en quart de finale.

De mon côté j'utilise gpg: j'écris les informations (login, mdp, …) dans un fichier texte, je le chiffre avec gpg avec ma clé publique, je supprime le fichier texte et voilà.

C'est totalement portable, je peux me connecter en ssh de l'extérieur et récupérer n'importe quel mot de passe, etc.
Le backup des fichiers chiffrés est sans problème, seul le backup de la clé est un peu plus compliquée, mais c'est déjà fait pour l'email donc rien de plus à faire!

Ah non pardon c'est 4032x4080, en tout cas la 4K ne peut pas être accélérée (par contre l'UHD peut):

$ vdpauinfo
[...]
Video surface:
name   width height types
-------------------------------------------
420     4096  4096  NV12 YV12 
422     4096  4096  UYVY YUYV 
[...]
Decoder capabilities:

name               level macbs width height
-------------------------------------------
MPEG1                 0 65536  4032  4048
MPEG2_SIMPLE          3 65536  4032  4048
MPEG2_MAIN            3 65536  4032  4048
H264_MAIN            41 65536  4032  4080
H264_HIGH            41 65536  4032  4080
VC1_SIMPLE            1  8190  2048  2048
VC1_MAIN              2  8190  2048  2048
[...]

J'avais testé mpv à une époque mais le changement de nom des options m'avait pas mal gêné, impossible de retrouver certaines.
Du coup je suis resté à mplayer2, vdpau fonctionne sans problème (enfin jusqu'à 4095 de large, dommage pour les vidéos 4K qui font 4096!) et je garde les options.

Chez moi le proof-of-concept ne fonctionne pas:

[+] Resolving symbols
[-] Couldn't resolve "commit_creds"
[-] Couldn't resolve "prepare_kernel_cred"

C'est efficace les kernel hardened avec PaX+Grsec :)