stevvooe

Love to see projects that focus on the "boring" parts of getting infrastructure up and running. Something like this can save a bundle of time. This is a great project with a great team behind it!

Note that I did not say "more granular layers" but more "more granular filesystem representation". This is a key point in achieving better data sharing. In fact, these use cases are not ruled out, but bolstered by OCIs approach. The introduction of alternative systems will be much easier to do when OCI is broadly implemented.

As far as metadata is concerned, your suggestion is exactly what OCI does. The problem with ACI is that it embeds a large part of the metadata into a tar file, which has to be fetched in its entirety. OCI is mostly metadata scaffolding, made up of indexes, manifests and configs that can all be fetched without large bandwidth requirements.

The compositional aspect that you've brought up has been explored and it doesn't make a whole lot of sense to cram that into images. Typically, such a system requires composing container filesystems through named references, allowing components to be independently rebuilt. Because this composition often relies on details of the target deployment media (orchestration system, container runtime, specific operating system, etc.), especially in how it deals with the security of name resolution, baking it into an image format leads to massive inflexibility.

Moving it up the stack works much better and avoid the technical complexities that come with doing it within images. We can see this image composition in action in k8s PODs, docker stacks and other systems. Such constructions can be distributed through OCI images, through media types, but they are based on the compositional capabilities of the target system.

There is no real advantage to a dependency graph versus a list of layers. Originally, Docker images were actually fetched in sequence, similar to the ACI approach, but this blocked parallelization on each subsequent step. What has become OCI uses a list of layers to avoid this bottleneck.

As long as images share layers, network traffic would be the same in either scenario.

Reduced transfers will be achieved by formats that have a more granular filesystem representation. Right now, we are really held back by the continued use of tar, but that is another problem.

Nix has been a very cool project to watch over the years.

You can address part of the problem of picking up extra data in final images by declaring temporary build locations, such as `/var/lib/cache`, as a volume. Anything written to a volume won't be included in the final image.

Yes, I do mean areas with high poverty areas or low income.

I am not really suggesting any particular cause of poverty, but lead-soil levels seem to have some negative effect. The more important suggestion is that its not just income disparity, anonymity and juxtaposition of poverty and wealth, if at all, that leads to higher crime rates in cities.

In fact, mixed-income neighborhoods have been linked to better social mobility, but that is getting off-topic.

Many people carry out fruitful lives in The Nut.

Create a separate ServeMux for your application and let the utilities register to the DefaultServeMux via init (and you can even register your own!). Bind the DefaultServeMux to the debug port (6060) using http.ListenAndServe(debugPort, nil) and bind your app to its port (8080) with http.ListenAndServe(appPort, appMux).

Didn't Nintendo already beat that theme to death?

After following the development of Go for awhile, I've come to idolize Rob Pike's terse, accurate communication style.

You're not way off, but, in this case, it has more to do with the fact that the Cove 2 Octopi are particularly beloved among the Seattle diving community.