16 ms·

Like many others I too admire Drew's work. But one thing I appreciate the most is the visual style and usability of Sourcehut. I don't know what it is exactly (

by omdv 6y ago

Like many others I too admire Drew's work. But one thing I appreciate the most is the visual style and usability of Sourcehut. I don't know what it is exactly (am not a UX or visual designer myself, although work with them a lot), but to me it is one of the most aesthetically appealing sites I visit.

lhorie 6y ago
I find the text a bit hard to read (and it seems at least one other commenter mentioned the compressed line-height). What I do notice is that the site loads very fast (sub-1s w/ cache disabled via devtools to simulate first visit, and sub-50ms otherwise). That alone deserves big props.
- deleted 6y ago
  [deleted]
- Scarbutt 6y ago
  some heavy caching is happening somewhere.
  - ddevault 6y ago
    No caching (except for the CSS file, which your browser is probably caching), just simple pages and lightweight backends. https://forgeperf.org https://forgeperf.org All of our pages are done in 2 requests, or 1 with a warm cache.
    - deleted 6y ago
      [deleted]
    - Hello71 6y ago
      I was going to ask how you speed up pygments so much, but apparently the answer is "actually, some stuff is cached".
      - ddevault 6y ago
        Ah, yes, some stuff is cached :) but it doesn't do much, we kind of cache it on principle. An example that makes more of a difference is the git SSH pipeline.
- ddevault 6y ago
  I am very proud of our performance :) https://forgeperf.org/ https://forgeperf.org/
  - mappu 6y ago
    I think Codeberg.org is not doing the (normally very fast) Gitea any favors here, because it's hosted on Hetzner in Germany. Lighthouse may only throttle the connection further. Where are the tests being run from? Is there any way to control for network latency (maybe subtract the ICMP rtt from the tests?) You might consider comparing it to other Gitea instances like https://try.gitea.io/ https://try.gitea.io/ (Digital Ocean / USA), https://mirror.git.trinitydesktop.org/ https://mirror.git.trinitydesktop.org/ (Czech Republic) or https://gitea.com/ https://gitea.com/ (China), but I guess Codeberg is probably the most representative instance for public use.
    - ddevault 6y ago
      This has been brought up many times, but latency and bandwidth is controlled for with Lighthouse. The same tests have also been run from Germany without appreciably different results. It's also easy to run the test suite yourself if you have an hour of compute time to spare: https://git.sr.ht/~sircmpwn/forgeperf https://git.sr.ht/~sircmpwn/forgeperf The goal here isn't to compare forge software (that would require a completely different approach to level the playing field), but to compare hosted options. The test suite is easily extended with other hosts or pages, and a few people have tested against their own Gitea instance - usually it ranks somewhere just above the middle of the pack.
- kick 6y ago
  Line-height on Sourcehut itself is reasonable. It's just on the blog that it's off.
girzel 6y ago
I feel the same way, and as someone who has struggled to make his open source projects look like anything other than roaring garbage, I am perplexed, and jealous, and guess somehow a little hopeful? I can totally imagine making something like Sir Hat (sorry) a part-time project and, in an alternate universe where I am a better coder and more dedicated than I actually am, producing something super solid after a few years. I cannot, however, imagine any universe in which I would produce something that looked as good as this. I recommended it to the Emacs developers (who are considering moving to some sort of forge-alike site) in part because it seems to fit the FSF's principles, but more because the aesthetics are what Emacs should aspire to: plain text that looks good.
- kick 6y ago
  What exactly do you think is so revolutionary about its design? I love it, personally, but I love it because it's not revolutionary. It takes some basic design principles and sticks to them militantly, which is sort of how Drew seems to handle everything. It's a successful approach. Some tips: If you're going for a flat look (which you should), don't go the Google direction. * Make it actually flat; no shadows. Shadows are your enemy. Only use shadows if absolutely necessary, and even then think twice. * Use solid lines to separate buttons and other colorful objects from the page. This is more accessible than shadows, and looks pretty instead of Google's weird 2014 pseudoskeuomorphism. Use accessible colors! * You have no excuse for using a color scheme that isn't accessible; accessible color schemes generally work better for people who aren't design-inclined, anyway. * There are a bunch of sites you can use to check whether a color scheme is accessible, and there are also a bunch that have a bunch of accessible color schemes already laid out for you. * Do not believe yourself when trying to justify an inclusion of a pretty color that makes the site less accessible. I know the color is pretty. There are a lot of colors that won't make the site harder to view, though! Don't break from your design. Ever. * Nobody likes using an application that has seven different styles of interaction and looks like it's from three different eras depending on the page you're on.
  - indymike 6y ago
    There's some really good advice right here: Take some basic design principles and stick to them
