13 ms·

Sourcehut's Second Year in Alpha

318 points by pcr910303 6y ago

__henil 6y ago
> Welcome to sourcehut! This suite of open source tools is the software development platform you've been waiting for. > Git and Mercurial hosting, mailing lists, bug tracking, continuous integration, and more > Absolutely no tracking or advertising > All features work without JavaScript > 100% free and open source software For someone who is not familiar with sourcehut what other benefits does it provide over gitlab? (Don't get me wrong i absolutely like that every feature works without javascript, i am just curious)
- mahkoh 6y ago
  I've been using sr.ht to run unit tests on OpenBSD. Performance has been excellent and prices are low (from $2/month.)
- rainingcatndogs 6y ago
  I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.
  - brianzelip 6y ago
    Here's a video on the email workflow by Sourcehut's author, https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
    - dnr 6y ago
      Wow, that video feels pretty disingenuous. - The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them. (I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.) - He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison. - The graylisting thing is an own-goal, sorry. - He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that. - Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision. Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list. Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions. You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand. Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.? - What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
      - tristan957 6y ago
        When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe. You can assign a review to someone. You literally just CC them on the email. > And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows. If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
        dnr 6y ago
        > When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013. > You can mark emails with labels though depending on your Email client. The onus is on you. But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion. > You can assign a review to someone. You literally just CC them on the email. Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions. > If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it. Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction. I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all). An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.
- eatonphil 6y ago
  I haven't used Sourcehut, but almost no other CI service I know of provides FreeBSD or OpenBSD runners.
- arch-ninja 6y ago
  I count simplicity as a feature. Not knocking GitLab, from a business perspective they provide the same capability.
- mfsch 6y ago
  I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.
  - __henil 6y ago
    I have known that development of linux, git was done over email, And always wondered how PR worked there, but I never took time to know how actually it was done. For someone like me this[0] looks like a good start. [0]: https://git-send-email.io/ https://git-send-email.io/
- shakna 6y ago
  Everything is modular and "vendorless". To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD. If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues. And I can self-host each of these "modules" myself, with full documentation on how to do that.
- njkleiner 6y ago
  I imagine the builtin email support might be the single biggest selling point, if you're into that kind of workflow... Also, the simplicity is certainly appreciated.
- slmjkdbtl 6y ago
  Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.
  - alexwennerberg 6y ago
    > no javascript To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.
    - gray_-_wolf 6y ago
      > and optional. This is imho the most important part.
  - deleted 6y ago
    [deleted]
- hprotagonist 6y ago
  ideological purity.
- busterarm 6y ago
  It's actually open source (instead of the source available/open core nonsense). Whether that matters to you or your business is a different story.
  - SulfurHexaFluri 6y ago
    The open source section of Gitlab is very powerful and perfectly usable on its own.
    - busterarm 6y ago
      The problem with open-core licenses is that you always have to weigh the risk of whether the feature you depend on will get pulled into the paid license, pegging you on a release forever without updates. If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows). Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.
- wpietri 6y ago
  There's a nice feature list on their home page: https://sourcehut.org/ https://sourcehut.org/ The one that made me go "oooh!" is this: Powerful continuous integration - Runs fully virtualised builds on various Linux distros and BSDs - Submit ad-hoc jobs without pushing to your repository - Post-build triggers for email, webhooks, etc - Log in with SSH after build failures to investigate further Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.
  - sytse 6y ago
    The parent asked which features of sourcehut are not in GitLab. I think manual triggers are in GitLab https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/13797 https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/1... and I assume post build triggers are. Logging in via SSH seems useful although that would mean keeping the machine running after a failed build.
    - eatonphil 6y ago
      Somewhat related to this thread: a frustration I have with most CI systems is how hard it can be to reproduce the run locally using (ideally all of the) same configuration. For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files. Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today. It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
      - Macha 6y ago
        The trick is to do as much as possible outside the CI system. Ideally, each step should just call a single script, Makefile command, or your language's build tool equivalent.
- nathcd 6y ago
  To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.
  - judge2020 6y ago
    Sounds like a good way to accidentally create a repo, hopefully it’s private by default.
    - ddevault 6y ago
      It gives you a link to click to confirm the new repository creation, or you can use git push options to set the visibility and description (git push -o visibility=public -o description="my cool repo")
    - alisonkisk 6y ago
      One of many ways that amateur open system are vulnerable to fraud and abuse once they lose their security-via-obscurity
      - MaxBarraclough 6y ago
        1. Please don't do this. HackerNews is not the place to hurl empty insults. 2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here. 3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.
