> In ex-Yugoslavia there is a rather pronounced distinction between citizenship and nationality.
As a Yugoslav war refugee, this is spot on.
Small sidenote: Even if all of these languages are effectively one big "super-Balkan" language it is a _very_ divisive point from an ethnicity perspective given the number of conflicts this region has had over the centuries. While it's not my cup of tea, the reality is that people from the Balkans will often judge others from that region (both positively and negatively) based on these almost-imperceptible language differences since they signal to the listener some degree of ethnicity, nationality, socioeconomic level, and education level.
I also did a talk on Flatpak (part of what's being used under the covers for Pressure Vessel) and OSTree a while back if you want to know how the underlying tech works for it: https://youtu.be/KFwBu-_k3rM?t=705. Flatpak-specific things start at 26:51.
Keep them away from both the image and the container! Getting env var values dumped for a process is trivial outside of the process and even easier within the container process space.
Solid post though there are a couple of things I would disagree with:
> Do not upgrade your system packages
Most distros will have smooth upgrades and provide you with patched libs that your app may need and the latest image may not provide. It's slightly more prone to breaks but it creates a less vulnerable runtime app env.
> Do not use ‘latest’ tag for base image
Depends on the org but sometimes pinning means that you will likely end up using and end-of-life image because it requires proactive work to maintain. If you leave it as 'latest' this won't happen but you will get out-of-band breaks to keep that working. Choose wisely.
A few things I would add too:
- Don't mount Docker socket into any container unless absolutely necessary
- Your biggest security threat will be from your app's dependencies, not the container's setup
- Do not run a full init system unless absolutely necessary as this is just a security disaster waiting to happen. There are valid use cases for it but they're rare.
Keep them away from the container and use one or more of the following:
- A vault (Conjur, HCV, something else)
- A built-in credential service that comes with your cloud
- A sidecar that injects credentials or authenticates connections to the backend directly (Secretless Broker, service meshes, etc)
If you are doing a poor man's solution, mounted tmpfs volumes that contain secrets are not terrible (but they're not really that much safer than env vars).
(shameless plug as well) Try out CyberArk DAP (formerly Conjur): https://hub.docker.com/r/cyberark/conjur. OSS, powerful RBAC, has k8s-native workload ident auth, works on OCP and w/ PCF, lots of tooling integrations (https://github.com/cyberark/summon, https://github.com/cyberark/secretless-broker, etc), and there's a relatively straightforward path up to "enterprise"-y stuff if you think you want the bells and whistles (replication, auto-deployable followers, multi-zone failover, etc).
As a "docker expert" (I wrote a book on it [1], was one of the first people to get a Docker certification, and have gave multiple talks on it): please send help!
Except not really... The original article's writer doesn't know what they're talking about. If anything, knowing Docker has increased my employability in the new K8s-centric world.
Same happened to me. A few years back, I got an offer from Amazon after going through the interview pipeline and the non-compete and outside-of-work IP assignment were the only thing I asked to be changed since they were draconian given Amazon's wide breadth of products. They declined to make the change so I declined to accept their offer.
In general, Amazon doesn't make positive impressions on potential employees by saying "work for us and we could easily prevent you from working anywhere else for a year and a half (and please trust us that we won't)".
It's a really a complex answer with many facets but the main one in my opinion is that the displays of that era were CRTs with extremely low resolution (e.g. 1024x768) and generally dull color depth. This in turn required things within the page to be large, blocky, and saturated to make it appear pleasant to the eyes. What you see in these screenshots of FrontPage is _not_ what the user nor the developer would experience on such hardware. As a analogue example of a game character on an LCD vs CRT might help illustrate this: https://kayin.moe/wp-content/uploads/2014/02/1391807722376-1....
Some other smaller things also contributed but I don't think they were such big deals:
- Lack of good compression on both transfer of data and file formats, necessitating simpler designs and palette-based image formats.
- Graphics acceleration was generally slow so smooth animations were out.
- Image creation/editing tools were practically non-existent and digital cameras were rare so it makes sense that the resulting pages that have had designed assets were scary-looking.
Interesting to see that both sides seemed to have been fighting for what they believed to be a better idea but neither recognized the points where they inadvertently escalated the divisions between them.
