PROJET AUTOBLOG


le hollandais volant

Site original : le hollandais volant

⇐ retour index

Vivaldi après 1 mois… Retour sous Firefox

dimanche 20 juin 2021 à 15:45

i
Ça fait quelques semaines que j’utilise Vivaldi en navigateur principal sur mon ordi.

J’avais changé, car j’étais lassé de Firefox et quelques-unes de ses options qui partent, viennent, repartent, et de divers choix incompréhensibles faites par Mozilla sur ce navigateur, et dans l’espoir de trouver une solution plus « future-proof » que Firefox qui est virtuellement mourant et que Mozilla considère comme un fardeau plutôt qu’un fer de lance.

Vivaldi n’est pas officiellement libre, mais tous leurs composants le sont, même si en partie c’est porté par Google.
Vivaldi est le navigateur plein d’options pratique et qui reste utilisable. Du génie. Je n’ai rien à reprocher au travail que Vivaldi a fait avec ce navigateur : il est complet et pratique.

Juste un truc.
Blink.

Blink c’est le moteur de rendu (à l’origine un fork de Webkit) : le sous-programme du navigateur responsable de l’affichage des pages. C’est le même moteur de rendu que Chrome, Edgium, Chromium, Opera…

Ce qui différencie ces navigateurs, c’est tout le reste qui n’est pas le moteur de rendu, c’est-à-dire la partie visible du navigateur (menus, disposition, couleurs…).

Or :
Blink est lent.
Blink est mauvais.
Blink est lourd.
Mais Blink est utilisé par 80 % des navigateurs.

En bref, Blink c’est le nouveau IE6.

Pour l’affichage des pages, Firefox est plus fidèle aux standards.
Pour l’exécution des programmes web, Firefox est plus rapide.
Pour la gestion des ressources, Firefox est moins gourmand.

Firefox n’utilise pas Blink, mais Gecko/Servo (projet Quantum). Ce moteur est rapide, efficace, léger. Y a pas à dire. Ça n’a plus rien à voir avec le Firefox de 2015 où c’était un gros patapouf hyper-lent.

À ce jour, c’est la seule alternative au monstre Blink. Et c’est bien dommage, car même Mozilla semble délaisser le truc pour se lancer dans ses projets commerciaux (à coup de licenciements et plans de restructuration).

À l’époque d’Opera 12 (ancêtre spirituel de Vivaldi), Opera n’utilisait pas Blink/Webkit mais leur propre moteur de rendu : Presto. Il était plus rapide que Gecko et Webkit, mais Opera l’a laissé tomber pour se tourner vers Webkit (devenu Blink ensuite).

Quand Vivaldi est né, quelque temps après, ils ont fait le choix de prendre Blink et non Gecko.
Je ne suis pas là pour dire qu’il s’agisse d’une erreur, mais pour moi, ça reste un défaut et un reproche technique.

Après un mois sous Vivaldi, je le vois tous les jours : un clic droit dans un champ texte sous Vivaldi prend plusieurs secondes (c’est instantané sous Firefox). Les outils de dév sont bien plus complets et orientés utilisateur dans Firefox que dans Blink. Les éléments d’interface (input number/date/…) sont mieux pensés dans Firefox que dans Vivaldi/Chrome. Sans compter l’affichage des pages, les rendus graphiques…

Bref, Vivaldi est bon, vraiment très bon…
… si vous venez de Chrome/Opera/Edgium. Vraiment : essayez-le, vous ne verrez pas ces défauts et vous aurez un navigateur mieux foutu et mieux pour votre vie privée.

Mais si vous arrivez de Firefox, vous aurez un truc plus lent, plus lourd et les contrôles dans les pages seront ce que Firefox avait il y a 10 ans.

Si vous êtes web-dév, oubliez les outils de dév de Chrome/Vivaldi/Blink : c’est de la vraie merde. Ceux de Firefox sont plus complets, plus pratiques, même si un point plus bugué.


@Vivaldi : le jour où vous passez de Blink à Gecko, vous aurez le meilleur navigateur du monde.
En attendant, vous avez la meilleure interface avec le pire moteur de rendu.


ÉDIT : je dis bien qu’ici tout ça concerne mon ressenti après une utilisation représentative de mon usage, avec les modules, ma configuration… bref, des conditions réelles ; soit tout le contraire d’une « fresh-install » habituellement utilisée lors des benchmark et des tests journalistiques.

Ah et aussi sous Linux (Linux Mint).

TousAnti-TousAntiCovid !

mercredi 9 juin 2021 à 18:26

Imposer un mouchard gouvernemental et rentabiliser ça, en 7 étapes, sous couvert de crise sanitaire et « pour notre bien ».

Étape 1

