Mise à jour de la base de données, veuillez patienter...

Cette semaine j’ai installé la dernière version de Resurrection Remix sur mon Galaxy S3.

J’ai fait la totale :

• Resurrection Remix
• Boeffla Kernel
• Xposed Framework
• Tk GAPPS (Édition Pico)

Avec ça le S3 tourne avec la dernière version de Lollipop et il tourne bien.

Enfin… Jusqu’au moment d’installer les appli Facebook et Facebook Messenger où c’est la catastrophe. Son temps de réaction s’effondre et la batterie fond à vue d’œil. J’ai même parfois l’impression que c’est au sens propre tellement le CPU se met à chauffer.

J’avais déjà des soupçons depuis la dernière réinstallation complète de mon téléphone et ce coup ci c’était la goutte de trop et j’ai finalement fait ce que j’aurais du faire depuis longtemps : Je les ai virées.

Facebook t’abuses un peu quand même.

Déjà à l’installation on peut se douter qu’il y a un truc chelou. Parce que les permissions demandées font juste peur.

Ensuite le poids téléchargé est un peu effrayant lui aussi.

Et puis passé le quart d’heure nécessaire à l’installation (véridique) la place occupé sur la partition /data est juste ÉNORME !

C’est lent, ça met des plombes à s’installer, ça pèse une tonne. Est-ce que ça vaut le coup de les garder juste pour avoir de quoi glandouiller dans le bus en allant ou en rentrant du boulot ?

Ben non. Hop, à la benne. Et là miracle : Mon téléphone est rapide à nouveau.

Connaissant Facebook j’imagine sans peine que ses applis écoutent en permanence tout ce qu’elles peuvent et que si ça ne se voit pas trop sur les téléphone récents, quand il commence à faire son âge ça fini par se remarquer.

Heureusement il y a un remplaçant : Face Slim

Face Slim qui porte décidément bien son nom, qui est Libre, disponible sur F-Droid et qui consiste en fait à afficher la version mobile de Facebook dans un navigateur intégré en fournissant aussi un moyen d’être notifié ainsi que quelques raccourcis.

Le fichier d’installation fait 800Ko, installée elle occupe 2,55Mo et elle réagit à la vitesse de la 3G. Juste ce qu’on attend d’une telle appli en fait.

Comme ça je peux laisser libre cours à mes bas instincts et continuer de profiter d’un téléphone rapide.

Résumé des épisodes précédents

Depuis à peu près un an mon code s’écrit dans VIM. Un VIM avec plein de plugins, mais un VIM quand même.

Depuis j’ai installé VIMperator qui permet l’utilisation de Firefox au clavier, VIM-style, je suis passé de XFCE4 à GNOME3 à i3wm et je me tâte sérieusement à installer muttator pour Thunderbird.

Et c’est tellement confortable que je n’arrive juste plus à m’en passer. Qu’on me demande d’utiliser un SublimeText, un IntelliJ ou un Notepad++ et je me met à pester devant tant d’inefficacité.

Ça a l’air un peu prétentieux dit comme ça et je me souviens très bien de ce que je trouve agaçant chez la plupart des évangélistes VIM : Ils oublient très souvent que passer à VIM c’est un investissement conséquent.

Il faut désapprendre à peu près tout ce qu’on sait sur les éditeurs de texte, apprendre une palanquée de raccourcis clavier et supporter d’être parfaitement inefficace pendant des semaines, voire des mois.

Impossible donc de jeter la pierre à celles et ceux qui n’ont pas le temps ou l’envie de s’y mettre.

Mais bref, je suis passé à VIM et je ne peux pas revenir en arrière. Du coup l’écriture d’article dans l’éditeur WordPress je kiffais moyen et j’avais commencé à écrire mes articles dans un fichier .md, des fois synchronisé sur ownCloud, des fois posé un peu n’importe ou sur mon disque dur.

C’était un joyeux bordel et je devais toujours me coltiner le copier-coller dans WordPress. Pour corriger l’orthographe, la grammaire ou réécrire des bouts c’était soit dans l’éditeur, soit à nouveau un copier-coller sur le PC. Bref, c’était chiant.

Et puis j’ai entendu parler de Jekyll qui permet d’écrire son blog en markdown et de générer des fichiers HTML qui vont bien.

