rodarima
3 months ago
Maintainer here.
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:
bromuro
3 months 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
3 months ago
Huh? For me it works fine? Are you sure you are on https://dillo-browser.org/ ?
dpkirchner
3 months 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
3 months 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.
mhitza
3 months 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
3 months ago
Oh tor client is good idea
puttycat
3 months ago
Can you say more about why you're moving away from GitHub?
rodarima
3 months 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.
hoistbypetard
3 months 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
3 months 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.
nmz
3 months ago
There's companies out there whose main source of business is wetworks, as in drone strikes and so on, microsoft going for the most unethical title, I don't think its even in the ranking.
I do agree that not using it is better morally, however, given the limitations of git vs fossil, which carries the issues and wiki inside the repo itself, its not a good idea to switch to another service without guarantees that its host will be forever standing, github won't die in the next decade, but the alternatives mentioned might. even google (code) got out of the source hosting business.
shiomiru
3 months ago
But your confidence in GitHub's continued existence comes from its network effects, no? And competing services can only gain such network effects if more people use them. So to me this feels like a defeatist argument.
nmz
3 months ago
This is not a magical achievement, github is solvent and its business model is solid, give the same amount of users to any other service and it might collapse. Any service has to scale and the more users it has the more costs it incurs, nonprofits are a risk, the moment they run out of money, the service collapses.
shiomiru
3 months ago
If it's not a magical achievement, then surely competitors could replicate it too.
Of course you can't put a million users today in a service used by a thousand yesterday, but I don't buy the "non-profits don't scale" argument. If that were true, we wouldn't have Wikipedia either.
nmz
3 months ago
Replication is not enough, Competition only wins if it offers lower cost or better service (or intolerable service if free), While yes, the userbase is essential, you're still ignoring the reason why the userbase is there in the first place services before github existed and github is the one that ended up winning, competition cannot just offer a better ethical stance and its not even that, since github itself is not doing anything criminal, it's simply aligned with microsoft, so the ethical stance is "I don't like AI" and "I don't like microsoft", that is simply not enough of an offer to make the entire userbase switch. the only way you could is if github decided to throw all of its userbase like bitbucket did, and given that its name is git, I doubt they'll ever do that.
shiomiru
3 months ago
To clarify, I think it's fair to say "I use GitHub because I don't think MS is that bad" (I disagree, but it's at least a consistent view.)
I only take an issue with "I think MS is morally reprehensible but everybody uses it so I'll keep using it too" because it's a self-fulfilling prophecy. Most people looking for code hosting will use whatever they first run into, so when you choose a host for your project you are also directly channeling users towards said host. It's your responsibility to pick a host for your projects that isn't evil by your standards, whatever those may be.
369548684892826
3 months ago
> the most unethical company that ever existed
Maybe in the tech world, but in the real world there are companies such as Nestlé out there competing for this title.
lou1306
3 months ago
Not even in the tech world. Microsoft did more than its fair share of cutthroat business practices, but there are tech companies out there that are quite literally thriving on worker exploitation.
1718627440
3 months ago
Amazon?
DrewADesign
3 months ago
Damn near any gig economy company.
mavhc
3 months ago
I raise you The East India Company
t43562
3 months ago
In the tech age there are new East India Company equivalents.
kristopolous
3 months ago
Belgian Congolese tire companies under King Leopold, Atlantic slave trade companies, Basil Zaharoff and Vickers who sold machine guns to both sides agitating WW1, IG Farben who did the Nazi gas chambers, Shell oil who since the 1970s continues spending billions funding climate change disinformation and billions preparing for it, at the same time... It's a long list.
Take Hyundai, a brand I drive, childhood slave factories, in the 2020s... You can't even brush your teeth without the ghosts of slavery.
oblio
3 months ago
Which one?
paradox460
3 months ago
> the most unethical company that ever existed.
The East India trading company?
rationably
3 months ago
Have you considered Sourcehut? sr.ht
dbtc
3 months ago
I appreciate these priorities!
fouc
3 months ago
Reasons 1, 2, and 4 convince me the most. It's insane how slow and cumbersome github's code review page has been is ever since they moved from rails to react.
blks
3 months ago
MS will steal your code for their slop machines.
arcanemachiner
3 months ago
They will happily steal it from the new site as well. :)
mk89
3 months ago
It's even faster to scrape, apparently :)
thesuitonym
3 months ago
I understand that it's only token resistance, but if it were me, I'd rather not give them approval to do it.
DrewADesign
3 months ago
Right. It’s fair use to munge your work into competing products against your will if it’s for the _~•’AI’•~_
znpy
3 months 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!
MarsIronPI
3 months 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.
jmclnx
3 months 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
3 months 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...
threemux
3 months 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.
imglorp
3 months 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
3 months ago
Yes, thanks for the reminder. This is what they write about:
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
huflungdung
3 months ago
[dead]
mtillman
3 months ago
It still has great looking icons, a proper boarder bevel, and real scroll bars. Thank you!
jagged-chisel
3 months ago
I’m imagining a comfy bevel on the bench outside your hostile where your boarders can sit happily.
hcs
3 months ago
I'm imagining a place for boarders to stay confrontationally
disqard
3 months ago
Defiantly true.
axiolite
3 months 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.
jesperwe
3 months ago
And read scrolls while having a a cocktail in the bar.
user
3 months ago
eikenberry
3 months ago
What is the bug tracking software you are using?
rodarima
3 months ago
I wrote my own:
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/
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.
1718627440
3 months ago
> SIGUSR1 to dillo
That's an excellent program !
khimaros
3 months ago
maybe of interest: https://github.com/git-bug/git-bug
keyle
3 months ago
That is very cool.
saint_yossarian
3 months ago
fishgoesblub
3 months ago
Why cgit and not something nice like Gitea, or Forgejo?
Bolwin
3 months 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
catwell
3 months 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 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.
messe
3 months ago
Have you looked at self hosting sourcehut (https://sourcehut.org/)?
rodarima
3 months 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
3 months ago
What a breath of fresh air, I’m watching people dance with plain text behind the bars of Jira, GitLab & Teams
thesuitonym
3 months ago
My guess is gitea and forgejo don't render well in Dillo.
winningChild
3 months ago
[dead]
al_be_back
3 months 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.
mason_mpls
3 months ago
More memory means more memory for my website to take up!
1vuio0pswjnm7
3 months 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
TheRealPomax
3 months 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.
nicoburns
3 months ago
Is there some kind of status tracker somewhere. That describes which web standards are supported?
rodarima
3 months ago
Not really. There was this list but it is outdated: 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
3 months 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!
kragen
3 months ago
That's wonderful to see!
mixmastamyk
3 months ago
Hmm, it is tiny on my highres screen. Anyone know how to double the scale?
O1111OOO
3 months 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
3 months 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)
1718627440
3 months ago
How can you report something to the bug tracker?
sylware
3 months ago
If they could move away from c++ too.... like plain and simple C like the netsurf browser?
anthk
3 months ago
DIllo is much lighter and it supports Gopher, Gemini, Info, Man and potentially in a further future, URL rewritting plugins.
kragen
3 months 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
3 months ago
Rewriting it in Rust is the obvious choice.
anthk
3 months 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.
kragen
3 months ago
I just compiled some C++ code using G++ under ulimit -v 108032, but it didn't use much of the STL. For a simple example program using iostream, vector, unique_ptr, and std::string, I needed more, but had success with ulimit -v 262144: http://canonical.org/~kragen/sw/dev3/docentes.cc.
The last "real" C++ code I wrote was probably the modular softsynth in http://canonical.org/~kragen/sw/dev3/sweetdreams-c++.cc (see http://canonical.org/~kragen/sw/dev3/sweetdreams.html for an explanation) which also compiles successfully in under 256MiB of virtual memory (¼GiB). But that's still under 500 lines of code.
I'm not sure how much RAM you need to compile G++ itself. More, I imagine. I was definitely compiling versions of GCC long before I ever saw a machine with so much RAM as 1GB, but I am guessing you probably need at least 1GiB for recent versions, maybe 4GiB.
LLVM, which is required for both clang and Rust, is much heavier. You definitely can't compile current versions of LLVM on i386, m68k, or any 32-bit platform anymore. You can get it to cross-compile to them as targets. In theory there are PPC64 machines that have enough address space to build it, but I'm not sure anyone ever made a PPC64 machine with enough physical RAM to build it in a practical span of time.
anthk
3 months ago
I run OpenBSD 7.8 under an i386 ATOM netbook, n270 CPU and 1GB of RAM. I hav no Rust, but I have C++, JimTCL, nim (I compled Chawan). Go runs, too. Maybe I can't compile LLVM in my netbook, but a tuned up machine with 2-4GB of RAM might be able to do such task with a bit of swap in a SSD and boosted up login.conf limits.
kragen
3 months ago
Maybe so, but I think it would have to be an amd64 CPU rather than an i386. Maybe you could do it inside of QEMU; does QEMU running on i386 permit emulating address spaces larger than 4GiB?
anthk
3 months ago
If you run PAE and enable ZRAM, You can probably handle it by booting a 32 bit OS under a 64 bit machine as you state.
sylware
3 months 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).
kragen
3 months ago
Rewriting GCC's C++ codebase in C is also not realistic.
sylware
3 months ago
I pointed out that some people seems to get good results at porting c++ to C using "AI"(LLM).
And big mistakes require big fixing.
kragen
3 months ago
Yeah, we doin', big pimpin', we spendin' cheese
Big pimpin' on B-L-A-D’s, we doin'
Big pimpin' up in NYC
It's just that Jigga Man, Pimp C and B-U-N B
anthk
3 months ago
Rust it's worse for that; for full reproducibility you almost need to create a release-centipede from an old GCC-rs (or GCC) compilable release to the current one. At least that's the norm under Guix.
On cproc, cparser, I meant that we have no lightweight c++ compilers and sadly the closest to cparser in lightness it's clang++, because it's either that or the g++ behemoth.
sylware
3 months ago
In the light of all that, there are still people unable to understand why computer languages with ultra-complex syntaxes are really an issue (c++, microsoft rust, etc...)
anthk
3 months ago
More like complex, overloaded. ML languages have a complex syntax but are manageable. OTOH, on Lisp, about bloated languages like Common Lisp compared to Scheme, you don't have to follow all the Common Lisp Hyperspec in order to create something; a subset would be pretty fine, even without CLOS. Scheme IMHO it's worse with SRFI's with tons of opaque numbers in order to guess what does that. And don't let me start on Guile modules vs the Chicken ones...
People rants about CL being a bit 'huge', but with the introduction to the Symbolic Computation book and Paradigms of Artificial Intelligence Programming you are almost done except for a few modules from QuickLisp (CL's CPAN/PIP), such as bordeaux-threads, usockets and MCClim for an UI, which will run everywhere.
C++ templates can be far more complex than Common Lisp macros. At least with CL you have a REPL to trivially debug and inspect then. Clang and GCC just recently began to introduce * understandable* help and error messages over template parsing walls...
kragen
3 months ago
Rust compilers are an even bigger dependency than C++ compilers.
sylware
3 months ago
Microsoft rust is not that much worse than c++.
That said, it seems some people get nice results at porting from c++ to C using "AI" (LLM?).
anthk
3 months ago
If fltk had C bindings it would have been a thing long ago, because usually C programs will run faster than their C++ counterparts. DIllo's requeriments would be far smaller (and Dillo runs on potatos, I won't be surprised if it still runs on i486 machines)
kragen
3 months ago
*a good suggestion.