return to table of content

Show HN: Resurrecting the Dillo browser

heads
40 replies
17h5m

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.

tentacleuno
15 replies
16h38m

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

chmod775
4 replies
10h55m

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.

mrweasel
3 replies
8h6m

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.

smallerfish
2 replies
6h36m

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

pmontra
1 replies
5h15m

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?"

smallerfish
0 replies
4h31m

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.

niutech
2 replies
16h18m

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

rjzzleep
0 replies
12h30m

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?

creesch
0 replies
12h19m

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.

bArray
2 replies
8h41m

> 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

Snow_Falls
1 replies
1h45m

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

Waterluvian
1 replies
14h44m

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.

SoftTalker
0 replies
13h31m

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

pmontra
0 replies
5h19m

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.

akokanka
0 replies
13h21m

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

bombcar
10 replies
16h23m

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.

niutech
4 replies
16h12m

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.

rasz
2 replies
14h59m

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

userbinator
0 replies
12h21m

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

mrweasel
0 replies
8h5m

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

forgotpwd16
0 replies
9h30m

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

creesch
4 replies
12h4m

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.

nyanpasu64
3 replies
10h20m

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

pmontra
0 replies
5h9m

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.

forgotpwd16
0 replies
9h44m

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.

creesch
0 replies
9h59m

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.

niutech
7 replies
16h15m

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

rjzzleep
2 replies
12h20m

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.

rubymamis
0 replies
3h5m

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

niutech
0 replies
7h33m

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

subtra3t
1 replies
9h49m

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

niutech
0 replies
7h29m

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

RF_Savage
1 replies
9h38m

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.

niutech
0 replies
7h32m
prmoustache
4 replies
8h16m

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.

Krssst
2 replies
6h20m

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.

prmoustache
0 replies
6h10m

Search is instantaneous on my gnome evolution MTA.

anthk
0 replies
3h26m

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

anthk
0 replies
5h32m

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

krylon
21 replies
19h33m

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

minitech
8 replies
18h35m

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

astowaway
7 replies
16h56m

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]

rodarima
5 replies
16h46m

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.

ajot
4 replies
14h59m

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

necovek
3 replies
9h25m

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

anthk
1 replies
8h45m

Or just use eww from Emacs.

krylon
0 replies
2h54m

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.

harryvederci
0 replies
8h12m

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

minitech
0 replies
15h53m

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

yjftsjthsd-h
3 replies
18h45m

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

nmz
1 replies
17h11m

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.

yjftsjthsd-h
0 replies
16h58m

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.

krylon
0 replies
17h9m

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

rodarima
3 replies
19h9m

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

bluedino
2 replies
18h0m

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

tentacleuno
1 replies
16h35m

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.

lmz
0 replies
16h9m

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

niutech
0 replies
16h8m

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

nicman23
0 replies
11h19m

firefox with umatrix probably will be better for that hardware.

barbs
0 replies
11h57m

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?

anthk
0 replies
4h39m

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.

nu11ptr
8 replies
19h58m

How does this do at rendering modern websites?

rodarima
5 replies
19h52m

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.

krylon
4 replies
19h28m

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.

anthk
3 replies
8h39m

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.

krylon
1 replies
7h15m

Thank you! I'll give that a try.

anthk
0 replies
7h11m

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.

rodarima
0 replies
7h11m

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

userbinator
0 replies
19h13m

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

chx
0 replies
19h52m

poorly it doesn't even pass acid2

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

janice1999
8 replies
19h50m

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?

rodarima
7 replies
19h41m

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.

dfox
3 replies
19h36m

I would suggest switching to Meson instead of CMake.

janice1999
1 replies
19h28m

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.

actionfromafar
0 replies
17h42m

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

Brian_K_White
0 replies
18h43m

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.

bambax
1 replies
8h15m

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/

rodarima
0 replies
6h56m

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.

yjftsjthsd-h
0 replies
18h30m

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

sheepscreek
5 replies
19h31m

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

