I'm not sure what the adoption will be like in the long term (the design might be too minimalist/niche for some), but it's nice to see such variety and focus on usability and meaningful minimalism.
It feels like my install of Gitea and Drone CI, but taken a step further on getting things done and not much more. Probably a pretty stark contrast from what my personal GitLab and GitLab CI instance used to run like (the UI there was great IMO, just slow).
It's nice that we have solutions like that, especially those that can be self-hosted, or just hosted versions for people who don't want to admin their own instances. For now, self-hosted Gitea and Drone CI are good enough for me.
Sourcehut the website is indeed very pleasant to even just browse, but as a very occasional browser of it I have struggled perhaps three times over the last couple of months, for several minutes each, to find the list of services in the parent comment—even though I knew it was there.
At least the last two times I’ve finally succeeded through remembering the existence of https://man.sr.ht/, which does have a (different) list of services, and only when writing this comment did I stumble upon what is probably the intended way—that https://sr.ht/ (my first try every time, and what “sourcehut” in every header links to), which looks like a Sourcehut-the-website homepage, has a link in its body, titled “Sourcehut”, to https://sourcehut.org/ (previously located only via a search engine), which is seems to be the intended Sourcehut-the-website homepage, and presents it thoroughly and eloquently.
Now that I’m looking at this closely, man.sr.ht mentions “service[] links in the navigation at the top of the site”. Those probably eliminate this problem for logged-in users—but I’m not one of them, so(?) I don’t see any!
A somewhat related complaint is that the git.sr.ht page for a project (that I’m most likely to remember, because they’re in my git remotes) don’t link back to the sr.ht page for it with the ML and CI and perhaps sibling repos (that I can in the common case reach by simply editing the domain of the URL—once I remember it exists). I wouldn’t be surprised if most people unfamilliar with Sourcehut, when visiting a git.sr.ht link, thought the repo on it was all there was (especially given it would be true on GitHub).
(All of this is reasonable given how Sourcehut is factored into several services, but it’s still unfortunate.)
TL;DR: Sourcehut nice, Sourcehut homepage also nice but difficult to find when pointed to hosted project’s home or repo page, former also nonobvious from latter.
>Those probably eliminate this problem for logged-in users—but I’m not one of them, so(?) I don’t see any!
These were intentionally removed for logged-out users because they can be a bit confusing -- many users would look at, say, a git repo, and think that the lists link would take them to that project's mailing lists. This is a long-understood problem that we expect to be able to solve within several weeks -- briefly mentioned in the OP.
> A somewhat related complaint is that the git.sr.ht page for a project (that I’m most likely to remember, because they’re in my git remotes) don’t link back to the sr.ht page for it with the ML and CI and perhaps sibling repos (that I can in the common case reach by simply editing the domain of the URL—once I remember it exists). I wouldn’t be surprised if most people unfamilliar with Sourcehut, when visiting a git.sr.ht link, thought the repo on it was all there was (especially given it would be true on GitHub).
Same basic problem, same planned solution, same priority.
This is awesome -- I've been following sourcehut's progress very closely, right from the beginning. You guys have come far, and have a bright future ahead. I'm looking forward to learning how you plan to adopt and run Kubernetes in your DC.
Also stoked for {names,mail}.sr.ht -- two services that I'll most definitely be using when they launch.
they're awesome they just do personal email though, no saas. i was using them for verification emails and they said its fine for testing but you need to find a volume sender.
I use this on my daily driver every day and is a great option to the "standard" systemd-logind or elogind. I think of it as a shining example of sourcehut's core values.
Emacs, although with the obvious caveat that the sourcehut hosting of Emacs is little more than a mirror right now. There was at one point serious talk of Emacs moving its primary development to either sr.ht or a GNU-hosted sourcehut, but I'm not sure if that went anywhere.
I have to say, very excited about all of the future projects!
I'm also interested in seeing what the federated GQL solution will be as well- there are established players in this space like Apollo but built on more open-core models. Their federation model is well defined and on version 2 now. Not sure what learnings can be taken from this, or if that solutions "just fits" the needs of Sourcehut.
29 comments
[ 4.7 ms ] story [ 86.2 ms ] threadSourceHut is a breath of fresh for FLOSS, and I'm genuinely excited to see --- and hopefully contribute to --- the upcoming projects.
Even the homepage has a few links that you can click around, to explore some of the features for yourself: https://sourcehut.org/
"Hosted git repositories": https://git.sr.ht/~sircmpwn/scdoc
"Powerful continuous integration": https://builds.sr.ht/~sircmpwn/job/97412
"Mailing lists & code review tools": https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/14726
"Focused ticket tracking": https://todo.sr.ht/~sircmpwn/todo.sr.ht
"Markdown- and git-driven wikis": https://man.sr.ht/
I'm not sure what the adoption will be like in the long term (the design might be too minimalist/niche for some), but it's nice to see such variety and focus on usability and meaningful minimalism.
It feels like my install of Gitea and Drone CI, but taken a step further on getting things done and not much more. Probably a pretty stark contrast from what my personal GitLab and GitLab CI instance used to run like (the UI there was great IMO, just slow).
It's nice that we have solutions like that, especially those that can be self-hosted, or just hosted versions for people who don't want to admin their own instances. For now, self-hosted Gitea and Drone CI are good enough for me.
At least the last two times I’ve finally succeeded through remembering the existence of https://man.sr.ht/, which does have a (different) list of services, and only when writing this comment did I stumble upon what is probably the intended way—that https://sr.ht/ (my first try every time, and what “sourcehut” in every header links to), which looks like a Sourcehut-the-website homepage, has a link in its body, titled “Sourcehut”, to https://sourcehut.org/ (previously located only via a search engine), which is seems to be the intended Sourcehut-the-website homepage, and presents it thoroughly and eloquently.
Now that I’m looking at this closely, man.sr.ht mentions “service[] links in the navigation at the top of the site”. Those probably eliminate this problem for logged-in users—but I’m not one of them, so(?) I don’t see any!
A somewhat related complaint is that the git.sr.ht page for a project (that I’m most likely to remember, because they’re in my git remotes) don’t link back to the sr.ht page for it with the ML and CI and perhaps sibling repos (that I can in the common case reach by simply editing the domain of the URL—once I remember it exists). I wouldn’t be surprised if most people unfamilliar with Sourcehut, when visiting a git.sr.ht link, thought the repo on it was all there was (especially given it would be true on GitHub).
(All of this is reasonable given how Sourcehut is factored into several services, but it’s still unfortunate.)
TL;DR: Sourcehut nice, Sourcehut homepage also nice but difficult to find when pointed to hosted project’s home or repo page, former also nonobvious from latter.
These were intentionally removed for logged-out users because they can be a bit confusing -- many users would look at, say, a git repo, and think that the lists link would take them to that project's mailing lists. This is a long-understood problem that we expect to be able to solve within several weeks -- briefly mentioned in the OP.
> A somewhat related complaint is that the git.sr.ht page for a project (that I’m most likely to remember, because they’re in my git remotes) don’t link back to the sr.ht page for it with the ML and CI and perhaps sibling repos (that I can in the common case reach by simply editing the domain of the URL—once I remember it exists). I wouldn’t be surprised if most people unfamilliar with Sourcehut, when visiting a git.sr.ht link, thought the repo on it was all there was (especially given it would be true on GitHub).
Same basic problem, same planned solution, same priority.
(I do not mean to imply that they're downing on Migadu or anything, 's mostly a curious question)
https://sr.ht/~mil/sxmo/
https://sr.ht/~thestr4ng3r/chiaki/
https://sr.ht/~alextee/zrythm/
https://sr.ht/~eliasnaur/gio/
https://sr.ht/~mil/mepo/
https://sr.ht/~etalab/code.gouv.fr/
Feel free to browse more here:
https://sr.ht/projects
I use this on my daily driver every day and is a great option to the "standard" systemd-logind or elogind. I think of it as a shining example of sourcehut's core values.
I'm also interested in seeing what the federated GQL solution will be as well- there are established players in this space like Apollo but built on more open-core models. Their federation model is well defined and on version 2 now. Not sure what learnings can be taken from this, or if that solutions "just fits" the needs of Sourcehut.
Keep it coming, everything is looking great!