Sourcehut's Second Year in Alpha

https://sourcehut.org/blog/2020-11-15-sourcehut-2-year-alpha/

by goranmoomin • 6 years ago

318 138 6 years ago

__henil2• 6 years 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• 6 years 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• 6 years 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• 6 years ago

Here's a video on the email workflow by Sourcehut's author, https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...

eatonphil2• 6 years ago

I haven't used Sourcehut, but almost no other CI service I know of provides FreeBSD or OpenBSD runners.

arch-ninja• 6 years ago

I count simplicity as a feature. Not knocking GitLab, from a business perspective they provide the same capability.

mfsch• 6 years 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.

__henil2• 6 years 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/

shakna2• 6 years 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• 6 years 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• 6 years 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.

knowledge-clay• 6 years ago

no javascript

To be clear, sourcehut does occasionally use JavaScript, it’s just very conservative and optional.

hprotagonist• 6 years ago

ideological purity.

busterarm2• 6 years 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.

SulfurHexaFluri2• 6 years ago

The open source section of Gitlab is very powerful and perfectly usable on its own.

wpietri• 6 years ago

There's a nice feature list on their home page: 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.

sytse3• 6 years 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/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.

nathcd• 6 years 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• 6 years ago

Sounds like a good way to accidentally create a repo, hopefully it’s private by default.

musicmatze• 6 years 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• 6 years ago

Can you elaborate on how sourcehut or other git workflows scale better?

Znafon3• 6 years 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.

ChickeNES2• 6 years 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.

sirodoht2• 6 years ago

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

wirrbel• 6 years ago

I just like the fact that there is mercurial support

colonwqbang• 6 years 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• 6 years 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• 6 years 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• 6 years 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.

systemvoltage5• 6 years 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.

smt883• 6 years 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.

jamescostian5• 6 years ago

I, on the other hand, dislike this design. Consider how many devs use Apple products - proprietary products that come in a walled garden, and that in many ways go against developers. A good amount of it comes down to aesthetics. Were Sourcehut to have, say, a "2020 theme" or something, that would help lots of those devs appreciate it more.

Developers are using macOS despite it continually removing features from developers, and are even in some cases defending Apple's decisions. I believe that this design actively harms the adoption of Sourcehut. There are definitely other things Sourcehut should do if they want more of GitHub's and GitLab's marketshare, changing their UI (or adding an alternative UI) is an important part of that process.

ddevault24• 6 years ago

Design is in the eye of the beholder - many users find SourceHut's UI beautiful and have praised it as such. Beauty is also more than just a pretty face - SourceHut is an engineering tool, and if it elegantly and efficiently organizes information for engineers to use, that can be more important and more beautiful than an eye-catching design. In fact, an eye-catching design can often degrade the experience of engineering tools, and eye-catching elements - such as colorful buttons - are carefully and deliberately controlled for in the design of sr.ht. It optimizes getting you the information you need or helping you complete the task you came here for as efficiently as possible.

SourceHut has been designed deliberately and for a specific purpose. The simplicitly of its appearance is a feature.

ancarda• 6 years ago

I can't speak for everyone, but I didn't pickup macOS because it's shiny. I picked it up because it's UNIX/BSD while also having a lot of proprietary software like Photoshop (without using Wine). That and the hardware is pretty good.

Sure, I want stuff to look nice too, but only if it doesn't ruin the user experience in other ways like making the site slower to load and use

zorked• 6 years ago

FWIW I am attracted to Sourcehut's aesthetic exactly because it's not a "2020 theme", so I've been using it and paying for it. Pages are simple and functional. Github makes me feel tired, overwhelmed, and it requires too much scrolling and reading what looks like ad copy.

systemvoltage5• 6 years ago

Do you like HN's design? It gets the job done, right? Why do we need aesthetics? It gets in the way for the most part.

Barrin92• 6 years ago

not only do I see fewer macbooks every year among the affluent crowd as more and more people just seem to go straight for linux or WSL machines, this is particularly untrue for much of the developing world, where most of the developers of the future will live (or already do, IDK). And let me tell you those people appreciate a simple, fast loading webpage.

If you want more market share build a product for the entire world, which does not run on the newest fancy version of iOS.

sam0x172• 6 years 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.

ddevault24• 6 years 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.

sam0x172• 6 years 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.

xvilka2• 6 years 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/...

ddevault24• 6 years 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

xvilka2• 6 years ago

Always good to know. Thank you for it, I am a happy user myself!

coder5432• 6 years 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.

martanne• 6 years ago

Long-waited NetBSD support in CI would be awesome to be finished too.

As the maintainer of the linked vis project, I can confirm that the provided SSH access to the CI environment is very convenient and saves a lot of time.

I would also like to see the NetBSD support completed. It turns out that up until last week, we missed a #define to compile out of the box[1].

[1] https://git.sr.ht/~martanne/vis/commit/01eef9f87b72b0c147367...

alisonkisk• 6 years ago

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

sirodoht2• 6 years ago

The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD.

shakna2• 6 years 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__• 6 years 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/

SahAssar• 6 years ago

See here: https://news.ycombinator.com/item?id=18930509

mikepurvis• 6 years 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-availabilit...

setheron• 6 years ago

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

fuball63• 6 years 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://en.wikipedia.org/wiki/Gopher_%28protocol%29

MaxBarraclough• 6 years 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?

jniedrauer• 6 years 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.

ddevault24• 6 years 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. 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.

rwj2• 6 years 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.

CivBase2• 6 years 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?

ddevault24• 6 years 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-discuss

https://lists.sr.ht/~sircmpwn/sr.ht-announce

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.

CivBase2• 6 years ago

That's perfect. Thanks!

yjftsjthsd-h• 6 years ago

Most mailing lists have archives; doesn't that do what you want?

Rapzid• 6 years ago

Mailing lists?! Yuck!

- Most developers born after 1980

_ix• 6 years 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• 6 years ago

Full transparency: I'm trying to build something similar at 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/

[2] https://sourcehut.org/blog/2020-04-20-prioritizing-simplitit...

[3] https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prev...

[4] 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.

JNRowe2• 6 years 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.

ddevault24• 6 years 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

There's a patchset in my review queue which will organize, update, and streamline these instructions - might be worth checking back in a week.

JNRowe2• 6 years 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• 6 years ago

Yup. We migrated from BB to our own self hosted install nearly a year ago. Couldn't be happier with the change.

ndagestad• 6 years 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)

Sourcehut's Second Year in Alpha

Related Stories