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

121–130 of 145 posts

Re: Docker

#121

Post by jacooper »

> Docker Inc.'s goal was presumably that users would start using paid Docker plans to raise the quotas but, well, that's only attractive for users that either don't know about caching proxies or judge the overhead of using one to be more costly than Docker Hub... and I have a hard time picturing an organization where that would be true.

But that achieved their goal too? They wanted to reduce loses from bandwidth costs, that works by either making the users pay, or use less bandwidth.

Re: Docker

#122

Post by sirius87 »

krab wrote: post #120
sirius87 wrote: post #118

Earlier quoted context omitted.

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.

Base images are already available on different container image hosting platforms. For instance, ubuntu is here [1] on Amazon ECR. So it's matter of updating Dockerfiles to use them.

There again there's the question of finding image sources you can trust to be updated and secure. Docker Hub has a "Docker Official Image" tag for critical base images that are managed by each community.

[1] https://gallery.ecr.aws/ubuntu/ubuntu

Re: Docker

#123

Post by jacooper »

BossingAround wrote: post #53
sirius87 wrote: post #44

In its weird death spiral, if Docker Inc. were to be bought out by Microsoft, I shudder to think how much of the dev ecosystem would yet again depend on Microsoft's good graces to shoulder the burden of storage and data transfer costs for building products. They already do npm and Github (+ Github Container Registry) so they have some standing in being stewards in this space. On the plus side, it would perhaps give e…

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

Call me when podman fully supports the Compose spec(so Docker compose V2)

Re: Docker

#124

Post by traverseda »

nemothekid wrote: post #19
kinghuang wrote: post #9

Earlier quoted context omitted.

I feel like all that VC money was actually their undoing. Instead of working with the community, Docker spent bucketloads of money acquiring a lot of community projects and startups in an obvious attempt to become an end-to-end container solution company. But, they didn't have a plan and ended up killing most of those acquisitions. To me, it felt like Docker was using all the money they got to squash the community in…

> I feel like all that VC money was actually their undoing. I don't think you have Docker without VC money. I think at best you have some LXC-lite project that is intertwined with GCP/AWS/Azure but unfortunately, I don't think you get something as quite polished as Docker in the same timeframe without VCs pouring millions to hire people to work on it. Where I am sympathetic to Docker is Docker wouldn't have worked as…

>there probably a ton of services you could build with the right team and right amount of people that could make an even greater impact than Docker on productivity and they would never be built because it would be way too difficult to monetize

There's a big difference between creating value and capturing value. Probably thr biggest single issue with capitalism in general.

Re: Docker

#125

Post by [deleted] »

Julesman wrote: post #27

I know I will get downvoted for this as off topic, but this is just the latest blog we've seen in this top 30 of many that show ZERO regard for legibility. Yes, I can zoom my browser, but c'mon. A 13px font for paragraph text is nearly hostile. It's not that legible to people with perfect eyesight, but then it's not at all legible to anyone with imperfect eyesight. It's like saying you don't care if anyone who reads…

[deleted]

Re: Docker

#126

Post by toastal »

prmoustache wrote: post #100
Julesman wrote: post #27

I know I will get downvoted for this as off topic, but this is just the latest blog we've seen in this top 30 of many that show ZERO regard for legibility. Yes, I can zoom my browser, but c'mon. A 13px font for paragraph text is nearly hostile. It's not that legible to people with perfect eyesight, but then it's not at all legible to anyone with imperfect eyesight. It's like saying you don't care if anyone who reads…

Not sure what you are talking about, the font seems much bigger than the one on hacker news and pretty standard sized for a website or a desktop (which usually has default font size at 11 or 12px). Besides: - Nearly if not all desktops allow to scale. If your eyeseight is that bad you should set it at desktop level anyway. - All browsers and terminal emulators allows one to use his own defined fonts and size. - Nearl…

This is why you should do more CSS with rems and respecting the user agent's size so it's easier for folks to get the size they want (this article's author used ems and defaults though)

Re: Docker

#127

Post by krab »

sirius87 wrote: post #122
krab wrote: post #120

Earlier quoted context omitted.

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.

Base images are already available on different container image hosting platforms. For instance, ubuntu is here [1] on Amazon ECR. So it's matter of updating Dockerfiles to use them. There again there's the question of finding image sources you can trust to be updated and secure. Docker Hub has a "Docker Official Image" tag for critical base images that are managed by each community. [1] https://gallery.ecr.aws/ubuntu…

That's my point - that it's entirely possible to not rely on the single central repository.

Re. finding the sources, a central namespace may still be useful, hence the use of caching proxies.

Re: Docker

#128

Post by dingusdew »

Julesman wrote: post #27

I know I will get downvoted for this as off topic, but this is just the latest blog we've seen in this top 30 of many that show ZERO regard for legibility. Yes, I can zoom my browser, but c'mon. A 13px font for paragraph text is nearly hostile. It's not that legible to people with perfect eyesight, but then it's not at all legible to anyone with imperfect eyesight. It's like saying you don't care if anyone who reads…

[dead]

Re: Docker

#129

Post by ironick09 »

tyingq wrote: post #105
Kwpolska wrote: post #76

Earlier quoted context omitted.

Docker Desktop runs dockerd in WSL and adds a few things to enable working with it from Windows (e.g. installs the docker CLI on the Windows side and exposes the dockerd control socket to it). You can easily get rid of it and replace it with running dockerd in WSL on your own, or with podman-based tools.

Docker did do something smart with Docker Desktop by including wsl-vpnkit...to work around brain-dead corporate VPNs that break docker networking. Your alternative solutions don't work when AnyConnect or GlobalProtect, etc, are running.

This is only partially true, if _all_ traffic is tunneled over the vpn, then yes you’ll have this issue, but if the traffic is split such that only interesting traffic is sent over the vpn, then you won’t have this issue.

Re: Docker

#130

Post by EntrePrescott »

EntrePrescott wrote: post #88
Dalewyn wrote: post #79

Earlier quoted context omitted.

>The kernel of truth is that the technology itself isn’t valuable; it’s the /humanization/ of a technology, how it interfaces with the people who use it every day. Apple in a nutshell.

Apple even takes it even one step further: they understood (Just like haute couture, cosmetics and luxury watch brands before them) that it's neither the product nor the technology nor even the interface itself that's what's really valuable (in the sense of: monetizeable), but the user EXPERIENCE in the sense of how it makes the user FEEL. Which is Why Apple excels in brand marketing. If you want a cash cow, you don'…

in retrosprect - re-reading my last comment again, too late for editing - I just noticed that there is a small detail error in it, owed to my technology/development-oriented bias that is too detached from the brand marketing and sales/monetization oriented mindset of Apple:

Instead of "user", the more fitting word would have been "customer", though even that would only have been a rough one-word approximation for the concept that could in the Apple brand marketing context better be described as "person (to be) suggestively conditioned to be a follower/fan who is content with being kept in a walled garden and milked as much as possible in order to be part of the circle and to continually FEEL the EXPERIENCE".

So yes, "EXPERIENCE" is key, but "user experience" in the sense that "user" has in development/tech or even specifically in UX is only a smaller part of that.

Post reply on HN