Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

containerd will still run images build by Docker. Google can talk about how Docker is missing CRI support, but I feel like this is just Google wanting to cut out Docker entirely.

I seems like containerd is maintained by The Linux Foundation, a group of people who mostly don't even run Linux (most of their releases and media material is made on Macs)

I dunno. I don't like the direction things are going in the open source world right now.



This was always a land-grab by folk who wanted Docker's """community""" (read: channel) but not Docker's commercial interests. Any time you see a much larger commercial entity insist you write a spec for your technology, especially one with much larger pockets, the writing is always on the cards.

The bit that absolutely fucking sickens me is how these transactions are often dressed up in language with free software intonations like "community", "collaboration" etc. Institutionalized doublethink is so thick in the modern free software world that few people even recognize the difference any more. As an aside, can anyone remember not so long ago when Google wouldn't shut up about "the open web"? Probably stopped saying that not long after Chrome ate the entire ecosystem and began dictating terms.

The one mea culpa for Docker is that the sales folk behind Kubernetes haven't the slightest understanding of the usability story that made Docker such a raging success to begin with. The sheer size of the organizations they represent may not even allow them to recreate that experience if indeed they recognized the genius of it. It remains to be seen whether they'll manage that before another orchestrator comes along and changes the wind once again. The trophy could still be stolen, there's definitely room for it.


Meh.

The whole idea of containerization came from Google anyways, who uses it internally. Docker came out with their container system without understanding what made it work so well for Google. They then discovered the hard way that the whole point of containers is to not matter, which makes it hard to build a business on them.

Docker responded by building up a whole ecosystem and doing everything that they could to make Docker matter. Which makes them a PITA to use. (One which you might not notice if you internalize their way of doing things and memorize their commands.)

One of my favorite quotes about Docker was from a Linux kernel developer. It went, "On the rare occasions when they manage to ask the right question, they don't understand the answer."

I've seen Docker be a disaster over and over again. The fact that they have a good sales pitch only makes it worse because more people get stuck with a bad technology.

Eliminating Docker from the equation seems to me to be an unmitigated Good Thing.


> The whole idea of containerization came from Google anyways, who uses it internally.

Not really. Jails and chroots are a form of containerization and have existed for a long time. Sun debuted containers (with Zones branding) as we think of them today long before Google took interest, and still years before Docker came to the forefront.

> I've seen Docker be a disaster over and over again. The fact that they have a good sales pitch only makes it worse because more people get stuck with a bad technology.

> Eliminating Docker from the equation seems to me to be an unmitigated Good Thing.

Now this I agree with, Docker is a wreck. Poor design, bad tooling, and often downright hostile to the needs of their users. Docker is the Myspace of infra tooling and the sooner they croak, the better.


What Google pioneered was the idea of defining how to build a bunch of containers, building them, deploying them together to a cloud, and then having them talk to each other according to preset rules.

Yes, we had chroot, jails, and VMs long before. I'd point to IBM's 360 model 67 which was released in 1967 as the earliest example that I'm aware of. A typical use before containerazation was shared hosting. But people thought of and managed those as servers. Maybe servers with some scripting, but still servers.

I'm not aware of anyone prior to Google treating them as disposable units that were built and deployed at scale according to automated rules. There is a significant mind shift from "let's give you a pretend server" to, "let's stand up a service in an automated way by deploying it with its dependency as a pretend server that you network together as needed". And another one still to, "And let's create a network operating system to manage all services across all of our data centers." And another one still to standardize on a practices that let any data center can go down at any time with no service disruption, and any 2 can go down with no bigger problems than increased latency.

Google standardized all of that years before I heard "containerization" whispered by anyone outside of Google.


Containers came from Solaris and the BSDs, and the warehouse-sized containerized deploys that this article/changelog is associated with came from Google. You're both right.

And agreed, Docker is a mess. It seems like everything that's good about Docker was developed by other companies, and everything that's bad about Docker was developed by Docker. The sooner the other companies can write Docker out of the picture the better. I want the time I wasted on Swarm back.