Gouvernement : “Faisons une application anonymisée qui regarde si l’on a croisé quelqu’un touché par le Covid. Ça n’enregistre rien, juste le fait que le porteur de l’appli ait ou non eu le virus. L’ensemble est centralisé pour coordonner les notifications”

Les geeks paranos : “Mouais, ok.”

La CNIL : *Zzzz… Zzzz…*

Étape 2

Gouvernement : “En fait, regardez, vous pouvez faire vos attestations avec l’application. Faut juste mettre votre nom, votre adresse, etc.”

Les geeks paranos : “C’est bon, je désinstalle.”

Les gens : “rhoo, tu vois le mal partout.”

La CNIL : Zzzzzzzzzz… Zzzz…*

Étape 3

Gouvernement : “et on va inclure un QRCode nominatif, en clair dedans. Il sera scannable avec une autre appli privatrice.”

Les geeks paranos : “Heu… c’est normal que l’autre appli ait besoin du réseau ? Et fasse des requêtes qui incluent les coordonnées GPS ? C’est chelou, ça sera sans moi.”

Les gens : “oh, les restos sont ouverts ! Serveur, une bière s’il vous plaît !”

La CNIL : Zblblbl…*

(source)

Étape 4

Gouvernement : “En fait, ça serait bien que nos appli récoltaient toutes les données sur tous les téléphones, pour pouvoir cibler les personnes fragiles.”

Les geeks paranos : “vous voulez siphonner tous les téléphones, en fait, maintenant que l’appli est installée partout ?”

Les gens : “Serveur, une autre bière !”

La CNIL : *Zzzzzz*

(source)

Étape 5

Gouvernement : “L’appli est désormais obligatoire pour faire vos courses, c’est pour votre bien. Et vous scannerez le ticket de caisse en sortie avec l’appli.”


Les geeks paranos : “Ah carrément ? Et si j’ai pas de téléphone ?”

Les gens : “Tout le monde a un téléphone, fais pas le con !”

La CNIL : *a fusionné avec le CSA*

Étape 6

Gouvernement : “Qu’est-ce qu’on va bien pouvoir faire de ces données ? On pourrait les vendre !”

VOUS ÊTES ICI ↑ (mis à jour le 23/08)
Les geeks paranos : “comme les anglais ?”

Les gens : “Osef, j’ai rien à cacher.”

Le CSA : “$$$”

(source)
(source, pour la France, le début en tout cas)

Nouvelles de oText (built 2021-05)

lundi 10 mai 2021 à 06:04

Capture d’écran de oText.

Présentation

oText, c’est le programme « maison » que j’utilise pour publier des articles sur ce blog.

Depuis longtemps, il s’agit d’un peu plus qu’un simple moteur de blog, puisqu’il me permet également de partager mes liens « au fil du web », d’envoyer des fichiers sur mon serveur, de suivre mes flux RSS, d’avoir un moyen de prise de notes (façon Google Keep), de gérer un agenda, et plus…

… le tout sous une même interface de gestion, ce qui était le but visé depuis le début.

Ça ressemble un peu à NextCloud, dit comme ça, mais NextCloud est beaucoup plus complet, avec application mobile, gestion Caldav, CardDav, sondages, formulaires, modules…

Mon outil, en contrepartie du nombre restreint de fonctions, est plus léger (seulement 1,3 Mo, contre 375 Mo pour NextCloud). Il suffit néanmoins si vous voulez simplement un petit script web dans le navigateur. Et c’est mon cas.

Ça fait longtemps que je n’en ai pas parlé ici, mais je considère que cette version est relativement aboutie. Les principales nouveautés concernent un thème admin peaufiné avec un choix clair ou sombre (on peut forcer l’un ou l’autre, ou alors laisser le navigateur choisir en fonction des préférences du système). Le thème public — refait lui aussi — s’adapte par défaut aux paramètres du navigateur de l’internaute.

Comme toujours, l’accent est mis à la fois sur l’UX/UI en material-design, et respect des standards du Web et la légèreté (l’interface en JS reste très rapide), et sur la présence des options les plus utiles sans tout le superflu présent sur d’autres programmes du genre.

Astuce : vu le poids du script (1 Mo), vous pouvez l’installer et l’utiliser comme un lecteur RSS seul, ou pour l’agenda ou les notes seules… bref, en profiter même si vous n’avez pas besoin d’un blog, mais que vous cherchez quelque chose de léger quand-même.

Téléchargement

Fichier 7z : otext.7z

Taille : 408 967 octets
Sha1 : 8cf6fc8a657ff0e1657e75b3c9d23a2cdecc1ef4

Installation

  1. dézippez le fichier dans un dossier « ./blog »
  2. envoyez ce dossier sur votre serveur
  3. rendez-vous dans le dossier ./blog
  4. suivez les quelques étapes d’installation (création d’un pseudo, d’un mot de passe, etc.)