Sauf que Aldarone.fr c’est pas juste mon blog, c’est aussi un réseau WordPress multisite qui héberge d’autres blogs, je peux pas simplement virer WordPress pour le remplacer par Jekyll. Il aurait aussi fallu gérer la conservation des URLs et tout. Bref, c’était chiant.

La solution

Heureusement parmi les plugins WordPress il y a à boire et à manger, j’ai donc fini par trouver mon graal : WordPress GitHub Sync

Après la création d’un dépôt dédié sur Github, l’autorisation du plugin à y accéder et à être notifié quand le dépôt change, voila tous mes articles regroupés sur Aldarone/aldarone.fr

À partir de maintenant il me suffit d’enregistrer un fichier .md sur la branche master avec un peu de YAML dans l’en-tête pour définir son titre et son statut de publication pour que ce dernier soit automatiquement créé dans WordPress. De même, à chaque modification depuis l’administration, WPGHS fera un commit dans le dépôt pour répercuter les changements.

Tout n’est pas parfait et à l’heure actuelle je dois encore me rendre dans l’administration pour envoyer les images et gérer les catégories, les tags et l’image d’en tête, mais je vais pas trop me plaindre non plus.

Et qu’est-ce que ça implique ?

Déjà, écrire son blog dans un dépôt Git c’est intéressant en terme de suivi de modifications. C’est en tout cas plus pratique que le système moisi de révisions intégré à WordPress.

En terme de sauvegarde c’est assez chouette aussi puisque tous mes articles depuis le début du blog ont été placés dans le dépôt et les prochains seront eux aussi conservés dans un format facilement exploitable si un jour je change de plateforme.

Enfin, comme le dépôt est public, mes brouillons seront visibles dessus avant publication, je pourrais les faire relire et corriger plus facilement.

Je ne compte pas désactiver le système de tickets ni de pull request donc les lecteurs et lectrices qui savent utiliser GitHub pourront proposer des corrections et modifications très simplement avec une PR, les autres pourront ouvrir un ticket pour signaler les erreurs.

Dans tous les cas, améliorer mon workflow d’écriture m’a donné un petit boost de motivation et je devrais publier plus régulièrement pendant un moment.

À la prochaine !

Résumé des épisodes précédents

Depuis à peu près un an mon code s’écrit dans VIM. Un VIM avec plein de plugins, mais un VIM quand même.

Depuis j’ai installé VIMperator qui permet l’utilisation de Firefox au clavier, VIM-style, je suis passé de XFCE4 à GNOME3 à i3wm et je me tâte sérieusement à installer muttator pour Thunderbird.

Et c’est tellement confortable que je n’arrive juste plus à m’en passer. Qu’on me demande d’utiliser un SublimeText, un IntelliJ ou un Notepad++ et je me met à pester devant tant d’inefficacité.

Ça a l’air un peu prétentieux dit comme ça et je me souviens très bien de ce que je trouve agaçant chez la plupart des évangélistes VIM : Ils oublient très souvent que passer à VIM c’est un investissement conséquent.

Il faut désapprendre à peu près tout ce qu’on sait sur les éditeurs de texte, apprendre une palanquée de raccourcis clavier et supporter d’être parfaitement inefficace pendant des semaines, voire des mois.

Impossible donc de jeter la pierre à celles et ceux qui n’ont pas le temps ou l’envie de s’y mettre.

Mais bref, je suis passé à VIM et je ne peux pas revenir en arrière. Du coup l’écriture d’article dans l’éditeur WordPress je kiffais moyen et j’avais commencé à écrire mes articles dans un fichier .md, des fois synchronisé sur ownCloud, des fois posé un peu n’importe ou sur mon disque dur.

C’était un joyeux bordel et je devais toujours me coltiner le copier-coller dans WordPress. Pour corriger l’orthographe, la grammaire ou réécrire des bouts c’était soit dans l’éditeur, soit à nouveau un copier-coller sur le PC. Bref, c’était chiant.

Et puis j’ai entendu parler de Jekyll qui permet d’écrire son blog en markdown et de générer des fichiers HTML qui vont bien.

Sauf que Aldarone.fr c’est pas juste mon blog, c’est aussi un réseau WordPress multisite qui héberge d’autres blogs, je peux pas simplement virer WordPress pour le remplacer par Jekyll. Il aurait aussi fallu gérer la conservation des URLs et tout. Bref, c’était chiant.

