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.
I think we should emphasize that Sourcehut is just currently free while it is in alpha. Mr. DeVault been very upfront about the fact that he's planning to start charging eventually. From his FAQ,
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).
I think that makes a whole lot of sense. The actual post explains it wonderfully:
>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.
Thank you for calling this out! It's great to see more products adopt this stance and this is one of the reasons we chose to not raise funds for Typesense [1].
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.
Does SourceHut still have an aversion to Kubernetes and Docker? Last year I was trying to setup SourceHut on my home infra (which is Docker/SystemD based, but was Kubernetes based) and I was told I'd be banned if I asked about it, and that they don't support that kind of software. Super weird interaction from someone I otherwise used to admire.
Some Kubernetes and Docker people get somewhat religious about it, and rather than taking “I/we don't support that and don't have any immediate plans to, but feel free to try it yourself” as a valid response will plead, nag, and otherwise try to cajole a project's maintainer's to reconsider, sometimes being irritatingly persistent and calling into question a person's overall intelligence because they don't currently want to directly support that plumbing. Such discussions can become time-consuming, tiresome, and (if really persistent in trying to convert them to the cause) difficult to just ignore.
> 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.
Bah, what a dumb argument. There's a whole ocean between "we don't really support Docker, you're on your own" and "if you dare ask this again, you'll get banned." That's not the Kubernetes guys being religious here.
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's a whole ocean between "we don't really support Docker" and "if you dare ask this again, you'll get banned."
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.
Perhaps there is a difference between "not wanting to engage on the matter" and "banning someone on sight"? Maybe there's polite ways to say, "Sorry, but we're not interested in supporting docker, and we don't care about any arguments for it" that would take less effort than rudely telling someone to fuck off?
Of course the suggestion of “banning on sight” could have been an attempt at humour by way of hyperbole, something I should have noted in my previous reply.
> 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.
> 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.
It was on Libera in a public channel. It wasn't humor. I'm very used to the IRC crowd and recognizing even the cringiest of humor tactics. There's also another person on this thread now who Drew reacted similarly on a mailing list.
I will be very surprised if Drew isn't called in by his communities at some point.
> Some Kubernetes and Docker people get somewhat religious about it
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.
Drew seemed irritated when I posted a Dockerfile for setting up the Hare language language compiler for development on the mailing list, trying to save other folks the effort.
We're going to start looking into k8s and Docker soon as one of the candidates for infrastructure in our new datacenter rollout, but don't hold your breath. It will be a while before this bears any fruit and we may decide it's not worth it.
Orchestrators and runtimes should always be carefully chosen, if at all, so that's great. Sounds like you have some smart people working on it. My post was less about the tech and more around the culture that's been established at SourceHut with respect to those technologies. If I can't even join #sr.ht and ask about images or strategies others are using that's going to be an issue.
#sr.ht is an on-topic channel for end-user support and development discussion. Since Docker/k8s has been rejected upstream, it's off-topic for #sr.ht. The channel needs to keep quiet and keep a high signal:noise ratio to make sure that users get attention when they need support. That said, you could discuss it on the off-topic channel, #sr.ht.watercooler, if you like.
Speaking from the user side on CI usability, SourceHut, while not supporting a cache (which would be dope), has been pretty good with Nix and supports running NixOS unstable as an image for CI. This has been better for me than wasting steps building containers from Nix and then running the containers that some CIs require. I believe the SourceHut setup is in nixpkgs too to run yourself easily.
Pretty feeble argument. Basically it boils down to "if you use Docker you risk not learning how it works and hurting yourself." As I mention in the sibling comment, it would feel less patronising just saying out loud "we do not like containers, roll your own."
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.
Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that?
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.
Docker != containers. You're arguing as if the srht or generally the diy anti-kubernetes crowd was against containers. Or as if docker was the only mean of secure isolation. More likely than not you'll find them running bwrap, lxc, qemu, etc. You're missing your opponents here, it's very much the opposite of conservative sysadmins that went incompetent and don't understand the new tech. It's (imho) people that are fed up with the "click here to deploy a production server", the "infinite elastic scaling" and the fact that most of these false promises are hidden by bloated software. Nobody is saying that docker gets nothing right, just that most of the time others do more of the good and less of the bad.
> 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).
> Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that?
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.
> Docker and K8S are sharp knives with no warnings on them.
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.
> 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.
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)
And that's before you have parts of your stack running Node, Python, .NET, Ruby, PHP, Go or whatever else you might have to deal with. You can basically forget about automatically provisioning ACME certificates through Let's Encrypt, as well as being able to (easily) have all of your certificates in one place (at least for whatever that node needs), for easier renewals. This is especially noticeable when you want to serve dozens of different sites/applications from the same node.
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
So, how is that a bad choice? Some reasonable arguments that I can come up with are:
- 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
Perhaps I'm missing something that's staring me in the face.
Has ddevault ever commented on how much build minutes will cost out of alpha? From their pricing page it seems like a fixed monthly cost for unlimited minutes, which doesn't seem sustainable to me.
Right now it’s unlimited*, where the * means that you’re not allowed to abuse it by doing things like Bitcoin mining. So far the model seems to be financially sustainable (they release quarterly financial statements).
Worth noting as well, from the list of various hosting services, Codeberg is the only one explicitly for FOSS software and not for proprietary software. Sourcehut seems to be in the box of everything for running the service is FOSS but they would be OK with hosting non-FOSS software, whereas Codeberg isn't for hosting proprietary software at all.
> 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. [...]
I have a lot of love for framasoft, but beware that they have limited resources and have in the past closed down or geofenced services I was relying on.
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!
I no longer trust bitbucket after they shut down their mercurial support. That was the thing that differentiated them from everyone else. Why even use them now?
Bitbucket is like an ex girlfriend you don't quite recall why you broke up with, but afterwards every time you meet her and hear her voice it all comes back in a rush how disgusted she made you feel.
Can't you just run gitlab or whatever else out of a container in 5 seconds nowadays? Map a single volume and you are likely done. Its not that it's hard to self host that I choose to use third party git services (its clearly not!), it's just that the benefits of self hosting a git repository are increasingly few unless you have strict security requirements etc etc, and the free options are so good now. Running self hosted git is trivial in 2022 if you really need to, with many one-line container deployment options to choose from.
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.
Yeah I'm sure you could. I use that VPS for my blog and personal projects also so I wanted to keep resource utilization to a minimum and not administer a webapp.
Gitlab has a nice GUI, team features, and CI/CD integration. It's a reasonable choice for a team.
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.
If you add a git-daemon-export-ok file to the repo, it's accessible read-only over the git protocol. That's how all my repos on https://git.jeskin.net are setup.
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?
The best way to collaborate would be just sending patches, either with git send-email or as an attachment to a regular message. Then the author applies them and the repo/stagit will display the change.
Please keep in mind codeberg runs on donations (like mine :) ). If you join and have resources, consider donating (they're on LiberaPay). Their finances seem healthy and sustainable for now.
Which is a Chinese site hosted behind the GFW. I can't even access the site because they block my IP address. I really hope OSS projects don't consider them for their hosting.
I guess it's the same stuff developers from other countries like Iran, Syria, etc., face when trying to work with Github. It's a shame many OSS projects find providers like these OK when there should be plenty of alternatives that don't block users by country.
I know, but not all of the alternatives noted by the parent post are hosted in Europe, either. Some are US based, and it doesn't mean your project can't be subject to censorship.
I'd exercise caution building on top of it since I don't think Zoom cares about Keybase and I was unable to find any server among their repositories (https://github.com/orgs/keybase/repositories) such that one could self-host after Zoom bores of running the Keybase infra
Wait, most if not all are not noscript/basic (x)html friendly, what codeberg seems to be. Ok, github.com has most of its critical functions (microsoft has managed not to f*ck it up... yet) working with a noscript/basic (x)html browser, gitlab and bitbucket, not even possible to create an account, and if I recall properly, neither for sourcehut.
There are other git services which are noscript/basic (x)html friendly from the ground up, and EU based, but much less popular.
I... don't think that's true of Sourcehut? Drew has certainly argued for the fact that websites should be usable without Javascript, so it would surprise me if Sourcehut didn't follow the same standards.
gitlab and github both provide a program that runs on your raspi and executes the ci pipeline. Search for ‘runner‘. As a solo developer, you can even install the runner on your laptop. It will only be needed while you’re connected to the network anyways.
> 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].
I'd like to plug self-hosting via Gitea. I have it running on a Raspberry Pi Zero(!) and it works really well[0]. I no longer star projects on GitHub: instead, I mirror them onto my Gitea server which periodically syncs in changes with a cadence of my choosing[1]. If a project I depend on ever gets deleted from GitHub, I'll have a reasonably up-to-date copy.
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
What kind of machine (specs) would I need to run to self-host gitea with decent performance? Small container or EC2 instance (or droplet), etc should be enough?
Err...I guess you sort of answered my question since you're running it on a raspberry pi :P Performance seems just fine? Curious to hear more about your experience. Thanks!
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.
I initially used the class-10 microSD card that boots the Pi, but I've moved to an ISCSI mount on my NAS, mostly because I have an unsophisticated LFS setup
Remarkably, Gitea can also run directly on my NAS with it's very slow CPU and limited memory. I wouldn't be surprised if it runs on other "appliance"-type devices like routers & NAS with 10+ year-old ARM or MIPS microprocessors.
Nice to Woodpecker CI getting some traction. Great software for selfhosted ci. Simpler to start than Jenkins, not as flexible ofc, but most projects do not require that amount of flexibility and footguns. Woodpecker one of the best tools for small/medium self-hosted CI's out there atm.
I just took one look, I had never heard of it before, and... it's depending on the serialization order of steps in the YAML to run pipelines?! What fresh hell is this?
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?
I am not hating on the whole of YAML, but the way they are misusing it in Woodpecker. None of those other services you mention are doing something this bad, e.g. relying on parts of YAML that are NOT standard (ordering of elements in a dict) and not supported by some languages/libraries.
> From what I’ve seen, the config uses dictionaries for concurrent pipelines.
Oh wow. You’re right. That is dumb. When I glanced over the example config file it looked like frontend and backend was intended to run in parallel (because that would have been the sensible way to design it).
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.
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.
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.
I'd guess Linux is the most important platform for most customers. Also, it's probably the easiest and least expensive platform to support. I'd be very surprised if they'd picked another platform to support in their initial release of this feature.
The "every job uses a Docker container" is what worries me. Because the other two certainly don't have a robust container mechanism. Sure, Windows has something, but it is a far cry from "pick a distro, install some stuff, and call it a day" because there's some blessed image that supports installing .NET stuff and if you don't base on that, you're SoL (at least last I checked). And that's even ignoring the lack of rendering if you need it or the filesystem performance hit they seemed to be plagued with.
In the event of things going nasty with export regulations, it appears we are left with FOSS UNIX clones, and ISO/ECMA based programming languages, or those independent from corporate stewardship.
The underlying tech (Woodpecker) supports running tasks on Linux, MacOS, and Windows. It seems like they are still just in the testing phase, maybe they need a customer to run builds on all 3.
I don't see any docs about that. How is the `image` value used on macOS and expected to contain some usable macOS filesystem layout? Are you expected to SSH to a machine running the target platform from a Docker container and run the commands that way?
Yeah the docs are lacking. The way Woodpecker works is, there is a Server, that is sort of the "manager"; you only run one of these. You run one Agent on each host that you want builds to happen on. The Agent then executes the steps of your Pipeline on a "platform", which is an Agent running on a particular OS.
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.
here in the USA, Apple and Microsoft repeatedly lock out Linux|*nix from interoperability, marketing, transparency and more .. Linux Foundation appears to be a marketing club for Fortune 500.. where is this perspective ? You developers must include proprietary duopoly in any "open" effort but wait at the back door until I return and tell you what I want to ?
Projects I work on are cross-platform. When evaluating or comparing CI solutions, is that not a requirement to consider?
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.
I really don't get why do every org do this. A simple mail about the takedown to the owner with few lines explaining the situation shouldn't be difficult, and I would say it is the best ROI to prevent PR damage like this.
Any service known for not proactively removing content will be overburdened as users from other services who submit 'complaint-generating' content will flock to your service.
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.
Taking down content immediately based on one party making a claim is ripe to be abused. Take down the wrong person and masses will gather and call you out as well. This site has a question mark after they did this. Just based on that information I wouldn't rush to this service because someone will have an easier time shutting the project down here than elsewhere
I am not saying don't remove content. I am saying that mailing 5 sentence reasoning would just take 5 minutes and would save lot of pain specially for complex and effort taking content like code repository where the volume of removal is likely less than handful per day.
In this particular case - at least from the meager scraps of information I can gather - Wikiless was taken down on trademark infringement concerns, and the creator hasn't had the time to do the necessary modifications to properly debrand their fork.
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.
> Obsidian does not offer free syncing between devices and you will have to manually set up a method to sync your notes, either by using something like Dropbox, Google Drive, or Git.
its pretty much a modified instance of Gitea with a small, privacy-friendly German Gmhb behind it. Still like it a lot. Wish more developers at the very least set up mirrors on either Codeberg or Sourcehut.
Shame that they don't seem to support the European Self-Sovereign Identity Framework for registration: https://essif-lab.eu/
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 will probably be a corporate-circlejerc like GAIA-X again. The website is just bad at explaining what's going on. It reads like an academic paper and is not user friendly at all. Do you have any experience with that?
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.
> Looks like a bunch of cryptocurrency/blockchain people scooping up government funds
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 ...
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).
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).
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:
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 :)
The premise looks very interesting but I can't tell if this exists or if it's a call for contributions for a broad idea. Based on the home page I'd assume this system is not net implemented, let alone functional.
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.
A forge run by a nonprofit is better than a forge run by Microsoft or another for-profit corp but I think the ideal would be having projects host their own code with federation between the different hosts to make contributions from "external" users easy. Thankfully there is ongoing work towards that goal: https://forgefed.org/
Slightly off topic, but wtf happened to sourceforge? A decade ago it was _the_ place to host open source projects. How did they lose almost all of the market share to GitHub?
they got caught packaging installers with adware / bloatware. Lots of projects / people moved away from it. After the backlash they reversed the policy but the damage was done at that point already.
Github makes money from private repo subscriptions, Sourceforge was ad based. Also Github focuses on source code hosting, a lot / most Sourceforge projects just hosted the release files to a project.
The quality of the site went down hill, even with ads showing download buttons trying to trick the user.
For the use case of this post, revision/version control of notes (markdown/text), I recently started using Fossil [0].
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.
The problem is that GitHub is so endemic, and useful for open source projects that simply need the traction/eyeballs.
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
Firstly I appreciate these initiatives but I think this misses a large point of why github or gitlab is popular.
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.
The privacy policy is not compliant from what I see. I still love the mission but it just leaves a bad taste in my mouth - if one makes privacy a marketing point then at least the privacy policy should be compliant.
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.)
Consider filing an issue in https://codeberg.org/Codeberg/org. I had an data protection issue earlier and emailed them (from Impressum) and they dealt with it really well.
> 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.
I've moved a few of my repos over to Codeberg, but I'm not entirely happy with their reliability, having had at least two outages in the last few months where I couldn't browse repositories on the web interface.
I've used GitHub around an order of magnitude more than Codeberg (mostly for my older repos and other people's current repos) and GitLab still, but from my limited sample size using Codeberg, it's been down an order of magnitude more than either site you mentioned.
Kind of ironic to host the website for a (partial) Github alternative on Github.io.
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.
i would have serious concerns about hosting in europe due to hate speech laws that are muddy and ripe for abuse. the site doesn't have a hate speech policy i can find, is anyone here informed on exactly what the ramifications of such laws might be?
>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?
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).
No, it's more that we Europeans scratch our head as to what he wants. The comment reads like a troll post. Why would code be nuked for hate speech?
/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.
Well if you are not worshipping Nazis or trying to push hate against minorities you shouldn't run into problems.
But I'm quite sure most other services in the states wouldn't tolerate such things too
Google "Is ___ racist?" (inserting almost any term: gardening, math, science, climate change, doesnt matter) and you will always find academic and mainstream opinion-piece proof that it's racist against "minorities".
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.
i have serious concerns about hosting in the US because US companies often remove content or lock out or terminate their users/customers for unpredictable reasons. in europe at least i can read up on what the law is, and expect that as long as my content is lawful, it will not be taken down.
Another comment mentioned that they took down wikiless without warning or explaination, and then the explaination that eventually came later was still not great (complaint from wikimedia). It doesn't sound like they are so much better on this point.
right, things are not perfect, and people make mistakes, but that doesn't contradict my claim because it should still be possible to object to the takedown and take measures to get the host to reinstate the content if the IP claim was wrong. in the US, in the same situation there might not be a recourse.
Btw does anyone understand Gitlab’s pricing? Their cheapest offer ($228/user/year) is almost as expensive as GitHub’s most expensive offer ($252/user/year). We are a team of 5 using Gitlab.com, but when we’ll grow to 6 we’ll have to go from $0 to $120/mo in order to continue using it. I’ve heard bad stories about self-hosted Gitlab and I wouldn’t like to have yet another internal service to maintain.
Nowhere else do people mention the continent as much as Europe. And, for the life of me, I don't know why this is!? And it always seems to mean "we respect your data". Let the product speak for itself, I'm not switching from something that works well to something that works okay, but respects my privacy a bit more.
It's not so mich about the continent more about the jurisdiction, europe has GDPR which seems to do an ok job. You don't have to switch to a more privacy focused service but it's good that they exist and you can see that more and more of those services are popping up, protonmail for mail, duckduckgo for search and so on
I understand what you did, but I don't think it actually answers the question. Saying an organization is based in Europe does not mean they are bound by the GDPR. If that was the intention then it should say EU to make it clear.
• 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 (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.