-
The
docker-loginrepo is setup with minimal (read-only) access which allows all users to login. This creates the necessary credentials store required for all subsequent docker operations. The team docker repositories will be setup with RBAC to only allow access to members of that respective team to perform docker push/pull operations. -
The proxy will inspect the context path for the docker pull/push operations and proceed only if authorization is successful.
In February 2017, Google announced the availability GPU-based VMs. I spun up a few of these instances, and ran some benchmarks. Along the way, I wrote down the steps taken to provision these VM instances, and install relevant drivers.
Update April 2019: Updated instructions to use instances with the Tesla T4 GPUs.
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
- By Edmond Lau
- Highly Recommended 👍
- http://www.theeffectiveengineer.com/
| # Base settings and GC logging | |
| -server -XX:+AlwaysPreTouch # First should be default, but we make it explicit, second pre-zeroes memory mapped pages on JVM startup -- improves runtime performance | |
| # -Xloggc:gc-%t.log # CUSTOMIZE LOCATION HERE - $path/gc-%t.log -- the %t in the gc log file path is so we get a new file with each JVM restart | |
| -XX:NumberOfGCLogFiles=5 -XX:+UseGCLogFileRotation -XX:GCLogFileSize=20m # Limits the number of files, logs to folder | |
| -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCCause | |
| -XX:+PrintTenuringDistribution -XX:+PrintReferenceGC -XX:+PrintAdaptiveSizePolicy # gather info on object age & reference GC time for further tuning if needed. | |
| # G1 specific settings -- probably should be default for multi-core systems with >2 GB of heap (below that, default is probably fine) | |
| -XX:+UseG1GC | |
| -XX:+UseStringDeduplication |
| #!/bin/bash | |
| # | |
| # Batch Time-Lapse creation script. | |
| # | |
| # This script can be used to speed up, trim, and finally concatenate tens or | |
| # even hundreds of video clips, e.g. from a dash cam. You can do other things, | |
| # too, but the main things this script does include: | |
| # | |
| # 1. Copy across and speed up video clips from an input dir to an output dir. | |
| # 2. Trim off the first x frames of each of the copied/sped up clips. |
Picking the right architecture = Picking the right battles + Managing trade-offs
- Clarify and agree on the scope of the system
- User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?