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
• https://github.com/
• https://gitlab.com/
• https://bitbucket.org/
• 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.
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.