Show HN: Resurrecting the Dillo browser | Hacker News Reader

Show HN: Resurrecting the Dillo browser

dillo-browser.github.io

599 pointsrodarima174 comments

Hi, in mid 2022 the host dillo.org expired [0], taking down the website, mercurial repo, the mailing list and the email server used to reach the core developers of Dillo. Someone bought it and now serves a weird clone of the original page with missing content.

[0]: https://news.ycombinator.com/item?id=32448104

I felt sad as I didn't want it to die, so I got a copy of the repo from my hard disk, uploaded it to GitHub and decided to do some maintenance on the code to at least keep the build working. After some time, the folks at Atari Forum decided to use my repo to port it to the Atari platform and they managed to do it [1].

[1]: https://github.com/dillo-browser/dillo/issues/34

That gave me some motivation to work a bit more on the project to prevent it from dying. So I created an organization under the name of "dillo-browser" and made a new webpage [2] with a backup of the old one.

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

With the help of Andreas Kemnade which had access to the original server, we managed to backup most of the stuff from the original website (including non-reachable pages) which I uploaded to the Archive.

In the meanwhile, I combined the support for both OpenSSL (1.1 and 3) and mbedTLS (2 and 3) as well as proper CI with rendering tests. We now build Dillo for Ubuntu, FreeBSD and macOS!

