
The Sourcehut Project Hub - ddevault
https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-live/
======
omdv
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
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.

~~~
ddevault
I am very proud of our performance :)

[https://forgeperf.org/](https://forgeperf.org/)

~~~
mappu
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
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.

------
tiffanyh
Drew, congrats! I love the principles you hold fast too.

Q: does this mean pricing is no longer optional?

[https://sourcehut.org/pricing/](https://sourcehut.org/pricing/)

~~~
ddevault
Payment is still optional, and SourceHut is still considered an alpha. This
completes only one of a few important milestones blocking the beta.

And, thank you for the kind words :)

~~~
tiffanyh
Well, don’t wait too long before you charge :)

I realize we can all make optional payments but I’d love for you have
committed reoccurring revenue you can count on.

(I say this as a huge admirer of what’s you’re working on and accomplished)

~~~
ddevault
We have enough :) Not a lot, but enough, and a little more than that. You can
keep an eye on the financial reports if you want to see for yourself:

[https://sourcehut.org/blog/2020-04-13-sourcehut-q1-2020-fina...](https://sourcehut.org/blog/2020-04-13-sourcehut-q1-2020-financial-
report/)

Note that I have secondary income sources, and we also make some money from
lending our staff out as part-time consultants. It's not important to me to
maximize the earning potential of SourceHut. The mission is to make the free
and open source ecosystem better, not to make our own pockets richer.

~~~
Arkanosis
I have a hard time telling if I admire your mindset more than your work or the
opposite… :)

------
lbotos
Drew, Consider adding a line-height on .content of 120%. Should make it a
little bit easier to read.

~~~
ddevault
Good suggestion, thanks.

------
emptysongglass
I love sr.ht but for the love of God can we please have an easily deployable
Dockerfile for selfhosting? I'm almost positive its lack stems from Drew's
ideals of how software ought to be distributed but it would really help with
wider adoption. Sometimes you don't have he luxury of dealing with a NixOS or
straight Debian system or you're running containers-only because of company
policy and so on and so forth.

~~~
ddevault
This was brought up a couple of times, start here for the response:

[https://news.ycombinator.com/item?id=23037904](https://news.ycombinator.com/item?id=23037904)

~~~
emptysongglass
Let me be real with you for a second in one of those let's pretend we've just
taken a bunch of psychedelics and all the structures that prop us and our
beliefs and ideals have collapsed: I really think you should reconsider your
position on this. Containers are ok, they are not a threat; the kinds of
people who are going to be selfhosting your stack are the same kinds of
curious, investigative people who will debug when it all falls down. Those
people do not need to be pushed through a manual series of commands as a
hazing ritual.

I'll be just as real with you that I'm not going to be the one to maintain it.
It's in the best interest in the platform's broader adoption I make my plea.
Because people like me will just flounder on the rocks of the GitHubs of the
world. And that's not a future either of us really want.

~~~
ddevault
It's not a hazing ritual, it's a necessary series of learning steps which
equips you to be a _good_ sysadmin of your new instance. Whatever did we do
before Docker? The world must have sucked back then!

~~~
t0astbread
Not to be snarky but Docker (+ Hub) is mostly just packaging with some
isolation to avoid conflicts, right? So why would you recommend packages from
"regular" package managers (as seen in the installation instructions) but not
Docker? (This is a serious question, maybe I am missing something.)

~~~
ignaloidas
Because Docker is a really shitty way to package applications. You don't
package the application, you package an entire linux distro, with it's
packages, and your application into a single opaque blob. Normal package
managers just package your application in a more simple manner which works in
conjunction with your OS, not on top of it.

~~~
t0astbread
It makes sense to package and isolate the base system since it avoids any
"hidden state" that could influence the behaviour of your program and
introduce hard-to-debug errors.

And it's not packed into a single opaque block: You can specify an image to
derive your image from and Docker will overlay-mount your image on top of the
base image, avoiding the need to store multiple copies of a base image.

------
selfhostfan
Hey ddevault, thank you for work, especially Sway and Wlroots. Is there any
plan to distribute Sourcehut as a docker image for installation? I personally
self-host a number of applications myself (using Docker+Traefik), and would
like to move to Sourcehut from SCM Manager.

~~~
ddevault
Thanks for the kind words :)

However, there is no Docker turn-key installer, and no plans to make one. I
elaborated on this here:

