@bnjbvr - opensource

Une lettre d'amour pour le Zen Browser

2025-05-07T00:00:00+00:00

Comment je suis passé de Firefox comme navigateur Web principal au Zen Browser.

🔗</a>grandeur et décadence des pandas roux</h2>
Longtemps, j’ai utilisé le navigateur Web Firefox de bonne heure. Depuis mon adolescence, environ. À l’époque, parce qu’il révolutionnait les performances dans les navigateurs, face à Internet Explorer 6, permettant de naviguer à toute vitesse, avant que Google Chrome n’arrive et ne chamboule tout. Plus tard, je suis parti pour Chrome, finalement revenu pour Firefox, pour ses promesses quant à la protection de la vie privée des utilisateur·ices, son absence d’intérêts commerciaux à la direction de Mozilla. Encore plus tard, j’ai même eu la chance de travailler pour Mozilla, d’apprécier la puissance intellectuelle 1</a> des devs de Firefox et des autres produits de Mozilla, de pouvoir discuter avec les divers PDG, voire l’une des personnes à l’origine de l’initiative Mozilla Mitchell Baker</a>.
Mais tout n’a pas été rose tout du long. Même en tant qu’utilisateur, j’ai eu plusieurs fois des remontées acides, des grimaces de dégoût, et ce, indépendamment de mon licenciement économique en 2020 (causé par La Crise™, qui frappait fortement le monde de la publicité du fait des confinements liés au COVID19). Le rachat de Pocket</a> a été pour moi très marquant : un produit pas open-source, qui a galéré à le devenir complètement (de mémoire, la mise à disposition du code serveur est arrivée au cours de l’année 2024, quasiment plus de 10 ans après le rachat). Pendant ce temps-là, une autre équipe en interne avait créé une liste d’articles à lire plus tard, directement intégrée dans le navigateur. Cette même équipe était en train de créer des fondations techniques très solides et une vision cohérente pour une éventuelle plateforme de cloud personnel, à une période où je rêvais d’un Nextcloud</a> ou d’un CozyCloud</a> pour tous·tes, et où je me racontais que Mozilla avait la possibilité de vraiment changer les choses. Si seulement nous mettions à disposition des services cloud personnels estampillés Mozilla, absolument tout libres, infogérés par Mozilla, nous aurions même un angle business possible derrière ça : fournir quelques méga- ou giga-octets de stockage gratuit, puis faire payer les suivants. Mais d’autres décisions techniques et organisationnelles m’ont également marqué. Les virages et détours au sujet de Firefox OS, qui a finalement vécu sa meilleure vie une fois extirpé de Mozilla. Le choix de désinvestir dans Rust et Servo (un moteur de navigateur réécrit de zéro, en Rust), quand d’autres projets qui me semblaient moins prometteurs mais beaucoup plus « dans l’air du temps » (entendez : 🤮 metaverse 🤮 ou IA 🤮 déjà) ont été largement préférés. Pas besoin de revenir sur les différents épisodes, ou de trop me justifier ; disons que les derniers en date, notamment la cacophonie sur la notice liée à la vie privée, et l’arrivée d’IA nativement intégrée, ont un peu fini de me dégoûter, et ont rendu très compliqué pour moi le fait de continuer de défendre Mozilla malgré tout.
Parce que oui, je continuerai à défendre l’outsider Mozilla, tant au niveau technologique ou au niveau organisationnel. Technologique, parce que c’est l’un des trois derniers participants à encore créer un moteur de rendu, en gros toute la machinerie qui permet de faire un navigateur Web, et l’un des deux à tenter de combattre l’hégémonie de celui de Google. Organisationnel, parce qu’il s’agit (toujours, malgré tout) d’une entreprise « à mission »2</a> adossée à une fondation. Pas d’actionnaires auprès de qui il serait nécessaire de rendre des comptes ou d’offrir des dividendes ; pas d’objectif de s’enrichir à milliards. Juste une nécessité de gagner assez d’argent pour se maintenir en vie, et faire des trucs™ : payer les devs, proposer des initiatives d’éducation populaire au numérique et aux enjeux de protection de la vie privée.
Du moins, ça c’est là où je les attendrais ; en pratique, l’entreprise a tendance à s’éparpiller, à s’accrocher à n’importe quel qualificateur porteur de hype de la Silicon Valley, et essayer d’en tirer un profit pour se désolidariser du financement de Google pour la publicité offerte. D’où le metaverse ; d’où les initiatives un peu surprenantes sur l’IA. Je comprends le pourquoi et partage la motivation de prendre de la distance par rapport au financement via Google. Ça en devient absurde : aux USA, des procès antitrust ont actuellement lieu pour empêcher Google de financer les navigateurs à coups de millions pour être le moteur de recherche principal, ce afin de permettre aux autres moteurs de recherche d’être plus compétitifs™. Mais c’est une telle source de revenus pour Mozilla, que Mozilla en vient à défendre Google pour que Big G puisse continuer ce genre de pratiques</a>, sinon quoi la survie de Firefox (via son financement) serait menacée directement. Paradoxe de la compétition en effet. Bref, vivement que Mozilla puisse être plus tranquille financièrement, et idéalement pas en vendant de l’IA ou des produits inutiles ou en prenant des décisions qui ont l’air au mieux absurdes au pire effrayantes</a>, et aussi je voudrais la paix dans le monde et un poney, ce sera tout, un café et l’addition merci.