I also became familiar with the plugin mechanism in Dillo, which allows any program that uses the standard input and output to become a plugin registered to a given protocol (like file://...). I did a simple one (which is just a bash script) to read local manual pages which is handy to follow links to other pages [3], but check also the ones Charles E. Lehner did which are more advanced [4].

[3]: https://github.com/dillo-browser/dillo-plugin-man [4]: https://groups.google.com/g/dillo/c/WGEMg7AXN4o/

As of today, I'm unable to contact the main developer, Jorge Arellano Cid, which has not interacted with the mailing list for some years now. Jorge, if you read this, please contact with me (you can find my email in the git commits).

Regarding the future of Dillo, I'm planning to (finally) do the 3.1 release after some testing, and for that it would be convenient to have the help of some users to get some feedback ;-)

If you want to contribute, feel free to open a PR or send a patch (via GitHub or by email, I don't care). Check also the current issues and pull requests to see what is pending or already being working on. I will probably setup a mailing list at some point too.

Thanks! Rodrigo.

Open articleView on HN

Wow, this is so stunning. Thanks a lot Rodrigo, and obviously to the dillo team, Jorge Arellano Cid, etc.!!

For others on Macs (I'm on an M1 under macOS 12.7), here's what worked for me:

- start by following the mac installation instructions here [0], specifically `brew install` the suggested packages + openssl (I used version 3)

- follow the "from git" installation instructions here [1] BUT, before running `./configure`, run these export commands [2] to make sure that the openssl files are found

- `make`, then `sudo make install` (like in the good old days). then run `dillo`.

- it just... works. and it's blazing fast. it's a 1.6mb binary, it supports ssl... it's brilliant. google search sorta works (with broken css). signing in to google is impossible without javascript..? yeah wow. a whole world to explore. THANKS!

[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

> Wow, this is so stunning. Thanks a lot Rodrigo, and obviously to the dillo team, Jorge Arellano Cid, etc.!!

Thanks!

> follow the "from git" installation instructions here [1] BUT, before running `./configure`, run these export commands [2] to make sure that the openssl files are found

I should add that to the install instructions for macOS, although in the CI it seems to work without the include flags (keep in mind I don't own a Mac, so my testing abilities are limited).

The world of low spec hardware really does need faster, lighter browsers. Too many times now have I configured an SBC, RPi, or even a laptop that’s just a few years old and been disappointed that, while everything else is wonderful and fast and smooth looking, it is browser performance that is the one thing holding me back.

I am resigned to the fact that some of my requirements really do mean I need a Ryzen 7 with 16GB of RAM. Sadly my biggest compute loads are for MS Teams and webmail.

> MS Teams

I really do empathize here, after having to use Teams for around 2 years. It's amazingly slow, confusing, buggy (it would crash the tab quite regularly), and just generally a perfect role model for what software shouldn't be[0].

I'm still quite amazed that Microsoft decided this was acceptable. I'm curious how Slack performs; perhaps they're not trying harder because there's no[t much] competition in this space ...?

[0]: (If I remember correctly, they were using AngularJS at the time, but I'm sure they're now using the regular React stack.)

For a lightweight MS Teams experience, try: https://github.com/fossteams/teams-cli (terminal client), https://github.com/cacticouncil/lounge-lizard (both Slack & Teams) or https://github.com/EionRobb/purple-teams (plugin for Pidgin).

A little reminder from the past eh? I had to sigh when I read that. I guess purple somewhat died when the companies started banning accounts left and right for using third party clients for using their services. In a few cases it also seems like those bans started happening, because companies wanted to shut down third party clients to make sure people can't bypass ads, but also unfortunately to keep them from harvesting data.

I kinda have to ask, what features can you enforce in rate limiting in a first party client that you can't enforce in a third party client?

While it is neat that people work on them, realistically these are not replacements for people wishing to have a lighter teams experience.

- Non of them are close to feature complete. As soon as you have to do more than chat (share files, do meetings, etc) they will let you down.

- In most corporate environments there is some extra layer of authentication involved I highly doubt these clients are able to handle.

The best way I have found to have a lighter teams experience is to simply use the web version as a PWA. This basically offers you all the features without the extended footprint of effectively running a second browser.

I think a look at the organizational and project management structure of the team(s) that develop Teams would reveal a lot. I doubt we can blame the tools they use.

I think a look at the organizational and project management structure of organizations that elect to use Teams would reveal a lot, also.

Yup. It's slow buggy. Tends to go into infinite loops. Sad really that it slows corporates so much.

> I'm curious how Slack performs

My colleagues and myself used Slack for years, were forced to use Teams for about 2 years because of our new parent company, and finally went back to Slack after we collectively quit that shitshow to start a new company.

While Slack isn't perfect either, it's miles better.

> While Slack isn't perfect either, it's miles better.

We switched from HipChat to Google Chat, which in my mind is pretty bad. Customers are often on Teams, which somehow manages to be MUCH MUCH worse. People kept telling me that Slack is much better than either Google Chat or MS Team, but after using it I can't say that I'd agree. Teams is clearly the worst, Slack is awful in its own way and Google Chat manages to be the best of the three, but mostly because the two others are so terrible.

It's clearly not an easy problem to solve, but I do wonder why all of these "enterprise" messaging/meeting/chat platforms are so terrible.

Twist is better still than Slack - they force everything into threads, so it becomes a reasonably browsable experience, and therefore possible to maintain async comms with. Slack still wins on integrations, though Twist has a few (including Zapier).

How do you find the thread with the conversation you need to carry on? That's the problem with Slack. Slack threads is where information goes to hide and die. "Ah, you did answer that two days ago? Where?"

There are two levels of organization - channels and threads, so it's not too bad to browse if reasonably setup. It also gives you an inbox with all of your unread threads, so that you can catch up quickly; and, you can mark a thread unread if you want to punt on it after reading.

> > MS Teams

> I really do empathize here, after having to use Teams for around 2 years. It's amazingly slow, confusing, buggy (it would crash the tab quite regularly), and just generally a perfect role model for what software shouldn't be[0].

Teams for Linux [1] also struggles with resources. Teams in general is an absolute mess. I would go further and say that most MS products are resource intensive buggy crap.

[1] https://github.com/IsmaelMartinez/teams-for-linux

That's an unfair characterisation, sometimes they're actively user hostile instead of just poorly designed.

One of my favourite ongoing jokes is Word, the program that exists for typing, 'randomly' deletes what you type:

https://techcommunity.microsoft.com/t5/word/word-online-web-...

https://answers.microsoft.com/en-us/msoffice/forum/all/how-t...

https://answers.microsoft.com/en-us/msoffice/forum/all/why-d...

https://answers.microsoft.com/en-us/msoffice/forum/all/word-...

https://answers.microsoft.com/en-us/msoffice/forum/all/text-...

https://answers.microsoft.com/en-us/msoffice/forum/all/word-...

https://answers.microsoft.com/en-us/msoffice/forum/all/when-...

https://answers.microsoft.com/en-us/msoffice/forum/all/word-...

https://answers.microsoft.com/en-us/msoffice/forum/all/why-i...

I have no idea how many engineers work on Office Online, but other than security bugs I cannot think of a more important issue to resolve.

> I'm still quite amazed that Microsoft decided this was acceptable

Their customers find it acceptable so it's OK for MS too.

If customers wouldn't find it acceptable they would use something else and we wouldn't be having this conversation. Maybe it helps that it comes with the Office suite and they already paid for it.

By the way, when a customer asks me how I want to do a video chat, almost always with screen sharing, I suggest Meet. If they mandate Teams, OK, I'll do Teams in a browser. Actually the best screen sharing seems to be Skype. It can zoom too. None of them can go full screen with no useless UI around the shared screen, tough luck. None of my customers are using Zoom anymore.

It’s sad. I have clear memories of browsing the web quite capably with windows 98 and 64MB of RAM (or less!) and now we can’t even do it with gigabytes.

You can still browse the web using Opera 12.18, which takes a little memory, but the HTML5 support will be poor. The web has evolved since then.

Opera 12 source code leaked, so you could even port it to new platforms. Sadly multiple exploits, html5, and finally licensing make it a dead end :(.

Licensing is the only real problem, but that never stopped people from doing things either.

Opera really should have open source Presto when they switched to Blink.

For some reason Linux users never got an update to 12.18 or 12.17. Latest one was 12.16.

To be fair, that was also a much lighter web. Even if you remove all the heavy javascript overload modern webpages will be heavier simply due to higher resolution images and other media.

It also highly depends on what you want to browse. HN for example will work just fine without much memory. Expecting YouTube to be as light as 90s websites is asking a bit much.

Having said that, I do agree that we have overshot, and many websites are way too heavy for their use case.

Sticking with YouTube as an example, assuming for a moment that whatever device you are using does have hardware decoding, so video playback isn't dragging down performance. It still is an extremely heavy website due to all the tracking shenanigans, interactive elements and the fact that it is an SPA based design. Alternative front-ends like invidious show it is possible and in the past Google did actually provide light versions of many of their web apps specifically for this sort of use case. Sadly that is no longer the case.

On my Windows 7 throwback computer running an i5 3570K (a damn near top-of-the-line CPU 10 years ago) with iGPU, in Waterfox YouTube stutters when fullscreen in 1080p (even with enhanced-h264ify and hardware video decoding as far as I can tell), both in YouTube and Firefox's pop-out player. Videos play smoothly in Invidious. Enhancer for YouTube™ has a popout/embed button I could test, but it was pulled from addons.mozilla.org due to being broken by YouTube changes (it still works for me on my main computer?).

To be honest, that could be just be some interaction with Waterfox specifically. It's not the first time I have encountered people having various issues with that firefox fork that other browsers don't encounter.

My test video is https://www.youtube.com/watch?v=lEuHOFgjrAo watched at 1080p60 in full screen. It's a reasonably good test of 60fps smoothness, though synthetic scrolling tests like TestUFO screen recordings might be better strictly speaking.

- Tried creating a new blank Waterfox profile with no changes except uBlock0. It drops frames, and the borders of the video (4:3 pillarboxes on a 16:9 screen) have a blue or green tint after I seek.

- Same result in a new blank Firefox ESR 115.6.0 (last Windows 7 release) profile with uBlock0.

- The YouTube embed player at https://www.youtube.com/embed/lEuHOFgjrAo, on my main Waterfox profile, runs as smoothly as Invidious (no stutters unless I'm interacting with the player UI).

On my Linux laptop with i3-3xxxm (a low-end? CPU even 10+ years ago) with iGPU, in Firefox YouTube plays fine in fullscreen in 1080p even without forcing h264. Enhancer removal is indeed a loss. Can try ImprovedTube.

My laptop is an i7 4xxx so it's one year newer than yours and intrinsically better specced, i7 vs i5. I have no problems with videos. It could be the NVIDIA card in my laptop or the OS. I'm on Debian 11 now, which is much newer than Windows 7. Drivers, codecs, etc are more recent and possibly more performant.

Check out more lightweight web browsers: NetSurf, Pale Moon, K-Meleon on Goanna, Otter Browser, Ultralight, as well as terminal apps: Carbonyl, Browsh, Links (it has a graphical mode too).

When you run a chromium in headless mode it doesn't make the browser any lighter. I think what the OP means is that you need to have a browser with the most important JS and CSS functionality to render modern websites, but without all the junk on top of it.

qutebrowser and nyxt would fit the bill better. to be honest I feel like nyxt is really cool, but I'm not sure if choosing a lisp was the right idea.

You can install Carbonyl in a VPS and use my Carbonyl Terminal (https://github.com/niutech/carbonyl-terminal) as a thin client for it.

qutebrowser binary is 424MB (on macOS, at least). Is that considered light?

Well my (un-googled) Chromium installation takes up 254MB, and I use that as my "big/corporate" browser so I would definitely not consider that light.

qutebrowser uses a qt-webengine library in the background, which is also basically a full chromium rendering engine, where not all features are exposed to the UI. It's only light in terms of UI. Just like a headless Chromium is only light on the UI side of things.

I tried using palemoon a few years ago, but many web pages just didn't work at all. I wonder if that's changed?

Check out yourself, the latest release was 2 weeks ago: https://www.palemoon.org/releasenotes.shtml

There even was elinks that used svgalib instead of X.

So one could use it on a machine that did not even have any desktop enviroment installed.

This was Links, not Elinks: https://en.wikipedia.org/wiki/Links_%28web_browser%29

This is gross exageration. A fairly decent low end desktop/laptop CPU with 4GB of RAM is enough to run MS Teams, and I don't really understand why one would on purpose use a webmail when there are more practical and efficient MTAs.

> I don't really understand why one would on purpose use a webmail when there are more practical and efficient MTAs.

Search on webmail is instantaneous. It was not on MTAs last time I tried. I remember someone always struggling to find old mails with his MTA while gmail would find it quite quickly.

Search is instantaneous on my gnome evolution MTA.

Mutt with cached email it's uber fast. Also, your mail inbox it's yours, forever.

Something must be really wrong when you need a 4GB machine to basically run Kopete/Pidgin+inline plugins at HD resolutions.

Given the circumstances, I am happy to read this. I own two ~2009 netbooks with Intel Atom N270 CPUs and 1GB of RAM each - running Firefox on those is ridiculous, whereas dillo will run very well on these.

I used to use dillo on my main desktop too, for browsing documentation that wasn't too heavy on CSS - having 20 to 40 tabs open would gobble up a lot of RAM in Firefox, whereas dillo happily stayed around 100MB no matter what I threw at it. My current desktop has enough RAM this not a concern any more, but I have fond memories of using dillo on memory-deficient machines and am a current user still.

Also, the lack of a Javascript engine makes it a very secure browser. Whenever I try to open a link that I am suspicious of, I do so in dillo.

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

> I used to use dillo on my main desktop too, for browsing documentation that wasn't too heavy on CSS - having 20 to 40 tabs open would gobble up a lot of RAM in Firefox, whereas dillo happily stayed around 100MB no matter what I threw at it. My current desktop has enough RAM this not a concern any more, but I have fond memories of using dillo on memory-deficient machines and am a current user still.

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 used to use dillo on my main desktop too, for browsing documentation that wasn't too heavy on CSS

Hah! I used an old Dell laptop that had a 1400x1050 (?) screen for this exact purpose with Dillo.

I was so mad that software stopped using Windows help files...they were so much more efficient!

> I was so mad that software stopped using Windows help files

Are you referring to HTML Help? I believe they rendered those with Internet Explorer; I'm willing to bet they still do for backwards compatibility.

I think they meant the Windows help files (HLP files). There seems to be a copy of the viewer here https://archive.org/details/microsoft_help_viewer_hlp

I also like dillo, but just as an option - have you tried netsurf as well? Likewise very lightweight.

dillo is more lightweight, although it doesn't support html5, while netsurf does support some html5. The website itself of dillo does not render the same in dillo.

Sure; I personally view it as a continuum of lynx..elinks..dillo..netsurf..........firefox is so. Just pointing out that netsurf is close to dillo.

I have. I only discovered it about two weeks ago, though. But so far, I do like it. Thank you!

> Also, the lack of a Javascript engine makes it a very secure browser. Whenever I try to open a link that I am suspicious of, I do so in dillo.

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).

I would say there is a chance that there are fewer vulnerabilities in the 60k~ lines of code contained within dillo than the in the however many million lines of code it takes to do anything with firefox or chromium.

running dillo in a bubblewrap container would probably be fine and not eat all of your available resources.

[i got my 60k loc number from running tokei in the dillo repo, doing the same in the gecko repo took multiple minutes and pegged 8 cores at 100%, might be a bug in tokei or maybe 21 million lines of code is just enormous]

I would recommend not opening suspicious pages in any browser at all. If you don't have the choice, then maybe download it with curl(1) and then inspect it with hexdump(1) or more(1), so you can see the content before sending it to an HTML parser.

Hey, nice to see you here Mr Stallman, thank you for all the hard work all these years :)

Mr Stallman would probably be using wget which is a GNU project, if not downloading directly from Emacs.

Or just use eww from Emacs.

For some reason I started using w3m with emacs integration years ago and am very comfortable with it. I know eww exists, but I think I only tried it once or twice.

> I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see https://git.savannah.gnu.org/git/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it.

Source: https://stallman.org/stallman-computing.html

Sure, Dillo in a sandbox is a big improvement over Dillo not in a sandbox (don’t forget an isolated X instance when you’re doing bubblewrap, ’cause FLTK 1.3 doesn’t support Wayland). I’d still feel more comfortable with mainstream browsers (and yes, they can handle many tabs on a still-small amount of memory).

Try Pale Moon, Basilisk or K-Meleon (on Goanna), which are more lightweight than Firefox. Other alternatives: Otter Browser (on Qt WebKit) or Ladybird (on LibWeb).

Which OS are you running on your netbooks? I recently acquired an old netbook with an Intel Atom processor and have been trying to find decent lightweight yet usable OS for it. I'd tried Debian but Firefox was too slow on it, maybe I should try again with Dillo now?

firefox with umatrix probably will be better for that hardware.

Zramup script:

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

Not Firefox, but Luakit might do it fine on single pages where JS is mandatory, such as, sadly, my country's goverment pages to do personal life related tasks.

The extension system[0] seems interesting; it reminds me of w3m's local CGI scripts. (From what I can tell, w3m's local CGI came first, but I don't know if it influenced DPI and/or if w3m's system had a predecessor too...)

For a short description of what w3m local CGI scripts can do:

* They can be used for implementing a man page viewer, as in w3mman. It seems Dillo has a similar plugin[1].

* w3m's bookmark system is implemented using local CGI; it seems Dillo's bookmarks are implemented as a dpi plugin too.

* 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.)

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 :)

[0]: https://dillo-browser.github.io/old/dpi1.html

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

> * w3m's bookmark system is implemented using local CGI; it seems Dillo's bookmarks are implemented as a dpi plugin too.

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.

As far as I remember, Arachne also did something similar.

I can confirm that the extension system is simple and nice to work with. I implemented a thin Go library for writing Dillo plugins (https://github.com/boomlinde/dpi) and made a plugin for the Gemini protocol (https://github.com/boomlinde/gemini.filter.dpi). I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

Thanks for your DPI work. I tested the gemini plugin and works very well.

My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers. I understand that is a tradeoff between usability and security, but I wish there was a better solution than that.

For now I uploaded Charles plugin written in shell script[1], which always trusts the certificate.

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

But I'm considering switching to the Go version if I can find a way to improve the UX.

Also, I kindly ask you to add the tag "dillo-plugin" so you can make Dillo plugins easily discoverable by searching for the tag in GitHub[2].

[2]: https://github.com/topics/dillo-plugin

> I believe that in recent versions of Dillo, even https is implemented as a DPI plugin.

This was done initially[3] (before 2007) but it was moved to the browser itself[4] in 2016.

[3]: https://github.com/dillo-browser/dillo/commits/afd2763caa56d...

[4]: https://github.com/dillo-browser/dillo/commit/bf5a7783f4a192...

> My only complain is that it keeps asking to confirm new keys every time a new server is visited which causes a lot of friction to explore several gemini servers.

Hmm, yeah, it's a trade off. It never annoyed me personally so I haven't given it much thought, but I could add some means to configure this behavior. There should be a commit shortly.

I've been meaning to change how it behaves when the certificate differs from the pinned one as well, because as it is now you manually have to remove the old pinned certificate from the file system when a certificate is replaced, which isn't great but at least should happen much less often.

> Also, I kindly ask you to add the tag "dillo-plugin" so you can make Dillo plugins easily discoverable by searching for the tag in GitHub[2].

Thanks for the heads up! Done.

> This was done initially[3] (before 2007) but it was moved to the browser itself[4] in 2016.

I see, so I had the chronology mixed up :).

I've updated the plugin so that you can switch between auto pinning and confirmation now, via a configuration file!

Thank you! :-)

I suggest contacting this guy Renato Bravo

https://www.youtube.com/channel/UCuklruLsO-CFoKK_rjNXrXg

https://www.youtube.com/watch?v=A6mb9qt2-3o

At video above Renato comments " ese es mi compañero Jorge " translated "that's my mate Jorge"

I found a Renato Bravo at Linkedin but I don't think is the same person.

Good idea. I think it may be this one[1] as it is also from the same region Valparaíso in Chile as Jorge. I don't use LinkedIn, but if someone can message him that would be great, thanks!

[1]: https://cl.linkedin.com/in/renatobravo

I found that "Renato Bravo" you link, but based on photo ressemblance I don't think they are the same person.

I used to test out sites on Dillo a lot to see if the experience was absolutely broken, but Dillo got too rusty so I went to checking Netsurf, w3m & elinks--so a revival is encouraging, especially for underpowered systems. Shame to see a project moving from a self-hosted Mercurial repository to a US-megacorparate-owned Git repository in Microsoft GitHub. …But at least the maintainer is committed to accepting email patches so folks aren’t required to create accounts / accept ToS with them.

> I used to test out sites on Dillo a lot to see if the experience was absolutely broken

Thanks! That should be done more often :-)

