Show HN : la résurrection du navigateur Dillo

 (dillo-browser.github.io)
1 points par GN⁺ 2024-01-03 | 1 commentaires | Partager sur WhatsApp
  • Dillo est un navigateur web graphique rapide et léger, conçu aussi pour les machines anciennes ou modestes et les connexions lentes ; il fonctionne sous Linux, BSD, MacOS, Windows via Cygwin et Atari
  • En combinant C/C++, peu de dépendances, son propre moteur de rendu en temps réel et la bibliothèque GUI FLTK, il vise une faible consommation mémoire et un rendu rapide même sur de grandes pages
  • Il prend en charge nativement HTTP, HTTPS, FTP et les fichiers locaux, et peut être étendu à de nouveaux protocoles via des plugins écrits dans n’importe quel langage
  • Le projet reste orienté vers la réduction des barrières d’accès au web, la sécurité et la confidentialité personnelles, ainsi que l’efficacité logicielle
  • La dernière version est 3.2.0 ; les principales données sont conservées dans son propre dépôt git et répliquées sur Codeberg et Sourcehut

Un petit navigateur graphique rapide

  • Dillo est un navigateur web graphique rapide et léger
  • Il fonctionne sous Linux, BSD, MacOS, Windows via Cygwin et Atari

  • Implémentation

    • Il est écrit en C et C++ et a peu de dépendances
    • Il implémente son propre moteur de rendu en temps réel
    • Même sur de grandes pages, il consomme peu de mémoire et rend les pages rapidement
    • Il utilise la bibliothèque GUI FLTK, rapide et sans superflu

  • Fonctionnalités de base et objectifs

    • Il prend en charge HTTP, HTTPS, FTP et les fichiers locaux
    • Il est extensible au moyen de plugins pouvant être écrits dans n’importe quel langage
    • C’est un logiciel libre sous licence GPLv3
    • Le bug meter aide les auteurs à respecter les standards du web
    • Il vise à abaisser les barrières d’accès au web, à prendre en charge les machines anciennes ou modestes et les connexions lentes, ainsi qu’à favoriser la sécurité et la confidentialité personnelles et une forte efficacité logicielle
    • L’utilisation des fonctionnalités est décrite dans le User Manual
    • Le domaine dillo.org n’est plus contrôlé par les développeurs de Dillo

Une infrastructure de projet déplacée vers l’auto-hébergement

Versions, documentation et moyens de contribuer

  • Il est possible de télécharger la latest release 3.2.0 et de la compiler en suivant les instructions de README.md
  • Les dernières modifications peuvent être clonées directement depuis le Git repository

  • Documentation

    • User Manual : couvre l’utilisation de toutes les fonctionnalités et est distribué avec le navigateur pour pouvoir être lu localement
    • Topic Guide : traite de sujets supplémentaires absents du manuel, comme la configuration de Dillo et mpv pour ouvrir des fichiers multimédias à partir d’URL
    • Developer Documentation : couvre la conception interne et l’implémentation du navigateur, et est recommandée aux développeurs

  • Comment contribuer

    • Si vous trouvez une partie qui ne fonctionne pas en naviguant sur le web avec Dillo, vous pouvez ouvrir une issue ou envoyer un e-mail à dillo-dev@mailman3.com
    • Vous pouvez envoyer un patch implémentant une nouvelle fonctionnalité ou corrigeant un bug, ou créer une pull request
    • Vous pouvez soutenir les coûts de test et d’infrastructure via Liberapay

Prise en charge de protocoles extensible par plugins

  • Les plugins interagissent via l’entrée et la sortie standard et ajoutent la prise en charge de nouveaux protocoles
  • Voici des exemples de plugins fournis
    • Gemini : gemini://, Bash, plugin pour le protocole Gemini
    • Gopher : gopher://, C, plugin pour le protocole Gopher
    • IPFS : ipfs://, ipns://, Go, plugin pour le protocole IPFS
    • Man : man://, Bash, rend les pages de manuel en HTML
    • Spartan : spartan://, Bash, plugin pour le protocole Spartan
  • D’autres plugins sont disponibles dans les dépôts git
  • Pour ajouter un nouveau plugin, il suffit d’envoyer par e-mail le lien du dépôt et une brève description

À lire aussi

