zlacker

[parent] [thread] 5 comments
1. mike_h+(OP)[view] [source] 2023-05-25 10:51:02
It's compatible with (nearly) all Windows apps, modulo bugs and missing AppXManifest features.
replies(1): >>onepla+dI
2. onepla+dI[view] [source] 2023-05-25 15:19:44
>>mike_h+(OP)
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.

replies(1): >>pjmlp+gX
◧◩
3. pjmlp+gX[view] [source] [discussion] 2023-05-25 16:28:58
>>onepla+dI
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.

replies(1): >>onepla+SN1
◧◩◪
4. onepla+SN1[view] [source] [discussion] 2023-05-25 20:52:09
>>pjmlp+gX
I'm not really interested in that dead-end avenue. Bulk usage is all browser based, most basic applications that do have a desktop-based client are essentially packaged chrome browsers, and high-performance apps are so custom and so tied to old APIs that they wouldn't work with any of the new container methods Microsoft attempted over the years.

Windows workloads are getting smaller, not bigger.

This attempt at a yet another microsft iteration of things like flatpak/docker/dpkg/rpm/nix etc is no more likely to be embraced than the previous ones. There is a reason default packaging of popular software is still SFX packages spewing files all over the place and not MSI or MSIX. The former is usually only included als an alternative (i.e. Chrome's "Enterprise" version) because tools like SCCM are not very useful without it.

replies(1): >>pjmlp+n93
◧◩◪◨
5. pjmlp+n93[view] [source] [discussion] 2023-05-26 07:42:43
>>onepla+SN1
Have fun with The Year of Desktop Linux, or maybe one of the BSDs.
replies(1): >>onepla+tQ3
◧◩◪◨⬒
6. onepla+tQ3[view] [source] [discussion] 2023-05-26 13:33:57
>>pjmlp+n93
I'm surprised after 14 replies you are still completely missing the point. This has nothing to do with 'windows bad' or 'app sandboxing bad' or 'haha desktop' some nonsense like that. (which is what you seem to be interpreting every time)

This has to do with Microsoft trying to re-invent the wheel time after time, and consistently failing (within their own ecosystem) because they build things that contradict the desired user experience which prevents adoption. And with adoption, I mean the same kind of adoption that Docker (now OCI) has.

That is not a direct link between desktop-app sandboxing vs. microservice containers, but a comparison between doing things good enough for mass usage (Docker) vs. trying to do it 'the enterprise way' (every attempt beyond win32 so far, including COM, MSI and APPX). And it's not about their technology having bugs either (every tech does, not just MS-tech), plenty of the technical aspects are fine, but that alone is not going to drive adoption as the last few decades have shown.

[go to top]