Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating Dillo from GitHub

dillo-browser.org

Post reply on HN
Print view View original

61–70 of 219 posts

Re: Migrating Dillo from GitHub

#61

Post by elktown »

simonw wrote: post #18
simonw wrote: post #13

Earlier quoted context omitted.

I'd love to hear the inside story of GitHub's migration of their core product features to React. It clearly represents a pretty seismic cultural change within the company. GitHub was my go-to example of a sophisticated application that loaded fast and didn't require JavaScript for well over a decade. The new React stuff is sluggish even on a crazy fast computer. My guess is that the "old guard" who made the original…

In answer to my own question about in-depth decision making, I just found this presentation from February 2025 by seven-year GitHub veteran Joel Hawksley: https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-a... Relevant quote: > But beyond accessibility and availability, there is also a growing expectation of GitHub being more app-like. > The first case of this was when we rebuilt GitHub projects. Customers w…

I honestly believe that the people involved likely already wanted to move over to React/SPAs for one reason or another, and were mostly just searching for excuses to do so - hence these kind of vague and seemingly disproportional reasons. Mobile over desktop? Whatever app-like means over performance?

Non-technical incentives steering technical decisions is more common than we'd perhaps like to admit.

Re: Migrating Dillo from GitHub

#62

Post by xrd »

adamcharnock wrote: post #28
xrd wrote: post #19

I've been messing around with GitLab as a self hosted alternative for a few years. I do like it, but it is resource intensive! For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic. The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary.…

We've been looking at Forgejo too. Do you have any experience with Forgejo Actions you can share? That is one thing we are looking at with a little trepidation.

I setup actions yesterday. There are a few tiny rough edges, but it is definitely working for me. I'm using it to build my hugo blog which "sprinklylls" in a Svelte app, so it needs to have nodejs + hugo and a custom orchestrator written in Zig.

What I did:

  * used a custom docker image on my own registry domain with hugo/nodejs and my custom zig app
    * no problems
  * store artifacts 
    * required using a different artifact "uses" v3 instead of v4 (uses: actions/upload-artifact@v3)
    * An example of how there are some subtle differences between GitHub Actions, but IMHO, this is a step forward because GitLab CI YAML is totally different
    * can't browse the artifacts like I can on gitlab, only allows download of the zip. Not a big deal, but nice to verify without littering my Downloads folder.
  * Unable to use "forgejo-runner exec" which I use extensively to test whether a workflow is correct before pushing
    * Strange error: "Error: Open(/home/runner/.cache/actcache/bolt.db): timeout"
    * I think GitLab broke this feature recently as well!
  * Getting the runner to work with podman and as a service was a little tricky (but now works)
    * Mostly because of the way the docker socket is not created by default on podman
    * And the docker_host path is different inside the runner config file.
    * There are two config files, one (JSON) is always stored in .runner and contains the auth information and IP, and the other is YAML and runner needs the -c switch to specify it, and has the config of the runner (docker options, etc). It's a bit strange there are two files IMHO.

Re: Migrating Dillo from GitHub

#63

Post by picafrost »

Excellent. I hope to see more of it.

Another social issue on GitHub: you cannot use the "good first issue" tag on a public repository without being subjected to low quality drive-by PRs or AI slop automatically submitted by someone's bot.

I think the issue with centralization is still understated. I know developers who seem to struggle reading code if it's not presented by VS Code or a GitHub page. And then, why not totally capture everyone into developing just with GitHub Codespaces?

This is exactly what well-intentioned folk like to see: it's solving everyone's problems! Batteries included, nothing else is needed! Why use your own machine or software that doesn't ping into a telemetry hell-hole of data collection on a regular basis?

Re: Migrating Dillo from GitHub

#64

Post by estimator7292 »

homebrewer wrote: post #25
xrd wrote: post #19

I've been messing around with GitLab as a self hosted alternative for a few years. I do like it, but it is resource intensive! For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic. The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary.…

Ease of maintenance is an even bigger difference. We've been using gitea for a bit over five years now, and gitlab for a few years before that, and gitea requires no maintenance in comparison. Upgrades come down to pulling the new version and restarting the daemon, and take just a few seconds. It's definitely the best solution for self-hosters who want to spend as little time as possible on their infrastructure. Back…

