Show HN: Dillo 3.1.0 released after 9 years (dillo-browser.github.io)
As commented before[1], I've been working on the past months to get the Dillo
back to life and today I'm happy to release the 3.1.0 version, after almost 9
years since the last one.
[1]: https://news.ycombinator.com/item?id=38847613
During this time:
- A new mailing list was created[2] which is beginning to get some messages and patches. It is available in gmane via NNTP at gmane.comp.web.dillo.devel.
[2]: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman...
- A LiberaPay page[3] which received the first donations (thanks!).
[3]: https://liberapay.com/dillo/
- Some more bugs where fixed and new features where added (details in the release page and/or changelog).
Thanks to all the people that contributed with patches and tests. Now let's see if we can make it land in some distros!
111 comments
[ 4.5 ms ] story [ 231 ms ] threadLike a js-mini that doesn't have the bells and whistles like opengl, bluetooth and midi support
Shockingly, edbrowse parses JS pages well enough to login and post in some sites.
Apart from CJK, there are other issues with fonts that we have to solve too. Feel free to open more issues: https://github.com/dillo-browser/dillo/issues
I might submit a photo with the device running Dillo.
I don't I'll ever see anything like it again, despite 10-100x the computing power and 10-100x the bandwidth increases.
http://links.twibright.com/
https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman...
Here is the bad rule:
This causes Dillo to render the text in grey from the second paragraph on.
In that case, maybe we could get a query parameter along the lines of "useValidMarkup=1" (or a user setting might be better) to produce valid HTML for the benefit of niche browsers that expect it while preserving the current (invalid but stable) markup by default.
I don't think so, but if it does I recommend they instead stick to the HTML (4.01 or 5) spec by default.
> In that case, maybe we could get a query parameter along the lines of useValidMarkup=1" (or a user setting might be better) to produce valid HTML for the benefit of niche browsers that expect it while preserving the current invalid but stable) markup by default.
They can guess the browser by the User-Agent and serve a "patched" version if needed (bluedwarf.top does it). But I would recommend doing against this, as it reduces the incentive for clients to get fixed and moves the responsibility to webmasters.
And here are more: https://dillo-browser.github.io/gallery/index.html
[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...
[1]: https://news.ycombinator.com/item?id=38853053
I didn't try it out, though, i just read it in the documentation.
And the CSS wizards who remove the underline on the link, so when I'm helping people over the phone they can't find the link :'-(
And the damn trackers :(
[1]: https://aur.archlinux.org/packages/dillo-git
you can do this to compile it on macos (tested on M1):
install https://www.xquartz.org/ to have X11
brew install fltk libjpeg #you might also need openssl@3 but unsure
git clone https://github.com/crossbowerbt/dillo-plus/; cd dillo-plus
# update the 1.3.8_1 fltk version sed 's/1.3.8_1/1.3.9/g' Makefile.options.MacOS > Makefile.options
make -j8
# find binary in ./src/dillo
maybe someone should make a brew package (for both this and dillo-plus)..?
Here are some cherry picks:
- Dillo on the Kindle: https://fosstodon.org/@dillo/112181258739093008
- Dillo on an old Samsung phone: https://fosstodon.org/@dillo/112327798958777998
Dillo original goal[1] is to provide access to the web to places with very bad internet speed or latency as well as old or resource constrained computers.
[1]: https://dillo-browser.github.io/old/interview.html
I don't think we will ever implement JS support, as that would increase a lot the minimum requirements to run Dillo and make the attack surface on the browser much bigger.
For low bandwidth or slow computers, also try Carbonyl Terminal (https://github.com/niutech/carbonyl-terminal).
With Dillo I'd just had as a 'new' feature, audio and video links opened with xdg-open (or any other plumber) and better Unicode support, which might be reduced due to FLTK, but FLTK itself calls XFT, so I doudt it, as I happened to perfectly open Motif based stuff compiled against XFT with the full coverage of the Unifont font set.
[0]: https://sr.ht/~bptato/chawan/
Some kind strangers have created unstable packages on the AUR[0] and NixOS[1]. The former is quite recent, the latter is somewhat older.
> Have you considered support for UTF-8 half-blocks or Sixel for graphics?
In fact, there is experimental support for the sixel & kitty protocols, but for now it's slow, ugly, and only works with PNG.
You can play around with it by putting the following in ~/.config/chawan/config.toml:
but you will see that it's undocumented for a reason...[0]: https://aur.archlinux.org/packages/chawan-git
[1]: https://search.nixos.org/packages?channel=unstable&show=chaw...
You can browse spartan pages with a Dillo plugin[1], as well as Gopher, Gemini and others.
[1]: https://dillo-browser.github.io/#plugins
> how is it handling modern security features like new versions of TLS or SSL
We support OpenSSL 1.1 and 3 (and any other API-compatible), LibreSSL and mbedTLS 2 and 3. You can choose the one you like/trust more at link time.
> Add support for OpenSSL, LibreSSL and mbed TLS for HTTPS, which is now enabled by default.
> we have setup a new website based on GitHub pages (so hopefully it won't dissapear soon)
Why cede control of your namespace to GitHub, though? You can host stuff on GitHub Pages without having to go through github.io to get there. Just grab another (cheap) domain and set up a CNAME record to point to GitHub Pages.
This cost me $17.32 for two years—so this time next year, even if there's not $11 or whatever available, there'll be a whole other year to come up with it.
NearlyFreeSpeech.NET (which this isn't using right now; it's just on a free static host) allows anyone to deposit funds into an account for sites hosted there, not just the person behind the site, which means it can in theory stay up indefinitely, even if the person in charge is incapacitated and/or stops putting their own money into it (so long as they don't actively take an interest against its continued operation).
The post explains how they lost their long-held domain name. At least GitHub won't dry up and blow away if you miss a payment.
They're all cheap at the start... and do not necessarily stay that way.
The very end of the post makes it clear this is a temporary situation.
They didn't lose dillo.org because it suddenly became not cheap. They didn't "lose" it at all—they were never in control of it. The post explains that it lapsed because whoever had it didn't renew, and it wouldn't matter much, because the person who was in charge is no longer involved with Dillo, anyway, which would have made dillo.org a true zombie site.
> The very end of the post makes it clear this is a temporary situation
There's no such thing when it comes to namespaces. Which is my whole point.
If they had grabbed dilloproject.org (or whatever) today, they could continue using that no matter where they're actually hosting the pages in the future. Once you're in somebody else's namespace, though, the only thing you can do is abandon it after adopting a new one and hope that a redirect suffices.
kudos on shipping code I guess.
It’s a minimalistic web browser that works on low powered machines
https://dillo.org/
You can read the main website for more details[1].
[1]: https://dillo-browser.github.io/
And the release page[2], which explains a bit of the history of the project and the current state.
[2]: https://dillo-browser.github.io/latest.html
[1]: https://github.com/dillo-browser/dillo-plugin-man
More plugins: https://dillo-browser.github.io/index.html#plugins
On the man plugin, for the users with mandoc/mdoc, I found a bug, '-T html' should be '-Thtml' without spaces. Then works fine.
I once shipped Dillo in a tiny memory resident distro, it was fantastic. Happy to see its return.
That said, more noscript/basic (x)html browsers, the better, even written with computer languages with an extremely complex syntax (rust/java/etc).
In my project list: a minimal linux kernel with gcc-cleaned C code.
Will try this on NetBSD :)
And https://daemonforums.org/ works great with dillo, with dillo you can even log into daemonforums. The ID ywill not be saved, but AFAIK no other forum allows login when in dillo.
[1]: https://dillo-browser.github.io/user_help.html#cookies
I test my websites with Dillo diligently, so I have some re-testing to do now. :)