Containers are great tools that can encapsulate an application and its dependencies, allowing apps to run anywhere in a streamlined way. Some container images contain commands to start a long-lived binary, whereas others may simply contain data that needs to be available in the environment (for example, a Kubernetes cluster). For example, operator-framework bundles and crossplane packages both use container images to store Kubernetes manifests. These manifests are unpacked on-cluster and made available to end users.
One of the downsides of using container images to store data is that they are necessarily opaque. There's no way to quickly tell what's inside the image, although the hash digest is useful in seeing whether the image has changed from a previous version. The options are to use docker cp or something similar using podman or containerd.
Using docker cp by itself can be cumbersome. Say you have a remote image somewhere in a registry. You have to pull the image, create a container from that image, and only then run docker cp <container-id> using an unintuitive syntax for selecting what should be copied to the local filesystem.
dcp is a simple binary that attempts to simplify this workflow. A user can simply say dcp <image-name> and it can extract the contents of that image onto the local filesystem. It can also just print the contents of the image to stdout, and not create any local files.
I'm actually running into this issue right now, in the context of a test that I'm writing. The test needs to copy some data out of an image. The image contains a full filesystem, and some of the files are read-only. The copy is done via docker cp, which requires elevated privileges on the host to copy read-only files (see https://github.com/moby/moby/issues/35987 for more info).
As a result, the test needs to be run using sudo to work correctly. The test environment is containerized, so there is a Dockerfile, but as the article mentioned the user in the container should not be root. Is there any plausible way around this? Updating the image is not under my control, and changing the copy code is also riskier than I would like.
Since this is in the context of CI, the threat is lower than live production, but still....
Interesting how they enforce the namespaced scope for ACK custom resources. This is a logical design choice but makes it trickier for operators to use.
Say I have an operator watching all namespaces on the cluster. Since operator CRDs are global in scope it makes sense for some operators to be installed as singletons. A CR for this operator gets created in some namespace, and it wants to talk to s3 -- it has to bring along its own s3 credentials and only that CR is allowed to use the s3 bucket? You can imagine a scenario where multiple CRs across namespaces want access to the same s3 bucket.
A dilemma that we are running into at work is that we have all our software open source and readily available on github but use an internal bug tracker to manage bugs picked up by QE and other people in our org. These bugs are given significantly higher priority than our GH issues and we end up with a pile of GH issues that no one has the time or ability to adequately track. As our team recently set up its own open source working group and generally is making open source contributions in other projects a higher priority I see this problem getting worse. Does anyone have any suggestions how to overcome such an issue?
And I guess I'd just like to add my two cents: sometimes your issues are not being adequately triaged because the project is using another system for bug tracking and the engineers are slammed fixing those bugs instead lol.
How much of being a 10x dev comes down to understanding the existing system really well and being able to iterate quickly?
I wouldn't call myself a 10x dev but at my last startup I was very productive, definitely more than expected at my skill level, because early on I had a lot of access to the people who designed our (undocumented, untested, and buggy) backend system. Then when I got a feature ticket (consisting of 3 words) I was able to quickly bang it out and deliver it, whereas other more senior engineers struggled because they didn't fully understand how the backend microservices actually worked and talked to each other.
Now I work at a big tech co and I'm in the latter position: I have a hard time understanding our complex CI/CD, and don't have nearly as much understanding of all the existing components. As a result I'm not nearly as productive and back to feeling like a 1x or 0.1x dev.
Of course a 10x dev understands the existing system, but it's more than that. A 10x dev IMO, understands how to logically take apart and put together a system. I find it amusing that we recognize grand masters in chess and elite performs in other fields, but don't wish to acknowledge that such people exist in our fields.
What I have seen with such developers is that they can jump into a system they have no idea about and ramp up faster than most people. I don't believe that everyone can be a 10x, I also don't believe that everyone that can be a 10x is even going to reach that field. From what I have seen, these folks are the sorts that enjoy working on non user centric app. They hate those ambiguities, so you might find them in security, or working on compilers, networking and lower level sort of codes where it's possible to conquer whatever demon that will arise from the code. It's almost impossible to WIN in user centric app where what's correct is subjective.
> I find it amusing that we recognize grand masters in chess and elite performs in other fields, but don't wish to acknowledge that such people exist in our fields.
It’s easy to rank people playing a zero-sum game where the only thing that varies is opponent, use ELO and call it a day. Software development is more complicated because the problems and quality of solutions aren’t even clear. So to me it makes sense that we don’t have software development grandmasters outside of things like IOI.
I personal believe problems and quality are pretty clear. The challenge is in understanding what the problem is, which is not a "programming" activity, but rather a communication activity. You could have 2 customers who want a solution that clash and conflict, if you make one happy, you make the other sad. No matter how you tackle it, you lose.
e.g. You build something for sales that makes customer service unhappy or vice versa.
You build something and keep it backwards compatible and that makes your prior users happy but puts off new users who were willing to adopt or vice versa.
At this point, it's no longer about programming. Doesn't diminish that those activities are just important. We could also argue that there are 10x user interface and interaction designers, 10x project managers, 10x product managers, etc. The confluence of such folks is a beautiful thing to experience, however it's not needed, just 1 or 2 of those with a bunch of "average" folks can ship and release a really good product.
I took a new job this past fall, and I found our "git push to production" pipeline to be quite opaque. I solved this by taking on small projects to implement incremental improvements: improving log level configuration for production, simplifying database migrations, etc. I learned a bunch about different parts of the system, and it gave me a chance to gain some visibility in a good way. And each improvement helps me feel more productive, and that increase in perceived/actual productivity comes from better tooling or having knowledge of how the system works.
I mostly read fiction books and technical O'Reilly stuff. Would highly recommend both. Reading books is infinitely more relaxing than browsing content online aimlessly.
It's a fair criticism of the older versions of Go - it did not have good dependency management out of the box. Probably due to the famous Google monorepo and how they did not need to tackle that issue head on themselves. However the past few years Go has really addressed this problem, first through the dep project (which has your standard .lock file for pinning dependencies similar to Node) and now go modules (included in the latest Go versions). Now you get dependency management out of the box. Your point is valid but does not reflect the modern state of Go.