I get preferring that major open sourced projects weren't controlled by a big corporation, but this seems overly dramatic.

Docker was always a company first and foremost, I fail to see how leaving the technology in their commercial control would have been better in any way than making it an open standard. Just because Docker = small = good and Google = giant corporation = evil? Docker raised huge amounts of VC funding, they had every intention of becoming a giant corporation themselves.

And it's kind of bizarre to completely discount the outcome of this situation, which is that we have amazing container tools that are free and open and standardized, just because you don't like some of the parties involved in getting to this point.


> making it an open standard

I would hesitate to use the term "open standard" until I'd thoroughly assessed the identities of everyone contributing to that open spec, along with those of their employers, and what history the spec has of accepting genuinely "community" contributions (in the 1990s sense of that word)


The container image/runtime/distribution area is heavily standardized now via the Open Container Initiative (OCI) that was founded 5 years ago.

https://www.linuxfoundation.org/press-release/2015/12/open-c... https://kubernetes.io/blog/2016/12/container-runtime-interfa...

You can see the releases and specs that are supported by all major container runtimes here: https://opencontainers.org/release-notices/overview/

For example, OpenShift ships https://cri-o.io in its kubernetes distribution as its container runtime, so this isn't really new.

Disclosure: I helped start OCI and CNCF


I've never tried contributing to CRI so I don't really know what the process is like. I imagine like any such large and established standard it would require a herculean effort, that doesn't necessarily mean it's not open just that it can't possibly accept any random idea that comes along and still continue to serve its huge user base.

But let's say you're right and call it a closed standard. Then this change drops support for one older, clunkier closed standard in favor of the current closed standard. Still doesn't seem like anything to get upset over.


> This was always a land-grab by...

What's "this" in that sentence? Kubernetes in general?


The standardization of “Docker” containers into “OCI” containers and the huge amount of public pressure put on Docker to separate out their runtime containerd from dockerd.


Do you think it shouldn't have been standardized so other vendors products could be interoperable with docker's containers, or just that the standardization should have been done differently, or other?


I would say that Google never wanted to be _in_ with Docker in the first place. Google had been doing things the docker way before Docker existed (Borg). Docker sort of caught the developer ecosystem by surprise, but proved the viability of containers in general. From this point forward it was clear Google would build their cloud future on “containers”, not on Docker. If you can find archived streams of the GCP conference that took place shortly after Dockers rise in popularity, they say the word container all day long, but never mention the word Docker once. I was there and remember counting


Support for Docker was a correct market move for Cloud to adopt users that were already familiar with a tech base.

But divorcing their API from that tech base is also a move to support Cloud users---they don't want the story for big companies to be "If you want to use Kubernetes, you must also attach to Docker." That cuts potential customers out of the market who want to use Kubernetes but may have a reason they can't use Docker (even if that reason is simply strategic).

Google Cloud's business model walks a tightrope between usability and flexibility. Really, all the cloud vendors do, to varying degrees of success.


> I dunno. I don't like the direction things are going in the open source world right now.

I commented on a child comment as well, but I don't understand this idea. The news is that a piece of commercially built software is being deprecated by a major project in favor of one built on an open standard, and you're interpreting this as a blow to open source?


> I seems like containerd is maintained by The Linux Foundation, a group of people who mostly don't even run Linux (most of their releases and media material is made on Macs)

Using Macs for content creation isn't evidence that the Foundation members don't use also Linux, whether for software development, backend servers, etc.


It's probably fair to extrapolate that some tools they rely upon in their business flow aren't available on Linux, which is probably of concern.


I think Derek Taylor does a good breakdown of all the various software choices by The Linux Foundation:

https://www.youtube.com/watch?v=a-2dYfYvJGk


If I made presentations, you would discover that my content was all created on a linux desktop.

What a totally random data point of no relevance or significance eh?

Such things do in fact reflect the character and nature of the people involved. It doesn't necessarilly define them entirely, but yes it does reflect them.

It's not that you're not a "true Scotsman" necessarily if you say, care about linux primarily in other roles than desktops. You can be perfectly sincere in that, and it's valuable even if it only goes that far. But it does mean you are in a different class from people who actually do abjure the convenience of proprietary software wherever possible, and today "possible" absolutely includes ordinary office work and even presentation media creation.

