amouat

I loved this book! It's about much simpler, generally turn based games though

We needed Wolfi to be able to create minimal (distroless if you like) container images based on glibc with 0 vulnerabilities. Turns out a lot of other people are interested in Wolfi for various reasons, and we're more than happy to work with them.

You definitely don't need to use Wolfi! But I would say, if you run containers you might want to check out Chainguard Images: https://github.com/chainguard-images/images

I think it's more subpackages such as -dev, -lib and -doc variants. These are defined as part of the parent package but count as distinct packages.

Yeah, it's definitely not a platform for running containers. Apologies for any confusion there.

But regarding being a full linux distro, we're really just missing the kernel and I could see that happening at some point in the future.

99% of Wolfi is the package repository. We've compiled all the software to run an OS from source against glibc and made it available as APKs (apart from the kernel). The major use case for this is composing container images using tools like apko.

When you run Linux containers, you're using the kernel from the host, but everything else is provided in the container i.e. file system, utilities etc. So you can effectively run Debian or Alpine on top of a Arch kernel by just doing "docker run debian" etc. And now you can also do "docker run cgr.dev/chainguard/wolfi-base".

You're welcome to join the regular community meeting: https://github.com/wolfi-dev/community

We do fully intend for wolfi to be a community project, but it will take some time. We do say on the home page:

>What are the plans for long-term Wolfi governance? We intend for Wolfi to be a community-driven project, which means over time it will have multi-vendor governance and maintainers. For now we're focused on building the project and community, and will revisit this in several months when a community has formed.

Just to be clear, the official images are definitely not at risk, and I say that as a Docker captain.

Official images are hugely important to Docker, now and going forward.

I set up a "notes" contact on whatsapp. I had to invite someone then immediately kick them out, so it's just me. But it makes a nice easy way to jot stuff down on the run without requiring a separate app.

That's big! Theoretically you can make a lot of money on the spread ("beware picking up pennies in front of a streamroller")

One of the major benefits of Rust is that it isn't garbage collected. I'm not sure of the current status of GC support in WASM, but it used to mean that to compile something like Go to WASM also meant including a full GC implementation in the WASM code, not only bloating it but complicating implementation etc.

If this is related to musl or DNS, we are planning to add glibc base images which should address those issues.

Have a look at Patterns of Software by Richard Gabriel https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

It's not so much that Alexander has thoughts on software but that others realised they could draw clear analogues.

It's worth looking at https://kontain.app/ - seems to address a lot of the mentioned pain points in the article.

So I largely agree, but it's not that "other people are hellish", it's that they are, in fact, hell.

Satre is using the word hell to mean "the afterlife" i.e. we live on in other people's minds and opinions whether we like it or not.

Also people don't have to be dysfunctional for it to be a form of torture, we are trapped in their minds (gaze?) no matter what.

I don't think they owned the wallet, so they couldn't make outgoing transactions. I assume they didn't want to use a wallet they did control in case it could be used to identify them.

And for anyone (like me) that thought, "ok that's fair enough, what's the problem?", the issue is that it could also be interpreted as generic arguments.

A full explanation of the ambiguity is in the linked issue:

  let a = (b<c, d>(e));

  This can either mean a tuple

  let a = ((b < c), (d > e));

  Or a pair of generic arguments.

  let a = b::<c, d>(e);

More or less. I don't think they even argue about the economics of it any more.

As long as they can blame somebody else (the EU, remainers, the global situation) they will be happy. They want to mould the UK into their own vision and don't care how many people are disadvantaged in the process.

"oxter". It's a common word in Shetland (island to the north of Scotland), less so on the mainland.

There's usually some reference, but it can be a bit cryptic. All the Docker books have a whale.

I'm not sure that's true. GKE is still using Docker at least. It will move to containerd in the next few versions I expect.

There's a bit more here, but it doesn't really say much: https://www.docker.com/blog/docker-next-chapter-advancing-de...

I'm a little confused by this.

I get the specification is cloud agnostic. But it looks like the developer needs to write the underlying code to provision and maintain the application on the various clouds. It feels like a too thin abstraction. And it seems pretty leaky currently; the examples all have hard and specific requirements e.g. Azure, k8s etc.

What am I missing? Is the idea that we will create tooling to automatically create the provisioning and maintenance code?

I think we should avoid commenting about the dev's background. It was clearly a company decision and the discussion should be at that level.

Yeah, it should do that. You can read up on how the kubelet and Linux OOM work in k8s here https://kubernetes.io/docs/tasks/administer-cluster/out-of-r.... Once the OOM kicks in though, I think you're in a pretty bad place.

Scheduling is only really going to work well if you set limits, requests and quotas for containers. Please do this if you're running containers in production. I know it's a pain, as it's non-trivial to figure out how much resource your containers need, but the payoff is you avoid the issues described in the article.

This almost exactly mirrors my experience. I really hate when questions get closed.

Fixing it would take such a change in direction and leadership that it looks unlikely to happen. It seems such a shame.

Kaniko does run in the container as root, but the container doesn't need to be granted any extra privileges when run (you don't need the equivalent of Docker's --privileged flag).

As a small counterpoint, I did notice some people did very well at Advent of Code using Rust e.g. sciyoshi was 4th overall.

https://adventofcode.com/2017/leaderboard https://github.com/sciyoshi/advent-of-rust-2017

Agreed. I think they mean it's rare in terms of subject matter and style. If you want a painting of a fruit bowl, that's easy to find, but this, not so much...

Docker for Mac and Windows will include a single node k8s cluster, so yes, effectively a replacement for minikube. Docker EE will include full support for k8s as an orchestrator as well as Swarm mode.

Yes. And I don't mean to knock minikube, but this is potentially simpler and easier to use.