La solution

Heureusement parmi les plugins WordPress il y a à boire et à manger, j’ai donc fini par trouver mon graal : WordPress GitHub Sync

Après la création d’un dépôt dédié sur Github, l’autorisation du plugin à y accéder et à être notifié quand le dépôt change, voila tous mes articles regroupés sur Aldarone/aldarone.fr

À partir de maintenant il me suffit d’enregistrer un fichier .md sur la branche master avec un peu de YAML dans l’en-tête pour définir son titre et son statut de publication pour que ce dernier soit automatiquement créé dans WordPress. De même, à chaque modification depuis l’administration, WPGHS fera un commit dans le dépôt pour répercuter les changements.

Tout n’est pas parfait et à l’heure actuelle je dois encore me rendre dans l’administration pour envoyer les images et gérer les catégories, les tags et l’image d’en tête, mais je vais pas trop me plaindre non plus.

Et qu’est-ce que ça implique ?

Déjà, écrire son blog dans un dépôt Git c’est intéressant en terme de suivi de modifications. C’est en tout cas plus pratique que le système moisi de révisions intégré à WordPress.

En terme de sauvegarde c’est assez chouette aussi puisque tous mes articles depuis le début du blog ont été placés dans le dépôt et les prochains seront eux aussi conservés dans un format facilement exploitable si un jour je change de plateforme.

Enfin, comme le dépôt est public, mes brouillons seront visibles dessus avant publication, je pourrais les faire relire et corriger plus facilement.

Je ne compte pas désactiver le système de tickets ni de pull request donc les lecteurs et lectrices qui savent utiliser GitHub pourront proposer des corrections et modifications très simplement avec une PR, les autres pourront ouvrir un ticket pour signaler les erreurs.

Dans tous les cas, améliorer mon workflow d’écriture m’a donné un petit boost de motivation et je devrais publier plus régulièrement pendant un moment.

À la prochaine !

Résumé des épisodes précédents

Depuis à peu près un an mon code s’écrit dans VIM. Un VIM avec plein de plugins, mais un VIM quand même.

Depuis j’ai installé VIMperator qui permet l’utilisation de Firefox au clavier, VIM-style, je suis passé de XFCE4 à GNOME3 à i3wm et je me tâte sérieusement à installer muttator pour Thunderbird.

Et c’est tellement confortable que je n’arrive juste plus à m’en passer. Qu’on me demande d’utiliser un SublimeText, un IntelliJ ou un Notepad++ et je me met à pester devant tant d’inefficacité.

Ça a l’air un peu prétentieux dit comme ça et je me souviens très bien de ce que je trouve agaçant chez la plupart des évangélistes VIM : Ils oublient très souvent que passer à VIM c’est un investissement conséquent.

Il faut désapprendre à peu près tout ce qu’on sait sur les éditeurs de texte, apprendre une palanquée de raccourcis clavier et supporter d’être parfaitement inefficace pendant des semaines, voire des mois.

Impossible donc de jeter la pierre à celles et ceux qui n’ont pas le temps ou l’envie de s’y mettre.

Mais bref, je suis passé à VIM et je ne peux pas revenir en arrière. Du coup l’écriture d’article dans l’éditeur WordPress je kiffais moyen et j’avais commencé à écrire mes articles dans un fichier .md, des fois synchronisé sur ownCloud, des fois posé un peu n’importe ou sur mon disque dur.

C’était un joyeux bordel et je devais toujours me coltiner le copier-coller dans WordPress. Pour corriger l’orthographe, la grammaire ou réécrire des bouts c’était soit dans l’éditeur, soit à nouveau un copier-coller sur le PC. Bref, c’était chiant.

Et puis j’ai entendu parler de Jekyll qui permet d’écrire son blog en markdown et de générer des fichiers HTML qui vont bien.

Sauf que Aldarone.fr c’est pas juste mon blog, c’est aussi un réseau WordPress multisite qui héberge d’autres blogs, je peux pas simplement virer WordPress pour le remplacer par Jekyll. Il aurait aussi fallu gérer la conservation des URLs et tout. Bref, c’était chiant.

La solution