🔗</a>ok bon, alors on va où, on fait quoi ?</h2>
Les plus malin·gnes auront lu le titre de l’article, et les plus pressé·es pourront aller au sous-titre suivant. En attendant, un peu d’état de l’art sur les navigateurs existants.
Si vous êtes sur un MacOS ou un iOS, je pense assez sincèrement qu’Apple fait un bon boulot de protection de la vie privée avec Safari, et ça peut être une solution satisfaisante, si vous ignorez le fait que l’entreprise cherche à tout prix à vous enclaver dans son jardin doré, et fera tout pour éviter de vous faire voir ailleurs. Après tout, une application Web, c’est une application qui n’est pas dans l’App Store d’Apple, et qui donc ne rapporte pas d’argent à Apple, pourquoi s’embêter à soutenir une telle plateforme 😏
Et sinon, eh bien on ne va pas aller chez Chrome non plus, hein. Ce serait comme dire « ohlala la démocratie est en danger en France, si c’est comme ça je me casse en Chine / Corée du Nord / États-Unis3</a> ».
Émerge donc un besoin de cohérence, pour moi : je veux continuer à utiliser Gecko, le moteur de rendu de Firefox, et je veux continuer à utiliser un navigateur qui protège ma vie privée (et ne s’engouffre pas dans l’IA à la première occasion). Il existe bien des variantes de Firefox (forks) dans le monde du libre : IceCat</a> (anciennement IceWeasel), LibreWolf</a> me viennent à l’esprit, mais il en existe également d’autres d’après cette page Wikipédia</a>. Ces forks ont tendance à réutiliser principalement les mêmes concepts de navigateurs tels que nous les connaissons, et s’évertuent à supprimer les fonctionnalités dont l’impact est considéré comme étant néfaste vis-à-vis de la vie privée : télémétrie, toutes les méthodes directes ou indirectes de tracking même si c’est pour Mozilla, IA intégrée, et j’en passe et des meilleures.
D’aucuns disent à juste titre qu’abandonner Firefox pour aller sur un fork, c’est comme arrêter de boire de l’eau du robinet et ne consommer que l’eau mise en bouteille par le voisin un peu conspi et réac. Il y a effectivement un risque inhérent que les devs de ces projets s’amusent à mettre en place des bouts de code malveillants dans leur projet, ou le fassent par inadvertance. Le résultat est le même : les utilisateur·ices de ces forks seraient alors mis en danger, et l’utilisation d’un navigateur alternatif serait même contre-productive quant à l’intention initiale de mieux protéger sa vie privée des caprices des créateur·ices de Firefox. Mais la même question se poserait vis-à-vis de Firefox lui-même, si l’on ne savait pas que ce dernier est maintenu par la vénérable entreprise Mozilla ; la question de la confiance en le code est réglée, au vu des principes de l’entreprise. Ou « était » réglée ? L’intégration d’outils d’IA pourrait relever d’une trahison au niveau du code (la recette de fabrication de Firefox), remettant justement en question la confiance accordée par les utilisateur·ices. Je ne tiens pas à plonger dans l’aspect philosophique de la question. Pour moi, le fait que Firefox ou ses forks soient open-source garantit qu’il n’y aura pas de mauvaise surprise, parce que des gens plus paranoïaques que moi vont vérifier que le code ne fait pas n’importe quoi, à plus ou moins grande échelle. Cependant, même avec les plus belles intentions du monde, il est important que ces forks se remettent à jour sur Firefox régulièrement et rapidement. Je reviens là-dessus plus bas.

Pour un usage général, je pense que l’option LibreWolf ferait très bien le boulot : pas d’intégration d’outils de protection de la vie privée qui rendraient l’usage imbitable pour des néophytes, des bons choix par défaut, très sensés, recommandé dans le dessin ci-dessus par le brillant David Revoy</a>, bref, c’est Très Bien/10.
🔗</a>pendant ce temps-là, à Vera Cruz,</h2>
Pendant ce temps-là, donc, du côté des navigateurs pas open-source et conçus par des entreprises qui veulent engranger de la Grosse Caillasse™, il y a un petit nouveau, nommé Arc Browser</a>. Bien entendu, basé sur Chrome. Mais qui apporte un peu de renouveau et de fraîcheur dans le monde des navigateurs. Par exemple, cette barre d’onglets verticale sur le côté, sans barre d’URL au dessus du site, pour une esthétique assez minimaliste, qui donne toute la place au site. Des espaces différents, avec des répertoires d’onglets, pour contenir et regrouper les innombrables onglets ouverts navigués dans des contextes différents, et limiter l’expansion de la charge cognitive de tout avoir sous les yeux tout le temps. La possibilité de découper la vue de la page en deux, pour pouvoir naviguer sur deux sites différents, côte-à-côte.

