cpuguy83

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).

Multiple reasons:

1. Firecracker is still a smaller more deliberate surface area 2. qemu didn't have a microvm type at the time. Firecracker was the impetus for it

qemu has a microvm machine profile, also boots in ms.

There are also tooling on Linux to do containers as microvm's, long before Apple containers were a thing.

Or, and bear with me hear, there is a problem even if you aren't experiencing it.

I've been using spotlight since it was introduced for... everything. In Tahoe it has been absolutely terrible. Unusable. Always indexing. Never showing me applications which is the main thing I use it for (yes, it is configured to show applications!). They broke something.

Not seeing complaints doesn't mean they don't exist. Not to mention ui latency that is common in electron apps that is just a low-level constant annoyance.

That does not exist in the US as far as I've seen.

There's Amazon's "just walk out" stuff, which they just killed.

I made no comment about RedHat's offerings.

I don't feel like RedHat had to do anything to sell support contracts in this case, because that was already their business. All they had to do was say they'll include container support as part of their contracts.

What they did do, AIUI based on feedback in the oss docker repos, is those contracts stipulated that you must run RHEL in the container and the host, and use systemd in the container in order to be "in support". So that's kind of a self-feeding thing.

Right, and Docker sold such products and from early on.

It compiles fast, starts up fast, and doesn't have a ton of hoops to jump through (ie borrower/checker in rust).

That's true, we didn't do much around it. Small startup with monetization problems and all.

You'd have to point me to those PR's, I don't recall anything specifically around rootless. I recall a lot of things like a `--systemd` flag to `docker run`, and just general things that reduce container security to make systemd fit in.

I haven't personally used it, but containerd also has "nerdbox": http://github.com/containerd/nerdbox

Docker can run rootless the same way podman does.

Absolutely none of this is true. Docker had support contracts (Docker EE... and trying to remember, docker-cs before that naming pivot?).

Corporate customers do not care about any of the things you mentioned. I mean, maybe some, but in general no. That's not what corps think about.

There was never "no interest" at Docker in cgv2 or rootless. Never. cgv2 early on was not useable. It lacked so much functionality that v1 had. It also didn't buy much, particularly because most Docker users aren't manually managing cgroups themselves.

Docker literally sold a private registry product. It was the first thing Docker built and sold (and no, it was not late, it was very early on).