>WCET ("worst case execution time") is an important consideration: Operations should take a fixed amount of time and the produced machine code should be predictable.
Good luck. Give the avionics guys a call if you solve this at the language level.
Maybe I have low standards given I've never touched what gitlab or CircleCi have to offer, but compared to my past experiences with Buildbot, Jenkins and Travis, it's miles ahead of these in my opinion.
Am I missing a truly better alternative or CI systems simply are all kind of a pita?
I don't enough experience w/ Buildbot or Travis to comment on those, but Jenkins?
I get that it got the job done and was standard at one point, but every single Jenkins instance I've seen in the wild is a steaming pile of ... unpatched, unloved, liability. I've come to understand that it isn't necessarily Jenkins at fault, it's teams 'running' their own infrastructure as an afterthought, coupled with the risk of borking the setup at the 'wrong time', which is always. From my experience this pattern seems nearly universal.
Github actions definitely has its warts and missing features, but I'll take managed build services over Jenkins every time.
Jenkins was just build in pre-container way so a lot of stuff (unless you specifically make your jobs use containers) is dependent on setup of machine running jenkins. But that does make some things easier, just harder to make repeatable as you pretty much configuration management solution to keep the jenkins machine config repeatable.
And yes "we can't be arsed to patch it till it's problem" is pretty much standard for any on-site infrastructure that doesn't have ops people yelling at devs to keep it up to date, but that's more SaaS vs onsite benefit than Jenkins failing.
My issue with Github CI is that it doesn't run your code in a container. You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.
> You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.
Yeah checking out everytime is a slight papercut I guess, but I guess it gives you control as sometimes you don't need to checkout anything or want a shallow/full clone. I guess if it checked out for you then their would be other papercuts.
I use their runners so never need to do any cleanup and get a fresh slate everytime.
The tone is off. Cloudflare shared a post-mortem on the same day as the incident. It's unreasonable to throw a "I wish technical organisations would be more thorough in investigating accidents".
With that said, I would also like to know how it took them ~2 hours to see the error. That's a long, long time.
Arko explained why he changed the password. Yes, he should have communicated the change, and that's on him. I still can't understand why RC preferred to publish a hit piece on him instead of... calling him to ask if he had changed the password? Bonkers.
Now, are you using that to justify the hostile takeover of critical infrastructure to the entire Ruby community? I'm baffled. RC did a *hostile takeover*. How many times do I have to repeat this?
Here you are, saying out loud that RC would have needed to call Arko to ask if Arko had changed the password. There are one too many "if"'s in that sentence!
Why in the everloving cosmic fuck did he not tell them? In a great many circumstances what he did is a crime. Nobody's coming after him on this but if this was me I would paper the everloving fuck out of what I did so there wasn't even a possibility that the owner of the account had any uncertainty as to what happened.
I don't know what happened with "the repos", is why I haven't offered an opinion about it. I have a professional interest in stories about people gaining unauthorized access to accounts. I assure you, the law doesn't weigh one party's transgression against the other the way you suggest it should.
I find your obsession over Andre's fault and disdain towards the stealing of the repos by RC amusing.
And you know what? I think you're right! What Andre did could constitute a crime. Any serious organization would lawyer up and go after him... right? RIGHT?
Yes, and he already explained why he did it. Yes, he should have communicated it clearly. That's on him.
At the same time, why didn't RC call him to ask? Was it easier to write about a security INCIDENT throwing shade at Arko?
With that said, let's keep focused on the real issue: RC did a hostile takeover of the projects. That's not been properly disputed so far. Matz is, therefore, accepting to steward stolen projects.
It doesn't matter why you break into your former employer's server. That's the point.
> Matz is, therefore, accepting to steward stolen projects.
You know Arko didn't even start working on Rubygems until it was nearly 10 years old, right?
One of the original authors is in here and on X saying he supports it being taken over by RubyCore. Which matters much more than whatever the maintainers who were locked out think.
"Please confirm that you cannot access the Ruby Central AWS root account credentials, either through the console or by access keys."
Alternatively, we could see the whole issue for what it is: a power struggle between political factions of an open source project that is unprofessionally handled by at least one side.
> It doesn't matter why you break into your former employer's server.
Arko already stated that he didn't know he had been fired. Geez.
> You know Arko didn't even start working on Rubygems until it was nearly 10 years old, right?
The project was stolen from a set of maintainers, not just Arko. Let's stick to the facts: someone with admin rights over the repos revoked the access of other admins without their consent. What do you call this?
> One of the original authors is in here and on X saying he supports it being taken over by RubyCore. Which matters much more than whatever the maintainers who were locked out think.
How in the world is that relevant? I have a lot of respect for Rich, but he wasn't a maintainer.
> have a lot of respect for Rich, but he wasn't a maintainer.
LMAO
No. He's one of the few people on the planet that could lay claim to it's copyright. He also gave the insight that Rubygems has literally ALWAYS been a part of RubyCentral.
Arko tried to copyright Rubygems and file a claim against RC. That's literally part of the issue here... Because the repo doesn't matter that much, it's OSS, you can fork...
But if you do care about the repo, once again, RC has always controlled Rubygems. From the day it was written. The maintainers were even paid by RC. That makes it RC's, not the maintainers'.
Arko explained why he changed the password; I agree that he should have communicated the change. Now, does that justify the hostile takeover of the projects? C'mon... folks, there was a hostile takeover of two projects. Will we, as a community, ignore that?
I don't understand how Matz accepted this as-is. Taking over these projects without addressing the takeover makes them toxic assets that will taint the Ruby community for a long, long time.
Look. I brought up Arko's credibility. I didn't bring up the Ruby Central folks credibility. That's a separate thread -- there's literally like 500 other threads to discuss that topic.
What you're doing is called a Whataboutism. I was responding to a comment about gem.coop.
Andre Arko is not credible and thus gem.coop is not credible. He can explain all he wants but his actions were plainly inexcusable. Whatever Ruby Central did is immaterial to the point of whether or not Andre Arko can be involved with services that we rely on.
Good luck. Give the avionics guys a call if you solve this at the language level.
reply