Miam miam ; enfin un peu d’innovation dans les navigateurs, qui n’est pas sans rappeler le navigateur Vivaldi</a> (aussi basé sur Chrome 🥲). Au final, quels sont ses défauts, pour moi ? D’une part il est basé sur Chrome, et participe de l’hégémonie de son moteur de rendu. D’autre part, il est maintenu par une entreprise qui injecte de l’IA à toutes balles dans la version mobile du navigateur. Enfin, il n’est pas disponible sous Linux, système d’exploitation que j’affectionne tout particulièrement pour l’utiliser au quotidien 🤓
🔗</a>la lettre d’amour (rohlala enfin, on n’en pouvait plus)</h2>
Et c’est là qu’entre en jeu notre seigneur et sauveur</del>4</a> le Zen Browser</a>. Pas besoin de tergiverser, vu que sa conception semble directement inspirée d’Arc, il contient peu ou prou les mêmes fonctionnalités, et même mieux :
Ce navigateur est basé sur Firefox et donc Gecko. En soi, il soutient donc indirectement la puissance technologique de Mozilla. Plus pragmatiquement, il est compatible avec l’écosystème d’addons Firefox (si vous n’avez pas encore installé uBlock Origin</a>, allez-y, prenez votre temps, je vous attends tranquillement ici) et permet de se synchroniser avec un compte Mozilla classique (pour partager ses favoris / mots de passe etc. avec les autres instances de Zen Browser… ou de Firefox !).</li>
Il est disponible sur Linux, MacOS et Windows, donc globalement partout.</li>
Il y a donc une barre d’onglets verticale, sur le côté, qui laisse toute la place au contenu. Pas de barre d’URL en haut ; celle-ci existe bien, mais elle est plus discrète, en haut de la pile des onglets. Il est même possible de déplacer cette barre d’onglets sur la droite de l’écran. J’adore ça, personnellement, puisque ça donne la place principale sur mon écran pour l’application Web que je suis en train de regarder, et ça a même tendance à me faire croire que l’application Web est en fait une app native.</li>
En appuyant sur `Ctrl+Alt+C</code>, j’enclenche le mode compact, qui cache même cette barre d’onglets, pour n’avoir vraiment plus que le site en face des yeux. C’est très reposant et très zen (j’approuve le nom de facto).</li>`
`Il est aussi possible d’épingler des sites favoris, ce qui va n’afficher que leur icône, en très gros, tout en haut de la barre d’onglets. Idéal pour les sites sur lesquels je reviens souvent, notamment le tchat Matrix, mes emails, le lecteur musical etc.</li>`
Le navigateur essaie très activement de décharger automatiquement les onglets, notamment ceux qui n’ont pas été visités depuis un petit moment (alors que le navigateur était ouvert). Dans la barre d’onglets verticaux, il est même possible de séparer les onglets qui ne doivent pas être déchargés (au dessus d’une petite barre horizontale) de ceux qui peuvent l’être à n’importe quel moment (en dessous de cette même barre horizontale). Autant vous dire que la mémoire vive (RAM) de votre ordinateur appréciera 🥰</li>
`La gestion des onglets en espaces permet de compartimentaliser et de séparer les différents contextes liés à des onglets. Après quelques semaines d’utilisation sur cette machine, j’ai 3 espaces : un pour la navigation « au quotidien » que j’essaie de vider régulièrement, un pour` `Kresus</a> (🎶 un gestionnaire de finances personnelles libre, qu’il est trop bien 🎶) avec des liens vers des merge requests à relire ou finir, un pour des pages et sites que j’aimerais lire ou explorer plus tard, mais moins prioritaires.</li>`
Le découpage de la vue en plusieurs sous-vues (split view) est hyper pratique pour consulter deux pages en même temps. On clique sur deux onglets (ou plus), puis par exemple on presse Ctrl+Alt+V</code> pour les afficher côte-à-côte verticalement. Dans mes cas d’utilisation récurrents, je noterai le fait de prendre des notes (dans Silverbullet</a> par exemple) pendant que je regarde une vidéo instructive sur Youtube (et oui) ; ou de faire une comparaison de deux sites au niveau de leur contenu. Il est possible de découper la vue jusque 4 fois, donc j’imagine aussi bien un cas d’usage de tableau de bord avec plein de sites importants qu’on veut garder sous les yeux.</li> </ul> </video> L’une de mes fonctionnalités favorites, c’est l’ouverture d’un lien en mode aperçu (glance). Pour cela, on clique sur un lien en maintenant pressé Alt</code>. Cela ouvre une plus petite vue de ce site au-dessus du site que l’on visite, et cette petite vue peut être fermée via une presse de la touche Échap</code> ou en cliquant en dehors de cette vue ; ce qui nous ramène au site précédent. Il est également possible d’étendre une vue aperçu en un véritable onglet, pour naviguer plus normalement dessus. Ça ne paraît pas grand chose comme ça, mais pour moi c’est très très utile : souvent je suis sur des sites avec beaucoup de liens, et j’en suis parfois certains pour aller voir ce qui se trame derrière, avant de revenir au site. Avec ce mode d’aperçu, je reste dans le contexte de ce que je regardais avant, et je passe moins de temps à jongler entre plein d’onglets ; je n’ai qu’un seul onglet ouvert tout du long de ma navigation.</li> </ul> </video> Le fork est maintenu par des passionné·es, pas par une entreprise ; ce qui pourrait être un désavantage, mais l’activité autour du projet est très élevée. D’une part, beaucoup de commits récents dans l’historique du dépôt de code</a>…</li> …Et ce qui est le plus important, selon moi : les mises à jour de rattrapage de Firefox sont hyper rapides. Le problème est le suivant, quand vous maintenez un navigateur basé sur Firefox, il est nécessaire de récupérer régulièrement les changements de votre projet source (on parle d’upstream), ici Firefox, afin de les intégrer dans votre projet. Si ce n’est pas fait assez rapidement, vous risquez très rapidement d’utiliser un logiciel qui a des failles de sécurité rendues publiques. Or, de ce que j’observe, les devs de Zen Browser ont tendance à intégrer les nouvelles versions de Firefox très vite ; la dernière version de Firefox (la 138.0.1) est sortie le 1er mai</a>, la version correspondante de Zen Browser (basée sur la 138.0.1) est sortie le 3 mai</a> (voire le soir du 2 mai). Pour moi, c’est gage de qualité, d’autant plus que c’est donc maintenu par des gens qui font ça sur leur temps libre, pour le plaisir, c’est particulièrement honorable 🙏</li> </ul> 🔗</a>oui mais quid de ceci, Benjamin, quid de cela ?</h2> Ohlala je vous vois arriver avec vos gros sabots. Non, le Zen Browser n’est pas parfait, et c’est OK. Oui, c’est risqué qu’un navigateur, un des logiciels les plus centraux dans nos utilisations bureautiques modernes, soit maintenu par une poignée de gentils geeks avec trop de temps libre. Oui, Firefox pourrait sûrement faire la même chose avec 15 personnalisations de about:config</code>, un thème personnalisé en CSS et une plâtrée d’addons 5</a>. Je reviendrais sûrement sur Firefox, si jamais l’activité autour de Zen Browser venait à diminuer, ou bien au premier mouvement de drague à destination de l’IA, ou bien à la première faille de sécurité pas ou mal gérée. En attendant, c’est rafraîchissant d’avoir de nouveau du plaisir à utiliser un navigateur Web moderne, avec des fonctionnalités innovantes, tout en ne faisant aucun compromis sur ma vie privée. J’utilise maintenant Zen Browser depuis quelques semaines sur une machine, et je suis tout bonnement ravi, au point que je pense l’installer un peu partout rapidement, en complément/remplacement de Firefox. J’ai tendance à être de moins en moins prosélyte quant à l’utilisation de logiciels, libres ou non. Chacun·e fait bien comme iel veut, on ne part pas toustes du même endroit, on a bien le droit de prioriser d’autres sujets avant celui de l’utilisation de tel ou tel logiciels. Mais c’est une des premières fois depuis un moment que je remarque un logiciel libre si cool et innovant que j’adore l’utiliser, que j’ai envie d’en parler et de vous le partager ; voilà qui est chose faite 😊 Pour télécharger le navigateur Zen Browser, c’est par ici</a>. Si comme moi vous êtes fans, n’hésitez-pas à soutenir le développement avec un don</a> ! bac +5 les enfants, comme disait le cowboy ↩</a> </li> j’emploie des guillemets ici, parce qu’il me semble que le terme a une signification bien précise aux USA, mais ce n’est pas celle que j’utilise ici. ↩</a> </li> too soon 🥲 ↩</a> </li> roh le cliché de libriste, c’est moche. ↩</a> </li> il y a quelques semaines j’ai essayé de supprimer la barre d’URL en haut de Firefox pour la cacher, ou ne l’afficher qu’au survol ; sachez qu’il n’existe pas de solution officielle, et toutes les solutions officieuses (à base de Greasemonkey ou autres billevesées) sont fragiles comme un égo de mec. ↩</a> </li> </ol> </section>



