zlacker

>>pjmlp+(OP)
Is this microsoft-docker for GUI apps?

>>london+Hj
More like yet another half-assed attempt at cgroups. Not saying cgroups is chopped liver, but at least it has in broad use with lots of users, tools and experience over a long period of time.

Microsoft has yet to come up with something even half as useful and popular. So far their best effort has been WSL2, and it's working well because it's linux, not because it's windows containers (which is something else).

This is pretty frustrating because they have plenty of money and smart people to throw at it, yet at every turn we get something that just doesn't match what people want and need, instead we get something that might look good on a keynote slide.

>>onepla+Gr
Windows has had cgroups before they were even an idea on Linux via Job API.

>>pjmlp+LQ
That's the problem, the Job API is not cgroups and cannot be used as cgroups.

NT also had multiple personalities or subsystems before KVM or QEMU were even thought of, yet here we are, a useless feature with no traction and no ecosystem.

The point isn't the features that a thing like cgroups provides, it's the adoption, and that is something you cannot enterprise your way into like you can with desktop software like office.

If you reverse the statement: why is the Job API not used with OCI, Windows Containers or WSL, and was a replacement created (twice no less, WSL1 and WSL2 are very different) and a virtual machine with linux the only real adopted method for containers.

(answer: because everything else that was attempted just failed one way or another, regardless of de academic or enterprise-ish correctness of those attempts)

>>onepla+AS
I thought jobs were used for Windows Containers: "Windows containers utilize job objects to group and track processes associated with each container. Resource controls are implemented on the parent job object associated with the container."

https://learn.microsoft.com/en-us/virtualization/windowscont...

>>ripley+Pu1
Ah, you are right. I thought it mostly relied on Hyper-V isolation (a bit like core isolation) and the process grouping was mostly a bonus inside the Hyper-V context, but apparently this works without Hyper-V as well so it would make sense that you'd just use the Job API.

Maybe if there was some ProjFS-style text I/O for the Job API someone would have made a OCI-like container format, but I suppose even then it would be too different to be embraced like Docker was when it was released. You'd need to have it combined with WinFsp or a FUSE-alike adapter and it might even be possible to have layers and use a union/merge/overlay FS. Putting that side-by-side with containerd and cgroups2, it would still look rather Frankenstein-ish; not very windows-y, and not linux-ish either.