6 ms·

Maintainer here. We are currently in the process of moving Dillo away from GitHub: - New website (nginx): https://dillo-browser.org/ https://dillo-browser.org

by rodarima 11mo ago

Maintainer here. We are currently in the process of moving Dillo away from GitHub: - New website (nginx): https://dillo-browser.org/ https://dillo-browser.org/ - Repositories (C, cgit): https://git.dillo-browser.org/ https://git.dillo-browser.org/ - Bug tracker (C, buggy): https://bug.dillo-browser.org/ 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/114927456382947046 - https://fosstodon.org/@dillo/115307022432139097 https://fosstodon.org/@dillo/115307022432139097

fishgoesblub 11mo ago
Why cgit and not something nice like Gitea, or Forgejo?
- winningChild 11mo ago
  [dead]
- thesuitonym 11mo ago
  My guess is gitea and forgejo don't render well in Dillo.
- Bolwin 11mo ago
  They're like 10x more complex and you don't need most of their functionality for just a frontend. That said I wish there was something a little better than cgit
  - messe 11mo ago
    Have you looked at self hosting sourcehut (https://sourcehut.org/ https://sourcehut.org/)?
    - rodarima 11mo ago
      Yes, but all those services have the same main problem: a single point of failure. They also don't work offline. 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.
      - mason_mpls 11mo ago
        What a breath of fresh air, I’m watching people dance with plain text behind the bars of Jira, GitLab & Teams
  - catwell 11mo ago
    If you're looking for something light, self-hostable and a bit more "social" (i.e. with pull requests and bug creation from the web) I recommend looking at https://tangled.org https://tangled.org It doesn't render perfectly in Dillo but basic features appear to work. However I really like what you've done here for Dillo as well.
mixmastamyk 11mo ago
Hmm, it is tiny on my highres screen. Anyone know how to double the scale?
- O1111OOO 11mo ago
  Check out: /etc/dillo/dillorc There are options here for (my setup below): geometry=1600x900 increase font_factor=1.75 bg_color=0xFAF9F6 Start and Home pages too.
  - O1111OOO 11mo ago
    update - this should be the core directory for changes, config, etc: ~/.dillo/ (per user directory) dillorc is in here too and overrides /etc/dillo (the system-wide directory)
nicoburns 11mo ago
Is there some kind of status tracker somewhere. That describes which web standards are supported?
- rodarima 11mo ago
  Not really. There was this list but it is outdated: https://dillo-browser.org/old/css_compat/index.html https://dillo-browser.org/old/css_compat/index.html 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.
  - nicoburns 11mo ago
    > but many of them require JS to perform the check Yeah, if we add JS support to Blitz then one of our initial targets will probably be "enough to run the WPT test runner". > I was also reading how you do it in blitz We are able to run ~20k tests (~30k subtests) from the `css` directory without JS which is IMO more than enough for it to be worthwhile. > Probably the best indicator of which features are supported is to pass as many tests as possible from WPT that cover that feature. Yes, and no. It definitely is an indicator to some extent. But in implementing floats recently I've a lot of the web suddenly renders correctly, but I'm only passing ~100 more tests!
eikenberry 11mo ago
What is the bug tracking software you are using?
- saint_yossarian 11mo ago
  https://git.dillo-browser.org/buggy/ https://git.dillo-browser.org/buggy/
- rodarima 11mo ago
  I wrote my own: https://git.dillo-browser.org/buggy/ https://git.dillo-browser.org/buggy/ It fetches the issues from GitHub and stores them in <number>/index.md in Markdown format, with some special headers. I then keep the issues in a git repository: https://git.dillo-browser.org/bugtracker/ 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#n23 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.
  - keyle 11mo ago
    That is very cool.
  - khimaros 11mo ago
    maybe of interest: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug
  - 1718627440 11mo ago
    > SIGUSR1 to dillo That's an excellent program !
imglorp 11mo ago
Repeating a warning from github about the old URL - dillo.org is not controlled by the devs and could become a malware route, is that right?
- rodarima 11mo ago
  Yes, thanks for the reminder. This is what they write about: https://dillo.org/post-sitemap.xml 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://dillo-browser.org/dillo.org.html
  - huflungdung 11mo ago
    [dead]
znpy 11mo ago
I have the fondest memories of running dillo under netbsd on my hp jornada 728, around 2008 -2009… thank you for all the work!
- jmclnx 11mo ago
  And dillo still works great on NetBSD :) I think it is becoming more important to i386 BSD, especially since i386 OpenBSD can no longer build Firefox, Seamonkey and IIRC Chrome on i386 systems. I have been using dillo more and more as time goes on, plus you can get plugins for Gemini Protocol and Gopher.
  - anthk 11mo ago
    gemini://gemi.dev with News Waffle it's a godsend to read bloated news sites, both in English and in Spanish. Also, gopher://magical.fish The register, some bloated Spanish such as Xataka and Genbeta...
