| ▲ | odie5533 2 days ago |
| Why do people self-host things like this instead of Github or Gitlab? I don't want to maintain more services for my services. Who has time for that. |
|
| ▲ | homebrewer 2 days ago | parent | next [-] |
| Our gitea instance had roughly five minutes of downtime in total over the past year, just to upgrade gitea itself. All in the middle of the night. How much downtime has GitHub seen over the same period, and how many people's work was affected by that? |
|
| ▲ | pheggs 2 days ago | parent | prev | next [-] |
| I've been hosting a git service for quite a while now and it's maybe around half an hour per year of maintenance work. It's totally worth it in my opinion, it's so much better on almost every way ... One big reason is decentralization. Full control of data, change what you want, then things like the current npmjs attack show the downsides of having everyone using the same thing, and so much more |
| |
| ▲ | odie5533 2 days ago | parent [-] | | Backups, OS upgrades, version upgrades, firewall management, DDoS management. I just find self-hosting to be excessive to do right. | | |
| ▲ | n4bz0r 2 days ago | parent | next [-] | | The concerns are valid, but I'd like to point out that managing all that isn't as frightening as it sounds. If you do small scale (we're talking self-hosted git here after all), all these are either non-issue or a one-time issue. Figuring out backups and firewall is the latter. Once figured out, you don't worry about that at all. Figuring these out isn't rocket science either. As for the former. For minimum maintenance, I often run services in docker containers - one service (as in compose stack) per Debian VM. This makes OS upgrades very stable and, given docker is the only "3rd-party" package, they are very unlikely to break the system. That allows to set unattended-upgrades to upgrade everything. With this approach most of the maintenance comes from managing containers' versions. It's a good practice to use fixed containers' versions which does mean there is some labor involved when it comes to upgrading them, but you don't always have to stick to the exact version. Many containers have tags for major versions and these are fairly safe to rely on for automatic upgrades. The manual part of the upgrades when a new major release comes out can be a really rare occasion. If your services' containers don't do such versioning (GitLab and YouTrack are the examples of that), then you aren't as lucky, but bumping a version every few months or so shouldn't be too laborsome either. Now, if DDoS is a concern, there is probably already the staff in place to deal with that. DDoS is mostly for popular public services to worry about, not for a private Gitea instance. Such pranks are costly to randomly poke around and require some actual incentive. But why keep a private instance out in the open anyway? Put it behind a VPN and then you don't really have to account for security and upgrades as much. | | |
| ▲ | supriyo-biswas 2 days ago | parent [-] | | For the GP's DDOS concern, you could just expose the service through a Cloudflare tunnel or something. |
| |
| ▲ | chasd00 2 days ago | parent | prev | next [-] | | tinkering with services and networks and the whole self-hosting concept is pretty fun for many people. | |
| ▲ | pheggs 2 days ago | parent | prev [-] | | its not that hard though, and to be honest I trust myself more than a large org like microsoft to get that right |
|
|
|
| ▲ | elevation 2 days ago | parent | prev | next [-] |
| One answer might be to avoid LLMs training off the intellectual property that your humans typed out for you. But as LLM code generation tools take off, it's a losing battle for most orgs to prevent staff from using LLMs to generate the code in the first place, so this particular advantage is being subverted. |
| |
| ▲ | odie5533 2 days ago | parent [-] | | This probably only matters for 1-2 years tops. LLMs are taking off pretty fast. |
|
|
| ▲ | hamdingers 2 days ago | parent | prev | next [-] |
| As a mirror of my GitHub repositories following the 3-2-1 backup principle. |
|
| ▲ | d12bb 2 days ago | parent | prev | next [-] |
| Especially as self-hosting means loosing the community aspect of GitHub. Every potential contributor already has an account. Every new team member already knows how to use it. |
| |
| ▲ | nirvdrum 2 days ago | parent | next [-] | | You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot. I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy is quite easy —- it goes along with the rest of my off-site NAS backup without me needing to retain local clones on my desktop. And my CI runners are substantially faster than what I get through GitHub Actions. The complexity and maintenance burden of self-hosting is way overblown. The benefits are often understated and the deficiencies of whatever hosted service left unaddressed. | | |
| ▲ | rmoriz 2 days ago | parent [-] | | Microsoft/GitHub has no model training. How do you think Copilot works? Also if you provide open source, people and companies are gonna use it. | | |
| ▲ | bigfishrunning 2 days ago | parent | next [-] | | When I publish open source code, I don't mind if people or companies use it, or maybe even learn from it. What I don't like is feeding it into a giant plagiarism machine that is perpetuating the centralization of power on the internet. | | | |
| ▲ | nirvdrum 2 days ago | parent | prev [-] | | > Microsoft/GitHub has no model training. How do you think Copilot works? I'm sure if you used that big, smug brain of yours you'd piece together exactly what I meant. Here's a search query to get the juices flowing: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... Whether you agree with why someone may be opting to self-host a git server is immaterial to why they've done so. Likewise, I'm not going to rehash the debate over fair use vs software licenses. Pretending like you don't understand why someone that published code under a copyleft license is displeased with it being locked in a proprietary model being used to build proprietary software is willful ignorance. But, again, it makes no difference whether you're right or they're right; no one is obligated to continue pushing open source code to GitHub or any other service. |
|
| |
| ▲ | pheggs 2 days ago | parent | prev [-] | | I mean git was exactly designed to be decentralized |
|
|
| ▲ | abdullahkhalids 2 days ago | parent | prev | next [-] |
| A better question is why does it take any time to maintain a tool like this? I spend zero time maintaining my open-source browser (Firefox). It just periodically updates itself and everything just works. I maybe spend a bit of time maintaining my IDE by updating settings and installing plugins for it, but nothing onerous. A tool like this is not fundamentally more complex than a browser or a full-fledged IDE. |
| |
| ▲ | odie5533 2 days ago | parent [-] | | You ever have a Firefox update where you have to go and change Settings, or adjust your extensions? Never? | | |
|
|
| ▲ | kachapopopow 2 days ago | parent | prev [-] |
| because:
1) privacy - don't want projects leaving a closed circle of people
2) compliance - you have to self-host and gitlab/github are way too expensive for what they provide when open-source alternatives exist
3) you just want to say fuck you to coorperate (nothing is free) and join the clippy movement. |
