#73 - Industry News - Issue #2

Links, Code, and Transcript

Welcome to this weeks Industry News episode. The idea of this weekly episode, is that I will review interesting links that I found throughout the week, so that you can check them out too. Alright, so lets dive in.

Unauthorized access to Docker Hub database

Probably the biggest issue for me in the last week was that Docker Hub has a security breach. If you read through here, you’ll find that a around 190k people had their usernames, hashed passwords, and a subset of these people had their GitHub and Bitbucket tokens for Docker autobuilds exposed. I got this email, so I guess my data was exposed too. I’d highly recommend everyone change their password for Docker Hub regardless. There was a pretty good HN thread on the topic where they chat about some of the autobuild stuff. But, for me, when I checked Docker Hub, I did have my Github account linked, so I disconnected that. This used to say connected. Then, I checked on the Github side too and there were no Docker Hub tokens kicking around. You can check for linked accounts by logging into Github, going to your Settings, and checking the Applications tab. Nothing exists for Docker Hub here. I did not even have any autobuilds configured, but must have had this kicking around from a long time ago, so I should have been more proactive in disabling that when done. So, potentially someone could have accessed some of my repos.

Docker Hub Linked Accounts

There is a Github page for reviewing your security log but this only has the last 50 actions on your account. So, if you are fairly active on Github, you can quickly roll the log over, and you’ll see something useful. But, I didn’t see anything in there and I don’t have anything private so I’m not too worried. This is more of a heads up anyways. I’d recommend changing your password, revoking any tokens, and checking your Github activity feed. This type of stuff, is why pretty much all Enterprise customers, require a hosted on-prem version of Github and a totally private Docker Registry.

You can check it out at Unauthorized access to Docker Hub database along with the HN thread.

Benchmarking Istio & Linkerd CPU

Next up, the folks over at Shopify posted something about how they are deploying Istio as their service mesh. But, they ran into a major problem: cost. The article is pretty good and walks you through a bunch of metrics and performance profiling they did. They mention that for every million requests per second they see, when running a service mesh like Istio with detailed telemetry enabled, they consume 1,200 cpu cores. So, you are paying a massive performance cost. They calculate that at around 40-50k per month. I found it a pretty interesting read. Sort of echo’s my previous comments, in episode #63 on Istio, about how it is still super early days and I would not recommend deploying this just yet. There is likely much more improvements coming down the pipe and lots of best practices to be flushed out.

You can check it out at Benchmarking Istio & Linkerd CPU. Also, here episode #63 - Istio, where we installed Istio and ran through some demos.

When setting an environment variable gives you a 40x speedup

The final article I wanted to share, was around this pretty good command line debugging session, where it was discovered that disabling colours when listing a directory with lots of files greatly speeds things up! I’ll let you read through it. It’s a pretty quick read and has some useful debugging tips in here.


$ mkdir $SCRATCH/dont
$ touch $SCRATCH/dont/{1..10000} # don't try this at home!
$ time ls --color=always $SCRATCH/dont | wc -l

real    0m12.758s
user    0m0.104s
sys     0m0.699s


$ export LS_COLORS='ex=00:su=00:sg=00:ca=00:'
$ ls --color=always $SCRATCH/dont | wc -l

real    0m0.337s
user    0m0.032s
sys     0m0.029s

You can check these tips out at When setting an environment variable gives you a 40x speedup. There was also a pretty good HN thread with lots of good stories in it.

Alright, that’s it for this episode. Thanks for watching. Cya next week. Bye.

  • Published
  • Duration
    4 minutes
  • Download
    MP4 or WebM
You may also like...