Polylactic_acid 6y ago
I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a list of branches and I had to click through every tab until I landed on "refs" that had it. What does refs mean? I assume its some internal git terminology but why not just call the tab branches. I then went to find out where I could submit a PR/MR and I couldn't find any such feature. I also couldn't find a list of bugs or how to open one. I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.
- ddevault 6y ago
  The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology. SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way: https://man.sr.ht/ https://man.sr.ht/ There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started: https://git-send-email.io https://git-send-email.io If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.
  - thayne 6y ago
    > There are no pull requests or merge requests. We use email, which is how Git was designed to be used. I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has: - Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky. - Ability to search by tags/labels - Automatic linking between related issues and pull requests (with backreferences) - The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list. - Highlighting changes in the diff (source hut actually does this) I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.
fluffything 6y ago
I used some of their work, so I'm forever indebted to them. However, I don't like how they treat users, potential contributors, etc. Like, I started using sway full time, posted a question, started looking at the source code to fix it myself, and then just ended up fixing it for my fork and never pushing it upstream because the main thing I learned through my questions was that my free time is to valuable to deal with them. Maybe 30 years ago the badge of being able to contribute to open source even though the maintainers are "super tough" meant something. But it's 2020: I want to do things in my free time that make me happy, I want to learn something while contributing to open source, and ideally learn from those who know more than me. So I'd rather just continue contributing to Rust, where everybody is super nice, those who know more teach and mentor those who know less, and in general the community is super open and reflective (e.g. the attitude is not "how come you didn't know this" but rather "which mistake did _we_ make that led you here without learning this along the way"). To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence. This attitude is super harmful. Drew is just one person, and they can only do so much, and that does reflect on Sway, which is why I ended up switching back to i3.
- enriquto 6y ago
  > However, I don't like how they treat users, potential contributors, etc. What are you talking about? The mailing lists are super friendly.
  - fluffything 6y ago
    I only interacted with them on Github issues in the sway repo. The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]". Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange. At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind.... Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.

by omdv 6y ago

lhorie 6y ago

I find the text a bit hard to read (and it seems at least one other commenter mentioned the compressed line-height). What I do notice is that the site loads very fast (sub-1s w/ cache disabled via devtools to simulate first visit, and sub-50ms otherwise). That alone deserves big props.

deleted 6y ago
[deleted]
Scarbutt 6y ago
some heavy caching is happening somewhere.
- ddevault 6y ago
  No caching (except for the CSS file, which your browser is probably caching), just simple pages and lightweight backends. https://forgeperf.org https://forgeperf.org All of our pages are done in 2 requests, or 1 with a warm cache.
  - deleted 6y ago
    [deleted]
  - Hello71 6y ago
    I was going to ask how you speed up pygments so much, but apparently the answer is "actually, some stuff is cached".
    - ddevault 6y ago
      Ah, yes, some stuff is cached :) but it doesn't do much, we kind of cache it on principle. An example that makes more of a difference is the git SSH pipeline.
ddevault 6y ago
I am very proud of our performance :) https://forgeperf.org/ https://forgeperf.org/
- mappu 6y ago
  I think Codeberg.org is not doing the (normally very fast) Gitea any favors here, because it's hosted on Hetzner in Germany. Lighthouse may only throttle the connection further. Where are the tests being run from? Is there any way to control for network latency (maybe subtract the ICMP rtt from the tests?) You might consider comparing it to other Gitea instances like https://try.gitea.io/ https://try.gitea.io/ (Digital Ocean / USA), https://mirror.git.trinitydesktop.org/ https://mirror.git.trinitydesktop.org/ (Czech Republic) or https://gitea.com/ https://gitea.com/ (China), but I guess Codeberg is probably the most representative instance for public use.
  - ddevault 6y ago
    This has been brought up many times, but latency and bandwidth is controlled for with Lighthouse. The same tests have also been run from Germany without appreciably different results. It's also easy to run the test suite yourself if you have an hour of compute time to spare: https://git.sr.ht/~sircmpwn/forgeperf https://git.sr.ht/~sircmpwn/forgeperf The goal here isn't to compare forge software (that would require a completely different approach to level the playing field), but to compare hosted options. The test suite is easily extended with other hosts or pages, and a few people have tested against their own Gitea instance - usually it ranks somewhere just above the middle of the pack.
