this piques my interest. i've been looking for a set of project hosting and management tools which are deeply integrated with each other and with very minimal UIs designed as an extension of the tool's inherent abstractions, rather than obscuring the tool behind "simple" UI abstractions which ultimately force opinionated workflows.
the only thing that's missing for this to be useful to me is code review. re: the UI, gerrit has always been my favorite code review platform because it embraces git's abstractions.
drew: do you have any plans for adding a code review service?
Hiya! I do have plans on adding a code review service, driven by email on lists.sr.ht in a similar style to how it's done in other mailing list driven projects. Here's an example of how this works:
What's the pricing structure going to be, ie. how much should I expect to pay for hosting a dozen of small git repos? I can't access the billing page without an account.
Thanks for your work for the FLOSS community, btw. I've got one machine running Sway and I might start using sr.ht.
You can choose any of $2/mo, $5/mo, or $10/mo, depending on your financial situation and investment in sr.ht. All plans have access to all features. Here's a screenshot of the billing page:
Thanks for providing this and thanks for allowing us to pay for an account. I hope that sr.ht becomes sustainable, it's great to have an alternative that is focused on open source developers.
I do intend to expand this list, probably with at least Debian packages. This isn't a high priority at the moment, though, I have limited bandwidth for sr.ht until it's profitable and have to focus on other features. This is definitely an area where an interested Debian user could contribute packages, though, especially if nicely integrated with builds.sr.ht like the other packages are.
dispatch is the newest sr.ht service and docs are scant. They'll come eventually... but it's pretty similar to the rest of sr.ht, you could probably figure it out if you gave it a shot.
I adore the aesthetic! Absolutely smooth web design; top notch work Drew.
Just registered and hope to familiarize myself with everything. This is one of the few "Show HN" projects I've felt compelled to actually try. Heck, I'm so charmed by it I want to contribute.
Always keep in mind that many people have an interest in ensuring their own job remains relevant and necessary. How else can you explain e.g. google's constant UI changes? Designer's keeping themselves busy (even though there are no real reasons for the changes)!
> On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScript
At the age of Spectre/Meltdown, it is no longer safe to leave JavaScript enabled, so thank you for this.
Then, keep in mind that new Spectre style vulnerabilities have been announced for CPUs, and the feasibility of using GPUs in this style of attacks is being explored now.
Javascript hardly needs help from Spectre/Meltdown to be a security threat. It has never been safe to allow Javascript. A reasonable compromise is to use a Javascript blocker that lets you white-list domains.
One immediate difference is that sr.ht has a publicly-hosted version; I'm having trouble finding that for Trac.
Trac is also not JS-free, so for those who prefer to not rely on arbitrary Turing-complete code running locally without explicit permission, sr.ht has an edge there.
That said, Trac feels a lot more polished (unsurprisingly, given that it has a significant headstart in terms of development resource and time).
Right, Trac has an extreme head start; it was, before Github, practically the de facto standard answer to this "software forge" problem. But it also continues to work just great, and has a pretty decent ecosystem.
I currently host my personal repositories on GitLab, as I see the monoculture that has developed around GitHub to be dangerous for the community in the long term. I went ahead and created an account on sr.ht, and subscribed for the $20 / year plan. Whether or not I end up using the service (though I think I will), I'm happy to spend $20 to support this work.
One note - the billing plans seem to be recurring right now. If you could offer an option to make a one-time payment, that would be much appreciated. If anyone else is interested in subscribing to support the project but doesn't want a recurring charge on their card, you can go to https://meta.sr.ht/billing and "cancel", which will turn off autorenewal but leave your account active for the term for which you've paid.
For the sake of sustainability, I want to discourage people from using one-time payments. For the time being charge -> cancel manually is the preferred way to do this.
I have not tried to clone it myself. But if it is not a web-facing URL, you should list it in clear CLI command and remove the <a> tag. People will click if you make it clickable.
> BTW, please add a nice 404 so people won't see that you're running nginx/1.14.0 :-)
Actually simply adding a custom 404 page won't hide the webserver/version, as it is also sent along the HTTP response headers.
For nginx specifically, one can use the `server_tokens off;` directive, which hides the version (but not the webserver). Brings back memories of when I used to recompile the webserver to remove this header :)
Of course for UX a custom 404 page is great. Congratulations, Sir_Cmpwn, this is just awesome and I'll soon be subscribing.
Congrats on the milestone. This is a huge boon to the open source community. I love the pricing model.
Are there any plans or ideas for a migration path from GitHub to sir.ht? I would imagine that if there was a way to transfer issues and discussions it would encourage more users to make the switch.
Here's one data point for you: zig programming language. Influencing factors:
* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
>* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting.
>* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
Planned. Also planned to let you sync between both.
>* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
Eventually users will be able to add custom base images, which will permit the use of Windows (if you can get an sshd running there, at least). As for multi-arch, experimental support for aarch64 is there, and by the end of the year I expect to have RISC-V builds backed by HiFive hardware.
Nonetheless, it'd be nice to have some way of plugging in more of this kind of functionality at the instance, user, and possibly repo levels. Obviously syntax highlighting is one use case, but some others:
- Sophisticated cross-referencing tools like Kythe and SourceGraph
- Linking stdlib functions and imports to public documentation, like cppreference.com, python.org, etc.
- Linking ticket/user names to my non-srht bug tracking tool (especially JIRA, but there are lots of possibilities).
- Linking to public or self-hosted generated API docs (doxygen, swagger, sphinx, etc).
- Linking to info pages generated from metadata-type files such a PKG-INFO (for example containing dependency tree information).
- Propagating back information gathered from build or test runs, for example highlighting areas missing test coverage, or which are "hot" from a perf point of view.
Only some of these would be appropriate to go into the mainline version of the tool, which is why it's important to support plugging in these capabilities for the users which need/want them.
I think a lot of what you're looking for is going to be possible through generic interfaces I plan on writing. It's not going to take the shape of "you can write code which executes on sr.ht's servers just for your repo in particular", but rather things like "you can POST to an API endpoint on git.sr.ht to annotate the sources in your tree for a specific commit sha with links to pydoc et al". builds.sr.ht would then be the place where you could run arbitrary code to automate this.
Sourcegraph CEO here. We would love to help integrate Sourcegraph into sr.ht for code intelligence (hovers, go-to-definition, etc.). We’re kicking this off with GitLab next month.
I'm sure it's lovely, but where is it? I can't see any mention of pricing in the blog entry, or in https://meta.sr.ht/, and the top hit in Google for "sr.ht pricing" is... your comment.
It would be nice to be able to add custom links to whatever form this navigation takes, also (for example, if a project uses a different solution for code review/patch submission).
Very impressive! The https://builds.sr.ht service looks especially interesting - any chance there's a way to use it without fully moving over to sr.ht? It would be nice to be able to try out the build system without having to fully commit to moving to to sr.ht, especially for projects with a large history on other platforms.
I went ahead and registered and signed up for a plan. If this is the kind of project you like to see, I encourage you to consider signing up to contribute.
Feature request: I'd love to see U2F support added.
Yep! This is planned and partially working through builds.sr.ht. I deploy my blog, drewdevault.com, through builds.sr.ht: https://builds.sr.ht/~sircmpwn/drewdevault.com This is built with Jekyll and used to be on GitHub pages. The plan is to have a place where you can dump static content, then you can use any site generator you want with builds.sr.ht.
Don't have an immediate use, but I signed up for the $20/yr account. Seems like an incredible platform, and if I have this expectation that better software be built and not tied to huge corporations beholden to investors, the only way to do that is to support it. Looking forward to digging into all this.
I love this. Everything I've read so far breathes this "made for devs" attitude. I hope that a few years from now in a HN thread that lists successful companies that got "launched" on HN (you know, the Dropboxes and so on), this will be among them---and that the product is still as honest and awesome as it looks right now!
220 comments
[ 3.2 ms ] story [ 255 ms ] threadthe only thing that's missing for this to be useful to me is code review. re: the UI, gerrit has always been my favorite code review platform because it embraces git's abstractions.
drew: do you have any plans for adding a code review service?
https://lists.sr.ht/~emersion/mrsh-dev/%3C20180916165820.144...
My plan is to parse these discussions using this library my friend made:
https://git.sr.ht/~emersion/python-emailthreads
Then provide a UI similar to Gerrit, but driven by emails underneath.
actually, i bet you have a list for high-level development updates. can you point me to it?
https://lists.sr.ht/~sircmpwn/sr.ht-announce
https://man.sr.ht/billing-faq.md
Thanks for your work for the FLOSS community, btw. I've got one machine running Sway and I might start using sr.ht.
https://sr.ht/rYFF.png
I'll capture the information here in the billing FAQ and make it easier to get to the billing FAQ without signing up later tonight.
Thanks for using sway :)
It seems a fresh revenue model after so much the-user-is-the-product models. Here's is to your success!
(Fantastic job by the way, as other commenters are pointing out this is the type of project hosting suite that I've been looking for)
https://man.sr.ht/installation.md
Just registered and hope to familiarize myself with everything. This is one of the few "Show HN" projects I've felt compelled to actually try. Heck, I'm so charmed by it I want to contribute.
What a lovely Thursday morning discovery.
Always keep in mind that many people have an interest in ensuring their own job remains relevant and necessary. How else can you explain e.g. google's constant UI changes? Designer's keeping themselves busy (even though there are no real reasons for the changes)!
At the age of Spectre/Meltdown, it is no longer safe to leave JavaScript enabled, so thank you for this.
Then, keep in mind that new Spectre style vulnerabilities have been announced for CPUs, and the feasibility of using GPUs in this style of attacks is being explored now.
Trac is also not JS-free, so for those who prefer to not rely on arbitrary Turing-complete code running locally without explicit permission, sr.ht has an edge there.
That said, Trac feels a lot more polished (unsurprisingly, given that it has a significant headstart in terms of development resource and time).
I currently host my personal repositories on GitLab, as I see the monoculture that has developed around GitHub to be dangerous for the community in the long term. I went ahead and created an account on sr.ht, and subscribed for the $20 / year plan. Whether or not I end up using the service (though I think I will), I'm happy to spend $20 to support this work.
One note - the billing plans seem to be recurring right now. If you could offer an option to make a one-time payment, that would be much appreciated. If anyone else is interested in subscribing to support the project but doesn't want a recurring charge on their card, you can go to https://meta.sr.ht/billing and "cancel", which will turn off autorenewal but leave your account active for the term for which you've paid.
Thanks for your support!
Gonna go and subscribe as well, probably. Looks quite promising.
https://lists.sr.ht/~ontouchstart
BTW, please add a nice 404 so people won't see that you're running nginx/1.14.0 :-)
https://sr.ht/~ontouchstart
https://man.sr.ht/root
also gives a 404, but in a little better format. :)
You may be confused because your shell expands it to the value of $HOME -- which you can prevent by putting it inside single quotes.
Actually simply adding a custom 404 page won't hide the webserver/version, as it is also sent along the HTTP response headers.
For nginx specifically, one can use the `server_tokens off;` directive, which hides the version (but not the webserver). Brings back memories of when I used to recompile the webserver to remove this header :)
Of course for UX a custom 404 page is great. Congratulations, Sir_Cmpwn, this is just awesome and I'll soon be subscribing.
Are there any plans or ideas for a migration path from GitHub to sir.ht? I would imagine that if there was a way to transfer issues and discussions it would encourage more users to make the switch.
Here's one data point for you: zig programming language. Influencing factors:
* If we had syntax highlighting in the file browser, that would be a win over GitHub, which insists that there be "hundreds of GitHub repositories" before accepting a syntax highlighting pull request for a new language. I could imagine it would be reasonable to support "repository-local" highlighting configuration.
* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting.
>* Transferring existing content as mentioned above. It would be unwise for us to give up all the issues and discussion.
Planned. Also planned to let you sync between both.
>* The fact that the build service supports FreeBSD is already a win. However, to switch from Azure DevOps we would lose Windows builds. Is that ruled out due to the open source nature of sr.ht, or is that planned? Related, it would be attractive if sir.ht offered more architectures, e.g. i386, ARM, RISC-V (I believe this was mentioned but I could not find it in the docs)
Eventually users will be able to add custom base images, which will permit the use of Windows (if you can get an sshd running there, at least). As for multi-arch, experimental support for aarch64 is there, and by the end of the year I expect to have RISC-V builds backed by HiFive hardware.
I really appreciate this response! That encourages improvements that benefit everyone, not just sr.ht users.
msys2 has an sshd. I use it on a Windows VM runner with Gitlab CI. It's not easy to set up but it can be done.
- Sophisticated cross-referencing tools like Kythe and SourceGraph
- Linking stdlib functions and imports to public documentation, like cppreference.com, python.org, etc.
- Linking ticket/user names to my non-srht bug tracking tool (especially JIRA, but there are lots of possibilities).
- Linking to public or self-hosted generated API docs (doxygen, swagger, sphinx, etc).
- Linking to info pages generated from metadata-type files such a PKG-INFO (for example containing dependency tree information).
- Propagating back information gathered from build or test runs, for example highlighting areas missing test coverage, or which are "hot" from a perf point of view.
Only some of these would be appropriate to go into the mainline version of the tool, which is why it's important to support plugging in these capabilities for the users which need/want them.
I'm sure it's lovely, but where is it? I can't see any mention of pricing in the blog entry, or in https://meta.sr.ht/, and the top hit in Google for "sr.ht pricing" is... your comment.
https://news.ycombinator.com/item?id=18460244
I look forward to doing deep dive the next few days and looking to contribute anyway I can.
I went ahead and registered and signed up for a plan. If this is the kind of project you like to see, I encourage you to consider signing up to contribute.
Feature request: I'd love to see U2F support added.
>any chance there's a way to use it without fully moving over to sr.ht?
Yep. I currently use builds.sr.ht in combination with GitHub, for example, to build sway & wlroots:
https://github.com/swaywm/wlroots/pull/1377
You can wire this up at https://dispatch.sr.ht
The API is also pretty simple: https://man.sr.ht/builds.sr.ht/api.md
postmarketOS uses the API, for example, in combination with some custom tooling around their package manager.
>Feature request: I'd love to see U2F support added.
https://todo.sr.ht/~sircmpwn/meta.sr.ht/62
This has been discussed before, I would accept a patch but can't work on it myself until my browser (qutebrowser) grows U2F support.
On GitHub you navigate to project(repo), then drill down to sub section provides specific piece of functionality (repo, commits, issues, wiki..)
Here you navigate to app then drill down to project..