Heureusement parmi les plugins WordPress il y a à boire et à manger, j’ai donc fini par trouver mon graal : WordPress GitHub Sync

Après la création d’un dépôt dédié sur Github, l’autorisation du plugin à y accéder et à être notifié quand le dépôt change, voila tous mes articles regroupés sur Aldarone/aldarone.fr

À partir de maintenant il me suffit d’enregistrer un fichier .md sur la branche master avec un peu de YAML dans l’en-tête pour définir son titre et son statut de publication pour que ce dernier soit automatiquement créé dans WordPress. De même, à chaque modification depuis l’administration, WPGHS fera un commit dans le dépôt pour répercuter les changements.

Tout n’est pas parfait et à l’heure actuelle je dois encore me rendre dans l’administration pour envoyer les images et gérer les catégories, les tags et l’image d’en tête, mais je vais pas trop me plaindre non plus.

Et qu’est-ce que ça implique ?

Déjà, écrire son blog dans un dépôt Git c’est intéressant en terme de suivi de modifications. C’est en tout cas plus pratique que le système moisi de révisions intégré à WordPress.

En terme de sauvegarde c’est assez chouette aussi puisque tous mes articles depuis le début du blog ont été placés dans le dépôt et les prochains seront eux aussi conservés dans un format facilement exploitable si un jour je change de plateforme.

Enfin, comme le dépôt est public, mes brouillons seront visibles dessus avant publication, je pourrais les faire relire et corriger plus facilement.

Je ne compte pas désactiver le système de tickets ni de pull request donc les lecteurs et lectrices qui savent utiliser GitHub pourront proposer des corrections et modifications très simplement avec une PR, les autres pourront ouvrir un ticket pour signaler les erreurs.

Dans tous les cas, améliorer mon workflow d’écriture m’a donné un petit boost de motivation et je devrais publier plus régulièrement pendant un moment.

À la prochaine !

À la fin de la semaine passée, une nouvelle inquiétante (pour ne pas dire catastrophique) a commencé à se répandre sur les internets :
Mozilla agirait de concert avec les féministes pour faire peser une insupportable censure sur le géant Google.

Voyez plutôt :

Google a annoncé fin septembre, le 22, un nouvel algorithme de compression nommé Brotli, capable d’offrir une compression équivalente à LZMA ou bzip2
pour des performances approchant celles de deflate. Qui dit nouveau format dit également nouvelle extension de fichier, c’est pourquoi, en suivant une convention
aussi vieille que techniquement dépassée, il fut tout naturellement proposé de tronquer le nom de l’algorithme à 3 caractères, donnant ainsi l’extension .bro
aux fichiers compressés par brotli.

C’est là que le bat blesse et que les vilaines féministes entrent en jeu pour exercer une pression terrible sur la personne ayant fait cette proposition,
forçant ainsi le malheureux développeur à s’auto-censurer pour ne pas subir plus de harcèlement de la part de ces furies.

Pour lutter contre la pensée unique qui émane de leur action, je décide ce soir, en dépit des risques, de reproduire ici les vifs échanges ayant eu lieu sur le bugtracker de Mozilla :

1. Jyrki Alakuijala :
   

   In https://datatracker.ietf.org/doc/draft-alakuijala-brotli/ section 12. ‘IANA Considerations’ we are making a reservation for content encoding type ‘bro’, not ‘brotli’.

   We are hoping to establish a file ending .bro for brotli compressed files, a command line tool ‘bro’ for compressing and uncompressing brotli files, and a accept/content encoding type ‘bro’.

   bro is short for brotli — there are no hidden meanings in it, just practicality: less typing, less bytes to upload/download, shorter compressed filenames.

   Dans la section 12 du document « Préparations pour l’IANA » nous réservons le type d’encodage de contenu « bro » et non « brotli »

   Nous espérons fournir une extension en .bro pour les fichiers compressés par brotli, un outil en ligne de commande « bro » pour compresser et décompresser les fichiers brotli, ainsi qu’un type d’encodage « bro »

   Bro est le diminutif de brotli, il n’y a pas de sens caché, jsute de la praticité : Moins de caractères, moins d’octets à envoyer ou recevoir, des noms de fichier plus courts.

