Forgejo is GPL 3, with the Github stuff apparently even running it on owned device is tied to a per user per month bill, and I have no idea if code is available and editable just having a look at https://azure.microsoft.com/en-us/pricing/details/githubente...
yes, GitHub Enterprise Server is not free. And yes you pay a license fee per user per month, billed annually, and the minimum license purchase is 10 users at something like $21/user/month. Microsoft discounts you qualify for will bring that down. You pay because you get support. You won't need it often, but when you do, you really need it.
It is easy to administer even for 15k users, and mostly it takes care of itself if you give it enough RAM and CPU for all the activity.
Downloading the virtual hard drive image from GitHub is easy and decrypting the code inside is borderline trivial, but I'm not going to help anyone do that. I've never had a need to do it.
As a server product it is good. I recommend it if you can afford it. It is not intended for private individuals or non-profits, though. It's for corporations who want their code on-premise, and for that it is quite good.
Commercial software support is not free. Contracting out for professional services or diverting internal developers to fix issues with open source software are also not free.
There have been complaints about it on Reddit as well. I registered an account recently and to me the annoying thing is the constant "making sure you are not a bot" check. For now I see no reason to migrate, but I do admit Forgejo looks very interesting to self-host.
3. They have a UI, but anyone can also build one and the ecosystem is shared
I've been considering Gerrit for git-codereview, and tangled will be interesting when private data / repos are a thing. Not trying to have multiple git hosts while I wait
I, too, am extremely interested in development on Tangled, but I miss two features from GitHub - universal search and Releases. the web frontend of Tangled is so fast that I am still getting used to the speed, and jj-first features like stacked PRs are just awesome. kinda reminds me of how Linux patch submitting works.
Codeberg doesnt currently support any, but Forgejo, the software it runs on, is implementing support for ActivityPub. Codeberg will likely enable it once support is stable.
I moved (from selfhost gitlab) to forgejo recently, and for my needs it's a lot better, with a lot less hassle. It also seems a lot more performant (again probably because I don't need a lot of the advanced features of gitlab).
I've been contemplating this for almost two years. Gitlab has gotten very bloated and despite disabling a number of services in the config, it continues to require increasingly more compute and RAM; we don't even use the integrated Postgres database.
There are a few things that keep me on Gitlab, but the main one is the quality of the CI/CD system and the gitlab runners.
I looked at Woodpecker, but it seems so docker-centric and we are, uh, not.
The other big gulf is issues and issue management. Gitlab CE is terrible; weird limitations (no epics unless you pay), broken features, UX nightmares, but from the looks of it Forjego is even more lacking in this area? Despite this seeming disdain, the other feature we regularly use is referencing issue numbers in commits to tie work together easily. On this one, I can see the answer as "be the change - contribute this to Forgejo" and I'm certainly willing. Still, it's currently a blocker.
But my hopes in putting this comment out there is that perhaps others have suggestions or insight I'm missing?
Crazy. Who would have an incentive to spend resources on DDoS'ing Codeberg? The only party I can think of would be Github. I know that the normalization of ruthlessness and winner-takes-all mentality made crime mandatory for large parts of the economy, but still cannot wrap my mind around it.
Not just them. For example, Qt self hosted cgit got ddos just two weeks ago. No idea why random open source projects getting attacked.
> in the past 48 hours, code.qt.io has been under a persistent DDoS
attack. The attackers utilize a highly distributed network of IP
addresses, attempting to obstruct services and network bandwidth.
Probably some little script kiddie fucks who think they are elite mega haxors and use their mommie's credit card to pay one of the ddos services readily accessible.
DDoS are crazy cheap now, it could be a random person for the lulz, or just as a test or demo (though I suspect Codeberg aren't a bit enough target to be impressive there).
What is cheap and what are the risks of getting caught? I can understand that for a 15 yo it might be for the lulz, but I am having a hard time to imagine that this would give street creds, and why be persistent about it. AI-bots would make more sense, but these can be dealt with.
Big tech would be far more interested in slurping data than DDoS'ing them.
An issue with comments, linked to a PR with review comments, the commit stack implementing the feature, and further commits addressing comments is probably valuable data to train a coding agent.
Serving all that data is not just a matter of cloning the repo. It means hitting their (public, documented) API end points, that are likely more costly to run.
And if they rate limit the scrappers, the unscrupulous bunch will start spreading requests across the whole internet.
I think the goal is unclear, but the effect will be that Codeberg will be perceived as less of a real, stable alternative. Breaking in was not in my mind, but that will have the same effect, maybe even more damaging.
Now, if that has been the intended effect, I hope I won't have to believe that.
Story time:
I remember that back in the day I had a domain name for a pretty hot keyword with a great, organic position in Google rankings. Then someday it got all of a sudden serious boost from black-SEO, with a bazillion links from all kinds of unrelated websites. My domain got penalized and dropped of from the front page.
For threat analysis, you need to know how hard you are to break in, what the incentives are, and who your potential adversaries are.
For each potential adversary, you list the risk strategy; that's threat analysis 101.
E.g. you have a locked door, some valuables, and your opponent is the state-level. Risk strategy: ignore, no door you can afford will be able to stop a state-level actor.
I concur the question, "Who would have an incentive to spend resources on DDoS'ing Codeberg?" is a bit convoluted in mixing incentive and resources. But it's still, exactly, threat analysis, just not very useful threat analysis.
I said e.V., not EV. Codeberg is an e.V., i.e. a "registered association" in Germany. I am not actually sure if you could technically buy an e.V., but I am 100% certain that all of the Codeberg e.V. members would not take kindly to an attempt at a hostile takeover from Microsoft. So no, buying Codeberg is not easier than DDoSing them.
What do you mean by "orgs", and what do you mean by "the codeberg"?
Sure, they could try to bribe the Codeberg e.V. active members into changing its mission or disbanding the association entirely, but they would need to get a 2/3 majority at a general assembly while only the people actively involved in the e.V. and/or one of its projects can get voting rights. I find that highly unlikely to succeed.
Are there standards committees with 786 voting members, of which you would have to convince at least 2/3 to betray the ideals of the association they chose to actively take part in to get the association to disband or otherwise stop it from pursuing its mission?
~800 members? That's great to hear actually. I like Codeberg and want them to succeed and be protected from outside effects.
That's said, I believe my comparison checks out. Having ~800 members is a useful moat, and will deter actors from harming Codeberg.
OTOH, the mechanism can still theoretically work. Of course Microsoft won't try something that blatant, but if the e.V loses this moat, there are mechanisms which Microsoft can and would like to use as Codeberg gets more popular.
I think another big "moat" is actually that Codeberg is composed of natural people only (those with voting rights, anyway). Real people have values, and since they have to actively participate in Codeberg in some way to get voting rights those values are probably aligned with Codeberg's mission. I don't actually now the details of the standardization process you cite, but I think this is a big difference to it.
Additionally, from skimming the bylaws of Codeberg I'd say they have multiple fail-safes built in as additional protection. For one, you can't just pay ~1600 people to sign up and crash a general assembly, every membership application has to be approved first. They also ask for "support [for] the association and its purpose in an adequate fashion" from its members, and include mechanisms to kick people out that violate this or are otherwise acting against Codeberg's interests, which such a hostile attack would surely qualify as.
Of course it's something to stay vigilant about, but I think Codeberg is well positioned with regard to protecting against a hostile takeover and shutdown situation, to the point that DDoS is the much easier attack against them (as was the initial topic).
Part of the problem is that Codeberg/Gitea's API endpoints are well documented and there are bots that scrape for gitea instances. Its similar to running SSH on port 22 or hosting popular PHP forums software, there are always automated attacks by different entities simply because they recognize the API.
Try exposing a paswordless SSH server to outside to see what happens. It'll be tried immediately, non-stop.
Now, all the servers I run has no public SSH ports, anymore. This is also why I don't expose home-servers to internet. I don't want that chaos at my doorstep.
Yeah, I have been thinking about hosting a small internet facing service on my home server, but I’m just not willing to take the risk. I’d do it on a separate internet connection, but not on my main one.
You can always use a small Hetzner server (or a free Oracle Cloud one if you are in a pinch) and install tailscale to all of your servers to create a P2P yet invisible network between your hosts. You need to protect the internet facing one properly, and set ACLs at tailscale level if you're storing anything personal on that network, though.
Yeah no need for public ssh. Or if you do pick a random port and fail2ban or better just whitelist the one IP you are using for the duration of that session.
To avoid needing SSH just send your logs and metrics out and do something to autodeploy securely then you rarely need to be in. Or use k8s :)
This is just FUD, there is nothing dangerous in having an SSH server open to the internet that only allows key authentication. Sure, scanners will keep pinging it, but nobody is ever going to burn an ssh 0day on your home server.
A few years ago a vulnerable compression library almost got pushed out that major Linux distros linked their OpenSSH implementations to. That was caught by blind luck. I'm confident there's a lot more shit out there that we don't know about.
"opsec" includes well defined things like threat modeling, risk factors, and such. "Things I have seen" and vague "better safe than sorry" is not part of that.
GitHub uptime isn't perfect either. You will notice these outages from time to time if your employer is using it for more than just "store some git repos", e.g. using GHA for builds and deploys, packages etc.
Because they are Codeberg I'm betting they have a philosophical aversion to using a cloud based ddos protection service like Cloudflare. Sadly the problem is that noone has come up with any other type of solution that actually works.
https://status.codeberg.org/status/codeberg