> Shame to see a project moving from a self-hosted Mercurial repository to a US-megacorparate-owned Git repository in Microsoft GitHub

Agreed. I decided that it was a good starting point moving to GitHub as a first start, to increase the chances the project gets more visibility and hopefully attract more contributions. I also trust GitHub to be alive for at least 5 to 10 more years, so I can put a redirect notice on the main webpage.

But yeah, I agree it would be better to self host or move to a federated forge. There is an issue to cover other options[1], but our current problem is that other forges like Codeberg don't have a way (as a free account) to run the CI pipelines in other platforms like MacOS. My idea was to eventually get hold on some real hardware so we can setup our own runners and also test in different architectures. Feel free to add other alternatives and I will take a look.

[1]: https://github.com/dillo-browser/dillo/issues/39

Keep in mind also, that because the project was previously self-hosted (including the mail server) that created a gigantic single point of failure (which failed very badly) that I'm trying to avoid.

> But at least the maintainer is committed to accepting email patches so folks aren’t required to create accounts / accept ToS with them.

Yeah, I'm thinking in creating a mailing list for that purpose, but apart from sourcehut (at least on alpha) and googlegroups, I don't know that many places that offer one free of charge.

> Shame to see a project moving from a self-hosted Mercurial repository to a US-megacorparate-owned Git repository in Microsoft GitHub

