9 ms·

Considering Sourcehut

177 points by Dunedan 4y ago

octoberfranklin 4y ago
- junon 4y ago
  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.
- bayindirh 4y ago
  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.
  - anotherhue 4y ago
    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.
  - drKarl 4y ago
    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
    - bayindirh 4y ago
      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.
  - WJW 4y ago
    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.
    - bayindirh 4y ago
      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?
- lucideer 4y ago
  Because: - 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 https://todo.sr.ht/~sircmpwn/lists.sr.ht/111
  - girvo 4y ago
    > (b) IDE code-review UX is still, despite everything, lagging Web UI code review UX This can't be overstated. Visual Studio Code seems to be making moves in this direction at least, but then again it's GitHub specific I believe?
- Arnavion 4y ago
  Right, calling contributors "hostile" and putting "hate" in their mouths is sure to win them over to your cause...
- deleted 4y ago
  [deleted]
- gspr 4y ago
  > 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.
  - Tmpod 4y ago
    > 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.
    - gspr 4y ago
      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.
jraph 4y ago
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. [1] https://codeberg.org/ https://codeberg.org/
- KronisLV 4y ago
  > 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-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). I actually did a writeup about the switch in more detail "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... 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).
Winsaucerer 4y ago
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. Overall quite happy with sourcehut for my needs.
- mariusor 4y ago
  > The git-by-email setup is more inconvenient. 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.
  - vnorilo 4y ago
    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.
    - _ikke_ 4y ago
      The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.
      - mariusor 4y ago
        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.
ddevault 4y ago
I use postmarketOS myself as my daily driver on my PinePhone, and I'm honored to have them consider SourceHut for their needs. Welcome!
Wronnay 4y ago
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.
- ddevault 4y ago
  This comes with some caveats: - 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.
- forgotpwd16 4y ago
  >they are searching for a free service 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.
  - O__________O 4y ago
    Both, article mentions: (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; ...”
  - seanw444 4y ago
    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.
olalonde 4y ago
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. Etc. [0] https://meta.sr.ht/login https://meta.sr.ht/login [1] https://meta.sr.ht/ https://meta.sr.ht/ [2] https://sr.ht/~martijnbraam/photoflow/ https://sr.ht/~martijnbraam/photoflow/ see "View project feed" vs "public-inbox" links at the top.
- DrBazza 4y ago
  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.
- mikro2nd 4y ago
  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.
- lpcvoid 4y ago
  Do you miss the millions of bytes of bloated Javascript mess that "modern" websites are littered with? SourceHut's UI is absolutely amazing.
  - deleted 4y ago
    [deleted]
- 4y ago
HexDecOctBin 4y ago
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. [1]: https://scm-manager.org/ https://scm-manager.org/ [2]: https://www.mercurial-scm.org/wiki/MercurialHosting https://www.mercurial-scm.org/wiki/MercurialHosting
- bchanudet 4y ago
  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.
jonnycomputer 4y ago
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?
zxwrt 4y ago
sr.ht lack ipv6 support to be viable option. I'd suggest considering codeberg or notabug instead.
- deleted 4y ago
  [deleted]
jszymborski 4y ago
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 https://savannah.nongnu.org/ https://savannah.nongnu.org/
- _-david-_ 4y ago
  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.
  - jszymborski 4y ago
    Ah, yes, that would likely not fit.
- xigoi 4y ago
  I've heard about Savannah, but didn't know it had a version for non-GNU projects.

177 points by Dunedan 4y ago

junon 4y ago
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.
bayindirh 4y ago
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.
- anotherhue 4y ago
  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.
- drKarl 4y ago
  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
  - bayindirh 4y ago
    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.
- WJW 4y ago
  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.
  - bayindirh 4y ago
    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?
lucideer 4y ago
Because: - 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 https://todo.sr.ht/~sircmpwn/lists.sr.ht/111
- girvo 4y ago
  > (b) IDE code-review UX is still, despite everything, lagging Web UI code review UX This can't be overstated. Visual Studio Code seems to be making moves in this direction at least, but then again it's GitHub specific I believe?
Arnavion 4y ago
Right, calling contributors "hostile" and putting "hate" in their mouths is sure to win them over to your cause...
deleted 4y ago
[deleted]
gspr 4y ago
> 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.
- Tmpod 4y ago
  > 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.
  - gspr 4y ago
    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.

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. [1] https://codeberg.org/ https://codeberg.org/

KronisLV 4y ago
> 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-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). I actually did a writeup about the switch in more detail "Goodbye GitLab; Hello Gitea, Nexus and Drone": https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-nexus-and-drone https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... 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).

Winsaucerer 4y ago

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. Overall quite happy with sourcehut for my needs.

mariusor 4y ago
> The git-by-email setup is more inconvenient. 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.
- vnorilo 4y ago
  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.
  - _ikke_ 4y ago
    The issue is most users do not have the infrastructure to let others pull directly from their repositories, hence centralized hosts became popular.
    - mariusor 4y ago
      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.

ddevault 4y ago

I use postmarketOS myself as my daily driver on my PinePhone, and I'm honored to have them consider SourceHut for their needs. Welcome!

Wronnay 4y ago

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.

ddevault 4y ago
This comes with some caveats: - 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.
forgotpwd16 4y ago
>they are searching for a free service 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.
- O__________O 4y ago
  Both, article mentions: (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; ...”
- seanw444 4y ago
  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.

olalonde 4y ago

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. Etc. [0] https://meta.sr.ht/login https://meta.sr.ht/login [1] https://meta.sr.ht/ https://meta.sr.ht/ [2] https://sr.ht/~martijnbraam/photoflow/ https://sr.ht/~martijnbraam/photoflow/ see "View project feed" vs "public-inbox" links at the top.

DrBazza 4y ago
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.
mikro2nd 4y ago
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.
lpcvoid 4y ago
Do you miss the millions of bytes of bloated Javascript mess that "modern" websites are littered with? SourceHut's UI is absolutely amazing.
- deleted 4y ago
  [deleted]
4y ago

HexDecOctBin 4y ago

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. [1]: https://scm-manager.org/ https://scm-manager.org/ [2]: https://www.mercurial-scm.org/wiki/MercurialHosting https://www.mercurial-scm.org/wiki/MercurialHosting

bchanudet 4y ago
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.

jonnycomputer 4y ago

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?

zxwrt 4y ago

sr.ht lack ipv6 support to be viable option. I'd suggest considering codeberg or notabug instead.

deleted 4y ago
[deleted]

jszymborski 4y ago

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 https://savannah.nongnu.org/ https://savannah.nongnu.org/

_-david-_ 4y ago
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.
- jszymborski 4y ago
  Ah, yes, that would likely not fit.
xigoi 4y ago
I've heard about Savannah, but didn't know it had a version for non-GNU projects.