PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Comment transformer un de ses services avec Docker : gogs

mardi 5 décembre 2017 à 18:30

Maintenant que je sais utiliser mon cluster swarm, il est temps d’expérimenter l’utilisation et surtout la transformation des services existants. La première montagne à laquelle j’ai décidé de m’attaquer : ma forge Git personnelle.

Gogs est un service Git à héberger soi même. Son installation n’est pas toujours de tout repos, surtout sous Debian, d’autant plus dans la configuration où je me trouve (derrière un bastion sur un réseau privé). J’ai en plus ajouté une couche de complexité en choissant comme base de données le moteur Postgresql.

Que ça ne me retienne pas, la structure du projet est selon moi parfaite pour se faire la main et transformer cette installation en stack sur Docker Swarm. Commençons par le début, l’inventaire des logiciels et points d’entrée, et les points persistants.

Postgresql

La VM qui héberge actuellement Gogs est une Debian 8 (la 9 n’était pas encore sortie). Postgresql est donc en version 9.4, ce qui n’est pas un problème puisqu’il est encore supporté (la 9.2 vient seulement de se mettre en retraite). Je vais pouvoir disposer d’un container dédié, il y a une image officielle, j’ai donc le choix entre simplement copier le dossier data en conservant la version 9.4 (après une première analyse c’est chaud, l’installation entre Docker et Debian semble un peu bizarre), monter un 9.6 ou 10 tout neuf en important un dumpall. Dans les deux cas, le dossier data du container postgresql doit être persistant. Son port par défaut sera exposé de manière classique, on verra comment gérer l’accès en fonction du nœud.

Gogs

Le point central, puisque c’est le service lui-même. Le déploiement via Docker est grandement documenté, le dossier /data/ du container doit contenir tout ce que le service Gogs nécessite : dépôts, configurations… Le point le plus tendu pour moi, avec la configuration en bastion, va être de pouvoir relier SSH sans savoir à l’avance sur quel nœud il sera actif. La partie HTTP est facile à mettre en place (je reviendrai dessus tout à l’heure), mais SSH, c’est autrement plus compliqué. Le réseau overlay de Docker permet de router correctement les connexions à un port vers le nœud qui l’expose actuellement, je pourrais donc me contenter de définir la connexion à un nœud en particulier. Mais le concept de l’architecture est de pouvoir continuer à disposer du service même si le nœud est manquant. On verra donc comment résoudre ce problème.

Avant de parler plus finement du réseau, Je voulais vous présenter le docker-compose, mais pendant la mise en place, j’ai rencontré tellement de problèmes, que j’ai du reprendre pas mal de choses. Et comme les erreurs sont aussi intéressantes que les réussites, autant vous partager tout ça, pas à pas, pour comprendre comment j’en suis arrivé au résultat que j’exploite désormais.

Premier fail : le démarrage du conteneur Postgresql

Quand j’ai regardé la structure des dossiers entre la version actuellement installée et ce qu’allait faire en théorie le conteneur, j’ai préféré lancer le tout comme pour une première installation pour comparer, et je n’avais que cinq dépôts, repartir de zéro n’est pas non plus catastrophique. Je lance la stack, composée de deux services (un Postgresql, l’autre Gogs), et alors que j’expérimente déjà plusieurs lenteurs sur le téléchargement des images depuis le hub (un problème récurrent semble-t-il), j’ai également un comportement étrange : Postgresql ne semble pas démarrer. En fouillant plus finement, notamment la documentation sur le hub, on apprend que si Postgresql n’est pas tatillon avec l’utilisateur sur lequel il est lancé, ce n’est pas le cas d’initdb, et manifestement il n’arrive pas à initialiser le dossier. Mais rien à faire, toutes mes tentatives pour lancer ce conteneur échouent.

Après deux heures de lectures, d’essais ratés (pour accélérer les choses je lance le conteneur indépendamment sur un nœud, en spécifiant le volume de destination sans beaucoup plus de succès), après réflexion je ne touche jamais à Postgresql, même sur l’installation actuelle, du coup autant repartir de zéro sur une base sqlite. Un contournement sale, facile peut-être, mais le propre d’une architecture est aussi de faire des choix adaptés à la configuration, et ma forge personnelle ne va pas faire grand chose de violent, donc une grosse base de données n’est pas forcément le choix le plus éclairé.

Deuxième fail : l’initialisation du conteneur gogs

Ben oui, autant le dire tout de suite, évidemment ça ne s’est pas passé correctement du premier coup pour lui aussi. Premier écueil, il n’arrive pas à écrire dans le dossier. Je contourne salement avec un chmod 777, pour me rendre compte d’une chose : il essaie de changer des propriétaires sur les fichiers mais n’y parvient pas (« Operation not permitted »), idem pour certaines permissions. Pourtant l’installation semble tout de même arriver au bout et Gogs est facilement manipulable via son interface web. Jusqu’à me rendre compte que je me suis trompé sur le point de montage et qu’une partie des données est stockée dans le container, ce qu’il faut à tout prix éviter. On scratch donc tout pour tout refaire, ça va très vite, et je continue de constater ces erreurs de changements de droits et de propriétaires, sans pour autant impacter plus que ça le service, en apparence. Au moins toutes les données essentielles (configuration, base de données, dépôts) sont exportées correctement et partagées sur les nœuds.

Jusqu’au premier push via SSH : le contenu du dépôt ne s’actualise pas sur l’interface web (deuxième écueil). Après une vingtaine de minutes de recherches je découvre alors que c’est le montage NFS qui est en cause, via l’utilisation de l’option noexec dudit montage qui empêche l’exécution du hook qui met à jour les infos du dépôt pour l’interface web. Les données, elles, sont bien présentes dans le dossier gogs-repositories. Correction du montage sur les trois nœuds (merci Ansible), redémarrage du container, suppression du dépôt, recréation, push, et paf, ça fait des Chocapic.

Dernier écueil, qui semble en lien avec les soucis de droits, le miroir sur GitHub ne fonctionne pas, SSH refuse de lire la clé privée, car elle ne lui appartient pas et les droits ne le permettent pas. Tout à fait logique, mais dans l’immédiat je ne considère pas ce point comme prioritaire, je remets donc l’analyse à plus tard. Si vraiment je veux pousser une mise à jour je peux toujours ajouter un deuxième remote « github » au dépôt concerné sur mon poste et pousser dessus, mais c’est moins élégant.

Une gestion du réseau particulière

Commençons par les plus simples. Le reverse-proxy HTTP, Nginx en l’occurrence, tape en mode load-balancer sur les trois nœuds, je n’ai donc pas à me soucier du nœud sur lequel il tourne, je suis tranquille de ce côté-là, puisqu’il gère la disponibilité du service tout seul, et le réseau overlay s’occupe du routage sur le nœud actif dans tous les cas. Super simple donc. Voilà à quoi ressemble par exemple le vhost du visualizer :

upstream visualizer_swarm {
	ip_hash;
	server 192.168.1.9:8080;
	server 192.168.1.11:8080;
	server 192.168.1.43:8080;
}

server {
    listen 80;
    server_name visu.seboss666.ovh;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://visualizer_swarm;
    }
}