I get your point but it’s a bit of an odd complaint when the main reason it went away was that it was self hosted.

Fantastic work. I remember using Dillo in Puppy Linux from Live CDs back in the day.

What's the minimum compiler you target? Any big long term plans? Fuzzing? Moving to 'modern' build system like CMake?

Thanks!

> 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.

I would suggest switching to Meson instead of CMake.

How well does Meson handle complex cross-platform projects nowadays with multiple compilers? My team tried Meson about ~3yrs ago for an embedded system. We ended up moving to CMake instead after struggling to use it for armclang.

It’s better, but I believe link options still is controlled a little too much by meson magic.

I would suggest neither of those, nor ninja nor anything but make. Whatever sucks about a simple/shallow stack, what sucks about tall fat stacks is worse.

Speculation: I wonder if it's relatively easy to fuzz because the extension system already has things adapted to communicate over std in/out.

> targeting a lot of platforms

Wouldn't a project such as this one be a perfect candidate for Cosmopolitan?

> Cosmopolitan Libc makes C a build-anywhere run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS on AMD64 and ARM64 with the best possible performance.

https://justine.lol/cosmopolitan/

AFAIK, Cosmopolitan only works well if your program only depends on the libc. Even if you statically compile Dillo and the FLTK, you still would need a graphic Xorg server. For Linux and BSDs may work, but in macOS I think it won't, as for that platform you need the FLTK to link against macOS graphic libraries.

