obsidian-wielder VS gitlab

Depending on which particular subject you are interested in:

- The plugin:

https://wielder.victor.earth/Welcome shows the sort of things you can build with Wielder. The github repository for the library is here https://github.com/victorb/obsidian-wielder

- How To Solve it

The key ideas behind How To Solve It are that for a lot of our challenges there are strategies we can use to tackle them effectively. How To Solve It expounds on how to go about understanding a problem, understanding the connection of the data you have with what you don't know, how to make problems more tractable, carrying out a plan, and evaluating the results.

- Untools

A site dedicated to listing various strategies for thinking, communicating and prioritization; they sell templates similar in nature to what I'm building, but I depart sharply from them in my desired document representation choice for templates - Zettlekastian graph continuations for me versus linear documents for them.

- My own tool

This is currently private and not yet ready for public consumption. I have a whole lot of philosophical backing for what I'm trying to build but it is still very far from generating utility at the level I want it too. Later today I'll see about moving some private notes into a blog post going into more depth about what I'm building and why.

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...