I recently contributed to a project hosted on sr.ht for the first time. It took some getting used to. I can see the potential, but there are some sharp edges.
The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.
I generally recommend setting up a separate email client for development, and I recommend one I wrote myself for this purpose: https://aerc-mail.org. You don't have to stop using your primary mail client to incorporate a second one into your workflow. Just think of the patches as notification emails in your normal inbox, and then something like aerc as a domain-specific tool. Over time I bet you'll find yourself opening aerc more and thunderbird less, though ;)
We're also working on web-based tools for this workflow, which allow you to create patchsets, respond to feedback, and review them entirely from the web, but these are still WIP. You can submit patchsets and view discussions on the web today, and the rest of the tools are WIP.
Powerful continuous integration
- Runs fully virtualised builds on various Linux distros and BSDs
- Submit ad-hoc jobs without pushing to your repository
- Post-build triggers for email, webhooks, etc
- Log in with SSH after build failures to investigate further
Submitting jobs without pushing and logging in after failed builds are two features that I didn't know I wanted. But now that I see them, I really want them.
Somewhat related to this thread: a frustration I have with most CI systems is how hard it can be to reproduce the run locally using (ideally all of the) same configuration.
For example, Gitlab CI has a local runner but it's not really first class, definitely isn't kept up to date with the real runners. It seems like it's more of a recreation of a job system based off of (an older version of) Gitlab CI configuration files.
Circle CI has a more decent story around this if I remember correctly. But first-class support for local reproduction of CI runs is the kind of thing I'd like to see as table stakes today.
It can be challenging to debug certain things in the live CI system for developers without being able to recreate locally (otherwise you have to bring in the team that manages the CI system to help them debug with you which takes time).
The trick is to do as much as possible outside the CI system. Ideally, each step should just call a single script, Makefile command, or your language's build tool equivalent.
That gets deeply complicated where integration or automation tests are concerned, and those types of tests provide the most value per effort in environments where test-authoring, QA, and refactoring time is limited.
>That gets deeply complicated where integration or automation tests are concerned
I don't understand why this would be true.
For $dayjob I've been writing end-to-end tests that run via GitHub Actions. Each test starts with a package of the compiled code (built by another GHA workflow), deploys a bunch of cloud resources including a VM, scp's the package to the VM, and ssh's to the VM to install the package and run the test. The package contains multiple services that must be individually configured based on the particular test, and then a test process interacts with these services in a bunch of ways. I think we can agree these are complicated tests; they're not just unit tests you can run in a Docker container and be done with (which we also have, of course).
Now, these tests are written entirely in a shell script. It has been designed from the start that a developer can run the script locally and get exactly the same result as when GHA runs it. The things like auth tokens for the cloud are read as environment variables, so when running as a GHA workflow the env vars are hooked up to repository secrets, but when running locally the developer can just provide their own auth token via env vars to the script. Furthermore, the script cleans up the cloud resources when it finishes, but if the developer wants to investigate the failure they can just comment out the cleanup step from the script.
I'm sure there are third-party GH Actions to create those cloud resources, to scp files to remote targets, and to run commands via ssh against remote targets. But using those actions not only removes the ability to run the tests locally, it also requires learning arbitrary DSLs ("How does this action take parameters? What limitations does it have? How do I process the output of one action to be the parameter of the next? How do I parallelize these two actions that don't need to run in series?") and introduces third-party code that you have to trust with your cloud auth token.
I've found it pretty easy debug GitLab CI issues. You know the docker image, so you can create the environment locally. You then need to concat the scripts together.
Local CI is very important to quickly solve failed runs.
The problem is that we need a ton of logic in the coordinator. For example on how to do matrix builds. For local builds to be perfectly similar we would have to recreate that logic inside the runner. This is hard, not in the least because it are different programming languages.
They are not talking about manual triggers. afaik, and correct me in I'm wrong, I have to write a commit and push yaml file to the repo to be able to run the pipeline. On srht's builds on the other hand I can submit a yaml file by itself to start a job. That way when setting up the build you don't have to go through the whole edit/commit/push cycle.
I think the most consequential difference is that sourcehut is built on top of existing tools for distributed development with the goal of avoiding lock-in. Instead of replacing the distributed tools traditionally used in FLOSS development (mailing lists, patches) with centralized ones (issue tracker, pull requests), the goal is to provide an interface that makes it easier to use the tools of the distributed model.
I have known that development of linux, git was done over email, And always wondered how PR worked there, but I never took time to know how actually it was done.
For someone like me this[0] looks like a good start.
The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA.
The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see nixos/nixpkgs) because it does not allow horizontal scaling at all - thousands of "PRs" open, nobody feeling responsible and slowdown overall.
Having a tool that provides only an "overlay" over the workflow git wants to be used with, and that's what sourcehut is, but not a replacement for it (which is what github is), is refreshing and promising!
> The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA.
Welp, that puts me off using it entirely sadly. I hate dealing with mailing lists and refuse to contribute to any project that requires dealing with text patches in 2020. Like it or not, the pull request model is simply easier to deal with and is easier for new users to use.
The pull request model is not easier to use, you just already know how to use it. Anyone who maintains a large enough GitHub project can attest that there are many people who don't grok GitHub pull requests, either.
If you prefer to use a web-based workflow, then you can both prepare and review patches on our web UI, and they're automatically sent as emails. You don't actually have to interact with email directly at all.
And, once you're used to it, pretty much everyone who uses email can assure you that it's much easier to use, much more efficient, and much more scalable than pull requests.
No, it's not unfamiliarity, I have had to use email to manage and submit patches before, and hated it. This just stinks of doing things the old way in cargo cult like fashion. This whole approach, some development in email, some on the web, and some on a disused IRC channel is exactly why projects like Cairo suffer from lack of contributions. Do people really want to deal with text patches in 2020? I appreciate the back-to-basics approach and aesthetics, but srht just seems to be throwing out the baby with the bathwater.
>is exactly why projects like Cairo suffer from lack of contributions
I don't really agree with this. Many projects enjoy a vibrant development community on mailing lists today. Cairo suffers from different issues - and ultimately in Cairo's case it doesn't really matter. Cairo has been "done" for years, it's not the end of the world if it doesn't see much activity.
>Do people really want to deal with text patches in 2020?
Yes. You'll find many of them in this very thread. SourceHut is a brand-new service, only around for 2 years in alpha, and in 2020 alone it transacted 37,000 emails. There's obviously demand here.
One thing that can matter a lot if you're trying out the email workflow is making sure you're using a good client. I made one that I recommend as such: https://aerc-mail.org. Other good choices include mutt and alpine.
Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens?
Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one?
These are some of the killer features of the PR/MR Github/Gitlab workflows.
>Can you comment on individual lines of a changeset in an email and reply to such comments separately, and then see such conversations in the context of the diff? And then mark them as resolved when that happens?
Yes, except for the last bit. Unlike GitHub/GitLab you can also respond to several comments at once.
>Can you read those discussions later in a "flat" presentation without scrolling through emails one-by-one?
Judging from my GitHub experience, I think they mean seeing, under each chunk of code, the whole conversation thread pertaining to that chunk. In other words, where a standard mailing list format looks like:
Person 1
> Chunk of code 1
Comment
> Chunk of code 2
Comment
Person 2
> Chunk of code 1
Comment
> Chunk of code 2
Comment
they want a view like:
Chunk of code 1
Person 1
Comment
Person 2
Comment
Chunk of code 2
Person 1
Comment
Person 2
Comment
Out of curiosity, do you have an example of what it looks like? (I checked several patches on https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches but couldn't find anything with line-by-line discussion.)
The issue is brought up repeatedly, but there's no real movement right this moment (or for the last several months, really).
There are several proponents of SourceHut thanks to its email-based workflows and (apparently?) LibreJS compatibility. But none are passionate enough to push for it, thus far, and do the work required.
As opposed to, say, advocates of Gitlab (which got effectively banned by a long list of requirements, alas).
Most projects on SourceHut don't receive anywhere near 10 patches per day. There are not any many large projects on sr.ht - established projects are slow to move off other platforms, and new projects haven't had a lot of time to gather steam. The top lists peak at like, 3 per day. What matters more is their volume: 1,447 of them were created in 2020.
For one, many corporate environments no longer directly tie email user identity and code user identity directly together, they frequently manage them thru a third service that both services connect to instead (e.g. OAuth, ActiveDirectory, etc).
This also only works well if you have: 1) one commit per change, 2) every reviewer has a fully up to date copy of any/all repos being reviewed, 3) a single change only affects a single repo.
The one-commit-per-change (squashed changes) is not always the preference, but it's effectively mandatory since the presentation format for patches only lends itself well to an isolated patch-diff and not a VCS history of changes (ironic since it's intended for the latter). As a great example of this, it's very difficult to compare the differences between the resulting code between two patches submitted to the same thread when I want to confirm a series of corrections to the original submissions were made properly and without side-effect.
Every reviewer having a fully up-to-date copy of the repo the changes are going into works amazingly well for a fully distributed VCS, defining the gatekeeping maintainer's copy as the ultimate source of truth for the "latest". When multiple maintainers for the repo exist, as in most corporate environments and the monorepo organization, this breaks down. The ultimate source of truth for "latest" is now a remotely hosted repository that no one individual gatekeeps. Therefore all maintainers need to constantly duplicate the remote copy and keep it up to date. Either the maintainer is an active developer that's also creating changes constantly and will therefore need to keep two different copies so they can be building and testing their own development changes while keeping a pristine copy purely for review purposes, or they don't usually do a lot of active development themselves and keeping a local copy at all is purely for the purposes of review. In terms of pushing proliferation of copies of the distributed VCS it works, but when more (but not completely) centralized as most corporate environments/users need it's an extra hurdle that impedes the process rather than helping.
For a single change to affect only a single repo requires at the extreme a monorepo layout, or an extremely well modularized design. As noted before, monorepo is very much against the design (few people should need a fully history copy of the entire repo locally with a monorepo, and many maintainers control the same repo) and defining sufficiently modularized breakdown is nigh impossible with larger projects. The Linux project is a great example of this problem, but has a semi-solution that involves having an even larger developer base involved at different levels of a heirarchy, and split repos for "modules" (independently maintained subcomponents or specialty areas) that have to manually cross-related. This is demonstrably problematic even now when a sub-area uses a separate repo and submits wholesale changes to the downstream project, losing almost all of the history and cross-linked-tracking information in so doing. Recognized as a common problem, the community has either gone the monorepo route where all changes go into the single larger repo at the cost of much greater coordination requirements, or the submodule-like route where each sub-part becomes more isolated but may have cross-cutting changes across multiple separate repos. As the repos proliferate in the latter case, individual maintainers often become responsible for a larger number of repos and the other two problems impact them more.
In summary, the mailing list solved a basic problem for a specific narrow use case at a time when technological constraints and solution options were very different than they are now. While the development/maintenance process can still be made to fit its usage, the large scale needs often no longer match, nor do the same technological restrictions apply. GitHub PRs aren't necessarily significantly better, but they do at least move the same concept to a place where an individual user/maintainer can keep their individual source of truth in one place (online), interact with it without needing a full development system/setup present, AND provides options for moving development processes in a new direction. The last has stagnated pretty badly, but throwing it out for a return to a system that has little to no options for modifying the process to meet modern needs seems overly agressive.
Where do I see all patches neatly organized in threads, ready to be open as a timeline feed? Anything that involves custom filters or scripting an e-mail client is not easier nor more efficient than a web UI made for purpose.
How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
These are just two off the top of my head. PRs as a code contribution approach can be improved upon, but mailing lists are not better at all for small projects and are only situationally better for bigger ones.
>Where do I see all patches neatly organized in threads, ready to be open as a timeline feed? Anything that involves custom filters or scripting an e-mail client is not easier nor more efficient than a web UI made for purpose.
>How do I make a minor adjustment to a patch as a response to feedback without resending the whole thing? Anything more complicated than git commit && git push to my remote clone is not easier nor more efficient than the status quo.
git commit && git push also re-sends the entire thing, assuming you rebased, and you should very definitely be rebasing.
That's a multi-purpose mailing list, where I had to read for a couple of minutes to assume belongs to the whole project sr.ht instead of a specific repo (I trusted your response to mean this was an actual 1:1 replacement and that I missed it), and I had to go into one of the patches and find a link to an issue in the tracker, and from there I had to go to the main page of that issue's project, and from there I see there's an ad-hoc association between the tracker and the actual repo by a link in the description which I assume you added because you noticed that it's useful to associate issue trackers and repos. And that's just for finding one of the repos that mailing list covers.
In the end, I still have to come up with custom filters to use to get only the patch requests for the specific repo I'm interested in, and assume everybody follows every single non-obvious instruction to the letter to make it all work.
The whole experience feels like a grabbing a bunch of general purpose tools and trying to get them to work for the project's purpose as well as possible, because there is no solution that solves the problem in obvious ways that doesn't require learning and carefully following a bunch of ceremony without failure. Except in this case, there are such solutions, and I'd have to be a sadist to try to get coworkers to learn and follow every single convention to the letter when they have problems just working well with git in the first place.
> git commit && git push also re-sends the entire thing
Which is not what I wanted, since even half-arsed PR implementations like Bitbucket's (let alone better ones like GitLab's) support dealing with direct feedback and changes that respond to them in a single PR.
> assuming you rebased, and you should very definitely be rebasing.
I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
I agree that it should be easier to find related resources, like the git repo a patch applies to. This is one of the issues prioritized during the alpha, and I'll ask for your patience and understanding that it doesn't represent an unfixable flaw - stuff like this is why we still have the alpha designation.
You can already filter by project, though. Here are all the git.sr.ht patches:
The feature is hinted at in the placeholder text on the search box.
>support dealing with direct feedback and changes that respond to them in a single PR.
Linking multiple versions of a patch together into one cohesive patchset is another thing which is possible in theory and prioritized for the alpha.
>I do, when working on feature branchs. But that's another nonintuitive thing to get people to unlearn and relearn. Which of course, also includes git send-email.
Well, for what little it's worth, you've convinced me to give sourcehut a try for a personal project where any of these shortcomings should not pose a problem.
You leave me thinking you actually give a shit about not leaving the average person behind and that ease of use is a priority. So if you can eventually couple the simplicity and performance you already have with slight changes to make the UI at least as obvious as GitHub to both programmers and students, then that's a winner. Just subscribed in hopes to seeing that happen.
What is "easier" about having to deal with github than your email?
Github has needed a non-web-app interface since 2007. It's good to see real competition and not just another clone of github's, erm, interesting design choices.
Github lets me instantly jump in and contribute to a project with an issue report without having to sign up to a mailing list. I hate mailing lists with a passion because they spam my inbox with rubbish.
Yes I know you can automate filtering them in to folders but that isn't simple to do when you self host email and use it across multiple computers because most filtering is done client side.
I also have one mailing list that seems to have messed up and I'm stuck on the list despite trying to unsubscribe a few times.
You don't have to sign up for most mailing lists to send an email to them. The default permissions for new lists on SourceHut allow postings from non-subscribers. It's very common to fire off a patch without subscribing.
It's not "an abomination of a workflow", and it's very possible for communities to have difficulties in scaling with a mailing list and have a bus factor of 1 despite plenty of movement on the mailing list.
Git also had a git-request-pull command that prepares a mail with the same information that you can find in a pull request on GitHub even before GitHub existed.
There is no "one true way" to Git and if organization to adapt their workflow to their needs they can have issues both with mailing lists and the centralised forge model.
Not a sourcehut power user myself but for me personally the user experience and aesthetics is way superior. The web client made me think about how tech directly relates to user experience, by having no javascript and minimal style means there's less chance to fuck up, everything is super responsive and simple, there are a lot of features but very well sorted and clear. Also I always prefer softwares that have a lead dev who I respect.
To put it another way, if I want to use the CI, then I can drag in sources from anyone. GitHub, GitLab, raw HTTP, etc. Multiple projects. Then build against not just the usual suspects, but also BSD.
If I want to open up an issue tracker without it being connected to any project, I can go ahead and do that. I can also make it frictionless and have user's without an account go ahead and open up/comment on issues.
And I can self-host each of these "modules" myself, with full documentation on how to do that.
The problem with open-core licenses is that you always have to weigh the risk of whether the feature you depend on will get pulled into the paid license, pegging you on a release forever without updates.
If you look at the direction of most popular products that are open-core, you have a spectrum from ElasticSearch (Slightly hobbled, the free x-pack features that you WILL use in production put you at risk of dipping into paid uses and in violation. running Amazon's fork/open distro is strictly better) to Neo4j (completely unusable in a production context without a paid, mega-expensive, cost-of-a-nice-house-per-year license. No clustering, can't be effectively monitored, none of the tuning knobs that you will need as your dataset grows).
Open-core licenses are entirely hostile to the spirit of OSS and just pay it lip service to delude the ignorant.
I haven't used them but I think the most important benefit is collaboration (sending pull requests etc...) is done via email and thus is less centralised platfomr than github/gitlab which uses their own mechanisms.
- The whole premise assumes that you need to make a new account for each project you contribute to, because they're hosted on individual gitea or similar instances. Some are, but let's be honest, the vast majority of projects are currently hosted on a very small set of services (github, gitlab, one or two others), and most developers will already have accounts on them.
(I get that part of the goal is to eliminate dependency on large code hosting services, and I agree with that. But we should do that with federation standards so people can use individual gitea/whatever instances without making accounts on all of them, not by traveling back in time 20 years.)
- He spends a lot of time complaining about silly password requirements. The complaint is valid but not relevant to the comparison.
- The graylisting thing is an own-goal, sorry.
- He complains that forking the repo and creating the PR require context-switching from the cli to the web and back, but there are cli tools that can fork repos and create PRs for you on github, gitlab, etc. to fix that.
- Let's allow that submitting a single patch, starting from outside the project, is faster for the contributor with an email workflow. But that's a tiny part of the process. There's a lot of things that happen after that patch: the project maintainers have to triage it, they have to review it, make comments on specific lines of the diff, or sometimes on line that aren't part of the diff, and then indicate that the submitter should make changes and try again. The submitter then has to make changes and submit it again. The reviewers, at that point, will probably want to see the diff between the first and second revision.
Triage: The github/gitlab UI for this is not great but acceptable. Viewing a mailing list in my email client mixes discussion and patches. I can't mark threads with labels or priorities. I can't assign a particular review to a particular person and have it show up in their todo list.
Review: Sure, you can reply to a patch posted on a list and intersperse comments, but web uis for code review are pretty decent these days. You can easily see much more of the context when required, your comments and replies on specific lines get threaded even across revisions of the code, each comment thread can have an individual "done" indicator, etc. The review as a whole has a global status of whose turn it is to take an action next. All of these seem much harder by email; you end up just using a lot of conventions.
You can use a web-based review tool with email-based patches, of course, but... why bother? If you're doing web-based review, just do the whole workflow there and it'll be a lot simpler and easier to understand.
Resubmit: Resubmitting a patch set by email posts brand new diffs. How do I see the differences between different versions of the patch? Sure, I can rig up a bunch of scripts to do this, but is it integrated with the review tool, etc.?
- What happens when I become a maintainer? I have to sign up for a new mailing list. And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI.
You can mark emails with labels though depending on your Email client. The onus is on you. SourceHut also supports adding labels to SourceHut tickets through email I believe.
You can assign a review to someone. You literally just CC them on the email.
> And that means I have to go in my email client settings, make a new folder, make a new filter rule to direct email from that list into that folder. That's a huge amount of friction that doesn't exist in the web-based workflows.
If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
> When that video was made, github CLI was not an official thing, and I have never even heard of a gitlab CLI.
I used "hub" back in 2013, so it's at least that old. It wasn't official, though I'm not sure why that makes any difference. Searching on google for "gitlab cli clients" shows a bunch, at least some of which have histories dating back to 2013.
> You can mark emails with labels though depending on your Email client. The onus is on you.
But those are local to you and your client. I'm talking about labels that are shared state, that the whole project and the public can see. Those are widely used on github for categorization, triage, communicating the stage of the review, etc. They're undeniably useful to teams. You can put all that information in English text in email bodies, but then everyone has to read a whole thread to understand the state of things, and there's more potential for confusion.
> You can assign a review to someone. You literally just CC them on the email.
Same thing: how do I assign a reviewer so that everyone can quickly and unambiguously see who is assigned to review that PR/patch set? With PR metadata, this is trivial. With mailing lists, it depends on social conventions.
> If that is a lot of friction for you, then you probably either have a horrible email client, or don't know how to use it.
Thank you for insulting my intelligence. I didn't say it's hard, I said that it adds friction.
I'm not claiming that the web-based PR and review UI works for everyone; obvious email works fantastically well for Linux (though I'm not convinced something else couldn't work even better). I do think it works very well for small to medium size projects (which are most projects, after all).
An accurate comparison of the strengths and weaknesses of each model would need to be much more thorough and look at the entire development cycle, for projects of different sizes. I don't agree that that video was anything like that. It seemed like a cheap shot, based on one cherry-picked metric (time to submit an initial patch starting from nothing) that's not particular representative.
To add to others' comments, another nice detail is that you can simply push to a non-existing repository to create it, rather than having to first create it through the web ui.
It gives you a link to click to confirm the new repository creation, or you can use git push options to set the visibility and description (git push -o visibility=public -o description="my cool repo")
1. Please don't do this. HackerNews is not the place to hurl empty insults.
2. I'm not sure if your intent was to insult Drew DeVault personally, or to insult the SourceHut project. Drew has given us no reason to doubt his competence, and SourceHut is already accepting payments. Neither sense of the word amateur applies here.
3. That's not what security-by-obscurity means. It would be a bad default, instead, but as Drew has since explained, it's not even that. Unless you explicitly request creation of a public repo, you won't get a public repo.
I really like the page design, very clear and non-flashy. Looks like time was well spent delivering features and good performance instead of building a "beautiful" page.
Do you really need anything else? To me the design is a feature itself. I don't need to load 1MB of stuff and run a heavy scripting language to display... text (of course that 1MB comes with complementary popups, banners, weird scrolling, autoplying videos, and stuff jumping around for 10s until the page loads entirely).
I, on the other hand, dislike this design. Consider how many devs use Apple products - proprietary products that come in a walled garden, and that in many ways go against developers. A good amount of it comes down to aesthetics. Were Sourcehut to have, say, a "2020 theme" or something, that would help lots of those devs appreciate it more.
Developers are using macOS despite it continually removing features from developers, and are even in some cases defending Apple's decisions. I believe that this design actively harms the adoption of Sourcehut. There are definitely other things Sourcehut should do if they want more of GitHub's and GitLab's marketshare, changing their UI (or adding an alternative UI) is an important part of that process.
FWIW I am attracted to Sourcehut's aesthetic exactly because it's not a "2020 theme", so I've been using it and paying for it. Pages are simple and functional. Github makes me feel tired, overwhelmed, and it requires too much scrolling and reading what looks like ad copy.
While i do generally like Github, i find the Apple portion of the GP comment especially funny - as parts of their website is one of the worst experiences i've had on the modern web.
From memory it was mostly locked scrolling, slow page loads, awful rendered video, etc. Ironically i recently saw Google with the same problem on their new Phone product page (a few months back).
It seems Designers are being given too much freedom with completely no concern for practical implementation. No one on the dev side stands up and says "but that'll lag like mad" - they just implement the bloated slow mess to spec; and god knows performance is never in spec.
So yea, i might agree with the GP comment - i do prefer "modern" look over that of Sourcehuts.. if it worked. But as it stands, Sourcehut's UI is faster than every modern UI i deal with, and i want things that work - first and foremost. Fast.
I'm a web developer, and I actually agree completely about their scrolling and page loads. Absolutely awful on both counts! That said, Apple already has mass adoption, and dealing with those UI inconveniences is considered acceptable in exchange for the OSes they provide (by their users - just look at how so many of them vote with their wallets). If Apple.com were a popular website, I'd say they'd be in trouble, but their real money comes from their (non-web-frontend) software.
That said, you can have a "modern" UI (although not UX) from SourceHut with only CSS changes. You can write all the CSS needed for a modern UI without doing it wrong like Apple did, and (if you know what you're doing) without adding megabytes of bloat. Add caching to the mix, and SourceHut would be just as fast but look more modern.
I can't speak for everyone, but I didn't pickup macOS because it's shiny. I picked it up because it's UNIX/BSD while also having a lot of proprietary software like Photoshop (without using Wine). That and the hardware is pretty good.
Sure, I want stuff to look nice too, but only if it doesn't ruin the user experience in other ways like making the site slower to load and use
Design is in the eye of the beholder - many users find SourceHut's UI beautiful and have praised it as such. Beauty is also more than just a pretty face - SourceHut is an engineering tool, and if it elegantly and efficiently organizes information for engineers to use, that can be more important and more beautiful than an eye-catching design. In fact, an eye-catching design can often degrade the experience of engineering tools, and eye-catching elements - such as colorful buttons - are carefully and deliberately controlled for in the design of sr.ht. It optimizes getting you the information you need or helping you complete the task you came here for as efficiently as possible.
SourceHut has been designed deliberately and for a specific purpose. The simplicitly of its appearance is a feature.
I did not downvote you. I think it's wonderful that people love the UI of SourceHut. You've put a lot of effort in and made a product that many people love, and that is fantastic and a hell of a lot more than I can say for myself. Seriously, congrats on all you've accomplished, and thank you for all you've done for the open source community, it's quite a lot and very deserving of appreciation
But my point is about mass-adoption. What I personally think of the UI isn't very important - as you say, "Design is in the eye of the beholder". But I would argue that if GitHub were to release a redesign identical to SourceHut in 2020, we'd see the largest exodus of GitHub users (for personal projects at least) ever - far, far, FAR more than any other time GitHub has changed their UI.
You can argue that GitHub and GitLab have UI that degrades a developer's experience. You can argue that their designs are FADs, and even that eventually they might change their design to be more similar to your's. And all of those arguments may be right. But right now, I'd argue that this design hurts mass adoption, and even though what design language is "in style" is completely a FAD, following the FAD does help adoption, and entire companies (e.g. fast-fashion like H&M) make tons of profit on FADs (even when they do horrible things - like how fast fashion is bad for the environment, some of GitHub's actions are bad for open source, the Apple example, etc).
I think your numbers are great evidence that you will get users with your current design, and I think that were you to release a GitHub clone (design-wise), you'd lose most of your users and would still struggle to gain non-GitHub users. I don't think there's a way to satisfy both camps of users, but perhaps a "colorful" and "minimal" theme may help? This is not as important as other things you are doing such as the things mentioned in https://news.ycombinator.com/item?id=25103662 but I do think it would help with mass-adoption (which may even be a non-goal, or may be far less important than other goals - that's totally fine too, I'm not trying to judge you or say you're completely wrong, just pointing out something which I feel is missed in these design discussions on HN).
>I did not downvote you. I think it's wonderful that people love the UI of SourceHut. You've put a lot of effort in and made a product that many people love, and that is fantastic and a hell of a lot more than I can say for myself. Seriously, congrats on all you've accomplished, and thank you for all you've done for the open source community, it's quite a lot and very deserving of appreciation
Sure, no worries, there are no personal feelings attached to these comments.
>But my point is about mass-adoption
Mass adoption is not a goal of sr.ht.
>if GitHub were to release a redesign identical to SourceHut in 2020, we'd see the largest exodus of GitHub users
In some ways it makes me happy that great products aren't popular :) I feel like I am part of an exclusive club of exceptional people that make great products. See: https://suckless.org/ -> Great products, but not popular.
You seem to be stuck with confirmation bias: Just because the way things are doesn't mean they're optimal. All things can get stuck in a local optima and it takes guts to challenge the status quo to get out of it. This "undoing" is what we call innovation. Whether it survies the undoing or not - that's upto the users who adopt this product. If it does survive, then we all progress. If it doesn't, it was a great experiment. Thanks for empathizing with what Drew is doing.
>> You can argue that GitHub and GitLab have UI that degrades a developer's experience. [...] And all of those arguments may be right. But right now, I'd argue that this design hurts mass adoption
> You seem to be stuck with confirmation bias: Just because the way things are doesn't mean they're optimal
I'm afraid you haven't understood my words. I'm not talking about optimal, in fact, optimal is explicitly made a non-goal in my comment. You can tell me about VHS vs Betamax, and all I can say is I had never even heard of Betamax until I saw people talking about it on HN. You can tell me Plan 9 is better than Linux, or that (insert obscure brand here) is better than Heinz. Mass-adopted solution != optimal solution. Mass-adoption doesn't even require products to attain local optima, let alone global optima. I use an obscure toothpaste that comes in tablets in glass bottles - totally obscure, likely will never reach mass-adoption, but it is better.
I was not aware that mass-adoption was not a goal of SourceHut, and I mistakenly assumed it was. Without mass-adoption as a goal, I can totally see how this mentality you expressed makes perfect sense, and I personally agree with it for less-well-adopted things that I use too: "If it does survive, then we all progress. If it doesn't, it was a great experiment"
No. Especially on a non-mobile screen. I used to have better-than 20/20 vision, I would guess that I now have around 20/20 vision. I find the text to be too small on the home page and scrunched up. I'm on a 4k monitor, and the front page stops at "30" and wants me to click "More" instead of loading in more posts automatically (and loading in even more as I scroll). I find this inconvenient and wasteful - I'd much rather each post take up more height, and I'd strongly prefer a "infinite" scrolling system. Even if I was on a 1080p monitor, I'd rather have each post on the front page take up double the amount of vertical space it does now than have it's current UI. The loss of information density would be (to me) well worth it.
I've switched from a mac and iPhone to Linux and Android, and as you can tell, I'm still on HN. Clearly, design isn't absolutely everything to me. But the notion that aesthetics "get in the way for the most part" is one I and most other developers I know in real life disagree with. I'd argue that HN's aesthetics get in the way. I personally have used browser extensions to change the HN CSS, due to how much I dislike the UI.
Because I enjoy using things I find aesthetically pleasing more than things I don’t.
It’s one of the main reasons I left Sourcehut. No slight intended — I think Drew has built something really useful and I’ve even submitted a patch to fix a design bug. But ultimately I prefer GitLab’s visual polish.
not only do I see fewer macbooks every year among the affluent crowd as more and more people just seem to go straight for linux or WSL machines, this is particularly untrue for much of the developing world, where most of the developers of the future will live (or already do, IDK). And let me tell you those people appreciate a simple, fast loading webpage.
If you want more market share build a product for the entire world, which does not run on the newest fancy version of iOS.
During a global pandemic, countries shutting down and the global economy not doing so well to say the least, the Mac at 36-years old grossed a little over $9 billion. That's more than either the iPad or the Apple Watch.
It seems that people working from home for the foreseeable future bought a lot of Macs.
Should be interesting now that M1 Mac laptops are reported to have blow away performance and last as long as 20 hours on a single charge.
And these Macs come with a BSD-derived development environment and will likely run Linux in a VM faster than comparable Intel machines can run it natively.
We need to get out of this rut of UX/UI design. UX/UI designers’ existence itself is based on generalized condemnation of a group of people: “Engineers are bad at designing and aesthetics.” Every time that’s brought up, I roll my eyes.
The truth is there are some outstanding UX/UI designers and there are some really bad engineers who design terrible unfriendly shit. The reverse is more common from what I’ve seen.
So you take issue with condemnation of an entire group and then do it yourself immediately afterward?
Saying engineers are bad at design is fine. Most people are bad at things they don't practice, and we know most engineers don't practice design.
Saying UX/UI designers (two separate groups with totally different backgrounds) are bad at design is maligning an entire field and suggesting a team hierarchy where engineers make all decisions.
You're using a very particular definition of "design". Let's take the typical interface of unix tools (default to outputting to stdout, default to inputting over stdin). Brian Kernighan talked about his they retrofitted all tools to use this model once they invented pipes.
Is it not UX, is it not design? Why does design have to be graphical, and why does "UX/UI designers" get to say what it is? How can a tool even exist without an interface? And if a tool is used, surely it has a user ;)
> You're using a very particular definition of "design"
No, I'm using a common definition of it. I'm using the same one that the person I responded to was using, which is the type of design for which people hire UX/UI designers.
People don't hire UX/UI designers to design CLIs. Maybe they should, but they don't. Is it UX and UI? Sure. But we're talking about an industry term at this point, not 100% of everything that is designable.
> Why does design have to be graphical, and why does "UX/UI designers" get to say what it is?
I honestly don't know who or what you're arguing against right now. This seems totally tangential to the comment I replied to.
Companies hire engineers to write code and designers to create GUIs. Those are the domains we're talking about. I don't disagree with you philosophically at all.
> > most engineers don't practice design
My meaning was unclear here.
I meant that most engineers don't study and repeatedly practice design, meaning that they don't have feedback loops with their designs. The goal is releasing their code, not building their skill at design.
Designers, on the other hand, will create many iterations of something with feedback along the way, sometimes in an academic setting.
Even setting that aside, most engineers work at large corporations where design is a bureaucratic process that engineers aren't expected to change. They just write the code.
> Citation needed.
No, it's not. First of all, I've in the software industry for 20 years, so I'm going to lean on first-hand experience here.
Second, the burden of proof is on the person making the more uncommon claim. The inverse of "most software engineers don't practice design" is "most software engineers do practice design," and the latter would be more surprising to the typical person.
Unless, as mentioned above, you expand the meaning of "design" far beyond what the original thread was about, which was web UI design.
What is "not what the parent said"? And why is your interpretation different?
The parent said it is more common for engineers to be good at UI design than for UX/UI designers to be good at it. The last two sentences say it plainly.
SourceHut is an interesting concept and basically the equivalent of a built-at-home GitHub. It's based on Python (and now Go), runs on Alpine on baremetal in a datacenter in the US. Some of the above aren't just views for SourceHut though, they're more like a way of life. If you'd like to test that join the SourceHut channel on Freenode and ask if anyone has any reference for Dockerfiles or Kubernetes and see what response you get.
SourceHut and other code hosting sites are popping up as a wave of programmers push for decentralization. Some may say that it's in response to youtube-dl, but this has been happening slowly for a while. If SourceHut isn't right for you there's always Codeberg which is essentially a Gitea instance backed by a non-profit in the EU.
Been using sourcehut little over a year now. I'm a fan
Looks real good in dark mode via the standard "dark reader" browser plugin most people use these days, btw. Would love to see them add a native dark mode though. That's my main gripe.
The official response to this ask was "convince the browsers to ship prefers-color-scheme dark", and now that they have, the official answer is "patches welcome". I would definitely be down to add a dark theme if someone put in the work.
I've looked at this with some curiosity over the past year, but it was only this morning that I decided to take a closer look. While I'm a huge fan of GitLab, I think this is really something special. I spent $50 to show some support and I'd like to find other ways I can contribute.
I know Drew is very adamant about using mailing lists instead of pull requests. However, I like the public nature of pull requests and how they archive discussions.
Is there anything that already exists out there to bring that functionality to the email workflow?
Additionally, unlike GitHub, these discussions have been forwarded to all list subscribers, any of whom could trivially turn them into another public archive, independently of sourcehut. Such an archive is also available to list admins in one click for both export and import, in a standard file format. With DKIM and PGP signatures and such, you can even preserve the authenticity of these messages across arbitrary sources.
Any one have personal experiences on self hosting an instance that they wish to share? I keep meaning to look in to it a bit more, but always seem to end up nudging it down the list.
BTW, I think the documentation already seems nice and approachable. From your send-email helper site right through to the sr.ht docs themselves. Much appreciated.
[I was kind of asking for personal experiences - in part - because docs don't always match reality ;)]
I've been selfhosting it for a while now and the installation wasn't hard when I installed it, and the doc has gotten better since
The hardest part was setting up a working mail server for the mailing lists (but that has nothing to do with sourcehut)
I wish more of the SourceHut stack was written in Go, like Gitea. It would greatly increase performance and simplify deployment. Long-waited NetBSD support in CI[1] would be awesome to be finished too.
More and more of it is being rewritten in Go as part of the API 2.0 project. In any case, SourceHut is already the fastest software forge by objective measures:
The comment you’re responding to specifically calls out Gitea, which isn’t measured in forge perf. (Most likely because there isn’t a major, permanent, public instance of Gitea... it seems to currently be targeted at self hosted instances, and then its speed is obviously dependent on the hardware it’s hosted on.)
Gitea and SourceHut can both be very fast, from what I’ve seen, but I haven’t seen any objective comparison numbers.
Codeberg, which is tested here, is hosted on Gitea.
A separate comparison would be needed to test the performance of self-hosted options. This comparison is meant to test hosted options, and in order to be fair, that has to also account for their hardware configuration, network situation, and so on, so simply adding a vaguely defined "Gitea" measure here would not be fair.
> Long-waited NetBSD support in CI would be awesome to be finished too.
As the maintainer of the linked vis project, I can confirm that the provided SSH access to the CI environment is very convenient and saves a lot of time.
I would also like to see the NetBSD support completed. It turns out that up until last week, we missed a #define to compile out of the box[1].
Both are alternative protocols to HTTP. Gopher is an older technology that uses a menu based organization of information. Gemini is newer and seeks to provide an alternative internet with a simpler client implementation.
> The only thing that worries me about the domain is lack of reviews about the entity that manages the .ht ccTLD.
The country of Haiti? Réseau de Développement Durable d'Haïti is an autonomous non-profit that acts much like a government department. They're actually also in charge of Haiti's internet backbone, so are less likely to be inclined to come up with arbitrary rules or suddenly change what is acceptable for the ccTLD. They have bigger concerns.
Judge for yourself if we were out of line. Steve's repository was basically an archive of his Instagram account, hundreds of high-resolution images. This is not what SourceHut is designed for. Mercurial repositories in particular have an outsized impact, because we generate nightly clonebundles from larger repos, and because images are uncompressible this results in a disproportionately large amount of wasted CPU time and disk space.
We updated our approach, in any case, to use the following email template instead:
At the time this thread first came up, I agreed that my sarcastic response to his Mercurial contributorship comment was out of line, and apologised for that.
Others who have read this thread came away with a different impression than you did. I tried to explain why it was a problem, rather than just leaving them put out. Personally, I prefer this approach over the cold, unfeeling notification from a robot that noticed your repo was oversized. Human admins is a feature of sourcehut, and human failures of communication occasionally occur as a result.
Anyway, the facts are laid out, and I'm not particularly enthusiastic about rehashing this discussion again, 10 months later, in an unrelated post celebrating our anniversary.
Honestly maybe Drew has the right to choose how he runs his service, but who gives a shit? He's taking money, nobody owes him. If you have to care about hosting details anyway, it's probably less of a hassle to self-host.
How much do you think the 1GB and processing actually cost? 1GB is surely less than a dollar, and the processing could either be special-cased or would not be more than $5/month for the duration until they get proper large-file support.
Meanwhile, the client's first comment on "surely 1.1gb" reads to me as saying "why are you wasting my time?", and Drew's response seemed to say "this is not an isolated incident, this is just how I operate", to which the "I've canceled my account because this is bullshit" is IMO entirely appropriate.
Sourcehut's decision and communication both seem reasonable to me. I think both parties could have maybe been a bit more genial, but the discussion remained professional throughout in my eyes.
The email-based workflow could be convenient for some, but speaking for myself, I'd mainly prefer to interact via the web UI. The ability to send updates to patches submitted from the web UI seems to be missing. If I made a mistake or was asked to change something, I had to completely re-submit the patch as a separate email. I couldn't find a way to communicate on mailing lists without using an external email client. Basic things, like needing to hand-wrap my emails at 70-something characters, and remember to remove quoted text from the bottom of emails, is an unfortunate barrier to entry for new contributors. All of these things could be abstracted away via the web UI for those who don't want to use email.