I found gitea's interface to be so unusably bad that i switched to full-fat GitLab.

Gitea refused to do some perfectly sensible action- I think it had something to do with creating a fork of my own repo. Looking online, there's zero technical reason for this, and the explanation given was "this is how GitHub does things". Immediately uninstalled. I'm not here for this level of disrespect.

Re: Migrating Dillo from GitHub

#65

Post by ramon156 »

> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug.

I love this. I used to be a big fan of linear (because the alternatives were dog water), but this also opened the question "why even have a seperate, disconnected tool?"

Most of my personal projects have a TODO.md somewhere with a list of things i need to work on. If people really need a frontend for bugs, it wouldn't be more than just rendering that markdown on the web.

Re: Migrating Dillo from GitHub

#66

Post by iamkonstantin »

adamcharnock wrote: post #28
xrd wrote: post #19

I've been messing around with GitLab as a self hosted alternative for a few years. I do like it, but it is resource intensive! For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic. The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary.…

We've been looking at Forgejo too. Do you have any experience with Forgejo Actions you can share? That is one thing we are looking at with a little trepidation.

We use them in our shop. It's quite straightforward if you're already familiar with Github Actions. The Forgejo runner is tiny and you can build it even on unsupported platforms (https://code.forgejo.org/forgejo/runner) e.g. we've setup our CI to also run on Macs (by https://www.oakhost.net) for App Store related builds. It's really quite a joy :)

Re: Migrating Dillo from GitHub

#68

Post by mystifyingpoi »

ramon156 wrote: post #65

> To avoid this problem, I created my own bug tracker software, buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. I love this. I used to be a big fan of linear (because the alternatives were dog water), but this also opened the question "why even have a seperate, disconnected tool?" Most of my personal projects have a TODO.md somewhere with a list of th…

> As it is simply plain text

Well, if your bugs can be specified clearly in plain text and plain text only, then yeah, I'd also advocate for this approach. Unfortunately, that's not really the case in any bigger software project. I need screenshots, video recordings that are 100 megs, cross-issue linking etc. I hate JIRA (of course) but it gets it right.

Re: Migrating Dillo from GitHub

#69

Post by speakingmoistly »

tayo42 wrote: post #56
potato-peeler wrote: post #43

I hope you will continue maintaining a mirror in GH. Some tools like deepwiki are excellent resources to learn about a codebase when their is not much documentation going around. But these tools only support pulling from GH.

How is pulling dependent on github? Git pulling isn't unique to github and it works over http or ssh?

It's less about pulling and more about tools like DeepWiki making the assumption that its inputs live in GitHub, so repository URLs are expected to be GH URLs as opposed to a URL to a git repository anywhere.

That being said, there's no reason for tools like it to have those constraints other than pushing users into an ecosystem they prefer (i.e. GitHub instead of other forges).

Re: Migrating Dillo from GitHub

#70

Post by mfenniak »

xrd wrote: post #62
adamcharnock wrote: post #28

Earlier quoted context omitted.

We've been looking at Forgejo too. Do you have any experience with Forgejo Actions you can share? That is one thing we are looking at with a little trepidation.

I setup actions yesterday. There are a few tiny rough edges, but it is definitely working for me. I'm using it to build my hugo blog which "sprinklylls" in a Svelte app, so it needs to have nodejs + hugo and a custom orchestrator written in Zig. What I did: * used a custom docker image on my own registry domain with hugo/nodejs and my custom zig app * no problems * store artifacts * required using a different artifac…

> * Strange error: "Error: Open(/home/runner/.cache/actcache/bolt.db): timeout"

This will occur if you have a `forgejo-runner daemon` running while you try to use `exec` -- both are trying to open the cache database, and only the first to open it can operate. You could avoid this by changing the cache directory of the daemon by changing `cache.dir` in the config file, or run the two processes as different users.

> It's a bit strange there are two files IMHO.

The `.runner` file isn't a config file, it's a state file -- not intended for user editing. But yes, it's a bit odd.

Post reply on HN