On comprend que le port exposé est le 8080, et qu’il ne faudrait que peu de choses pour basculer tout ça en HTTPS si je le voulais (ce que j’ai fait pour le registry, que j’aborderai après).

SSH cependant… c’est une autre affaire. Il est très compliqué de le proxyfier, voire impossible, sans même parler de le load-balancer, c’est juste une aberration protocolaire; d’où le bastion d’ailleurs, vous pouvez vous rafraîchir la mémoire si vous comprenez mal de quoi je parle. Comme on n’est jamais certain que le nœud sur lequel on va se connecter est debout, il faut un moyen d’avoir une entrée DNS à jour. Et un fichier de configuration SSH qui lance la connexion derrière le bastion sur le bon port aussi, sinon on a une surprise comme moi à tenter de pousser un dépot git sur une installation (l’hote qui héberge les conteneurs) qui ne dispose pas de forge git adaptée.

La solution va sembler tordue, mais je la trouve particulièrement intéressante pour m’attaquer à une autre fonctionnalité de Docker : la création de sa propre image, ainsi que l’utilisation de Python pour taper sur une API REST, ce que je n’ai pas encore suffisamment l’occasion de faire.

DockerFile + Python + API OVH : une sacrée expérience !

Cette solution particulière est venue de Flemzord en discutant du sujet sur Telegram : la mise à jour dynamique de l’entrée DNS en fonction du nœud actif. Et c’est tout à fait possible, j’ai la chance d’avoir l’API d’OVH sous la main pour mettre à jour ma zone. J’ai un peu tâtonné pour créer les clés nécessaires, mais au final ça a été rapide.

Pour me simplifier la tâche, je suis passé par la classe Python qu’OVH fournit et maintient sur pip. Un réflexe « de l’ancien monde » consisterait à simplement lancer le script à intervalles réguliers via une tâche cron sur l’un des managers, et mettre à jour la zone DNS si besoin, mais une fois de plus étant dans un cluster on ne peut s’assurer que le manager en question est toujours debout et en bon état. Il est donc préférable d’utiliser là aussi un conteneur, dont la particularité sera d’être lancé obligatoirement sur un manager, et de pouvoir accéder au socket pour identifier le host qui exécute gogs à un instant T.

Étant donné la spécificité du script je préfère construire ma propre image, ne serait-ce que parce que je n’ai pas trouvé grand chose d’intéressant existant sur le hub pour gérer l’API OVH + la connexion au socket docker (ou pas documenté/pas à jour). Et ça fait un exercice de plus, à la fois sur Python, et sur la construction d’une image custom. J’ai voulu partir au départ sur la version 3.5 de python, qui correspond à la version disponible sur Debian 9, puisque j’ai fait mes tests « bare » avec, via une des images basées sur Alpine fournies officiellement (3.5-alpine), mais mon script repose sur l’exécution d’une commande « docker service ps » qui nécessite du coup une version de Docker récente qui intègre le mode Swarm, hors la version de Docker correspondante dans les dépôts Alpine 3.4 utilisée s’avère être une 1.11, et il faut la 1.12. J’ai fini par intégrer une autre image tierce pour ne plus perdre de temps, pas forcément maintenue, mais qui m’a permis de débloquer la situation. Je verrais pour disposer d’un truc un peu plus propre dans le futur.

Le fonctionnement du script est simple :

Le tout dans une boucle while true: avec un sleep(60) à la fin pour faire les opérations une fois par minute. Le coup du dictionnaire c’est sale, comme j’ai les entrées DNS correspondantes aux différents hosts dans la zone, je pourrais et je ferai certainement tout via l’API dans un futur proche. L’idée était d’avoir un truc rapide qui fonctionne.

J’ai pas mal tâtonné pour le fonctionnement en brut de ce script, notamment pour l’utilisation de docker via subprocess. En effet, au début naïvement j’ai voulu passer par os.system(), sans avoir lu la documentation, et je peinais à comprendre le comportement et le résultat de la commande, avant de percuter qu’on ne récupère pas la sortie de la commande mais juste son code de retour. L’utilisation de subprocess.check_output() ne fut pas non plus de tout repos avant d’arriver à un résultat exploitable, et aura demandé une bonne demi-heure d’échecs successifs et d’erreurs peu claires pour un novice. Surtout quand, en bon débile qui se respecte, vous commencez par lancer votre script avec la version par défaut de Python sur Debian 9 qui est encore la 2.7 et pas la 3.5.

Alors que c’était mon premier, j’ai moins galéré pour le Dockerfile finalement, mais c’est plus lié à l’image, pour intégrer Docker en sus, finalement ça n’a pas été aussi long. Il ne contient que 7 lignes, qui consistent à mettre à jour les dépôts Alpine, installer Docker, installer le module « ovh » via pip, copier le contenu du dossier (script et configuration d’API OVH) et lancer le script. Bon par contre ça fait une image de presque 160Mo pour un script python de 30 lignes, c’est pas ouf, mais au moins ça fonctionne parfaitement.

Reste un problème : je ne compte pas publier cette image sur le hub Docker en l’état, entre autres parce que c’est dégueulasse au possible, il me faut donc un registry privé. La communication du daemon docker avec un registry se fait via HTTPS, et il existe une image docker simple qui remplit parfaitement le boulot. J’ai donc créé une « mini-stack » pour le registry avec un volume partagé pour les images, et un petit vhost sur la frontière avec pour l’occasion acme.sh qui m’a fait le certificat HTTPS en un tour de main (et un request_body_size à 0 pour s’éviter les erreurs 413 en poussant dessus…).

Dernier exercice nouveau pour moi, j’avais bossé sur un des nœuds tout du long pour terminer ce mini-projet, j’ai terminé en créant l’image « ovhdnsupdate » sur mon poste, en la poussant sur le registry, et en redéployant la stack avec le chemin vers cette « nouvelle » image provenant du registry privé. Et ça a fonctionné du premier coup 😛

Un fichier compose finalement très simple

Je n’ai donc pas besoin de beaucoup d’éléments, après l’abandon de postgresql, les deux que j’ai mentionné sont les seuls nécessaires, puisque le reverse-proxy se trouve pour sa part au niveau du bastion. En lieu et place d’Nginx certains passeront par Traefik qui peut tout gérer automatiquement (à la définition d’un service, si on ajoute les infos pour Traefik il va générer tout seul sa configuration et le certificat Let’s Encrypt kivabien), mais qui demande d’exposer directement son cluster, ce que je n’ai pas trop envie de faire pour l’instant.

Comme indiqué, il n’y a que les deux composants dont j’ai besoin, j’ai sacrifié les configurations existantes de Gogs à cause des structures de dossiers utilisées par le container, qui n’a pas grand chose à voir avec la structure du projet quand on l’installe en bare-metal via clonage du dépôt Git. Aucune redondance nécessaire sur les services, seulement le démarrage automatique, sebnet est le nom du réseau overlay que j’ai créé, les dossiers partagés sont dans /home/seboss666/docker qui est un montage NFS sur le NAS (pour être partagé entre les nœuds, donc pas de souci de ce côté-là).