1 commentaires

 
GN⁺ 2024-01-03
Avis Hacker News

  • La compilation s’est bien passée sur un M1 Mac sous macOS 12.7, et pour l’installation il a suffi de suivre les instructions macOS, d’installer les paquets avec brew install ainsi que OpenSSL 3, puis d’exécuter un export pour définir le chemin d’OpenSSL avant ./configure
    Ensuite, avec make, sudo make install, puis dillo, tout a fonctionné immédiatement ; le binaire de 1.6MB prend aussi en charge SSL et il est très rapide
    La recherche Google reste plus ou moins utilisable même si le CSS est cassé, mais sans JavaScript, la connexion à Google semble difficile
    [0] https://github.com/dillo-browser/dillo/blob/master/doc/insta...
    [1] https://github.com/dillo-browser/dillo/blob/master/doc/insta...
    [2] https://stackoverflow.com/a/77749836

    • Il faudrait sans doute ajouter la configuration du chemin OpenSSL aux instructions d’installation macOS
      Dans le CI, cela semble fonctionner même sans flag include, mais comme je n’ai pas de Mac sous la main, mes tests restent limités

  • Du matériel peu puissant a vraiment besoin de navigateurs plus rapides et plus légers
    Les SBC, Raspberry Pi et ordinateurs portables de quelques années restent agréables à utiliser pour le reste, mais c’est toujours le navigateur qui finit par tout ralentir
    Au final, on en vient à accepter qu’il faut un Ryzen 7 et 16 GB de RAM à cause de certaines exigences, et le plus amer est que la plus grosse charge de calcul vient de MS Teams et du webmail

    • Après avoir utilisé MS Teams pendant environ deux ans, je compatis totalement
      C’était incroyablement lent, confus, bourré de bugs, et les onglets plantaient souvent ; on aurait dit un contre-exemple de ce que le logiciel ne devrait pas être
      J’ai encore du mal à croire que Microsoft ait jugé cela acceptable, et je me demande comment Slack se compare
      C’est peut-être parce qu’il n’y a pas beaucoup de concurrence qu’ils ne font pas plus d’efforts
    • Je me souviens très bien qu’on naviguait plutôt correctement sur le web avec Windows 98 et 64MB de RAM, et c’est triste de voir qu’aujourd’hui même plusieurs GB ne suffisent plus vraiment
    • Parmi les navigateurs web plus légers, il y a NetSurf, Pale Moon, K-Meleon on Goanna, Otter Browser et Ultralight, et côté applications terminal il y a aussi Carbonyl, Browsh et Links
      Links prend aussi en charge un mode graphique
    • Je trouve cela assez exagéré
      Un CPU de bureau/portable d’entrée de gamme correct avec 4GB de RAM suffit à faire tourner MS Teams, et comme il existe des agents de transfert de courrier plus pratiques et plus efficaces, je ne vois pas très bien pourquoi on s’obstine à utiliser le webmail

  • Vu le contexte, je suis heureux d’apprendre que Dillo continue d’exister
    J’ai deux netbooks Intel Atom N270 datant d’environ 2009 avec 1GB de RAM ; Firefox y est absurdement lourd, alors que Dillo y tournerait très bien
    Autrefois, j’utilisais aussi Dillo sur mon ordinateur principal pour lire des documents dont le CSS n’était pas trop lourd, et pendant que Firefox avec 20 à 40 onglets consommait beaucoup de RAM, Dillo restait en général autour de 100MB
    Comme il n’a pas de moteur JavaScript, j’utilise aussi Dillo pour ouvrir des liens suspects, et je le trouve excellent depuis plus de 15 ans

    • Pour ouvrir des liens suspects, je recommanderais plutôt un profil Chromium ou Firefox avec JavaScript et les polices web désactivés qu’un logiciel en C dont la maintenance est incertaine
      Dillo n’a pas de sandbox pour des parties complexes et souvent attaquées comme le décodage d’images, le parsing HTML/CSS, les protocoles réseau ou l’accès aux fichiers locaux
    • C’était justement l’objectif que Jorge avait en tête : permettre aussi aux personnes vivant dans des régions où l’on utilise des machines peu performantes d’accéder au web
      À l’université, j’utilisais chez moi un vieux Pentium 4, et avec un navigateur classique il fallait attendre environ 30 secondes pour ouvrir un seul onglet
      J’utilisais donc surtout Dillo, et quand un article nécessitait JavaScript, je passais par le cache Google avant de basculer vers Firefox
      Le réseau étant lui aussi lent, le fait de ne récupérer que le HTML aidait énormément, et Dillo est resté très rapide pendant des années
    • Je me demande si tu as aussi essayé NetSurf comme alternative
      C’est également très léger
    • Le script zramup peut aider si l’on configure du swap zram
      doas /sbin/modprobe zram
      doas /sbin/zramctl --find --size 1024M
      doas /sbin/mkswap /dev/zram0
      doas /sbin/swapon /dev/zram0 --priority -1
      Sans aller jusqu’à Firefox, Luakit peut malgré tout convenir pour les tâches en page unique où JavaScript est indispensable, comme sur certains sites administratifs publics
    • Je suis curieux de savoir quel système d’exploitation tourne sur ces netbooks
      J’ai récemment récupéré un netbook Intel Atom et je cherche un OS léger et utilisable
      J’ai aussi essayé Debian, mais Firefox était trop lent ; peut-être que cela vaudrait le coup de retenter avec Dillo cette fois

  • Le système d’extension est intéressant, et rappelle les scripts CGI locaux de w3m
    Les CGI locaux de w3m peuvent servir de visionneuse de pages man, de système de signets, et à implémenter des protocoles supplémentaires combinés avec urimethodmap
    Dillo semble avoir quelque chose de similaire, avec un plugin man et un plugin DPI pour les signets, et il semble aussi possible d’avoir des schémas personnalisés comme man:
    Je ne savais pas qu’il existait d’autres navigateurs que w3m prenant en charge cette approche, et comme je travaillais sur un projet personnel reposant lui aussi sur une structure de plugins similaire, jusqu’à HTTP, cela me fait un deuxième exemple de référence
    [0]: https://dillo-browser.github.io/old/dpi1.html
    [1]: https://github.com/dillo-browser/dillo-plugin-man

    • Dans Dillo, beaucoup de fonctionnalités sont implémentées en DPI
      Il y a des plugins qui implémentent des « sites web » comme file:, vsource:, ftp:, et d’autres qui gèrent des fonctions comme les cookies, les téléchargements ou les signets
      Comme ils tournent dans des processus séparés, les téléchargements continuent même après la fermeture du navigateur
      [1]: https://github.com/dillo-browser/dillo/tree/master/dpi
      Dans ~/.dillo/dpidrc, on relie les protocoles aux binaires de plugins, et des plugins externes permettent gemini:, gopher:, voire git:
      Jusqu’à récemment, HTTPS aussi était implémenté comme plugin DPI, mais c’est maintenant intégré au navigateur lui-même
    • Le système d’extension est simple et facile à manipuler
      J’ai créé une fine bibliothèque Go pour écrire des plugins Dillo(https://github.com/boomlinde/dpi), et j’ai aussi fait un plugin pour le protocole Gemini(https://github.com/boomlinde/gemini.filter.dpi)
      D’après ce que je sais, récemment dans Dillo, https aussi était implémenté comme plugin DPI
    • Si je me souviens bien, Arachne faisait quelque chose de similaire

  • Je suggère de contacter Renato Bravo
    https://www.youtube.com/channel/UCuklruLsO-CFoKK_rjNXrXg
    https://www.youtube.com/watch?v=A6mb9qt2-3o
    Dans la vidéo ci-dessus, Renato dit « ese es mi compañero Jorge », c’est-à-dire « cet homme est mon collègue Jorge »
    J’ai bien trouvé un Renato Bravo sur LinkedIn, mais je ne sais pas si c’est la même personne

    • Bonne idée
      S’il vient lui aussi de la région de Valparaíso au Chili, comme Jorge, c’est probablement bien lui
      Je n’utilise pas LinkedIn, mais ce serait bien si quelqu’un pouvait lui envoyer un message
      [1]: https://cl.linkedin.com/in/renatobravo

  • Autrefois, je testais souvent sur Dillo pour voir si un site se cassait complètement, mais Dillo était devenu trop obsolète, donc je suis passé à NetSurf, w3m et elinks
    Son retour est encourageant, surtout pour les systèmes peu gourmands en énergie
    En revanche, c’est dommage de passer d’un dépôt Mercurial auto-hébergé à un dépôt Git GitHub appartenant à une grande entreprise américaine, même si le mainteneur dit qu’il acceptera les patchs par e-mail, ce qui évite d’imposer la création d’un compte ou l’acceptation de conditions d’utilisation

    • Vu que la principale raison de la disparition de l’auto-hébergement était précisément l’auto-hébergement, je comprends cette critique, mais elle me semble aussi un peu étrange
    • J’ai estimé qu’un passage sur GitHub constituait un bon point de départ pour donner plus de visibilité au projet et attirer davantage de contributions
      On peut au moins croire que GitHub existera encore pendant 5 à 10 ans, donc il sera possible de laisser un avis de redirection sur la page web principale
      Cela dit, je suis d’accord qu’il vaudrait mieux revenir à de l’auto-hébergement ou à une forge fédérée
      Il existe une issue à ce sujet, et le problème actuel est qu’avec les comptes gratuits d’autres forges comme Codeberg, il n’y a pas de moyen de faire tourner des pipelines CI sur d’autres plateformes comme macOS
      À long terme, j’aimerais obtenir du vrai matériel pour mettre en place mes propres runners et tester aussi sur plusieurs architectures
      [1]: https://github.com/dillo-browser/dillo/issues/39
      L’ancien projet auto-hébergeait même son serveur mail, créant un énorme point unique de défaillance, et cela a effectivement très mal tourné, donc j’essaie d’éviter ça
      Je réfléchis aussi à une mailing list pour les patchs par e-mail, mais en dehors de sourcehut et googlegroups, je ne connais pas beaucoup de services gratuits qui en proposent

  • Je me souviens avoir utilisé Dillo sur le Live CD de Puppy Linux il y a longtemps
    Je me demande quel est le compilateur minimal visé, s’il existe un plan à long terme, si du fuzzing est prévu, et s’il y aura une migration vers un système de build moderne comme CMake

    • Nous n’avons pas encore fixé de compilateur minimal cible, mais cela ne semble pas difficile à ajouter à la CI
      Le plan à long terme est d’abord d’empêcher Dillo de mourir et d’éviter qu’il soit retiré des distributions
      Ensuite, cela dépendra du temps libre disponible, mais je veux au minimum assurer la maintenance
      Avant le fuzzing, je pense qu’ajouter d’autres suites de tests de navigateurs permettrait déjà d’attraper beaucoup de problèmes de rendu, et le fuzzing pourrait être particulièrement intéressant pour le parseur HTML/CSS maison
      Après avoir modifié configure.ac, j’ai constaté que c’était très pénible dès qu’on vise plusieurs plateformes, et la cross-compilation est aussi cassée
      Il faudra vérifier comment se comporte le support CMake sur les autres systèmes avant de voir si l’on peut supprimer en toute sécurité la famille Automake, mais je ne veux pas introduire de gros changements avant la sortie de la version 3.1

  • J’ai récupéré le code sur GitHub et tenté de le compiler, et le site par défaut était toujours dillo.org ; quand j’ai essayé de le visiter, le navigateur a planté
    duckduckgo.com plantait lui aussi, et cela semblait lié à un échec d’assert d’OpenSSL
    En recompilant avec mbedTLS, j’ai pu visiter ces sites
    J’ai essayé de me connecter à ce fil pour poster une réponse, mais même après avoir saisi mon nom d’utilisateur et mon mot de passe et m’être connecté, je restais déconnecté en permanence sans aucun message d’erreur

    • Merci d’avoir testé ; il faut remplacer le site par défaut par le nouveau site web
      Si vous ouvrez une issue GitHub avec les informations système et la version d’OpenSSL, on pourra essayer de reproduire le problème
      Le problème de connexion vient probablement du fait que les cookies sont désactivés
      https://dillo-browser.github.io/old/dillo3-help.html
      https://dillo-browser.github.io/old/Cookies.txt
      Par défaut, Dillo désactive tous les cookies ; il est donc recommandé de les autoriser manuellement site par site
      echo "news.ycombinator.com ACCEPT" >> ~/.dillo/cookies.txt
      Ensuite, il suffit de redémarrer le démon DPI pour qu’il recharge la configuration des cookies
      dpidc stop

  • C’est agréable de voir que Dillo suscite encore de l’intérêt
    J’ai encore pas mal de plugins Dillo récupérés autrefois sur scuttlebutt
    J’ai dillo-adb, dillo-dat, dillo-finger, dillo-git, dillo-gopher, dillo-gemini, dillo-ipfs, dillo-ssb, dillo-ytdl, et si vous voulez je peux les regrouper dans un zip pour que vous puissiez les forker et poursuivre le projet

    • La plupart semblent avoir été créés par Charles, qui maintient l’interface web scuttlebutt ; on peut donc les télécharger depuis sa page d’accueil
      https://celehner.com/projects.html#dillo-plugins
      J’ai déjà parlé avec Charles de la possibilité de conserver des copies sur GitHub sous l’organisation dillo-browser
      Vous pouvez aussi ouvrir une issue et y téléverser une copie du fichier zip pour qu’elle soit conservée

  • C’est gratifiant de voir continuer un travail issu de graines semées il y a longtemps