So out of curiosity i downloaded the code from github, built it and tried it. The default site is still dillo.org which crashed the browser when it tried to visit it. Same with duckduckgo.com (crashed). Actually the crash seems to be related to some assert failure with OpenSSL as recompiling Dillo with mbedSSL lets me visit these sites.

I tried to login and reply to this thread but for some reason it wouldn't login (no error or anything, after entering my username and password and clicking login, i'd remained logged out).

> The default site is still dillo.org which crashed the browser when it tried to visit it. Same with duckduckgo.com (crashed). Actually the crash seems to be related to some assert failure with OpenSSL as recompiling Dillo with mbedSSL lets me visit these sites.

Thanks for testing! I need to replace that with the new website. Could you open an issue on GitHub with some details of your system and OpenSSL version so I can try to reproduce it?

> I tried to login and reply to this thread but for some reason it wouldn't login (no error or anything, after entering my username and password and clicking login, i'd remained logged out).

This is likely because the cookies are disabled. See the Cookies docs:

https://dillo-browser.github.io/old/dillo3-help.html

https://dillo-browser.github.io/old/Cookies.txt

By default, Dillo has all cookies disabled. You have to either manually enable them per site (recommended) or globally:

  $ echo "news.ycombinator.com ACCEPT" >> ~/.dillo/cookies.txt

