CapNProto RPC protocol

Because some auth provider recommended it as the only app to use. While it is a good app, it does backup into Drive.

While it’s not a perfect solution, you can export and backup your data with QR codes, so you can back it up without cloud.

Is this useful if I am using pi coding agent? It can swicth between models mid session?

Forgejo is also OSS, so you can easily migrate git and issues and prs and everything to your own hosted instance, if codeberg proves untrustworthy. Which I can't on github.

Could the title say "process to install non-curated Android apps"? "Sideload" and "unverified" imply that the collection of centrally approved apps is the default way to install software.

Or maybe it is and android's promises about openness are dead.

The `:` prefix is an interesting choice. I don't fully understand when it is needed. It seems to always be used at the beginning of the query. But why is it not used before WHERE?

The : prefix marks OmniQL commands, the action you want to perform (:GET, :CREATE, :DELETE, etc.). It's how the parser distinguishes OmniQL syntax from native SQL or other query languages. WHERE, AND, OR, LIMIT etc. are clauses. They modify the command but aren't commands themselves. So the rule is simple: commands get :, clauses don't. Think of it like a terminal. You prefix the command (git push) but not the flags (--force). Same idea here.

Why does JOIN get the prefix then? Is it a command? I would assume that it is a GET clause.

In OmniQL, JOIN isn't a clause inside another query. It's a standalone operation. You write :INNER JOIN Order User ON user_id = id, not :GET ... JOIN .... Since it starts the query and tells the engine what to do, it gets the : prefix. The rule is: anything that begins a query gets :, anything that modifies it (WHERE, ON, LIMIT) doesn't. This is actually a deliberate design choice. In SQL, JOIN lives inside a SELECT so you end up with one big statement doing multiple things. In OmniQL each : command does one thing. Flat and predictable rather than nesting clauses inside clauses. This also lets the engine translate consistently whether it outputs SQL JOINs for Postgres and MySQL or a $lookup aggregation pipeline for MongoDB. Same syntax, engine handles the rest.

I like arrow for its type system. It's efficient, complete and does not have "infinite precision decimals". Considering Postgres's decimal encoding, using i256 as the backing type is so much saner approach.

Yea, I have this too. It sometimes reminds me about the thing I was doing before I got distracted.

I wanted to try tauri out, but i couldn't get the nix dev shell for it working. My suspicion was that they do something too magical with the build process.

My launcher of last 8years: Lawndesk. It's not on play store and you have to download it from github, but it is the only no-nonsens launcher on android without a drawer.

I just want a grid of apps, each of which appears exactly once. And then folders, to keep things on known locations