Codeberg: A GitHub alternative from Europe
ruky.me
ruky.me
• https://codeberg.org/ (As per the linked article)
• https://sr.ht/ (Sourcehut)
Codeberg and Sourcehut appear to use open source code for their web page backend; the others seem to use proprietary software (in the case of GitLab, there is a free version, but gitlab.com also uses non-free software).
Sourcehut says they may some day charge people to host open source software on their server, but right now it’s a free beer service (but, yes, I have donated) using Free (libre) software.
Souceforge also has a proprietary free-to-use for open source Git hosting service, but their service is a little buggy so I would use one (or in my case, all) of the five I have listed.
If there are any others, please let us know.
In terms of continuous integration, in my particular use case, the automated CI tests take about an hour to all run, so I have a Raspberry Pi server the size of a deck of cards which runs Ubuntu 22.04. The server uses a crontab which checks to see if the Git repo has been updated once a day, and runs the tests inside a Docker container if the repo has changed. Some problems, such as automated testing, don’t need to be solved by putting everything in a cloud.
On the bright side I suppose that means they shouldn't have any of those pesky commercial pressures to start charging people.
I don't think I need to say what the down sides are.
And then the feds come for you for breaking some of those US sanctions you had no idea about.
https://finance.yahoo.com/news/gitee-chinas-answer-github-re...
Pretty sure GitLab is open source.
There is a FOSS GitLab https://gitlab.com/gitlab-org/gitlab-foss
The hosted gitlab.com instance uses EE features so parent is correct to say that the gitlab.com site is not open source.
It’s OSS but with proprietary parts. That’s the issue with the term "open-source": their source code is indeed open [1] but it’s not 100% free (as in freedom).
Edit: mmh apparently I’m mistaken; according to another commenter this is called "open-core" and not "open-source" [2].
Codeberg is a fork of Gitea https://github.com/go-gitea/gitea which curiously uses GitHub for hosting.
*EDIT* https://codeberg.org/
I'm guessing they're just maintaining their own copy and Codeberg is more about the service rather than being another git hosting project.
> https://registry.hub.docker.com/r/gitlab/gitlab-ce/
While it might be fun to self-host, a 5 dollar a month fee to run it is also not price competitive with the free or paid individual tiers at github.com for a single user too. I'd probably only do this if the git repo was being hosted on my home LAN.
I also remember the there were tools that use Git as a backend for a change review system, and for an issue-tracking system (much like the stuff which Fossil has integrated).
With that, you theoretically don't need a central server at all, as long as you can send patches to each other. In practice, a central server is an important convenience that helps keep the history synchronized between several developers.
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
I like the idea of generating static webpages, it sounds great for read only content.
However, it doesn't sound very good for collaboration. Someone can come your repo but it doesn't seem easy for them to submit changes back upstream to your repo?
From the FAQ (https://docs.codeberg.org/getting-started/faq/#is-it-allowed...):
> Is it allowed to host non-free software?
> Our mission is to support the creation and development of Free Software; therefore we only allow repos licensed under an OSI/FSF-approved license. For more details see Licensing article. However, we sometimes tolerate repositories that aren't perfectly licensed and focus on spreading awareness on the topic of improper FLOSS licensing and its issues.
> Can I host private (non-licensed) repositories?
> Codeberg is intended for free and open source content. [...]
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC32T7UNXIK7O....
https://man.sr.ht/billing-faq.md#why-should-i-pay-when-githu...
The point is to set up a responsible financial situation between himself and the users and avoid the bad incentive structures that "free" services have ("Free" until VC money runs out, at which point it is roll of the dice whether they'll be monetized through acquisition, or some annoying scheme).
>Most other companies are financially supported by venture capital, in the form of large investments from a small number of people. If you use their services for free, or even if you pay the modest fees for their paid plans, they are not incentivized to serve your needs first. They are beholden to their investors, and at their behest, they may implement changes you don't like: invasive tracking, selling your data, and so on.
>SourceHut has not accepted, and will never accept, any outside investments. Our sole source of revenue is from sr.ht users making their account payments. This incentivizes us to only consider your needs, and not to use you as a resource to be exploited. The financial relationship is much more responsible for both parties.
A very commendable stance.
From an article I wrote recently on this topic [2]:
> Selling Stock vs Selling Search
One key realization we had is that when we bring on investors, we are essentially bringing on a new group of customers - customers for whom the product is our company stock.
The value this group of customers (investors) gets from the product they are buying (stocks) is appreciating stock prices. And the way we can keep this group of customers happy is by regularly raising the next round of funding which is when stock prices appreciate, or having a liquidity event to make a return on investment.
We are concerned that “launching” a new “product line” (selling stocks) and bringing on a whole new group of customers (investors), would cause us to lose our precious bandwidth that could have otherwise been spent on our core search product that our primary group of users and customers expect from us. After all, the “company stock” product line would not exist without the core search product.
[2] https://typesense.org/blog/why-we-are-not-raising-funds/
> be banned if I asked about it
I assume this means the maintainer(s) have experienced the above a few times, and have given up trying to be more polite about it!
Don't take it personally. If you want to use a tool with that plumbing then feel free to DIY. If you make it work well, perhaps publish your process and/or images and support it for others who need/want that support.
Also, it doesn't even make sense on the engineering point of view. I understand not liking Docker the company or Kubernetes the product, but Linux namespaces are a kernel level facility, and banning people because they dare ask how to integrate this product with a native subsystem seems absolute zealotry from people with oversized ego.
Nothing wrong with that, but let's call a spade a spade. It's their project, so it's their right to be a prick about it, but that shouldn't stop other people to call them out on it.
There is. And I'm suggesting that the water filling that ocean has come from having the same discussion over and over again with people who have asked in the past, each thinking they might be the one to finally help you see the light. I've not personally dealt with it from the point of view of infrastructure choices, but I hear tale of those who have, and I've been subject to it with regard to people who didn't agree with a licence choice so can speak for how much it makes you not want to engage at all just-in-case.
I'm not suggesting you'd be like that, but I understand not wanting to engage on the matter based on previous experiences.
> that would take less effort than
Unfortunately, not always. Sometimes the only way to convince people that it isn't worth their time continuing to try to change your mind, is to blatantly be a dick about it. I try not to jump straight to dickishness though: I'll state my position politely once, I may have time to repeat that once or twice more, then out come the big guns.
On a public mailing list or similar I might be more blunt: linking to past discussions in the first instance then jumping to DickCon1. On a public group the discussion is taking more than just my time and might encourage others to chime in and drag the matter instead of letting it close.
And again: the suggestion of “banning on sight” could have been intended as an attempt at humour by way of hyperbole, rather than the direct “off you fuck” that was felt. Communication of sentiment online is very prone to errors like that.
This is exactly my point: given that online communication is low bandwidth, why are you attempting humour with someone new, who is therefore very unlikely to get it? (And, given Drew's track record, I find it extremely unlikely that he is just trying to be funny, but that's a different matter.)
Also, your point about not wanting to spend more time on a discussion than is necessary, you can simply... not. Say not interested, post a link to a FAQ that covers your stance, and simply don't engage. You don't need to be offensive. You don't need to be worried about people dragging the matter. It's just a discussion.
I will be very surprised if Drew isn't called in by his communities at some point.
I asked once and didn't get a response for what I think was 3-5 days and asked again (it is a low frequency channel, but that gap seemed appropriate). I wasn't making a religious argument, literally just asking about the availability of images.
> Don't take it personally. If you want to use a tool with that plumbing then feel free to DIY. If you make it work well, perhaps publish your process and/or images and support it for others who need/want that support.
I mean Drew was pretty clear that I couldn't even ask questions related to either subject in that channel. I don't take it personally, but it certainly affected the way that I view the project and Drew as a human being.
https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d28...
I was researching Keycloak integration with Kubernetes (a project needed it at the office).
I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS.
If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is.
The person didn't learn how to use and administer Keycloak, didn't make good judgement calls about security and published bad information while doing that.
Docker is easy to abuse and creates people who think know stuff, but do not in reality.
Docker. Pull Responsibly (TM).
Listen, I understand not liking containers. That's fine. But just say so, or try to give more concrete arguments to the table than "I saw a guy in a video creating an insecure container. Thus Docker creates ignorance."
As if configuring servers by hand isn't prone to misconfiguration or bad security practices. Perhaps we have namespaces today because people have been creating insecure, unmaintainable pet systems since the stone age, yet it doesn't save you from hurting yourself if you don't know what you're doing.
You're building rest of your comment on this misinterpretation of my comment.
What I say is "Docker is easy, but it lowers the bar for making mistakes too much. Using Docker without enough information creates bigger problems, faster".
You can do a lot of mistakes, and fatal ones at that, while working on bare metal too. I'm managing systems for 15+ years, using Linux close to 20, and had my fair share on any abstraction level (metal, VM, container, etc.).
However, K8S and Docker is susceptible to create a whole set of problems, and more importantly without knowing it, until it's too late. VMs and bare metal fail relatively early and with more noise. If you do something wrong with your K8S deployment, you can't mend it, and need to re-deploy it.
I do not prefer Docker and K8S, and avoid the latter if I can, but I'm not an hard-line extremist against any of them. I also manage containers and a K8S cluster at work, too.
And no, I never patronize anyone. This is not my style. I just shared my experience, and told that "learning wrong things is easier with Docker", that's all.
I know excellent developers and sysadmins who do wonders with containers, too. Docker and K8S are sharp knives with no warnings on them. That's all.
And that's nothing wrong with that. You might also "hurt" yourself by installing software by hand.
Let's agree to disagree, this "it could be dangerous!" argument feels like doubling down on a weak position, but I honestly do not care about fighting someone over the internet about it. Your computer, your rules :-)
Yes, except poor documentation and lots of open secrets.
There is no need to fight. We're just discussing. We can do things differently and obtain the same brilliant or disastrous results regardless of the underlying abstraction layer/platform.
All approaches have advantages and disadvantages, so all takes are equally weak IMHO.
Have a nice day,
Cheers.
> I saw a guy in a video creating an insecure container. Thus Docker creates ignorance
It's more than a guy. Once you see that kubernetes is corporate bloat you gotta ask for the responsability of the people making it. Yes it's creating people that don't understand how things are actually wired (and no, this is not a "natural" direction of history). It's making people dependent on complex stuff and it's actually hiding from mainstream knowledge the simple ways to do simple stuff. I recently had to help someone deploy stuff on an openshift hosting and i must say the experience is infuriating (not even talking about the runtime efficiency of managing the bazillion moving parts).
> If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is.
Would you mind sharing your argumentation about this, both in the context of Keycloak and in general?
In my eyes, enabling TLS on whatever application you want to run directly is almost always a bad choice, because you now need to deal with its unique implementation, as well as any vulnerabilities that the implementation could have. For example, even if all of your services run Java, you might find that a Spring application, a Spring Boot application, a Quarkus and a Vert.X application all have different ways of enabling it:
Spring example: https://www.baeldung.com/spring-channel-security-https
Spring Boot example: https://www.baeldung.com/spring-boot-https-self-signed-certificate
Quarkus example: https://quarkus.io/guides/http-reference#ssl
Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs)
In contrast, when you have a web server as your point of ingress, that then acts as a transparent reverse proxy in front of your applications:
- it takes care of all of the certificates, in a common format, they're easy to renew or can be provisioned thanks to ACME
- it can take care of other concerns, like path rewriting, HTTP to HTTPS redirects, rate limiting, additional caching or headers
- your applications can talk to one another in the internal network through HTTP, whereas encryption there can be added transparently
- with containers, this might be an overlay network where the clustering/networking solution takes care of internal certificates and rotates them often
- it's easier to screw things up and expose stuff directly (e.g. port mappings, instead of overlay networks)
- one could feasibly argue that sometimes the application itself might want to look at the certificates and do something with them (e.g. expiry alerts)
- one could also argue that reverse proxies won't necessarily be perfect and some software might not correctly deal with headers
https://gist.github.com/GavinRay97/e3c166c5ba24c2c1bc4a09d7b...
He said "Docker isn't a supported installation mechanism."
I wasn't aware of Drew's anti-docker stance, whoops.
I believe Git and Mercurial are considered to be 'about as good' by most.
Some people probably used it because for awhile, pre-GitLab, it was the GitHub alternative with the most generous free tier for private repos.
However, the overwhelming majority of users probably use it because they're already in the Atlassian ecosystem due to JIRA.
I think Codeberg's co-op style governance/funding makes a lot of sense w.r.t sustainability.
A reminder that Framasoft's a worthy cause to donate to if you are looking for causes to support!
There are other git services which are noscript/basic (x)html friendly from the ground up, and EU based, but much less popular.
A few years ago, captchas were long to go thru but at least without that horrible javascript.
It's not proprietary?
https://sourceforge.net/create/
> And, as if all of that wasn’t enough, the SourceForge platform runs on Apache Allura which itself is Open Source!
https://knowyourmeme.com/memes/events/c-plus-equality-c
I suggest to use and support the alternative that explicitly promises not to engage in censorship - gitgud.io
If you have a Pi in a drawer somewhere, or an underutilized 512MB VPS, using it to self-host a Gitea instance is worthwhile!
0.Using SQLite as the data store.
1. Alternatively, you can use your Gitea instance as the primary, and have it push changes to other git servers like GitHub or Gitlab
Performance wise, pushing and pulling work as fast as any other git server (Though I don't have any hooks). The UI is snappy, though it can be sluggish when initially importing large projects.
Out of the 2-dozen projects its handling, the only issue I encountered was the Pi choking while migrating a large project (github.com/huggingface/transformers): I suspect it was hitting an internal timeout when importing large LFS files (ML models). Fortunately, since it uses bare repos and a simple db schema, I performed the git clone operation manually and updated the SQLite db to enable the "mirror" flag & it's been happily syncing since.
Of course performance depends on the size of your database and how many repos/files. I've configured it to use a sqlite3 database, which runs great.
Codeberg is working on CI and you can request early access. I've found it to work well and fast.
And I'm not saying that not supporting yet is a problem, but the docs saying "everything happens in Docker" implies a lack of forward-thinking in the design of the system that wholly excludes working elsewhere (including FreeBSD or other FOSS platforms).
Apparently it is being supported, but the docs will need some clarification now that some of the advertised assumptions are no longer going to be true.
By default an Agent just wants to execute jobs in a Docker container, using the docker backend. But there are multiple backends. To run a build on Windows/MacOS, you would download the Go binary for the Agent for that platform, and execute it with the right environment variables to specify the local backend.
I think a lot of this functionality is just now getting added to Woodpecker so it's not been documented. It's been in Drone for a long time, but the fork is from a while ago.
https://woodpecker-ci.org/docs/administration/setup https://woodpecker-ci.org/docs/administration/agent-config https://woodpecker-ci.org/docs/usage/pipeline-syntax#platfor... https://github.com/woodpecker-ci/woodpecker/tree/master/pipe...
Loading the YAML file in a language where dictionaries/hashmaps don't preserve the insertion order and serializing again will break your file? How could they fail at such a basic step of making a YAML-configurable CI system?
This is the worst abuse of YAML I have ever seen. Was putting `-` in front of each step too obvious?
> This is the worst abuse of YAML
When was the last time you looked at k8s manifests?
Plus it’s a bit late to hate on YAML for CI config since it’s already being used by most services, such as:
- Concource
- Travis
- CircleCi
- GitHub Actions
- Gitlab
- AWS CodeBuild
Like it or not, the YAML-train left the station years ago. So Woodpecker isn’t doing anything here this isn’t already an established industry norm.
https://woodpecker-ci.org/docs/usage/pipeline-syntax
The problem here is that if you load this YAML, modify it in code, and write it back out, but use a library or language that doesn't keep the ordering of the two entries the same, they will run in the wrong order.
As in their example: backend will be built, followed by frontend. Serially. Those are two different steps.
If instead you loaded this file and saved it without keeping the dictionary ordering the same, it is possible that frontend would not get built before backend.
To get what you want, you have to use the group option to group them together: https://woodpecker-ci.org/docs/usage/pipeline-syntax#group--... at which point frontend/backend would get run in parallel.
Gitlab CI requires you to define your stages up-front, and tasks in the same stage all get executed at the same time.
On Github CI all tasks get executed in parallel by default, unless you specify a needs dependency at which point it will run the steps as required to meet those needs requirements.
> From what I’ve seen, the config uses dictionaries for concurrent pipelines.
You are wrong about that, see https://github.com/woodpecker-ci/woodpecker/issues/771
It’s such a shame that the authors aren’t receptive to the problem because the longer they leave it the bigger the issue to change it will be.
That, along with many messing advanced features pushed me towards gitlab.
It was only days after the project maintainer contacted them that they wrote something back about an IP complaint from Wikimedia foundation.
When people who submit these complaints don't feel like you acquiesced in their favor they will assemble and call you out. Your service will be known as a safe harbor for groups of ill repute and eventually you may be forced to shutter the service because you're now known as the person enabling groups of ill repute.
I'm not saying it's right, I'm saying that's the cycle that history shows takes place. It seems effective at chilling the content in question and the service providers who serve it.
Examples: voat, rumble, Nchan, Nch, parler, the list goes on.
I absolutely agree, and in my opinion we already see this with DMCA.
The general cycle of "abusive users look for platforms that look the other way, while non-abusive users insist on platforms that don't" still applies. But the concern is less "Nazi[0] bars" and more "The Pirate Bay".
[0] FWIW I do not believe that it is possible to censor a Nazi.
b) They did not notify the repo owner, and took several days to respond.
c) I realize that it's a relatively new service, and they may not have a lot of experience dealing with this type of thing
> the repository has been made private (only contributors will be able to access the repo for now)
Huge difference and imho quite ok until things are clear.
From a visitor's perspective, it just became a 404 page, also without explanation, so effectively taken down.
Obsidian does not offer _free_ syncing, but it does offer it: https://obsidian.md/sync
It's not cheap though and it's not europe-based. But it's a way to support the development.
I am really hoping that this will take off and soon all Europeans will be able to prove they have the right to get services without having to reveal their full identity... and I think this is a great framework for registration to services like this as well.
This could be the real start of web3, but I'm pessimistic about the way most of the homepage is talking about funding more than about the problem being solved. The rest reads like a whitepaper.
Maybe blockchains are the right technology here (though I doubt it) but the people writing the documentation were the wrong people for the job.
Which sounds like every EU funded project I know. That's the state of state-driven tech innovation here, very nice. Happy to pay taxes for that sh*t ...
https://essif-lab.github.io/framework/docs/ssi-standards
But there's quite a lot going on... the work on SSI is being coordinated by the W3C Working Group on VCs (Verifiable Credentials) and DIDs (Decentralized Identifiers).
https://www.w3.org/community/credentials/
https://www.w3.org/2019/did-wg/
I don't know of any real-world usage yet, despite the fact that the specifications required for things to work and be used by real people already exist, and that there's a lot of DID methods (over 80 last I checked) registered, but as people have noted, most are based on blockchain (but not all... there's stuff like the peer, git, jwk DID methods that do not require blockchain)... but I have to say that, in this particular instance, blockchains may actually be a proper solution for a real problem (that of looking up public keys and metadata for entities/users in a distributed, highly-reliable manner).
https://www.w3.org/TR/did-spec-registries/#did-methods
If you want to look for related stuff, look for things that users would need to have to use SSI, like DID wallets... Some random examples I found by quickly searching:
https://www.dock.io/dock-wallet-app
https://identity.foundation/ion/
The OpenID Connect Standard is being extended to support self-issued OIDC (SIOP) which allows OIDC to interact with SSI constructs:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
So, yeah, there's a lot of stuff being created around SSI, but admitedly, almost nothing practical yet... Hence why I was hoping to find something where this work could be very helpful, like logging into Codeberg :)
Pages are either full of calls for projects or buzzwords for existing projects.
I think I've found the page containing implementation details but it all seems to be crypto/blockchain stuff. Disappointing, was hoping for something better.
The quality of the site went down hill, even with ads showing download buttons trying to trick the user.
https://www.pcworld.com/article/419579/new-sourceforge-owner...
I've wanted a reason to use Fossil for quite some time, and this is perfect since I'm the only user for this repository; Fossil is ideal for small groups of people and git is ideal for projects with thousands of contributors.
I'm just using VS Code with a Fossil extension and storing the notes as .md files in the repo. You could use the built-in wiki to store them, but that would give you less flexibility and less of the features of a source control.
Although I'm not yet, I could integrate some other features into my workflow like bug tracking, forum (to talk to myself and hold conversations over time to center myself where I left off), and technotes. I love the web-interface.
The only configuration I needed from stock was to turn on the search feature, change the home page to be my root document (README.md) and set it up to run as a daemon with systemd.
[0] - https://www2.fossil-scm.org/home/doc/trunk/www/index.wiki
I wish GitHub: - had scoped labels ala. GitLab. Project custom fields _almost_ get there but they must be more visible/accessible/filterable via 'basic' issue lists. - allowed longer label descriptions, they should double the 100 character limit - and allow 4-byte Unicode... - had wider milestone scoping
If your project is worth the attention, people will join you wherever you will be.
>and useful for open source project
Embrace, extend...
Recently a large scientific (EU) institution was wanting to coordinate efforts to have data stored inside EU - they wanted a running gitlab server (as many Prof. were just using their own local or using gitlab/github SaaS.
After contacting many EU companies no one could provide a 24x7 (reasonable uptime) services like github/gitlab with just a creditcard.
Too many EU companies suggested we self host. This institute does not have people/space to do it. They wanted Just Works.
Now what happens is that all these students get used to github/gitlab. And all future students become managers/employees - they will go to github/gitlab.
One example missing in the privacy policy is information regarding "the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;" There is more stuff that should be included, see: https://gdpr-info.eu/art-13-gdpr/.
(Technically it doesn't have to be in the privacy policy document but could be provided in some other kind of document. I guess thats not done though.)
> However, you won’t be getting the advanced features like automation or other integration...
Codeberg also has built-in CI support using Woodpecker (ci.codeberg.org). It works very well.
> However, if you are interested in a privacy-friendly GitHub alternative from Europe, I suggest you check out Codeberg.
Important to know that Codeberg only allows to host projects with a FLOSS license. So I wouldn't announce it as a GitHub alternative without a further note.
https://codeberg.org/explore/repos works
https://codeberg.org/ditzes/ditzes works as well
What page exactly doesn't work for you?
Never heard of this before, but I don't think this operates in the same space. Codeberg is a hosted platform, Gitbucket is a self-hostable platform. I think it competes more with Gitea and maybe Gitlab than Codeberg.
There's many privacy and other laws that affect myself and my neighbours in Europe that concern me, but hate speech has never been one of them.
Perhaps wherever you're from you draw lines differently to how we do it in Europe, with regards to what is socially and morally acceptable to say?
I should add that we also don't have a right to "free speech" in the UK as, say, Americans do, and yet it hasn't forced us to keep our mouths shut.
Maybe that's why he has serious concerns? Funny how it's always valid for Europeans to have concerns about America and its differences, but when it's the other way around it's a barrage of "How dare you?!" (just look at the responses to OPs concerns).
The lines are much blurrier than you are brushing off, especially now that we have post-structuralist definitions of everything. Do you trust the interpretation to be limited to obvious extreme things when people can't agree what terms like woman, inflation, recession, etc mean?
Or, think about what happens when a political party you don't like can use the same legal framework you built with good intentions in ways you probably won't like.
/e: lel, he has been warned by dang already for other comments: "Would you please stop the unsubstantive and/or flamebait comments?". So we don't need to bother.
[1] https://about.gitlab.com/blog/2015/07/01/operating-as-gitlab...
[2] https://about.gitlab.com/handbook/engineering/infrastructure...