Then reload the dpi daemon to read the cookies config again:

  $ dpidc stop

Here[0], i submitted a bug report. The issue seems to be that some OpenSSL error isn't handled elsewhere, isn't removed from the error queue and the function with the assertion assumes the queue is empty.

I put a breakpoint in ERR_put_error in the version that comes with openSUSE though there isn't much debug info there to be had so i don't know what the error is (perhaps building OpenSSL from source code with debug info and having Dillo link against it would help). I found where the error comes in Dillo's side (check the comment i made in the bug report) but i'm not sure how that'd be fixed (aside from draining the error queue :-P) as i don't know why these calls are made in the first place.

[0] https://github.com/dillo-browser/dillo/issues/51

The problem is fixed now in master. It was caused by an attempt to shutdown the SSL session (which requires sending data) in a closed file descriptor, which is handled different between OpenSSL (no thread error queued) and LibreSSL (badsectoracula was using LibreSSL, which queues a thread error), and later causes an assert to trigger as it was not expecting any error in the queue. See[1] for more details.

[1]: https://github.com/dillo-browser/dillo/pull/59

Thanks again for the report, these type of issues are hard to reproduce without using different environments.

Nice to know Dillo still gets some love! I've got a lot of dillo plugins stored up that I managed to get from scuttlebutt a while ago(dillo-adb, dillo-dat, dillo-finger, dillo-git, dillo-gopher, dillo-gemini, dillo-ipfs, dillo-ssb and dillo-ytdl), and if you're interested I can zip them up and send it to you to be forked and worked on the project

I think most of them are from Charles, and he maintains a scuttlebutt-web interface, so you can download them from the homepage:

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!

Done! I actually had forgotten where I had got them, but it's great that their original repos are still up!

Sending much love. It's gratifying to see work on this continue, from seeds planted so long ago.

Thanks, raphlinus as in Raph Levien! I was just reading your bytesink document [1] from around 1997 and checking the history of gzilla, the precursor of Dillo.

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

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

I haven't been in touch with him in over 20 years, so have no idea where even to start. Best of luck with that!

Cool, I remember the name Dillo from ... way back when, I guess.

Interesting to see a mix of C and C++ in the same codebase, that always makes me curious if there is some internal/mental "pressure" to convert the C code to C++ since that does seem simpler in many ways if you're already using C++.

Also, does anyone know why the functions have a (to me, incredibly random) "a_" prefix? Like this, from "dicache.h" [1]:

    void a_Dicache_init (void);
    DICacheEntry *a_Dicache_get_entry(const DilloUrl *Url, int version);
    void *a_Dicache_png_image(const char *Type, void *Ptr, CA_Callback_t *Call, void **Data);
    void *a_Dicache_gif_image(const char *Type, void *Ptr, CA_Callback_t *Call, void **Data);

It's like a set of perfectly module-prefixed names, but then an additional prefix of "a_" has been added?

Edit: moved a comma.

[1]: https://github.com/dillo-browser/dillo/blob/master/src/dicac...

> Interesting to see a mix of C and C++ in the same codebase, that always makes me curious if there is some internal/mental "pressure" to convert the C code to C++ since that does seem simpler in many ways if you're already using C++.

The initial Dillo was fully written in C and it used GTK+. As it moved to FLTK it began rewriting parts in C++.

> Also, does anyone know why the functions have a (to me, incredibly random) "a_" prefix? Like this, from "dicache.h" [1]:

This is something Jorge came up with around 1999[1] for the C part, so the "a_" prefix states functions that are used outside the module (like public in C++), while the others are not. The choice of "a" is explained as:

> Why the "a_" prefix? > > Because it reads better "a_Menu_create" than "d_Menu_create" cause the first one suggests "a Menu create" function!

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

I don't think this alone is a good choice, as one should better use "static" to enforce it.

Wow! Thanks for responding, and providing such an awesome answer.

Yes, that sounds very much like a lack of "static", which makes it even more confusing. It sounds unlikely that someone would start a browser project in C and not know about static.

I would not agree that it reads "better", it just makes it more random. Adding a letter that at least hinted at what was meant would have been better, if we're for some reason are limited to a single letter (like "p_" for public).

Glad to see people are still stepping forward to take care of this project. Would love to see Gemini/Gopher support, though this is just a crazy idea from the comments section. I have no idea how feasible it is.