Publish a Zola blog with Gitlab CI, real fast
2024-11-02T00:00:00+00:00
The two or three regular visitors of this blog (hi friends!) might have noticed I’ve changed the
design, as of this year. I’ve actually moved from using the Pelican</a>
static blog generator to using Zola</a>. This article shows the continuous
integration I’ve set up to automatically build and push content to my server, Real Fast™.</p>
</span>
Was there anything wrong with Pelican</code>? Not really. It has served me well over the years, and its
naming coming from an anagram of calepin</code>, French for a “small notebook”, is still just genius.
Installing on a new machine was a bit of a pain as I needed to recall which Python / virtualenv
/ etc. commands were required to install dependencies, but over the years I’ve made a Makefile to simplify that. And it
didn’t happen that often though; at most I’d run such a command once every two years or so (which
is, arguably, already a lot if that’s the frequency at which one switches machines).</p>
I mostly moved to Zola because I’m a zealot / member of the Rust evangelism strike
force</a>
on my spare time, and want to support tools created with Rust, which are usually blazing 😎 fast 🚀
1</a></sup>, in addition to being super safe. And, having a statically linked binary is super convenient,
and notably super nice for continuous integration and deployment purposes. Indeed, it’s trivial to
cache a single binary in CI, and not have to worry about installing/caching dependencies and so on.
In addition to that, Zola supports front-matter annotations with TOML or</em> YAML, so it offered a
nice migration path from Pelican, who uses YAML for frontmatters.</p>
I’ve been using Gitlab</a>, notably the Framagit</a>
instance hosted by the good fellows at Framasoft</a> (give them
money to support them!), for the repository hosting the sources of my blog. As such, I’ve wanted to
be able to push to the repository, and have the CI build and publish to my website.</p>
Now, let me explain how I’ve did it. These instructions are valid for GitLab Community Edition
v17.5.1</em> ; some things may change in newer versions, so I can’t guarantee they’ll work forever.
There’s a first stage that will build the public website using a cached Zola binary, if possible,
or grab it from the Github releases website otherwise.
The second stage2</a></sup> will upload it to the server, using rsync</code>. I’d recommend creating a new user
just for this task, with limited SSH access to a single directory, that is, where the generated
HTML will live. With caching, each stage takes at most 10 seconds to run, which I find…
acceptable 😁.</p>
Here’s the .gitlab-ci.yml</code> file I’ve checked in, heavily commented for your (and my future self’s) best
understanding:</p>
default</span>:</span></span>
  image</span>:</span> debian:stable-slim</span></span>
</span>
variables</span>:</span></span>
  # The runner will be able to pull your Zola theme when the strategy is</span></span>
  # set to "recursive".</span></span>
  GIT_SUBMODULE_STRATEGY</span>: "</span>recursive</span>"</span></span>
</span>
  # If you don't set a version here, your site will be built with the latest</span></span>
  # version of Zola available in GitHub releases.</span></span>
  # Use the semver (x.y.z) format to specify a version. For example: "0.17.2" or "0.18.0".</span></span>
  ZOLA_VERSION</span>:</span></span>
    description</span>: "</span>The version of Zola used to build the site.</span>"</span></span>
    value</span>: "</span>0.19.1</span>"</span></span>
</span>
build</span>:</span></span>
  stage</span>:</span> build</span></span>
</span>
  # Cache the Zola binary based on its version, to avoid conflicts between different versions.</span></span>
  cache</span>:</span></span>
    key</span>:</span> $ZOLA_VERSION</span></span>
    paths</span>:</span></span>
     # $CI_PROJECT_DIR is the current working directory in subsequent steps.</span></span>
      -</span> "</span>$CI_PROJECT_DIR/zola</span>"</span></span>
</span>
  script</span>:</span></span>
    -</span> |</span></span>
      if [ ! -e "$CI_PROJECT_DIR/zola" ]; then</span></span>
        echo "Downloading Zola…"</span></span>
</span>
        # Download enough to use `wget`.</span></span>
        apt-get update --assume-yes && apt-get install --assume-yes --no-install-recommends wget ca-certificates</span></span>
</span>
        if [ $ZOLA_VERSION ]; then</span></span>
          zola_url="https://github.com/getzola/zola/releases/download/v$ZOLA_VERSION/zola-v$ZOLA_VERSION-x86_64-unknown-linux-gnu.tar.gz"</span></span>
          if ! wget --quiet --spider $zola_url; then</span></span>
            echo "A Zola release with the specified version could not be found.";</span></span>
            exit 1;</span></span>
          fi</span></span>
        else</span></span>
          github_api_url="https://api.github.com/repos/getzola/zola/releases/latest"</span></span>
          zola_url=$(</span></span>
            wget --output-document - $github_api_url |</span></span>
            grep "browser_download_url.*linux-gnu.tar.gz" |</span></span>
            cut --delimiter : --fields 2,3 |</span></span>
            tr --delete "\" "</span></span>
          )</span></span>
        fi</span></span>
</span>
        wget $zola_url</span></span>
        tar -xzf *.tar.gz</span></span>
      else</span></span>
        echo "Reusing cached Zola…"</span></span>
      fi</span></span>
    -</span> |</span></span>
      $CI_PROJECT_DIR/zola build</span></span>
</span>
  # The built artifacts will be put in the `public/` directory, and reused during the next stage.</span></span>
  artifacts</span>:</span></span>
    paths</span>:</span></span>
      -</span> public/</span></span>
    expire_in</span>:</span> 1 day</span></span>
