exxo_

If one can measure the whole boot process and verify the attestation "remotely", why would he need secureboot on top of that?

There are several things that can impact performance on "traditional" container runtimes. For example, cgroups, LSMs, seccomp (especially with spectre mitigations), network NS/bridges, etc. There are also more subtle things like being able to do CMA, or deal with shared memory. Most runtimes let you opt out but this becomes difficult to manage and secure with multiple users.

It is the same idea, we actually considered it at first. There are some differences in the implementation though and we built enroot with the idea of being more extensible. We also have a plugin for SLURM (https://github.com/NVIDIA/pyxis)

Simple unprivileged container runtimes: https://github.com/NVIDIA/enroot https://github.com/hpc/charliecloud

Maybe it's time to have national referendums...

This is the first revision:

https://github.com/coreutils/coreutils/blob/ccbd1d7dc5189f46...

Speed vs readability:

https://github.com/coreutils/coreutils/blob/master/src/yes.c

https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

We (NVIDIA) recently moved away from Quay/Github/Jenkins to Gitlab for our deep learning automation and the experience so far has been truly amazing. We were able to automate our most complex DL container pipeline in a matter of days. We still have to workaround some Gitlab limitations (e.g. issues [CE]17069, [CE]18994, [CE]18106, [EE]224) but overall it's great to see everything working in harmony (i.e. Docker registry, CI pipelines, Git repositories, Runners on-premises). On a personal note, I would like to see more storage on Githost.io instances considering the fact that you can't easily delete pipeline traces and that Docker images can quickly add up.

If you want more insights, I suggest you read the section "Internals".

I'm not going to dwell on the details but there are many reason why doing so can go horribly wrong. Believe me, we (NVIDIA) evaluated our options and know the implications of running our drivers within containers.

Do you really know what --privileged do? If so, you know that there is no such thing as "install the driver system wide". For that you would have to circumvent the namespaces and a bunch of other things that Docker put in place.

"portable within the scope of a given kernel" [and driver] "version"

Well that's not what I call portable :) With nvidia-docker you can build a CUDA image on your laptop and deploy it anywhere in the cloud or on premises without a single modification.

I think you are missing the point, it has nothing to do with installing the NVIDIA drivers through Docker.

What you are showing[1] is how to install NVIDIA drivers on CoreOS the hackish way (not persistent, no driver libs, no DKMS, no UVM, no KMS...)

Regarding rkt, it's not supported at the moment but a similar approach could be taken. As for the Docker CLI wrapper, you can avoid it if you really need to.

You can already have dots in IPv6 addresses if it's an IPv4-mapped/compatible address (e.g. ::FFFF:129.144.52.38)

You need the NVIDIA drivers and the nvidia-docker plugin.

$ docker-machine create --driver amazonec2 --amazonec2-instance-type g2.2xlarge ...

$ docker-machine ssh <host> # install the NVIDIA driver and nvidia-docker-plugin

$ eval `docker-machine env <host>`

$ ssh-add ~/.docker/machine/machines/<host>/id_rsa

$ NV_HOST="ssh://ubuntu@<ip>:" nvidia-docker run mybuild/tensorflow

Step 2 can be skipped if you use a custom AMI.