Evaluating new software forges
notgull.net
notgull.net
I'll be honest, I do not trust cryptocurrency stuff and don't believe that it has utility. I hold none, I don't use it. That being said, this makes me wonder what the next category of projects that SourceHut will ban is.
What is the point of a free software forge if you can't host certain types of (legal) projects? It's hard to take a platform seriously, to move all of your work there when the administrators can (and most importantly, actually do) ban your projects based solely on their personal views.
[0]: https://sourcehut.org/blog/2022-10-31-tos-update-cryptocurre...
I also have no interest in crytocurrency.
> We will exercise discretion when applying this rule. If you believe that your use-case for cryptocurrency or blockchain is not plagued by these social problems, you may ask for permission to host it on SourceHut, or appeal its removal, by contacting support.
First of all, it says that you can talk with a real human about this, second they are very open it.
When contrasted with a certain forge owned by Microsoft, which reaps my source code w/o my consent & regardless of its license to train a model which do not approve, Source Hut's stance is much more acceptable.
I'm fine with companies having opinions, and I love it when they're open about them instead of being faceless and do unpredictable things to benefit themselves.
And lastly, nobody forces you to work with a company you don't agree with. I don't work with GitHub anymore, and you're not preferring SourceHut. That's OK.
GitHub owned by MSFT aside, and also putting their AI push _also_ aside, GitHub has things like Sponsors, Dependabot, and code scanning that you won't find anywhere else. They sure are luring you into ecosystems that require a huge escape velocity, but GitHub serves as less-friction entry point to open source software.
GitLab self hosting is also nice and flexible, but it has a more "enterprise open source" feeling to it. Debian and Drupal can take advantage of it, but I don't see myself hosting mini projects like my mini CSS library that is also used by three other strangers.
Source Hut is really nice too. Admittedly I don't like email based workflows, so I haven't really thought about moving anything there. But Source Hut has "unlisted" repos, which I thought was really clever and missing from other forges.
Gitlab has equivalents you can enable as CI pipelines.
So I think I'd put gitea* on that list as well.
(I don't think I disagree with your opinions about the ones you -have- listed)
* and I mean that to include forgejo, I think, though I haven't tried it so YMMV
Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again.
I'm looking forward to the federation work that is being done for forgejo, that will be big if it works out as it seems like it will.
Git is decentralized.
And if SourceHut disappears, what would you do with the repository? You’d upload it to a new forge, but how would you tell users where to find it, how would the users know this is the original source and not a hostile fork? It’s better to pick a stable, trustworthy. and 21st-century place like GitHub or GitLab instead of SourceHut.
It's better to not make yourself (much) dependent on functionalities that only the respective software forge provides.
There exist many ways for this. Why does this have to be the same provider (if you don't want to self-host this functionality) as the one that hosts the server for the VCS?
I would call expecting any developer to do it differently quite an entitled opinion. And DeVault has a way better track record on successful projects (some of which continue being successful after he moved on with the help of the communities he fostered) than any of us really.
Experience shows that it's very difficult to make a business work on top of open source software and he is doing it as we speak. Your complaint smells like a petty grudge in the face of all the other things that could be said about his projects.
> Not a very serious option if you're looking for anyone from the 21st century to contribute to your project. No, the email workflow doesn't get better by just screaming "it's not that bad!" over and over again.
Perhaps the maintainers of the respective project consider filtering out contributions from "hipster programmers" actually desirable for the project. :-)
My experience self hosting Gitlab was pretty terrible, it requires a lot of attention on your part, and internally the project feels like a bunch of fragile scripts.
There’s also little documentation for when things go wrong, with was almost every single update.
In the end I switched to Gitea as well and I’ve been happy with it for years at this point.
I've tried github actions, drone, woodpecker and gitlab. In my opinion gitlab has a much more flexible CI system.
Had two upgrades that needed minor manual intervention in 5 years. Uptime better than Github despite the #yolo approach.
Link: https://radicle.xyz
But honestly, I also wouldn't write about this without a lot of usage experience. For sure it's different from github/-lab etc. exciting and new, as you say.
There's also nothing wrong with LLMs. How you choose to integrate them into your life or forge is a choice but at the end of the day they're just another tool in the toolbelt. Pick what you want or need and leave the rest. I'm not forced to use Copilot but I appreciate it when I need it.
So, it's probably not your jive.
Today in software companies there is basically a gap where each discipline kinda prefers to work in it's own software silo (eg. Asana / Figma / GitHub), but that doesn't really make a lot of sense from a fundamental standpoint where all of those aspects of a team want to work very closely together. You end up kinda syncing a lot of info/state across the silos, or via meetingss/slack etc, so I think Pierre is trying to bring all that into one tool with some opinionated workflow. Makes a lot of sense from my perspective, curious how it ends up working out.
That's my own take -- for Drew's see https://drewdevault.com/2023/10/31/On-real-names.html
I'm just not comfortable putting myself out there like that. I get it's not technically against the rules to do it differently, but it's just... frowned upon.
Other justifications included that my peers would be sharing their real names and personal email addresses, so I'm being non-courteous by not doing the same... I dunno. It wasn't a particularly productive email chain, but it told me all I needed to know.
And it's not "Logan Dark", it's "LoganDark".
A portmanteau word of "hapax legomenon" (https://en.wikipedia.org/wiki/Hapax_legomenon) and "pseudonym", i.e. a pseudonym that is used nowhere else.
How do you define what repos you need and which commands are run? Ah, it is indeed also a YAML file: https://srht.site/automating-deployments
That was definitely the most bullshit criticism in the article. Clearly not even something they actually care about because they settled on Drone CI which is configured in exactly the same way.
It took me an embarrassingly long time to learn that you don't need to use their little action plugins for everything.
Once I figured that out, and figured out how to run CI in a container specified by the repo, I was actually quite happy to transition my CI away from Jenkins (which was always pretty rough, but I knew I could keep the builds running locally that way).
I guess the real proof will be if I'm able to ever leave GitHub, but I feel pretty good about the amount of lock-in vs the benefits of the service.
Would you happen to have an example YAML at hand?
https://github.com/ahepp/resume/blob/d7778b1339271cbd7812634...
It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile.
So when I'm developing on any Linux system, I can run
$ docker build .ci/Dockerfile -t my-container
$ docker run --rm -it -v $(pwd):/project -w /project my-container
I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for.
I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced:
https://github.com/ahepp/resume/commit/a144ee06b868ae867b287...
For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.
> Hyper Performant & Hackable Code Forge Built on Open Standards. Ayllu is a lightweight code forge designed to enable individuals and community projects to develop software in collaboration across open internet standards.
Weird the author said email was a pain, but last patch I received it was as easy as `himalaya read --raw X | git am` to apply & pointing out that modern email clients do a bad job supporting this seems more damning of those clients than the workflow.
EDIT: here's how I do it, in case it's useful: https://github.com/Misterio77/nix-config/blob/a74b2ede/hosts...
…It would be great if darcs had Pijul’s channels …or Pijul’s CLI UX had parity with darcs
Perhaps I'm being too nitpicky, and there's nothing inherently wrong with their final choices, but their criticisms of the other systems alongside their reasons for choosing what they did are contradictory; overall the article was internally inconsistent.
Gitlab was dismissed for the SaaS being only open-core, despite opting for self-hosting in the end. Codeberg was dismissed for having limited CI, but in the end they went for a separate standalone CI anyway (& almost the same platform as Codeberg, just with the added overhead of self-hosting).
Yet they ended up choosing a self-hosted option, Gitea, because it was recommended by an acquaintance and they set up a couple lightsail servers on AWS to run it.
It's totally fine for the author to share their preferences; they're just exhibiting the internal inconsistencies and irrational behavior we're probably all guilty of at one point or another.
I think the only thing you'd lose is the 'social' aspects of GitHub, but I believe that can be made up with a combination of rss feeds (?), ActivityPub etc.
We need to separate discovery from hosting across the web. It's convenient to implement them together, but certainly not necessary. Bring back the link aggregators!
But in the end I like it — mirroring self hosted source forges to github seems a good way to raise awareness of github alternatives.
They spent a lot of the post saying how they didn't really want to run stuff,
> However, I’m a software developer, not a sysadmin. I want to spend my time developing software, not putting out fires and paying AWS bills for the rest of time.
But then their friend convinced them to "kubectl apply" a couple of manifests & they got a bunch of stuff spin up quickly, on what should be a reliable-ish maintained-by-other-people cluster. This is the first time I've seen a win like this & it feels like such a sweet spot!
Like you, I have been using it since it was experimental, and it has been very nice.
My only complaint with Gitea Actions was that it required Docker specifically, not other OCI-compatible runtimes, but they recently added support for rootless Podman, so even that is no longer a complaint.
They don't like "AI-powered" because it is a vague, ill-defined term... except it's extremely obvious and well defined what GitHub means by that (and they've even used copilot and liked it!)
Gitlab CI is rejected because it uses YAML for config... like every other CI system they mention.
Gitlab isn't ok because it's open core, but Drone CI is.
Could have been an interesting comparison but it wasn't.
This blog post and the revenue growth at Gitlab over the last two quarters appear to be evidence of people wanting to moving away from GitHub (though their earnings report attribute the growth to other initiatives, clearly I had no real insight on this). As an extension of my self hosting of Mastodon efforts from last year I rolled up my other minor hosting efforts into https://hawt.cloud as a place to experiment with providing services like this.
This all ties in with the “Open Web” or “Small Web” sentiments I’ve seen expressed recently. The hyperscalers are locking more and more up into their ecosystems but there should still exist small vendors/hosting/service providers. They’ll never scale or be as reliable as the big guys but if they cease to exist a lot will be lost.
My github repositories were changed to point to it. The latest change by Microsoft made me move, I was considering a move when Copilot became a thing. 2FA got me off my butt to finally move.
It was not really complicated to install but the resources that it is using are insane. First, it would not even start if you don't have a dozen of Gb of ram available. Also, even if completely empty, the thing would take 30 mins to warm up doing I don't know what before being available for initial setup.
In honest opinion, trying so much to copy GitHub, Gitlab became a heavy bloated software stack.
- clone repo from original forge, push on yours
- open PR on your forge, kicking in a like-blog-trackbacks-of-yore API so that the PR would be known/opened on the original forge.
The thing would really put the "Pull Request" back in PR.
Lots of things to define and handle correctly to prevent abuse but it could be a much better distributed experience.
I guess big players like GitHub would nit like that too much though as it would fragment their coding social network.
In the discussion I also read about ForgeFed[0], also ActivityPub based, and which Forego is apparently implementing[1].
[0]: https://forgefed.org
I would agree... in its GitHub incarnation.
> You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.
Which is... where? The PR+fork model is what that implements: fork for the always-on storage so that upstream can fetch from it, PR for upstream to be notified about, discuss around, follow subsequent updates of, and track integration of the changeset.
The problem in the GitHub model is that it's all happening on a single centralised platform, removing the distributed benefits of Git at great benefit to GitHub through network effects, stifling competition.
What I propose is that the always-on storage need not be at GitHub, and there'd be a notification system towards GitHub to point to that always-on storage. Could be a bare GitHub repo with GitWeb (which is something one has to set up) + a curl to an upstream API endpoint, but sooner or later people are going to want to have a bit more than that, so having a forge do that (either a self-hosted one like Gitea/Forgejo or any hosted one like SourceHut/Codeberg/GitLab/Bitbucket) is practical.
This essentially makes forges interoperable, restoring the distributed nature of git development that GitHub killed by centralising git hosting.
(Of course you can s/GitHub/whatever-derivative/g above, I just focused on GitHub for the sake of simplicity because it's the monopolistic elephant in the room)
We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary.
If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor.
> I would agree... in its GitHub incarnation
No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them).
It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)
Has anyone else found themselves wondering if GitHub switched to a different web framework?
I feel like they moved further down the client-side rendering rabbit hole recently. Their UI feels increasingly janky to me. Several times a day I get a view of completely un-styled HTML that eventually organizes itself into the appropriate presentation.
For many scenarios, the GH web UI used to be preferable over navigating through visual studio because of how responsive it was. Now, I find the exact opposite to be true. I avoid the GH web UI as much as possible. VS2022 isn't great, but at least it's not implemented using react on top of some bullshit chrome wrapper.
I intend to start some drama with GH over this. ReactJS will win if we do nothing.
> If you want to create a repo for PR’s sake, email me at dev at notgull dot net and I can set you up.
So is there no way to allow seamless forking like on GitHub without high risks of abuse?
“”” AI Services q. AI Services. "AI services" are services that are labeled or described by Microsoft as including, using, powered by, or being an Artificial Intelligence ("AI") system.
iii. Limits on use of data from the AI Services. You may not use the AI services, or data from the AI services, to create, train, or improve (directly or indirectly) any other AI service.
“””
If you ask GitHub Copilot Chat about the issue, it/they suggest seeking professional legal advice. To use GitHub Copilot. An AI trained on our AI code from GitHub. To write AI code. For paying customers.
https://drive.google.com/file/d/1DIj6-mgyxVRBJNEeVZMV8t8ec2L...
Satya Nadella is King Midas. I emailed him and their legal team about it many times and he could have personally gone into the codebase and deleted this service term by now. I reported them to the State of Washington Attorney General (you can, too), and to the Federal Trade Commission Antitrust Team (you can, too), and to the Department of Justice Antitrust Enforcement Division (you can, too). Unclear how to report this to the EU Parliament AI Act folks, but maybe they posted new info since I last checked.
It’s a single line of text, certainly unfair and unreasonable and almost surely illegal in pretty much every relevant jurisdiction, so there’s certainly no an argument to be made that the fix is too technically challenging, even in light of Microsoft’s historical ineptitude.
We could check to see if Washington State has laws against contractual restraint of trade like California does. (Hint, Hint.)
Why release free software if you don’t want others to use it?
Why provide any code to GitHub if you don’t want GitHub to use it?
This is just tribalism, the ideology isn’t even consistent.
Most of these systems are an amalgamation of scm, ci/cd, issues, wikis, project management, security integrations, static site hosting, review workflows, management of release artifacts etc etc.
Also there is just something about its sidebar-centric UI I just don't like. It's not as bad as gitlab but still, it bugs me every time I use it.
In this case calling k8s a "nightmare" is a strong red flag akin to the mantra of "java is slow". It lacks the nuance of hands on XP and reeks of rules of thumb miss applied to the point of catchphrases.
FWIW I find the author's obviously subjective opinions on their tools much more valuable than your obviously subjective opinions of this author.
At least w.r.t. the original comment, this seems like a misunderstanding. GP was saying that, absent any explanation for why the author came to the opinions they did, the article doesn't say much of value. They don't dislike the author sharing their opinions on the author's own blog.
I've just been noticing a trend of people, like the article author, who are quick to dismiss things for reasons that are inconsistent and dogmatic. Why be so close minded? I think it's okay to be dismissive of the dismissive. Which, I didn't really dismiss him did I? I read his entire article.
They’re saying that we, as a community, should not elevate unsubstantiated writing that comes across as “I don’t truly understand these things or have deep experience, but this is what everyone else says on every other blog post or comment, and I’m parroting it”.
I would add on to it that I feel there’s sometimes a real thing in these discussions where reviews like these often come from people just tinkering and looking for the next thing to mindlessly experiment with. It’s not always representative of real world trade offs.
(I say all this as someone who self hosts a Gitea instance)
Kubernetes is a nightmare, and I'm glad that some people are not afraid to point out the state of the emperor's outfit.
Kubernetes started in a rough shape but it has been chiseled over the years to be boring tech that just works and provides a layer of abstraction to build abstractions on top of.
I've been working with Kubernetes for the past 6 years. It's fine. It does its job. Let's all move on from the outrage.
It's a type of "security" that doesn't find an answer in "better AIs" or "AIs with improved alignment". The value comes out of being safe from the risk that can come out of the humans in control of these AIs.
I comes out of staying away and making impossible for any and all AIs to touch it.
Like the difference between food from a chef and hyperindustrialized food.
What if you want chef food only?
In the same way, exclusively human software creations.