- MarsIronPI 11mo ago
  I remember installing Debian on my OLPC XO-1. Dillo and Netsurf were the only browsers that I even tried running on that thing (w. 512MB RAM). Netsurf had better compatibility, but Dillo was noticeably faster and more responsive. Truly a pleasure to use when it supported the site I was on.
sylware 11mo ago
If they could move away from c++ too.... like plain and simple C like the netsurf browser?
- anthk 11mo ago
  DIllo is much lighter and it supports Gopher, Gemini, Info, Man and potentially in a further future, URL rewritting plugins.
  - kragen 11mo ago
    Yeah, but C++ compilers are pretty heavyweight. That said, rewriting a C++ codebase in C is about as likely as rewriting it in Java, so it wasn't a good suggestions.
    - a96 11mo ago
      Rewriting it in Rust is the obvious choice.
      - anthk 11mo ago
        The worst choice. Rust doesn't compile under OpenBSD i386. Dillo runs even on PPC and some m68k platforms. If any, maye FLTK + C. On C++ compilers, clang++ it's much faster than g++ under legacy platforms. Clang uses far less RAM and CPU than GCC while compiling. I know we have no cproc/cparser or tcc for C++, but at least clang it's usable with 1GB of RAM.
        sylware 11mo ago
        cproc/tcc/scc/etc are C compilers not c++. If you want to compile a recent c++ compiler (gcc/clang), you must have already a c++ compiler (one of the biggest mistake in open source software ever was to move gcc to c++, clang doing the wrong thing right from the start...). You can start to compile gcc 4.7.4, the last gcc compiler with buggy c++98 you could compile with a C compiler (you will need to patch it, and even unroll its full SDK), then you will have to compile at least 2 gccs to reach the last gcc. This insane mess is due to the infinite versions of c++ ISO "standard", introducing tons of feature creep which will force you to "upgrade" (mostly no real good reasons, namely developer tantrums, or planned obsolescence). This is disgusting, Big Tech grade abomination of software engineering, shame on the people who did that and those in power who are not trying to fix it (probably the GCC steering committee).
mtillman 11mo ago
It still has great looking icons, a proper boarder bevel, and real scroll bars. Thank you!
- jagged-chisel 11mo ago
  I’m imagining a comfy bevel on the bench outside your hostile where your boarders can sit happily.
  - hcs 11mo ago
    I'm imagining a place for boarders to stay confrontationally
    - disqard 11mo ago
      Defiantly true.
  - axiolite 11mo ago
    > outside your hostile I don't imagine you'll get much business at your hostile... They'd probably rather go to hotels or youth hostels instead.
  - deleted 11mo ago
    [deleted]
  - jesperwe 11mo ago
    And read scrolls while having a a cocktail in the bar.
puttycat 11mo ago
Can you say more about why you're moving away from GitHub?
- rodarima 11mo ago
  Many reasons, in no particular order: - 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.
  - dbtc 11mo ago
    I appreciate these priorities!
  - hoistbypetard 11mo ago
    > I want the bug tracker to be readable from Dillo itself. I’m glad you’re prioritizing this and that you consider this a reason to choose a different forge.
  - a96 11mo ago
    It's an excellent choice. Though Microsoft alone should be a sufficient answer. Many people will never interact with github projects because it requires an account with the most unethical company that ever existed. https://sfconservancy.org/GiveUpGitHub/ https://sfconservancy.org/GiveUpGitHub/
mhitza 11mo ago
Haven't got the chance to play around with it, but looks fun. And maybe something cool to use to repackage into an alternative Tor/I2P browser for hidden websites. What's holding back CSS and HTML support (at their specific versions) and is there interest of expanding that support in full, but lacking resources?
- lhmiles 11mo ago
  Oh tor client is good idea
