Yes, we have our own CI service. It is not public for now.

Thanks for the article and for including all the references.

We now adhere to https://semver.org/ as much as we can, where each of the three version numbers has a meaning, so it would be nice to include them all. I'll mention it in the next release (and probably add it to the changelog as well).

> I wondered if you were in communication with any of those developers, and if you have managed to bring in any of their code or improvements?

I'm in contact with the Mobilized Dillo developer and we exchange some patches from time to time.

> Are you using the latest FLTK?

The change from FLTK 1.3.X to 1.4.X breaks many things in Dillo. One of my priorities is to get it fixed ASAP but it will take a while. I'll probably ship experimental support for FLTK 1.4.X under a configure flag in the next 3.3.0 release so I don't delay it for too long.

In the short term you can disable CSS or images from the menu. You can also disable specific image decoders from the configuration with the "ignore_image_formats" option.

- It is extremely slow and resource intensive. Opening any link/page takes at least 3 seconds on my fastest computer, but the content is mostly text with images.

- It cannot be used without JS (it used to be at least readable, now only the issue description loads). I want the bug tracker to be readable from Dillo itself. There are several CLI options but those are no better than just storing the issues as files and using my editor.

- It forces users to create an account to interact and it doesn't interoperate with other forges. It is a walled garden owned by a for-profit corporation.

- You need an Internet connection to use it and a good one. Loading the main page of the dillo repo requires 3 MiB of traffic (compressed) This is more than twice the size of a release of Dillo (we use a floppy disk as limit). Loading our index of all opened issues downloads 7.6 KiB (compressed).

- Replying by email mangles the content (there is no Markdown?).

- I cannot add (built-in) dependencies across issues.

I'll probably write some post with more details when we finally consider the migration complete.

I believe that storing the issues in plain text in git repositories synced across several git servers is more robust and future-proof, but time will tell.

Having a simple storage format allows me to later on export it to any other service if I change my mind.

https://dillo-browser.org/release/3.1.0/commits-author.png

The initial release was around the 15th of December, 1999. It's going to be 26 years ago: https://dillo-browser.org/25-years/index.html

https://www.bttr-software.de/forum/board_entry.php?id=10797

Unfortunately, none of those ports made their way back to the main project. However, if there is enough interest I would be willing to merge them. I'm not very familiar with DOS/FreeDOS, so probably someone would have to help us to update the changes, but probably doable between 3.0 and 3.2.0.

https://dillo.org/post-sitemap.xml

At some point I should investigate if we can fill a complaint to get it taken down at least. Here is more info: https://dillo-browser.org/dillo.org.html

https://git.dillo-browser.org/buggy/

It fetches the issues from GitHub and stores them in /index.md in Markdown format, with some special headers. I then keep the issues in a git repository:

https://git.dillo-browser.org/bugtracker/

So we have a very robust storage that we can move around and also allows me to work offline. When I want to push changes, I just push them via git, then buggy(1) runs in the server via a web hook. This also tracks the edit changes.

While typing, I often use `find . -name '*.md' | entr make` which regenerates the issues that have changed into HTML as well as the index, then sends a SIGUSR1 to dillo, which reloads the issue page.

The nice thing of allowing arbitrary HTML inline is that I can write the reproducers in the issue itself:

https://git.dillo-browser.org/bugtracker/tree/501/index.md#n...

Closing an issue is just changing the header "State: open" by "State: closed", often with a comment pointing to the merged commit.

Probably the best indicator of which features are supported is to pass as many tests as possible from WPT that cover that feature.

I did some experiments to pass some tests from WPT, but many of them require JS to perform the check (I was also reading how you do it in blitz). It would probably be the best way forward, so it indicates what is actually supported.

Later they also blocked other non-JS browsers like links or w3m, so I assume they no longer care. They used to maintain several frontends that worked in really old devices.

I don't think there is any User-Agent that works today, however you can still use the Google index via other search indexes that can fetch Google results without JS (for example Startpage still works). However, it is probably a good idea to have more options available that have their own independent index engine (for example Mojeek). Seirdy has a very good list: https://seirdy.one/posts/2021/03/10/search-engines-with-own-...

We are currently in the process of moving Dillo away from GitHub:

- New website (nginx): https://dillo-browser.org/

- Repositories (C, cgit): https://git.dillo-browser.org/

- Bug tracker (C, buggy): https://bug.dillo-browser.org/

They should survive HN hug.

The CI runs on git hooks and outputs the logs to the web (private for now).

All services are very simple and work without JS, so Dillo can be developed fully within Dillo itself.

During this testing period I will continue to sync the GitHub git repository, but in the future I will probably mark it as archived.

See also:

- https://fosstodon.org/@dillo/114927456382947046

- https://fosstodon.org/@dillo/115307022432139097

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.

Comments URL: https://news.ycombinator.com/item?id=45243201

Points: 4

# Comments: 2