~wolf480pl

Poland

https://wolf480.pl

~wolf480pl/postjs

Last active 11 months ago
View more

Recent activity

Re: Supporting user groups/organizations on SourceHut 13 days 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 13 days 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

Re: login is too smart 6 months ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

Hi

AFAIK it logs you back in because you're still logged into meta.sr.ht

I know 2 ways to avoid that:

a) go to meta.sr.ht and log out there

b) use your browser's private mode for the second user

Regards
Wolf480pl

W dniu 24.08.2019 o 10:02, Uwe Brauer pisze:

[PATCH git-rebase.io] Note the difference between soft and mixed reset 9 months ago

From Wolf480pl to ~sircmpwn/public-inbox

Add a footnote explaining the difference between a soft reset
and a mixed reset.

Also renumber footnote 3 to 4, to keep the order consistent
with their appearance in the text.
---
I'm not sure if my explanation is understandable enough to the target
audience, but I hope it's better than nothing.

 index.html | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/index.html b/index.html
index 6f04872..a3e6610 100644
[message trimmed]

Re: builds: public ip address range 9 months ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 04.05.2019 o 00:33, Paul W. Rankin pisze:
> [...] you'll stop 99.9% of bot login
> attempts by changing the port sshd listens on to something random, e.g.
> 2201.

Keep in mind mind that ports above 1024 by default don't require root
privileges to listen on.

So any program on your server could try to listen on eg. port 2201,
while if you used eg. port 922, only root could listen on that port.

Depending on your situation and configuration of your system,
eg. whether there's a chance your ssh server dies, and whether something
(eg. systemd) will keep the socket open, whether you give other people

Re: ArchLinux image does not find a package 10 months ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 26.04.2019 o 10:41, Adolfo Santiago Mouge pisze:
> I looked at the doc but didn't see anything there...
> 
>> Maybe you need to enable the multilib repo?

I don't know if builds.sr.ht has its own way of enabling multilib repo,
but you can always use the generic arch way of doing it,
i.e. uncomment the right lines in /etc/pacman.conf

I made an example builds.sr.ht job that does that and then installs
lib32-zlib. (Then it also prints the content of /etc/pacman.conf,
which you don't have to do, I just wanted to see if the patch
applied correctly).

Re: my journey on selfhosting git.sr.ht 10 months ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 06.04.2019 o 17:02, Artem pisze:
> here it goes: http://ix.io/1FsY

Nice read, and cool idea with including the bash_history verbatim

> aha! it turns out the systemd file actually uses gunicorn web
> server which we're missing. let's install that:
> 
>    75  yaourt -Suya gunicorn
> yaourt -Suya python-psycopg2 # meh, why i even have to do this manually? life sucks

I wonder why these are not even optdeps of the package.

> it's like i'm in 1994 and i have to maually createeverything from scratch

Re: Rust is not a good C replacement 11 months ago

From Wolf480pl to ~sircmpwn/public-inbox

Thanks for this article. I mostly agree with its points,
and I definitely agree that Rust is not a good language
for most of the usecases of C.

A few remarks though:

> Idiomatic C++ looks nothing like idiomatic C

Depends which C++ you mean. I think the idioms of C++ have changed
multiple times, and even the libstdc++ isn't idiomatic C++.

I've seen a lot of code written in C++ which looks more like C with
classes than idiomatic C++, for example in game engines. And I guess
the C/C++ term comes from the times when that style was idiomatic.

Re: Reject only HTML emails without text/plain alternative? 11 months ago

From Wolf480pl to ~sircmpwn/sr.ht-discuss

W dniu 23.03.2019 o 06:48, Simon Ser pisze:
> On Saturday, March 23, 2019 7:11 AM, Paul W. Rankin <hello@paulwrankin.com> wrote:
>> This would permit people to make quick replies that do not require being
>> at their computer (e.g. I can only ensure I'm sending text/plain email
>> wrapped at 72 chars by using FastMail's desktop UI).
> 
> But maybe it's a good thing, since it ensures you don't send
> non-wrapped e-mails? (lists.sr.ht won't display non-wrapped text
> properly, there are other discussions about this)

Maybe let's go one step further and ask:
Do we want quick replies made from a smartphone?
Wouldn't that mean they're done hastily, without much thought before
pressing the "Send" button?

Re: Status update, March 2019 11 months ago

From Wolf480pl to ~sircmpwn/public-inbox

Regarding your problem with SD card - I think it may be helpful
to look how Samsung handles it in their MuxPi[1], SD MUX[2]
or SDWire[3].

They use a special cable that plugs into an SD card slot[4]
to route all the SD card signals through their multiplexer
circuitry, which lets them dynamically switch the SD card
between being plugged into the supervised board,
and a USB card reader.

I don't know how hard it'd be to replicate what they're doing,
or to buy any of those, especially the cable, but I've seen
a MuxPi available for sale somewhere a while ago.