The vagaries of the dual licensing discourages a lot of teams working on commercial projects from kicking the tires on CodeQL and generally hinders adoption for private projects as well: are there any plans to change the licensing in the future?
The Jenkins vitriol is also puzzling to me, I think the security model, reliability and backup/restore story has gotten seismically better in the intervening decade people wrote it off
Respectfully, neither of these docs strike me as really sufficient to debug live running systems in the critical path for paying users. The first seems to be related to the inner development loop and local the second is again how to attach gdb to debug something in a controlled environment
Crash reporting, telemetry, useful queuing/saturation measures or a Rosetta Stone of “we look at X today in system and app level telemetry, in the <unikernel system> world we look at Y (or don’t need X for reason Z) would be more in the spirit of parity
Systems are often somewhat “hands off” in more change control sensitive environments too, these guides presume full access, line of sight connectivity and a expert operator which are three unsafe assumptions in larger production systems IMO
I was able to setup SigNoz on the order of five minutes to view traces in my Dagger builds locally just by exporting the right env vars — it was nice to not have to run and orchestrate three+ tools together
MongoDB Atlas is a multi-cloud developer data platform that simplifies how developers work with data.
We’re hiring a Site Reliability Engineer to join our Developer Infrastructure team. Our team supports the broader SRE organization by:
- Building and maintaining container images, OS packages, and infrastructure tooling
- Creating self-service Terraform workflows
- Handling cloud resource provisioning across AWS, GCP, and Azure
This is a full-time, remote role for candidates based in the four continental US timezones. Prior familiarity with Bazel, Go, Terraform, Argo workflows and GitHub Actions would be helpful.