Le site arthur.bebou.netlib.re - retour accueil
git clone git://bebou.netlib.re/arthur.bebou
Log | Files | Refs |
commit 12d3bd5149be90dc0a13b701a9308a67ae42d8e1 parent 5c44ef67b73fdabc47e206d56732c6b20745b39a Auterice: Arthur Pons <arthur.pons@unistra.fr> Date: Sun, 28 Apr 2024 16:12:02 +0200 Article navigation fini ? Diffstat:
| M | contents/navigation/index.sh | | | 215 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------- |
| A | details | | | 8 | ++++++++ |
2 files changed, 173 insertions(+), 50 deletions(-)
diff --git a/contents/navigation/index.sh b/contents/navigation/index.sh @@ -7,7 +7,7 @@ publication: 2024-04-26 sectionmd: main D'expérience, sur un vieil ordinateur, faire tourner un naviguateur web est -l'une des choses "classiques"[^1] les plus gourmandes en mémoire et en calcul. +l'une des choses "classiques" les plus gourmandes en mémoire et en calcul. S'en passer que c'est possible permettrait donc d'allonger la durée de vie de certains terminaux en rendant l'usage du web plus léger. La solution que nous allons documenter par la suite possède d'autres avantages, un peu de niche, @@ -16,51 +16,8 @@ que nous allons expliquer à la fin de l'article. ## Récupérer le contenu d'une page sur le web sans navigateur Les serveurs web écoutent sur internet et répondent à des requêtes http. -Par exemple, en utilisant la commande `nc` pour envoyer des données arbitraires -à un serveur, on peut écrire à la main une requête HTTP et récupérer une page : - - nc bebou.netlib.re 80 - GET /index.html HTTP/1.1 - Host: arthur.bebou.netlib.re - - HTTP/1.1 200 OK - Date: Thu, 25 Apr 2024 09:03:08 GMT - Server: merecat/2.32-rc4 - Last-Modified: Wed, 24 Apr 2024 20:48:32 GMT - Accept-Ranges: bytes - Content-Length: 4485 - Content-Type: text/html; charset=UTF-8 - Cache-Control: max-age=3600 - ETag: "433047229c59ec41e18fdd3d67153f94" - Connection: close - Vary: Accept-Encoding - - <!DOCTYPE html> - <html lang="fr"> - <head> - <title>Unix et environnement ?</title> - [...] - -Nous avons demandé `/index.html` mais nous pourrions demander `/index.md` pour -avoir la même page en markdown : - - - nc bebou.netlib.re 80 - GET /index.html HTTP/1.1 - Host: arthur.bebou.netlib.re - - [...] - - Unix et environnement ? - [Liste des articles au format tsv](http://arthur.bebou.netlib.re/articles.tsv)\ - Chaque page est disponible au format : - - * `.html` - de l'html - * `.sh` - les sources - -Evidemment on ne va pas taper la requête HTTP à la main à chaque fois. C'est -(en partie) pour ça qu'il existe des logiciels dédiés pour faire des requêtes. -`wget` et `curl` en sont deux exemples. Nous allons utiliser `curl` pour la suite. +Pour contruire et envoyer des requêtes HTTP nous pouvons utiliser des logiciels +dédiés tels que `wget` et `curl`. Nous allons utiliser `curl` pour la suite. curl -s arthur.bebou.netlib.re/index.md @@ -72,9 +29,6 @@ Evidemment on ne va pas taper la requête HTTP à la main à chaque fois. C'est * `.sh` - les sources [...] -Sur un raspberry 3b le temps pour récupérer le markdown et l'afficher dans le -terminal est d'environ `0,08s`. Par ailleurs `curl` prend `0,5Mo` sur le disque. - Si l'on veut lire l'article dans un pager ou un éditeur de texte ou peut piper la sortie de curl. @@ -112,7 +66,168 @@ se mettre sur la ligne avec le curl et taper `!!sh` puis faire entrer : l'une des choses "classiques"[^1] les plus gourmandes en mémoire et en calcul. S'en passer que c'est possible permettrait donc d'allonger la durée de vie de +Il est ensuite possible de lire cet article. `u` reviendra en arrière (comme un +`ctrl+z` dans la plupart des logiciels) et permettra de reprendre la lecture +de la première page. Il est clair que cette navigation n'est pas idéale. +Personnellement dans un navigateur classique je préfère ouvrir mes liens +dans un nouvel onglet. Ca tombe bien, vim permet d'ouvrir des fenêtres. +Si vous êtes dans vim vus pouvez lancer la commande `:vne` pour constater +qu'une nouvelle fenêtre verticale s'est ouverte. Si l'on pouvait y lancer notre +commande `curl` nous aurions donc le nouvel article dans une fenêtre séparée. +Pour cela il est possible de d'abord copier le lien, ouvrir la fenêtre, y coller +le lien copier puis finalement y exécuter la commande. Puisque les liens sont entre +parenthèses la commande finale sera : + yi(:vnew<CR>p!!xargs curl -s<CR> -[^1]: sous entendu pas de montage vidéo, de modélisation 3D ou de jeux vidéo aux graphismes 3D endsection + +<<\@ ./details "Explication détaillée de la commande" | save_html main +* `y` pour copier ("yank"), `i` pour "inner", `(` pour le délimiteur. Autrement +dit on copie tout ce qui se trouve à l'intérieur des parenthèses. +* `:vnew<CR>` pour ouvrir une nouvelle fenêtre verticale. `<CR>` permet de +simuler le fait d'appuyer sur la touche entrée. +* `p` pour coller le lien. +* `!!` pour filtrer la ligne courante dans une commande. +* `xargs curl -s`, la commande en question, `xargs` mettra ce qui se trouve +dans stdin (à savoir le lien qu'on vient de coller) en argument de `curl`. +* `<CR>` pour exécuter le tout. +@ + +sectionmd: main + +Il est possible de s'en faire une macro en ajoutant + + map <F6> yi(:vnew<CR>p!!xargs curl -s<CR> + +dans son `.vimrc`. Modifier `<F6>` pour y mettre la touche de son choix. + +Pour le moment cette macro n'est utile que pour ouvrir des documents qui +se lisent bien dans un éditeur de texte. Quant est-il si le lien renvoie +vers une image jpeg ? Pour remédier à ce problème il est possible de créer +un script dédié qui va, sur la base de l'url, déclencher plutôt tel ou +tel comportement. Ce script pourrait s'appeler `plumber.sh` et avoir la +tête suivante : + + case $1 in + *"youtube.com" ) + mpv --save-position-on-quit --ytdl-format="$format" --cache-secs=30 --volume=50 "$1" 2> /dev/null + ;; + *".jpeg" ) + feh -. "$1" + ;; + *".md" ) + curl -Ls "$1" + ;; + esac + +Ainsi si le lien est un lien youtube on lance mpv, si c'est une photo ou +l'ouvre avec feh et si c'est un fichier markdown on utilise directement curl. + +Il faudra modifier la macro en remplaçant `curl -s` par le chemin du script +`plumber.sh`. Ce concept de script agissant sur le contenu textuel ouvert dans +un éditeur de texte (ou plus largement dans la totalité de l'os) est une idée +importante dans le système d'exploitation [plan +9](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) où il porte le nom +de... [plumber](https://en.wikipedia.org/wiki/Plumber_(program)). + +En plus de l'html le site sur lequel vous lisez cet article existe entièrement +en markdown. Essayez de modifier `index.html` en `index.md` (ou de l'ajouter à +la fin) pour vous en convaincre. Cela veut dire que l'on peut le consulter sans +jamais ouvrir un navigateur web, facilitement voir rendant tout simplement +possible la navigation sur du matériel très contraint. + +## Comparatifs + +### Performances + +Tout est mesuré sur un raspberry 3b sur la page de cet article. Les résultats +pourraient être très différents si l'on faisait le comparatif sur un site très +lourd. Ici les écarts sont presque aussi petits que possibles puisque j'essaye +de faire de l'html assez léger. + +| | Nav "sobre" | Nav firefox | +|---|-------------|-------------| +| Taille sur le disque | ~8Mo | 237Mo | +| Temps de chargement d'une page de zéro | < 0,1s | ~ 10s | +| Temps de chargement si firefox ou vim déjà ouvert | < 0,1s | ~ 2s | +| Données téléchargées | 6,26Ko | 14,31Ko | +| Nb requêtes | 1 | 3 | + +Dans un contexte où le stockage serait vraiment contraint il se peut que +firefox soit gros pour l'installer mais si l'on parle de l'impact +environnemental du numérique ce ne sont pas quelques centaines de Mo de +stockage sur une carte SD qui feront vraiment la différence. + +La quantité de données est plus faible côté markdown parce que c'est un langage +avec moins de cérémonie, `# machin` vs `<h1>machin</h1>` et parce que l'on ne +télécharge pas de css. + +Au final c'est, je pense, vraiment le temps d'exécution qui fait une vraie +différence. Je crois me souvenir qu'en moyenne une personne ne tolère que +2/3 secondes de chargement pour une page web avant d'abandonner son chargement. +Avec les 10 secondes à l'ouverture du navigateur et quelques secondes à +l'ouverture d'un onglet et au chargement de la page *dans le meilleur des +cas* on s'approche vraiment de cette limite. Il n'est donc pas déraisonnable +penser qu'une moyenne jugerai la navigation web via firefox sur un rasp non +satisfaisante et serait fortement tentée de changer de matériel. Et pourtant +le rasp est tout à fait capable d'ingérer ces données si on le fait via +une interface différente. + +### Limites + +Évidemment la comparaison a ses limites. L'expérience de navigation dans vim +est peut-être fonctionnelle et, de plusieurs façons, supérieure à l'utilisation +d'un navigateur classique mais n'est certainement pas identique. Exit le css et +une bonne partie de la forme par exemple. Bien que je sois de l'avis que bien +plus de sites devraient être bien plus simples et pouvoir se résumer à du +markdown il est vrai que certains n'auraient pas vraiment de sens sous un +format markdown. + +On hérite aussi des désavantages du markdown, de sa syntaxe parfois limitée et +pas toujours parfaitement agréable à lire tel quel non plus. Par exemple le +petit accordéon que j'utilise dans cet article ne peut pas être fait en +markdown. Résultat ? Le markdown de cette page contient de l'html pour cette +partie là. Je pourrais modifier mon générateur de site pour contourner ce souci +mais au mieux je serai obligé d'intégrer une syntaxe strictement personnelle +annonçant l'existence d'un accordéon qui ne sera pas forcément comprise par +tous·tes et certainement pas par les parsers de markdown. + + +### Autres avantages + +Étant dans un éditeur de texte il est très facile d'enregistrer le document pour +le consulter de façon hors-ligne. C'est également possible de le faire pour un site +web mais l'affordance est moins incitative. + +Il est possible d'écrire directement dans le document pour prendre des notes. Non +seulement on exécute ce que et là où l'on lit mais on y écrit également. vim est +une ui qui permet de fondre ces trois actions en un seul espace. Une conséquence +de cela qui est, pour mes usages, très agréable, est qu'il est possible de suivre +des tutoriels contenant du code en exécutant directement le code dans le document ! +Si le document consulté est par exemple un tutoriel python il y apparaitra probablement +quelque chose comme : + +Pour afficher une chaîne de caractère on peut utiliser la fonction `print` : + + print("Coucou tout le monde !") + +Si je lis ce tuto en markdown dans vim je peux me placer sur cette ligne, taper +`!!python3` et obtenir son résultat dans le buffer vim[^1]. Cela économise des copier +coller mais permet également de modifier et tester la ligne de code directement +dans l'éditeur. Niveau sécurité il est toujours recommandé de *ne pas exécuter sur +votre machine du code que vous ne comprenez pas* mais au moins dans un éditeur de +texte il n'est à priori pas possible de [manipuler ce qui se retrouve dans votre +presse papier](https://research.securitum.com/the-curious-case-of-copy-paste/). + +Pour le shell en particulier suivre un tuto sous cette forme est +particulièrement agréable. Par exemple si un article contient des chemins +bidons partout dans ses exemples vous pouvez faire un remplacement dans tous le +fichier puis `!!sh` les commandes. Par exemple dans cette +[faq](http://bebou.netlib.re/faq/) il est écrit `votre_utilisateurice` partout +où devrait apparaître le nom de votre compte. Si celui-ci est `alice` alors on +peut lancer la commande vim `:%s/votre_utilisateurice/alice/` et suivre le tuto +comme s'il avait été personnalisé pour soi. + +[^1]: en réalité non puisque j'écris les blocs de code avec des tabulations et python n'est donc pas content... + diff --git a/details b/details @@ -0,0 +1,8 @@ +#! /bin/sh + +<<@ cat +<details> + <summary>$1</summary> + $(lowdown) +</details> +@