rodarima

Thanks for the feedback. I'm not sure if I understand the misdiagnosis part. I think that complex free software reduces the ability from independent groups to modify it, so forcing it to be small ensures it remains easy to modify.

Chromium is complex because they indeed solve a complex problem, and I don't think there is much room for a simpler software solution to implement the current web. So the problem is not the implementation, but the choice of what is being implemented. But I'm not sure how this conflicts with the above argument to preserve the ability to modify the software.

My main objective is to make sure that this problem doesn't happen in Dillo, which necessarily means we need to sacrifice many features. A benefit from using source size is that is easy to measure (we do it in the CI) so we avoid a subjective metric.

This is a talk I gave last month at FOSDEM 2025 where I presented the resurrection process of Dillo as well as a live demo at 5:10 of some new features. The whole presentation is done in Dillo itself from a 15 year old Intel Atom netbook.

There is also a backup at the archive, but you probably want to avoid flooding their servers if you can: https://archive (dot) org/details/dillo-fosdem-2025

The original video (with uncorrected color) is at FOSDEM website: https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resu...

Here are the slides (in HTML): https://dillo-browser.github.io/fosdem-2025/

The website is at: https://dillo-browser.github.io/

> Dillo is only sporadically developed.

I maintain it.

> They even lost control of the dillo.org domain a long time ago

New website is at: https://dillo-browser.github.io/

See https://dillo-browser.github.io/dillo.org.html and maybe https://www.youtube.com/watch?v=sFJp8JDg8Yg or https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resu...

> ... which pretty much spells amateur hour

?

The 3.2.0 version of the minimalistic Dillo browser was just released.

Fedi: https://fosstodon.org/@dillo/113849784119138640

Upcoming FOSDEM talk: https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resu...

Same on Dillo, reloading makes the JS wall go away for now, but probably won't last.

Edit: Reloading doesn't work anymore for me. Unless the sca_esv=xxxxxxxxx param is present it will redirect to the JS wall.

There are some benefits in using an alias instead.

First, it is easier and shorter to type and remember, as the path to the socket can be long. Second, multiple users may run a given service in a socket located at different paths. And third, using a host name can be used to create virtual hosts, so you can serve different responses to foo.unix and bar.unix while both point to the same server UNIX socket.

If you see a problem with using a host file, could to provide an example of how it could go wrong?

Because there are multiple protocols you could be using to talk to the socket other than HTTP. In order to use HTTP, you also need to specify the path and maybe other elements. What you may want is something like:

    http://<unix:///tmp/my.sock>/foo/bar.html?good=yes

To avoid the nesting of protocols, I think it is cleaner to give it a name and define the socket path elsewhere.

To easily run a HTTP service that only your user can talk to.

    echo 'unix:/tmp/my.sock weather.unix' >> ~/.config/unix.hosts
    dillo http://weather.unix/today/

I just wrote a simple RFC to support UNIX sockets in URLs, initially for Dillo[1] but potentially useful for other software.

It allows protocols other than HTTP to talk to the socket, like Gemini or Gopher.

[1]: https://dillo-browser.github.io/

Coincidentally, the Dillo FOSDEM talk also got accepted yesterday[1], so I'll try to make something special for the 25 year ocassion :)

[1]: https://fosdem.org/2025/schedule/event/fosdem-2025-4100-resu...

Oh, right! I'll fix that after coffee, thanks!

Edit: fixed!

Fixed at HN side (thanks dang).

> I wonder if HN sticks to the current HTML markup (which is full of validation errors!) to preserve compatibility with third-party clients that scrape and parse it?

I don't think so, but if it does I recommend they instead stick to the HTML (4.01 or 5) spec by default.

> In that case, maybe we could get a query parameter along the lines of useValidMarkup=1" (or a user setting might be better) to produce valid HTML for the benefit of niche browsers that expect it while preserving the current invalid but stable) markup by default.

They can guess the browser by the User-Agent and serve a "patched" version if needed (bluedwarf.top does it). But I would recommend doing against this, as it reduces the incentive for clients to get fixed and moves the responsibility to webmasters.

Thanks, I reported it too by email.

Thanks! You should be able to login most forums that don't require JS. Keep an eye on the cookies configuration[1] which are disabled by default.

[1]: https://dillo-browser.github.io/user_help.html#cookies

It is on the Arch Linux repository now :-)

  # pacman -Syu dillo

AFAIK, Ladybird goal is to build an independent web browser from scratch that can render the "modern" web.

Dillo original goal[1] is to provide access to the web to places with very bad internet speed or latency as well as old or resource constrained computers.

[1]: https://dillo-browser.github.io/old/interview.html

I don't think we will ever implement JS support, as that would increase a lot the minimum requirements to run Dillo and make the attack surface on the browser much bigger.

Please don't link to dillo dot org, see: https://dillo-browser.github.io/dillo.org.html

You may like this plugin[1] to read local man pages as properly formated HTML pages.

[1]: https://github.com/dillo-browser/dillo-plugin-man

More plugins: https://dillo-browser.github.io/index.html#plugins

TLDR: Dillo is a fast and small graphical web browser. It kind of died in 2017 and this is the first release after 9 years from the last one.

You can read the main website for more details[1].

[1]: https://dillo-browser.github.io/

And the release page[2], which explains a bit of the history of the project and the current state.

[2]: https://dillo-browser.github.io/latest.html

Because I considered it a good starting point as I can place a redirect notice there if we move to another place, without worrying we will lose the DNS again. If you want to help, feel free to do so :-)

What prevents you from doing some tests? We have seen Dillo running in a lot of old and not very common machines (Atari), so you may have some work already done.

> TIL of Spartan Protocol

You can browse spartan pages with a Dillo plugin[1], as well as Gopher, Gemini and others.

[1]: https://dillo-browser.github.io/#plugins

> how is it handling modern security features like new versions of TLS or SSL

We support OpenSSL 1.1 and 3 (and any other API-compatible), LibreSSL and mbedTLS 2 and 3. You can choose the one you like/trust more at link time.

Forgot to mention that we are also on Fedi: https://fosstodon.org/@dillo

Here are some cherry picks:

- Dillo on the Kindle: https://fosstodon.org/@dillo/112181258739093008

- Dillo on an old Samsung phone: https://fosstodon.org/@dillo/112327798958777998

It is orphan in Arch, but I will check tomorrow if I can apply for maintainer. In the meanwhile I have the AUR package[1] dillo-git:

[1]: https://aur.archlinux.org/packages/dillo-git

This was already asked the last time[1], but I think it would miss the point of Dillo.

[1]: https://news.ycombinator.com/item?id=38853053

Thanks!

In the main page: https://dillo-browser.github.io/

And here are more: https://dillo-browser.github.io/gallery/index.html

There are a lot of features waiting to be included in Dillo. We focused on solving bugs first and tried to get as few features as posible to get the 3.1.0 out as soon as posible.

Apart from CJK, there are other issues with fonts that we have to solve too. Feel free to open more issues: https://github.com/dillo-browser/dillo/issues

Check out the gallery: https://dillo-browser.github.io/gallery/index.html