I use Gitea for personal git server, they have a curated list of things can do with it: https://gitea.com/gitea/awesome-gitea What I like about it is the old UI of Github, mean time to start from scratch is very fast and low maintenance.
Edit: the reason that I posted this was not due to some hypothetical blind people but rather because I have been in a situation where I want to show a cool project to a friend with vision issues but I can't because the project is hosted on a gitea instance. I posted this because I was unaware of this issue until recently and presumed that there would be others here who are also not aware of this.
HN readers are downvoting you, but Gitea's problems are real and they exist. Enough of them are listed in codeberg's issue pages that I felt the software/platform is very buggy and has a lot of security issues as just a generic user with one week of experience, much less an admin.
Do you have a bug report? I'm a gitea user and want to reproduce it.
https://codeberg.org/Codeberg/Community/issues/355
(edit: grammar)
I know that this website presents a corporate money-minded version of the Hacker ethos, but this level of psychopathy? Downvoting pleas for accessibility because you don't need it? Really?
Although I would say that my comment would also be relevant to that user as long as their personal server is public and they do not want to exclude people with vision issues from viewing the projects that they host.
That would be an oxymoron. The https://en.wikipedia.org/wiki/Hacker_ethic is anti-corporate by definition.
> but this level of psychopathy?
Many times I've seen people downvoted to hell for pointing out accessibility issues around heavy websites.
Have you looked at the contents of the site and the driving force of the company behind it?
> Many times I've seen people downvoted to hell for pointing out accessibility issues around heavy websites.
Me too, it's a terrible shame.
Of course - hence my point about the conflict between hacker ethic and HN.
Why not just point out its problem and let the users decide?
Is that not what the comment was saying?
> Please avoid gitea. Gitea [...] is known for having accessibility issues, see [...]
Which is not the same as saying:
> Gitea [...] is known for having accessibility issues, see [...]
The first one offers a clear request of action combined with an explaining fact, while the ladder just shows the fact and leaves the action item up to the reader.
I ran git in a container "like you're supposed to" with https access but I wanted better management than adding user access to apache.
So I decided to upgrade to gitea. It was a pretty involved installation but I finally got it going. I set up a gitea cotnainer and was able to use it for a while. But one day it stopped working and I had to spend a bunch of time diagnosing why mariadb wasn't coming up. I can't recall exactly what i did (something with ib_logfile) but i finally got it going.
And a few days later when checking on it, I noticed it was using a bunch of cpu time. Apparently it uses resources just sitting there idle, like 5% cpu.
In the end, I made a git container again. I just used SSH access and one user: git
# pacman -S git
# useradd -m -G wheel -s /usr/bin/git-shell git
# systemctl enable sshd
$ git clone git@gitmachine:git/foo.git
It's basically just a simple perl script and a couple configuration files. It just work in my experience.
If you end up scaling to the point where you have dozens of users and need to make regular changes to the config it becomes rather cumbersome, but for small groups of people (with a couple of build bots and the like that need read-only repo access) it's very well suited.
I followed these instructions setting it up:
https://wiki.archlinux.org/index.php/gitea
I see it does mention sqlite so that would have simplified things. I wonder if it would have prevented the container from using cpu.
Now I'll have to spin up the gitea container again and experiment :)
As long as I pushed it forward, setting up a decent Postgres cluster with failover that I use over local file systems when available has been great.
I groan a bit anytime don’t thing requires persisting configuration to the local file system during the lifetime of the process.
Backups are a lot smoother too. The time invested does come back pretty quick.
There is nothing wrong with SQLite as such and in many situation it is perfect for the task. For a backend service that may need to scale, have availability requirements, is going to be run in a clustered or distributed environment, etc, it is not suitable. For one, you suddenly need to couple physical location of persisted data with usage of the same. Running it on networked filesystems is not supported.
Yes, there are some caveats there and ways to work around it but it's a square-peg-round-hole kind of situation.
For mobile or desktop apps, data jobs that can't be parallelized, local or light-weight analytics, embedded, it's great (though I do think many times it's used where something like leveldb or rocksdb would have been more appropriate but w/e).
I'm sure there are other use-cases in both "great choice" and "terrible choice" I saw in the wild and can't recall.
For something like gitea - it depends on the hosting environment,. requirements and scale. Obv for you it is not a pain-point, for me it absolutely is.
---
I really appreciate when project give the user the choice, like they do here!
ORMs are not the devil and can afford flexibility without having to spend time implementing for each supported backend specifically, if performance isn't critical enough that DB-specific optimizations are needed.
IMO for a project that is going to be self-hosted by a wide range of users, it's often premature optimization to make the v1 tied to a specific DB.
however if you have special requirement like a large team, or accessiblity(which I didn't check) you can try something else. The point here is that, it's much easier to use gitea than to use git+gitolite+nginx unless you want to spend more time with sysadmin instead of development itself.