There are both x64 and ARM64 RPM and Debian packages available for this closed-source Linux app.

One more reason to stick to my current niche distro :-D

BTW: out of curiosity, I just went to chatgpt.com and asked:

briefly, what’s the recommended way to distribute a desktop app on linux?

The answer wasn’t brief (at least for my definition of “brief”: it started with a bullet list of all possible packagings) but it ended with:

If you want one recommendation: ship Flatpak + AppImage. Flatpak for normal installation/updates, AppImage as the portable fallback.

Hand-coded or LLM-coded?

IDK if I’ll try it but… you should really change the distro’s claim: “unix for human beings” sounds like the distro is an ubuntu ripoff.

You’ll need networking basics for anything you do (there are lots of courses on youtube).

After that, you can just follow wherever you curiosity carries you :)

Might be that you are at the end of your distro-hopping journey, which isn’t when you have found the perfect distro, but when they all start to look the same

Sure thing!

(also, please do post about it when you eventually decide to switch to linux)

Does i3 do wayland?

Setting up an OIDC provider isn’t particularly difficult, but you’ll have to run it as a publicly accessible server in order for tailscale to interact with it.

It looks like you can register at netbird.io with email and password.

In your shoes I’d setup that for now, and later look into OIDC or (probably better) into self-hosting nebula (or maybe netbird).

Just try and see how it goes - it’s not like you can’t go back

IDK about the current status of x86 with android, but last time I checked it wasn’t good.

Lineage might be your best bet… it supports a few androidtv boxes (most notably the nvidia shield) see https://wiki.lineageos.org/devices/

where SyncThing is overkill

I just have a dedicated shared folder between my phone and desktop and drop oneoff stuff there (it’s also easier to script this way)

For files I use syncthing (also for music/photos/notes/etc… syncing files is IMHO the way to go wherever applicable).

For sending links to my PC (eg. articles linked from podcasts’ notes) I used to rely on firefox sync, but I’m starting to distance myself from Mozilla so I am gonna experiment with wallabang.

For sending small notes to myself (stuff that I want to sort or act upon when I get to my PC), I’m using signal’s “note to self” but I’m investigating alternatives because signal doesn’t mark such messages as unread and so sometimes I forget I’ve sent some.

That’s called dogfooding, not self-hosting :)

Let me get this straight though: I’m not saying no project self-hosts their code (eg. IIRC both KDE and Gnome do), I’m just saying that the majority of FOSS projects (including those that are dedicated to self hosters) does rely on some sort of third party to host their source code.

I don’t think it’s fair to criticize a FOSS project just because they rely on a third party (even commercial ones) to publish their source code.

Yep but eksb’s comment was about selfhosting, not FOSS or ethics (same can be said for this community, although that’s less relevant than the specific comment of course)

Even that is questionable to say the least: while codeberg is the main fogejo contributor, the forgejo project and codeberg are separate entities with separate governance and funding.

I’ve blocked the bot because I find it’s more annoying that useful (I’m not complaining - just giving feedback).

That said, IMHO from that list you should remove the entries that:

• are ambiguous (eg: HA has 2 entirely different meanings in your list)
• have become words on their own (eg. DNS, HTTP, etc…): nobody cares what these expand to (think, NASA) and also knowing what these expand to doesn’t help at all (if you tell me that HTTP means “hyper-text markup protocol” will I not have to go read wikipedia anyways to understand what it is?)
• are often not used according to your definition (eg. IP is more often used to refer to an IP address rather than to the protocol) - of course you may want to amend the definitions instead

Also, you should keep the acronym expansion (“RAID” => “Redundant Array of Independent Disks”) from any comment you may want to add (“for mass storage”) and - since you are at it - provide relevant links to wikipedia articles and/or other resources.

PS: since a lot of entries in the list are not even acronyms… maybe you should consider renaming the bot to something related to “abbreviations” or “glossary”?

What self-hosted software you use is not hosted on some third party forge?

Synchthing if I want local copies, otherwise I just mount sshfs shares from my nas (using sftpman as a helper)

you will have to spend a lot of time learning the Nix language

I’d say you shouldn’t use any system (be it nixos, ansible or even bash scripts) if you are not willing to learn it.

That said, I too find pre-made modules less useful that I initially thought when I got into nixos: unless you want to do very basic stuff, a lot of times it’s easier to just generate whatever scripts/configuration files you need directly (using one of the trivial builders in lib or writing a custom derivation) rather than learning how the corresponding nixos module works.

One could say nixos modules make easy things slightly easier, and hard things much harder (this is adapted - possibly imprecisely - from a quote on ORMs, I think by Joel Spolsky).

In your shoes (and, in fact, in mine) I’d try to move away from interactive tools and into file-driven ones.

Personally I use nixos, run WUD (what’s up docker) to be notified of available updates, and manually test/update the containers once in a while (every couple weeks or so?)

There are a bazillion other solutions (from stuff like ansible/chef/puppet, to docker-compose, to kubernetes, to… a hand-written bash script) - the idea is to setup stuff via files that you can version, reference and write comments in rather than using some gui for interactive steps that you’ll forget to document in some wiki.

Monitoring is a whole different beast than configuring: you’ll be probably better off using something that does just that instead of some all-in-one solution. Try looking into something like beszel before going for the full prometheus/graphana stack.