2. Patrick McManus :
   

   Thanks for pointing that out jyrki, can I talk you out of it? Certainly not too late to change the draft registration.

   « bro » has a gender problem, even though the dual meaning is unintentional. It comes of misogynistic and unprofessional due to the world it lives in. I received a series of ‘bro’ jokes in response to my posting about this new feature.

   Best to avoid it rather than spending time defending an arbitrary nickname.

   My interest is only in content-encoding interop.

   Merci pour cette précision jyrki, est-ce que je peux rajouter quelque chose ? Il n’est certainement pas trop tard pour modifier le brouillon d’enregistrement.

   « bro » va poser un problème de genre, même si le double sens n’est pas volontaire. Il semble misogyne et peu professionnel en raison du monde dans lequel nous vivons. J’ai déjà reçu une série de « blague de bro » en réponse à mon annonce de cette nouvelle fonctionnalité.

   Il vaut mieux l’éviter plutôt que de perdre du temps à défendre un surnom arbitraire.

   Mon seul intérêt réside dans l’interopérabilité des encodages de contenu.

3. Jyrki Alakuijala :
   

   would you be fine with ‘br’ ?

   Est-ce que « br » conviendrait ?

4. Patrick McManus :
   

   sounds good – thanks. I’ll make that change and let the content-provider I know is working with this know.

   Ça m’a l’air bien, merci. Je vais répercuter ce changement et je vais prévenir les fournisseurs de contenu qui travaillent dessus.

5. Jyrki Alakuijala :
   

   No, thank you for the advice. It is always better to fix things like this as early as possible.

   Non, merci à toi pour le conseil. C’est toujours mieux de corriger ce genre de choses le plus tôt possible.

Quelle pression insupportable pèse sur les épaules de ce malheureux Jyrki.

Un peu de sérieux s’il vous plait.

Depuis cet instant, nous pouvons voir fleurir les articles incendiaires écris par des hommes se sentant menacés par une modification mineure dans un brouillon de spécification.

Sur gHacks on peut ainsi lire :

While it does not really matter in the end if the extension is called bro or br or something else, bro should not be offensive to anyone especially since barely anyone will ever come into contact with it in first place. People who are offended by a file extension, or think others might be offended by it, should get their priorities straight as there are bigger fish to fry.

Dans un même paragraphe, l’auteur est capable d’affirmer que ça n’a aucune espèce d’importance puis de conclure que les féministes devraient revoir leurs priorités. Pourquoi s’affoler, en faire un article et s’opposer de tout son poids contre un changement qui n’aurait pas la moindre importance ?

Du côté de Reddit, ça titre comme ça :

Google removes .bro file extension from project for possibly being offensive and/or misogynistic according to feminists

Alors qu’il s’agit d’une discussion entre deux hommes dont aucun ne déclare spécifiquement qu’ils sont féministes.

Sur Slashdot, on prétend que le sujet fait controverse depuis l’annonce de Brotli :

Several weeks ago, Google launched Brotli, a new open source compression algorithm for the web. Since then, controversy broke out over the choice of ‘bro’ as the content encoding type.

Si on regarde la chronologie des fait, c’est n’est absolument pas le cas :

Brotli a été annoncé le 22 septembre. Le premier commentaire que je cite plus haut a été posté le 05 octobre, la proposition de passer à .br plutôt que .bro a été émise, acceptée et commitée le 06 septembre. Le post sur Slashdot est arrivé le 10 septembre, soit 4 jours après « la bataille »

C’est aussi à partir de ce moment que l’on trouve en trouve des traces sur Reddit et que les commentaires du ticket Bugzilla ainsi que du commit validant la modification commencent à se faire troller.

Qualifier ces évènements de controversés revient à utiliser une définition très particulière du mot « controverse » quand toute cette histoire n’est qu’une discussion sur un coin de table pendant la rédaction d’un brouillon qui a été ensuite montée en épingle par les conservateurs et les réactionnaires. Un cas d’école illustrant parfaitement leur maitrise du FUD et de l’astroturfing.

Je laisserai donc le mot de la fin au développeur qui a effectué la modification :

Even if we don’t understand why people are upset from our cultural standpoint, they would be (unnecessarily) upset and this is enough reason not to use it.

Même si, de notre point de vue culturel, nous ne comprenons pas pourquoi cela dérangerait des gens, illes le seraient sans nécessité et c’est une raison suffisante pour de pas utiliser cette extension.