I think of using Apptainer/Singularity as more like Docker than anything else (without the full networking configs). These are all issues with traditional Docker containers as well, so I’m not sure how you were using the containers or what you were expecting.

For my workflows on HPC, I use apptainers as basically drop-in replacements for Docker, and for that, they work quite well. These biggest benefit is that the containers are unprivileged. This means you can’t do a lot of things (in particular complex networking), but it also makes it much more secure for multi-tenant systems (like HPC).

(I know Docker and Apptainer are slightly different beasts, but I’m speaking in broad strokes in a general sense without extra permissions).

So you are using container app and your biggest problem with it is, that it's doing exactly as advertised -> containers :D

You don't mix and match pieces of containers, just like you wouldn't mix and match binaries from different distributions of Linux.

You can use a container as a single environment in which to do development, and that works fine. But they are by definition an isolated environment with different dependencies than other containers. The result of compiling something in a container necessarily needs to end up in its own container.

...that said, you could use the exact same container base image, and make many different container images from it, and those files would be compatible (assuming you shipped all needed dependencies).

How do you guys use Lua modules?

> Want single-file distribution model (although doesn't support deltas)

You can achieve that with docker by `docker save image-name > image-name.tar.gz` and `docker load --input image-name.tar.gz`.

It likewise doesn't support deltas but there was a link here on HN recently to something called "unregistry" which allows for doing "docker push" to deploy an image to a remote machine without a registry, and that thing does take deltas into account.

> (this is an anti-pattern in other container technologies)

It is? I have no issues packing my development containers full of concurrent running processes. systemd even supports running as a "container init" out of the box, so you can get something that looks very similar to a full VM.

> Apptainer and singularity ce are quite common in HPC. While both implementations fork the old singularity project, they are not really identical.

Apptainer is not a fork of the old Singularity project: Apptainer is the original project, but the community voted to change its name. It also came under the umbrella of the Linux Foundation:

* https://apptainer.org/news/community-announcement-20211130/

Sylabs (where the original Singularity author first worked) was the one that forked off the original project.

Luckily they’re still compatible with each others containers. Can use Apptainer to build the container then run it on Singularity and vice-versa.

Why are docker/podman less common? And why do you say it's better not to use containers? Performance?

Maybe the idea is that flatpak can have better sandbox control over applications running in flatpak using xdg-dbus ie. you can select the permissions that you want to give to a flatpak application and so sometimes it can act near native and not be completely isolated like containers.

Also I am not sure if apptainers are completely isolated.

Though I suppose through tools like https://containertoolbx.org/ such point also becomes moot & then I guess if they move to container, doesn't it sort of become like toolbx?

To be honest, I think a lot of tools can have a huge overlap b/w them and I guess that's okay too

Server - but this is kind of a wrong question. Apptainer is for running cli applications in immutable, rootless containers. The closest tool I can think of is Fedora Toolbx [1]. Apptainer is primarily used to distributing and reusing scientific computing tools b/c it doesn't allow root, doesn't allow for changes to the rootfs in each container, automatically mounts the working directory and works well with GPUs (that last point I can't personally attest to).

[1]: https://docs.fedoraproject.org/en-US/fedora-silverblue/toolb...

I used it on a SLURM cluster before. The documentation is done well and should be a good introduction. The only issue I had was that the cluster didn't have fakeroot or sudo, so I had to build the apptainer locally and transfer it to the server.

Why didn't toolbox fit your needs? I found toolbox to be a very reasonable way to install development dependencies on a per project basis while not managing multiple hidden filesystems.

I did start to use them for AI development on the HPC I have access to and it worked well (GPU pass-through basically automatically, the performace seemed basically the same) - but I mostly use them because I do not want to argue with administrators anymore that it's probably time they update Cuda 11.7 (as well as python 3.6) - the only version of Cuda currently installed on the cluster.

Apptainer excels for AI/ML distribution because it handles GPU access and MPI parallelization natively, with better performance than Docker in HPC environments. The --fakeroot feature lets you build containers without sudo, and the SIF file format makes distribution simpler than managing Docker layers.

conda

I thought the "hardened images" were a step in the right direction. It's a pain to have to deal with vulnerabilities on ephemeral short-lived containers/instances. Having something hyper up to date is welcome.

https://www.docker.com/blog/introducing-docker-hardened-imag...

https://dl.acm.org/doi/10.1145/3126908.3126925

This paper might help

See: https://apptainer.org/docs/admin/main/installation.html#mac

Just like with Docker, it spins up a Linux VM that integrates with Apptainer. You can install/use it with Lima (much like Docker).

You can also install it with `brew install lima` and then run `limactl start template://apptainer` to get a running Apptainer compatible VM running.

https://orbstack.dev

How do you use them to give you portability and reproducibility of builds?

From the Introduction [1]

    Many container platforms are available, but Apptainer is focused on:

    Verifiable reproducibility and security, using cryptographic signatures, an immutable container image format, and in-memory decryption.

    Integration over isolation by default. Easily make use of GPUs, high speed networks, parallel filesystems on a cluster or server by default.

    Mobility of compute. The single file SIF container format is easy to transport and share.

    A simple, effective security model. You are the same user inside a container as outside, and cannot gain additional privilege on the host system by default. Read more about Security in Apptainer.

This project is way older than (rootless) podman.

You should put time into learning this if you are going to be running HPC jobs on clusters, because some HPC clusters support this for jobs and not much else.

Appimage is terrible. It works by trying to make applications in appimages adhere to a lowest common denominator between Linux distros... which amounts to forcing application developers to develop for the oldest version of Linux appimage supports.

Nix is a huge pain to deal with.

Nix makes me think of the old Zawinski joke of:

"Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems,"

Except there are less upsides for using Nix over something like OCI.

fewer containers, surely :)

Of course we ignore the taking shots at a project just for its existence thing aside

I actually really like nixery.dev idea. Sounds kinda neat.

If I am being really honest, there are a lot of ways to go around tbh, there are ways to run nix inside of docker and docker inside of nix too.

There are ways to convert docker images into os too and there are tools like coreos.

There is nix-shell and someone on hackernews told me about comma and I am still figuring out comma (haha! Thanks to them!)

And if one just wants isolation, they can use bubblewrap or (pledge by jart) and I guess there is complete beauty and art in such container-esque space and I truly love this space a lot.

I am actually wondering right now that using traefik (as load balancer) + nats (for a modular monolith) + podman/coreos + (cloudflare tunnels?) + any vps and you can use nix to build those containers too or you can go the other way around by having a nixos on vps with traefik + nats can be a really good alternative to kubernetes.

I mean, There is docker swarm too if you don't want any of such complexity but people say that its less worked upon but still I guess there is a sort of fun in reinventing the wheel of kubernetes, but I guess I don't have tooo much problems with kubernetes I suppose because of the existence of helm charts (I haven't used kubernetes) but helm charts are written in go templates and I think they are a bit clunky but still I love golang and I feel like I would be okay with writing helm charts but I guess I am one of the people who just believes to scale horizontally first than vertically untill the economic scale gets broken and its more cheaper to use kubernetes / learn it than not.