- musicmatze 6y ago
  The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall. Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
  - throwaway894345 6y ago
    Can you elaborate on how sourcehut or other git workflows scale better?
    - ddevault 6y ago
      You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...
  - Znafon 6y ago
    It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
  - ChickeNES 6y ago
    > The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.
sirodoht 6y ago
I’ve been using SourceHut for many months and it feels like it’s now time to completely switch away from GitHub.
wirrbel 6y ago
I just like the fact that there is mercurial support
colonwqbang 6y ago
I really like the page design, very clear and non-flashy. Looks like time was well spent delivering features and good performance instead of building a "beautiful" page.
- andrepd 6y ago
  Do you really need anything else? To me the design is a feature itself. I don't need to load 1MB of stuff and run a heavy scripting language to display... text (of course that 1MB comes with complementary popups, banners, weird scrolling, autoplying videos, and stuff jumping around for 10s until the page loads entirely).
  - Shared404 6y ago
    > To me the design is a feature itself. Same here. The fact that it's so lightweight + being FL/OSS is what pulled me from Github.
  - palindrom615 6y ago
    well... yes, no javascript of sr.ht is great. just to be fair, there's no 1MB script in github or gitlab... just few kb.
- systemvoltage 6y ago
  We need to get out of this rut of UX/UI design. UX/UI designers’ existence itself is based on generalized condemnation of a group of people: “Engineers are bad at designing and aesthetics.” Every time that’s brought up, I roll my eyes. The truth is there are some outstanding UX/UI designers and there are some really bad engineers who design terrible unfriendly shit. The reverse is more common from what I’ve seen.
  - smt88 6y ago
    So you take issue with condemnation of an entire group and then do it yourself immediately afterward? Saying engineers are bad at design is fine. Most people are bad at things they don't practice, and we know most engineers don't practice design. Saying UX/UI designers (two separate groups with totally different backgrounds) are bad at design is maligning an entire field and suggesting a team hierarchy where engineers make all decisions.
sam0x17 6y ago
Been using sourcehut little over a year now. I'm a fan Looks real good in dark mode via the standard "dark reader" browser plugin most people use these days, btw. Would love to see them add a native dark mode though. That's my main gripe.
- ddevault 6y ago
  The official response to this ask was "convince the browsers to ship prefers-color-scheme dark", and now that they have, the official answer is "patches welcome". I would definitely be down to add a dark theme if someone put in the work.
  - sam0x17 6y ago
    I mean for a site like sourcehut the "work" could literally be an invert filter or taking the styles that dark reader generates for sourcehut.
xvilka 6y ago
I wish more of the SourceHut stack was written in Go, like Gitea. It would greatly increase performance and simplify deployment. Long-waited NetBSD support in CI[1] would be awesome to be finished too. [1] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/netbsd https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...
- ddevault 6y ago
  More and more of it is being rewritten in Go as part of the API 2.0 project. In any case, SourceHut is already the fastest software forge by objective measures: https://forgeperf.org https://forgeperf.org
  - xvilka 6y ago
    Always good to know. Thank you for it, I am a happy user myself!
  - coder543 6y ago
    The fastest... of the ones measured. The comment you’re responding to specifically calls out Gitea, which isn’t measured in forge perf. (Most likely because there isn’t a major, permanent, public instance of Gitea... it seems to currently be targeted at self hosted instances, and then its speed is obviously dependent on the hardware it’s hosted on.) Gitea and SourceHut can both be very fast, from what I’ve seen, but I haven’t seen any objective comparison numbers.
    - ddevault 6y ago
      Codeberg, which is tested here, is hosted on Gitea. A separate comparison would be needed to test the performance of self-hosted options. This comparison is meant to test hosted options, and in order to be fair, that has to also account for their hardware configuration, network situation, and so on, so simply adding a vaguely defined "Gitea" measure here would not be fair.
      - coder543 6y ago
alisonkisk 6y ago
It's unfortunate that sourcehut is hosted on sr.ht instead of the much more natural src.ht
- sirodoht 6y ago
  The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD.
  - shakna 6y ago
    > The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD. The country of Haiti? Réseau de Développement Durable d'Haïti is an autonomous non-profit that acts much like a government department. They're actually also in charge of Haiti's internet backbone, so are less likely to be inclined to come up with arbitrary rules or suddenly change what is acceptable for the ccTLD. They have bigger concerns.
