When I read that article, my initial reaction is that I hope there's not much change in response to that, or that any change is purely additive, in the sense of letting project owners choose alternate workflows. It seems OK that different workflows are better for different projects, and that one forge might fit a particular project's needs better than another.

I hope it's not dragging this thread too far off-topic to ask, though: is sourcehut doing OK? I'm certainly still happy using it, and it's been stable and very nice to use from my perspective.

I've noticed two things that make me want to hear an update on how both the project and the business is doing, though:

1. Drew recently offered a fork of Redis, called Redict, and chose to host development on Codeberg.[1]
2. The only posts on the SourceHut blog[2] in the past year or so are the ones that discuss the notable outage from early 2024.

I'm not trying to sound any kind of alarm; things are working great for me, and I could continue to use sourcehut in its current state indefinitely.

I'm assuming all the news is good, and people are just too busy to stop and talk about good news, as happens frequently. If anyone close enough to know could make time for even a brief update, though, it'd be great to hear a bit about what's gone on since the review of the 2022 financial report, other than the unexpectedly accelerated datacenter move.

[1](https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/)

Thanks for the feedback! I appreciate the suggestions, and feel like I 
should add a couple of observations that you were too kind to make 
directly just in case someone stumbles over this in the archives and 
considers using it.

On 1/2/22 17:05, Christopher Wellons wrote:
> * Instead of a racy exists() with "wb", you can use "xb" in a try-except 
> with FileExistsError, which will perform the check atomically (i.e. via 
> open(2) O_EXCL).

Thanks very much for pointing out "xb". I never noticed the addition of 
the x mode flag, and I've been moved over to python 3 for far to long to 
have any excuse for that.

I enjoyed this piece, and I've wanted a similar thing before.

 > I expect any experienced programmer could write a basic attachment 
extractor in their language of choice inside of 30 or so minutes. 
Hooking up a DEFLATE library for decompression would be the most 
difficult part.

That held up well for me. Here's my 15ish minute attempt in python:

https://git.sr.ht/~tuxpup/pypng-detach/tree/main/item/pypng_detach/cli.py

Reading a null-terminated string to get the name feels a little 
contorted in python, but compression was very straightforward.

> > I know I should go find a way to contribute to the wiki, but I only have
> > a minute to spare. At least in US English, "Free Software pole" is a
> > very funny translation of "le pôle logiciels libres." "Free Software
> > Center" would be a much clearer choice and would, in my opinion, almost
> > certainly better reflect the intent of the original version.
>
> I have been hesitating between "pole" and "unit".
>
> I did not consider "center": our unit is made of a handful of civil
> servants, "center" would not reflect the truth.
>
> How about "unit"? Does it sound better?
>

Salut Bastien,

I love your post and your organization's reasons for choosing SourceHut!

>
> as kindly mentioned by Drew on his blog post, Etalab's Free
> Software pole uses SourceHut for its repositories, e.g. for
> the code behind https://code.gouv.fr.
>
> We wrote some explanations of this choice here:
>
> https://man.sr.ht/~etalab/logiciels-libres/why-sourcehut.md
>

Can mailspring access this list now?

2021-04-28 16:53

On Sat Feb 6, 2021 at 1:37 PM EST, Mehdi Sadeghi wrote:
> Geoff, on your behalf I made the patch and Drew applied it. See
> https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/20084.
>

Very nice! Thank you for doing that, and I'm glad Drew was able to apply
it so swiftly.

> Hier is a mini wrap-up of the send-patch workflow I did. First add the
> following to your ~/.gitconfig (adapt it based on your email provider):

Thanks also for sharing your configuration for this. I suspect I was
unclear in my statement/question about where I'd gotten stuck sending
in a patch, though :). git-send-email works fine for me, and I've used

On Fri Feb 5, 2021 at 3:53 PM EST, gildarts wrote:
> On 2/5/2021 2:20 PM, Mehdi Sadeghi wrote:
> > Using Thunderbird I can sign and send emails (just tried). I have 
> > different sub-keys for signing and encrypting. This email should arrive 
> > signed too.
> > 
> > - Mehdi
> > 
>
> Yep it arrived signed. The question is if sr.ht can use the public key
> you uploaded to encrypt a message for you.
>

You nerd-sniped me, so I took a look. I can see that there are 3 user id

On Thu Dec 10, 2020 at 8:42 AM EST, Drew DeVault wrote:
>
> Yes. Please file a ticket with ~sircmpwn/lists.sr.ht, or send a patch.
> Let's just reject mail with this header outright and send a bounce.

Ticket filed. I'd like to take a swing at a patch over the next day or
two.

On Thu Dec 10, 2020 at 4:33 AM EST, Allen Sobot wrote:
> I'm terribly sorry about this, and this message will probably have that
> same header in it...
> I in fact had no clue about this header's existence, or in any case that
> my client puts it in.
> If you could therefore point me to a way to get rid of it I would be
> thankful (I use K-9 Mail on my phone and Neomutt on my computer)
>
It sure did. On the bright side, the fact that you didn't know about it
until I mentioned it suggests that very few mailers are sending such
receipts by default anymore. If they were, you'd have a bunch of read
receipts.

For K-9, it looks like details on that feature are here: