6 ms·

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 co

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.

mike_hearn 3y ago
MSIX files are Microsoft's equivalent of OCI containers and do all those things. It's not well known but here's a brief rundown of the format and tech: - They're zips (sorta, but you can't make them with any existing zip library) - They can contain VFS overlays for system directories. Files placed inside the package under the VFS directory will appear at runtime as if they are installed to c:\Windows\System32 and other well known locations, but only for apps within that package. This is built using an equivalent of unionfs called bindflt. - Apps run inside "app containers" which are at the lower levels composed of job objects and other kernel features. App containers are the basis of all sandboxing on Windows and are the closest equivalent of cgroups. - Writes to the user's home directory are transparently redirected to a separate directory specific to that package. This allows data to be cleaned on uninstall. - You can express various integration points in a declarative manifest file, install/uninstall/download them from the CLI, and individual packages have update feeds a bit like a Docker repository. There are some differences: - MSIX is designed for desktop apps, not servers. - There's no concept of layering like Docker has. - A Docker repository is a relatively heavy serverish thing. MSIX packages can have a stream of updates expressed, but it's done by just publishing an XML file to a web server. - MSIX doesn't try to wrap an entire Windows userland in the same way that Docker images ship entire copies of Linux userland. It's all about overlay filesystems.
- oneplane 3y ago
  But that's the problem, isn't it? It tries to be too much of an 'enterprise solution' instead of a developer-centric ship-your-stuff method. It's not getting traction, and it's not compatible with anything. It's technically a correct format, but that's not what you need to get a thriving ecosystem.
  - mike_hearn 3y ago
    It's compatible with (nearly) all Windows apps, modulo bugs and missing AppXManifest features.
    - oneplane 3y ago
      So from a developer perspective (in the OCI ecosystem), it's perhaps 10% new GUI stuff, and then 10% of what Docker does, and Docker doesn't even do its own stuff all that well. Unless someone really wants that GUI stuff (as in, presenting the packaged application with a GUI, something OCI doesn't do well), this will never get picked unless forced, and if forced people will not use it because they enjoy it or because it has ecosystem traction, but because they were forced. Again, it doesn't matter how correct it is, what features it does have or how it compares to all the other attempts from the past, what matters is that unless a developer is in the single scenario where they are forced to use it, they will probably ignore it. Granted, before we got into the 'microsoft container concepts suck' threat, this article was specifically about win32 app isolation, so if we look at it from that perspective, this is a step up. But that's not where the mindshare or the money is.
      - pjmlp 3y ago
        If you had spent any time reading the related Blue Hat content, this is the first step alongside developer certificates, to bring UWP model to across all Windows workloads. You can then either switch to macOS or ChromeOS with similar models already, use one of the mobile OSes, which have used such restrictions for years, or maybe it is finally when the exodus to Linux Desktop takes place.

mike_hearn 3y ago

MSIX files are Microsoft's equivalent of OCI containers and do all those things. It's not well known but here's a brief rundown of the format and tech: - They're zips (sorta, but you can't make them with any existing zip library) - They can contain VFS overlays for system directories. Files placed inside the package under the VFS directory will appear at runtime as if they are installed to c:\Windows\System32 and other well known locations, but only for apps within that package. This is built using an equivalent of unionfs called bindflt. - Apps run inside "app containers" which are at the lower levels composed of job objects and other kernel features. App containers are the basis of all sandboxing on Windows and are the closest equivalent of cgroups. - Writes to the user's home directory are transparently redirected to a separate directory specific to that package. This allows data to be cleaned on uninstall. - You can express various integration points in a declarative manifest file, install/uninstall/download them from the CLI, and individual packages have update feeds a bit like a Docker repository. There are some differences: - MSIX is designed for desktop apps, not servers. - There's no concept of layering like Docker has. - A Docker repository is a relatively heavy serverish thing. MSIX packages can have a stream of updates expressed, but it's done by just publishing an XML file to a web server. - MSIX doesn't try to wrap an entire Windows userland in the same way that Docker images ship entire copies of Linux userland. It's all about overlay filesystems.

oneplane 3y ago
But that's the problem, isn't it? It tries to be too much of an 'enterprise solution' instead of a developer-centric ship-your-stuff method. It's not getting traction, and it's not compatible with anything. It's technically a correct format, but that's not what you need to get a thriving ecosystem.
- mike_hearn 3y ago
  It's compatible with (nearly) all Windows apps, modulo bugs and missing AppXManifest features.
  - oneplane 3y ago
    So from a developer perspective (in the OCI ecosystem), it's perhaps 10% new GUI stuff, and then 10% of what Docker does, and Docker doesn't even do its own stuff all that well. Unless someone really wants that GUI stuff (as in, presenting the packaged application with a GUI, something OCI doesn't do well), this will never get picked unless forced, and if forced people will not use it because they enjoy it or because it has ecosystem traction, but because they were forced. Again, it doesn't matter how correct it is, what features it does have or how it compares to all the other attempts from the past, what matters is that unless a developer is in the single scenario where they are forced to use it, they will probably ignore it. Granted, before we got into the 'microsoft container concepts suck' threat, this article was specifically about win32 app isolation, so if we look at it from that perspective, this is a step up. But that's not where the mindshare or the money is.
    - pjmlp 3y ago
      If you had spent any time reading the related Blue Hat content, this is the first step alongside developer certificates, to bring UWP model to across all Windows workloads. You can then either switch to macOS or ChromeOS with similar models already, use one of the mobile OSes, which have used such restrictions for years, or maybe it is finally when the exodus to Linux Desktop takes place.