My experience is that it works until it does not, and then you are down on a rabbit hole trying to figure out why.
The only reason we keep using it is because we have other priorities, but once we have more spare time, this module is going to hell, it's not reliable at all.
I had a similar experience with ARC (actions-runner-controller).
One of the machines in the fleet failed to sync its clock via NTP. Once a job X got scheduled to it, the runner pod failed authentication due to incorrect clock time, and then the whole ARC system started to behave incorrectly: job X was stuck without runners, until another workflow job Y was created, and then X got run but Y became stuck. There were also other wierd behaviors like this so I eventually rebuilt everything based on VMs and stopped using ARC.
Using VMs also allowed me to support the use of the official runner images [0], which is good for compatibility.
I feel more people would benefit from managed "self-hosted" runners, so I started DimeRun [1] to provide cheaper GHA runners for people who don't have the time/willingness to troubleshoot low-level infra issues.
It's only really usable for anything that doesn't involve secrets, I'd be very concerned using anything third party in CI, let alone the runner itself. Supply chain attack senses tingling :).
Yes I totally understand the concern. We are actively working on SOC 2 and other compliance stuff to help with this. But honestly I feel the compliance requirements are weaker than what we actually implemented. For example proper secure boot and whole disk encryption (without sacrificing performance) are mandatory in our mindset but these specific things don't get reflected in compliance.
Instead of being a service, I'm also open to sell the software+hardware solution behind it, so you can have it on-prem. Do you think that's something you would consider given the constraints on supply chain security?
We're too small for on-prem services, so not your target market, just shared my 2c as someone who had been burned by self-hosting github runners too many a time.
I'm not sure why you had that experience. We just saw issues with no spot availability for the instance types we needed but you could get that info from the lambda logs. Most debugging could come from there.
the main question here is, do you really need to change the settings once you have a baseline?
I'm another one using a private GitHub repo for this. But I don't need to pull, update, sync or whatsoever. I've been using the same config for years, and in the eventual case that I would change / add something, I can do that quickly in a few computers, no need to have any sort of sync.
For VSCode settings I just use the built-in service.
As you said, a benefit of large distributed systems is that usually its a shared responsibility, with different teams owning different services.
The exhaustion comes into place when those services are not really independent, or when the responsibility is not really shared, which in turn is just a worse version of a typical system maintained by sysadmins.
One thing that helps is bring the DevOps culture into the company, but the right way. It's not just about "oh cool we are now agile and deploy a few times a day", it's all down to shared responsibility.
I've been using a LG 27" 4k60Hz with a MBP for a few years.
Recently got a 32" LG monitor from my employer, and I really tried to make it work, but it was plain impossible. It's too big, and due to scaling (which I don't need with 27"), fonts are very blurry.
I ended up with my 27" again and using the 32" for my bike trainer :)
There is no one better than yourself to get what you're looking for, so instead of relying in a third party to give you the edge, make sure you're already on the top of the wave.
I never work with external recruiters (staffing agencies)I have made the exception three times, and all of them ended with a poor experience, basically repeating the same information over and over again between them and the people from the actual company.
> If somebody asked me logic/brainteaser questions like that, I would politely stop them, explain that if they're asking me that question I'm not a good match for the company
This is exactly what I started to do after I was asked a leetcode-based question for a SRE manager position.
It turned out that by making clear my "profile", I stopped to have bullshit interviews and started to get ones more aligned to actual daily work.
By contrast, I have recently accepted a new position, and in almost every interview I was asked, with a negative connotation, why I had stayed so long (6 years) with my current employer.
In my opinion it can be a sign of loyalty, depth, engagement and responsibility among other things. I don’t understand how this can be viewed as a negative. Seems almost pathological to me to suggest that job hopping is preferred.
Very few companies increase their pay in line with market trends. If you’re at a company for 6 years, you’re likely getting paid undermarket rate. When I see someone doing that - I wonder, “are they not willing to go outside their comfort zone even when there are clear benefits?”
Personally - I’ve had no issues getting a job. I’ve job hopped consistently since I started working in 2013. I haven’t had a single job last more than a couple years. I will be looking for a new job in 2022 as well. I don’t expect anything bad to happen due to my hopping. It’s a norm within the industry.
If companies didn’t want this to happen then they’d work harder at retaining talent.
You do realize you are on HackerNews, where Paul Graham says it’s a negative trait for founders, start up workers, etc. So most companies that are growing or are looking to change directions will feel this way.
If you are at the same company people want to at the very least see growth. Positional or responsibility wise.
I rather hire someone with multiple 2-3 year stints, than someone with one 8 year job. But it’s only a small part of the hiring equation.
My experience is that it works until it does not, and then you are down on a rabbit hole trying to figure out why.
The only reason we keep using it is because we have other priorities, but once we have more spare time, this module is going to hell, it's not reliable at all.