Voilà le futur déjà présent qui se profile, et qu’on appelle l’infrastructure as code : une fois affranchi de l’installation matérielle, la définition de la configuration des hôtes via Ansible, et des cinq lignes de commandes pour créer un cluster swarm, au-delà des erreurs que j’ai pu rencontrer, il ne faut qu’une trentaine de lignes dans un fichier docker compose, une trentaine de lignes python pour mon script (quarante en comptant la configuration), 7 lignes de Dockerfile, pour définir le déploiement d’une pile d’application nécessaires à la fourniture et l’exploitation de votre service. Sachant que les premières étapes peuvent elles aussi être regroupées au sein d’un fichier dédié pour le déploiement sur une plateforme publique ou privée (je continue à faire à la main pour apprendre), via Terraform par exemple. On lance le déploiement, on attend, on profite.

Reste un dernier point qui me titille malgré tout, cette histoire de droits coincés sur le stockage NFS.

NFS, ce petit vicieux qui cache ses imperfections (et une autre de mes erreurs)

En effet, j’ai encore à travailler sur la solution pour ne plus rencontrer ce problème de changement de propriétaire qui a une source : le montage NFS. Par curiosité, j’ai fait un petit test à la main sur l’un des noeuds du cluster :

[seboss666@swarmleader ~/docker ]$ touch coucou.txt
[seboss666@swarmleader ~/docker ]$ l
total 8
drwxrwxrwx 5 seboss666 seboss666 4096 30.11.2017 11:43 gogs/
drwxrwxrwx 3 seboss666 seboss666 4096 01.12.2017 20:20 registry/
-rw-r--r-- 1 seboss666 seboss666    0 02.12.2017 09:22 coucou.txt
[seboss666@swarmleader ~/docker ]$ sudo chown ansible: coucou.txt 
[sudo] Mot de passe de seboss666 : 
chown: modification du propriétaire de 'coucou.txt': Opération non permise

La dernière fois que j’ai rencontré cette erreur, c’est lorsque j’ai monté un partage NFS en sélectionnant le protocole NFSv4 alors que la source ne supportait que le NFSv3. Là, c’est le contraire, j’ai sélectionné volontairement la v3 car j’ai déjà expérimenté des différences importantes de performances et qu’il est plus simple à optimiser de ce point de vue, mais manifestement, le NAS Asustor ne l’entend pas de cet oreille. Hors, je n’ai absolument pas la main sur la totalité de la configuration des exports et des protocoles supportés.

Il s’avère que c’est finalement un « mappage » utilisateur dans les paramètres du partage NFS que j’avais positionné sur mon utilisateur, et qu’il fallait positionner à « root ». Comme je n’avais « restauré » qu’un seul dépôt pour les tests, j’ai de nouveau refait l’installation de zéro histoire d’avoir un truc réellement propre. Enfin presque, il reste un détail d’UID par défaut, mais c’est lié au conteneur gogs et sans grosse incidence sur le service en lui-même, au moins quand il essaie de changer quelque chose (propriétaire, permissions), ça fonctionne.

Mon dernier problème que je pensais lié au NFS était le mirroring GitHub, qui finalement était lié au fait que sans interactivité, pas de validation de la connexion SSH la première fois. En recopiant le fichier known_hosts de la VM d’origine, ça fonctionne !

Un projet particulièrement instructif

J’ai appris énormément avec cette conversion, autant des erreurs que des succès, les deux étant liés de près ou de loin non seulement à mon apprentissage de la technologie, mais aussi à l’installation de mon cluster (généralement on débute sur une machine unique pour faire ce genre de choses) et le choix de l’utilisation d’un partage NFS comme point de montage partagé. Mon sentiment à propos de la technologie ne change pas fondamentalement, mais mettre les mains dedans profondément est d’autant plus intéressant, voire plus que toutes les documentations et partages d’expérience, que ça permet d’en saisir les limitations dans certains contextes.

On comprend aussi beaucoup mieux les avantages et inconvénients. J’imagine que l’installation hors container d’un registry privé pour mes images Docker m’aurait pris beaucoup plus de temps, et finalement ce qui m’a ralenti c’est l’installation d’acme.sh et la génération du certificat Let’s Encrypt sur le reverse proxy, et non pas l’installation du service lui-même. Un service peut donc être particulièrement rapide à déployer, d’autant plus quand il repose sur plusieurs logiciels qui sont déployés d’une seule traite. Dans le contexte de clustering, la mise à l’échelle (lancer plusieurs instances d’un service pour absorber la charge) est aussi très grandement facilité. Je ne vais pas revenir sur les aspects négatifs de la conteneurisation, Aeris l’a déjà très bien fait et comme le concept n’a pas fondamentalement évolué, la plupart des critiques restent valides.

J’ai beau ne pas l’accueillir avec un très grand enthousiasme, la montée en puissance de la conteneurisation et la tendance au « serverless » sont une réalité, et si tous les acteurs n’ont pas nécessairement besoin ou envie d’y passer, il est impossible de ne pas au moins s’armer un minimum avant que ça ne vous tombe dessus. C’est d’autant plus vrai quand Amazon annonce que Kubernetes, qui est un orchestrateur « concurrent » de Swarm libéré par Google, qui est exploité sur sa plateforme Google Cloud Engine, sera également proposé en tant que service, en plus de l’offre maison Elastic Container Service.

D’ailleurs, Kubernetes sera certainement ma prochaine montagne. Beaucoup de concepts de clustering sont communs avec Swarm, il n’est donc pas illogique de s’y intéresser également, surtout quand on sait que c’est l’orchestrateur majoritaire sur le « marché » (si tant est qu’on peut parler de marché dans un contexte où ils sont majoritairement gratuits et open-source).

On veut les fichiers !

Il va falloir patienter un peu pour voir tout ou partie de ce que j’ai pu écrire pour terminer ce déploiement. Si les infos de connexion à l’API sont dans un fichier à part qui se trouve dans le gitignore du dépôt, les informations liées à la zone DNS, à l’identifiant de l’entrée, la gestion de la liste d’IP du cluster, tout ça est codé en dur dans le script python, et tout le monde conviendra que c’est très sale. Le boulot n’est donc pas encore complètement terminé, mais ça concerne principalement le fait de faire les choses proprement. Idem pour la définition de la stack, il faudra variabiliser l’adresse du registry pour l’image correspondant au script. A moins que je ne choisisse de faire construire l’image à la volée, mais ça me semble un peu plus compliqué à faire. Rien que lors de la finalisation de l’écriture de ce billet sacrément long, en testant une panne d’un nœud, j’ai découvert un problème avec la façon sommaire que j’utilisais pour récupérer le nœud qui héberge le service gogs, et j’ai déjà du refaire l’image et redéployer; ça m’a permis d’ailleurs d’apprendre à me servir correctement des tags, même quand on pensait avoir suffisamment appris, ça ne s’arrête jamais…

Surtout que dans l’absolu, je n’ai rien révolutionné non plus : un Dockerfile est un Dockerfile, un fichier docker-stack.yml est… enfin bref, vous avez compris. Dans l’esprit et au final, je vais tout partager, mais il faut d’abord que ça ressemble à quelque chose de potable et de réutilisable à peu de frais pour vous. Et là dans l’immédiat, j’ai mes dépôts à recréer et re-remplir 🙂

UPDATE : le dépôt est disponible à l’adresse suivante 😉

Ce dont j’ai besoin pour mon prochain smartphone

