Makes sense. SourceHut is probably perfect for Postmarket OS. Both have a strong taste for minimalism and free software. Choosing hosting provided by SourceHut instead of self hosting may also help fund SourceHut itself so that's good too. Go for it!
I too am not really happy with GitLab.com. It requires contributors to fill a reCAPTCHA and I'm not a fan of it being open core. I chose Gitorious (and was moved to GitLab.com when it disappears) precisely because I don't want to endorse proprietary software, nor tracking. I don't want to run proprietary code - from Google! - and, above all, make people run Google's proprietary code and tracking. That's just not coherent. GitLab is considering moving to hCaptcha if I remember correctly but that's still proprietary and still a third party.
So I made the jump two weeks ago. I now self host my code. I pay for the resources I use so no more strange free lunch. I personally find SourceHut a bit bare but that might just be habits. I picked Gitea instead. People can log in with their GitHub or GitLab account if they wish so the argument that it prevents contributions because you have to create yet another account does not hold. Gitea is quite fast and works well without JS at least for consulting the code. It's quite easy to set up - I have already been self-hosting a number of services for years know. It's also very straightforward easy to use - much more than GitLab so far. I don't force anybody to run proprietary software to use or contribute to my projects.
For people who don't want to self host but would like an alternative to GitLab, Codeberg [1] is worth checking out, in addition to Source Hut. It uses Gitea. It's been mentioned in one of the latest blog posts from Drew Devault (the creator of SourceHut) by the way. It's hosted in Germany, too, if it matters. I guess it would be good to support them.
> So I made the jump two weeks ago. I now self host my code. I pay for the resources I use so no more strange free lunch.
I also chose this exact approach.
Previously, I ran GitLab, GitLab Registry and GitLab CI and while I think that it's a nice ecosystem to work within (especially at work, where it still is an excellent option, as long as someone else manages the instance), it was also a bit heavy on the resources and updating across major releases... just didn't work. I wrote about that previously, "GitLab updates are broken": https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
So, eventually I switched over to Gitea, Drone CI and Nexus, all of which now comfortably live on a single VPS with 4 GB of RAM. The performance is good, the resource usage is acceptable and when things break it just takes the individual component down instead of the whole platform (which is also nice for more granular updates).
Of course, actually applying those updates is still somewhat of a problem and will definitely be so until the end of time or until I get enough spare income to make someone else worry about all of that for me (including moving back to cloud platforms and paying for private Docker image storage, CI etc.).
But honestly my current setup is good enough for me, at about 6 euros per month for the hosting (my time is more or less worthless so not counting that).
When I write GitLab.com, I'm referring to the service, not the software project. The service relies on reCAPTCHA. The project provides the feature but does not require it nor enable it by default.
I'm not going to say that GitLab is evil. I don't think it is. I don't see the world like this anyway. But yes, there are proprietary bits involved in Gitlab.com (and the service actually runs Gitlab EE afaik). What do you expect from me as a free software enthusiast? Close my eyes and suck it, or live to my principles, which is easy considering there are good open source forges that are also not based on an open core model?
As cool as GitLab is to the eyes of many people, I don't like making unnecessary exceptions.
Now, I would still be fine self-hosting GitLab CE. But from a technical perspective, Gitea is probably better than GitLab for me: it's lighter on resources and easier to maintain. I also like the UI better.
As I read it, they are searching for a free service.
AFAIK Sourcehut is only free currently because it is in alpha stage. So it will cost at least $20/year in the future. (Which is still way cheaper than GitLabs Premium plan, but still: it isn't "free")
I don't think people think enough about that fact. Sourcehut is not a "free" alternative if you plan long term.
I think something like codeberg.org would be a real "free" alternative. Because Codeberg - as a non-profit - doesn't plan to sell anything in the future.
- It's always affordable; if you cannot pay for any reason then you'll be given free service.
- Payment is not required to contribute to projects, just to host them.
- Paying for SourceHut makes more sense than paying for other platforms. The money stays in FOSS and keeps the platform accountable to its users, not its investors. Choosing a free service means that you're subject to someone else's demands -- that is, whoever is actually footing your bill.
pmOS is already aware of this, in fact they're already paying to use the CI service. Still: it's important for new users to understand this. Everyone who signs up is sent a welcome email which lays out these details.
Free as in beer or as in freedom? In podcast they say that GL isn't entirely open source and they don't like that they're using some proprietary features of it.
(1) “After gitlab.com's recent changes to the free tier, we have been seriously reconsidering if gitlab.com is still the best development platform for postmarketOS.”
(2) “SourceHut is a great match for the postmarketOS principles: AGPL licensed, no Open-core model; ...”
Correct. Free doesn't mean free of cost in Sourcehut's sense. Running a service like that, that scales, is hard when you don't make much money. They have every right to charge for usage of the main site. The cool part is that the entirety of the platform can be self-hosted, and nothing's hidden from you. It's also super minimal compared to GitLab.
I use sourcehut for a few projects, and I love the build system. I don't have extensive experience with build systems, but I've explored a handful. What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds. As a result, there's also not much about it to learn. Most of it uses my existing knowledge of Linux and surrounding tools.
The git-by-email setup is more inconvenient. I haven't found an email setup I'm comfortable with. I also haven't tried a lot, but with a pull request system like github there's not really anything to try.
>What I love about sourcehut's build system is that for the most part it's just straight up scripts/commands. If I can do it in Linux, then I should be able to get it going without difficulty via sourcehut builds.
FWIW, it's possible to do it for GitHub etc as well. These CI providers try to get you to use their bespoke "Actions", ie custom DSLs that only work with the one CI provider, but nothing prevents you from ignoring all that and just writing an "exec this shell script" step. It's what I do for all my GitHub repos. I can run the script locally just like the GitHub CI does it in its VMs.
It really is the way to do it. Then you are also version-controlling your build-setup and if the cloud or your self-host solution is down at the wrong time you can instantly run an equivalent build locally.
The cloud is really about one thing and one thing only. Vendor lock-in. I don't accept that. And I don't see any sensible reason for it.
Due to the distributed nature of git, that's not actually required. Any sourcehut project can merge branches that exist in different places on the Internet.
The feedback and reviewing process might be more cumbersome, but accepting code contributions is not impeded in any way.
Indeed. A pull request is indeed a ... request to pull changes! One fetch/apply later you can use your local merge tools to evaluate.
I guess the various hubs, labs and buckets make it slightly harder to run malicious code on your own box, but the difference might be smaller than one would think.
Well, no, that's putting the cart before the horse.
Git was not designed for remote fetching from every menial contributor. Nothing was—it didn't make sense to.* The idea with git-pull is that it's for use among a set of frequent collaborators—so for a given repo you have a handful of remotes, if any. It was not intended that everyone would need "infrastructure to let others pull directly from their repositories". That didn't arise until GitHub decided to eschew with the traditional currency of open source (i.e. patches) and use branch merges for everything. By doing so they created the demand that is responsible for the current popularity of centralized hosts—which they just so happen to be. It's one big dark pattern, not very different from the way Facebook nursed the growth of their userbase by erecting barriers around their walled garden.
* And still really doesn't. Encapsulating everything with a new branch that lives on a public fork + a proposed merge isn't terribly efficient, being the wrong tool for the job and all... People convince themselves, though, to overlook the time/effort costs of that arrangement because it's what they're used to.
It is truly weird to me that the standard workflow for submitting a change to someone's project is now to make a copy of their project, change it, and then ask them to import your change. This is inside-out and upside-down!
Surely it would be a million times more intuitive for forges to offer a "submit a patch to this project" feature?
What are you talking about? git request-pull came far before GitHub existed, and that sends an email for a request & instructions to pull from a remote branch.
I think that at least for this specific use case the would be PostmarketOS contributors have access to Gitlab.
Of course I can't speak for the devs of PostmarketOS, but on my own projects hosted on Sourcehut, that's how I ask for alternative contributions coming from people uncomfortable with sending patches using email.
Have people used SCM Manager [1]? I recently found it on the Mercurial self-hosting page [2], and while it seems pretty good based on using it for a few weeks (at least for a single person use-case), the fact that I never hear of it (as much as Gogs or Gitea) makes me think that it may have some non-obvious issues with it.
We've been using for nearly 10 years in my company, hosting 100+ repositories in it. This is one of the few forges that allow hosting Git, Mercurial, and even SVN repositories within the same web interface. We had a lot of Mercurial repos in the past, but the domination of git for web development made us switch to git. Having all our repos under one software and authentication system is quite nice.
As the administrator I also really appreciate that there is an APT package available, so it is updated with the rest of the OS via unattended-upgrades. They also provide Docker and k8s installations. Except for the v1 to v2 migration 3 or 4 years ago that was a bit chaotic at first, it has been a very solid software.
This is "just" a repository hosting software though. It will not force you to use a specific git flow, there is no PR/MR interface. There are some plugins to enable some workflows, but nothing specific. While not numerous, there are several integrations available, like JIRA or Redmine, even LDAP for authentication.
There are no CI/CD part either. There is a Jenkins plugin though. Or you can also configure webhooks to be called on push events and design your own CI around it.
I'm surprised I never really hear people talk about GNU's Savannah. I've never hosted a project there, but it seems like a good fit for a GPL'd project
Does Postmarket meet the requirements? I could be wrong, but I thought Postmarket used non free firmware?
>Projects running on Replicant may be hosted on Savannah. Projects having dependencies on nonfree software, such as proprietary software drivers or AndroidOS, are not permissible.
Started host my own git server; wanted gitlab, but was too heavy for dinky server (and didn't want to upgrade), so found Gitea, which meets my needs. Don't know if it would meet their needs. Anyone use Gitea with complex deployment scenarios?
I just can't get past how bad SourceHut's UI is. They really need to hire someone that knows some basic UI principles.
Edit: As a commenter suggested, I will elaborate a little:
I'm a big fan of minimalist and lightweight UIs, that's not my issue with SourceHut's design. My issue is the disregard for several established UI principles (balance, proportion, repetition, etc.). Some examples:
- The login[0] and register[1] pages have completely inconsistent layouts (left aligned vs centered aligned, one has a header and the other not, etc.).
- The margin between the top navigation and page content is inconsistent from page to page.
- Inconsistent styling of links. Some links have an underline that disappears on mouseover, while for some other links, it's the opposite[2].
- Inconsistent use of margin/padding all over the place.
I love minimalistic javascript-free UIs and that sourcehut is fast (and under AGPL).
Yet I find the layout in Sourcehut really confusing and not self-explanatory.
Not having a bugtracker UI and having to jump around different FQDNs related to the same project is a usability killer for me.
I don't expect forges to copy github. E.g. trac is very different but still has a rational and friendly layout.
EDIT: I also like that codeberg.org is non-profit and community-driven. If the sourcehut UI was to become usable I wish codeberg would run an instance of sourcehut.
Yeah, the disconnect between sourcehut components isn't great, but AFAIK they are working on hub.sr.ht or smth like that, and also better integration between all of those services, precisely to fix that issue.
I'm eager to see that implemented, because it will be a good step forward.
I don't even mind the separate component approach but I wish they would just have a single consistent navigation bar on all of them for switching between all the services for a project.
Yeah, I too quite like the approach, but at the moment the components are too dissociated with each other, so something like what you suggested would come along way to making the platform more welcoming and useful.
While I get how the first line of your comment could come across dismissive in isolation (and I guess that was the entire comment before the Edit - so I understand the downvotes in that context), there's a common reply in sibling comments here that bothers me much much more:
> "bloated Javascript"
> "pointless javascript"
> "javascript-free UIs"
I don't know how much people have worked in UI and with front-end code (HTML/CSS/JS) but... the commenter criticised the UI. Javascript is not a UI language. Being a front-end language it's used a lot in close conjunction with UI components to control interactivity and data flow, but it has no responsibility for their appearance. In terms of aesthetic visual design, the amount of Javascript you have behind it isn't really relevant.
I do see a lot of people mentioning performance (which is a great feature of Sourcehut's), but is also a separate topic.
(fwiw I also love Javascriptless interfaces, not arguing that)
The kind of whizzbangs associated with "beautiful UI" often involves copious amounts of JavaScript hijacking scroll events, running code for every pixel of a mouse move, and so on. Something as simple as "header in the middle of the page" can involve an absolutely-positioned header moved around on scroll events.
That's why people were mentioning JS. If you've worked on frontend UI then you can't tell me you don't know what I'm talking about.
(And yes, I know it can be done with just CSS instead of moving an absolutely-positioned header with JS in scroll events. Tell that to the websites that do it, not to me.)
I know what you're talking about but I've also never seen anyone (neither on HN nor anywhere outside a caricature design agency boardroom) criticise the lack of whizzbangs.
Noone was talking about whizzbangs here, least of all the gp.
Personally I really, really like Sourcehut's UI/UX -- far easier to navigate for a casual user than those other Big Name alternatives. As well, I like the minimalism of the UI.
It's not bad at all, unfamiliar perhaps, because all the others have copied github.
It's like that so that page sizes are as a small as possible, to cater for all users on all platforms in all locations. Not everyone is American or European with a gigabit connection. No pointless theming, no pointless javascript, no trackers and so on.
strong agree, though with the caveat that it's "bad" for my tastes and priorities, but is clearly ok for other folks.
it feels all too common for folks to rage against bloaty interfaces (i agree, they're terrible!) but swing wildly back towards clunky browser-default randomness. you can have a consistent, polished interface without javascript and tons of images!
one thing w/ sourcehut that i find adds confusion is their choice to make their various services (source vs tickets vs mailing lists) completely separate apps. start on this page:
when you click on the "source" tab what do you expect will happen? i expect i'll go to a page with a source tree, listing files and directories. i also expect that i'll now be on the "source" tab at the new page, and will have the option to click back to the "summary" tab or any of the others that i currently see.
instead, you're taken to basically the same exact summary page (displaying README content) but with some git commit info on top. the highlighted tab is now... SUMMARY, AGAIN and there's a completely different tab set available to you. there is no way to click anywhere to get back to the previous version of the summary page and explore that tab group further.
i'm sure this makes sense to some folks (and they'll explain why i'm wrong below), but to me it feels like a cohesive user experience is not being prioritized here, and that's something i value ¯\_(ツ)_/¯
This is the one thing I, too, struggle with with sr.ht. I keep on using it, but I can't wrap my head around why this is supposed to be a good way to do it.
The link parent posted is not of the repository but of the project. Sourcehut doesn't use the 1 to 1 relationship between projects and repositories, wiki, and issue tracker that the other source forges employ.
A sourcehut project can have as many as them as there are required. Therefore the Source tab takes you to the main git/HG repo that you have added for your project.
That's also the reason why the descriptions are different, one is of the project, the other is of the repository.
It's only confusing if you dismiss everything that's not a clone of github without investing the little time it takes to learn about the differences.
Agreed, the styling has put me off by feeling broken / unfinished. In particular too little and too inconsistent padding.
However reviewing now I’ll say that for whatever reason it seems things are much improved. Still not my personal favorite but significantly more clear.
Contributing patches for these issues would allow you to have free (as in beer) access to sourcehut. I know it's a trite message, but it's open source, you can make it better instead of histrionically "not getting past how bad it is".
I very much like Sourcehut's UI as a whole (i.e. their design philosophy or whatever), but yeah it is very inconsistent. Hopefully, as it matures, the UI will gain more consistency.
>The login[0] and register[1] pages have completely inconsistent layouts (left aligned vs centered aligned, one has a header and the other not, etc.).
The register link is actually: https://meta.sr.ht/register. You pointed to meta homepage. When you proceed to enter your info (username/password) you'll see the layouts are consistent.
The "Register" link in the top navigation links to https://meta.sr.ht/, while the "Register" link inside the login page links to https://meta.sr.ht/register (another inconsistency I guess).
Agree with a lot of your comment but from its early days I think the UI consistency has come on leaps and bounds.
e.g.:
The current homepage has an odd out-of-place looking blue banner. This is largely down to uneven margins and paddings applied to the banner content - in particular vertical paddings aren't optically aligned with horizontal.
This same issue was once common through sourcehut's content but it's already clear how much that's improved looking at how much better the primary homepage content looks in contrast to the banner.
There's little tiny niggling issues like that everywhere - often related to vertical alignment not matching horizontal alignment - and while each is individually negligible, the cumulative affect is a bit jarring. But I still see it improving all the time.
Or maybe it's just a matter of taste? Personally I find many popular proprietary applications (including web "applications") as comfortable and enjoyable to use as walking on two hands backwards while blindfolded. Yet most people around me seem quite satisfied.
Because it's inconvenient. I went down the sourcehut road. Realized people don't need that stuff to develop, and it's way more annoying to work with when you just want to get something done and you don't _care_ about the "truly decentralized" parts.
To be clear, I adore sourcehut and it felt like a good way to develop. Certainly felt more like a hacker doing it. But I had the exact concerns as the author. I needed contributors, or the potential for that.
Because many people are afraid of what is not familiar, that's it.
It's not hostility, but a rather a case of shying away from reading the docs and changing the way they work.
From my experience not everyone is conductive to try and adapt to new ways, and many people do not use git CLI or SSH. They just use GitHub's gh CLI command.
This needlessly dismisses people who have tried both and still prefer not to use the one with more hassle.
Believe it or not, there are people out there who don't care about decentralization and latency-tolerant store-forward networking for their own sake. Getting things done is way more important to them and the user experience of git send-email is simply not as good as the centralized version.
People can have preferences, I deeply respect that.
On the other hand, I put my code out there (anywhere), and people are free to decide whether they contribute to it or not.
This is the platform I use, and this what the platform provides. If they want to contribute, and don't prefer the mail flow, they can reach me, and we can discuss it.
This is a two way street. Nobody is forced to contribute to anything, and I have no obligation to use services which people prefer. No?
It's not black or white, I love CLI and I use git CLI and SSH, I use tmux, vim etc, but to diff two branches or perform a code review I prefer my IDE (IntelliJ Idea) or a Pull/Merge Request on GitHub, Gitlab or similar
Of course. I'm in the same boat with you, but in the younger generation I generally see a trend.
GitHub creates this intellectual soft-jail, making developers think that the only way to work with git is gh or GitHub itself. If Kernel can cooperate with e-mail, everybody can.
OTOH, Source Hut is considering a PR-Like subsystem IIRC, and they use mail-based collaboration primarily, because it allows cooperation without opening an account with Source Hut.
This is an important feature, and line of thought, if you ask me.
I agree, I see many impedances (sorry) in command line usage. I think the percentage of people who can use one declines every year, there's simply no competing with the advertising budgets of flashier systems.
- UX is important to the average software developer
- UX within popular email clients targeting the task of code review is non-existent
- UX within IDEs for code review is better but: (a) send-email integrations are less polished/mature than they could be (largely due to the dominance of PR/MR flows) and (b) IDE code-review UX is still, despite everything, lagging Web UI code review UX
TL;DR: open distributed specs are what we need ideally, but you can't escape the fact that they'll always need much more work to overcome feature inconsistency and niche uses
---
I'm really rooting for sourcehut in this battle as I think if it got some adoption we could start seeing improvements to the above problems (they're all surmountable), but I think the biggest thing that's going to help that adoption is sourcehut adding a (good) web UI for their flow, per https://todo.sr.ht/~sircmpwn/lists.sr.ht/111
> Why are so many of your great contributors so hostile to the only part of the Internet that is still truly decentralized?
> Why do they hate store-and-forward, latency-tolerant networks?
I do like email-based development. And I pay for Sourcehut. But I also understand why others don't like email-based interfaces. And I too sometimes get annoyed by Debian's BTS taking minutes to act on (email-based) changes to bug reports. Minutes where I'm just idly sitting around waiting so as not to have to context switch. I abhor GH and friends, but oh man sometimes an instantaneous interface is important.
> but oh man sometimes an instantaneous interface is important.
That can indeed be a flow breaker, however, in my experience, it's not necessarily an email issue, but Debian's in this case, since sending stuff to lists.sr.ht is pretty snappy (like a couple of seconds after the client sends it). It isn't as fast and instantaneous as your typical web UI yet it's not a flow breaker either, imo, though YMMV.
But that's the point: the original poster pointed out the great value in store-and-forward, latency-tolerant systems like email. So while you may indeed be lucky and have low-latency interactions through email in certain situations, you've then added extra assumptions and requirements to the aforementioned latency-tolerant robust system. Wanting fast ("instant") response times from a system based on email seems like a folly.
I too am not really happy with GitLab.com. It requires contributors to fill a reCAPTCHA and I'm not a fan of it being open core. I chose Gitorious (and was moved to GitLab.com when it disappears) precisely because I don't want to endorse proprietary software, nor tracking. I don't want to run proprietary code - from Google! - and, above all, make people run Google's proprietary code and tracking. That's just not coherent. GitLab is considering moving to hCaptcha if I remember correctly but that's still proprietary and still a third party.
So I made the jump two weeks ago. I now self host my code. I pay for the resources I use so no more strange free lunch. I personally find SourceHut a bit bare but that might just be habits. I picked Gitea instead. People can log in with their GitHub or GitLab account if they wish so the argument that it prevents contributions because you have to create yet another account does not hold. Gitea is quite fast and works well without JS at least for consulting the code. It's quite easy to set up - I have already been self-hosting a number of services for years know. It's also very straightforward easy to use - much more than GitLab so far. I don't force anybody to run proprietary software to use or contribute to my projects.
For people who don't want to self host but would like an alternative to GitLab, Codeberg [1] is worth checking out, in addition to Source Hut. It uses Gitea. It's been mentioned in one of the latest blog posts from Drew Devault (the creator of SourceHut) by the way. It's hosted in Germany, too, if it matters. I guess it would be good to support them.
[1] https://codeberg.org/