[https://news.ycombinator.com/item?id=23037232](https://news.ycombinator.com/item?id=23037232)

But, I've also long acknowledged that if someone else wanted to make a set of
third-party Docker images, it would be feasible, and I wouldn't be bothered by
it (so long as you didn't ask me to support it).

~~~
selfhostfan
I see, thanks for the reply. I didn't make my own only because I don't usually
have time to maintain and monitor for new updates; but if updating it is as
simple as `apk update`, then that shouldn't be a problem.

------
tsukurimashou
Happy for you Drew, I've been following you on and off for a few years, feels
good to see someone being able to live off the kind of work you do.

I like the minimalist approach of many aspects of your work. And the whole
website using no JavaScript is also very nice to see.

Have you thought about adding some opt-in JavaScript to enhance the user
experience?

~~~
ddevault
There are 2 or 3 small touches of JavaScript here and there which make
conservative enhancements. But, it's a base design requirement that all
features have to work without JavaScript - and once they do, adding JavaScript
doesn't often seem very compelling.

------
e12e
Great to see things progressing. We're currently self-hosting gitlab, and the
relatively tight coupling of repo and issues/issue boards is an itch for us.

How is the self-host story for sourcehut (paid or gratis)?

Is there a turn-key variant with turn-key upgrades a la gitlab omnibus
installer?

~~~
ddevault
The self-hosting story is pretty good(TM). It's not turn-key, and there is not
an installer. You need to run through the steps manually, which are documented
here:

[https://man.sr.ht/installation.md](https://man.sr.ht/installation.md)

Most people get this done in an hour or two, sometimes with the help of #sr.ht
on irc.freenode.net. It's also often made easier by the fact that you can skip
any services you don't need, like paste hosting or wikis. By making you go
through the steps and set it up, it makes sure to leave you with an
understanding of the pieces and how they fit together, so you're better
equipped to deal with it if/when it breaks and to adapt it to your particular
circumstances. After you set it up, upgrades are usually pretty painless, you
just run `apk upgrade` and it takes care of the rest. In general, I think this
approach makes a lot more sense than the turn-key Dockerized approach.

~~~
e12e
Thank you - I followed a link that said "open source" and it took me to a list
of repositories (which is nice, we all like open source) - but I apparently
didn't land on the install-link (to be fair, I didn't look very hard).

I'm not sure I'm a fan of many approaches I've seen (gitlab omnibus is not a
docker install, BTW).

You appear to be supporting alpine Linux - and also Debian derived systems -
via packackes?

Packages, obviously, is a nice way to install software... If I wanted an
appliance - I should set up an alpine vm, install source-hut components I
like, point it at a managed postgres instance and a smart mail host - and
assume I'll only ever need to do rolling updates via apk - and distro upgrades
via alpine?

Is running on Debian likely to be as smooth?

~~~
ddevault
If you remember where you found that link, let me know, so I can update it.

>Packages, obviously, is a nice way to install software... If I wanted an
appliance - I should set up an alpine vm, install source-hut components I
like, point it at a managed postgres instance and a smart mail host - and
assume I'll only ever need to do rolling updates via apk - and distro upgrades
via alpine?

Yeah, that's about right. Upgrades are done just by running your normal
package manager updates.

>Is running on Debian likely to be as smooth?

The Debian repository is community-maintained, but the maintainer does a good
job and a few people have reported sucess using his packages. We also set it
up so that upstream releases automatically update the Debian repo. You'll have
to depend on him for support, though, not me - his nick is dlax and he hangs
out in #sr.ht on irc.freenode.net; and his email is given on the package page.
He's a helpful fellow.

Alpine Linux is indeed the officially supported platform, though, and I highly
recommend it. I wouldn't dream of running a different system in production,
Alpine is simple and reliable and it's easy to fit the whole thing into your
head.

~~~
e12e
Thank you.

> If you remember where you found that link, let me know, so I can update it.

I belive it was the "100% free and open source" link in this very post:

[https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-
is-l...](https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-live/)

Which goes to:
[https://git.sr.ht/~sircmpwn/?search=sr.ht](https://git.sr.ht/~sircmpwn/?search=sr.ht)

Which does indeed link the repos - which is good - but from a mindset of "how
do I self-host?" maybe a bit bare bones.

Looks like if one follows any of the repo links - the install info is at the
bottom. May be an artifact of me being on my phone.

As I said, I didn't look very hard.

I really appreciate the no-nonsense/no hype vibe - but at the same time, I
really do want a "here's a sane way to get up and running" front and center.

Now, obviously there's a hosted offering - but at my current company we have a
few projects that we feel more comfortable self-hosting due to the nature of
some of our customers. For some, we avoid third parties, where we can.

~~~
ddevault
Thanks for the tip! I've updated that URL to the following, which is much more
helpful:

[https://sr.ht/~sircmpwn/sourcehut](https://sr.ht/~sircmpwn/sourcehut)

------
Seirdy
This is excellent. The great thing about Sourcehut is that if you have extra
git remotes, you can keep working like nothing ever happened if the site goes
down. Issues and patches are decentralized over email.

The Project Hub looks like an excellent way to tie together all the separate
Sourcehut services to better compete with other "complete" VCS-based
collaboration suites like GitHub and GitLab. In the future, it would be really
cool to expose an API to allow adding "custom" services that aren't part of
Sourcehut.

It's good to see Sourcehut focusing on project discovery, since this is the
area where GitHub excels at the most. When I search for a small CLI/TUI
utility, I often run these filters:

\- filter out weblangs, frontend-oriented languages, and languages with heavy
runtimes (JS, TypeScript, CoffeeScript, Vue, CSS, HTML, Dart, Purescript,
Livescript, Elm, Swift, JVM languages, .NET languages, Vala, QML, etc.). I
have several shortcuts for many combinations of languages so I don't have to
type them out every time.

\- filter repos below a certain size (a repo above 10mb is probably full of
bloat).

\- If applicable, filter out repos whose last commit was before a certain
date.

\- If applicable, filter by topic

\- If it concerns a recent technology, I can filter repositories created after
a certain date.

\- If I want to try a smaller project that isn't cursed with mainstream
success, I filter repositories below a certain number of stars.

For instance, if I feel like my MPD setup is missing something, I might
search:

    
    
      mpd stars:<150 pushed:>2019-01-01 size:<8000 -language:purescript -language:livescript -language:vue -language:javascript -language:typescript -language:coffeescript -language:elm -language:dart -language:java -language:scala -language:kotlin -language:clojure -language:groovy -language:php -language:objective-c -language:objective-c++ -language:swift -language:css -language:HTML -language:haxe -language:csharp -language:fsharp -language:"jupyter notebook" -language:powershell -language:cuda -language:assembly -language:tex -language:batchfile -language:erlang -language:elixir -language:emacs -language:vim -language:plpgsq -language:julia -language:xslt -language:systemverilog -language:verilog -language:hcl -language:tsql -language:jsonnnet -language:gdscript -language:r -language:smarty -language:freemarker -language:nix -language:saltstack -language:"visual basic" -language:"visual basic .net" -language:plsql -language:"rich text format" -language:dockerfile -language:vala -language:QML -language:actionscript -language:matlab -language:alloy -language:cobol -language:graphql -language:m4 -language:qmake -language:fish -language:opencl -language:json -language:rmarkdown -language:xml -language:markdown -language:applescript -language:puppet
    

The result [0] shows quite a few nice utilities. If I want to go even more
minimal, I could filter out Ruby and even Python projects.

It would be great to have a FOSS implementation of an advanced project search
utility that isn't limited to (or even part of) any particular hosting
provider. Maybe ActivityPub could help facilitate connecting and indexing
project metadata from different hosting providers.

[0]:
[https://github.com/search?o=desc&q=mpd+stars%3A%3C150+pushed...](https://github.com/search?o=desc&q=mpd+stars%3A%3C150+pushed%3A%3E2019-01-01+size%3A%3C8000+-language%3Apurescript+-language%3Alivescript+-language%3Avue+-language%3Ajavascript+-language%3Atypescript+-language%3Acoffeescript+-language%3Aelm+-language%3Adart+-language%3Ajava+-language%3Ascala+-language%3Akotlin+-language%3Aclojure+-language%3Agroovy+-language%3Aphp+-language%3Aobjective-c+-language%3Aobjective-c%2B%2B+-language%3Aswift+-language%3Acss+-language%3AHTML+-language%3Ahaxe+-language%3Acsharp+-language%3Afsharp+-language%3A%22jupyter+notebook%22+-language%3Apowershell+-language%3Acuda+-language%3Aassembly+-language%3Atex+-language%3Abatchfile+-language%3Aerlang+-language%3Aelixir+-language%3Aemacs+-language%3Avim+-language%3Aplpgsq+-language%3Ajulia+-language%3Axslt+-language%3Asystemverilog+-language%3Averilog+-language%3Ahcl+-language%3Atsql+-language%3Ajsonnnet+-language%3Agdscript+-language%3Ar+-language%3Asmarty+-language%3Afreemarker+-language%3Anix+-language%3Asaltstack+-language%3A%22visual+basic%22+-language%3A%22visual+basic+.net%22+-language%3Aplsql+-language%3A%22rich+text+format%22+-language%3Adockerfile+-language%3Avala+-language%3AQML+-language%3Aactionscript+-language%3Amatlab+-language%3Aalloy+-language%3Acobol+-language%3Agraphql+-language%3Am4+-language%3Aqmake+-language%3Afish+-language%3Aopencl+-language%3Ajson+-language%3Armarkdown+-language%3Axml+-language%3Amarkdown+-language%3Aapplescript+-language%3Apuppet&s=stars&type=Repositories&utf8=%E2%9C%93)

------
smartmic
Congratulations to everyone involved and using Sourcehut! It is good to see
viable, free alternatives to Github rising. The developer ecosystem becomes
weaker if almost everyone get trapped in a corporate monoculture.

Personally, I trust fossil-scm for my side projects. Albeit based on a
completely different design philosophy, I recommend to check it out for
everyone eager to look outside the box.

------
foresto
Thank you. I spent ten minutes looking for a project index when I discovered
sourcehut today, and failed to find one.

Am I blind, or is there no link to
[https://sr.ht/projects](https://sr.ht/projects) from the main sr.ht or
sourcehut.org pages? What is the expected path of discovery?

------
chrisweekly
Bravo! Congrats! Thank you!