- erk__ 6y ago
  Is it not because this specific instance of sourcehut[0] is called sir hat. Or is that something I have made up in my mind. [0]: https://sourcehut.org/ https://sourcehut.org/
  - SahAssar 6y ago
    See here: https://news.ycombinator.com/item?id=18930509 https://news.ycombinator.com/item?id=18930509
- mikepurvis 6y ago
  IIRC, the domain predates the "sourcehut" name; for the first little while, the author referred to it as sir-hat: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...
deleted 6y ago
[deleted]
setheron 6y ago
I'm not familiar with gemini or gopher. Anyone want to offer a summary ?
- fuball63 6y ago
  Both are alternative protocols to HTTP. Gopher is an older technology that uses a menu based organization of information. Gemini is newer and seeks to provide an alternative internet with a simpler client implementation. https://gemini.circumlunar.space/docs/faq.html https://gemini.circumlunar.space/docs/faq.html https://en.wikipedia.org/wiki/Gopher_%28protocol%29 https://en.wikipedia.org/wiki/Gopher_%28protocol%29
  - MaxBarraclough 6y ago
    Makes me wonder about the future of Gemini and SourceHut. > gemini:// and gopher:// URLs are now permitted for profile URLs Is that as far as SourceHut's Gemini support goes for now? Could we expect more in future?
    - ddevault 6y ago
      Can't say what it will look like from this distance, but you can expect more Gemini+SourceHut stuff in the future.
tyfytyf 6y ago
https://mobile.twitter.com/stevelosh/status/1215814068549742593 https://mobile.twitter.com/stevelosh/status/1215814068549742...
- ddevault 6y ago
  At the time, Steve agreed to share the email transcript from this incident: https://paste.sr.ht/~sircmpwn/5f6ae83ffc961215cb82f1a98f78a020e9309484 https://paste.sr.ht/~sircmpwn/5f6ae83ffc961215cb82f1a98f78a0... Judge for yourself if we were out of line. Steve's repository was basically an archive of his Instagram account, hundreds of high-resolution images. This is not what SourceHut is designed for. Mercurial repositories in particular have an outsized impact, because we generate nightly clonebundles from larger repos, and because images are uncompressible this results in a disproportionately large amount of wasted CPU time and disk space. We updated our approach, in any case, to use the following email template instead: https://paste.sr.ht/~sircmpwn/3d32eb7bbc564170c3d30f041e5e8dc71aa5a1c6 https://paste.sr.ht/~sircmpwn/3d32eb7bbc564170c3d30f041e5e8d... And we expanded on acceptable use in the documentation: https://man.sr.ht/hg.sr.ht/#acceptable-resource-usage https://man.sr.ht/hg.sr.ht/#acceptable-resource-usage
  - hitekker 6y ago
    Yikes. The first few emails were mostly professional and the entire encounter could have been resolved by line 63. But you kept emailing him. It's like you were offended by his dissatisfaction and wanted to "disprove" his feelings: > Hg was not designed to store large blobs, and it puts an unreasonable strain on our servers that most users don't burden us with That unnecessary follow-up made him want to move all of his other repos off platform. So, you lashed out: > As someone who contributed to Mercurial as recently as 2011, I'm sure you're aware of this... This email thread started out as a heads up and ended with you losing a customer, for no good reason.
    - ddevault 6y ago
      At the time this thread first came up, I agreed that my sarcastic response to his Mercurial contributorship comment was out of line, and apologised for that. Others who have read this thread came away with a different impression than you did. I tried to explain why it was a problem, rather than just leaving them put out. Personally, I prefer this approach over the cold, unfeeling notification from a robot that noticed your repo was oversized. Human admins is a feature of sourcehut, and human failures of communication occasionally occur as a result. Anyway, the facts are laid out, and I'm not particularly enthusiastic about rehashing this discussion again, 10 months later, in an unrelated post celebrating our anniversary.
jniedrauer 6y ago
I recently contributed to a project hosted on sr.ht for the first time. It took some getting used to. I can see the potential, but there are some sharp edges. The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.
- ddevault 6y ago
  I generally recommend setting up a separate email client for development, and I recommend one I wrote myself for this purpose: https://aerc-mail.org https://aerc-mail.org. You don't have to stop using your primary mail client to incorporate a second one into your workflow. Just think of the patches as notification emails in your normal inbox, and then something like aerc as a domain-specific tool. Over time I bet you'll find yourself opening aerc more and thunderbird less, though ;) We're also working on web-based tools for this workflow, which allow you to create patchsets, respond to feedback, and review them entirely from the web, but these are still WIP. You can submit patchsets and view discussions on the web today, and the rest of the tools are WIP.
  - rwj 6y ago
    I will need to check out aerc. I've only submitted one patch, but there are enough differences from regular email to create quite a barrier.
