> #! /usr/bin/env nix-shell > #! nix-shell -i python3 -p python3Packages.pillow python3Packages.ansicolor > > # scale image by 50% > import sys, PIL.Image, ansicolor > path = sys.argv[1] > image = PIL.Image.open(path) > factor = 0.5 > image = image.resize((round(image.width * factor), round(image.height * factor))) > path = path + ".s50.jpg" > image.save(path) > print(ansicolor.green(f"done {path}"))

Just `chmod +x` and you have an executable with all dependencies you specify!

[0] https://nixos.wiki/wiki/Nix-shell_shebang

EDIT: Now I see its badly formatted, Either way, be careful with #! size limits.

  #! /usr/bin/env nix-shell
  #! nix-shell -i python3 -p python3Packages.pillow python3Packages.ansicolor
  
  # scale image by 50%
  import sys, PIL.Image, ansicolor
  path = sys.argv[1]
  image = PIL.Image.open(path)
  factor = 0.5
  image = image.resize((round(image.width \* factor), round(image.height \* factor)))
  path = path + ".s50.jpg"
  image.save(path)
  print(ansicolor.green(f"done {path}"))

My own rule of thumb is that nix-shell is great for quick one-offs and for sharing environments. For local tools and anything else I’m sharing with my future self, it’s usually better to write a nix expression and install it, which gives me access to Nix’s (excellent) rollback system, and lets me upgrade on my schedule, not upstream’s.

* - ‘Latest’ according to whatever Nix channel checkout currently applies. Which you can change, of course, but the point is it’s external to the script.

https://dpc.pw/posts/nix-users-you-can-start-using-rust-scri...

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works on OSs that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

Fortunately this non-standard behavior is more the norm than the exception: it works at least on modern GNU/Linux, BSDs, and macOS.

[1] https://www.gnu.org/software/coreutils/manual/html_node/env-...

[2] https://github.com/coreutils/coreutils/blob/b09dc6306e7affaf...

[0] https://unix.stackexchange.com/questions/399690/multiple-arg...

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.

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

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.

Many App deployments in Azure also use Windows containers.

> Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.

(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.

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.

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.

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.

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.

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.

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

    zip -ur myape.com .args

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...

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.

> 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.

Container packing is cool, but is it just a security thing preventing us from using our normal hardware? Or versioning (NixOS)? Is wasm capable of doing this and is wasm still alive? I just feel like needing to run tests inception style inside and outside docker gets complicated and annoying and always try to just use Linux directly these days.

It's like if you have a workshop and you diligently organize all of the different parts into different trays in different units so it's easier to do all the types of work you need to do. You could just have a giant box in the corner where you chuck absolutely everything.. far less complex, but it'd make your day to day work a nightmare.

Next thing we’ll define a new format and runtime to package and run a collection of docker images with associated configuration.

First came machines, to perform simple "computation" tasks.

Then came the computer with instructions to represent the generalized notion of computational work.

Then we wanted a way to DRY instructions so we got functions.

Then we wanted a way to package collections of functions so we got libraries.

Then we wanted a way to manage collections of libraries so we got package managers.

Then we wanted a way to distribute collections of packages so we got containers.

Now we're in a world where instantiating and configuring a collection of containers is error-prone, burdensome, and rarely portable.

Each level adds something (containers have the benefit of being language-agnostic), but the price is complexity.

I was secretly assuming that something like that is already being done. ;)

Recursion is fine and useful. What’s detrimental is if each layer defines conceptually same things in slightly different ways and with different terminology. Make a recursive format (like a file system) and be done with it (and/or extend it so that all levels can profit from the extension).

I don't hate docker, but I find that it's just not that useful until you reach a certain scale. I stopped using it for personal projects and am much happier for it.

I still believe in containers in a multi-developer environment, but in my experience the disadvantages outweigh the advantages when your only coworker is future-you.

It is less about security and more about having several applications on the same hardware without full blown VMs.

Podman is better but it's also a bit coupled to a distro - https://news.ycombinator.com/item?id=38981844

The problem is the Linux kernel container primitives are a bit of a mess

bubblewrap is a lot closer, although last I heard it's not in some distros for security reasons - https://news.ycombinator.com/item?id=30823164

the scale is non virtualized qemu all the way to docker which will even screw your iptables rules for your convenience. hn crowd falling in the middle as the Goldie locks we all are.

> Please don't fulminate. Please don't sneer, including at the rest of the community.