samedi 2 décembre 2017 à 10:30

Mon OnePlus X commence à présenter de plus en plus de problèmes, après seulement deux ans de bons et loyaux services (dans l’ensemble). Reboots intempestifs, pertes d’associations Bluetooth, mise en veille du réseau incontrôlable, absence de mise à jour de OnePlus (j’attends pas Android 7 parce qu’on sait que Qualcomm est un enfoiré, mais au moins les maj de sécurité sur Android 6, c’est pas la mer à boire)… Bref, il est temps d’envisager de changer de crèmerie. Et de regarder quels sont pour moi les points déterminants pour un smartphone qui va me faire, au minimum, les deux prochaines années. En espérant que ça vous donne une idée des bonnes questions à se poser, au delà du prix.

L’indépendance à l’opérateur

J’entends par là qu’il n’est pas question de passer par un opérateur pour payer mon téléphone. Parce que systématiquement les smartphones vendus par les opérateurs :

Alors certes, ça pourra paraître plus cher, mais je vous assure que sur le long terme, vous êtes gagnant à rester indépendant de votre opérateur. Et ça quel que soit le forfait que vous avez souscrit.

Surtout qu’il n’est pas rare de pouvoir payer en plusieurs fois maintenant, notamment en ligne, et même maintenant sur Amazon.

Une version d’Android pratiquement pure, et surtout à jour

Ça c’est plus personnel qu’autre chose, parce que l’interface Material Design d’Android me convient parfaitement, mais il y a un autre objectif derrière : un fabricant qui ne modifie rien ou presque pourra plus facilement mettre à jour le téléphone. J’ai déjà pu indiquer que la sécurité devait devenir une priorité pour tout le monde, alors favoriser un fabricant bon élève me semble un bon comportement.

Évidemment, si un constructeur sait tenir la distance avec sa propre surcouche, comme Samsung le fait avec certains des modèles qu’il commercialise, je ne suis pas si sectaire, comme on le verra quand j’aborderai à la fin du billet les modèles que j’ai en vue.

J’ai une préférence toute particulière pour la dernière release, 8.0, qui a permis à Google de revoir profondément l’organisation d’Android, avec Treble, pour pouvoir plus facilement déployer les mises à jour de sécurité sans pour autant remettre en question les personnalisations des constructeurs, et sans avoir à régénérer une image à jour à flasher sur l’appareil (que ce soit via OTA ou USB). Il est cependant très peu présent, même les nouveaux modèles sortent encore au mieux en Android 7.x avec, pour certains, un plan de mise à jour vers Android 8, malheureusement parfois sans Treble, donc il faut que je reste vigilant.

Écran : pas plus de 5 pouces, mais Full HD obligatoire

Je parle de l’écran, mais c’est plus le form factor qui compte, j’ai beau avoir de grandes mains j’aime bien finalement mon téléphone, sa taille est parfaite, je peu l’utiliser à une seule main. Avec la mode grandissante des « borderless », les tailles d’écran augmentent sans que l’appareil grandisse d’autant.

Je n’ai pas trop de contraintes quant à la technologie, même si l’AMOLED permet de limiter sa consommation, par contre, la résolution, je ne reviendrais pas sur le Full HD, c’est vraiment confortable quand on lit beaucoup dessus.

Une batterie au top

Je n’ai pas nécessairement besoin d’un ultra foudre de guerre, ce qui compte c’est l’autonomie. J’ai de plus en plus de mal à finir la journée sans avoir à rebrancher mon téléphone à peine rentré du travail, et ça seulement avec VLC+Firefox, quand j’écoute de la musique en lisant les infos (dans le RER entre autres). Avec le Bluetooth activé en permanence, j’avais déjà déterminé que la consommation supplémentaire était négligeable.

Je n’attend donc pas de miracles, les fabricants continuent de vouloir jouer au jeu du kikalaplugross pour faire plaisir aux développeurs feignants qui ne veulent pas faire d’effort sur la légèreté de leurs applications (Facebook lui-même recommandait à un moment d’utiliser la version web mobile du site plutôt que l’application à cause de sa consommation…), mais un peu plus d’une journée d’autonomie ça sera appréciable.

Une prise Jack, please

J’ai déjà un casque Bluetooth à pas cher, très peu endurant, et mon seul achat pour le black friday est un casque Bluetooth qui couvre mieux et tiens plus longtemps la charge. Il n’est donc pas question de râler parce que mon matériel actuel ne servira plus, surtout qu’on a encore des prises Jack sur les ordinateurs. Mais une grande partie de ma musique est au format FLAC (j’achète de plus en plus sur BandCamp), et une musique au tel format ne s’apprécie qu’avec une bonne transmission du son aux écouteurs. Hors, actuellement le protocole AD2P qui est utilisé pour transmettre l’audio via Bluetooth n’est pas adapté à une telle qualité. En effet, il compresse le son de manière destructive, une nécessité pour le faible débit de la transmission sans fil, et on trouve certains casques qui tentent de « restaurer » une information détruite, en croisant les doigts pour que le son ne soit pas trop distordu.

Donc non, pour écouter correctement de la musique au format FLAC, le moins destructeur est encore une connexion Jack, en attendant un nouveau protocole moins destructif pour une version future du Bluetooth.

MicroSD, of course

Avec la connerie française de la redevance pour copie privée, intégrer une grande quantité de stockage dans un smartphone coûte un bras, qui va dans des poches depuis longtemps loin d’être propres. Ce n’est pas un problème franco-français ceci dit, mais rien qu’en Europe on est les champions. En plus de ça, pour les données importantes, je préfère que le stockage soit portable, et rien de tel pour ça qu’une carte SD.

Le seul hic dans l’histoire, c’est que souvent, ça implique qu’un smartphone capable de faire du dual SIM perd cette capacité, le deuxième emplacement étant à double emploi, mais un seul à la fois. Et je n’exclue pas de tester plus sérieusement Free Mobile avant pourquoi pas de basculer dessus (la grosse quantité de data, illimitée en l’occurrence étant déjà abonné Free ADSL, étant d’un grand secours chez ma mère).

Photo, empreinte, NFC, USB-C ?

Le capteur photo du OnePlus X n’est pas dénué de qualités, mais il est vite mis en défaut sur une luminosité un peu faible, et l’autofocus est un peu lent à la détente. Et ces défauts s’applique aussi à la capture vidéo. Et en deux ans, on a fait pas mal de progrès, il ne devrait donc pas être compliqué de trouver un remplaçant potable.

J’ai encore un peu de mal à considérer l’utilisation d’un lecteur d’empreinte, autant on peut changer un mot de passe si on se le fait déplomber, autant je compte pas me couper les doigts pour changer d’empreintes. Donc c’est pas une priorité, ni un manque si je n’en ai pas.

Et si vous n’avez pas encore lu ou entendu mon sentiment à propos du NFC, sachez que j’abhorre notamment l’utilisation qu’on en a fait sur les cartes bancaires désormais en circulation. Et je n’ai pas envie de filer 30% de mes transactions à Google, Samsung et compagnie. Donc tant qu’on peut désactiver la fonctionnalité, c’est pas un énorme problème si y’a du sans contact d’embarqué.

