Yes that's true. I guess what I wanted to point out is that GitLab has dependencies like Postgres, Redis, Ruby (with Rails), Vue.js… whereas Forgejo can use just SQLite and jQuery.
sqlite is not something one would use for a database with a lot of users, postresql or mysql/mariadb is a better choice in these circumstances.
and i don't think having jquery as a dependency in 2023 is a positive sign.
not sayibg the software is bad, it's just different.
Fortunately they were inaccurate, and it supports mariadb and postgre too.
In the documentation, they leave sqlite and mssql to the last places in the listings.
Probably Forgejo/Gitea also uses such dependencies, but their Go counterparts which are statically built into the server binary.
If resource efficiency only depended on that, Gitlab would be more efficient with memory because of this. We all know that's not the case, I just said it as a comparison.
This also means that while Forgejo/Gitea depends less on your system installation, it also wont benefit from updated dependency packages.
it also wont benefit from updated dependency packages
If they maintain the binary properly, could cause less issues with dependencies compatibility, so it's less pain for the DevOps team, like a container image, just pull the new image and done.
Well, this way they could install dependencies anyway just automatically, so you don't see them unless you read before accepting the installation. I still can read this:
Install and configure the necessary dependencies sudo yum install -y curl policycoreutils-python openssh-server perl
And then:
Add the GitLab package repository and install the package curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
So they do some magic here, the script just installs the repository, so I can't see exactly any dependency they are currently using.
That's a bit of an unfair comparison - that's the GitLab instructions to install from source. Most people use a package (rpm, deb) to install GitLab.
The installation instructions for GitLab from prebuilt binaries is https://about.gitlab.com/install/, and that's significantly shorter.
That said, I think for most home applications, GitLab is hugely overkill.
Yes that's true. I guess what I wanted to point out is that GitLab has dependencies like Postgres, Redis, Ruby (with Rails), Vue.js… whereas Forgejo can use just SQLite and jQuery.
sqlite is not something one would use for a database with a lot of users, postresql or mysql/mariadb is a better choice in these circumstances. and i don't think having jquery as a dependency in 2023 is a positive sign. not sayibg the software is bad, it's just different.
Fortunately they were inaccurate, and it supports mariadb and postgre too.
In the documentation, they leave sqlite and mssql to the last places in the listings.
That's a red flag
Forgejo can use PostgreSQL perfectly → https://forgejo.org/docs/latest/admin/installation/#postgresql-database
Hopefully not, as sqllite is never in a prominent place among the other supported databases in the documentation
Looking at it, I see the following…
GitLab's deps:
sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev libpcre2-dev build-essential git-coreForgejo deps:
I am missing something?
Probably Forgejo/Gitea also uses such dependencies, but their Go counterparts which are statically built into the server binary.
If resource efficiency only depended on that, Gitlab would be more efficient with memory because of this. We all know that's not the case, I just said it as a comparison.
This also means that while Forgejo/Gitea depends less on your system installation, it also wont benefit from updated dependency packages.
If they maintain the binary properly, could cause less issues with dependencies compatibility, so it's less pain for the DevOps team, like a container image, just pull the new image and done.
I assume that's to build from source.
The times I've installed GitLab it's been a case of
dnf install https://.... The rest gets dragged in automatically.Well, this way they could install dependencies anyway just automatically, so you don't see them unless you read before accepting the installation. I still can read this:
And then:
So they do some magic here, the script just installs the repository, so I can't see exactly any dependency they are currently using.