Here's our GCP spend for the past month: https://imgur.com/a/VVJTSKx. Note that does not include a separate AWS cluster that we are migrating jobs too.
A large chunk of this comes from the nature of distributed tests. We need to reproduce the environment, spin up compute, etc. We do have a large problem with flaky tests on the project as well. Whether that's timeouts, memory/cpu consumption creep over time, loads of other things. We talk about how one day we'd like to get to the granulairty of being able to go to a SIG and say, "this flaky test of yours is costing the project $x in retries. Please dedicate some resources to fix it".
How we distribute the artifacts is a whole different conversation. The container world is unique in that voluntary mirrors are not as possible as with linux packages and other binaries.
Back when I was at DigitalOcean they were laying off/firing people from the company but not announcing any departures. You'd just go to message someone and their Slack account was deactivated. This was over the course of several weeks. I built a Slack bot to post when accounts got deactivated and learned of some new departures well before those impacted actually did.
I never bothered with the myQ bit and instead sacrificed one of the garage door opener remotes by wiring the button up to a relay (z-wave by Zooz) that I zip tied to the scaffold. It's worked great for the past 4 years in Home Assistant.
denhac is alive and well! We had our 15th anniversary party earlier this month and recently crossed 350 members. We're entirely volunteer run with no paid employees.
I currently serve as vice-chair of the board. I joined right before COVID and my focus has been helping get policies and processes in place to continue to help us scale. We've seen pretty rapid growth post COVID and are seeing ~10 new members a month.
Happy to answer any questions (when I wake up).
Be sure to stop and say hi If you're ever in Denver, CO!
I recently gave a talk on this and agree. While it was fun to learn, the difference between oauth and oidc isn't clear. Especially with what I've been referring to as oidc "wave 2" - machine to machine authentication without OAuth seemingly involved at all.
My partner and I just drove from Denver to NYC in a Model 3. We stopped using any sort of "autopilot" in the middle of Kansas when it kept randomly slamming on the breaks on an empty I-70 with clear skies in broad daylight.
This is my dream. Being able to use Fleet/JetBrains's backend as an LSP/DAP for Neovim. It sounds like the architecture is there with Fleet. Please JetBrains friends!
Colorado resident here. Maybe companies will start to take this seriously now that more states are passing similar laws. My go to response to recruiter spam for the past 1.5 years has been "Do you have Colorado Equal Pay for Equal Work Act compliant job listings" to which they usually don't reply. The majority of "US Remote" posts I see don't include this information but the ones that do are interesting data points.
I've had my 11th gen Framework for ~ 5 months now and I really want to love it but I've stopped recommending it to others because of the battery issues.
The biggest problem is that it drains 1-2% per hour in deep sleep on Linux. That means if you leave it asleep in your bag after work it will be between 15-30% lower when you go to use it the next morning. People on the forums[0] are even seeing up to a 4% per hour drain. I don't know what is common with other laptops but I can't say I've ever had to think about sleep drain before.
I've just ordered the 12th gen board upgrade with fingers crossed it helps but really consider going back to a ThinkPad X1 Carbon.
We've been able to reach <0.5%/hour on Linux with 12th Gen and recent kernels. There are also some additional firmware optimizations we're working on to resolve higher s0ix drain with different combinations of Expansion Cards inserted that keep the retimers from going into a suspend state.
On 11th Gen and 12th Gen, one of the other major drivers of s0ix drain we have seen is SSDs with firmware issues that keep them in higher power states in suspend. Updating SSD firmware is challenging on Linux, so if you are unable to do that, there is also a workaround to change a kernel parameter which we have seen result in <1%/hour drain on 11th Gen: https://guides.frame.work/Guide/Ubuntu+22.04+LTS+Installatio...
FWIW, my sleep drain issue (on 11th gen) got noticeably better once I replaced my USB-A and HDMI modules with USB-C. Now I just have 4 USB-C modules. I did try updating SSD firmware before that, but I don't believe that had an impact. I'm not sure whether it was HDMI or USB-A or both that was the issue.
I run the latest kernel (5.16.16 currently) on Arch.
I've turned just about every knob and kernel parameter I can, only use the USB C expansion cards, kernel is 5.18.12, and my Samsung 980 Pro is on the latest firmware (5B2QGXA7) so I look forward to what the 12th Gen board can do.
Have you tried configuring suspend-then-hibernate with a very short timer (e.g., 10 or 30 minutes)? The configuration for it is shipped with systemd these days, so all you have to do is turn it on and set the timer length. With fast SSDs, resume from hibernate is not very painful.
That should let you close your laptop and open it in a few days without any big issue, even if S0ix continues to suck.
Configuring suspend-then-hibernate is a pain on both Fedora and Ubuntu for different reasons: Fedora uses zswap by default and Ubuntu's swap partition is too small.
Last I installed it, Ubuntu actually used a swap file, so configuring hibernation required adding a kernel parameter to your boot arguments specifying what file to resume from.
The deep sleep power drain is really annoying, but on the bright side those power tuning tips let me go through an entire 8 hour workday from a full charge. At least until I need to test things on an Android emulator.
I have this issue with a Dell XPS 13 (2021) with Ubuntu, I read in several places this is common problem among modern Intel based laptops, even in Windows.
Here's our GCP spend for the past month: https://imgur.com/a/VVJTSKx. Note that does not include a separate AWS cluster that we are migrating jobs too.
A large chunk of this comes from the nature of distributed tests. We need to reproduce the environment, spin up compute, etc. We do have a large problem with flaky tests on the project as well. Whether that's timeouts, memory/cpu consumption creep over time, loads of other things. We talk about how one day we'd like to get to the granulairty of being able to go to a SIG and say, "this flaky test of yours is costing the project $x in retries. Please dedicate some resources to fix it".
How we distribute the artifacts is a whole different conversation. The container world is unique in that voluntary mirrors are not as possible as with linux packages and other binaries.
If this space interests you please join us at either [SIG K8s Infra](https://github.com/kubernetes/community/tree/master/sig-k8s-...) or [SIG Testing](https://github.com/kubernetes/community/blob/master/sig-test...)!