Un truc qu’il faut savoir, c’est que l’intérêt de l’USB-C réside surtout dans le protocole USB 3.x qui est derrière, mais pour lequel on n’avait pas pu adapter la connectique micro-usb classique. On a donc droit à une plus grande vitesse de transfert entre l’appareil et l’ordinateur en USB, ainsi qu’une charge plus rapide, l’USB 3.x permettant d’aller au-delà de l’USB 2 en matière de puissance délivrée. Donc je cracherai pas dessus si j’en ai.

Quels sont les candidats au final ?

Un des plus évidents, c’est le Google Pixel 2, mais il cumule quelques gros points faibles, comme une batterie faiblarde par rapport à la puissance embarquée, un prix assez élevé, et surtout, il n’est pas vendu en France. Et vu le bordel pour en faire importer un, ce n’est pas mon préféré. Mais si vous avez le budget c’est un concurrent sérieux.

Il y a aussi le Motorola G5 Plus. Certes son design n’est pas le plus sexy du monde, mais la fiche technique est séduisante, surtout mis en face de son prix qui est très intéressant, et Motorola a une tradition de soutenir ses téléphones particulièrement longtemps par rapport aux autres concurrents. Toujours chez Moto, le Z2 Play est intéressant, bien qu’il soit un peu plus grand que son cousin, et inévitablement plus cher.

Plus récemment, je me suis intéressé à la fiche technique du Galaxy A5 2017, qui est très intéressante, et qui va bénéficier sous peu d’Android 8. Sur le papier, De plus, Samsung a un historique assez sympathique quant à l’ouverture de ses téléphones, il sera donc possible de le faire vivre bien plus longtemps que prévu. C’est probablement le client le plus intéressant de ce panel, il est assez agréable à l’œil en plus.

Dans les candidats moins évidents mais peut-être pertinents, j’inclurai le Honor 9, même si je suis un peu rebuté par la surcouche et un support des fréquences 4G incomplet pour les bandes exploitées en France (je pense notamment à la toute récente addition des 700Mhz, très pratique pour les intérieurs bétonnés). Il reste un peu au dessus du budget que je compte mettre dans l’appareil (aux alentours de 300 balles), mais au détour d’une bonne affaire, qui sait…

Un dernier appareil sur lequel je ne m’étais que peu penché étant donné son prix à la sortie est le LG G6, mais récemment, sa forte baisse de prix l’a remis dans la compétition personnelle. Il est en effet facile de le trouver dans les 400€ (il vous en coûtait 700 à sa sortie), son seul point faible qui pourra freiner son évolutivité est la connerie habituelle de Qualcomm d’abandonner ses puces les plus anciennes, un tour qui m’est déjà arrivé avec le OnePlux X dont la puce de 2014 est déjà abandonnée par son fabricant. De plus il est encore sous Android 7.0, et si à priori il passera sous Android 8, LG n’a rien communiqué de précis sur le sujet.

Ce dernier est probablement le plus sexy de tous les modèles présents, malgré le dépassement de budget. A priori j’attendrai début d’année 2018 pour changer de bidule, d’ici là, on aura probablement de nouveaux modèles annoncés, certains pourraient également se démarquer. Donc cette liste n’est pas définitive. En tout cas, j’espère vous avoir montré que les choix d’un appareil ne doivent surtout pas se limiter au budget et à l’apparence, mais également à son usage et sa pérennité. Car si vos appareils sont de plus en plus « intelligents », ce n’est pas une raison pour que vous deveniez de plus ne plus bête.

Alors, le Firefox nouvelle génération, il rocks ou il rocks ?

jeudi 30 novembre 2017 à 18:30

Comme j’avais d’autres priorités en tête au moment de la sortie du Messie, c’est à dire Firefox 57, j’ai laissé les autres acteurs du Web (blogueurs, sites d’information, etc) vous donner leur vision du navigateur. J’avais aussi envie d’en parler mais reste-t-il quelque chose à en dire, est-ce que ma vision du navigateur en tant que quasi-fanboy est pertinente malgré tout ? J’ai posé la question sur Twitter, en testant pour la première fois les sondages, et vous avez été sans pitié. Essayons donc de voir si je peux faire un exposé cohérent et intéressant du renouveau du panda roux.

Une numéro de version dans la continuité, mais un renouveau presque total

Il y a un an, Mozilla a amorcé une série de travaux devant aboutir au navigateur qui est sorti depuis maintenant presque un mois. Ces travaux sont regroupés sous le terme Quantum. Tout le monde n’en a que pour les extensions, et l’absence d’alternatives pour certaines d’entre elles, mais le changement est bien plus profond que ça, et n’est pas fait juste pour déranger les habitudes.

Il faut en effet se souvenir que Firefox, malgré une amélioration continue depuis sa sortie il y a 13 ans, traînait quelques boulets qu’il était compliqué de détacher de ses chevilles pour qu’il puisse courir de nouveau. En plus de revoir les fondations de fond en comble (couper les jambes qui sont attachées aux boulets et en greffer de nouvelles), ils ont décidé pour l’occasion de tenter un changement de langage de programmation, et Mozilla n’a pas fait les choses à moitié en créant carrément le langage Rust, dont l’objectif est d’apporter, au niveau du langage lui-même, une meilleure sécurité notamment sur la gestion de la mémoire, tout en garantissant un haut niveau de performances,  deux points cruciaux pour un navigateur web de nos jours.

Et tous les composants y sont passés ou vont y passer, du moteur de rendu à l’interface, en passant par l’interpréteur CSS, le moteur JavaScript, extensions… finalement ce qui fait que Firefox est encore Firefox c’est que votre dossier de profil reste le même, avec ses bases sqlite pour les différents paramètres et historiques. Certains des éléments réécrits ont été intégrés au fur et à mesure, c’est ainsi que ça fait plusieurs mois que la lecture des vidéos HTML5 est prise en charge par un composant écrit en Rust. Et vu la différence de performance dès Firefox 56 sur Android (confirmé par un de mes collègues lui aussi utilisateur du navigateur mobile), je soupçonne Mozilla d’avoir intégré d’autres couches dans cette version intermédiaire avant le grand saut.

C’était nécessaire : la sécurité du navigateur commençait à être limite, quand les autres acteurs proposent une mécanique de bac à sable isolant le navigateur du reste du système pour éviter tout intrusion grave. C’est maintenant possible, en lien notamment avec le moteur de rendu, qui est maintenant en plus pleinement capable d’exploiter tous les cœurs de votre CPU grâce à une parallélisation plus grande, donc des performances en hausse, un autre élément sur lequel Firefox était en retard. On note également une plus grande séparation entre processus qui gèrent l’interface et processus qui gèrent les sites contenus dans les onglets, améliorant de fait la stabilité globale du logiciel. Bon ceci dit, je touche du bois dans l’ensemble, ça doit faire 8 ans que je n’ai pas rencontré une grande instabilité sur Firefox.

Nécessairement des pots cassés

