1 puntos por GN⁺ 2024-01-03 | 1 comentarios | Compartir por WhatsApp
  • Dillo es un navegador web gráfico rápido y pequeño, pensado incluso para máquinas antiguas o modestas y conexiones lentas; funciona en Linux, BSD, MacOS, Windows mediante Cygwin y Atari
  • Combina C/C++ y pocas dependencias, su propio motor de renderizado en tiempo real y la biblioteca GUI FLTK para buscar bajo uso de memoria y renderizado rápido incluso en páginas grandes
  • Soporta de forma nativa HTTP, HTTPS, FTP y archivos locales, y puede ampliar nuevos protocolos mediante plugins escritos en cualquier lenguaje
  • El proyecto mantiene un enfoque centrado en reducir las barreras de entrada a la web y priorizar la seguridad y privacidad personal, así como la eficiencia del software
  • La versión más reciente es la 3.2.0, y los datos principales se guardan en su propio repositorio git, con réplicas en Codeberg y Sourcehut

Un navegador gráfico pequeño y rápido

  • Dillo es un navegador web gráfico rápido y pequeño
  • Funciona en Linux, BSD, MacOS, Windows mediante Cygwin y Atari
  • Cómo está implementado

    • Está escrito en C y C++ y tiene pocas dependencias
    • Implementa su propio motor de renderizado en tiempo real
    • Mantiene un bajo uso de memoria y un renderizado rápido incluso en páginas grandes
    • Usa la biblioteca GUI FLTK, rápida y sin adornos innecesarios
  • Funciones básicas y objetivos

    • Soporta HTTP, HTTPS, FTP y archivos locales
    • Es ampliable mediante plugins escritos en cualquier lenguaje
    • Es software libre bajo licencia GPLv3
    • El bug meter ayuda a los autores a seguir los estándares web
    • Sus metas son reducir las barreras de entrada a la web, soportar máquinas antiguas o modestas y conexiones lentas, proteger la seguridad y privacidad personal, y lograr una alta eficiencia del software
    • Las instrucciones de uso de sus funciones pueden consultarse en el User Manual
    • El dominio dillo.org ya no está bajo control de los desarrolladores de Dillo

Infraestructura del proyecto movida a self-hosting

Lanzamientos, documentación y vías de contribución

  • Puede descargarse la latest release 3.2.0 y compilarse siguiendo las instrucciones de README.md
  • Los cambios más recientes pueden clonarse directamente desde el Git repository
  • Documentación

    • User Manual: cubre el uso de todas las funciones y se distribuye junto con el navegador para poder leerse localmente
    • Topic Guide: trata temas adicionales no incluidos en el manual, como cómo configurar Dillo y mpv para abrir archivos multimedia desde URLs
    • Developer Documentation: cubre el diseño interno y la implementación del navegador, y se recomienda a desarrolladores
  • Cómo contribuir

    • Si al navegar la web con Dillo encuentras algo que no funciona, puedes abrir un issue o enviar un correo a dillo-dev@mailman3.com
    • Puedes enviar parches para implementar funciones nuevas o corregir errores, o crear un pull request
    • Puedes apoyar los costos de pruebas e infraestructura mediante Liberapay

Soporte de protocolos ampliado mediante plugins

  • Los plugins interactúan mediante entrada y salida estándar y añaden soporte para nuevos protocolos
  • Algunos ejemplos de plugins disponibles son:
    • Gemini: gemini://, Bash, plugin del protocolo Gemini
    • Gopher: gopher://, C, plugin del protocolo Gopher
    • IPFS: ipfs://, ipns://, Go, plugin del protocolo IPFS
    • Man: man://, Bash, renderiza páginas man como HTML
    • Spartan: spartan://, Bash, plugin del protocolo Spartan
  • Pueden consultarse más plugins en los git repositories
  • Para añadir un plugin nuevo, basta con enviar por correo el enlace del repositorio y una breve descripción

