Linux containers are great (and I run Linux as my desktop OS), just pointing out the not-so-efficient nature of considering this cross-platform.
Linux containers are great (and I run Linux as my desktop OS), just pointing out the not-so-efficient nature of considering this cross-platform.
Docker natively supports Windows, and it is low lift to make native Windows images for many common programming environments.
Does anyone use it? No not really. It makes a lot of sense if you need Windows stack stuff that is superior to Linux, like DirectX, but maybe not so much for regular applications.
There is also macOS containers, a project that has a decent proof of concept of a containerd fork that runs macOS container images. In principle there is a shorter path of work for so called host process containers, but fully isolated exists for macOS, it could work with e.g. Kubernetes, and people want it and it makes sense, and it sort of does exist.
The difference between cross-platform and “cross-platform” as you’re talking about it is really having some absolutely gigantic company, like Amazon or Google, literally top 10 in the world, putting this stuff into a social media zeitgeist.
You can run them through Docker Desktop, but then why not just run the same containers you will be deploying on you server (which is most likely going to be linux based?).
I would love for MS to make containers the way to deploy programs to Windows, but that requires them to make the runtime part of the default install and to make it available on all the OSs.
They are supported all the same. IMO the main issue is that this feature is poorly marketed.
Still unless it works on Win10 home, it won't be the default way to install software for windows - which sucks, since its a better way than the current one.
Windows containers are supported in Windows Professional as well.
Maybe it is because I spend most of my time as Windows developer, this wasn't hard to find,
> One physical computer system running Windows 10 or 11 Professional or Enterprise with Anniversary Update (version 1607) or later.
https://learn.microsoft.com/en-us/virtualization/windowscont...
What I missed was that it only applied to windows server images.
Also the exception only seems to apply for development and testing services and, for some reason, only a physical computer.
Regardless, I was clearly wrong: it is possible, just not well documented.
However, Docker is an OS-level virtualization. Docker natively supports Windows in the sense that there is a native app. That native app spins up Linux virtual machines, so the container is "native" to my Intel CPU with their virtualization extensions, but it is not native to Windows. I use it, which I say with no animus toward your original message.
edit: I was ignorant of native windows containers. I'm old and my brain still maps docker to lxc I guess. Apologies to OP - the DirectX line should have caught my attention.
Docker Desktop aims to provide the same experience across Mac and Windows and as such those use Linux VM's, yes. However Docker most definitely supports Windows containers.
I run ubuntu desktop in a vbox VM.
If I run ubuntu desktop on docker, I have to RDP into it.
What type of container will WSL build? A desktop - or headless with CLI?
Finally - which is lighter-weight, Vbox VM, or a Docker container, or whatever WSL makes?
EDIT: NM - I understand the answer now.
Pretty sure WSL is installing the full OS as a guest, a la VirtualBox
Many App deployments in Azure also use Windows containers.
(Not to mention it produces unactionable output by default, and if I love one thing, it's "this page didn't work one out of 100 times, must be infra problem" incidents)
Linux is only free when our time isn't worth money.
Playwright is developed by Microsoft, by the way.
that's funny, because having rotated through all 3 major cloud providers in the past 5 years now (at different places), Azure support is the most time-wasting not worth it even if it was free, and i'd much prefer if i could waste my time reading documentation that makes sense, but Azure doesn't have that either.
Azure doesn't happen to be an outlier in Microsoft products, right?
> Playwright is developed by Microsoft, by the way.
And I'm happy the people there get to make things that work outside the eldritch horror that is Windows Server.
Oh, man, not this shit.
Linux saves time. Windows servers are an endless time sink, that costs more on its hardware, and have added license costs. And license costs are also mostly the time you spend managing your licenses, the actual money you send to Microsoft is peanuts.
Windows only costs its price if your time is worthless.
In my experience the choice is usually made by the familiarity rather than ideology. Windows server can definitely be a better choice if they already successfully use it. And that's the case even if a Linux based server would be actually better for their use case based on some arbitrary metrics. Some are so ideologically challenged that they use both and see no problem.
One of the only enduring lessons from IT history is that there's always going to come a time to move on from some technology or vendor. And IBM isn't doing wrong by trying to capture some cash but it's very late in this game and its a losing battle.
I'm guessing that it's going to be the 'legacy' cloud vendor's time soon. The markup is way out of whack.
If you want to pay rather a lot more than merely twice as much you can get source from MS too, and still not get all the utility because it comes with ndas and no ocean of other user hackers who want the same obvious things you do.
Spending time on an open tool is an investment that you do because it pays off. Spending your own time, or paying a developer (hired in house or consultant), or paying license fees for a closed product are all just things you spend to get the result.
It has nothing to do with your time being worthless. If your own time is too super valuable to spend directly building, then the choice is not "pay MS to do it or do it myself", it's pay an employee to do it one way or pay an employee to do it another way.
You pay an employee 100k and MS 100k, or you pay 2 employees. You get 10x more value out of two humans producing work that you 100% own and get to have every important detail exactly how you want it, and then it works for as long as you want it. Even with the churn from security updates and popular fads, anything you invested in building, you still get to use forever if you want. No serial number ever expires, no activation ever blocks your ability to make backups and hot spares and parallel extra capacity. And those humans actively solve new weird problems in a way no piece of software or software licence ever can.
The reason not to pay MS is not because it costs money, it's because you get shit for it.
> Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
In reality as you said tons of effort are spent exactly trying to make Linux good at the things windows has been good at for 30 years. But there's that weird dissonance that makes people think that windows is inferior to Linux on a technical level just because it's inferior on a software license/freedom level. The two are completely unrelated. The funniest thing is people who argue that the Linux kernel is just the future compared to the "antiquated" NT kernel (lol, lmao)
Vulkan is like Direct3D 12, a low level 3D API. Between the two, most seem to consider Vulkan the better option. However, Vulkan has the reputation of being verbose and very much not noob friendly. It is mostly geared towards advanced engine developers who want full control to make the most of the hardware.
Besides 3D, the rest of the multimedia API are a bit of a mess it seems. On Windows and elsewhere. I haven't look at it for many years though.
DirectX as a whole product: yes.
For the two middlewares Unity and Unreal, on real applications, DirectX 11 will have better latency (lower CPU time mostly), DirectX 12 performance will be higher throughput (greater FPS), but neither will be by very much. Like a single application on ordinary hardware, it won’t matter. But for the thing I measure, occupancy, you can get something like 3x as much efficiency with DirectX on Windows compared to the same application on Vulkan on Linux.
I really think people who "want" containers on MacOS don't understand containers or what problem they solve, and if they think they need them should consider why they aren't already running their dev environment in Linux.
Edit: Ok, apparently it natively supports Windows for Windows containers and for everything else there's a Hyper-V integration. Not sure if you can write a portable Dockerfile script like that though.
It is a matter of having build parameters for base images and using programming languages that are mostly OS agnostic.
Each ape file is also a valid zip file. Add your dependencies as if the ape was an archive:
zip -ur myape.com mydependency.anything
Also add a `.args` file: zip -ur myape.com .args
For this .args file, put one argument per line. This will run on start. You can use `/zip/mydepencency.anything` to read from files, but if you have an executable dependency you'll need to extract it first (I use the host shell or host powershell for this).You can do this with any software you can compile with comsocc, by adding a call to LoadZipArgs[1] in the main function.
It's easy to get started, your ideas will branch out as soon as you start playing with it.
[1]: https://github.com/jart/cosmopolitan/blob/master/tool/args/a...
> It'll be nice to know that any normal PC program we write will "just work" on Raspberry Pi and Apple ARM. All we have to do embed an ARM build of the emulator above within our x86 executables, and have them morph and re-exec appropriately, similar to how Cosmopolitan is already doing doing with qemu-x86_64, except that this wouldn't need to be installed beforehand.
Many Windows products, e.g. Sitecore, only support Windows containers.
Microsoft Store software relies on Windows containers infrastructure.
Windows containers make use of Windows jobs APIs.