CivBase 6y ago
I know Drew is very adamant about using mailing lists instead of pull requests. However, I like the public nature of pull requests and how they archive discussions. Is there anything that already exists out there to bring that functionality to the email workflow?
- ddevault 6y ago
  Yes, SourceHut mailing lists have public archives. Some examples from our official mailing lists: https://lists.sr.ht/~sircmpwn/sr.ht-dev https://lists.sr.ht/~sircmpwn/sr.ht-dev https://lists.sr.ht/~sircmpwn/sr.ht-discuss https://lists.sr.ht/~sircmpwn/sr.ht-discuss https://lists.sr.ht/~sircmpwn/sr.ht-announce https://lists.sr.ht/~sircmpwn/sr.ht-announce https://lists.sr.ht/~sircmpwn/sr.ht-ops https://lists.sr.ht/~sircmpwn/sr.ht-ops Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.
  - CivBase 6y ago
    That's perfect. Thanks!
- yjftsjthsd-h 6y ago
  Most mailing lists have archives; doesn't that do what you want?
- Rapzid 6y ago
  Mailing lists?! Yuck! - Most developers born after 1980
_ix 6y ago
I've looked at this with some curiosity over the past year, but it was only this morning that I decided to take a closer look. While I'm a huge fan of GitLab, I think this is really something special. I spent $50 to show some support and I'd like to find other ways I can contribute.
kodah 6y ago
Full transparency: I'm trying to build something similar at https://gopherworks.io https://gopherworks.io if anyone's interested in helping. I recently wrote an article for my own code hosting service where I talked a little about SourceHut and what makes it unique: - SourceHut follows a zero investor approach [1] - SourceHut's Principal Engineer, Drew Devault, prides himself in simple infrastructure [2] - Drew believes Mailing List Workflows are the way forward [3] - SourceHut is designed for accessibility first [4] [1] https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ [2] https://sourcehut.org/blog/2020-04-20-prioritizing-simplitity/ https://sourcehut.org/blog/2020-04-20-prioritizing-simplitit... [3] https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-censorship/ https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prev... [4] https://sourcehut.org/blog/2020-05-27-accessibility-through-simplicity/ https://sourcehut.org/blog/2020-05-27-accessibility-through-... SourceHut is an interesting concept and basically the equivalent of a built-at-home GitHub. It's based on Python (and now Go), runs on Alpine on baremetal in a datacenter in the US. Some of the above aren't just views for SourceHut though, they're more like a way of life. If you'd like to test that join the SourceHut channel on Freenode and ask if anyone has any reference for Dockerfiles or Kubernetes and see what response you get. SourceHut and other code hosting sites are popping up as a wave of programmers push for decentralization. Some may say that it's in response to youtube-dl, but this has been happening slowly for a while. If SourceHut isn't right for you there's always Codeberg which is essentially a Gitea instance backed by a non-profit in the EU.
JNRowe 6y ago
Any one have personal experiences on self hosting an instance that they wish to share? I keep meaning to look in to it a bit more, but always seem to end up nudging it down the list.
- ddevault 6y ago
  You might get some answers by posting on sr.ht-discuss: ~sircmpwn/sr.ht-discuss@lists.sr.ht Installation instructions are here: https://man.sr.ht/installation.md https://man.sr.ht/installation.md There's a patchset in my review queue which will organize, update, and streamline these instructions - might be worth checking back in a week.
  - JNRowe 6y ago
    Thanks Drew, and peterjsanchez too. BTW, I think the documentation already seems nice and approachable. From your send-email helper site right through to the sr.ht docs themselves. Much appreciated. [I was kind of asking for personal experiences - in part - because docs don't always match reality ;)]
- peterjsanchez 6y ago
  Yup. We migrated from BB to our own self hosted install nearly a year ago. Couldn't be happier with the change.
- ndagestad 6y ago
  I've been selfhosting it for a while now and the installation wasn't hard when I installed it, and the doc has gotten better since The hardest part was setting up a working mail server for the mailing lists (but that has nothing to do with sourcehut)

318 points by pcr910303 6y ago

> Welcome to sourcehut! This suite of open source tools is the software development platform you've been waiting for. > Git and Mercurial hosting, mailing lists, bug tracking, continuous integration, and more > Absolutely no tracking or advertising > All features work without JavaScript > 100% free and open source software For someone who is not familiar with sourcehut what other benefits does it provide over gitlab? (Don't get me wrong i absolutely like that every feature works without javascript, i am just curious)