Je ne vais pas pleurer sur la disparition des vieux plugins NPAPI, dont la technologie d’interface avec le navigateur remonte au début des années 2000 (correction, c’est encore plus vieux), là où le multicœurs était réservé aux machines extrêmement chères que sont les stations de travail propriétaires ainsi que les supercalculateurs. Seul Flash reste encore supporté car malheureusement, si le grand public pourrait s’en passer, il existe encore trop d’applications pourtant « professionnelles » qui sont codées avec ce framework. Lui aussi j’aimerai le voir crever plus tôt que 2020. Déjà maintenant il est activé à la demande et pas par défaut.

Parmi les reproches que j’ai pu lire le plus, c’est au niveau des extensions qu’on croirait à une vraie catastrophe à entendre les gens. On pouvait s’y attendre, mais tout de même… Si Mozilla avait fait un premier pas vers une rénovation de ses extensions avec JetPack, celui-ci posait beaucoup de problèmes également, aussi bien sur la sécurité que sur la parallélisation. Décision fut prise il y a un an maintenant de passer au format WebExtensions, déjà exploité sur Google Chrome et dérivés. On pourra arguer que Firefox copie encore Chrome, mais le fait est que ce nouveau format basé sur les technologies web permet de réutiliser les composants de rendu du navigateur, et donc de profiter des performances de ceux-ci.

La conséquence cependant, et j’en ai fait personnellement les frais, c’est que certaines capacités que permettaient Jetpack ne sont plus possibles dans WebExtensions, et pour l’instant il n’y a rien à faire pour corriger cet était de fait, bien que les développeurs restent ouverts à certaines adaptations de l’API, ce qui permet à terme de faire plus de choses que chez Chrome. Ajoutez à ça les développeurs d’extensions qui ne ne veulent pas forcément refaire le travail de zéro, et forcément on a l’impression que beaucoup de monde reste sur le carreau. Cependant, Mozilla a quand même eu une ou deux bonnes idées : il y a une section qui regroupe les modules que vous ne pouvez plus utiliser, et propose un bouton pour rechercher des extensions similaires qui pourraient remplir le rôle, avec parfois à la clé de très bonnes surprises.

WebExtensions a même coexisté avec Jetpack pendant plusieurs mois, et les extensions qui deviendraient incompatibles étaient déjà marquées comme obsolètes. Pour ma part j’avais fait le boulot en amont pour m’assurer que je serai tranquille, dans l’ensemble. Malgré tout, parmi les utilisateurs qui n’ont pas eu le réflexe de vérifier ce point, il était inévitable que ça fasse quelques dégâts. Courage Cyrille. Si vous êtes effectivement coincé avec certaines extensions, vous pouvez installer à la place Firefox ESR, qui est encore basé sur Firefox 52, donc pleinement compatible, mais c’est reculer pour mieux sauter, je vous recommande de faire vos recherches et adaptations au plus vite, que ce soit pour vous ou d’autres personnes.

Les thèmes ont également pris un pion dans l’affaire. Pour ma part, j’avais déjà basculé sur le minimal dark que Firefox fournit et continue de fournir (j’aime bien les thèmes sombres), mais certaines personnes ont pu installer des choses plus exotiques (j’ai vu cet été qu’il existait encore un thème « Modern » qui était l’interface de Netscape fin des années 90,et j’utilisais le thème ARC qui n’a pas été maintenu super longtemps). Il n’y a donc plus que les personas qui sont supportées correctement actuellement, en raison d’un autre grand changement de Firefox : Photon.

Une interface plus lumineuse ?

Admirez le jeu de mots pourri, surtout pour un mec qui utilise un thème sombre. Photon est le nom de code de l’interface de Firefox, et elle a elle aussi été complètement revue. Sous le capot, exit XUL qui n’a pas super bien vieilli et qui commençait à ralentir le reste de Firefox et à limiter les possibilités d’évolution. Il y a des points qui me plaisent bien, comme un retour à des onglets qui ne ressemblent pas à ceux de Chrome (les détracteurs diront que ce coup-ci c’est Microsoft Edge qui a été copié), la barre d’adresses peut être encore mieux organisée. La nouvelle gestion du panneau latéral ne me fait personnellement ni chaud ni froid, au bout du deuxième clic j’avais compris, et de toute façon j’utilise tellement les raccourcis claviers que j’ai pas trop senti la différence.

Là où je suis un peu déçu, c’est le menu principal. J’aimais bien les « gros » boutons, le menu était entièrement personnalisable et je n’avais laissé que le strict minimum, et j’avais tendance à faire de même quand je paramétrais Firefox pour quelqu’un. Je ne sais pas ce qui a motivé le passage à un menu plus « chromesque » qui n’a pas beaucoup de charme, et qui est beaucoup plus lourd selon moi.

À gauche FF57, à droite FF56

Fort heureusement, les outils de développement sont toujours là, et fonctionnent toujours aussi bien. Les masochistes qui font du JavaScript auront même droit à un support affiné de certains framework JavaScript comme React (qui reste pourtant à déconseiller quand on voit comment Facebook joue avec la licence).

Quid de la performance et de la consommation ?

C’était l’objectif après tout, alors ? Il y a une réelle évolution dans le ressenti. Je n’ai peut-être pas senti le même effet waouh que certains, notamment parce que je suis actuellement chez ma mère où n’importe quel navigateur doit s’incliner face à une connexion pourrie, mais pour ma part, notamment sur le rendu, ou sur les défilements et interactions sur les pages fortement dynamiques ne soufrent plus de micro-freeze. Je n’ai plus de lag lors de la bascule entre onglets, le chargement des outils de développements est plus rapide, bref, dans l’ensemble vous avez compris, le travail accompli se sent, du moins sur les performances et le ressenti, tout est plus agréable à l’utilisation sur ce navigateur. Les benchmarks qui pullulent confirment globalement cette sensation.

Je n’ai pas encore pu mesurer précisément ce qu’il en est sous Windows, mais sous Linux la consommation de RAM ne me semble pas nécessairement plus faible, c’est peut-être en lien avec les extensions que j’utilise (j’en ai rajouté deux/trois depuis le mois d’Août), ou le fait que le navigateur doit actuellement supporter une trentaine d’onglets ouverts depuis plusieurs jours (la joie de bosser sur des technos qu’on ne connaît pas bien, beaucoup, beaucoup de documentation). Il me semble toutefois que le garbage collector a toujours autant de mal à faire son boulot, quand on l’active manuellement (via about:memory), on gagne facilement plusieurs dizaines de mégaoctets. Il y a encore pas mal de boulot à faire selon moi de ce côté, mais il faut aussi avouer que les sites/applications web sont particulièrement lourds de nos jours, c’est particulièrement pénible d’ailleurs (palme d’or à la console Azure).

Alors ? on vire Chrome ?

Ça fait un bout de temps que je vous dis que Chrome devrait disparaître de pas mal de machines, mais malheureusement, on connaît les méthodes de Google pour s’infiltrer partout. D’autant plus sur mobile qui est plus que jamais le terrain sur lequel on devrait se battre vu l’évolution des usages grand public. Là aussi Firefox a une position compliquée, et son arrivée tardive fait que Chrome a pu régner sans partage pendant trop longtemps, au delà de son installation par défaut, une pratique pour laquelle Microsoft s’était pris des rafales de la part de la justice européenne avec Internet Explorer sous Windows (également avec le lecteur Windows Media). On attend encore un traitement équivalent…

