cpuguy83

This is focused on builds, so running either buildkitd or dockerd in an Apple containerization container. No port forwarding or host volume stuff (really its focused on running buildkit on mac) BUT complete integration with docker CLI and buildx.

https://github.com/cpuguy83/crucible

Thanks for this. Just started another rewatch and were of course in awe of the house.

Plenty of people offended by closing a PR or issue unresolved.

In an ideal universe yes. But we live in a world where vulnerability scanners reign supreme.

It's not (just) more of them, it's the same ones reported by multiple people.

I think the point is those issues are now easily discoverable and are nearly public because of it.

I'm reminded of the old-timey picture of a bunch of people on a train staring at their newspapers. Nothing new here.

Not a full docker env, I aimed this as doing builds though you can run dockerd as an option, https://github.com/cpuguy83/crucible uses the containerization framework to run either build kitd or dockerd and wire it up to docker/buildx cli (or whatever client tooling you want to use).

The Containerization framework is a library that sits as a layer on top of the virtualization framework. So each container is its own VM.

Machine is tooling above the containerization framework to run multiple things in a container in a vm.

Hold onto your butts.

No, docker access means root. You can use "rootless" mode, in this case it means root in a user namespace (that is not the "host" user namespace).

Apple did recently approve drivers for both nvidia and amd, but not for gaming purposes.

Apple supported OpenGL plenty, just that the world moved. Apple created metal, shortly after Vulkan was created.

"They could support it if they wanted to" is almost a tautology. Of course they could. But then they have to support another thing. They are on the hook when something goes wrong.

Does it free up fab space to make the newer ram?

The whole entire reason is compression is not deterministic across tooling.

containerd 2.3 has support for erofs which does a direct import of the layer. It can even convert the tar based layers to erofs, faster than extracting the tar normally.

Also looking at block-based content store so that blocks can be deduped across images.

That is not correct. You would have to use the same compression tool (and likely version) for this to match.

Old docker discarded the compressed bits but kept some metadata about the the so it can at least recreate the tar.

It also recreated the manifest o push.

That's almost certainly nothing to do with the change. Please report this if you can with commands used.

Buildkit isn't changing behavior here. Internally in docker there is a shim to make the legacy storage behave like containerd snapshotters (as well as it can, anyway--not perfect due to hard to resolve issues in the old storage). But it still kept both the compressed and uncompressed versions of images.

The problem is distros often remove older versions from the repo as soon as the new version is available. Granted there is an archive that you can pull from.

Giving kids the worst machines money can buy paired with absolutely terrible "education" software which is little more than bubble sheets on a screen was obviously going to fail.

The problem isn't that kids can't learn on tech, it's that the whole thing was done in the worst way possible.

Sorry having to use ctrl+shift for in a terminal is absolutely awful. macOS keyboard shortcuts are king.

Yeah this is the assumption, even pre-OSX. I won't claim to know the majority of mac users, especially not since the large uptick in the 2010's... but it seems, in my experience, very much the norm to not maximize windows and I wouldn't be surprised if people who do maximize are mostly Windows converts (not that there's anything wrong with that).

Debatable because you don't use it?

Homebrew would like a word.

You mean like https://wiki.nixos.org/wiki/NixOS_Containers ?

This attack was not mitigated by hash pinning. The setup-trivy action installs the latest version of trivy unless you specify a version.

Give https://github.com/project-dalec/dalec a look. It is more declarative. Has explicit abstractions for packages, caching, language level integrations, hermetic builds, source packages, system packages, and minimal containers.

Its a Buildkit frontend, so you still use "docker build".

Buildkit has the same caching model. That's what I'm saying. It doesn't force you to give it digests like nix functions often do but you can (and should).

No it doesn't. If the content of a url changes then the only way to have reproducibility is caching. You tell nix the content hash is some value and it looks up the value in the nix store. Note, it will match anything with that content hash so it is absolutely possible to tell it the wrong hash.

Producing different outputs isn't dockerfile's fault. Dockerfile doesn't enforce reproducibility but reproducibility can be achieved with it.

Nix isn't some magical thing that makes things reproducible either. nix is simply pinning build inputs and relying on caches. nixpkgs is entirely git based so you end up pinning the entire package tree.

I don't agree that the code is cheap. It doesn't require a pipeline of people to be trained and that is huge, but it's not cheap.

Tokens are expensive. We don't know what the actual cost is yet. We have startups, who aren't turning a profit, buying up all the capacity of the supply chain. There are so many impacts here that we don't have the data on.

This used to be option exposed in settings.

This just isn't true anymore (besides the green).