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.
- 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.
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.
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'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
- 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
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:
Not interested in this for the time being, it's pretty fast without.
Thanks so much for your support!
I hate being THAT guy, but would you consider trying 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.
 This obviously also depends on the other contributors, so you might not want to bother with the effort.
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.
> 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.
> GPL v2, without the "any later version" clause (sorry FSF, I don't want to accept licences you didn't even write yet).
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)!
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.
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.
> 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?
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.
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.
Azure DevOps pipelines are really capable, with a great UI - I'd love to see a side-by-side comparison?
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?
My plan is to parse these discussions using this library my friend made:
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?
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.
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:
>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?
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.
>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.
Indeed looks like it covers my needs. Thanks!
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.
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
(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)
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.
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.)
One intriguing thing about sr.ht is the way builds.sr.ht is described: amazingly powerful . 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.
: By approximation, some projects hosted on GitHub have more specific rules and will not consider those who deviate.
Also happy to see more aliens here appreciating brutalist aesthetics :-)
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.
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.
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'
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).
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.
I'm glad that you like everything else :)
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.
Small ux thing; the nav bar on top are different for every subdomain. Probably easier to navigate if the elements are in fixed positions.
They're ordered by the time you accessed each last. I agree that this is, in retrospect, unintuitive and poorly designed. Will be reverting it soon enough.
Was very confused by the changing order.
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:
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.
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..
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.
<meta id="refresh" http-equiv="refresh" content="5">
The script you found removes it and does it a different way so it can scroll to the bottom. Optional progressive enhancement.
(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)
Alternatively, have you considered contacting the folks at dockerhub and request integration similar to GitHub ?
It seems a fresh revenue model after so much the-user-is-the-product models. Here's is to your success!
Thanks for your work for the FLOSS community, btw. I've got one machine running Sway and I might start using sr.ht.
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 :)
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!
>The more I look into it, the more impressive it looks, thanks for the great open source contribution!
I'm glad you like it :)
Thanks for sr.ht!
I look forward to doing deep dive the next few days and looking to contribute anyway I can.
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 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 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.
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!
Other then that I'm quite interested how this is going to look long term.
Good Lord, I had a visceral reaction to that. (It was like the opposite of the urge to throw up.)
All I wish for is a budget software built in :)
It reminds me of NearlyFreeSpeech.net in a good way !
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 :)
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.
That would be excellent. I have my own solution... 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
If you already have a server to host the static content on, you can use this today.
Don't change the order of the header for each page
How well does it work with teams?
hackers always collab frequently with anons
You have my attention!
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.
I'm happy about Drew's decision to not include JS.
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.