Il y a un autre souci, dont les techniciens sont conscients, et Mozilla devrait d’autant plus chercher à la diminuer, c’est la dépendance à Google : un navigateur qui se présente comme un défenseur de la vie privée qui embarque Google Analytics sur les pages de ses services, ça la fout mal. Je n’ai rien contre une certaine collaboration entre éditeurs, c’est même une très bonne chose selon moi, mais la liste safe-browsing, qui permet de marquer et d’alerter les visiteurs à propos de sites malveillants, est elle aussi hébergée chez Google, et chaque récupération de la liste doit certainement s’accompagner d’un enregistrement chez eux, comme s’ils n’avaient pas déjà suffisamment d’informations sur le monde entier.

Je n’ai pas de problème à faire la promotion de Firefox malgré ce paradoxe, parce que j’aime le logiciel et son positionnement, et pas seulement « par défaut » comme le pense Cyrille Borne, parce qu’il n’existe rien d’autre en dehors de la « galaxie webkit/blink » (et c’est en grande partie vrai). Mais certains pourraient également se ranger se son côté si le comportement était un peu plus cohérent.

Ce n’est qu’un début

La refondation de Firefox était nécessaire, et Mozilla ne compte pas s’arrêter là : par exemple, il y a plein d’avantages à tirer parti des solutions graphiques pour plusieurs tâches (même les solutions intégrées), et la version 59 doit introduire WebRender qui permet justement d’exploiter nos GPUs. Non seulement on pourrait encore espérer un gain en réactivité, mais également, sur les machines mobiles, de consommation, certaines opérations étant plus efficaces sur un GPU qu’un CPU.

Il y a également d’autres évolutions en cours notamment en rapport avec le ciblage de votre activité, un des combats de la protection de la vie privée, qui est d’ores-et-déjà compliquée par l’introduction d’une fonctionnalité héritée du Tor browser, qui se base sur Firefox, et qui empêche un site d’exploiter le contenu d’un cookie créé par un autre domaine (ce qui est notamment le cas avec la publicité). Bref, la fin de ce gros chantier ne marque absolument pas le début d’une pause, parce que les artisans d’une société de surveillance de masse et de profilage continuent eux d’affûter leurs armes pour détruire ce qui vous reste d’intimité et de vie privée. Et un bon comportement ne suffira pas si l’on ne dispose pas des outils et services permettant de se sentir en sécurité, et en qui on peut avoir confiance.

Causons un peu de ma santé, je vais bien (mais ça fait mal)

mardi 28 novembre 2017 à 18:30

Je tiens d’abord à vous remercier pour tous vos messages de soutien, et de rétablissement après l’opération, ça fait chaud à mon petit cœur 🙂 Pour ceux qui vivent dans une grotte ou qui viennent pour la première fois sur le blog, je me suis fait opérer ce vendredi 24 Novembre (une veille d’Ubuntu Party…) pour corriger une hernie inguinale. L’occasion, maintenant que c’est confirmé que je vais survivre, de vous détailler un peu comment ça s’est déroulé. Non pas de photos dégueu, désolé pour les tordus 😀

Un planning respecté, c’est cool

Ce qu’il y a de plus frustrant quand on se rend à l’hôpital (à la clinique en l’occurrence), c’est l’attente. Pour ma part, j’étais le deuxième sur la liste des interventions prévues pour mon chirurgien, arrivé à 7h l’infirmière me dit que je devrait être opéré à 9h. Ce délai a été respecté, donc attendre pendant plus d’une heure et demi n’était pas un problème. En plus, à part une visite de confirmation tardive de la part du doc le soir, tout s’est finalement déroulé comme prévu (environ une heure d’opération, un poil plus long en définitive mais rien de catastrophique). J’avais beau être calme (13,3 de tension, 37°C de température, check), patienter plus longtemps m’aurait certainement énervé un peu, quand bien même on vous file un « apéro » quand vous arrivez dans la salle de réveil qui sert aussi pour préparer les anesthésies.

Et puis le restant de la journée, une fois revenu dans ma chambre j’avais mon Chromebook et mon smartphone, donc je ne me suis pas vraiment fait chier, d’autant qu’un peu avant d’entrer à l’hopital, je me suis lancé dans un projet lié à mes expérimentations autour de Docker que je vous partagerai quand j’aurai terminé, parce qu’il y a du boulot et que c’est un peu plus compliqué que prévu.

La péridurale, c’est marrant, mais pas tout le temps

Le terme technique, c’est rachianesthésie, pour indiquer qu’on endort tout le bas du corps à partir du nombril. Je suis donc resté réveillé pratiquement toute la journée, enfin presque, j’avais dormi 4h, j’ai quand même fait une sieste dans l’après-midi parce que j’étais claqué. Oui, on m’a opéré le ventre et j’étais réveillé. Mais pas de bol, j’ai rien pu voir (ma curiosité, que voulez-vous).

Sur le coup, à peine 10 minutes après la piqûre, on a l’impression de vous avoir coulé du béton dans les jambes. C’est la seule sensation qu’il vous reste, et quand ça arrive, il faut avouer que c’est pas très agréable. On a certes l’impression que les jambes sont restées dans la position où elles étaient, mais pendant l’opération je ne sentais rien de rien, donc pas évident de savoir si elles ont été manipulées.

Le côté marrant, c’est quand ça commence à revenir. On essaie désespérément de bouger, d’abord les orteils, qui effectivement sont les premiers à revenir. J’ai tout de suite pensé à Beatrix Kiddo pendant son évasion de l’hôpital après sa sortie de coma. Sauf que vous le voyez bouger (trembler serait plus correct), mais vous ne le sentez pas encore vraiment. Vous avez progressivement des fourmis dans les parties qui se réveillent doucement. Quand on commence à pouvoir soulever les jambes, c’est chaotique, on a l’impression de prendre un coup de jus parce que c’est un peu binaire (ça passe ou ça passe pas), on ne contrôle pas la descente, donc ça tombe comme une pierre, mais ça ne fait toujours pas mal.

Une chose à savoir, c’est que l’un des derniers organes à finalement revenir, c’est la vessie. Pas de pipi, pas de sortie. Et là je tiens à souligner le pouvoir de l’esprit, parce que par trois fois j’ai tenté dans le courant de l’après-midi d’y aller, pensant que ça allait couler tout seul, et finalement c’est le bruit de l’eau du lavabo coulant à côté qui a permis de débloquer définitivement la situation. Ne jamais sous-estimer son cerveau donc, même le mien dans son état actuel. Et donc, en termes de sensations, ça a commencé à revenir des pieds au nombril, et encore, une fois sorti j’étais encore un peu engourdi au niveau des fesses, faut dire que j’avais presque littéralement passé la journée dessus.

Une convalescence qui risque d’être plutôt longue

Autant le dire d’emblée, même avec les anti-douleurs qui m’ont été prescrits (Monoalgic+Dafalgan), je douille. Je dois doser chaque mouvement, et finalement, il n’y a qu’en position quasi-allongée que je ne sens pratiquement rien, car rien ne vient pousser sur la cicatrice, qu’elle soit externe ou interne (on a quand même cousu un filet sur ma paroi abdominale, avec les intestins qui poussent derrière). Tousser est une torture, et du fait de contracter très peu les muscles abdominaux, le transit intestinal est un peu compliqué, alors qu’un des objectifs de l’opération est également de rétablir un peu l’ordre normal des choses.