Captures d’écran

Voir sur le folio.
La capture d’en-tête donne déjà une idée.

Dépendances

Côté serveur :

Modules PHP :

(PDO : pour la base de données ; cURL : pour les flux RSS et pour récupérer les titres des liens ; GD : pour le traitement des images uploadées ; XML : pour le parsage des flux RSS ; ZIP : pour la fonction d’export de les données dans une archive ; MBString : pour un support Unicode étendu)

Côté client :

Défauts et fonctions absentes

Des bugs ? Des suggestions ?

En commentaire ci-dessous.

Par contre, j’ai codé tout ça avant tout pour moi et je le mets en ligne à qui le veut, tel quel, dans l’espoir qu’il puisse être jugé utile à d’autres.

Considérez que ce script a simplement le mérite d’exister et d’être à disposition. Il n’y a pas de support ni de maintenance publique du script. Je n’ai pas le temps (ni l’envie) pour gérer le projet ou de façon plus active.

Si vous voulez une fonction spécifique, je vous conseille de la coder vous-même ou de trouver quelqu’un d’autre que moi pour le faire.

Soutien ?

J’ai eu le cas pour d’autres trucs : si certains se sentent l’envie de payer pour ce script, déjà merci, ensuite veuillez me contacter pour qu’on en discute.

Autre chose ?

Non.

Quelques astuces .htaccess

mardi 4 mai 2021 à 22:18

J’avais déjà fait un article sur ça il y a longtemps, mais là aussi il semble qu’elle ne soit plus au goût du jour.

Après moult tests et quelques surprises, je mets ici quelques snippets de code, pour mémo, surtout pour moi.

Notes :

Notes 2 :
Selon votre fichier et les règles qui s’y trouvent déjà, il peut être nécessaire d’y ajouter (une fois) les instructions suivantes :

RewriteEngine on
RewriteBase /

Je ne les fais pas figurer partout ci-dessous.

Forcer la redirection HTTPS

Les navigateurs le font tout seuls parfois, mais il vaut mieux l’ajouter :

## Force HTTPS
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301]

Supprimer le « www », au début du nom du site

Certains préfèrent le conserver, d’autres non. Dans tous les cas, il est préférable d’avoir un choix et de forcer la redirection de l’une des URL vers l’autre. C’est plus propre et c’est aussi mieux pour le référencement d’avoir une seule URL pour chaque ressource :

## Removes www.
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1%{REQUEST_URI} [R=301]

Supprimer les slashes redondants

J’ai mis du temps à trouver un code qui fonctionne quelle que soit la position des doubles-slashs. Généralement les forums en proposaient plusieurs selon que le slash soit au début, à la fin ou au milieu de l’URL.

## Removes multiple consecutive slashes anywhere in URL
RewriteCond %{THE_REQUEST} \s[^?]*//
RewriteRule ^.*$ /$0 [R=301,NE]

Maintenant, les urls suivantes :

Sont toutes réécrites en :

Supprimer le code derrière le chemin d’un script

## Rewrite ^*.php/*$ to *.php$ (removes anything after a "*.php/")
RewriteCond %{REQUEST_URI} ^(.*)\.php/(.*)$
RewriteRule . %1.php [R=301]

Celui-là est plus compliqué.
Quand on appelle un fichier fichier.php, on en exécute le contenu. Si l’on l’appelle avec un paramètre fichier.php?parametre, c’est toujours le même fichier qui est exécuté, mais maintenant l’exécution tient compte de la valeur du paramètre.

Dans le cas suivant par contre, il y a possibilité de problèmes : fichier.php/.
Le fichier est appelé (et donc exécuté), mais il est traité comme un dossier (car il est suivi d’un slash et non d’un point d’interrogation), et avec lui la notion de profondeur de l’arborescence, etc.
C’est un problème assez sévère et je préfère l’éviter.

J’y vais donc assez lourdement : quand je vois un fichier .php qui est directement suivi d’un slash, on vire tout ce qui suit le slash, incluant ce dernier.

Les urls suivantes :

Sont toutes réécrites en :

Notez que ça ne visera que le script exécuté. Rien n’empêche en effet d’avoir la chaîne « .php » suivi d’un slash dans un paramètre d’un autre fichier php (celui exécuté).
Cette URL ne sera pas modifiée, par exemple : exemple.com/fichier.php?parametre=fichier.php/bla/bla

Supprimer le « index.php » à la fin des URL

## Rewrites "/index.php" to "/"
RewriteCond %{REQUEST_URI} ^(.*)/index\.php$ [NC]
RewriteRule . %1 [R=301,L]

