fonix232

The recommendations so far are quite solid.

I’d also add that crowdsec with the right collections as a primary filter within your reverse proxy setup can be extremely useful, potentially even better than fail2ban, as CS delivers a literal “scan every packet and put them against these rules” approach - where the rules are crowd sourced, thus are more up to date than any manual blocklists, filter list etc. can be, and can spot even 0day intrusion approaches.

It depends on the app. You can use Authentik as an OIDC provider and allow apps that offer OIDC to log in through that - and that usually works for TV sticks and such.

Uhm, no.

Only if the licence allows. I personally go for A/GPLv3 wherever I can because I don’t want corporations to just take and not contribute back. But that means I can’t just copy MIT/Apache software, need to do my own implementation from scratch. Which I prefer anyway.

I’d argue that AI does change things:

• on one hand it increases the percentage of invalid/unusable images. A mis-labeled image is still potentially useful, an image of a toucan in the Arctic isn’t. This means that even large datasets become largely unusable because of the volume of fake images.
• on the other hand any AI picture that slips through, taints the dataset and results in expensive manual cleanup to ensure data is reliable.

why would I try a book REQUESTING system when I’m working on my own AIO solution?

I’m actually working on an all in one solution that sort of fills the roles of Readarr AND Calibre - without all the baggage of the latter.

Oh, and of course a KOReader library plugin that foregoes OPDS and works like the Kindle interface (“available books” synced from this backend, one tap downloads them, plus potentially adding series handling too in the future).

But right now it’s mostly manual downloads + CWA ingest + OPDS via KOReader.

.desktop files are essentially used similar to Windows’ registry - you create such a metadata file in a specific location, and it acts as a launcher, autostart setup, and file type assignment (so you can easily assign e.g. PNG files to open with Krita by default).

As the wiki says, you can put multiple MIME types (file type descriptor such as “text/plain” or “application/json” or “image/jpeg” and so on) onto one dotdesktop file, meaning you only need a single launcher to support all file types.

Krita explicitly creates quite a few dotdesktop files, each supporting only a single MIME type.

Downside: littered desktop.

Upside: you can easily pick and choose which file types to open with Krita directly.

Most desktop environments actually handle the [samename]. extension.desktop repetition so you’ll only have one Krita launcher entry but it will still collate all MIME type support that is present. Want to exclude e.g. BMP files? Delete the .bmp.desktop file.