mahkoh 6y ago
I've been using sr.ht to run unit tests on OpenBSD. Performance has been excellent and prices are low (from $2/month.)
rainingcatndogs 6y ago
I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.
- brianzelip 6y ago
  Here's a video on the email workflow by Sourcehut's author, https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
  - dnr 6y ago
    Wow, that video feels pretty disingenuous. - The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them. (I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.) - He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison. - The graylisting thing is an own-goal, sorry. - He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that. - Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision. Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list. Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions. You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand. Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.? - What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
    - tristan957 6y ago
      When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe. You can assign a review to someone. You literally just CC them on the email. > And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows. If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
      - dnr 6y ago
        > When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI. I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013. > You can mark emails with labels though depending on your Email client. The onus is on you. But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion. > You can assign a review to someone. You literally just CC them on the email. Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions. > If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it. Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction. I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all). An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.
eatonphil 6y ago
I haven't used Sourcehut, but almost no other CI service I know of provides FreeBSD or OpenBSD runners.
arch-ninja 6y ago
I count simplicity as a feature. Not knocking GitLab, from a business perspective they provide the same capability.
mfsch 6y ago
I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.
- __henil 6y ago
  I have known that development of linux, git was done over email, And always wondered how PR worked there, but I never took time to know how actually it was done. For someone like me this[0] looks like a good start. [0]: https://git-send-email.io/ https://git-send-email.io/
shakna 6y ago
Everything is modular and "vendorless". To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD. If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues. And I can self-host each of these "modules" myself, with full documentation on how to do that.
njkleiner 6y ago
I imagine the builtin email support might be the single biggest selling point, if you're into that kind of workflow... Also, the simplicity is certainly appreciated.
slmjkdbtl 6y ago
Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.
- alexwennerberg 6y ago
  > no javascript To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.
  - gray_-_wolf 6y ago
    > and optional. This is imho the most important part.
- deleted 6y ago
  [deleted]
hprotagonist 6y ago
ideological purity.
busterarm 6y ago
It's actually open source (instead of the source available/open core nonsense). Whether that matters to you or your business is a different story.
- SulfurHexaFluri 6y ago
  The open source section of Gitlab is very powerful and perfectly usable on its own.
  - busterarm 6y ago
    The problem with open-core licenses is that you always have to weigh the risk of whether the feature you depend on will get pulled into the paid license, pegging you on a release forever without updates. If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows). Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.
wpietri 6y ago
There's a nice feature list on their home page: https://sourcehut.org/ https://sourcehut.org/ The one that made me go "oooh!" is this: Powerful continuous integration - Runs fully virtualised builds on various Linux distros and BSDs - Submit ad-hoc jobs without pushing to your repository - Post-build triggers for email, webhooks, etc - Log in with SSH after build failures to investigate further Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.
- sytse 6y ago
  The parent asked which features of sourcehut are not in GitLab. I think manual triggers are in GitLab https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/13797 https://forum.gitlab.com/t/gitlab-ci-run-pipeline-manually/1... and I assume post build triggers are. Logging in via SSH seems useful although that would mean keeping the machine running after a failed build.
  - eatonphil 6y ago
    Somewhat related to this thread: a frustration I have with most CI systems is how hard it can be to reproduce the run locally using (ideally all of the) same configuration. For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files. Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today. It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
    - Macha 6y ago
      The trick is to do as much as possible outside the CI system. Ideally, each step should just call a single script, Makefile command, or your language's build tool equivalent.
nathcd 6y ago
To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.
- judge2020 6y ago
  Sounds like a good way to accidentally create a repo, hopefully it’s private by default.
  - ddevault 6y ago
    It gives you a link to click to confirm the new repository creation, or you can use git push options to set the visibility and description (git push -o visibility=public -o description="my cool repo")
  - alisonkisk 6y ago
    One of many ways that amateur open system are vulnerable to fraud and abuse once they lose their security-via-obscurity
    - MaxBarraclough 6y ago
      1. Please don't do this. HackerNews is not the place to hurl empty insults. 2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here. 3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.