Quand on affiche un dossier sur un site, comme example.com/folder/, le « index.php » ou « index.html » qu’il contient est implicitement affiché. C’est la page par défaut. Le demander de façon explicite est donc généralement inutile.

Afin d’éviter d’avoir des URL redondantes, je préfère ne conserver que les URL sans le « index.php ». Les éventuels paramètres, eux, sont maintenus.

Pour résumer

Avec tout ça, toutes les URL suivantes :

Renvoient toutes sur :

Petite note sur les cascades de fichers .htaccess

On peut mettre un fichier .htaccess dans chaque dossier et leurs sous-dossiers si l’on veut, et les directives seront appliquées à tous les fichiers inclus dans le dossier, y compris leurs sous-dossiers.

Par contre, mettre un RewriteEngine on dans un des sous-dossiers pourra avoir pour effet d’annuler les directives des fichiers situées dans les dossiers parents. C’était le cas chez moi récement, même si je n’ai pas souvenir d’un tel comportement lors de la mise en place de ces fichiers.
Il est possible que ça vienne de la configuration du serveur.

Vivaldi : placer la barre de marque-pages verticalement (méthode 2021)

dimanche 2 mai 2021 à 11:51

Il y a quelques années, j’avais fait un article pour expliquer comment mettre la barre de signets verticalement dans Vivaldi. Cette méthode n’est plus d’actualité et était de toute façon remise à zéro lors des mises à jour du navigateur.

La nouvelle méthode est elle persistante, et même si elle semble similaire, elle utilise des options qui n’étaient pas là dans Vivaldi avant.

Activer les modifs CSS de l’interface

Pour commencer, il faut activer 2-3 trucs dans les options du navigateur, y compris des options expérimentales.

Premièrement, activez les mods CSS. Pour ça, allez sur l’adresse vivaldi://experiments/ puis cochez la case « Allow for using CSS modifications ». Relancez le navigateur.

Rendez-vous ensuite dans les paramètres, et cherchez « CSS ». Vous devez alors voir apparaître une option qui permet de spécifier un dossier :

Paramètre de CSS de Vivaldi
Mettez-y un dossier de votre choix. Je vous conseille de choisir un sous dossier nommé « userChrome » dans le dossier de profil de Vivaldi. Sous GNU/Linux, le dossier de profil se trouve dans ~/.config/vivaldi/.

Ce dossier « userChrome » va contenir des fichiers CSS contenant le code CSS correspondant aux modifs de l’interface du navigateur.

Activer la barre de signets

Ensuite, dans les paramètres, toujours, assurez-vous que la barre de signets soit en haut, que les signets soient affichés sous formes d’icônes seulement :

Afficher les signets sous forme d’icônes.

Utiliser du CSS pour mettre cette barre verticalement sur la droite

Ce que mon code CSS va faire maintenant, c’est :

Le code en question :

/* Bookmarkbar : turning it on the side, placing it on the right */
#app #browser #main .bookmark-bar {
	transform: rotate(90deg) scale(1, 1)!important;
	transform-origin: 0% 0%!important;
	position: relative!important;
	left: 100%;
	height: 34px;
}

/* flip back the individual icons */
#app #browser #main .bookmark-bar button {
	transform: rotate(-90deg)!important;
}

/* gives margins to the main frame */
#app #browser #main .inner {
	margin-right: 35px!important; /* gives place to the new bars position */
	margin-top: -35px!important; /* claims the place from its old position */
}

Ce code est à placer dans un fichier CSS dans le dossier créé précédemment. Donnez-lui le nom que vous voulez ; par exemple « vertical-bookmarks.css ».

Enregistrez ce fichier, puis redémarrez Vivaldi, et la barre devrait être vertical, à droite :

Vivaldi avec la barre de signets à droite.

Quelques notes

Ceci est testé avec Vivaldi 3.7.2218.58 (Stable channel) (64 bits) sous Linux Mint 20.
Le code CSS utilisé est le même que celui de mon astuce d’il y a quelques années.

Vivaldi le dit bien : l’option pour le CSS peut, un jour, être modifié ou retiré. Dans ce cas, ce mod ne fonctionnera plus : la barre de signets sera alors de nouveau en haut, horizontalement. Ça ne sera pas grave (aucune perte de données), mais il faudra alors trouver autre chose.

À l’époque d’Opera, il était possible de mettre la barre de signets verticalement d’une simple option dans les réglages. On peut espérer que cette option revienne un jour dans Vivaldi. En attendant, ce bricolage permet de dépanner.

Toute l’interface de Vivaldi est accessible en CSS. Pour en explorer les éléments, il faut lancer Vivaldi dans un mode spécial, avec la commande vivaldi --debug-packed-apps --silent-debugger-extension-api, et ensuite utiliser les outils de développeurs pour l’explorer et moder ça.