bromuro 11mo ago
The website doesn’t display correctly when I increase the browser’s font size, and it doesn’t work in reader mode. :( I have poor eyesight, so I can’t read the content.
- Maxion 11mo ago
  Huh? For me it works fine? Are you sure you are on https://dillo-browser.org/ https://dillo-browser.org/ ?
  - dpkirchner 11mo ago
    I have the same problem, and yeah, that's the site. Tapping the button to increase the font size just zooms the page in so now I have to scroll horizontally to read the content. Something on the page is preventing natural reflowing, I could probably figure out what if I was on my desktop. My hunch is it's the row of images.
    - 1718627440 11mo ago
      It is because of this: .main { margin: 2em auto; width: 50em; } So the whole page width just increases with the font size. I think they should have used max-width instead. This also causes problems, when you resize your browser window.
al_be_back 11mo ago
happy anniversary! > Uses the fast and bloat-free FLTK GUI library [1] Bloat as a moat, is sadly the strategy of much of the web or apps in recent years. High Performance has shifted into how fast we can serve bloat. Efficiency has become about pushing the most bloat with least time. Pages are bloated, sites are bloated, browsers are bloated, browser-market is bloated (two-a-dime! or three for free). The whole damn web is a big bloat. wtf happened. [1] https://dillo-browser.github.io/ https://dillo-browser.github.io/
- 1vuio0pswjnm7 11mo ago
  "High performance has shifted into how fast we can serve bloat." If remove ads and behavioural tracking, speed is faster But goal of Big Tech, who make the popular browsers, is to make speed faster (fast enough) _with_ ads and tracking User wants fast speed. User does not want ads and tracking. Big Tech wants users in order to target with ads and tracking. Big Tech tries top deliver fast speed to keep users interested User can achieve fast speed _without_ ads and tracking I do it every day. I do not use a large propular browser to make HTTP requests nor to read HTML
- mason_mpls 11mo ago
  More memory means more memory for my website to take up!
threemux 11mo ago
Hi there - love Dillo. I use it on NetBSD and it works great. Once you're off GitHub will there be a way to get notified of releases? I use GitHub's RSS feeds for that now.
kragen 11mo ago
That's wonderful to see!
1718627440 11mo ago
How can you report something to the bug tracker?
TheRealPomax 11mo ago
If you're putting everything on the same domain, I do hope you made it impossible for someone to ever get their hands on dillo-browser.org ever again.

fishgoesblub 11mo ago

Why cgit and not something nice like Gitea, or Forgejo?

winningChild 11mo ago
[dead]
thesuitonym 11mo ago
My guess is gitea and forgejo don't render well in Dillo.
Bolwin 11mo ago
They're like 10x more complex and you don't need most of their functionality for just a frontend. That said I wish there was something a little better than cgit
- messe 11mo ago
  Have you looked at self hosting sourcehut (https://sourcehut.org/ https://sourcehut.org/)?
  - rodarima 11mo ago
    Yes, but all those services have the same main problem: a single point of failure. They also don't work offline. 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.
    - mason_mpls 11mo ago
      What a breath of fresh air, I’m watching people dance with plain text behind the bars of Jira, GitLab & Teams
- catwell 11mo ago
  If you're looking for something light, self-hostable and a bit more "social" (i.e. with pull requests and bug creation from the web) I recommend looking at https://tangled.org https://tangled.org It doesn't render perfectly in Dillo but basic features appear to work. However I really like what you've done here for Dillo as well.

mixmastamyk 11mo ago

Hmm, it is tiny on my highres screen. Anyone know how to double the scale?

O1111OOO 11mo ago
Check out: /etc/dillo/dillorc There are options here for (my setup below): geometry=1600x900 increase font_factor=1.75 bg_color=0xFAF9F6 Start and Home pages too.
- O1111OOO 11mo ago
  update - this should be the core directory for changes, config, etc: ~/.dillo/ (per user directory) dillorc is in here too and overrides /etc/dillo (the system-wide directory)

nicoburns 11mo ago

Is there some kind of status tracker somewhere. That describes which web standards are supported?

rodarima 11mo ago
Not really. There was this list but it is outdated: https://dillo-browser.org/old/css_compat/index.html https://dillo-browser.org/old/css_compat/index.html 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.
- nicoburns 11mo ago
  > but many of them require JS to perform the check Yeah, if we add JS support to Blitz then one of our initial targets will probably be "enough to run the WPT test runner". > I was also reading how you do it in blitz We are able to run ~20k tests (~30k subtests) from the `css` directory without JS which is IMO more than enough for it to be worthwhile. > Probably the best indicator of which features are supported is to pass as many tests as possible from WPT that cover that feature. Yes, and no. It definitely is an indicator to some extent. But in implementing floats recently I've a lot of the web suddenly renders correctly, but I'm only passing ~100 more tests!

eikenberry 11mo ago

What is the bug tracking software you are using?

saint_yossarian 11mo ago
https://git.dillo-browser.org/buggy/ https://git.dillo-browser.org/buggy/
rodarima 11mo ago
I wrote my own: https://git.dillo-browser.org/buggy/ https://git.dillo-browser.org/buggy/ It fetches the issues from GitHub and stores them in <number>/index.md in Markdown format, with some special headers. I then keep the issues in a git repository: https://git.dillo-browser.org/bugtracker/ 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#n23 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.
- keyle 11mo ago
  That is very cool.
- khimaros 11mo ago
  maybe of interest: https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug
- 1718627440 11mo ago
  > SIGUSR1 to dillo That's an excellent program !

imglorp 11mo ago

Repeating a warning from github about the old URL - dillo.org is not controlled by the devs and could become a malware route, is that right?

rodarima 11mo ago
Yes, thanks for the reminder. This is what they write about: https://dillo.org/post-sitemap.xml 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://dillo-browser.org/dillo.org.html
- huflungdung 11mo ago
  [dead]

znpy 11mo ago

I have the fondest memories of running dillo under netbsd on my hp jornada 728, around 2008 -2009… thank you for all the work!

jmclnx 11mo ago
And dillo still works great on NetBSD :) I think it is becoming more important to i386 BSD, especially since i386 OpenBSD can no longer build Firefox, Seamonkey and IIRC Chrome on i386 systems. I have been using dillo more and more as time goes on, plus you can get plugins for Gemini Protocol and Gopher.
- anthk 11mo ago
  gemini://gemi.dev with News Waffle it's a godsend to read bloated news sites, both in English and in Spanish. Also, gopher://magical.fish The register, some bloated Spanish such as Xataka and Genbeta...
MarsIronPI 11mo ago
I remember installing Debian on my OLPC XO-1. Dillo and Netsurf were the only browsers that I even tried running on that thing (w. 512MB RAM). Netsurf had better compatibility, but Dillo was noticeably faster and more responsive. Truly a pleasure to use when it supported the site I was on.

sylware 11mo ago

If they could move away from c++ too.... like plain and simple C like the netsurf browser?

anthk 11mo ago
DIllo is much lighter and it supports Gopher, Gemini, Info, Man and potentially in a further future, URL rewritting plugins.
- kragen 11mo ago
  Yeah, but C++ compilers are pretty heavyweight. That said, rewriting a C++ codebase in C is about as likely as rewriting it in Java, so it wasn't a good suggestions.
  - a96 11mo ago
    Rewriting it in Rust is the obvious choice.
    - anthk 11mo ago
      The worst choice. Rust doesn't compile under OpenBSD i386. Dillo runs even on PPC and some m68k platforms. If any, maye FLTK + C. On C++ compilers, clang++ it's much faster than g++ under legacy platforms. Clang uses far less RAM and CPU than GCC while compiling. I know we have no cproc/cparser or tcc for C++, but at least clang it's usable with 1GB of RAM.
      - sylware 11mo ago
        cproc/tcc/scc/etc are C compilers not c++. If you want to compile a recent c++ compiler (gcc/clang), you must have already a c++ compiler (one of the biggest mistake in open source software ever was to move gcc to c++, clang doing the wrong thing right from the start...). You can start to compile gcc 4.7.4, the last gcc compiler with buggy c++98 you could compile with a C compiler (you will need to patch it, and even unroll its full SDK), then you will have to compile at least 2 gccs to reach the last gcc. This insane mess is due to the infinite versions of c++ ISO "standard", introducing tons of feature creep which will force you to "upgrade" (mostly no real good reasons, namely developer tantrums, or planned obsolescence). This is disgusting, Big Tech grade abomination of software engineering, shame on the people who did that and those in power who are not trying to fix it (probably the GCC steering committee).

mtillman 11mo ago

It still has great looking icons, a proper boarder bevel, and real scroll bars. Thank you!

jagged-chisel 11mo ago
I’m imagining a comfy bevel on the bench outside your hostile where your boarders can sit happily.
- hcs 11mo ago
  I'm imagining a place for boarders to stay confrontationally
  - disqard 11mo ago
    Defiantly true.
- axiolite 11mo ago
  > outside your hostile I don't imagine you'll get much business at your hostile... They'd probably rather go to hotels or youth hostels instead.
- deleted 11mo ago
  [deleted]
- jesperwe 11mo ago
  And read scrolls while having a a cocktail in the bar.

puttycat 11mo ago

Can you say more about why you're moving away from GitHub?

rodarima 11mo ago
Many reasons, in no particular order: - 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.
- dbtc 11mo ago
  I appreciate these priorities!
- hoistbypetard 11mo ago
  > I want the bug tracker to be readable from Dillo itself. I’m glad you’re prioritizing this and that you consider this a reason to choose a different forge.
- a96 11mo ago
  It's an excellent choice. Though Microsoft alone should be a sufficient answer. Many people will never interact with github projects because it requires an account with the most unethical company that ever existed. https://sfconservancy.org/GiveUpGitHub/ https://sfconservancy.org/GiveUpGitHub/

mhitza 11mo ago

Haven't got the chance to play around with it, but looks fun. And maybe something cool to use to repackage into an alternative Tor/I2P browser for hidden websites. What's holding back CSS and HTML support (at their specific versions) and is there interest of expanding that support in full, but lacking resources?

lhmiles 11mo ago
Oh tor client is good idea

bromuro 11mo ago

The website doesn’t display correctly when I increase the browser’s font size, and it doesn’t work in reader mode. :( I have poor eyesight, so I can’t read the content.

Maxion 11mo ago
Huh? For me it works fine? Are you sure you are on https://dillo-browser.org/ https://dillo-browser.org/ ?
- dpkirchner 11mo ago
  I have the same problem, and yeah, that's the site. Tapping the button to increase the font size just zooms the page in so now I have to scroll horizontally to read the content. Something on the page is preventing natural reflowing, I could probably figure out what if I was on my desktop. My hunch is it's the row of images.
  - 1718627440 11mo ago
    It is because of this: .main { margin: 2em auto; width: 50em; } So the whole page width just increases with the font size. I think they should have used max-width instead. This also causes problems, when you resize your browser window.

al_be_back 11mo ago

happy anniversary! > Uses the fast and bloat-free FLTK GUI library [1] Bloat as a moat, is sadly the strategy of much of the web or apps in recent years. High Performance has shifted into how fast we can serve bloat. Efficiency has become about pushing the most bloat with least time. Pages are bloated, sites are bloated, browsers are bloated, browser-market is bloated (two-a-dime! or three for free). The whole damn web is a big bloat. wtf happened. [1] https://dillo-browser.github.io/ https://dillo-browser.github.io/

1vuio0pswjnm7 11mo ago
"High performance has shifted into how fast we can serve bloat." If remove ads and behavioural tracking, speed is faster But goal of Big Tech, who make the popular browsers, is to make speed faster (fast enough) _with_ ads and tracking User wants fast speed. User does not want ads and tracking. Big Tech wants users in order to target with ads and tracking. Big Tech tries top deliver fast speed to keep users interested User can achieve fast speed _without_ ads and tracking I do it every day. I do not use a large propular browser to make HTTP requests nor to read HTML
mason_mpls 11mo ago
More memory means more memory for my website to take up!

threemux 11mo ago

Hi there - love Dillo. I use it on NetBSD and it works great. Once you're off GitHub will there be a way to get notified of releases? I use GitHub's RSS feeds for that now.

kragen 11mo ago

That's wonderful to see!

1718627440 11mo ago

How can you report something to the bug tracker?

TheRealPomax 11mo ago

If you're putting everything on the same domain, I do hope you made it impossible for someone to ever get their hands on dillo-browser.org ever again.