You’ve turned this into a catch 22. If there were no female characters, you could argue that’s sexist. If the idiotic boss was female, you could argue all of the dumb characters are female so that’s sexist. If Jarod were the only female, that would be sexist.
How does this sketch get rewritten in such a way that it is not casually sexist?
To be clear, usually there’s an approval gate. Something is generated automatically but a product or business person has to actually approve the alert going out. Behind the scenes everyone internal knows shit is on fire (unless they have shitty monitoring, metrics, and alerting which is true for a lot of places but not major cloud or SaaS providers).
Speaking from 10+ YoE developing metrics, dashboards, uptime, all that shit and another 5+ on top of that at an exec level managing all that, this is bullshit. There is a disconnect between the automated systems that tell us something is down and the people that want to tell the outside world something is down. If you are a small company, there’s a decent chance you’ve launched your product without proper alerting and monitoring so you have to manually manage outages. If you are GitHub or AWS size, you know exactly when shit hits the fan because you have contracts that depend on that and you’re going to need some justification for downtime. Assuming a healthy environment, you’re doing a blameless postmortem but you’ve done millions of those at that scale and part of resolving them is ensuring you know before it happens again. Internally you know when there is an outage; exposing that externally is always about making yourself look good not customer experience.
What you’re describing is the incident management process. That also doesn’t require management input because you’re not going to wait for some fucking suit to respond to a Slack message. Your alarms have severities that give you agency. Again, small businesses sure you might not, but at large scale, especially with anyone holding anything like a SOC2, you have procedures in place and you’re stopping the bleeding. You will have some level of leadership that steps in and translates what the individual contributors are doing to business speak; that doesn’t prevent you from telling your customers shit is fucked up.
The only time a company actually needs to properly evaluate what’s going on before announcing is a security incident. There’s a huge difference between “my honeypot blew up” and “the database in this region is fucked so customers can’t write anything to it; they probably can’t use our product.” My honeypot blowing up might be an indication I’m fucked or that the attackers blew up the honeypot instead of anything else. Can’t send traffic to a region? Literally no reason the customer would be able to so why am I not telling them?
I read your response as either someone who knows nothing about the field or someone on the business side who doesn’t actually understand how single panes of glass work. If that’s not the case, I apologize. This is a huge pet peeve for basically anyone in the SRE/DevOps space who consumes these shitty status pages.
This is a common problem. Same thing happens with AWS outages too. Business people get to manually flip the switches here. It’s completely divorced from proper monitoring. An internal alert triggers, engineers start looking at it, and only when someone approves publishing the outage does it actually appear on the status page. Outages for places like GitHub and AWS are tied to SLAs that are tied to payouts or discounts for huge customers so there’s an immense incentive to not declare an outage even though everything is on fire. I have yelled at AWS, GitHub, Azure, and a few smaller vendors for this exact bullshit. One time we had a Textract outage for over six hours before AWS finally decided to declare one. We were fucking screaming at our TAM by the end because no one in our collective networks could use it but they refused to declare an outage.
Just alias pdoman=podman. I do that with all my common typos.
The problem is the underlying API. parseInt(“550e8400-e29b-41d4-a716-446655440000”, 10) (this is a UUID) returns 550. If you’re expecting that input to not parse as a number, then JavaScript fails you. To some degree there is a need for things to provide common standards. If your team all understands how parseInt works and agrees that those strings should be numbers and continues to design for that, you’re golden.
I can’t find this being a problem. What circles do you move in where “jerk” is a problematic word?
All of these packaging systems have plenty of tutorials. Speaking from experience, many maintainers were not developers when they started maintaining packages for distros other than the official distros. I have worked with several maintainers who do work in tech and know socially several who had no background. This could be a great place for you to start!
You bother because FOSS is as much paying it forward as it is getting shit for free.
I mean it’s FOSS. Have you considered opening a PR to contribute what’s missing? You can be the change you want to see. I wouldn’t normally comment something like this. Your emphasis on “still” raised my hackles a little bit and led me to ask why you still haven’t made your own.
In case you want to fact check this post, I highly recommend Glyn Moody’s Rebel Code. It’s a nice, fast read and covers all sorts of cool shit. I’d love to see a sequel covering newer events.
(Edit: OP is facetious; mine is only facetious in that it references OP)
I like how simple it is. It’s made distrohopping very, very simple for me over the years. The only pet machines I have are my actual dev boxes. The rest are cattle I manage with other tools. Galaxy has also made it much simpler to consume other Ansible which used to be really annoying.
I’m on the fence about Nix. When I first saw years ago it was yet another package management system. I’ve seen enough interesting things with it now that I’ll probably try it out the next time I want to rebuild my configs from scratch.
I really like Ansible and have used it for my personal dotfiles for years. I don’t think it’s a silver bullet and I’m aware of a lot of the criticism. Containerization or immutable infra solves more production problems so I don’t really use it much at work.
At least in the devops/SRE circles I work in, we know there are different tools for different jobs. While we might fight about which is the best, I haven’t seen the ossification you’re describing.
There are valid reasons to use one instead of the other. In most cases there isn’t a difference to the end user.
I am still mystified by IDE VCS tools. It’s usually faster for me to do a quick CLI shuffle than use the IDE.
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.
If a repo is very popular, it should have a lot of forks. The higher the upstream popularity, the higher the downstream popularity. When a dev makes a claim that there are a ton of malicious forks stealing IP, we can vet that claim by looking at the forks that respect the upstream. Big projects have a big community with big forks with many stars. The popular downstreams drive traffic to the upstream.
In this case, we have a couple hundred direct forks. That’s not a ton. Out of those, only three have stars. All of them only have one star. At face value, that could imply a few things: the repo is not very popular, the community is centralized around the upstream, or something else along those lines. Comparing this to other open source projects, our initial conclusion is that this is not a hugely popular repo and does not get a lot of development outside of its incredibly niche community.
Occam’s razor is a tool, not objective truth. Based on the facts as we can see them, this focus on forking from the dev is much more indicative of a burnout spiral, incredibly common in the FOSS community, than nefarious actors. If we see receipts, eg a collection of takedown requests on malicious forks attempting to claim ownership of the code, our analysis falls apart. That’s still a possibility, however remote.
There were forks that wanted to hide the fact that they were Floorp forks, forks that did not want to contribute to Floorp at all, forks that used the code for life and just changed the name of Floorp, and many other forks were born.
There are three visible forks that have any stars. All of them have one star. You’re telling me that a project that is so widely and maliciously repackaged has no normal forks with more than one star? Is this tech that only bad actors want to use and has no following in the open source community?
Where are these evil forks, how do we actually know they’re forks, and why are they still up if they’re breaking license?
Edit: Here is a fork with 200+ stars that isn’t a direct GH fork. Given its premise is an opinionated and branded Floorp, is it morally wrong for its maintainers to not contribute to Floorp (assuming they don’t only for the sake of argument)? Does your answer apply to fediverse server owners (eg Mastodon, Lemmy) whose premise is hosting an opinionated and branded instance often explicitly without the technical skill to suggest patches?
I catch a lot of shit for my distaste of GPL. I don’t think I should be able to tell you what you can and can’t do with my source code. I’ve released it into the wild. If I put caveats on it it’s not really free.