dietlibc VS gitlab

- Dietlibc: https://www.fefe.de/dietlibc/

The commercial success of a product totally depends on the business model you come up with, whatever be its opensource (or not) license.

Corporates have a vested interest in promoting the propaganda that only a non-xGPL opensource license can be commercialised successfully simply because they cannot freely steal the source code of a competing xGPL licensed software.

The real value of an FSF license, like the AGPL, is that it was designed to protect the copyright holders, and its users, "right to repair". And thus, it cannot be closed source by anyone (apart from the original copyright holders) once released under the said license (even if future versions are closed source, the old version under xPL remain opensource perpetually). Other open source license (that are less stringent) are prioritised to increase developer contribution. Source code under such license can be closed-source even from the original copyright holder.

But again, commercial success totally depends on the business model you come up with, irrespective of your license. The right license and the right business model will empower each other. Or cripple your business.

Stefan Tomanek - Creator of dietlibc, a libc optimized for small size - https://github.com/stefan-tomanek (The dietlibc project itself doesn't have an official GitHub repository, but you can find it at https://www.fefe.de/dietlibc/)

There are definitely some nice alternatives to glibc out there. He mentions Cosmopolitan Libc. I've used musl, uclibc, and dietlibc/libowfat in the past.

Maybe you should include the math part of a libc statically with your code. glibc is one option, or dietlibc if you want it to be as small as possible.

I agree that the implementation of printf is complex, but the interface is not. Hence calling it should not introduce bloat. Glibc adds a bunch of constructors and tables and such, whereas linking with dietlibc will probably lead to a smaller executable.

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...