J’ai deux semaines d’arrêt maladie, mais il y a peu de chances que je puisse reprendre une activité normale dans ce laps de temps. Fort heureusement, j’ai un manager compréhensif, avec qui je suis déjà assuré de pouvoir travailler de chez moi, m’évitant encore un peu les transports en commun si je ne suis pas suffisamment rétabli pour les supporter.

J’ai tout de même un seuil de tolérance à la douleur assez élevé, donc pas la peine d’attendre que je chiale pour un oui ou un non. Mais je vais encore avoir l’air d’un vieil homme usé par les années pendant quelques temps, ce qui fait que je vais vraiment limiter mes mouvements à la portion congrue un bon moment. j’avais dit qu’on se reverrait pas au PSL avant le mois de Février, en fonction de l’évolution c’était pas tant un mensonge que ça. Le chirurgien recommande de ne rien faire de significatif avant au moins deux mois, je vais définitivement lui faire confiance sur ce point.

Bonus : la cicatrice

Allez, on va éviter de balancer ça sur Twitter, voilà donc la fameuse balafre, particulièrement large. Mais propre, donc je vais pas pouvoir parader tel un Martin Riggs face à Lorna Cole, à terme il ne va pas rester grand chose. Et puis c’est assez bas, j’ai beau ne pas être gêné par le fait de me foutre à poil pour exhiber ma blessure de guerre, ça risque de choquer pas mal de gens autour. Alors vous devrez vous contenter de la photo 😛

Mi Band 2 + GadgetBridge, quoi de neuf docteur ?

lundi 27 novembre 2017 à 18:30

Je vous avais en effet présenté il y a quelques semaines une alternative aux applications aspiratrices de données qui accompagnent les bracelets connectés destinés à suivre votre activité physique et pour certains la santé qui va avec (via le sommeil, le rythme cardiaque, etc). J’avais alors indiqué qu’il fallait que je vous fasse un retour après une utilisation plus prolongée, ce qui tombe bien puisqu’il ne quitte plus mon bras ou presque.

Par quoi commencer ? Batterie toujours au top, 3 semaines alors que depuis pour améliorer la précision du sommeil j’ai activé l’option capteur cardiaque. Il prend donc à intervalle plus ou moins régulier une mesure du rythme. Je vais vous faire un paragraphe dédié à la précision d’une manière globale parce que c’est…

Notifications : je peux plus m’en passer

Ne pas sentir son téléphone vibrer dans sa propre poche et rater un appel ou un SMS important est frustrant. Ici, pratiquement plus de problème, sauf quand on a déjà les deux mains prises évidemment. Les icônes et le texte ne sont pas parfaits, mais ça donne déjà une petite idée de l’application concernée, on gère mieux les priorités.

Si vous avez l’esprit tordu, vous pouvez être connecté à un salon sur Telegram avec des pipelettes et vous en servir comme vibro masseur, parce qu’il vibre sacrément bien, pour dire j’ai réussi à l’entendre vibrer loin de mon poignet alors qu’il était plus éloigné que mon téléphone, que j’ai dû chercher des yeux.

Petite bonne surprise, depuis le début de l’écriture de ce brouillon une mise à jour permet maintenant d’afficher l’icône de l’application plutôt qu’une icône générique. C’est encore plus facile pour prioriser les réponses.

La précision, tout un sujet

J’ai déjà évoqué quelques points mais on va rentrer un peu plus en détail. La lecture cardiaque est complètement aux fraises, à me donner des valeurs beaucoup trop basses quand je suis en plein effort ou trop haute quand je suis allongé dans mon canapé. L’irrégularité des mesures prises pendant le sommeil confirme ce point.

Pire, alors que j’ai activé la lecture cardiaque pour soit disant améliorer la précision du sommeil, je suis surpris de découvrir parfois que je dors d’un sommeil profond alors que je suis sous la douche avec le bracelet posé sur le bureau. Si j’avais su plus tôt que j’avais un don d’ubiquité, il ne me reste plus qu’à savoir comment avoir deux moi éveillés pour abattre tout le boulot que j’ai en ce moment.

Je ne vais pas m’étendre sur la précision des mouvements, rien n’a changé de ce côté là, le firmware est exactement le même depuis le début de mon utilisation, le support des firmware plus récents ne semble pas avoir trop bougé du côté de GadgetBridge. On détecte malgré tout les différences entre les périodes assis derrière un bureau et mouvement. Par contre en me penchant un peu plus sur la lecture des pas on se rend compte qu’il fait bien la différence avec tous les mouvements même si ce n’est pas parfait.

Une appli qui évolue en douceur

Plusieurs mises à jour de l’application se sont succédées au fil des semaines, et si l’interface n’a que très peu évolué, certaines petites retouches comme le dessin du rythme cardiaque ou des corrections de bugs mineurs sont toujours plaisants. Je n’ai pas grand chose à dire ou redire de la stabilité, à part que de manière erratique le bracelet se déconnecte. Ça peut aussi bien être un problème avec le bracelet que le téléphone, j’ai déjà un comportement étrange sur la partie 4g/wifi que je n’ai jamais réussi à corriger. Le phénomène s’est amplifié ces derniers temps, mais c’est de manière erratique.

mon sommeil, tout un problème…

Les plus gros ajouts finalement résident dans l’amélioration de la gestion des mises à jour de firmware et le support de nouveaux appareils, avec l’arrivée notamment de l’Amazfit bip, de Xiaomi toujours, qui semble un peu plus haut de gamme, et je m’y intéresserai peut-être même s’il est plus moche que ce bête mi Band (ressemble un peu beaucoup à une Apple Watch, mais bon…). D’autres appareils sont également concernés, donc à voir.

Solidité relative

Je n’ai pas mis l’étanchéité à l’épreuve, mais j’ai réussi à rayer l’écran, me demandez pas comment. En premier lieu je l’avais pris pour carrément une fêlure. Le bracelet caoutchouc, lui, souffre un peu plus : la bague rigide qui maintient le boîtier en place s’est décollé d’un côté, à cause de la tension liée au fait que parfois le bracelet glisse un peu et le boîtier est poussé vers l’extérieur par mes os.

Va falloir un point de colle

Visualisation : Grafana ?

Je l’avais évoqué, la base de données est exportable au format sqlite, et donc on peut procéder derrière à ses propres analyses. Un point pratique si je veux corriger les mesures de sommeil. Pour visualiser mieux, je voulais passer par Grafana que vous connaissez déjà si vous traînez dans le coin depuis un bon moment. La sélection de la source m’a cependant posé problème, car si Grafana stocke ses paramètres dans une base sqlite, il est incapable d’exploiter ce format en tant que « data source ». La magie des développeurs, qui préfèrent plutôt vous ajouter moults plugins de services en ligne non libres, mais disposant d’une API. Il va donc falloir étudier des alternatives.

L’aventure objet connecté continuera donc, mais je changerai certainement d’appareil, en fonction de ce que GadgetBridge cependant. Je n’ai malheureusement pas le niveau pour les aider à améliorer le support et les fonctionnalités liées au matériel, mais je trouverais bien un moyen de contribuer.