rodarima
2 replies
19h21m

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.

cxr
1 replies
13h15m

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.

wakeupcall
0 replies
10h50m

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.

vitiral
0 replies
18h54m

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

tentacleuno
0 replies
16h31m

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.

znpy
4 replies
11h6m

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.

rodarima
1 replies
7h12m

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

znpy
0 replies
6h9m

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.

anthk
1 replies
8h40m

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

znpy
0 replies
7h51m

I have faster machines nowadays, luckily :)

LikeBeans
4 replies
17h13m

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

niutech
1 replies
16h5m

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

LikeBeans
0 replies
15h44m

Thank you for the links!

rodarima
0 replies
17h8m

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

relyks
0 replies
17h7m

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

foul
3 replies
18h47m

Very nice to hear!

Anybody knows what happened to Jorge A. Cid?

rodarima
2 replies
18h30m

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

tecleandor
0 replies
16h54m

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

foul
0 replies
18h20m

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.

unwind
2 replies
9h44m

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

rodarima
1 replies
7h17m

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.

unwind
0 replies
5h53m

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

toastal
2 replies
9h51m

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.

rodarima
0 replies
7h25m

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.

dewey
0 replies
5h43m

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.

systems_glitch
2 replies
18h1m

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.

rodarima
1 replies
17h52m

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.

anthk
0 replies
5h29m

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

shiomiru
2 replies
18h55m

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

rodarima
0 replies
18h33m

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

andrewshadura
0 replies
11h6m

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

rickcarlino
2 replies
19h51m

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.

jimbosis
0 replies
19h40m

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

raphlinus
2 replies
18h10m

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

rodarima
1 replies
15h16m

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

raphlinus
0 replies
13h38m

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!

mminer237
2 replies
18h55m

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

rodarima
0 replies
18h45m

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

foul
0 replies
18h50m

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

linkpuff
2 replies
19h10m

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

rodarima
1 replies
19h0m

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!

linkpuff
0 replies
18h43m

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

joshmarinacci
2 replies
16h21m

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?

t-3
1 replies
4h25m

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.

rodarima
0 replies
4h10m

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

badsectoracula
2 replies
15h59m

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

rodarima
1 replies
15h51m

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

badsectoracula
0 replies
14h57m

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

williamcotton
1 replies
16h31m

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

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

rodarima
0 replies
16h21m

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

pipeline_peak
1 replies
18h11m

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.

tentacleuno
0 replies
16h28m

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.

n3storm
1 replies
10h52m

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.

rodarima
0 replies
7h40m

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

mightyham
1 replies
19h55m

Does dillo support javascript?

chx
0 replies
19h52m

nah all scripting is ignored

gregsadetsky
1 replies
13h6m

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

rodarima
0 replies
7h4m

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

TheRealPomax
1 replies
18h13m

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.

rodarima
0 replies
18h4m

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.

Dwedit
1 replies
17h42m

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

rodarima
0 replies
17h17m

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

29athrowaway
1 replies
18h41m

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

rodarima
0 replies
18h28m
sylware
0 replies
7h45m

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.

reify
0 replies
11h6m

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

natas
0 replies
20h19m

huge huge thanks, I still use Dillo!

mtillman
0 replies
10h42m

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

marttt
0 replies
14h21m

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/

justusthane
0 replies
4h14m

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.

johnklos
0 replies
20h12m

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!

djur
0 replies
17h35m

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.

dannyobrien
0 replies
20h24m

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

anthk
0 replies
19h27m

You could try importing some changes from DilloNG:

https://github.com/w00fpack/dilloNG

andix
0 replies
6h34m

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

:D

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

adamredwoods
0 replies
19h8m

> Dillo requires FLTK-1.3

Nice, lean & mean! I'm interested.

DominoTree
0 replies
19h35m

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

DiggyJohnson
0 replies
19h14m

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!

Crontab
0 replies
19h57m

Nice work!!

Auguste
0 replies
18h44m

Well done! Dillo is a great little browser.