kick 6y ago
Line-height on Sourcehut itself is reasonable. It's just on the blog that it's off.

girzel 6y ago

I feel the same way, and as someone who has struggled to make his open source projects look like anything other than roaring garbage, I am perplexed, and jealous, and guess somehow a little hopeful? I can totally imagine making something like Sir Hat (sorry) a part-time project and, in an alternate universe where I am a better coder and more dedicated than I actually am, producing something super solid after a few years. I cannot, however, imagine any universe in which I would produce something that looked as good as this. I recommended it to the Emacs developers (who are considering moving to some sort of forge-alike site) in part because it seems to fit the FSF's principles, but more because the aesthetics are what Emacs should aspire to: plain text that looks good.

kick 6y ago
What exactly do you think is so revolutionary about its design? I love it, personally, but I love it because it's not revolutionary. It takes some basic design principles and sticks to them militantly, which is sort of how Drew seems to handle everything. It's a successful approach. Some tips: If you're going for a flat look (which you should), don't go the Google direction. * Make it actually flat; no shadows. Shadows are your enemy. Only use shadows if absolutely necessary, and even then think twice. * Use solid lines to separate buttons and other colorful objects from the page. This is more accessible than shadows, and looks pretty instead of Google's weird 2014 pseudoskeuomorphism. Use accessible colors! * You have no excuse for using a color scheme that isn't accessible; accessible color schemes generally work better for people who aren't design-inclined, anyway. * There are a bunch of sites you can use to check whether a color scheme is accessible, and there are also a bunch that have a bunch of accessible color schemes already laid out for you. * Do not believe yourself when trying to justify an inclusion of a pretty color that makes the site less accessible. I know the color is pretty. There are a lot of colors that won't make the site harder to view, though! Don't break from your design. Ever. * Nobody likes using an application that has seven different styles of interaction and looks like it's from three different eras depending on the page you're on.
- indymike 6y ago
  There's some really good advice right here: Take some basic design principles and stick to them

Polylactic_acid 6y ago

I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a list of branches and I had to click through every tab until I landed on "refs" that had it. What does refs mean? I assume its some internal git terminology but why not just call the tab branches. I then went to find out where I could submit a PR/MR and I couldn't find any such feature. I also couldn't find a list of bugs or how to open one. I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.

ddevault 6y ago
The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology. SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way: https://man.sr.ht/ https://man.sr.ht/ There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started: https://git-send-email.io https://git-send-email.io If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.
- thayne 6y ago
  > There are no pull requests or merge requests. We use email, which is how Git was designed to be used. I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has: - Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky. - Ability to search by tags/labels - Automatic linking between related issues and pull requests (with backreferences) - The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list. - Highlighting changes in the diff (source hut actually does this) I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.

fluffything 6y ago

I used some of their work, so I'm forever indebted to them. However, I don't like how they treat users, potential contributors, etc. Like, I started using sway full time, posted a question, started looking at the source code to fix it myself, and then just ended up fixing it for my fork and never pushing it upstream because the main thing I learned through my questions was that my free time is to valuable to deal with them. Maybe 30 years ago the badge of being able to contribute to open source even though the maintainers are "super tough" meant something. But it's 2020: I want to do things in my free time that make me happy, I want to learn something while contributing to open source, and ideally learn from those who know more than me. So I'd rather just continue contributing to Rust, where everybody is super nice, those who know more teach and mentor those who know less, and in general the community is super open and reflective (e.g. the attitude is not "how come you didn't know this" but rather "which mistake did _we_ make that led you here without learning this along the way"). To me sourcehut is just a fence that keeps the kind of maintainers I don't like at the other side of the github fence. This attitude is super harmful. Drew is just one person, and they can only do so much, and that does reflect on Sway, which is why I ended up switching back to i3.

enriquto 6y ago
> However, I don't like how they treat users, potential contributors, etc. What are you talking about? The mailing lists are super friendly.
- fluffything 6y ago
  I only interacted with them on Github issues in the sway repo. The interaction was of the form: "I'm having this problem, I've looked at this, what would be the best way for me to improve this". Reply from Drew "No [issue closed]". Then using sway, I ran into a lot of problems, and many of them were already reported, but closed issues, which closed with a similar exchange. At some point, every time I had a sway problem, I would search for my issue on Github with the closed filter first. Finding those issues, with no rationale, workarounds, path forward, discussion of any kind.... Yeah, I just stopped using sway a while after and went back to i3. It at least worked, so I never had to interact with their community.