Show HN: Resurrecting the Dillo browser (dillo-browser.github.io)

see https://news.ycombinator.com/item?id=32809126

https://github.com/crossbowerbt/dillo-plus

https://github.com/crossbowerbt/dillo-plus#gopher-and-gemini...

Edit: Newline formatting. Edit 2: Wording (port not fork).

https://git.scuttlebot.io/%25n7g%2BJlKZjPV6CRfSQL5YUWk%2BxYg... https://github.com/boomlinde/gemini.filter.dpi https://celehner.com/projects.html#dillo-plugins

> What's the minimum compiler you target?

I didn't defined any (yet), but shouldn't be too hard to add to the CI.

> Any big long term plans?

First preventing it from dying and getting removed from distros. Then it depends of how much free time I can dedicate to it, but at least maintaining it.

> Fuzzing?

I would say first adding some of the other browser tests suites. That should catch a lot of rendering issues. But yeah, fuzzing would be interesting, specially for the custom HTML and CSS parsers.

> Moving to 'modern' build system like CMake?

Yes, I had to modify the configure.ac and that was very painful, specially targeting a lot of platforms. It is also broken for cross compilation. I have to check also how is the support for cmake in other systems, so we can safely remove Automake and friends. But I didn't want to introduce any big changes before 3.1 is released.

This is precisely the objective Jorge had in mind, so people on other parts of the world with less capable machines where still able to access the web.

While I was in university, I was using an old Pentium 4 at home (which I still use) which couldn't open a single tab unless you wait around 30 seconds for it to load. So I was mostly using Dillo and failing back to Google cache and then Firefox to read something that required Javascript.

I used it for years and it always was super fast. Also, my network connection was not very fast, so loading only the HTML helped a lot.

> So thanks to everyone who continues to work on this, I really appreciate the work you do! Dillo is a fine piece of software that I have enjoyed using for at least 15 years now, and I hope it will be around for many years to come! <3

Thanks :-)

I would suggest using a Chromium or Firefox profile with JavaScript and webfonts disabled for this instead of questionably maintained C software that doesn’t have a sandbox for any of the complex and commonly exploited things it does (image decoding, HTML/CSS parsing, network protocols, local file access).

    #!/bin/sh
    doas /sbin/modprobe zram
    doas /sbin/zramctl --find --size 1024M
    doas /sbin/mkswap /dev/zram0
    doas /sbin/swapon /dev/zram0 --priority -1

[1]: https://groups.google.com/g/dillo/search?q=javascript

However, I don't think the machines that Dillo is targeting would benefit from adding support for it and it would increase a lot the surface for security problems. Maybe my advise would be to use another browser if you have the computing power to run JS.

https://celehner.com/projects.html#dillo-plugins

I already talked with him about keeping a copy of them in GitHub under the dillo-browser organization.

> and if you're interested I can zip them up and send it to you to be forked and worked on the project

Feel free to open an issue and upload it there, so we can keep a copy of the zip. Thanks!

I would say that the plugin system is one of the things makes Dillo a bit different.

I had some ideas to do performance tests and also check how well the rendering engine works with choppy connections (while content is still slowly downloading), but I didn't do any tests yet.

There were some very old results against firefox comparing memory usage in the old page [1].

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

Yeah, a lot of things [1] are implemented as DPI in Dillo. Some of the plugins implement "websites" like file:, vsource: and ftp: but others implement other features like the handling of cookies, downloads or bookmarks. As they are a different process, if you close the browser, the downloads continue.

[1]: https://github.com/dillo-browser/dillo/tree/master/dpi

> * w3m can use urimethodmap + local CGI to implement additional protocols. I guess DPI can do that too? (At least the custom man: scheme in dillo-plugin-man seems to indicate it can.)

Yes, there is a file (~/.dillo/dpidrc) that associates the protocol to the plugin binary (like this "proto.man=man/man.filter.dpi"). There is also gemini: gopher: and even git: available as external plugins.

> I had no idea any browser supported this besides w3m. I mostly imitated w3m's design in my own project (which includes the twist that support for every protocol, including HTTP, is implemented on top of a similar plugin system); I guess I have a second reference point now :)

In fact, not so long ago, the HTTPS protocol was implemented as a DPI plugin, but it was changed to be part of the browser.

https://github.com/dillo-browser/dillo-browser.github.io/pul...

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

Here [2] is the original development plan, which was focused on making the floating elements work well, but the main developer of that area, Sebastian, sadly passed away.

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

I'm planning to add better support for the most common attributes that break the layout the most (margin: auto) and also keep a proper table of the support status.

How so? A lot of websites rely upon animations (I'm guessing you're referring to more advanced CSS support here), yet people still use browsers like w3m, elinks, lynx, etc.

If anything, I'd imagine the information density would be much greater with something like Dillo: you'd have much less distracting (as you put it, "eye candy") to draw attention away from the text on the page, which is most certainly welcome IMO.

[1]: https://sources.debian.org/src/gzilla/0.1.5-3/bytesink.doc/

PS: Maybe you could give us a hand contacting Jorge :-)