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

Docker

computer.rip

Post reply on HN
Print view View original

111–120 of 145 posts

Re: Docker

#111

Post by ignoramous »

soneil wrote: post #6

The narrative seems quite clear to me. They released the tooling and the services to become the defacto solution, and then Swarm was supposed to be the cashcow that turned that into cashflow. And then k8s happened. They've raised a tonne of capital, and it probably looked sane at the time. And now they're grasping at straws trying to figure out how else they can turn this into revenue. A lot of the recent narrative h…

Speaking personally, the fate of Docker, Inc. was clear to me when they took their $40M Series C round in 2014. I had met with Solomon in April 2014 (after their $15M Series B) and tried to tell him what I had learned at Joyent: that raising a ton of money without having a concrete and repeatable business would almost inevitably lead to poor decision making.

I could see that I was being too abstract, so I distilled it -- and I more or less begged him to not take any more money. (Sadly, Silicon Valley's superlative, must-watch "Sand Hill Shuffle" episode would not air until 2015, or I would have pointed him to it.) When they took the $40M round -- which was an absolutely outrageous amount of capital to take into a company that didn't even have a conception of what they would possibly sell -- the future was clear to me.

I wasn't at all surprised when the SVP washouts from the likes of VMware and IBM landed at Docker -- though still somehow disappointed when they behaved predictably, accelerating the demise of the company. May Docker, Inc. at least become a business school case study to warn future generations of an avoidable fate!

- Bryan Cantrill, https://news.ycombinator.com/item?id=28460504

Re: Docker

#112

Post by yrro »

kuratkull wrote: post #98
koito17 wrote: post #86

Earlier quoted context omitted.

On my personal computer and projects I always use Podman. There is even a fancy web app if people desperately want a cool icon on their menu bar, though it pales in comparison to Docker Desktop in features. (For instance, it's not able to search for images, whereas Docker Desktop can). I do not miss Docker at all considering that I can copy paste almost every docker invocation I see online and have it run flawlessly…

We are now on the Podman train. We used Docker for a while on some parts of our services. We did a thorough comparison of Podman and Docker when it was time to move over all the rest of our legacy-deployed services. Podman won out on many technical, subjective, and future-looking topics. Feels good, everybody is on board here.

Big ask but I'm sure that would make a fantastic blog post...

Re: Docker

#113

Post by dontlaugh »

sofixa wrote: post #80
emptysongglass wrote: post #64

Earlier quoted context omitted.

There's an absolutely massive ecosystem of tooling around it to make a developer's life easier and abstract away the confusing parts. No one needs to write K8s manifests directly if they don't want to.

The abstractions work very well, until they don't and you need to dive in 5 abstractions deep to debug what's happening, or an upgrade needs to be done and you have conflicting dependencies a few levels deep.

Even during development I’ve had to learn far more than I’d like about k8s internals as things broke left and right.

ECS, nomad or even autoscaling VMs are much easier to deal with when they fail.

Re: Docker

#114

Post by prmoustache »

Kwpolska wrote: post #109
prmoustache wrote: post #103

Earlier quoted context omitted.

>does not give people a right to design unreadable/inaccessible websites. They aren't as the rendering of a website is ultimately always controlled by the client/visitor. Any website whose semantic is only made of text is infinitely more accessible than another that would use bigger fonts but would include images or content that only render if javascript is activated. And ultimately, they have every right to make it…

Some users don't know how to use their browser's zoom feature. Most don't know how to change the default font in their browser, and those that do might not want to do this in case some sites break because of bad assumptions. Others don't like zoom, because it makes images look blurry. The default appearance of the page should be usable and accessible by an average user. And yes, the 20px font applies to the full text…

The average user use prescription glasses if he has eyesights issues.

I've been wearing glasses since I was 6 or 7y old.

Re: Docker

#115

Post by electroly »

quickthrower2 wrote: post #47

How does the Docker story compare to NPM who are also freely hosting a bunch if stuff, heavily downloaded and relying on some paid users but mostly free. And NPM has “competing” repositorys too. Could the same happen with NPM where they need to charge? I get that NPM packages are smaller than docker images typically.

NPM went the other way: get bought out by a big company with deep pockets and a strategic interest in owning the ecosystem.

Re: Docker

#116

Post by krab »

sirius87 wrote: post #59
BossingAround wrote: post #53

Earlier quoted context omitted.

> if Docker Inc. were to be bought out by Microsoft... You can always use Podman. We already have fully OSS solutions in the container space.

Where do you host the base images? Someone's footing that bill or are you paying for it?

Why not decentralized? Debian (for example) can provide one or two servers with a gigabit line. That's going to be quite slow to download during every CI build. Therefore, your CI provider would have a caching proxy registry. You get fast service, upstream doesn't need a ton of bandwidth.

Re: Docker

#117

Post by pjmlp »

ngc248 wrote: post #41
berkle4455 wrote: post #14

okay so swarm is dead, but is kubernetes actually that good or is it just ubiquitous and you’re forced to use it today? what about nomad? or mrsk?

k8s is good, I don't get the hate against k8s.

YAML spaghetti, plus a complexity that makes Java application servers look like toys.

Re: Docker

#118

Post by sirius87 »

krab wrote: post #116
sirius87 wrote: post #59

Earlier quoted context omitted.

Where do you host the base images? Someone's footing that bill or are you paying for it?

Why not decentralized? Debian (for example) can provide one or two servers with a gigabit line. That's going to be quite slow to download during every CI build. Therefore, your CI provider would have a caching proxy registry. You get fast service, upstream doesn't need a ton of bandwidth.

Docker images are often tied to CI runs. So a Github action is configured to "bake" a docker image that saves the image to Github Container Registry and a CI platform is triggered to pull the image and run tests immediately thereafter. Imagine this happening on every Git commit in a certain branch.

Often, there isn't time for an image to be pulled from a mirroring serving.

Re: Docker

#119

Post by Kwpolska »

prmoustache wrote: post #114
Kwpolska wrote: post #109

Earlier quoted context omitted.

Some users don't know how to use their browser's zoom feature. Most don't know how to change the default font in their browser, and those that do might not want to do this in case some sites break because of bad assumptions. Others don't like zoom, because it makes images look blurry. The default appearance of the page should be usable and accessible by an average user. And yes, the 20px font applies to the full text…

The average user use prescription glasses if he has eyesights issues. I've been wearing glasses since I was 6 or 7y old.

I’m wearing glasses too, and they are of the correct power for my needs (as measured by an optometrist). That does not make HN less unusable and the posted page less uncomfortable at 100% zoom from the recommended viewing distance.

Re: Docker

#120

Post by krab »

sirius87 wrote: post #118
krab wrote: post #116

Earlier quoted context omitted.

Why not decentralized? Debian (for example) can provide one or two servers with a gigabit line. That's going to be quite slow to download during every CI build. Therefore, your CI provider would have a caching proxy registry. You get fast service, upstream doesn't need a ton of bandwidth.

Docker images are often tied to CI runs. So a Github action is configured to "bake" a docker image that saves the image to Github Container Registry and a CI platform is triggered to pull the image and run tests immediately thereafter. Imagine this happening on every Git commit in a certain branch. Often, there isn't time for an image to be pulled from a mirroring serving.

I meant the base images. If you're pushing your own images, then you can use any service you want (and pay for it). Since the traffic doesn't need to go through the internet at all, the bandwidth cost to Dockerhub would be irrelevant.
Post reply on HN