It didn't. Or rather it did, but not for the obvious reasons.
Taxes are not required for spending. Spending isn't required for spending, because ultimately government money is a proxy for power differentials and collective strategy.
Money defines which behaviours and which demographics are rewarded, and which are starved and punished. There are numbers and flow dynamics, but it's primarily a social credit system, not a substance.
Taxes are really a way to control the relative power of some groups over others - a form of regulation.
So when you have events like the New Deal and high taxes on the super rich, that means the economy is tuned towards diminishing power differentials, expanding infrastructure, and access to opportunity.
Low taxes on the super rich means expanding power differentials, more rigid hierarchy, diminishing collective infrastructure, and decreasing access to opportunity.
Likewise with provision of public services. If healthcare is cheap, guaranteed, and widely distributed, that increases individual agency and diminishes hierarchy.
If it's expensive and rationed by/for corporate monopolies, it increases hierarchy and diminishes agency.
>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'.
reply