Daniel Vetter

>> In a Flatpak you have (?) to assume the system glibc is incompatible with the bundled one either way, thus you can’t assume you can load host libraries.

> Not exactly. You must assume that the host glibc is incompatible with the bundled one, that's right.

> But that does not mean you cannot load host libraries. You can load them (provided you got them somehow inside the container namespace, including their dependencies) using the linker inside the container.

I meant that the glibcs are potentially ABI-incompatible both ways, not just that they’ll fight if you try to load both of them at once. Specifically, if the bundled (thus loaded) glibc is old, 2.U, and you try to load a host library wants a new frobnicate@GLIBC_2_V, V > U, you lose, right? I just don’t see any way around it.

>> These libraries require carnal knowledge of the kernel-space driver, thus emphatically cannot be bundled; but the previous point means that you can’t load them from the host system either.

> Yes and no; Intel and AMD user space drivers have to work with variety of kernel versions, so they cannot be too tight. Nvidia driver has tightly coupled user space and kernel space, but with the recent open-sourcing the kernel part, this will also change.

My impression of out-of-tree accelerated is mainly from fighting fglrx for the Radeon 9600 circa 2008, so extremely out of date. Intel is in-tree, so I’m willing to believe it has some degree of ABI stability, at least if an i915 blog post[1] is…

For the longest time I viewed kernel programming as an exalted realm of "optimized bare-metal software written by visionaries and wizards" (like operating system core developers of the Dave Cutler variety). Having had the misfortune of dabbling in reverse-engineering Windows drivers and debugging in-tree Linux kernel drivers, I now believe they're often messy hackjobs written by low-paid average-skilled embedded developers, no less fallible than the average enterprise Java programmer (https://blog.ffwll.ch/2022/08/locking-hierarchy.html expresses a similar sentiment). And I feel the maintainers are sometimes spread far too thin (Dmitry Torokhov manages a good chunk of Linux's entire input system, no wonder he lets mistakes slip by in the touchpad driver, I'm just disappointed I reported a bug to the mailing lists and never got a reply after like a month).

EDIT: The wizards are out there, for example https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-reordering/, but they're not evenly distributed, and perhaps the insane cutting-edge code they write (and the less insane code I write) isn't necessarily dependable, since by definition they lie on the edge of human understanding.

Here is what email patches are all about:

https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

I tried email patches with another person myself. The only reason GH won here, is because the git people made one fatal mistake: They forgot to include the tree hash and only show the commit hash in the email patch. But the commit hash is useless. When you email patch, then commits people want to treat as "the same" and talk about have different hashes. The commit times differ and there is not only the commit author, but also the committer.

We stopped doing email patches, because commit hashes became useless for communicating with each other.

GitHub made commit hashes "constant" in a way people care about.

For our purposes, tree hashes would have been much better in practice.

The git user interface is literally "git porcelain". It cuts you for no reason.

This is the most upsetting part about it, IMHO. The reason Microsoft pays a salary to this person is precisely to get GitHub mentioned into these sorts of conversations -- even though it's widely known that GitHub doesn't support such usecases.

But, of course, there's never any time to mention such facts; but here's an example if anyone's curious: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html.

Yet when a one-person team tries to provide relevant examples on the issues of dealing with Microsoft, pitching a potential solution, and offering their take on it -- fully open-sourced -- they get discounted as advertisement -- even though their service is free and open source.

I've found quite readable and relatively high level description of memory management and command submission in Linux drivers for Intel GPUs.

http://blog.ffwll.ch/2013/01/i915gem-crashcourse-overview.html

This (plus some low-level register poking) is the stuff you would need to implement in your GPU daemon. Actual generation of drawing commands, compilation of shaders etc is performed by applications.

The overhead should be in the order of few context switches to the GPU server for each frame rendered by any application (in Linux it's few syscalls instead of context switches). Probably not terrible.

Probably this link: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html ?

In that case, yes, that applies to GitLab too. The main problem is how GitHub and GitLab manage subprojects: GitLab forks are strictly hierarchical in how they manage pull requests and contributions (you can only submit patches from your repo to the single repo that you forked from).

But that may not be an issue for per-package repositories like Debian has on alioth. Debian does not have a monotree like the Linux kernel, every (source) package is a standalone project so the same objection does not apply here.