The Dillo+ (Dillo-Plus) project has already added Gopher and Gemini support to their port (they don't use the word fork) of Dillo:

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

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

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

This is already supported via plugins, check:

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

Will have to give this a shot on m68k Atari, it's been a long time!

Very nice!

Dillo is handy to have on lower specced machines. I've used it on m68k. I really should see why it doesn't compile on VAX, though...

Thanks!

Thanks very much for this! Dillo used to be more or less my main browser for quite a while, mostly with all images and CSS turned off. Its combination of quick GUI element toggling + config file for fine-tuning is excellent. A very versatile browser. Probably the only one thus far where I actually felt that I had a near-perfect "grasp" of my entire user experience. I could, and actually wanted to hand-tailor everything in this browser.

There is also an (outdated) Windows port called D+ [1]. I remember it crashing frequently on Windows 10, though.

1: https://sourceforge.net/projects/dplus-browser/

What's the benefit of Dillo versus, say, NetSurf?

A lot more lighterweight, and nowadays it's good to have less (it has less CSS compatibility, less html compatibility and no JS).

I'll have to do an in depth analysis first, I have very little experience with NetSurf.

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

Could you please also build Dillo for WebAssembly, so we can run it inside a Browser, without installing it?

edit: For Windows users, Dillo can just be installed in Ubuntu/WSL with "sudo apt install dillo", and just works. Warning: it's fast!

For those of you who use Dillo, what sites to you regularly view with it? It seems a lot of the web breaks without Javascript, right?

Not as much as you'd expect. For normal reading and browsing, only stuff behind cloudflare gives any issues (unless you're running a local proxy to handle ssl). "Webapps" obviously don't work, but for everything else it's just a maybe-uglier version of the normal internet. Dillo isn't as good at paywalls as links/elinks for some reason though.

> only stuff behind cloudflare gives any issues (unless you're running a local proxy to handle ssl).

This used to be a problem because Dillo didn't implemented SNI, but should be okay now. If you still have some site that doesn't connect with Dillo from git (there is an updated dillo-git AUR package in Arch Linux), please report it :-)

How does Dillo compare with historical web browsers (Netscape 4.x and earlier, MSIE 4.x and earlier) in terms of memory requirements?

I'm not sure how those other browsers are in terms of memory requirements, but Dillo runs fine with low memory (assuming you load normally sized pages). Here is an example where Dillo opened the single page HTML5 spec, which is 12.9 MiB of HTML, and google.com (sizes in KiB):

  % ps vp $(pgrep dillo)
      PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
   919059 pts/1    S+     0:01      0   458 59425 46884  0.2 dillo https://html.spec.whatwg.org/
   919584 pts/6    S+     0:00      0   458 28589 17360  0.1 dillo https://google.com

You know what would be really cool? if there is a way to use it as a lightweight alternative to Electron. Is that possible?

Assuming you don't use Javascript, kind of.

Dillo supports XEmbed, so you can run it embedded in another X windows. This is done by Claws Mail to render emails as HTML [1].

[1]: https://www.claws-mail.org/plugin.php?plugin=dillo

It would, but it's unlikely that the browser implements enough of Javascript or CSS to replace the engine for Electron and to be useful

There are better and lightweight alternatives for Electron: https://news.ycombinator.com/item?id=38687662

Thank you for the links!

After getting my own fair share of nostalgia (anyone remember running dillo on Damn Small Linux? I used to do that because all I had to run Linux in ~2003-2004 was a 486dx) and reading some of the comments, I think that Dillo could be a nice alternative to what Gemini was supposed to be.

If we could agree on some kind of "low-tech web" (a subset of html, a subset of css, a subset of javascript -- or maybe no javascript at all?) then Dillo could be the champion of this.

If a 486 can do TLS with mbedtls, you might be able to run cgmnlm as the Gemini client, albeit slowly.

I have faster machines nowadays, luckily :)

> If we could agree on some kind of "low-tech web" (a subset of html, a subset of css, a subset of javascript -- or maybe no javascript at all?) then Dillo could be the champion of this.

There is a "movement"[1] called the small web (smolweb?) which basically does what you are describing without being so restrictive as Gemini. AFAIK Dillo should be able to render most of those features properly.

[1]: https://smolweb.org/guidelines.html

Tbh, i just tried dillo again (it’s in the fedora repositories) but was saddened to find out it doesn’t support frames.

I was hoping it could be useful for having a light tool to read the single unix specification. There is a frame-less version, but frames are very handy for navigating those docs.

You could try importing some changes from DilloNG:

https://github.com/w00fpack/dilloNG

>> Dillo requires FLTK-1.3

Nice, lean & mean! I'm interested.

Very nice to hear!

Anybody knows what happened to Jorge A. Cid?

I have no news, but I hope HN could reach him :-)

I hope he's doing well, wherever he is. An active community around Dillo sparkles my wanting of hacking on it, Dpi (especially filters) is the best plugin system a browser could have imho.

Seems like, at least until 2022, he was still playing tennis tournaments in Club Stadio Italiano, located in Las Condes, Chile.

https://tourtenisquinta.cl/site/perfil?id=763

> Project objectives :

> Lower the barrier of entry to the web.

> Support old or small machines and slow connections.

Ram is cheap today, unfortunately the industry isn’t very humanitarian so they took advantage of that.

Now as the world expects fluent animation and eye candy, it’s virtually impossible to have a browser support as many sites as chrome and support older machines.

> Now as the world expects fluent animation and eye candy

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.

Hypothetically, could JavaScript support be added by using a lightweight engine, such as QuickJS?

