~wolf480pl

Poland

https://wolf480.pl

~wolf480pl/my-cool-project-devel

Last active 3 years ago

~wolf480pl/my-cool-project-announce

Last active 3 years ago

~wolf480pl/postjs

Last active 5 years ago
View more

Recent activity

Re: RFC: Organizations 1 year, 6 days ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

Disclaimer: I'm don't actively use sourcehut, just thought my insight could be useful

W dniu 13.03.2023 o 17:23, Ingo Hoffmann pisze:
> I see where you're coming from. My main concern is that, IMHO, billing should
> be more protected/has an extra layer of security.

I think if sourcehut wants to be used by companies,
it's important to be able to designate a user who can access *only* billing,
and not have any write access to repositories or team membership.

This allows giving someone from accounting/finance access to just the information
they need to pay the invoices without going through the person managing access.

W dniu 13.03.2023 o 15:59, Drew DeVault pisze:

Re: Discuss: proposed changes to the SourceHut terms of service 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 04.06.2020 o 19:44, Jordan pisze:
> [...] Another could be allowing non-foss projects to be hidden on the 
> platform, from the person’s profile/projects and activity and search function. Meaning the public can only interact with that repo or project 
> via a direct link. 

I think this is how unlisted projects work at the moment?
And as far as I understand, this proposal would still allow
for unlisted repos to have proprietary licenses.

Re: Discuss: proposed changes to the SourceHut terms of service 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 29.05.2020 o 15:52, Zachary King pisze:
> You can't grant a license for something you don't have
> rights to. You would need to transform it in some way to
> gain copyright, which you could then put under any license
> you want. See this article by CC. [1]

ok, from the article linked:

> If the work is in the public domain [...] the application
> of a CC license is ineffective

IOW, adding a LICENSE file to a non-copyrightable work is a no-op,
right?

Re: Discuss: proposed changes to the SourceHut terms of service 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 29.05.2020 o 15:05, Sam Whited pisze:
> What about repos that are not actually copyrightable? For example, I
> maintain a list of folk dances (some that I have written, some by other
> callers). In the U.S. at least these are not copyrightable even if
> you're the author of the dance, so a license like CC would not apply.
> 

IANAL, but if you grant a permission (a license) to someone
who doesn't need your permission, does it really hurt?

Re: SourceHut project hub 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

On 08.05.2020 at 17:01, Drew DeVault wrote:
> You have to dismiss it [the checklist] before the
> project will be listed.

That sounds pretty counterintuitive to me.

But if you want to keep that feature, maybe you could at least make it
more obvious that the dismiss button finalizes project creation?
Eg. make it a big blue button at the bottom of the checklist saying
"Publish project" or something like that.

Re: sr.ht wikis aren't 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 06.05.2020 o 17:02, Geoff Beier pisze:
> On Wednesday, May 6, 2020 10:45:44 AM EDT Drew DeVault wrote:
>> Such a feature is planned for man.sr.ht, so I think it qualifies, or at
>> least can be forgiven for being an incomplete alpha-quality project.
> 
> And isn't editing possible today via git send-email? Even wikipedia has access 
> controls... that doesn't seem to pull it into "not a wiki" territory.

One could argue that you're not editing it "directly",
as it's not through the website / through the same interface
that you use to read it.

Re: sr.ht wikis aren't 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 06.05.2020 o 16:28, Colby Russell pisze:
> Here are some links instead:
> 
> * <https://www.amazon.com/exec/obidos/ISBN%3D020171499X#The_Wiki_Way:_Quick_Collaboration_on_the_Web>
> * <https://en.wiktionary.org/wiki/wiki#Etymology>
> 

I don't think these links will be particularly helpful,
but I found the following definition of Wiki on Wikipedia:


> A wiki is a hypertext publication collaboratively edited and managed
> by its own audience directly using a web browser.

Re: DKIM fail? 3 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

On 30.04.2020 at 10:10, Simon Ser wrote:> Progress: it seems 1.1.1.1 doesn't see/accept your DNS TXT record. On

> my machine, this works:

>

>     drill TXT rincewind._domainkey.dreamfall.space

>

> But this doesn't:

>

Re: Supporting user groups/organizations on SourceHut 4 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 15.02.2020 o 11:33, Noah Loomans pisze:
> I wonder if groupnames are allowed to overlap with usernames? It could
> cause some confusion if both the user ~example and the group +example
> exist. Also, this could possibly be used for phishing as well. Imagine
> the group +example hosts their code at git.sr.ht/+example/project. Now
> an attacker could create git.sr.ht/~example/project, which looks the
> same but contains malicious code.
> 

Or they could create git.sr.ht/+examp1e/project
or git.sr.ht/+exarnple/project.

Depending on your font, these may be easily confusable with the original url.

Re: Supporting user groups/organizations on SourceHut 4 years ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 14.02.2020 o 17:31, Ludovic Chabant pisze:> [...] I don't
> know why we need a prefix though. The absence of a tilde is enough to
> tell it's not a user. And if the parallel with Unix is what we're
> shooting for, in Unix users have the tilde prefix, but groups don't
> have any prefix.

I know two places in unix in which you can put both a user and a grup,
and since they can have the same name, you need to disambiguate with a prefix:
- in chown, you specify groups as :mygroup
- in /etc/security/limits.conf, you specify groups as @mygroup

> The only point of a having a prefix for groups is if you have plans to
> have a *third* "thing" later down the line, and we need to
> differentiate between all three (although even then, 2 could have