musicmatze 6y ago
The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall. Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
- throwaway894345 6y ago
  Can you elaborate on how sourcehut or other git workflows scale better?
  - ddevault 6y ago
    You may find this helpful: https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html https://drewdevault.com/2020/09/02/Linux-development-is-prof...
- Znafon 6y ago
  It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list. Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed. There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
- ChickeNES 6y ago
  > The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.

sirodoht 6y ago

I’ve been using SourceHut for many months and it feels like it’s now time to completely switch away from GitHub.

wirrbel 6y ago

I just like the fact that there is mercurial support

colonwqbang 6y ago

I really like the page design, very clear and non-flashy. Looks like time was well spent delivering features and good performance instead of building a "beautiful" page.

andrepd 6y ago
Do you really need anything else? To me the design is a feature itself. I don't need to load 1MB of stuff and run a heavy scripting language to display... text (of course that 1MB comes with complementary popups, banners, weird scrolling, autoplying videos, and stuff jumping around for 10s until the page loads entirely).
- Shared404 6y ago
  > To me the design is a feature itself. Same here. The fact that it's so lightweight + being FL/OSS is what pulled me from Github.
- palindrom615 6y ago
  well... yes, no javascript of sr.ht is great. just to be fair, there's no 1MB script in github or gitlab... just few kb.
systemvoltage 6y ago
We need to get out of this rut of UX/UI design. UX/UI designers’ existence itself is based on generalized condemnation of a group of people: “Engineers are bad at designing and aesthetics.” Every time that’s brought up, I roll my eyes. The truth is there are some outstanding UX/UI designers and there are some really bad engineers who design terrible unfriendly shit. The reverse is more common from what I’ve seen.
- smt88 6y ago
  So you take issue with condemnation of an entire group and then do it yourself immediately afterward? Saying engineers are bad at design is fine. Most people are bad at things they don't practice, and we know most engineers don't practice design. Saying UX/UI designers (two separate groups with totally different backgrounds) are bad at design is maligning an entire field and suggesting a team hierarchy where engineers make all decisions.

sam0x17 6y ago

Been using sourcehut little over a year now. I'm a fan Looks real good in dark mode via the standard "dark reader" browser plugin most people use these days, btw. Would love to see them add a native dark mode though. That's my main gripe.

ddevault 6y ago
The official response to this ask was "convince the browsers to ship prefers-color-scheme dark", and now that they have, the official answer is "patches welcome". I would definitely be down to add a dark theme if someone put in the work.
- sam0x17 6y ago
  I mean for a site like sourcehut the "work" could literally be an invert filter or taking the styles that dark reader generates for sourcehut.

xvilka 6y ago

I wish more of the SourceHut stack was written in Go, like Gitea. It would greatly increase performance and simplify deployment. Long-waited NetBSD support in CI[1] would be awesome to be finished too. [1] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/netbsd https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...

ddevault 6y ago
More and more of it is being rewritten in Go as part of the API 2.0 project. In any case, SourceHut is already the fastest software forge by objective measures: https://forgeperf.org https://forgeperf.org
- xvilka 6y ago
  Always good to know. Thank you for it, I am a happy user myself!
- coder543 6y ago
  The fastest... of the ones measured. The comment you’re responding to specifically calls out Gitea, which isn’t measured in forge perf. (Most likely because there isn’t a major, permanent, public instance of Gitea... it seems to currently be targeted at self hosted instances, and then its speed is obviously dependent on the hardware it’s hosted on.) Gitea and SourceHut can both be very fast, from what I’ve seen, but I haven’t seen any objective comparison numbers.
  - ddevault 6y ago
    Codeberg, which is tested here, is hosted on Gitea. A separate comparison would be needed to test the performance of self-hosted options. This comparison is meant to test hosted options, and in order to be fair, that has to also account for their hardware configuration, network situation, and so on, so simply adding a vaguely defined "Gitea" measure here would not be fair.
    - coder543 6y ago

alisonkisk 6y ago

It's unfortunate that sourcehut is hosted on sr.ht instead of the much more natural src.ht

sirodoht 6y ago
The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD.
- shakna 6y ago
  > The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD. The country of Haiti? Réseau de Développement Durable d'Haïti is an autonomous non-profit that acts much like a government department. They're actually also in charge of Haiti's internet backbone, so are less likely to be inclined to come up with arbitrary rules or suddenly change what is acceptable for the ccTLD. They have bigger concerns.
