Sven Slootweg (soft-deprecated) @joepie91@pixie.town

Apparently indie game development sometimes looks like this

hell yeah, love it when moderation actually happens. got a report of a remote user, opened it right away, and the remote instance had banned them before i could even view their profile lmao

So this is what I need to find:

- an on screen keyboard that works with Arrow Key + Enter navigation (to be used with a USB Remote without an airmouse.)

- a wifi configuration utility that is entirely navigable with arrow keys + enter + escape (with OSK for text entry.) Ideally something that can run in a terminal.

- ... I think that's it. If I can find solutions for those two things, I can probably whip up a prototype this afternoon.

A quick thought on the "criticism of generative AI is classist and ableist" bs, and why it's so fuckin' insidious:

Yes, those are genuine issues. AI is not a meaningful solution to *any* of them.

The solution to "there aren't enough non-English speaking/disabled/working class voices being published" is not and *never will be* "here's an ethically abhorrent tool that fundamentally reshapes marginalised voices into the statistical mean voice of those already published"

@cynicalsecurity short answer: yes
daemonising is, as a concept (forking into background), essentially incompatible with go runtime model, which implements its own M:N threading and uses OS threads rather loosely, and it's trivial to end up in a situation where the process would already have some threads started before it would reach your daemonizing code.

long answer: still yes, but daemonizing is bad anyway.
as a preface, the following is coming from being burned in many ways by processes attempting to drop privileges and daemonizing on their own. most often by silent failures with nothing on stdout/stderr/logs; but sometimes by leaking/retaining elevated privileges when they weren't supposed to.

self-daemonising is surprisingly difficult to do properly in general, arguably maybe even impossible if your code is anything but a statically linked executable directly interfacing with the kernel syscall interface (not even going through libc) because of how many things happen before "your" code is reached in process lifetime.
i've seen services dropping privileges improperly too often to trust just about any service to do so, regardless of what programming language they're written in, and instead i strongly prefer to have a service manager that would setup proper environment (privs dropped, etc etc) first, and then start the service.
if nothing else, there's less security sensitive code to audit, and it's in just one place, instead of having a myriad variations, with every service author implementing their own slightly different way of doing things.

toxic minimalism is a thing.

The three genders

source: unknown