I assume this is Poe’s Law in action. Elon historically doesn’t understand shit about tech so the commenter is just highlighting something that’s been GA for other tools for years.

This isn’t recent. This has been an ongoing thing for at least 20 years (if not longer; that’s just the earliest I remember having this convo). Yes, it cleans the wound by killing things but it also fucks up the healthy tissue around the wound (see other comments for a more scientific explanation). Having some in a medical kit is useful for other activities such as diluting with water for an ear rinse, diluting with water for various mouth stuff (rinse not swallow), and some skin treatments (again, diluting first).

Strange; the page is shilling for a product that doesn’t use raw HTML for its site.

This is just distributed functions, right? This has been a thing for years. AWS Lambda, Azure Functions, GCP Cloud Functions, and so on. Not everything that uses these is built on a distributed functions model but a fuck ton of enterprises have been doing this for years.

There are an unsurprisingly large number of Ubuntu 16 boxes in the clouds. A quick google even shows a Spring 2024 course from a major US university recommending 32-bit Ubuntu 16.

And as long as you don’t need simple access to most features such as volumes. The podman implementation on not Linux leaves quite a bit to be desired for anyone trying to do more than just run a binary wrapped in a container. I’m not throwing shade because it’s FOSS and anything is better than Docker. Only Docker will work for a production-capable dev environment on not Linux unless podman’s development has exponentially increased in the last year since I tried to move a shop to podman on not Linux.

As long as you’re on Linux, podman is superior and will do all of the things you’re asking about. If you need to also support Windows or Mac, Docker is the only thing that will work (although people have told me Rancher isn’t bad now for a couple of years).

I bring new software into my organization through two methods:

1. Someone has used it before
2. We are reasonably confident in our ability to use existing staff, possibly with a new expert hire or consultation

It’s pretty rare for a large org to do completely net new software. Training is usually a big deal if that happens. Massive layoffs are also a possibility (see enterprises being dumb about containers). Smaller orgs tend not to have this problem. If they do you can usually tell in an interview and just not go there. Devs are constantly experimenting with net new shit (current libs don’t do the thing; gotta find new libs). Again, smart leaders are open to this.

In general, staffing is a huge part of any of these decisions. You might not see the convo but it is most likely happening.

If someone doesn’t understand the difference between swearing at and swearing around, that’s a shitty environment. If I say, “that was a shitty fucking outage” I am using some filler for emphasis so my mouth can catch up to my brain. If I say “you’re a fucking asshole” or “don’t be such a bitch” or “that’s fucking sexy” I am not being professional and I deserve some training on how to not be an ignorant walnut. Even with swearing around, I do think it’s smart to limit yourself to damnation, defecation, and simple fornication rather than gendered swears. There are also some places it’s not wise to swear around, such as client-facing roles because many of the people you will see don’t understand that swearing around is not swearing at.

I once lost a job after the onsite interview. I wait to swear until I I hear them swear. Apparently my use of “fuck” meant I was going to blow up and be a terrible person to my peers. Two years later I started running a department doing the thing I was interviewing for and my staff tends to be fiercely loyal. I’d argue my swearing speaks for itself and have shaped my professional attitude toward swearing around around this experience.

I work in tech and I’m quick to police my language if necessary. I’m also concerned about relative comfort (eg I try really hard not to blaspheme around some Christian peers). I do not swear at people. I do not work in a super corporate environment. YMMV.

I like study (you can find the full article online) and I think there’s been more research down this path in the years since.

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.

This issue has nothing to do with SaaS and everything to do with regular software updates (which are not limited to SaaS). Change the package to “LibreOffice Writer” and the delivery to “pacman -Syu” and suddenly the same bug has the potential to hit me. Hell, I have (well, had) floppies fresh from the store that introduced bugs into existing software back when I was a kid. Bugs will always exist and there isn’t enough regression testing in the world to ensure they don’t happen in the future.

All of your SaaS points are correct they just don’t apply here. We should be mad about the lack of testing in this instance.

That’s not all GNU/Linux though. Either the OP doesn’t understand a very common container OS, Alpine, doesn’t use systemd (also Void Linux and others outside the container space) or it’s something else.

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?

That’s fair! I agree with that.

Neither wins here. I cannot tell you how many libraries I have had to replace because FOSS devs move on. It’s probably greater than the number of products I’ve had to abandon for lack of support but I’m not sure what that is at a percentage level. In the DevOps world everything burns constantly, paid and free.

It’s very misleading to say “paying for software is stupid” and not consider the total cost of ownership. TCO includes things like infrastructure and maintenance. As an exec, I am constantly faced with two choices: free software that might do what I want or paid software that sort of does what I want. At face value, you would immediately tell me to get the free stuff. That’s where you miss TCO.

(Read the last paragraph if you think the business lens is bullshit)

Every FOSS solution I run requires me to deploy and maintain it. I only have so many hours in the day so at some threshold I have to hire more and more people to deploy and maintain. Integrating? That’s on me too because I’m using free software so now I need a resource to glue things together. My “free” option actually costs a portion of my engineering resources. I’m also on the hook for failures. Running my own ERP? I need to have support staff on-call to handle outages.

Every paid solution I run costs can require some of those things. Let’s ignore paid licenses and just focus on things I can completely outsource. This means I’m no longer on the hook for deployment and maintenance, so if I can show the cost of the paid software is less than my TCO, it’s a better deal. If I have a good relationship with the vendor, I might be able to delegate my integration needs to their product pipeline. I might be able to purchase a support contract that’s cheaper than running my own.

At some point every company will outgrow certain software. It’s a constant reevaluation of the costs of paid vs TCO of free and when I need to spend resources making it do something it doesn’t. A managed telemetry stack like Sumo or New Relic allows me to scale quickly but cheaply until I have the revenue to build an in-house team to instrument fucking everything.

The exact same logic applies to my time. I could run free everything. That comes with a higher TCO (usually). I say this as someone who has rebuilt dot files repos on the dot every three years and been running Linux since you could get it in a book at B Dalton at the indoor shopping mall so my tolerance for personal TCO is very high. However, I don’t change my own oil. It’s free! I could do it myself! I don’t want to. I buy certain things, like software, in my personal life because the TCO of FOSS is higher than I want to pay. I have outgrown Windows and Mac so I have some level required cost in Linux. I pay for some things like storage and routing solutions even though I could build and deploy and maintain all of that myself. Sometimes I just want my shit to work and not have to do it myself.

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.

They’ve renamed Kyber512 and still recommend it. If you believe DJB this is bad. If you believe in a government agency avoiding even the slightest appearance of backdooring (which they have consistently done), this is bad. If you trust NIST, this is fine.