erk__ 6y ago
Is it not because this specific instance of sourcehut[0] is called sir hat. Or is that something I have made up in my mind. [0]: https://sourcehut.org/ https://sourcehut.org/
- SahAssar 6y ago
  See here: https://news.ycombinator.com/item?id=18930509 https://news.ycombinator.com/item?id=18930509
mikepurvis 6y ago
IIRC, the domain predates the "sourcehut" name; for the first little while, the author referred to it as sir-hat: https://drewdevault.com/2018/11/15/sr.ht-general-availability.html https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...

deleted 6y ago

[deleted]

setheron 6y ago

I'm not familiar with gemini or gopher. Anyone want to offer a summary ?

fuball63 6y ago
Both are alternative protocols to HTTP. Gopher is an older technology that uses a menu based organization of information. Gemini is newer and seeks to provide an alternative internet with a simpler client implementation. https://gemini.circumlunar.space/docs/faq.html https://gemini.circumlunar.space/docs/faq.html https://en.wikipedia.org/wiki/Gopher_%28protocol%29 https://en.wikipedia.org/wiki/Gopher_%28protocol%29
- MaxBarraclough 6y ago
  Makes me wonder about the future of Gemini and SourceHut. > gemini:// and gopher:// URLs are now permitted for profile URLs Is that as far as SourceHut's Gemini support goes for now? Could we expect more in future?
  - ddevault 6y ago
    Can't say what it will look like from this distance, but you can expect more Gemini+SourceHut stuff in the future.

tyfytyf 6y ago

https://mobile.twitter.com/stevelosh/status/1215814068549742593 https://mobile.twitter.com/stevelosh/status/1215814068549742...

ddevault 6y ago
At the time, Steve agreed to share the email transcript from this incident: https://paste.sr.ht/~sircmpwn/5f6ae83ffc961215cb82f1a98f78a020e9309484 https://paste.sr.ht/~sircmpwn/5f6ae83ffc961215cb82f1a98f78a0... Judge for yourself if we were out of line. Steve's repository was basically an archive of his Instagram account, hundreds of high-resolution images. This is not what SourceHut is designed for. Mercurial repositories in particular have an outsized impact, because we generate nightly clonebundles from larger repos, and because images are uncompressible this results in a disproportionately large amount of wasted CPU time and disk space. We updated our approach, in any case, to use the following email template instead: https://paste.sr.ht/~sircmpwn/3d32eb7bbc564170c3d30f041e5e8dc71aa5a1c6 https://paste.sr.ht/~sircmpwn/3d32eb7bbc564170c3d30f041e5e8d... And we expanded on acceptable use in the documentation: https://man.sr.ht/hg.sr.ht/#acceptable-resource-usage https://man.sr.ht/hg.sr.ht/#acceptable-resource-usage
- hitekker 6y ago
  Yikes. The first few emails were mostly professional and the entire encounter could have been resolved by line 63. But you kept emailing him. It's like you were offended by his dissatisfaction and wanted to "disprove" his feelings: > Hg was not designed to store large blobs, and it puts an unreasonable strain on our servers that most users don't burden us with That unnecessary follow-up made him want to move all of his other repos off platform. So, you lashed out: > As someone who contributed to Mercurial as recently as 2011, I'm sure you're aware of this... This email thread started out as a heads up and ended with you losing a customer, for no good reason.
  - ddevault 6y ago
    At the time this thread first came up, I agreed that my sarcastic response to his Mercurial contributorship comment was out of line, and apologised for that. Others who have read this thread came away with a different impression than you did. I tried to explain why it was a problem, rather than just leaving them put out. Personally, I prefer this approach over the cold, unfeeling notification from a robot that noticed your repo was oversized. Human admins is a feature of sourcehut, and human failures of communication occasionally occur as a result. Anyway, the facts are laid out, and I'm not particularly enthusiastic about rehashing this discussion again, 10 months later, in an unrelated post celebrating our anniversary.

jniedrauer 6y ago

I recently contributed to a project hosted on sr.ht for the first time. It took some getting used to. I can see the potential, but there are some sharp edges. The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.