It's perfectly ok to be so compromised. Everyone doesn't have to be Stallman.

It's equally perfectly fair to observe that these people are not in that class, when such class does exist and other people do actually live the life.

You can't have it both ways that's all. If you want to preach a certain gospel to capitalise on the virtue signal, without actually living that gospel and not actually posessing that virtue, it's completely fair to be called out for it.


It seems hyperbolic to say that the operating system a person uses is reflective of their character.


i 100% agree with you. open source feels really, really bad especially in the last year.

to others reading this -- simplified, but, docker uses containerd to build/run images. all docker images are valid containerd images. you can run images through containerd straight off the docker hub.


It depends on what one means by "open source."

Open source is fine; there's a ton of available code out there, to mix and match for whatever goals you need. Open services were never a thing, and what we're observing is that the SAAS model is eating the entire marketplace because tying services together to solve tasks is far easier (and depending on scale, more maintainable) than tying software together to solve tasks on hardware you own and operate exclusively. Owning and operating the hardware in addition to owning and operating the software that does the thing you want to do doesn't scale as flexibly as letting someone else maintain the hardware and provide service-level guarantees, for a wide variety of applications. But the software driving those services is generally closed-source.

If by "open source" you mean "Free (as in freedom) software," the ship has kind of sailed. The GNU-style four essential freedoms break down philosophically in the case of SAAS, because the underlying assumption is "It's my hardware and I should have the right to control it" and that assumption breaks down when it's not my hardware. There may be an analogous assumption for "It's my data and..." but nobody's crystallized what that looks like in the way GNU crystallized the Four Freedoms.


This is a pretty good primer on this peculiar new problem.

It's kind of a case study for future text books about how if there is a certain incentive, it will be embodied and satisfied no matter what. If the names and labels have to change, they will, but the essentials will somehow turn out to not have changed in any meaningful way in the end.

It's if anything worse now than before. At least before you were allowed to own your inscrutible black box and use it indefinitely. There was sane persistence like a chair. You buy it, and it's there for you as long as you still want it after that. maybe you don't want it any more after a while, but it doesn't go poof on it's own.

One way things are actually better now though is, now in many cases the saas outside of your control really is just a convenience you could replace with self-hosted good-enough alternatives, thanks to decades of open source software and tools building up to being quite powerful and capable today.

I think this is a case of the rising water lifting all ships. If the proprietry crowd gained more ability to abuse their consumers, everyone else has likewise gained more ability to live without them. Both things are true and I tell myself it's a net positive rather than a positive and a negative cancelling out, because more and better tools is a net positive no matter that both sides have access to use them for crossed purposes. At least it means you have more options today than you did yesterday.


Regarding your last paragraph "They are my friends and I should have the right to socialize with them however I want without being surveilled".


I believe that's a good consequence of the kind of universal principles that it would be nice to have for data but can't serve as one of those principles.

For example, Al Capone had some friends, and the government violated his right to socialize with them without being surveilled for good cause.


It's normal for rights to be taken away from criminals. Or do you mean pre-conviction... I think it's ok if it involves manual legwork.


Al Capone wasn't yet convicted of anything when they started wiretapping his phones.


comtainerd is hosted by the Linux Foundation (more specifically CNCF). It is maintained by people from all over, including but not limited to the major US tech companies (Apple, Google, Microsoft, Amazon).

containerd was also created by Docker Inc and donated to the LF.


Docker Inc really do not want infrastructure projects wrapper docker itself. It causes all sorts of headaches for them. They encourage using containerd for infrastructure projects (which is basically the core of original docker extracted out as a sperate project maintained by a large community). Docker is basically an opiononated wrapper around containerd, and they intend to move even more in that direction in the future.

TLDR: Docker Inc almost certainly is happy to see this change happen.


Probably to get around the recent docker registry throttling would be my guess. They are likely looking at building out their own container ecosystem.


Changing the runtime doesn't change the registry.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: