MetricMike

That'd be a great addition!

Historically, the list of architectures that public github action runners make available has been quite limited. Having an alpine runner to surface unsupported commands would be a huge win.

That being said, it's very useful as a plugin dev to have this test suite while working on a WSL2/Ubuntu so that I don't need to run a full CI build every time

Their contributions notwithstanding, Shopify deserves a little extra kudos for publicizing Ruby Shield so well.

Open Source software is essential for progress, but can be scary to rely on. Efforts to harden it should be celebrated.

yep! PAM is "Pluggable Authentication Module" which sits between applications and the auth method, so you can put anything there. LDAP and ActiveDirectory are fairly common ones

There's no incentive for Microsoft to have continued investing in hiring or R&D without competition.

Yey! 2.4 finalized another crucial feature that didn't make it into the changelog or release notes - the --insecure-no-tls flag for operating behind a proxy with SSL termination (such as with a load balancer in AWS)

"But with code that recurses or calls other methods that are implemented in Ruby (better said: Carbon input language). From obvious reasons the mentioned improvment factor will go down to zero when spending all the time in builtins; (long running builtins, not Fixnum#+; but this effect begins with it). One may say snippets that do no work are producing larger speed improvments; but this is also the kind of code one calls object oriented; i.e. many levels of indirection, abstraction ....."

Two issues with this paragraph:

1) "Carbon input language" makes me think that I can't use the full breadth of Ruby. If I can't use the full breadth of Ruby it's not a Ruby VM.

2) I'm not really grokking the "snippets that do no work" portion, but given that Ruby (or at least the Rails/Sinatra flavors) are all about interdependent, highly-OO flavored code what audience is this VM targeting?

An additional point is - what if I have another CI gem that conflicts with capistrano-harrow but not capistrano?

What if capistrano-harrow introduces a security vulnerability that I'm not prepared for because I don't pay attention to a gem I'm not using?

I get that the maintainers want to promote their paid services, but this feels awful on multiple fronts. If capistrano is too expensive to maintain on your own, address that problem don't drag the Rails community kicking and screaming.

What about soliciting help from RubyTogether?

This is usually a fair point to make, but you're pointing at neither the flaws in the underlying case study nor the weakness in generalizing Utah to a wider area. That's not really fair, especially since parent comment is providing data.