ddevault 6y ago
I generally recommend setting up a separate email client for development, and I recommend one I wrote myself for this purpose: https://aerc-mail.org https://aerc-mail.org. You don't have to stop using your primary mail client to incorporate a second one into your workflow. Just think of the patches as notification emails in your normal inbox, and then something like aerc as a domain-specific tool. Over time I bet you'll find yourself opening aerc more and thunderbird less, though ;) We're also working on web-based tools for this workflow, which allow you to create patchsets, respond to feedback, and review them entirely from the web, but these are still WIP. You can submit patchsets and view discussions on the web today, and the rest of the tools are WIP.
- rwj 6y ago
  I will need to check out aerc. I've only submitted one patch, but there are enough differences from regular email to create quite a barrier.

CivBase 6y ago

I know Drew is very adamant about using mailing lists instead of pull requests. However, I like the public nature of pull requests and how they archive discussions. Is there anything that already exists out there to bring that functionality to the email workflow?

ddevault 6y ago
Yes, SourceHut mailing lists have public archives. Some examples from our official mailing lists: https://lists.sr.ht/~sircmpwn/sr.ht-dev https://lists.sr.ht/~sircmpwn/sr.ht-dev https://lists.sr.ht/~sircmpwn/sr.ht-discuss https://lists.sr.ht/~sircmpwn/sr.ht-discuss https://lists.sr.ht/~sircmpwn/sr.ht-announce https://lists.sr.ht/~sircmpwn/sr.ht-announce https://lists.sr.ht/~sircmpwn/sr.ht-ops https://lists.sr.ht/~sircmpwn/sr.ht-ops Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.
- CivBase 6y ago
  That's perfect. Thanks!
yjftsjthsd-h 6y ago
Most mailing lists have archives; doesn't that do what you want?
Rapzid 6y ago
Mailing lists?! Yuck! - Most developers born after 1980

_ix 6y ago

I've looked at this with some curiosity over the past year, but it was only this morning that I decided to take a closer look. While I'm a huge fan of GitLab, I think this is really something special. I spent $50 to show some support and I'd like to find other ways I can contribute.

kodah 6y ago

Full transparency: I'm trying to build something similar at https://gopherworks.io https://gopherworks.io if anyone's interested in helping. I recently wrote an article for my own code hosting service where I talked a little about SourceHut and what makes it unique: - SourceHut follows a zero investor approach [1] - SourceHut's Principal Engineer, Drew Devault, prides himself in simple infrastructure [2] - Drew believes Mailing List Workflows are the way forward [3] - SourceHut is designed for accessibility first [4] [1] https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/ [2] https://sourcehut.org/blog/2020-04-20-prioritizing-simplitity/ https://sourcehut.org/blog/2020-04-20-prioritizing-simplitit... [3] https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-censorship/ https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prev... [4] https://sourcehut.org/blog/2020-05-27-accessibility-through-simplicity/ https://sourcehut.org/blog/2020-05-27-accessibility-through-... SourceHut is an interesting concept and basically the equivalent of a built-at-home GitHub. It's based on Python (and now Go), runs on Alpine on baremetal in a datacenter in the US. Some of the above aren't just views for SourceHut though, they're more like a way of life. If you'd like to test that join the SourceHut channel on Freenode and ask if anyone has any reference for Dockerfiles or Kubernetes and see what response you get. SourceHut and other code hosting sites are popping up as a wave of programmers push for decentralization. Some may say that it's in response to youtube-dl, but this has been happening slowly for a while. If SourceHut isn't right for you there's always Codeberg which is essentially a Gitea instance backed by a non-profit in the EU.

JNRowe 6y ago

Any one have personal experiences on self hosting an instance that they wish to share? I keep meaning to look in to it a bit more, but always seem to end up nudging it down the list.

ddevault 6y ago
You might get some answers by posting on sr.ht-discuss: ~sircmpwn/sr.ht-discuss@lists.sr.ht Installation instructions are here: https://man.sr.ht/installation.md https://man.sr.ht/installation.md There's a patchset in my review queue which will organize, update, and streamline these instructions - might be worth checking back in a week.
- JNRowe 6y ago
  Thanks Drew, and peterjsanchez too. BTW, I think the documentation already seems nice and approachable. From your send-email helper site right through to the sr.ht docs themselves. Much appreciated. [I was kind of asking for personal experiences - in part - because docs don't always match reality ;)]
peterjsanchez 6y ago
Yup. We migrated from BB to our own self hosted install nearly a year ago. Couldn't be happier with the change.
ndagestad 6y ago
I've been selfhosting it for a while now and the installation wasn't hard when I installed it, and the doc has gotten better since The hardest part was setting up a working mail server for the mailing lists (but that has nothing to do with sourcehut)