~strahinja

Belgrade, Serbia

https://strahinja.org

Mathematician and Libre software programmer. Started with Basic in the 1990s, current focus: C, suckless programs.

~strahinja/public-inbox

Last active 3 years ago
View more

Recent activity

Re: Add pr.pico.sh to sourcehut? 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/14 04:13PM, Jakob написа:
> Yes, but compare that to GitHub: Click the green button to fork, 
> clone your repo, commit, push, click the green button to make a PR and 
> done.

I don't like clicking JavaScript buttons on web pages selling my data 
to third parties or feeding my code to AI if I can avoid it. Sometimes 
it is regrettably the only way to contribute to Free Software projects, 
_only_ because they aren't present on a code hosting platform like 
Sourcehut.

In contrast to this, I use simple command line and TUI programs to get 
the job done in a straightforward, efficient and controllable way. I 
use Neomutt as email client, I use Vim as my main text editor (and my

Re: Add pr.pico.sh to sourcehut? 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/14 03:04PM, Jakob написа:
> - A contributor has to enable SMTP in the settings of most mail 
> providers.

Email "providers" that don't support SMTP, like Tutanota, suck anyway.
Probably the most widespread free email provider, Gmail, currently
supports SMTP, and works with SMTP clients. Personally, for Gmail I'm
using msmtp[1] with its "allow insecure applications" setting and
"application password" even unrelated with Git, so I'm also using it
for Git. (I also use msmtp for my hosted email server.) The usage of
msmtp in Git is easily set up by adding this to .gitconfig:

	[sendemail]
		from = Your Name <youremail@host.com>

Re: Add pr.pico.sh to sourcehut? 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/14 02:37PM, Jakob написа:
> because the mail workflow is confusing, 

What is confusing about it exactly?

https://git-send-email.io/

Re: Clearer contribution and deployment guides 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/12 08:23PM, Monti написа:
> our Russian buddy 

*Serbian, though it is irrelevant to the discussion.

Re: Clearer contribution and deployment guides 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/12 07:29PM, Monti написа:
> This would be a traditional way for very technical users who are deeply
> familiar with the Linux kernel contribution workflow, I think Sourcehut
> should also consider less experienced users coming from git forges like
> Gitlab, Github or Codeberg (forgejo).

The motto of Sourcehut is "The Hacker's Forge". Its appeal is precisely 
in its difference from mainstream source hosting sites, mainly Github. 
It is geared towards a non-mainstream, alternative audience.


> Personally, I'm very used to contributing through pull/merge requests, but
> that doesn't mean I'm not open to discovering and maybe even changing my
> workflow.

Re: Clearer contribution and deployment guides 2 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/07/12 06:13PM, Monti написа:
> The simplest fix would be to put the introduction in its own section and do
> the same for `hacking', but renaming it to "developing" or "contributing" as
> the original title is another design flaw that I do not think I need to
> explain, as anyone who will think for at least 10 seconds will figure that
> out.

If you haven't already, I strongly suggest you read this:

	https://stallman.org/articles/on-hacking.html

it is the rationale behind this terminology, and one of the hallmarks 
of Free Software culture.

Re: Centralized repository hosting 4 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/05/23 10:59AM, Matěj Cepl написа:
> I know about OpenBSD, but let me just not comment on them … I
> would think it is their extreme conservatism they have never
> switched, and the close character of their community which make
> us unable to understand the context of their decisions, but let
> keep them as an outlier.

... and then a comment was made anyway. :^)

What can be found by a web search on this matter is that CVS "just worked" for 
the OpenBSD developers when they started, and now the hassle of migrating to a 
new versioning system outweighs the potential benefits. The system in 
development that I mentioned, got, supports importing from CVS and works with 
git trees, so could make the transition from CVS less painful. At the same

Re: Centralized repository hosting 4 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/05/22 05:45PM, Matěj Cepl написа:
> I mean, really [1]? If you really want to use CVS, then get help,
> the last stable release of CVS was 16 years ago [2], and there
> has never been a reason to use it even before. The fact that some
> operating systems are still developed in CVS, … I should probably
> not comment on that.

Main versioning system used in OpenBSD development is CVS, which didn't hinder 
it being perhaps the most proactively secure OS in existence.

* * *

That said, finxx, if you are using OpenBSD, recently I started transitioning to 
got[1], which I highly recommend trying out. It is a OpenBSD-based versioning

Re: Article about flaws of Sourcehut 5 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/05/02 01:19PM, Moritz Poldrack написа:
> This is a non sequitur, I think. Being able to use a system like the
> email-based workflow has no bearing on whether or not they are able to
> provide worthwhile contributions. That is ignoring non-code contributions
> like documentation changes, issues, or translations.

Maybe it is not immediately obvious, but it is still a filter.

Programmers won't have any issues with it. "Coders" might.

Re: Article about flaws of Sourcehut 5 months ago

From Страхиња Радић to ~sircmpwn/sr.ht-discuss

Дана 24/05/02 11:49AM, raingloom@riseup.net написа:
> Not every contribution is code.  If you make it difficult for people to
> report issues or contribute docs, you are going to end up with a worse
> product.

Regarding reporting "issues", I don't see the problem. Anyone finding
writing emails hard would have a hard time using most software anyway.

See here for an example of how problem reporting should be done:

	https://www.openbsd.org/report.html


Contributing documentation is not that different from contributing