Hi folks!
I've decided I really want to get off Github for various reasons you're
all probably familiar with. I particularly appreciate the decentralized
email-based workflow that I was used to with various DVCSs - arch,
darcs, mercurial, git (pre github), etc. I am looking for a home for my
various Open Source projects -- or perhaps I should say, "several homes"
since of course Git really is decentralized.
Basically, Sourcehut is the first forge I've ever seen that seems to
really be about decentralization and email-like control. I am quite
pleased with that!
Right now I see a lot appealing about both Sourcehut and Codeberg, and
have some questions and reflections about Sourcehut:
How does todo integrate with git? They seem to be somewhat disconnected
(though of course can be grouped in a project). Can I mention a task in
a git commit and have it be automatically linked or resolved depending
on how it was mentioned? If so, how can the commit specify which todo
tracker this pertains to?
I use org-mode (.org) files quite a bit, and fairly extensively for
documentation. Github and Codeberg (Gitea) render those, but Sourcehut
doesn't. Is there any possibility Sourcehut might render org files in
the near future?
I see that my SSH public keys are listed publicly. I recognize that
disclosure of them wouldn't direclty lead to a security compromise --
after all, they aren't private keys -- but nonetheless, it is not
something I really want to publish. I don't see the value in publishing
them, and would prefer not to have to do so.
I think it is important to have low barriers to entry for people. I
love all the email-based workflow, but when I tested it from an email
account from Gmail, it instantly rejected messages because they were
HTML. Messages sent to the todo system were rejected with an unhelpful
SMTP error, while messages sent to a mailing list got a more helpful
link to instructions for sending plain text. I myself am a fan of plain
text email, and I get the motivation behind this, but I am concerned
that, particularly for a mailing list, may represent a barrier to entry
for people.
Along the same lines, I believe that tar.gz files are more difficult to
open than ZIP files on Windows and Mac. It would be nice to have tags
downloadable as zips also.
Is there a way to upload a file for download with a release? Are
artifacts from the build system somehow made available?
Can the build system be used to generate and upload images to Docker
Hub?
To what extent are the project and site dependent on a single person for
ongoing viability?
Thanks!
- John
Quick answers:
On Mon Jan 31, 2022 at 4:11 PM CET, John Goerzen wrote:
> How does todo integrate with git? They seem to be somewhat disconnected> (though of course can be grouped in a project). Can I mention a task in> a git commit and have it be automatically linked or resolved depending> on how it was mentioned? If so, how can the commit specify which todo> tracker this pertains to?https://man.sr.ht/git.sr.ht/#referencing-tickets-in-git-commit-messages> I use org-mode (.org) files quite a bit, and fairly extensively for> documentation. Github and Codeberg (Gitea) render those, but Sourcehut> doesn't. Is there any possibility Sourcehut might render org files in> the near future?
First-class org mode support will not be added, but you can use org for
your readme file like so:
https://man.sr.ht/git.sr.ht/#readme-and-license-files> I see that my SSH public keys are listed publicly. I recognize that> disclosure of them wouldn't direclty lead to a security compromise --> after all, they aren't private keys -- but nonetheless, it is not> something I really want to publish. I don't see the value in publishing> them, and would prefer not to have to do so.
Your public keys are, as the name suggests, public.
> I think it is important to have low barriers to entry for people. I> love all the email-based workflow, but when I tested it from an email> account from Gmail, it instantly rejected messages because they were> HTML. Messages sent to the todo system were rejected with an unhelpful> SMTP error, while messages sent to a mailing list got a more helpful> link to instructions for sending plain text. I myself am a fan of plain> text email, and I get the motivation behind this, but I am concerned> that, particularly for a mailing list, may represent a barrier to entry> for people.
I agree that it would be nice to improve the todo bounce email in a
similar manner. Filed ticket:
https://todo.sr.ht/~sircmpwn/todo.sr.ht/256> Along the same lines, I believe that tar.gz files are more difficult to> open than ZIP files on Windows and Mac. It would be nice to have tags> downloadable as zips also.
NACK, we do not care about proprietary operating systems.
> Is there a way to upload a file for download with a release? Are> artifacts from the build system somehow made available?
Yes, and yes, but these are separate systems. You can attach files to
git tags on git.sr.ht and you can add artifacts to build manifests. The
latter are pruned after 90 days.
> Can the build system be used to generate and upload images to Docker> Hub?
Yes, in the sense that it can run arbitrary code so this is something
you can do yourself. There is no first-class integration.
> To what extent are the project and site dependent on a single person for> ongoing viability?
It is not.
"Drew DeVault" <sir@cmpwn.com> writes:
>> I see that my SSH public keys are listed publicly. I recognize that>> disclosure of them wouldn't direclty lead to a security compromise -->> after all, they aren't private keys -- but nonetheless, it is not>> something I really want to publish. I don't see the value in publishing>> them, and would prefer not to have to do so.>> Your public keys are, as the name suggests, public.
For what it's worth, this is true of other forges as well.
github.com/<username>.keys and gitlab.com/<username>.keys both return
your public keys. It is only sourcehut that makes this fact apparent
(which is nice). Not sure about gitea, etc., but I wouldn't be
surprised.
--
Andrew Fontaine
afontaine.dev
On Mon, Jan 31 2022, Andrew Fontaine wrote:
> For what it's worth, this is true of other forges as well.> github.com/<username>.keys and gitlab.com/<username>.keys both return> your public keys. It is only sourcehut that makes this fact apparent> (which is nice). Not sure about gitea, etc., but I wouldn't be> surprised.
I did not know that. Interesting. Though I notice Github (at least)
obscures the hostnames in the keys, while Sourcehut doesn't. I could,
of course, obscure them on the way in but then that makes it more
difficult for me. That was one of my larger concerns, really (revealing
internal hostnames).
On Mon, Jan 31 2022, Drew DeVault wrote:
> Your [ssh] public keys are, as the name suggests, public.
Why must they be exposed publicly, though? Is there an operational
reason?
>> Along the same lines, I believe that tar.gz files are more difficult to>> open than ZIP files on Windows and Mac. It would be nice to have tags>> downloadable as zips also.>> NACK, we do not care about proprietary operating systems.
So I've been a Debian developer for 25 years and Debian or FreeBSD have
been my primary desktop environment. My kids use Debian and my wife's
personal laptop also runs Debian (she's not a technologist). I
absolutely get this and share these ideals.
And yet, one of the things I was doing on Github was making COVID data
downloadable by the public; I wrote a Rust program to assemble data from
public sources and used GH actions to make it into an easily-digestable
form. I no longer maintain this. But like right then is not the time
for me to have to teach people about tar or Linux.
Some people have no choice; my wife's work laptop runs Windows. She
uses org-roam (and that's it from Emacs) so I figured out how to install
Doom Emacs and org-roam for her there. She's also used LibreOffice on
work laptops and such. Though she would unlikely be using Linux or
Emacs if it weren't for my help.
My point being - engagement can bring small victories for FLOSS too. I
am probably as appalled as you at how many devs use MacOS to write Linux
code, but nonetheless my projects are small and I don't want to throw up
barriers to participation in Open Source even if they may not be able to
embrace it to the same extent that I am.
Thanks,
John
John,
> I use org-mode (.org) files quite a bit, and fairly extensively for> documentation. Github and Codeberg (Gitea) render those, but Sourcehut> doesn't. Is there any possibility Sourcehut might render org files in> the near future?
i also use org-mode a lot. fwiw, my solution here is a git hook:
----
bash apollo2 (master): {51533} cat .git/hooks/post-commit
for name in $(git log -1 --name-only --pretty=format:); do
if [[ "${name}" == "README.org" ]]; then
make readme;
fi;
done
----
so that when i check in README.org, make produces (and checks in)
README.md:
----
${READMEMD}: ${READMEORG}
${EMACS} $< --batch -f org-md-export-to-markdown --kill
${GIT} commit -m "from ${READMEORG}" ${READMEMD}
readme: ${READMEMD}
----
it took me a while to get around to do this, but it works surprisingly
well, such that i mostly don't even notice it happening.
cheers, Greg
> My point being - engagement can bring small victories for FLOSS too. I> am probably as appalled as you at how many devs use MacOS to write Linux> code, but nonetheless my projects are small and I don't want to throw up> barriers to participation in Open Source even if they may not be able to> embrace it to the same extent that I am.
I agree with the sentiment.
That being said, my opinion regarding this specific case is that
the tar.gz files don't pose a significant barrier to
participation. But I realize that a barrier is a barrier, big or
small.
Still, I don't think that the cost & complexity required to
support other formats than tar.gz would be worth the benefits in
this case. I think developers need to and can easily learn how to
deal with tar.gz files regardless of the platform they are using.
So I acknowledge the trade-off here but I would choose not to
support other compression formats either in this case.
But again, I understand the general sentiment. I think it boils
down to whether Sourcehut cares about those small victories for
FLOSS. Which is another discussion.
On Mon, Jan 31, 2022 at 10:22:15AM -0600, John Goerzen wrote:
> On Mon, Jan 31 2022, Drew DeVault wrote:
[...]
> >> Along the same lines, I believe that tar.gz files are more difficult to> >> open than ZIP files on Windows and Mac. It would be nice to have tags> >> downloadable as zips also.> >> > NACK, we do not care about proprietary operating systems.>
[...]
> And yet, one of the things I was doing on Github was making COVID data> downloadable by the public; I wrote a Rust program to assemble data from> public sources and used GH actions to make it into an easily-digestable> form. I no longer maintain this. But like right then is not the time> for me to have to teach people about tar or Linux.
If you think it's worth it, you can always create a ZIP file from a
builds task, upload it somewhere and link to it from the README (or the
project's website).
Rene
On Mon Jan 31, 2022 at 7:49 PM CET, gwn wrote:
> But again, I understand the general sentiment. I think it boils> down to whether Sourcehut cares about those small victories for> FLOSS. Which is another discussion.
I think the question has more to do with whether or not propping up
the legitimacy of proprietary operating systems by implementing bad
features that they understand really does win a victory for FLOSS. In my
books, it does not.
> Still, I don't think that the cost & complexity required to> support other formats than tar.gz would be worth the benefits in> this case. I think developers need to and can easily learn how to> deal with tar.gz files regardless of the platform they are using.
Seconded. FWIW Python standard library supports it out of the box
and one should be able to expect the equivalent in other toolings.
I also use Org Export to generate README.md from Org Mode files.
However, Sourcehut is a favorite of many Emacs users (so much so that
they are seriously discussing a move to Sourcehut), and I think it would
be very useful if this step were eliminated.
I wish there was a good Python library to render Org mode.
On 1/2/22 02:44, John Goerzen wrote:
> On Mon, Jan 31 2022, Andrew Fontaine wrote:> I did not know that. Interesting. Though I notice Github (at least)> obscures the hostnames in the keys, while Sourcehut doesn't. I could,> of course, obscure them on the way in but then that makes it more> difficult for me. That was one of my larger concerns, really (revealing> internal hostnames).
For anyone who wasn't aware, an SSH public key is of the form:
ALGORITHM DATA COMMENT
...where ALGORITHM is a string like "ssh-rsa" that determines how DATA
should be parsed: https://www.rfc-editor.org/rfc/rfc4253#section-6.6
Meanwhile, COMMENT is arbitrary and can be anything at all. ssh-keygen
defaults to "$USER@$HOSTNAME", but there's no reason you can't change it
to something more relevant to you and more generic to other people, like
"from my work laptop" or "from my secret moon base".
It looks like GitHub removes the comment (or I just didn't bother
pasting it in), while GitLab changes it to "$GITLAB_USER (gitlab.com)".
Those use-cases are probably better for the vast majority of people who
only generated an SSH key because the website told them to, but
SourceHut's approach of recording and reporting the comment it was given
seems more useful to people who use SSH regularly for non-Git related tasks.