podman has underpinned our Kubernetes distribution, OpenShift, since 4.0 was released in 2019. OpenShift is a $1B+ USD business for us (https://www.newsobserver.com/news/business/article271678707....). You can search and see a sample of who uses it for Enterprise level business.

https://docs.openshift.com/container-platform/4.14/nodes/con....

https://docs.podman.io/en/latest/#:~:text=Podman%20relies%20....

The answer is a little bit more nuanced, as the defaults differ. Podman uses crun by default: https://podman.io/docs/installation#:~:text=crun%20%2F%20run.... For OpenShift the use of crun is available as a Technology Preview: https://www.redhat.com/en/blog/whats-new-in-red-hat-openshif... since 4.12. The default for 4.14 is still runC.

Notwithstanding, Podman is gaining a lot of momentum, especially now with Podman Desktop. Disclaimer: I work for Red Hat on the Podman Machine and OpenShift Local/CRC teams to provide integration with Podman Desktop aiming at developer usecases

At home I use only podman because my tinkering doesn't affect anyone but me.

Disclaimer: working at Red Hat as a (tech) manager of the OpenShift Local team, involved on the virtualization targets for Podman Machine and the integration of some of our extensions.

- Easier to grep a collection of single files

- Easier to see what you've got in your collection in a directory listing (whether via a shell or in a web UI such as GitHib)

- Easier to view the contents quickly (`cat`)

- General philosophy that flat is better than nested

For example, here's the same app but packaged as a regular bash script:

https://gist.github.com/lwneal/a24ba363d9cc9f7a02282c3621afa...

The only upside to having an executable Dockerfile is that it's still a valid Dockerfile that you can use with docker build, docker-compose, etc. in addition to being able to execute it.

https://superuser.com/a/440059

It embeds an awk (or any interpreter) script, and uses sed to cut out the script between tags in $0.

I agree with other comments that this kind of thing can get messy, but sometimes it makes a lot of sense and let's you share a single file.

The `nix bundle` command can generate an arx file, which includes all of an application's dependencies. As an example, we started getting issues with an EC2 server whose image was an accumulation of changes over several years; whilst we worked on migrating to a saner setup (containers defined using Nix), as a stop-gap we got the server working again by using `nix bundle` to create an arx executable containing working versions of all the application's dependencies, which we could copy to the existing server as a drop-in replacement of the existing (broken) command.

    #!/usr/bin/env -S guix shell python python-numpy -- python3
    import numpy
    print("This is numpy", numpy.version.version)

    #!/usr/bin/env -S bash -c "podman run --rm -w /x -v "\$PWD:/x" \$(podman build -q - 

I.e. you can't rely on this working on a POSIX compliant system

Well; thats Unix before Pottering and Microsoft.

    ```js title="/root/server.js"
    console.log('test')
    ```

    `/root/server.js`

    ```js
    console.log('test')
    ```

    RUN /root/server.js
    console.log('test')
    EOF

The point of this isn't to share this code, it's a demo of the clever shebang line.

Since this is actually env calling bash first, not docker, this should just be a Bash script. You can still feed the Dockerfile to docker build via STDIN. But you'd gain the ability to shellcheck the Bash, the code would be easier to read, write, maintain, add comments to, etc. You could keep the filename the same, run it the same way, etc. The way they've done it here is just unnecessarily difficult.

but you'd then have to work out how to "filter out" the bash commands inside this bash script to make it a valid docker file.

Unless of course, you entirely store the docker file contents inside heredocs. That works fine, but it's not as "cool" as "executing" dockerfiles as a script.

    #!/usr/bin/env -S bash -c "docker run --privileged ..."

    FROM docker
    
    RUN /other.Dockerfile
      #!/usr/bin/env -S bash -c "docker run ..."
      FROM debian:buster
    EOF
    RUN chmod +x /other.Dockerfile
    
    CMD bash -c "/other.Dockerfile &; ./main"

    -v /:/sysroot

    $ env "-S echo hello world"
    hello world

At Google Cloud we did this on a team I was on. It was really the only way we could be sure of the environment we were handing off to the customer.

Nice hack. Love it.

Here OP created a little hack for building and running a docker container by adding a shebang to a Dockerfile.

Usually it’s a two step process. You first use “docker build” to build the image and then “docker run” to create a container from it. With this little hack you just run “./Dockerfile” and it does both.

It’s cool, but not really useful for most people.

Pretty neat if you're using Dockerfiles, but also highly non-standard so you wouldn't use it in your company repo (unless you want to increase the "what-the-fuck" level of your repo).

It's more of a "look, this is cool" kind of a thing if you're a Linux and container user.

I mean, you could. Whether you should, well ...