Yes and it has been discussed in the mailing list before [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.

> I don't think the machines that Dillo is targeting would benefit from adding support for it

People tend to overestimate the resources required to run JS and have a miscalibrated sense of how slow they can/should expect it to be.

Firefox 1.x and 2.0 worked on machines with substantially worse specs than many of the ones that people are mentioning here (think: sub-GHz PIIIs with 128–256 MB of RAM), and substantial parts of Firefox itself are written in JS.

I haven't checked, but I'd bet that 2024-era QuickJS is also faster than 2004-era SpiderMonkey at executing the same script.

I was running FF (and netscape before that) on such machines, and they were about the worst possible program to run. My memory of browsers of the era was slow, buggy, and bloated. It was barely usable because the connection speed was by far the biggest bottleneck.

I was using dillo heavily at the time, when we didn't mind differences in rendering. After that I switched to konqueror. As the dhtml/js craze exploded, I caved in to ff when more often than not the websites didn't load or work as expected.

Probably but my guess based on the state of the web is that this a rabbit hole without end

If my (somewhat distant) understanding is correct, Dillo doesn't employ sandboxing like the other browsers. If this is the case, then adding support for JavaScript would be disastrous -- there are reasons why modern browsers use things like setuid, seccomp bpf, etc. etc.

Awesome, thanks for keeping it alive! Used it for ages on small live distros, an old Toshiba Libretto 110CT running Linux I used before netbooks became widely available, and on dialup or other slow connections when on-site at remote locations.

I'm collecting some pictures of Dillo on different computers, with the idea of adding them to a gallery. Here are some on the web:

[1]: https://en.wikipedia.org/wiki/Gateway_HandBook#/media/File:H...

[2]:http://damnsmalllinux.org/dmesg-screen-1.jpg

It would be nice to see it running in some remote location :-)

I also had it running at some point in my old Android phone (running Xorg directly on the framebuffer), but I don't know where I saved the picture.

I have it running under a n270 netbook with CWM and Hyperbola GNU/Linux :D

Dillo? I haven't heard that name in years!

I remember growing up I used the Dillo browser almost daily on my Raspberry Pi(2012). It was faster than Midori, and got me just enough information so that I could learn python from tutorials on the Raspberry Pi website.

It felt a bit strange then, when everyone around me was using Chrome. But looking back, it taught me a big lesson in how to maximize the use of minimal resources.

Thank you for picking up this project and maintaining it. Till date, there has been no true successor to Dillo that manages graphical web browsing with such little resources.

I used to use Dillo on a MacBook 3400c that I'd installed Linux on. That and Links. It's nice to see it again. I'm curious how much of the web is usable with it. Many of my favorite websites are still pretty basic HTML.

I'd never heard of Dillo before, but this is really cool! Huge props for taking this over. This truly illustrates the promise of open source.

Would be cool if it could give some kind of indication of what current percentage of HTML5, CSS3, and now-evergreen JS is, to set realistic expectations.

Dillo targets HTML4.1 and CSS2.1, although it incorporates some little features from HTML5 too. For CSS there is a list of "tests" [1] that more of less give you an idea of what works.

[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.

Finally, a browser with scroll bars! Nice work Jorge!

Real-life alternatives are a corner stone to a sane environment. Good to see that happening in the noscript/basic (x)html realm where Big Tech web engines killed everything for their own benefit.

But in the SDK space, ultra complex syntax languages should be avoid as f... and then c++ (and similar like rust/java/etc) should be avoided.

Great

I used this years ago and then forgot about it

Tested on arch first to set it up then installed on my raspberry pi zero w.

Tried all text only browsers on the pi zero and it is a pain. Dillo is far better.

You must create the dillorc file or add the default dillorc from the git page. Change the dillorc as you want, ie, start page, search page, colours etc.

well pleased

Is it pronounced “dil-ah” or “dil-oh”?

The former being the central Texas pronunciation and definitely without the “arma”!

I always pronounced it as the Spanish "armadillo" word /aɾmaðiʎo/ but Jorge uses "dil-oh":

https://youtu.be/A6mb9qt2-3o?t=212

Also, the video explains a lot about of the project, but in terrible quality :-D

Yes! Dillo enthuthiast here to say thanks and good luck.

What’s your approach to browser dev? Do you prefer to go wide or deep, for example the Ladybird project goes “deep” in that they choose an endpoint and try to get everything on the page working and whatnot. Maybe I’m rambling, but very cool!

I think the screenshots would look much better with another choice of font and icons.

Feel free to upload some more:

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

Thank you for doing this! Loved Dillo, back in the day

How does this do at rendering modern websites?

poorly it doesn't even pass acid2

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

Generally not great, as Dillo doesn't support Javascript and most modern sites are using it to create content. But if the site degrades well without JS it should render reasonably well.

I often use it to read Wikipedia articles. The layout is all jambled up, but the article content itself is fine. If a web site is low on layout, heavy on text, it usually works okay-ish. A lot of web sites these days, however, are an empty skeleton with a bit of Javascript code to load the content - these do not work in dillo, it has no Javascript engine; to a degree, I consider this a feature, but it makes large parts of the world wide web inaccessible.

Change the user agent to this one at ~/.dillo/dillorc:

      http_user_agent="Mozilla/5.0 (PSP (PlayStation Portable); 2.00)"

Then a lot of sites will load a compatible version.

Thank you! I'll give that a try.

Also, not web, but if you try a Gopher browser such as lynx, you can try gopher://magical.fish as a nice entry portal, it has tons of services. Also, gopher://gopherddit.com and gopher://hngopher.com

On Gemini, there's the Lagrange browser, and gemini://gemi.dev with a nice set of services too.

The modern web won't stop surprising me :-D

Basically an approximation of reader mode. Text and images will be fine, anything more advanced with CSS etc. will be ignored.

Well done! Dillo is a great little browser.

huge huge thanks, I still use Dillo!

Nice work!!

Does dillo support javascript?

nah all scripting is ignored

Reply on news.ycombinator.com