Sr.ht, the hacker's forge, now open for public alpha(drewdevault.com)
drewdevault.com
Sr.ht, the hacker's forge, now open for public alpha
https://drewdevault.com/2018/11/15/sr.ht-general-availability.html
220 comments
>* 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.
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.
> We use pygments, so patches to pygments would make it to sr.ht's syntax highlighting.
I really appreciate this response! That encourages improvements that benefit everyone, not just sr.ht users.
I really appreciate this response! That encourages improvements that benefit everyone, not just sr.ht users.
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.
- 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.
Great! My email is [email protected]. I can't guarantee a lot of cycles right now, but get in touch and I'll keep it on my radar.
Awesome. Just filed https://github.com/sourcegraph/sourcegraph/issues/1027 on our end to track it.
> 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).
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.
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.
Microsoft has ported OpenSSH, at least on Windows 10 you can install it as a Windows feature, or pull it from GitHub https://github.com/PowerShell/Win32-OpenSSH/releases
I have also successfully run it from WSL
> I love the pricing model.
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.
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.
At this point you have to be signed in to see it. See this comment for a screenshot and details:
https://news.ycombinator.com/item?id=18460244
https://news.ycombinator.com/item?id=18460244
My feedback:
- It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
- Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
- Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
- It feels very responsive. Great job on having the site being very light so far
- Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
- The UI looks clean and minimalistic, which is great. Featureful isn't a bad thing either if done right. I think you're on the right path though
Overall, this seems like a great project. I haven't tried the builds system yet, but I definitely will. Keep up the great work Drew!
- It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
- Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
- Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
- It feels very responsive. Great job on having the site being very light so far
- Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
- The UI looks clean and minimalistic, which is great. Featureful isn't a bad thing either if done right. I think you're on the right path though
Overall, this seems like a great project. I haven't tried the builds system yet, but I definitely will. Keep up the great work Drew!
Thank you for your feedback!
>It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
https://todo.sr.ht/~sircmpwn/sr.ht/112
>Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
Encrypted, too, if you add your PGP key to meta.sr.ht.
>Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
I may adjust the pricing later, but I want to see how this works out. If you're interested in going above and beyond, I accept donations here:
https://drewdevault.com/donate
Thanks <3
>Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
Not interested in this for the time being, it's pretty fast without.
Thanks so much for your support!
>It's left aligned, which makes it harder to use on an ultrawide, with the content in the first 1/3 of the page. Having a max-width on the main container and center aligning it would be great
https://todo.sr.ht/~sircmpwn/sr.ht/112
>Emails are GPG signed! Even if the usefulness is small, it's a awesome feature
Encrypted, too, if you add your PGP key to meta.sr.ht.
>Pricing seems good, but I would charge more. 3$, 8$, 15$, if following the pricing scheme you have. I know I'd be happy to pay for 15$/m for a useful service. You could also make it "pay however much you want", so it's flexible if people want to pay 5$ or 50$, and it calculate with the tiers (if over X$, use plan Y)
I may adjust the pricing later, but I want to see how this works out. If you're interested in going above and beyond, I accept donations here:
https://drewdevault.com/donate
Thanks <3
>Maybe having something like Turbolinks could be pretty cool. SPA are great because they feel instant, and with a few lines of optional JavaScript you could provide an experience which is SPA-like since the server-side rendering is so quick
Not interested in this for the time being, it's pretty fast without.
Thanks so much for your support!
Makes sense for everything! Great product, I will definitely check it out as it grows and probably buy a subscription.
Thanks! I hope you like it!
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.
What a lovely Thursday morning discovery.
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.
Agree. Simple and not over-engineered.
>not over-engineered
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)!
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)!
Thank you for your kind words! I'm happy that you like it.
It's ok but it should really be centred at least.
This is really exciting! I particularly like the lightness of the web-pages and the non-necessity of javascript. The support for the BSDs in the build system (FreeBSD at the moment, OpenBSD and NetBSD planned[0]) is also nice — as a Linux person I've far too often ignored the other Unixes and POSIX / general Unix compatibility.
I hate being THAT guy, but would you consider trying[1] to re-license the AGPL-3.0 bits to AGPL-3.0-or-later, unless sticking with just v3 was deliberate (in which case fair enough)? My rationale:
i) License-incompatibility is a curse that fragments the copyleft world.
ii) Worrying about AGPL-3.0-only being incompatible with AGPL-4.0, in ten years time, if/when the latter comes out, will be too late, as (hopefully) sr.ht will have had hundreds or thousands of contributors, many uncontactable, by then.
iii) Having AGPL-3.0-or-later instead of just AGPL-3.0 is unlikely to put off any contributors.
iv) (This is subjective and might not hold for you:) I trust the FSF not to do something sufficiently crazy with its next iteration of licenses (if such exist), that I would prefer my code not to be compatible with such licenses.
[0] https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3C201808022145...
[1] This obviously also depends on the other contributors, so you might not want to bother with the effort.
I hate being THAT guy, but would you consider trying[1] to re-license the AGPL-3.0 bits to AGPL-3.0-or-later, unless sticking with just v3 was deliberate (in which case fair enough)? My rationale:
i) License-incompatibility is a curse that fragments the copyleft world.
ii) Worrying about AGPL-3.0-only being incompatible with AGPL-4.0, in ten years time, if/when the latter comes out, will be too late, as (hopefully) sr.ht will have had hundreds or thousands of contributors, many uncontactable, by then.
iii) Having AGPL-3.0-or-later instead of just AGPL-3.0 is unlikely to put off any contributors.
iv) (This is subjective and might not hold for you:) I trust the FSF not to do something sufficiently crazy with its next iteration of licenses (if such exist), that I would prefer my code not to be compatible with such licenses.
[0] https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3C201808022145...
[1] This obviously also depends on the other contributors, so you might not want to bother with the effort.
> I trust the FSF not to do something sufficiently crazy
Personally, I don't trust this at all, and would recommend against the "or later" that yields future licensing decisions to the Richard Stallman and that FSF.
Personally, I don't trust this at all, and would recommend against the "or later" that yields future licensing decisions to the Richard Stallman and that FSF.
Can you elaborate on your reasoning for that?
not speaking for OP, but the significant changes between GPL v2 and GPL v3 would make me absolutely paranoid, and represent a good example. A "v2-and-later" would have subjected people to licensing changes they absolutely don't want.
From GPL 2:
> either version 2 of the License, or (at your option) any later version.
"At your option" means that no one is 'subjected' to changes they don't want. They just have the option to upgrade.
> either version 2 of the License, or (at your option) any later version.
"At your option" means that no one is 'subjected' to changes they don't want. They just have the option to upgrade.
Sure, but this thread is about licensing the software as "version $x or later", which pushes the choice to the user of the license.
And that is why GrafX2 devs switched[0] to GPLv2 only
> GPL v2, without the "any later version" clause (sorry FSF, I don't want to accept licences you didn't even write yet).
[0] https://gitlab.com/GrafX2/grafX2/commit/26c6d12d0987f4467036...
> GPL v2, without the "any later version" clause (sorry FSF, I don't want to accept licences you didn't even write yet).
[0] https://gitlab.com/GrafX2/grafX2/commit/26c6d12d0987f4467036...
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!
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.
> 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.
At the age of Spectre/Meltdown, it is no longer safe to leave JavaScript enabled, so thank you for this.
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.
got a source on that?
https://github.com/ascendr/spectre-chrome
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.
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.
I love this, and wish it well.
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.
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.
Thanks for your support!
Thanks for your support!
That is understandable, as long as it is not difficult to find the cancellation button.
Gonna go and subscribe as well, probably. Looks quite promising.
Gonna go and subscribe as well, probably. Looks quite promising.
A meta comment on the HN community: People constantly decry HN's "negativity" to Show HN posts or other tech related news, but I think when really cool projects (like this one) show up, people respond overwhelmingly positively. Maybe it's a good thing that HN as a community has high standards.
I noticed that there's no link from, for example, https://todo.sr.ht/~sircmpwn/man.sr.ht to https://git.sr.ht/~sircmpwn/man.sr.ht - is there any way to link a project's pages together across multiple sr.ht services? Otherwise the navigation isn't so friendly for someone just discovering a project.
Looks like the CI builds are tied to a user/group account rather than being tied to a particular repo or branch. Bravo on that— it works much better for projects whose build is composed of assets from many small repos than the approach of Travis (and GitLab, who cloned it) of tightly coupling those things.
I'm glad you like this, it was a key design decision of builds.sr.ht.
You mention:
> lists.sr.ht finally modernizes mailing lists
What's new that lists.sr.ht brings to the table? I only had a quick browse of https://lists.sr.ht/~sircmpwn/sr.ht-dev, but as far as I could tell it looked like a pretty normal list of topic lines (like a typical web forum), and the e-mail conversations themselves are just the messages concatenated into one long page (e.g. https://lists.sr.ht/~emersion/mrsh-dev/%3C20180916165820.144...).
Is there something interesting and new about the way these mailing lists work that I'm not seeing?
> lists.sr.ht finally modernizes mailing lists
What's new that lists.sr.ht brings to the table? I only had a quick browse of https://lists.sr.ht/~sircmpwn/sr.ht-dev, but as far as I could tell it looked like a pretty normal list of topic lines (like a typical web forum), and the e-mail conversations themselves are just the messages concatenated into one long page (e.g. https://lists.sr.ht/~emersion/mrsh-dev/%3C20180916165820.144...).
Is there something interesting and new about the way these mailing lists work that I'm not seeing?
"Looking like a typical web forum" is a huge improvement compared to what e.g. GNU Mailman offers.
Well, Mailman 3 with HyperKitty looks more like some web forums. But Mailman 2 is quite dated...
I also like how DFeed looks. It's written in D and simultaneously serves forums, mailing lists, IRC and (lol) Usenet; all on an SQLite backend. It's also compiled to machine code, so it's pretty fast:
https://forum.dlang.org/
https://forum.dlang.org/
Just having this is a huge improvement over what most lists have (e.g. https://lists.freedesktop.org/archives/wayland-devel/).
There are also patch formatting features that let you comfortably review patches: https://lists.sr.ht/%7Eemersion/mrsh-dev/%3C20180929203159.3...
The planned code review features (commenting a line, approving, applying a patch, reporting CI status) are also novel for mailing lists.
There are also patch formatting features that let you comfortably review patches: https://lists.sr.ht/%7Eemersion/mrsh-dev/%3C20180929203159.3...
The planned code review features (commenting a line, approving, applying a patch, reporting CI status) are also novel for mailing lists.
With a service like this, I don't understand why a lack of tracking is touted as a feature - I don't want Google et al tracking my search history and across 3rd party websites, but I want to provide usage data to services I value.
Usage data is valuable for understanding how users use your service, features that aren't used, or simply not discovered. I'd personally prefer that tracking was added, but as an opt-in model.
Usage data is valuable for understanding how users use your service, features that aren't used, or simply not discovered. I'd personally prefer that tracking was added, but as an opt-in model.
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?
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:
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.
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.
wow, that's such a natural interaction model. i will be eagerly following sr.ht's development. :)
actually, i bet you have a list for high-level development updates. can you point me to it?
actually, i bet you have a list for high-level development updates. can you point me to it?
Would you say Fossil (https://fossil-scm.org) forces an opinionated workflow?
Forgive me if this is covered elsewhere, but I haven't found it yet.
One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
I think it's great that you're supporting email as a first-class way to interact with the services, but will there also be anything like GitHub's "Notifications" page?
Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
Thanks for your work and for sharing it freely.
One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
I think it's great that you're supporting email as a first-class way to interact with the services, but will there also be anything like GitHub's "Notifications" page?
Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
Thanks for your work and for sharing it freely.
Thanks for your feedback and questions!
>One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
For the moment I've explicitly decided against this. I want sr.ht to be a professional tool more so than a social network. This may change to varying degrees in the future.
>will there also be anything like GitHub's "Notifications" page?
There will be a feed of events, which you can use for a similar reason. At the moment, there are feeds like this, but they aren't global - they're scoped to each sub-site, like lists.sr.ht. Here's what my lists.sr.ht page looks like:
https://sr.ht/SbLu.png
>Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
Maybe!
>One of the things that I do like about GitHub is actually the community/social aspect. For example, I follow projects I am interested in, and I can see notifications from all of them on one page--without filling up my email inbox. I also follow users who have similar interests, and I often discover new projects when I see in my feed (which I read via RSS) that they've starred a project that sounds interesting.
For the moment I've explicitly decided against this. I want sr.ht to be a professional tool more so than a social network. This may change to varying degrees in the future.
>will there also be anything like GitHub's "Notifications" page?
There will be a feed of events, which you can use for a similar reason. At the moment, there are feeds like this, but they aren't global - they're scoped to each sub-site, like lists.sr.ht. Here's what my lists.sr.ht page looks like:
https://sr.ht/SbLu.png
>Another feature I enjoy on GitHub is the ability to view issues and PRs across all of my repos from a single search page (e.g. search for "user:repo-owner-username is:issue"). Will sr.ht have anything like this?
Maybe!
Hi, and congratulations, it looks awesome and has that old school unix feel I like, so you have a subscriber here.
Regarding the social/professional divide, a way to follow releases/security patches/API breakages on the projects I follow might make me more productive. I don't care about who stars who, but a way to link projects brings something.
Following releases of dependencies and use this information to improve CI/CD and try to explain breakage or trigger new builds could be very useful.
Regarding the social/professional divide, a way to follow releases/security patches/API breakages on the projects I follow might make me more productive. I don't care about who stars who, but a way to link projects brings something.
Following releases of dependencies and use this information to improve CI/CD and try to explain breakage or trigger new builds could be very useful.
I recommend setting up a mailing list, project-announce or project-security, on lists.sr.ht for that purpose.
>Following releases of dependencies and use this information to improve CI/CD and try to explain breakage or trigger new builds could be very useful.
This should be quite possible, perhaps even automatable through dispatch.sr.ht.
>Following releases of dependencies and use this information to improve CI/CD and try to explain breakage or trigger new builds could be very useful.
This should be quite possible, perhaps even automatable through dispatch.sr.ht.
> I recommend setting up a mailing list, project-announce or project-security, on lists.sr.ht for that purpose.
Indeed looks like it covers my needs. Thanks!
Indeed looks like it covers my needs. Thanks!
I find the ability to subscribe to (and aggregate) notifications on individual issues and projects incredibly helpful, professionally, because it lets me easily keep track of fixes and changes in upstream projects.
You can have email notifications without filling up your inbox. Just set up a filter rule to move all emails from an address to a folder. I do that for all spammy things like mailing lists or issue tracker comments.
One of the coolest projects I've seen in a while! Really excited to see where this goes.
Some quick feedback: viewing messages on lists.sr.ht on mobile gives the "<code> block experience" of moving a horizontal a scroller for every line.
This might be intentional (wrapping can wreck formatting/alignment) but it might be worth wrapping for it to be less painful to read from a mobile browser.
Some quick feedback: viewing messages on lists.sr.ht on mobile gives the "<code> block experience" of moving a horizontal a scroller for every line.
This might be intentional (wrapping can wreck formatting/alignment) but it might be worth wrapping for it to be less painful to read from a mobile browser.
This looks really nice and it's working incredibly quick for me.
I have a couple of maybe stupid question.. I'm having trouble understanding the workflow. When I open something like https://todo.sr.ht/~sircmpwn/
This is the issue page for a user, right?
And then when I go to
https://todo.sr.ht/%7Esircmpwn/sr.ht
(oh, the tilde copy-and-pastes weird into the comment window.. not sure what that's about)
This is the "issue page" (in Github speak) for one of a user's repositories. But how do I navigate from there to the actual repository? The 'git' button at the top takes me to generic landing page? I found this link through the announcement page : https://git.sr.ht/~sircmpwn but I dont get how to navigate to there naturally.
Or how to go from the git back to the todo. I get they're decoupled features, but surely there must be a way to go back and forth.
Also when I open up the 'tree' section, each line starts with file permissions in the style of 'ls -la'. Is this b/c the system is fundamentally tied to POSIX? (I've used git with no problem on Windows before - so I don't see why it would be)
I have a couple of maybe stupid question.. I'm having trouble understanding the workflow. When I open something like https://todo.sr.ht/~sircmpwn/
This is the issue page for a user, right?
And then when I go to
https://todo.sr.ht/%7Esircmpwn/sr.ht
(oh, the tilde copy-and-pastes weird into the comment window.. not sure what that's about)
This is the "issue page" (in Github speak) for one of a user's repositories. But how do I navigate from there to the actual repository? The 'git' button at the top takes me to generic landing page? I found this link through the announcement page : https://git.sr.ht/~sircmpwn but I dont get how to navigate to there naturally.
Or how to go from the git back to the todo. I get they're decoupled features, but surely there must be a way to go back and forth.
Also when I open up the 'tree' section, each line starts with file permissions in the style of 'ls -la'. Is this b/c the system is fundamentally tied to POSIX? (I've used git with no problem on Windows before - so I don't see why it would be)
>Also when I open up the 'tree' section, each line starts with file permissions in the style of 'ls -la'. Is this b/c the system is fundamentally tied to POSIX? (I've used git with no problem on Windows before - so I don't see why it would be)
Because the file mode is stored in git. The tree view is a representation of the git tree, and the mode is a property stored in the tree.
Because the file mode is stored in git. The tree view is a representation of the git tree, and the mode is a property stored in the tree.
Gotcha. Thanks for taking the time to explain :)
Navigating between different pages for the same project is an upcoming feature
I remember a discussion with Drew on HN a while ago. I held that the GitHub model was more inviting to small contributions given the overhead of figuring out how to get said small contribution integrated was paid for every new project outside of GitHub(-likes), but only once for GitHub and friends [1] (see discussion at https://news.ycombinator.com/item?id=17803588).
sr.ht takes a very good stab at that problem, while maintaining that old-style approach. (For example through predictable mailing list names, should the project choose to use lists.sr.ht, which is likely.)
Kudos, Drew.
One intriguing thing about sr.ht is the way builds.sr.ht is described: amazingly powerful [2]. It's been a while since I configured myself a Travis workflow, but remember it was YAML based as well and one could do quite a number of things with it. What I'm missing is a description of exactly how builds.sr.ht towers above all the rest.
[1]: By approximation, some projects hosted on GitHub have more specific rules and will not consider those who deviate.
[2]: https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...
sr.ht takes a very good stab at that problem, while maintaining that old-style approach. (For example through predictable mailing list names, should the project choose to use lists.sr.ht, which is likely.)
Kudos, Drew.
One intriguing thing about sr.ht is the way builds.sr.ht is described: amazingly powerful [2]. It's been a while since I configured myself a Travis workflow, but remember it was YAML based as well and one could do quite a number of things with it. What I'm missing is a description of exactly how builds.sr.ht towers above all the rest.
[1]: By approximation, some projects hosted on GitHub have more specific rules and will not consider those who deviate.
[2]: https://drewdevault.com/2018/11/15/sr.ht-general-availabilit...
Congratulations from an early tester. I'm happy you're making such a good progress on this.
Also happy to see more aliens here appreciating brutalist aesthetics :-)
Also happy to see more aliens here appreciating brutalist aesthetics :-)
Just signed up. I like the old fashioned user URL, reminds me the age of public_html
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://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
> 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.
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.
Thanks for the feedback! https://todo.sr.ht/~sircmpwn/sr.ht/113
Following link listed on the man page https://man.sr.ht
https://man.sr.ht/root
also gives a 404, but in a little better format. :)
https://man.sr.ht/root
also gives a 404, but in a little better format. :)
That's a git clone URL, not a web-facing URL :)
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.
Hmm i made a golang project to test https://git.sr.ht/~ata/demo/tree/master/main.go and first thing I noticed was that ~ in my package name. I wonder if that’s valid golang?
Golang doesn’t have a problem with it, but I would have to rename src/git.sr.ht/ata src/git.sr.ht/~ata a ~ in the filename which linux doesn’t like
The only characters not allowed in a filename on Linux are 0x00 (the null byte) and '/'. It's perfectly valid to have '~' in it.
You may be confused because your shell expands it to the value of $HOME -- which you can prevent by putting it inside single quotes.
You may be confused because your shell expands it to the value of $HOME -- which you can prevent by putting it inside single quotes.
aaron@aspire5742:~$ echo hi > 'foo~bar.txt'
aaron@aspire5742:~$ ls -l *.txt
-rw-r--r-- 1 aaron aaron 3 Nov 16 03:20 foo~bar.txt
aaron@aspire5742:~$ cat 'foo~bar.txt'
hi
aaron@aspire5742:~$I mean, you can do it, it’ll work but looks weird.
How does this compare to Trac, which is also a 100% free, open source "software forge" (also built on Python)?
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).
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 like everything.
Well, almost everything: The "View raw message" feature exposes way too much information about your contributors - including their email, smtp client, ip, and a bunch of other things. I understand and appreciate the usefulness, but as a contributor I don't usually expect my details to become that public.
Well, almost everything: The "View raw message" feature exposes way too much information about your contributors - including their email, smtp client, ip, and a bunch of other things. I understand and appreciate the usefulness, but as a contributor I don't usually expect my details to become that public.
The IP is the IP of your mail server, which is a lot less private (you can derive that just by doing a DNS lookup on your hostname). The email address is explicitly exposed, your email is not private in git repos either, and it's important that people are able to get in touch with you. It's a mailing list!
I'm glad that you like everything else :)
I'm glad that you like everything else :)
Many email servers report the IP of the incoming SMTP connection when you use a client (e.g. mutt, Thunderbird, Apple Mail, or Outlook) as an "X-Client-IP" or similar raw header; often also the envelope "from", which may be different than the message "from" which is the only one usually shown.
It's not that IPs are very private - sending an email to someone often tells a lot about you. But having all that info publicly scrapable seems unexpected to me.
It's not that IPs are very private - sending an email to someone often tells a lot about you. But having all that info publicly scrapable seems unexpected to me.
That seems fair. I can probably strip unnecessary headers from incoming emails.
https://todo.sr.ht/~sircmpwn/lists.sr.ht/60
https://todo.sr.ht/~sircmpwn/lists.sr.ht/60
[deleted]
Looks fantastic, I just signed up to try it out.
Small ux thing; the nav bar on top are different for every subdomain. Probably easier to navigate if the elements are in fixed positions.
Small ux thing; the nav bar on top are different for every subdomain. Probably easier to navigate if the elements are in fixed positions.
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.
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.
Thanks for signing up!
>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.
>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.
Yeah, you can use https://man.sr.ht/dispatch.sr.ht/ to push github commits to builds.sr.ht, or write some automation to push builds using the API.
Is this orthogonal approach to GitHub, etc ?
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..
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..
According to comments elsewhere on this post, this functionality is in the works.
All features work without JavaScript
I see it as a reflection of the website's overall design stance: no frills, no stupid material design, no js junk scripts. Just a fast-loading website that loads what it needs to. This kind of website is quite refreshing in 2018.
Maybe one day it will have a tiny amount of JS, but let's cross that bridge when it comes. That's still better than the vast majority of modern websites built today.
Maybe one day it will have a tiny amount of JS, but let's cross that bridge when it comes. That's still better than the vast majority of modern websites built today.
It does already have some JS. On the builds page, when it is running a build, it refreshes every second to show new output.
This is accomplished without JavaScript.
There’s a script tag on the builds page that reloads the page every second, according to the page source. How is that not JavaScript?
Even if it did have JS, I think most of the crowd would be fine with minimal JS also, since there are some legitimate use cases. Having JS is not the end of the world, but today's standard is to completely abuse it, leading to horrifically bloated websites.
I like this design decision. I can't talk for other people, but if a page looks good on a text based browser, I consider it to be well designed page (although I don't force the converse).
The way I understand it, the only real reason why there is something like javascript at all is that one wants to improve latency / computing load on servers. But since javascript is already here, it is now easy to abuse it instead by cluttering all kinds of junk and computing to the page and to the browser / client.
The way I understand it, the only real reason why there is something like javascript at all is that one wants to improve latency / computing load on servers. But since javascript is already here, it is now easy to abuse it instead by cluttering all kinds of junk and computing to the page and to the browser / client.
You should make a more thorough comparison with other "100% open source" forges. Your main arguments against GitHub and the like are the license, tracking, and ads. Instead, you make no good arguments for why this tool is so "special" compared to other equivalently free tools. I'm not trying to be a jerk here, but the post looked like a hard sell to me.
I see for now there's only package repositories for Alpine and Arch (https://man.sr.ht/packages.md), any plans to expand this list any time soon?
(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)
(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)
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.
I love that you are able to support FreeBSD but Travis CI couldn't even be bothered. Is there support for Windows as well?
No, for the time being I'm only adding free (as in freedom) operating systems. In the future you'll be able to upload custom build images.
Have you considered adding a docker image repository similar to Dockerhub to the ecosystem?
Alternatively, have you considered contacting the folks at dockerhub and request integration similar to GitHub [1]?
[1]https://docs.docker.com/docker-hub/github/
Alternatively, have you considered contacting the folks at dockerhub and request integration similar to GitHub [1]?
[1]https://docs.docker.com/docker-hub/github/
This was discussed here: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CFA9122A8-8BD1...
Thank you!
This sounds too good to be true. Who's funding this project?
Hi, I made sr.ht. The users are funding it! There's some information about this here:
https://man.sr.ht/billing-faq.md
https://man.sr.ht/billing-faq.md
Thanks, I also found this information in the site: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3C2018071822544...
It seems a fresh revenue model after so much the-user-is-the-product models. Here's is to your success!
It seems a fresh revenue model after so much the-user-is-the-product models. Here's is to your success!
Thank you!
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.
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:
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 :)
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 :)
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.
Love the idea that of contributors being eligible for free access!
This is impressive. The level of thinking that you’ve put into this project is totally amazing. Kudos.
This is amazing! Just what I was looking for! I love this project, thanks a lot for this!!
Browsing from mobile so not easily able to poke around, hence pardon my ignorance, but what is meant by “software forge”? Is this common terminology? I haven’t heard it before. Initially I assumed this was some sort of web-based IDE, but I guess it’s more of a source control, continuous integration, devops, and deployment system? Is it like Github meets Jenkins meets Jira? It might be valuable to have a more clear overview message on the site.
Edit: The actual project homepage has a much better overview of what this is, sorry for my initial cluelessness. The more I look into it, the more impressive it looks, thanks for the great open source contribution!
Edit: The actual project homepage has a much better overview of what this is, sorry for my initial cluelessness. The more I look into it, the more impressive it looks, thanks for the great open source contribution!
It's a catch-all term for projects which fill the same niche as SourceForge, including GitHub, BitBucket, Gitlab, gogs & gitea, and so on.
>The more I look into it, the more impressive it looks, thanks for the great open source contribution!
I'm glad you like it :)
>The more I look into it, the more impressive it looks, thanks for the great open source contribution!
I'm glad you like it :)
Wow.
I've only glimpsed at some parts, but I'm really liking what I'm seeing! I also love the look and feel.
I look forward to doing deep dive the next few days and looking to contribute anyway I can.
I look forward to doing deep dive the next few days and looking to contribute anyway I can.
Hey, this is pretty neat!
One quick bit of feedback: In the audit log, I noticed oauth tokens being issued even though I didn't recall granting any. I had a moment of pause worrying I was breached until I realized it was the various sr.ht services requesting the tokens. It would be cool if there was something to map the client ids to the names of the different services in the audit log.
Anyway, thanks for building this service. Like other's have already said, it's cool to see a useful dev-focused tool from within the community.
One quick bit of feedback: In the audit log, I noticed oauth tokens being issued even though I didn't recall granting any. I had a moment of pause worrying I was breached until I realized it was the various sr.ht services requesting the tokens. It would be cool if there was something to map the client ids to the names of the different services in the audit log.
Anyway, thanks for building this service. Like other's have already said, it's cool to see a useful dev-focused tool from within the community.
Thanks! I should hide internal oauth tokens from the audit log. I'm glad you like sr.ht!
This is a very cool project, and I'm interested in using it for some of my private repos.
Some thoughts:
* Thanks for adding support for 2FA via OTPs, this is a requirement for me
* Access control is a little weird. I start without any users having access, but I can push to the repository. I can then add myself as "ro", and still push. I know this is an edge case but wanted to raise it
* I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
Some thoughts:
* Thanks for adding support for 2FA via OTPs, this is a requirement for me
* Access control is a little weird. I start without any users having access, but I can push to the repository. I can then add myself as "ro", and still push. I know this is an edge case but wanted to raise it
* I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
>I can then add myself as "ro", and still push. I know this is an edge case but wanted to raise it
Thanks: https://todo.sr.ht/~sircmpwn/git.sr.ht/128
>I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
The 502's are a bug, rather than a scaling issue. git.sr.ht seems to have a memory leak, which I'm investigating. Are you logged out as you browse between different subdomains? There's a ticket for logging you into everything at once, but for now you have to click "login" on every sub-site.
Thanks: https://todo.sr.ht/~sircmpwn/git.sr.ht/128
>I keep getting logged out while navigating through pages, though I'm guessing this is related to the 502's I'm getting occasionally (HN Effect)
The 502's are a bug, rather than a scaling issue. git.sr.ht seems to have a memory leak, which I'm investigating. Are you logged out as you browse between different subdomains? There's a ticket for logging you into everything at once, but for now you have to click "login" on every sub-site.
> Are you logged out as you browse between different subdomains?
This is probably it. Clicking "login" logs me right back in. The move between the subdomains is very smooth, so I did not even notice. Thanks!
This is probably it. Clicking "login" logs me right back in. The move between the subdomains is very smooth, so I did not even notice. Thanks!
I still prefer the GitLab UI for viewing project files, cgit style seems a bit "old-fashioned" to me.
Other then that I'm quite interested how this is going to look long term.
Other then that I'm quite interested how this is going to look long term.
> average page weighing less than 10 KiB, with no tracking and no JavaScript.
Good Lord, I had a visceral reaction to that. (It was like the opposite of the urge to throw up.)
Good Lord, I had a visceral reaction to that. (It was like the opposite of the urge to throw up.)
This is great ! I just subscribed for a year. Just what I needed to keep track of my current project.
All I wish for is a budget software built in :)
It reminds me of NearlyFreeSpeech.net in a good way !
All I wish for is a budget software built in :)
It reminds me of NearlyFreeSpeech.net in a good way !
It looks great and the minimalistic UI is a welcome breath :)
Could you share any details on how you implemented the build system? Are you running of different public cloud providers or are you using something different? Your announcement speaks about KVM so it looks like you implemented something yourself but I guess the cost and performance could easily become difficult to manage, so I'm curious how do you back this system :)
Could you share any details on how you implemented the build system? Are you running of different public cloud providers or are you using something different? Your announcement speaks about KVM so it looks like you implemented something yourself but I guess the cost and performance could easily become difficult to manage, so I'm curious how do you back this system :)
I built it all from scratch, and I host it on dedicated machines colocated in Philadelphia, with backup facilities in SF. It's pricy for the current scale, but as it scales will become very price effective.
This looks fantastic! One feature I would like to see in a service like this would be support for custom domains. Personally, I would be willing to pay extra for such a feature. It’s nice to have control of the domain for personal work, but self hosting for a handful of personal projects is a big ask - I would rather pay for someone to do it the right way.
Thanks for your feedback! This is definitely something I'm interested in adding in the future. I don't think I can prioritize it right now, because I have limited time to spend on sr.ht (I still have a day job), but I want to tackle it post-alpha.
Thanks for the response! I would definitely imagine a feature like this coming later on. Just signed up at $20/yr, and I hope everyone reading this does too... sr.ht is something that desperately needs to exist!
Drew, please keep doing phenomenal work.
Other stuff I'd love to see once sr.ht is more mature would be nice, clean, UNIX-ey alternatives to GitHub Pages and github.io. I'll be looking forward to OpenBSD support, especially for running CI jobs on as well.
Drew, please keep doing phenomenal work.
Other stuff I'd love to see once sr.ht is more mature would be nice, clean, UNIX-ey alternatives to GitHub Pages and github.io. I'll be looking forward to OpenBSD support, especially for running CI jobs on as well.
Great, thanks for your support! I definitely intend to implement something similar to GitHub pages, but even more powerful - how about using any static site generator you want? OpenBSD support is also coming soon!
> how about using any static site generator you want?
That would be excellent. I have my own solution[1]... being able to have everything built with a CI job on one platform would be great!
1 - http://cdaniels.net//2017-11-22_make-static-site.html
That would be excellent. I have my own solution[1]... being able to have everything built with a CI job on one platform would be great!
1 - http://cdaniels.net//2017-11-22_make-static-site.html
Awesome! Check out how I currently deploy my blog:
https://builds.sr.ht/~sircmpwn/drewdevault.com
https://builds.sr.ht/api/jobs/10416/manifest
If you already have a server to host the static content on, you can use this today.
https://builds.sr.ht/~sircmpwn/drewdevault.com
https://builds.sr.ht/api/jobs/10416/manifest
If you already have a server to host the static content on, you can use this today.
This is the type of project announcement that gets me excited to work on my own open-source efforts. Congrats Drew, this is great.
Having an OAuth error. I'll check back later because maybe you're messing around with it at the moment. Cool project.
I was about to say the same. I'm able to login at meta but not the others. Admittedly I haven't paid yet so I thought that might have been the culprit.
This service looks promising, but it is unfortunate that we have to go as barebones as 'no javscript' to convince people that they are not doing any malicious tracking. Javascript is becoming inevitable and some service/company that helps us trust a site's javascript will be most welcome in the future.
Sweet, I was complaining about how I'd like to have a bundle like that some days ago https://news.ycombinator.com/item?id=18423984
My feedback:
Don't change the order of the header for each page
Don't change the order of the header for each page
dispatch
lists
git
builds
todo
man
meta
Trying to register, and got a 403:
Forbidden
You don't have the permission to access the requested resource. It is either read-protected or not readable by the server.
Same here. I'll try later in the morning. Looks too nice to let it go.
I've always wished this to be open sourced. Oh man I'm glad there is no javascript nonsense, overall design is great. Thank you so much for opening this beauty :)
Will we be able to selfhost it on our own infra?
I didn't happen to see install instructions for dispatch on that page. Is that an oversight or is dispatch a component of builds.sr.ht?
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.
Very cool. Thanks!
Thank you so much for open sourcing the whole thing!
I wouldn't have it any other way :)
[deleted]
Ya, I believe so.
> You’re welcome to install it on your own hardware, and detailed instructions are available for those who want to do so.
Beware the AGPL on some components, though. You may want not to make a business whose business model revolves around adding features to sr.ht.
I'd be happy if my business contributes to a foss software and builds on top of it. I'm all against closed source.
Hi Drew -- awesome job! I want to migrate my projects there. Do you plan on supporting static sites a la GitHub pages?
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.
Wow. Excellent. What serves drewdevault.com -- sr.ht itself?
It's just running on my personal infrastructure. In the future there will be a place to host it on sr.ht.
Man I love this idea - signed up. But I've been getting 502s consistently, HN "Hug of Death"?
It's a memory leak in git.sr.ht, rather than an issue of scale, thankfully. I'm working on it. After a few refreshes you should get through, and the problem is isolated to git.sr.ht in particular.
Got a 502 just now on my first attempt to log in to git.sr.ht after signup. Second attempt was fine.
It would be nice if you could tap the red header text and move to a different module.
That's something I'll bookmark. Do you plan on including 2FA?
TOTP is supported.
Looks great, nice work! Registered my account, bill_barnhill.
This looks fantastic. Well done!
How well does it work with teams?
How well does it work with teams?
no github like social features=how is this a hacker's tool?
hackers always collab frequently with anons
hackers always collab frequently with anons
great work,thanks for you to open source
>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.
You have my attention!
You have my attention!
Server side html rendering will always be less efficient, but I can see the application of using curl to request and parse pages.
You mean more efficient, right? Because the single page "applications" that download UI and data with javascript take a three-digit number of requests and multiple seconds to render everything and be "done".
No, because once you download the js you don't redownload it on every page request. When you want to update contents you get the new data to be displayed. This is how any other gui application does server communication.
The traditional page based responses re-send all the html content over again. If the client can cache it then it doesn't have to be, but caching something like a git frontend does not work with page based responses due to the amount of new data.
Just because Facebook and Google abuse js to the nth degree does not mean it's automatically bad. It's how you use it, and you can infact do things without react and Vue.
The traditional page based responses re-send all the html content over again. If the client can cache it then it doesn't have to be, but caching something like a git frontend does not work with page based responses due to the amount of new data.
Just because Facebook and Google abuse js to the nth degree does not mean it's automatically bad. It's how you use it, and you can infact do things without react and Vue.
When most of the web looks like this: https://news.ycombinator.com/item?id=17655316
I'm happy about Drew's decision to not include JS.
I'm happy about Drew's decision to not include JS.
As I just stated, you don't need to have 1MB of JS to do things, it's that software companies typically do it because they're about actually providing a service and solving problems than worrying about non-issues such as 1 second more of initial download time.
This is 2018. You don't have a 56K modem, I don't have one. Those that do will benefit from smaller data requests after the initial download. Holding back the real issues the web can solve over an arbitrary problem like that is damaging to what can be achieved.
The web is a software platform, and unless you want to equally complain about applications in C that go over 1MB, you're making mountains out of mole hills.
This is 2018. You don't have a 56K modem, I don't have one. Those that do will benefit from smaller data requests after the initial download. Holding back the real issues the web can solve over an arbitrary problem like that is damaging to what can be achieved.
The web is a software platform, and unless you want to equally complain about applications in C that go over 1MB, you're making mountains out of mole hills.
[deleted]
The word “distributed” does not appear in the announcement telling me everything I need to know about not using it
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)