1 comentarios

 
GN⁺ 2024-01-03
Opiniones de Hacker News
  • En una Mac M1 con macOS 12.7 compiló bien, y para instalarlo bastó con seguir las instrucciones de macOS: instalar los paquetes con brew install y OpenSSL 3, y luego, antes de ./configure, ejecutar el export que configura la ruta de OpenSSL.
    Después, con make, sudo make install y dillo, arrancó de inmediato; es un binario de 1.6 MB, soporta SSL y es muy rápido.
    La búsqueda de Google funciona hasta cierto punto aunque el CSS se rompa, pero iniciar sesión en Google parece difícil porque no hay JavaScript.
    [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

    • Creo que habría que agregar a las instrucciones de instalación en macOS la configuración de la ruta de OpenSSL.
      En CI parece funcionar incluso sin las banderas de include, pero como no tengo una Mac propia, hay límites para probarlo.
  • Para hardware de bajos recursos realmente hace falta un navegador más rápido y liviano.
    En SBC, Raspberry Pi y laptops de hace algunos años, todo lo demás va fluido, pero el rendimiento del navegador siempre termina siendo el cuello de botella.
    Al final uno acaba aceptando que, por algunos requisitos, se necesita un Ryzen 7 y 16 GB de RAM, y es triste que las mayores cargas de cómputo sean MS Teams y el webmail.

    • Después de usar MS Teams durante unos dos años, lo entiendo totalmente.
      Es sorprendentemente lento, confuso, lleno de bugs, y las pestañas se mueren seguido; se siente como un ejemplo de cómo no debería ser el software.
      Todavía me sorprende que Microsoft haya decidido que eso estaba bien, y me da curiosidad cómo será Slack.
      Tal vez, como no hay mucha competencia, no se esfuerzan más en hacerlo bien.
    • Tengo muy presente el recuerdo de navegar bastante bien la web con Windows 98 y 64 MB de RAM, y es triste que ahora ni con varios GB alcance para hacerlo bien.
    • Entre los navegadores más livianos están NetSurf, Pale Moon, K-Meleon on Goanna, Otter Browser y Ultralight; y como apps de terminal están Carbonyl, Browsh y Links.
      Links también soporta modo gráfico.
    • Me parece que esto es bastante exagerado.
      Con una CPU de escritorio/laptop económica razonable y 4 GB de RAM alcanza para correr MS Teams, y tampoco entiendo muy bien por qué usar webmail cuando existen agentes de transferencia de correo más prácticos y eficientes.
  • Dada la situación, alegra saber que Dillo continúa.
    Tengo dos netbooks con Intel Atom N270 de alrededor de 2009 y 1 GB de RAM; Firefox es absurdamente pesado ahí, y Dillo debería andar muy bien.
    Antes también usaba Dillo en mi desktop principal para ver documentos cuyo CSS no era pesado, y mientras 20 a 40 pestañas en Firefox consumían mucha RAM, Dillo por lo general se mantenía cerca de los 100 MB.
    Como no tiene motor de JavaScript, también uso Dillo para abrir enlaces sospechosos, y siento que es un gran software que he usado bien durante más de 15 años.

    • Para abrir enlaces sospechosos, recomendaría usar un perfil de Chromium o Firefox con JavaScript y fuentes web desactivados antes que software en C con mantenimiento incierto.
      Dillo no tiene sandbox para partes complejas que suelen ser atacadas, como decodificación de imágenes, parsing de HTML/CSS, protocolos de red o acceso a archivos locales.
    • Ese era precisamente el objetivo que Jorge tenía en mente: permitir que personas de regiones donde se usan máquinas de bajo rendimiento pudieran acceder a la web.
      En la universidad usaba en casa una Pentium 4 vieja, y con los navegadores normales tenía que esperar unos 30 segundos para abrir una sola pestaña.
      Por eso usaba principalmente Dillo, y para artículos que requerían JavaScript pasaba por la caché de Google y luego iba a Firefox.
      Como la red también era lenta, que solo descargara HTML ayudaba muchísimo, y Dillo siempre fue muy rápido durante años.
    • Me da curiosidad si también probaste NetSurf como opción.
      También es muy liviano.
    • Configurar swap zram con el script zramup podría ayudar.
      doas /sbin/modprobe zram
      doas /sbin/zramctl --find --size 1024M
      doas /sbin/mkswap /dev/zram0
      doas /sbin/swapon /dev/zram0 --priority -1
      Aunque no sea Firefox, lamentablemente Luakit puede ser una buena opción para tareas de una sola página donde JavaScript es obligatorio, como sitios de administración pública.
    • Me da curiosidad qué sistema operativo usas en esa netbook.
      Hace poco conseguí una netbook con Intel Atom y estoy buscando un sistema operativo liviano pero usable.
      También probé Debian, pero Firefox era demasiado lento, y quizá ahora valga la pena volver a intentarlo con Dillo.
  • El sistema de extensiones es interesante y recuerda a los scripts CGI locales de w3m
    El CGI local de w3m puede usarse para un visor de páginas man, un sistema de marcadores y la implementación de protocolos adicionales en combinación con urimethodmap
    Dillo también parece tener, de forma similar, un plugin man y un plugin DPI para marcadores, y al parecer también permite esquemas personalizados como man:
    No sabía que hubiera navegadores además de w3m que admitieran este enfoque, y estaba creando un proyecto personal en el que incluso HTTP se montaba sobre una estructura de plugins parecida, así que ahora tengo un segundo caso de referencia
    [0]: https://dillo-browser.github.io/old/dpi1.html
    [1]: https://github.com/dillo-browser/dillo-plugin-man

    • En Dillo, muchas funciones están implementadas como DPI
      Hay plugins que implementan “sitios web” como file:, vsource: y ftp:, y también plugins encargados de funciones como el manejo de cookies, descargas y marcadores
      Como son procesos separados, las descargas continúan aunque se cierre el navegador
      [1]: https://github.com/dillo-browser/dillo/tree/master/dpi
      En ~/.dillo/dpidrc se vinculan protocolos con binarios de plugins, y con plugins externos se puede tener gemini:, gopher: e incluso git:
      Hasta hace poco, HTTPS también estaba implementado como plugin DPI, pero ahora pasó al propio navegador
    • El sistema de extensiones es simple y fácil de manejar
      Creé una biblioteca en Go delgada para escribir plugins de Dillo (https://github.com/boomlinde/dpi) y también hice un plugin para el protocolo Gemini (https://github.com/boomlinde/gemini.filter.dpi)
      Según tengo entendido, en Dillo reciente https también estaba implementado como plugin DPI
    • Si no recuerdo mal, Arachne hacía algo parecido
  • Sugieren contactar a Renato Bravo
    https://www.youtube.com/channel/UCuklruLsO-CFoKK_rjNXrXg
    https://www.youtube.com/watch?v=A6mb9qt2-3o
    En el video de arriba, Renato dice “ese es mi compañero Jorge”, es decir, “esa persona es mi colega Jorge”
    Encontré a Renato Bravo en LinkedIn, pero no sé si es la misma persona

    • Buena idea
      Si es de la misma zona de Valparaíso, Chile, que Jorge, quizá sea esta persona
      No uso LinkedIn, pero sería bueno que alguien pudiera enviarle un mensaje
      [1]: https://cl.linkedin.com/in/renatobravo
  • Antes solía probar seguido en Dillo para ver si un sitio se rompía por completo, pero Dillo quedó tan viejo que me pasé a NetSurf, w3m y elinks
    Su resurrección es alentadora, especialmente para sistemas de bajo consumo
    Sin embargo, es una lástima pasar de un repositorio Mercurial autoalojado a un repositorio Git en Microsoft GitHub, propiedad de una gran empresa estadounidense; aun así, como el mantenedor dice que aceptará parches por correo electrónico, no obliga a crear una cuenta ni a aceptar términos de uso

    • Si se tiene en cuenta que la razón principal por la que desapareció el autoalojamiento fue precisamente el autoalojamiento, esa queja se entiende, pero suena un poco rara
    • El traslado a GitHub se consideró un buen primer paso para aumentar la visibilidad del proyecto y atraer más contribuciones
      Se puede confiar en que GitHub seguirá existiendo al menos durante los próximos 5 a 10 años, así que se puede dejar un aviso de redirección en la página web principal
      Aun así, estoy de acuerdo en que sería mejor pasar a autoalojamiento o a una forge federada
      Hay un issue relacionado, y el problema actual es que en cuentas gratuitas de otras forges como Codeberg no hay forma de ejecutar pipelines de CI en otras plataformas, como macOS
      A largo plazo, me gustaría conseguir hardware real, montar runners propios y probar también en varias arquitecturas
      [1]: https://github.com/dillo-browser/dillo/issues/39
      El proyecto anterior incluso autoalojaba su servidor de correo, lo que creó un enorme punto único de falla, y como en la práctica falló gravemente, intento evitar eso
      También estoy considerando una lista de correo para parches por email, pero fuera de sourcehut y googlegroups no conozco muchos lugares que la ofrezcan gratis
  • Recuerdo haber usado Dillo antes en Puppy Linux desde un Live CD
    Me pregunto cuál será el compilador mínimo objetivo, si hay planes a largo plazo, si se hará fuzzing y si se migrará a un sistema de build moderno como CMake

    • Todavía no se definió un compilador mínimo objetivo, pero no parece difícil agregarlo al CI
      El plan a largo plazo es, primero, evitar que Dillo muera y que lo eliminen de las distribuciones
      Después dependerá del tiempo libre disponible, pero al menos intentaré darle mantenimiento
      Antes del fuzzing, creo que agregar otros conjuntos de pruebas de navegadores podría detectar muchos problemas de renderizado, y el fuzzing podría ser especialmente interesante para los parsers propios de HTML/CSS
      Al modificar configure.ac, resultó muy doloroso cuando se apunta a varias plataformas, y la compilación cruzada también está rota
      Primero habría que ver cómo funciona el soporte de CMake en otros sistemas y si se puede eliminar de forma segura la familia Automake, pero no quiero introducir cambios grandes antes del lanzamiento 3.1
  • Al bajar el código de GitHub y compilarlo, vi que el sitio predeterminado todavía era dillo.org, y al intentar visitarlo el navegador se cerró
    duckduckgo.com también se cerró igual, y parecía estar relacionado con un fallo de assert de OpenSSL
    Al recompilar con mbedTLS, pude visitar esos sitios
    Intenté iniciar sesión en este hilo y responder, pero aunque ingresaba el nombre de usuario y la contraseña e iniciaba sesión, seguía apareciendo como desconectado, sin ningún error

    • Gracias por probarlo; hay que cambiar el sitio predeterminado al nuevo sitio web
      Si abres un issue en GitHub con la información del sistema y la versión de OpenSSL, podemos intentar reproducirlo
      Es muy probable que el problema de inicio de sesión sea porque las cookies están desactivadas
      https://dillo-browser.github.io/old/dillo3-help.html
      https://dillo-browser.github.io/old/Cookies.txt
      En Dillo todas las cookies están desactivadas por defecto, así que se recomienda permitirlas manualmente por sitio
      echo "news.ycombinator.com ACCEPT" >> ~/.dillo/cookies.txt
      Después basta con reiniciar el demonio DPI para que vuelva a leer la configuración de cookies
      dpidc stop
  • Me alegra ver que Dillo todavía recibe atención
    Tengo bastantes plugins de Dillo que conseguí hace tiempo en scuttlebutt
    Están dillo-adb, dillo-dat, dillo-finger, dillo-git, dillo-gopher, dillo-gemini, dillo-ipfs, dillo-ssb, dillo-ytdl; si quieren, puedo empaquetarlos en un zip y enviarlos para que hagan un fork y los continúen dentro del proyecto

    • Parece que la mayoría fueron hechos por Charles, y como él mantiene la interfaz scuttlebutt-web, se pueden descargar desde su página principal
      https://celehner.com/projects.html#dillo-plugins
      Ya hablé con Charles sobre guardar una copia en GitHub bajo la organización dillo-browser
      También estaría bien que abrieras un issue y subieras ahí una copia del archivo zip para poder conservarla
  • Me da gusto ver que continúa el trabajo surgido de una semilla plantada hace mucho tiempo