Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

251–260 of 286 posts

Re: Docker's Second Death

#251

Post by justicezyx »

I am quite saddened by the article's tone: "technical debt of docker" ouch that's hurtful to Solomon and Sam...

I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence.

But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards the big corps, particularly Google. After all, the whole container community own it's creation to docker. One can always claim that container exits long before docker, but that's like claim there were always operating system before Unix, etc.

Re: Docker's Second Death

#252

Post by bayindirh »

user5994461 wrote: post #186
bayindirh wrote: post #178

Earlier quoted context omitted.

I have no doubt about their quality and affordability. Also, the price goes down when you subscribe for a longer time. I write C/C++ and Python mainly. Eclipse CDT and PyDev are very good. Since I'm using the platform for 15+ years, I've seen its bad days too. Except some edge cases, CDT is bulletproof and works very well. PyDev is also very smart and helps me the way I need. Actually, Eclipse has the best and most s…

Eclipse CDT is very good? I think we have a very different definition of very good. Could write a long rant on everything that was broken in Eclipse for C and C++ development. One question on eclipse. Did eclipse finally sort out git/svn support? Here's an interesting tidbit of history for those who don't know. One of the main drivers for the decline of eclipse was the complete lack of support for source control, whi…

Eclipse CDT was really bad back in the day. Slow, crashing, not smart enough but, it's very good now from my point of view. It can satisfy my needs and, I'm happy with it.

Heck, I've developed my whole Ph.D. with it and it interfaced the tools that I need to use well, was stable and fast. When I pressed a shortcut, it did the thing I expected it to do. The whole experience was, well, uneventful.

I've used Subversive IIRC during my Master's and it was uneventful too. Didn't lose any data, the plugin didn't misbehave or had any problem with it. Was using Assembla's SVN + Redmine bundle as my remote repository.

The git support was similar. I just installed it and it worked. Still works. As I said before, they've nailed the best logical view for git IMHO. IIRC, now it comes bundled with the Eclipse.

They may have done some things wrong in the past but, it's a solid IDE and I like working with it. I don't think they deserve the strong words you choose, but to each his own.

Of course, your mileage, taste and views may vary.

Re: Docker's Second Death

#253

Post by 14u2c »

nickjj wrote: post #115
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

> As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

I recommend taking a look at Hashicorp's Nomad. I was in a similar situation where I wanted container orchestration but our use case wasn't yet at the point where the complexity of kubernetes was justified. Nomad strikes a great balance. Its single binary and makes it easy to get a cluster up and running. You can run tasks other than docker containers as well.

Re: Docker's Second Death

#254

Post by chubot »

lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Well Docker used to be dotCloud, a PaaS company around the time of Heroku, but that didn't take off. So they pivoted to Docker.

https://en.wikipedia.org/wiki/Docker,_Inc.

Heroku had a lot of revenue and was acquired by Salesforce. I just learned on Twitter that YC was in the red before the Heroku acquistion !

https://twitter.com/paulg/status/1334945195532685317

I think what Heroku did right is really nail the Rails experience, and the Rails customer base. And then they expanded to multiple languages with the "Cedar" stack.

dotCloud tried to do every language from the get-go, and had a subpar experience for all of them, from what I understand.

Re: Docker's Second Death

#255

Post by skrebbel »

goatinaboat wrote: post #74
skrebbel wrote: post #29

Earlier quoted context omitted.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? Yes absolutely, the YAML will just need to be updated for API keys or whatever. Kubernetes is complicated to build a production grade cluster on bare metal but for getting started as a developer it’s no more complicated than Docker actually

This is super helpful, thanks. I always had the idea that I needed to grok all of Kube to get productive with it (and very much got that feeling last time I explored the docs). But knowing that I can ignore a lot of that if I use some kubernetes cloud service and just put my images up there, that's super nice. Thanks (also to some sibling comments of yours) for clearly drawing up the difference between those two things.

Re: Docker's Second Death

#256

Post by IceWreck »

kristianpaul wrote: post #237

Docker still very simple to use, wish i could do the same with some systemd/containerd integration.

If you want systemd integration, use podman. It has a docker compatible CLI and runs OCI images just like docker but unlike docker it runs daemonless and has systemd integration

Re: Docker's Second Death

#257

Post by klibertp »

nikisweeting wrote: post #236
OJFord wrote: post #228

Earlier quoted context omitted.

Hm, yes, but to play devil's advocate - if you want compose for orchestration (I don't) then you want that dependence not so much for initial start up, but for triggering restarts on failure. As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.

You can define any order or restart behavior you need with v2. As long any container with a service dependency fail hards if that dependency is missing/down, it will be restarted and the whole app will eventually reach an up state. restart: on-failure depends_on: other_service: condition: service_healthy https://docs.docker.com/compose/compose-file/compose-file-v2... https://docs.docker.com/compose/compose-file/compo…

From GP:

> Problem being, "depends_on" was removed in version 3, with no replacement in sight.

How is v2 relevant?

Re: Docker's Second Death

#258

Post by justincormack »

Rapzid wrote: post #198
user5994461 wrote: post #189

Earlier quoted context omitted.

Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall). P.S. For readers who don't have context. Make a ba…

Docker compose development was compromised by the agenda of pushing people to use swarm. This is why v2 features like resource limits were moved under the deploy: key and you have to use the special "--compatibility" flag to get them to work locally.

This is no longer the case. Compose is an open spec and the v2 and v3 formats are being merged into a unified format (where you don't need version numbers). There are now multiple implementations (eg for ECS/Fargate and ACI), and implementations are being encouraged to support all the options.

Re: Docker's Second Death

#259

Post by goatinaboat »

skrebbel wrote: post #255
goatinaboat wrote: post #74

Earlier quoted context omitted.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? Yes absolutely, the YAML will just need to be updated for API keys or whatever. Kubernetes is complicated to build a production grade cluster on bare metal but for getting started as a developer it’s no more complicated than Docker actually

This is super helpful, thanks. I always had the idea that I needed to grok all of Kube to get productive with it (and very much got that feeling last time I explored the docs). But knowing that I can ignore a lot of that if I use some kubernetes cloud service and just put my images up there, that's super nice. Thanks (also to some sibling comments of yours) for clearly drawing up the difference between those two thin…

This is super helpful, thanks. I always had the idea that I needed to grok all of Kube to get productive with it

The discoverability is still a problem with it, if no one told you e.g. about k3s you would never guess the name. Good luck :-)

Re: Docker's Second Death

#260

Post by jcelerier »

AsyncAwait wrote: post #42
jcelerier wrote: post #23

Earlier quoted context omitted.

is it able to pull a random ubuntu or fedora image ?

Yes. The image standard for containers is called OCI and there are several ways to use them outside of Docker.

but, where does it pull them from ? who's hosting the images ?
Post reply on HN