</span>
deploy</span>:</span></span>
  stage</span>:</span> deploy</span></span>
  only</span>:</span></span>
  -</span> main</span></span>
  dependencies</span>:</span></span>
  -</span> build</span></span>
  script</span>:</span></span>
  # Install rsync and ssh, if needs be.</span></span>
  -</span> apt-get update -qq && apt-get install -y -qq rsync</span></span>
  -</span> '</span>which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )</span>'</span></span>
  -</span> eval $(ssh-agent -s)</span></span>
  # Set SSH private key, and define the right permissions to not trigger security errors.</span></span>
  -</span> echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null</span></span>
  -</span> mkdir -p ~/.ssh</span></span>
  -</span> chmod 700 ~/.ssh</span></span>
  # Set SSH known hosts, and define the right permissions to not trigger security errors.</span></span>
  -</span> echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts</span></span>
  -</span> chmod 644 ~/.ssh/known_hosts</span></span>
  # Run rsync.</span></span>
  # Note: -avzh = append / verbose / compress / human-readable</span></span>
  -</span> rsync -avzh --delete public/* -e "ssh -p $SSH_PORT" $SSH_USERNAME@$SSH_HOST:$SSH_TARGET_DIR</span></span></code></pre>
After you’ve set this up, you need to fill some secrets on your CI, by going to Settings</code>,
then CI/CD</code>, then fill all the following variables under Variables</code>. Make sure to create them
as Masked</code> variables, if not Masked and hidden</code>, unless you’d like the SSH private key to
leak 🤡.</p>

SSH_HOST</code>: server’s host, e.g. mysupersecretserver.bouvier.cc</code></li>
SSH_PORT</code>: the port to be used for connecting with SSH, e.g. 22 by default.</li>
SSH_KNOWN_HOSTS</code>: a copy of a simplified ~/.ssh/known_hosts</code> file, stripped down to only
contain lines related to the above SSH_HOST</code>. This is to avoid having the CI task to confirm “Are
you sure you want to trust this host” when connecting for the first time to the server.</li>
SSH_TARGET_DIR</code>: the final directory where the generated HTML should live, e.g. /var/www/myblog</code>.</li>
SSH_USERNAME</code>: the username of the (Unix) user used in the CI task to upload generated artifacts
to your Web server…</li>
SSH_PRIVATE_KEY</code>: …and its private key.</li>
</ul>
Hope this was useful!</p>



Don’t pay attention to the emojis, they’re a meme at this point. ↩</a></p>
</li>

Using two stages is inherited from my previous setup using Pelican, and might be overkill
since the each stage takes at most 10 seconds to run, with a hot cache. ↩</a></p>
</li>
</ol>
</section>


Hetzner: cheap auction servers, and how to find them
2024-07-08T00:00:00+00:00
Lately, I’ve had to find a hosting server to replace the server we rented for delire.party,
our self-hosting collective of friends. Indeed, OVH decided, with no extra explanations, to
decomission our Kimsufi server at the end of the year, and to have us pay a few euros more per
month until then. This kind of practices irritates me, so I’ve decided to pull out
the plug (metaphorically speaking — the OVH server will still be online for the time of the
migration) and have our next server live at Hetzner.</p>
</span>
Hetzner is a German company, they’ve been relying on renewable energy for a
while</a>, and they have this interesting system
of server auctions, with prices lowering until a server has been rented out. For a regular human
being, that would mean checking the website multiple times a day to find a cheap server with the
right specification. I, for one, am a nerd, so I’ve looked for ways to automate this.</p>
There are a few scripts for this on the Internet, but I made a relatively short one that was
perfectly suited for my constraints. I wanted to only see servers with a price tag less than 50€
per month, and at least 2TB of NVME storage. I also wanted email notifications, so that I can stay
in the comfort of my email client to check out the new deals. The script doesn’t account for deals
it’s already seen, but using it for three days (running it once per day) was sufficient to find a
satisfying deal, so I didn’t even have to bother implementing that.</p>
The script is written in JavaScript (based on the one I’ve taken inspiration from), and it has two
dependencies: request</code> to run the HTTP requests, and nodemailer</code> to send me the email.</p>
var</span> nodemailer</span> =</span> require</span>(</span>"</span>nodemailer</span>"</span>)</span>;</span></span>
var</span> request</span> =</span> require</span>(</span>"</span>request</span>"</span>)</span>;</span></span>
</span>
var</span> dataUrl</span> = '</span>https://www.hetzner.com/_resources/app/jsondata/live_data_sb.json</span>';</span></span>
</span>
var</span> config</span> =</span> {</span></span>
    smtp_host</span>: "</span>mail.example.com</span>",</span></span>
    smtp_port</span>:</span> null</span>,</span></span>
    smtp_username</span>:</span> null</span>,</span></span>
    smtp_password</span>:</span> null</span>,</span></span>
    smtp_accept_unauthorized</span>:</span> true</span>,</span></span>
    email_from</span>: "</span>hetzner-deals@example.com</span>",</span></span>
    email_to</span>: "</span>your-email@example.com</span>",</span></span>
}</span></span>
</span>
if</span> (</span>!</span>config</span>.</span>smtp_host</span>) {</span></span>
    console</span>.</span>error</span>(</span>"</span>Please specity SMTP host</span>"</span>)</span>;</span></span>
    process</span>.</span>exit</span>(</span>1</span>)</span>;</span></span>
}</span></span>
</span>
if</span> (</span>!</span>config</span>.</span>email_to</span>) {</span></span>
    console</span>.</span>error</span>(</span>"</span>Please specify the email address to send notifications to</span>"</span>)</span>;</span></span>
    process</span>.</span>exit</span>(</span>1</span>)</span>;</span></span>
}</span></span>
</span>
var</span> transporter</span> =</span> nodemailer</span>.</span>createTransport</span>({</span></span>
    host</span>:</span> config</span>.</span>smtp_host</span>,</span></span>
    port</span>:</span> config</span>.</span>smtp_port</span>,</span></span>
    auth</span>:</span> {</span></span>
        user</span>:</span> config</span>.</span>smtp_username</span>,</span></span>
        pass</span>:</span> config</span>.</span>smtp_password</span></span>
    }</span>,</span></span>
    tls</span>:</span> {</span></span>
        rejectUnauthorized</span>:</span> !</span>config</span>.</span>smtp_accept_unauthorized</span></span>
    }</span></span>
})</span>;</span></span>
</span>
var</span> jar</span> =</span> request</span>.</span>jar</span>()</span>;</span></span>
request</span> =</span> request</span>.</span>defaults</span>({</span> jar</span>:</span> jar</span> })</span>;</span></span>
</span>
request</span>.</span>get</span>(</span>dataUrl</span>,</span> (</span>error</span>,</span> resp</span>,</span> body</span>)</span> =></span> {</span></span>
    if</span> (</span>error</span> ||</span> resp</span>.</span>statusCode</span> !==</span> 200</span>) {</span></span>
        console</span>.</span>error</span>(</span>"</span>Error: </span>" +</span> error</span>)</span>;</span></span>
        console</span>.</span>error</span>(</span>"</span>Response code: </span>" +</span> resp</span>.</span>statusCode</span>)</span>;</span></span>
        process</span>.</span>exit</span>(</span>2</span>)</span>;</span></span>
    }</span></span>
</span>
    let</span> json</span> =</span> JSON</span>.</span>parse</span>(</span>body</span>)</span>;</span></span>
</span>
    let</span> results</span> =</span> []</span>;</span></span>
    for</span> (</span>let</span> s</span> of</span> json</span>.</span>server</span>) {</span></span>
        // Here, `s` is the data representing a single server.</span></span>
        // You can look at it and make up your own filtering</span></span>
        // criteria based on its shape.</span></span>
        // console.log(s);</span></span>
</span>
        // This holds the total size of NVME storage.</span></span>
        let</span> sumNvme</span> =</span> s</span>.</span>serverDiskData</span>.</span>nvme</span>.</span>reduce</span>((</span>a</span>,</span> b</span>)</span> =></span> a</span> +</span> b</span>,</span> 0</span>)</span>;</span></span>
</span>
        // Rough approximation of the monthly price, based on the hourly price.</span></span>
        let</span> monthlyPrice</span> =</span> s</span>.</span>hourly_price</span> *</span> 24</span> *</span> 31</span>;</span></span>
        // renting an IPv4 costs around 2.02/month</span></span>
        monthlyPrice</span> +=</span> 2.02</span>;</span></span>
</span>
        // round to second decimal</span></span>
        monthlyPrice</span> =</span> ((</span>100</span> *</span> monthlyPrice</span>)</span> |</span> 0</span>)</span> /</span> 100</span>;</span></span>
</span>
        if</span> (</span>sumNvme</span> >=</span> 2000</span> &&</span> monthlyPrice</span> <</span> 50</span>) {</span></span>
            results</span>.</span>push</span>(</span>`</span>- </span>${</span>s</span>.</span>id}</span>:</span>`</span>)</span>;</span></span>
            results</span>.</span>push</span>(</span>`</span>    RAM=</span>${</span>s</span>.</span>ram_size}</span>GB</span>`</span>)</span>;</span></span>
            results</span>.</span>push</span>(</span>`</span>    NVME=</span>${</span>sumNvme</span>}</span>GB</span>`</span>)</span>;</span></span>
            results</span>.</span>push</span>(</span>`</span>    PRICE=~</span>${</span>monthlyPrice</span>}</span>€</span>`</span>)</span>;</span></span>
            results</span>.</span>push</span>(</span>`</span>    (</span>${</span>s</span>.</span>information}</span>)</span>`</span>)</span>;</span></span>
            results</span>.</span>push</span>(</span>''</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
</span>
    var</span> mailOptions</span> =</span> {</span></span>
        from</span>:</span> config</span>.</span>email_from</span>,</span></span>
        to</span>:</span> config</span>.</span>email_to</span>,</span></span>
        subject</span>: "</span>Hetzner Server deal found</span>",</span></span>
        text</span>: "</span>Found deals:</span>\n\n" +</span> results</span>.</span>join</span>(</span>'\n'</span>)</span>,</span></span>
    }</span>;</span></span>
</span>
    transporter</span>.</span>sendMail</span>(</span>mailOptions</span>,</span> function</span>(</span>error</span>,</span> info</span>) {</span></span>
        if</span> (</span>error</span>) {</span></span>
            console</span>.</span>error</span>(</span>"</span>Error sending email notification: </span>" +</span> error</span>)</span>;</span></span>
            process</span>.</span>exit</span>(</span>3</span>)</span>;</span></span>
        }</span> else</span> {</span></span>
            console</span>.</span>log</span>(</span>'</span>Email notification sent: </span>' +</span> info</span>.</span>response</span>)</span>;</span></span>
        }</span></span>
    })</span>;</span></span>
})</span>;</span></span></code></pre>
Hope this may be useful to some of you too!</p>


cargo-machete, find unused dependencies quickly
2022-04-27T23:17:23+00:00
cargo-machete</code> is a new Cargo tool that detects unused dependencies in Rust
projects, in a fast (yet imprecise) way. As of today you can install it with
cargo install cargo-machete</code> and then run it with cargo machete</code> from any
folder that contains a workspace or crate, to find if you have potentially
unused dependencies. Beware, it can report a few false positives!</p>
</span>🔗</a>Problem statement</h2>
When developers hack on code, it’s a pretty common to reuse software that
already exists and has been written, optimized, and battle-tested by many
others. In fact, that’s a core idea of the open-source movement, and one
historical reason for its existence.</p>
When zooming in into the Rust programming language case, my opinion is that it
is also a key reason why Rust has been so successful: having plenty of crates
doing everything you might need, already implemented for you and at hand’s
reach on crates.io</code>. Plus, having the wonder of a one-does-it-all Cargo tool
that makes it very easy to use those crates as dependencies in your project.
1</a></sup></p>
However, this comes with a price: sometimes you add a dependency because it’s
useful at a particular point in time. Much later, it’s not useful anymore, but
you may have forgotten about it. And then, the dependency remains as a zombie
in your Cargo.toml</code> file. Cargo will include it in the compilation graph,
despite the compilation artifacts not being used at all. The unused dependency
will just stay there, silently weep, waiting for you to recall it exists.</p>
Of course, the problem can even become worse: maybe you maintain several crates
that have unused dependencies. Or maybe you work with many crates as part of a
workspace, and each may have unused dependencies. Or simply you use many
dependencies yourself, and some may include unused dependencies. If you’ve
published your crates and others use those, then everyone could also compile
unused dependencies. At the scale of the entire Rust crates ecosystem, it can
have a huge impact on the compile times, produced heat and wasted energy.</p>
🔗</a>Have you heard about our lord and savior, cargo-udeps</code></h2>
There’s already a nice tool for this in the ecosystem:
cargo-udeps</code></a>. It will compile your
crate (or workspace) and then infer from the compiled artifacts what
dependencies are used by your project, and thus show you which dependencies are
unused</em>.</p>
That’s great, but the way it works forces a few tradeoffs:</p>

it requires to compile the whole crate with the Rustc nightly</code> compiler. For
me that means recompiling the whole project from scratch, most of the time,
since I’m mostly using stable rustc as my daily driver.</li>
if you compile for multiple targets (i.e. different combinations of CPU
flavor, OS, environment, etc.), you’d need to run cargo-udeps</code> on each of
those to find per-target unused dependencies. For instance, if a dependency
is only configured when compiling for x86_64 machines, then it may be flagged
as unused on every other configuration.</li>
most of all, since it look at compilation artifacts, it cannot know if a
specific dependency is directly used by your crate, or indirectly, leading to
somehwat mystifying results in the case of workspaces.</li>
</ul>
Let’s dive a bit deeper into the last item, which I’ll refer to as the
transitively-used dependencies problem</em>. Say you have your project AAA</code> that
contains a dependency to serde</code> in its Cargo.toml</code> file, while it’s not
directly used by your code. In fact, if you did a text-search of serde</code> in
AAA</code>’s code with grep</code>, you wouldn’t find a single match2</a></sup>. But now AAA</code>
is using another crate, AB</code>, that itself depends on serde</code>. cargo-udeps</code>
will see that serde</code> is used overall</em>, so it cannot let you know that AAA</code>’s
Cargo.toml</code> file references an unused dependency to serde</code>.</p>
</p>
How is this a problem? After all, if the workspace uses serde</code> even
indirectly, then we will</em> have to compile it at some point, so it’s not like
it’s really</em> unused.</p>
First of all, the AAA</code> crate might be using a different version of serde</code>
than the AB</code> crate, and this could result in different copies of the same
crate in your workspace. Note there are other nice tools that automatically
detect this kind of situation (hi there
cargo-deny</a>).</p>
Second, the order in which crates are compiled has an impact on compilation
parallelism, and having unused dependencies may add spurious synchronization
points in the compilation graph. When a Rust crate gets compiled by Cargo,
Cargo proceeds in two phases:</p>

first, it collects information so as to unlock the compilation of other
crates further down the road that may depend on this particular one. I don’t
know precisely what it entails, but one can make educated guesses: parse the
code, analyze which items are pub</code>lic, compute memory layouts for public
types, collect type information and so on and so forth.</li>
then, it does the actual compilation: optimize and generate the actual
machine code for that particular crate, that will be later linked with other
artifacts to form the final executable program.</li>
</ul>
The advantage of this two-phases scheme is that once Cargo is done with phase 1
for a particular crate, it can kick off the same process for other crates up
the dependency tree, while it runs phase 2 concurrently. With a multi-core
machine as is the norm on desktop computers, it’s almost certain that this will
bring speedups!</p>
For instance, consider the following Cargo.toml</code> file from our previous
example project:</p>
[</span>dependencies</span>]</span></span>
serde</span> = "</span>1.0</span>"</span></span></code></pre>
Then a possible compilation graph could look like that:</p>
</p>
In this case, ab</code> phase 1 can start as soon as serde</code> phase 1 has finished,
while serde</code>’s compilation phase 2 happens in the background.</p>
If you’re interested in reducing the overall compile times of your Rust
project, I would strongly suggest to go read Rust’s documentation around
timings
visualization</a>.
Crates which spend lots of time in the first phase (or more generally, in both
phases) are basically pipelining bottlenecks, so identifying/removing/working
around them overall speeds up compile times.</p>
Back to our small unused dependency problem: an unused dependency in your
Cargo.toml</code> may block the compilation of other crates up the dependency tree,
and thus may slow down the whole compilation process by creating useless check
points.</p>
Consider a crate C</code> that depends on crates A</code> and B</code>, with B</code> actually
unused:</p>
</p>
Here, the compilation of the crate C</code> could start way earlier, but it’s
blocking waiting for the compilation of B</code> to finish first, while it’s not
even used!</p>
🔗</a>Solving this, the naive way</h2>
So when I was trying to confirm whether crates found by cargo-udeps</code> were
actually used or not in my Rust projects, the thing I’d do would be to grep</code>
(or better, use the blazingly fast Rust replacement
ripgrep</a>) the crate’s name in the
project. After all, the crate’s name is in the source directory, if and only if
the crate is used, right?</p>
The answer is… mostly, yes. If we exclude dynamic code loading via mechanisms
like dlopen</code> or WebAssembly, then there aren’t so many ways to use other
crates directly</em>, in Rust code. In fact, we can exhaustively enumerate all the
syntax items to use other dependencies in Rust:</p>
use</span> my_crate</span>;</span></span>
use</span> your_crate </span>as</span> my_crate</span>;</span></span>
use {</span> your_crate </span>as</span> my_crate </span>};</span></span>
extern</span> crate</span> my_crate</span>;</span></span>
</span>
fn</span> main</span>() {</span></span>
    my_crate</span>::</span>something</span>();</span></span>
}</span></span></code></pre>
I’ve looked at a bit of Rust code now, and I haven’t seen other direct forms;
if I am missing any, please let me know! Now, these are the most frequent</em>
ways to use a dependency, but there are in fact other ways:</p>

build.rs</code> scripts can generate code that could use other crates, and that
would not be visible through a text search in the src/</code> directory, as the
generated code is somewhere inside the target/build/</code> directory.</li>
macros (procedural or not) can expand to code that’s using other crates,
while the source code doesn’t explicitly</em> mention them. For instance, the
log_once</code></a> crate uses the log</code> macros
in its own macros, but log_once</code> doesn’t depend on log</code> explicitly. It’s a
bold and smart move: it breaks the coupling with the specific version of
log</code> , and as long as the high-level API of log</code> is stable (which is the
case), then log_once</code> works with any</em> version of log</code>.</li>
</ul>
And then, there’s still a bit of room for some false positives:</p>

raw text submatches: e.g. if a crate is named bar</code>, then foobar::</code> would be
a match if we’re doing a raw grep</code> search</li>
text search isn’t syntaxic analysis, and we wouldn’t know if a match is in a
comment (// use foo;</code>), or a string (String::from("use foo;")</code>).</li>
</ul>
But that would do most of the job</em>, wouldn’t it? In particular, compared to
cargo-udeps</code>, this approach doesn’t suffer from the transitively-used
dependencies</em> problem. If you look for a crate’s name in the src/</code> directory
and it’s not there, it’s likely not used by your crate. The End.</p>
🔗</a>A tedious process calls for automation, so I made a tool</h2>
And I’ve called it cargo-machete</code>. Like a machete, it is very useful for
quickly weeding out things, but it is very imprecise and you wouldn’t trust it
at 100%.</p>
The gist of it is:</p>

find directories that might contain Rust projects, as indicated by the
presence of a Cargo.toml</code> file</li>
for each dependency, create an absolutely ugly regular expression that
matches any of the syntaxic forms presented above. The regular expression
does better than just raw text search, in particular it doesn’t run into the
text submatch issue.

then for each file in the project, try to match the regular expression
against each line of any source file, and stop at the first successful
match (which means the dependency is</em> used)</li>
</ul>
</li>
</ul>
This tool is fast</em>, because it combines the core library behind ripgrep</code> for
matching regular expressions, with rayon</em> for running it in parallel across
all the dependencies of a project. On my machine, the problem is CPU-bound,
because of the execution of the regular expression (and maybe thanks to my NVME
storage too). That’s only one data point, but on this particular beefy desktop
I use, it scans the entirety of the rust-lang/rust</code> repository in 1.08
seconds, or all of BytecodeAlliance/wasmtime</code> in 0.58 seconds.</p>
The tool is open source</em></a>, of course.</p>
As is the tradition for Cargo tools, it can be installed with:</p>
cargo install cargo</span>-</span>machete</span></span></code></pre>
and then can be used, from any directory that contains Rust code (be it a
workspace, a single project, or a directory on top of many Rust projects), with
the following line:</p>
cargo machete</span></span></code></pre>
Here’s an output example:</p>
></span> cargo machete</span></span>
Looking</span> for crates in this directory and analyzing their dependencies...</span></span>
/home/ben/code/cargo-machete/integration-tests/with-bench/Cargo.toml</span> --</span> no package, must be a workspace</span></span>
just-unused</span> --</span> /home/ben/code/cargo-machete/integration-tests/just-unused/Cargo.toml:</span></span>
	log</span></span>
unused-transitive</span> --</span> /home/ben/code/cargo-machete/integration-tests/unused-transitive/Cargo.toml:</span></span>
	lib1</span></span>
Done!</span></span></code></pre>
There are false positives</em>: code generated via macros or build scripts aren’t
inspected as they’re not in the src/</code> directory and cargo-machete</code> doesn’t
run any compile step. For instance, if a project depends on log</code> , but uses it
only through log_once</code>, then cargo-machete</code> will incorrectly flag log</code> as an
unused dependency.</p>
The good news is that, thanks to a contribution from @daniel5151</code>, you can
specify known false positives</em> in the Cargo.toml</code> file of your crate,
allowing use of cargo-machete</code> in CI setups:</p>
[</span>package</span>.</span>metadata</span>.</span>cargo-machete</span>]</span></span>
ignored</span> =</span> [</span>"</span>log</span>"</span>]</span> # false positive, used by log_once! macro</span></span></code></pre>
As far as I know, the risk for false negatives</em> (i.e. crates that are unused,
but the tool thinks they’re used) is pretty low. One such instance would be a
multi-line string containing one of the use</code> forms, but that seems rather
unlikely to be present in most Rust projects.</p>
The tool is still a bit rough, but it’s been already quite useful for some
projects I’ve been working on! In a particular work project, most unused
dependencies were transitively used and compiled, but the rejiggering of the
compilation graph lead to a 5% compile time speedup overall. Good impact over
effort ratio.</p>
🔗</a>What about other languages?</h2>
What makes this possible in Rust, and could it be extended to other languages?</p>
Dynamic languages by nature dynamically load code, but there are still ways to
try to automate detecting unused dependencies same as cargo-machete</code> does.
Consider JavaScript and its require</code> function, that can dynamically evaluate a
string that’s a path to a file with code we want to import. Since there’s an
infinity of ways to create a string, we can’t just perfectly rely on finding
require("abc")</code> and assume that if not present, then abc</code> isn’t used. Ditto
with import</code> statements, which can evaluate dynamic sources. That being said,
if JS code is restricted to use require</code> statements with only static strings
or static import</code> statements, then this may work too! Although when
restricting to static require</code>s, even just loading</em> the code in NodeJS would
be sufficient to find unused dependencies with perfect accuraccy.</p>
Back to static languages, where I constrain the problem to non-dynamic
dependencies (loaded via dlopen</code> etc.). In a language like C or C++, there are
no unified module systems or package description (yet! although cmake</code> might
be a de-facto standard). We can still apply this to header files, and look for
their inclusion via #include</code> statements. Macros and preprocessed code would
also throw a wrench in the process. Then some human intervention would still be
required to eliminate the .c files, but I haven’t thought about it too much.</p>
Static analysis of compiled binaries might be simpler, for that matter. If we
consider the problem for WebAssembly, we can frame it as “which imported
functions are not used in the module”, potentially eliminating an entire range
of host functions. In the simplest case, we could just look at the code
section, through the function bodies, and see if there’s any reference to
indices of every single imported function in call</code> opcodes. Then, there can be
function Table</code>s referencing those, so we have to make sure no table elements
reference the function. And if any table is mutable and publicly exposed via an
export, then a user of the wasm module may reference any function declared in
the wasm module, including imported functions, so all bets are off. Note
dead-code elimination in wasm would be pretty similar and suffer from the same
limitations: after all, a function dependency is just another kind of function,
in wasm! Each format may have such idiosyncrasies like that. Static analysis of
final binaries (as opposed to libraries) might be possible and reliable,
though.</p>
🔗</a>Closing thoughts</h2>
For the sake of completeness, I should mention the existence of a rustc
crate-wide lint for this, since May 2020 or
so</a>:
#![warn(unused_crate_dependencies)]</code>. This tells about unused crate
dependencies directly as a Rust warning, which in my opinion would be the ideal
end goal! Unfortunately, some Github comments suggest it suffers from having
too many false positives, and still it requires compiling the code.</p>
@est31</code>, of cargo-udeps</code>’s fame, has been working on a better
solution</a>. It seems to not be so
far from completion, so between this and the Rust lint, I’m hopeful that there
could be a time where we have a solution that is perfectly precise, with
neither false positives nor false negatives.</p>
In the meanwhile, I hope that cargo-machete</code> can be useful to some of you, or
that it inspires others to make similar quick-and-dirty tools, in Rust or in
other languages. Thanks for reading this far, and please get in
touch</a> if you have any thoughts about this!</p>



If you don’t know about the cargo-edit</code> tool that allows you to add a
dependency in one line with cargo add serde</code> to your project: now you
do</a>. ↩</a></p>
</li>

Wait for it… ↩</a></p>
</li>
</ol>
</section>


A primer on code generation in Cranelift
2021-02-17T19:00:42+00:00