Hacker News Reader

Comment by jlv2 | Hacker News Reader

This response totally misses the point.

"Sorry about it, we rushed a bit the last update and introduce a severe bug. I'll try to fix it today and if I cannot, rollback last grpcfuse patches."

View on HN

It feels like an habit of the Docker team, they always try to defend their anti-user decisions with vague and uninspired corporate bs. They're barely trying. Another classic: https://github.com/docker/docker.github.io/issues/6910

Wowww: https://github.com/docker/docker.github.io/issues/6910#issue...

What the hell does "Docker's new direction to go back to its roots and focus on developer tooling" even mean? Docker is developer tooling, that's the whole product. That's not "going back to your roots" that's just doing your damn job.

Is it developer tooling or deployment tooling?

I think part of Docker’s value proposition is that it’s both.

I wrote that comment at the time; to add some context to that comment: removal of the "login to download" was shortly after the "Docker Enterprise" business went to Mirantis. While Docker started as a developer centric tool, focus shifted to Enterprise products (Docker Enterprise Engine, UCP, Docker Trusted Registry, Docker Desktop Enterprise). After the move of the enterprise products to Mirantis, Docker's focus went back to developer products.

Oh my I had no idea they actually fixed it! Crazy it took 2 years, but at least they finally did!

Yeah, a lot of times they don't seem to understand that their core product is "you can run this command, and the virtual machine will work on any system that runs Docker, limited only by resource availability".

Heck within the first few weeks of dockerizing our system at a startup (c. 2015), they introduced a backward-incompatible change to docker-compose that we only found when onboarding new employees -- the exact thing it's supposed to be for!

These may simply be issues that are not at the discretion of these developers to either change or discuss with third parties.

As tempting as it is to weigh in publicly on such matters, the best way for a developer to get results is often to say little in public and try to resolve the issue behind the scenes (as was apparently done here).

The honest way to handle this would be for the CEO to say something like "I made this decision and I accept responsibility for it".

And the paucity of honesty in public communications is a testament to how few CEOs (and others in a leadership role who could buck-stops-here) are that sincere, willing to take that kind of heat, or to invest in understanding the problem in the first place. It’s also often a testament to how pathologically organizationally shielded they often are; I’d bet money even 5k thumbsdowns on an issue doesn’t bubble up to the top at most orgs.

> we've made this change to make sure we can improve the Docker for Mac and Windows experience for users moving forward

"How should we improve user experience? I know! Let's ruin user experience by forcing users to signup for an account they don't actually need! Brilliant!"

An addendum by another developer later on doubly misses the point: https://github.com/docker/roadmap/issues/183#issuecomment-75...

It's common to be defensive with these sorts of things. I wish people would instead be inquisitive And ask about potential downsides vs. upsides, but it's much easier to respond that way when you feel like your job or status isn't at risk.

Well, the Also I'm going to move this into the roadmap, as it's a feature request not a bug. is just as bad. If the process broke my desktop then it is a bug.

What if it was intended to break something? Still a bug? I say "no."

By your definition, all viruses, malware, and ransomware are simply bugs.

I can solve this silly debate by using the jargon of our times. It doesn’t matter whether it’s a bug, design flaw, dark pattern, bad UX, feature request. It’s a...

Defect!

If your software ships viruses, malware, and ransomware to a customer as part of an update / install then it most certainly a bug that needs to be fixed now.

You've apparently missed my point entirely. Well done.

I am talking about the malware itself...

Pretend you write malware. Your malware does what you want it to do: it destroys data. Is the data destruction a bug? Nope. Not a defect, either. It's a feature; the intended effect.

Docker intended for Docker Desktop to auto update. So, it's not a bug, but a feature. Misguided feature? Sure. User-hostile feature? Yep! It's a feature, anyway.

Talking about malware has no point in this unless we are talking about something shipped with docker. It is most definitely a bug (or defect) when the software cannot run.

Yes, it does. But your comment also misses the conclusion of the discussion: https://github.com/docker/roadmap/issues/183#issuecomment-80...

In the end, seems they are changing course after listening to user feedback. Clearly auto-updating works in some contexts, but not in others, and now we can all learn from it :)

> Clearly auto-updating works in some contexts, but not in others, and now we can all learn from it :)

I think the point was that we all knew auto-updating doesn't make sense in the context of developer tools. I'd even argue GitHub Desktop shouldn't be auto-updating. As a matter of fact, VSCode doesn't, and my compilers certainly don't.

Agree. "I was just following a successful model" is not the right way to approach engineering, without understanding the trade-offs and it seems that step was missed when implementing it in the first place.

Indeed, "I was just following a successful model" is exactly why software seems to have progressively gotten worse over the years. "Google does it and therefore I should, too!" No, you should maybe - just maybe - consider, you know, talking to your users and asking them what they want for once, and actually listening when they tell you.

And this applies outside of software, too. Apple dropped the headphone jack, so guess what every other phone manufacturer wants to do? Samsung shoved ads into its smart TVs, so guess what every other TV manufacturer wants to do? So much for product differentiation.

> As a matter of fact, VSCode doesn't

It does by default, using roughly the same method. Gratefully you can turn it off.

Edit: gratefully in terms of peace of mind. I’ve only ever been pleased when I do finally let VSCode updates install.

> It does by default, using roughly the same method. Gratefully you can turn it off.

Looked over their FAQ, and yeah, I'm super surprised that you're right, I don't remember ever turning it off.

Auto-updating does not work in any context because you can seriously break the end users stuff with no recourse. It needs to ask, always as you don't know what else is going on.

Well, many people when faced with a question from the computer will be to try to ignore it for as long as possible, that's not ideal either. Opt-out auto-update feels like the right way for consumer software, opt-in auto-update for professional software, like developer tools.

For professional (and especially tech-oriented) software I think there’s more leeway to ask the user. Prompt on install/first run would probably strike a better balance than opt-in.

Isn’t one of the main benefits of containers that you can set static versions, validate them, and then be able to deploy them with confidence that later changes won’t be used? It’s a shortcut to a known working configuration. I would expect container maintainers to appreciate the value of not updating as soon as its available.

They also explain why the think what they do is the way to go, nonethless, in the very next paragraph.

Reply on news.ycombinator.com