Hi, I'm using sr.ht for a while now and I wanted to give some feedback 
about the service:

- the paste and git services are both awesome, I miss nothing there and 
they have a very intuitive UI and API
- the hut cli tool ist awesome (only thing I'd like to see is to be able 
to update pastes with the same name; i.e. if I have a new revision of a 
file to be able to immediately replace the old one)
- sr.ht pages are nice although I wish there were some more error 
messages, just having it silently fail to deploy the site is kinda hard 
to trouble shoot
- I do have some issues with builds:
   - the containers are too small in many non-trivial cases: I'm using 
nix to build most of my stuff and for most jobs the build already fails 
when pulling cached derivations
   - the containers have very limited RAM: I am failing to e.g. build 
haskell-language-server in the containers, if it's not cached, because 
the container will run out of memory.
   - the status reports in that regard are (imho) improvable; there 
should be a difference between a build that just failed because of the 
constraints imposed by the container it's running it and a build that 
failed because the build is actually unsuccessful

I'd be happy to pay a premium (well what's a premium, let's say "more") 
for a larger container as I, in my current situation, cannot self-host 
runners non-trivially. fgaz also noticed that apparently the container 
constraints are larger for Debian (vs NixOS) containers, which I do not 
understand.

The grand issue I see here is, that there needs to be an incentive for 
people to switch to git hosters that are not GitHub other than morale; 
if people pay for CI service then I think it should work at least as 
well as the services that GitHub provides (seemingly to the user) "for 
free".

Overall I'm very happy though and I will keep recommending sourcehut to 
people I know. Thank you for providing this service and keep up the 
great work!

PS: I tried reaching out on IRC as well but it apparently got 
overlooked, so here we go again ;)

On Thu Feb 2, 2023 at 4:35 AM CST, Magnus Viernickel wrote:
> - I do have some issues with builds:
>    - the containers are too small in many non-trivial cases: I'm using 
> nix to build most of my stuff and for most jobs the build already fails 
> when pulling cached derivations
>    - the containers have very limited RAM: I am failing to e.g. build 
> haskell-language-server in the containers, if it's not cached, because 
> the container will run out of memory.

GHC is very resource hungry.  A couple of years ago I was unable to
compile a glorified TODO CLI app written in Haskell because the machine
ran out of memory. It had 8GiB and this was not enough to compile a CLI
app!!  (the culprit was one of the dependencies, but still)  Also, the
pre-compiled binaries provided by the author were more than 100MiB in
size!!  Again, for a CLI app[1].  Later, the author stopped providing
pre-compiled binaries and made Nix the only way to build/install the app
(for some reason many Haskellers love Nix).  I haven't looked at it ever
since, no way I would download/compile the whole world just for a TODO
CLI app.

I'm not a performance-junky but don't like unnecessary waste, and am
very displeased with the "modern" definition of "few resources".
Software just keeps using/requiring more resources (at some time I had
to add more RAM to my machine because 8GiB was not enough for
Firefox/Chrome+Slack+Zoom >:( --that I had to use for work).  In the
case of Haskell/GHC, when people bring up the issue with binary sizes
and memory consumption (both by GHC and the executables it produces),
many people in the community just reply with something like "RAM and SSD
are cheap, what's the problem?".  I gave up on Haskell, it's not an
option, resources-wise, for the kind of software and environments I'm
interested in.


I'm not saying your particular use-case and complaint are not valid (I
don't know it), though.  I was just venting my frustration with modern
software expectations, practices and ecosystem :)

- Lombera

[1] Compare this with the amazing https://redbean.dev/, a static
    webserver with Lua, SQLite and a REPL embedded in a single static,
    2MiB+ executable that can run on several OSs without modification.

On Thu, Feb 2, 2023, at 4:35 AM, Magnus Viernickel wrote:
> Hi, I'm using sr.ht for a while now and I wanted to give some feedback 
> about the service:
> 
> - I do have some issues with builds:
>   - the containers are too small in many non-trivial cases: I'm using 
> nix to build most of my stuff and for most jobs the build already fails 
> when pulling cached derivations

Small in terms of disk space, I presume? Asking because I use Nix w/
caching and haven't had any issues

>   - the containers have very limited RAM: I am failing to e.g. build 
> haskell-language-server in the containers, if it's not cached, because 
> the container will run out of memory.

I had this issue with a Bazel project, but one thing that helped
significantly was just turning down the parallel build count. One GHC
process already uses enough memory, but *two* is going to be using
double that. Might be worth playing around with that for the parts you
more use more RAM.

>   - the status reports in that regard are (imho) improvable; there 
> should be a difference between a build that just failed because of the 
> constraints imposed by the container it's running it and a build that 
> failed because the build is actually unsuccessful

I don't think this is trivially detectable; different things all handle
OOM conditions in different ways (though maybe it could try to check the
kernel logs?).