1_DevOps'ish

Generative AI has made big strides in recent years. Diffusion models make decent art and modern large language models can out-write even the best college student on a deadline. Over the holidays I tried it out by building an app.

More than 130,000 people were joining the new independent social media network a day in November. So why hasn’t it taken off?

good morning and welcome to 2023 pic.twitter.com/44vDM8OkXQ— forrestbrazeal@hachyderm.io (@forrestbrazeal) January 9, 2023

@ChrisShort@hachyderm.io We had 5 mins of sunshine so far in the month of Jan. Though it looks like that will change today. Apparently our last "Mostly Sunny" day was December 4.

This whole fediverse trend of responding to ideas about improving moderation with "well just make a personal block list, there you go" really needs to die. Personal filters and block lists are not "moderation" they aren't an affirmation of shared community values, they can't replace moderation to effectively stem the flow of hate content. They don't meet the need. If you don't have this need that is fine. There are places you can go. But lots of people do. jeeeeez

Gotta go fast

We've run hundreds of GPU benchmarks on all the current Nvidia and AMD graphics cards and ranked them in our comprehensive hierarchy.

Follow us on Twitter @HackRead - Facebook @ /HackRead

Vanilla OS, an Ubuntu-based Linux distribution, recently had its first stable release. Much like other Ubuntu-based distributions, it emphasizes ease of use. However, it approaches this differently than many others.

“Humans deserve to know when the writing isn’t human.”

Holy cow! Memorandum of Understanding to give farmers access to 'diagnostic tools' and documentation

Repo for SIG release. Contribute to kubernetes/sig-release development by creating an account on GitHub.

StayFocusd increases your productivity by limiting the amount of time that you can spend on time-wasting websites.

From economic headwinds to breakthrough technologies, 2023 is shaping up to be a year like no other. Join env0 CEO Ohad Maislish, AWS Senior Developer Advocate Chris Short, MGM Resorts International Principal Enterprise Architect Brandt Meyers, and BCG Gamma AI Senior Software Engineer Abel Essiane for a candid discussion of the past, present and future of IaC.

In this episode, Pete and Lisa discuss why great communication (both internally and externally) is essential to the success of any incident management process.

Designed to remove barriers to gaming and help players with disabilities play more easily, more comfortably and for longer periods on PS5.

Storing clean energy is crucial for climate action, and how we do it is fascinating.

Tech job cut announcements were up 649% in 2022 from the nearly 13,000 announced in 2021, Challenger reported.

Have you ever found yourself in a situation where you accidentally pushed secret keys or huge files while using Git? Did you know that removing those keys even 20 seconds after might be already too late?

Lots. And, bad news, kids, it will not be easy to manage.

Authors: Filip Křepinský (Red Hat), Morten Torkildsen (Google), Ravi Gudimetla (Apple) Ensuring the disruptions to your applications do not affect its availability isn't a simple task. Last month's release of Kubernetes v1.26 lets you specify an unhealthy pod eviction policy for PodDisruptionBudgets (PDBs) to help you maintain that availability during node management operations. In this article, we will dive deeper into what modifications were introduced for PDBs to give application owners greater flexibility in managing disruptions. What problems does this solve? API-initiated eviction of pods respects PodDisruptionBudgets (PDBs). This means that a requested voluntary disruption via an eviction to a Pod, should not disrupt a guarded application and .status.currentHealthy of a PDB should not fall below .status.desiredHealthy . Running pods that are Unhealthy do not count towards the PDB status, but eviction of these is only possible in case the application is not disrupted. This helps disrupted or not yet started application to achieve availability as soon as possible without additional downtime that would be caused by evictions. Unfortunately, this poses a problem for cluster administrators that would like to drain nodes without any manual interventions. Misbehaving applications with pods in CrashLoopBackOff state (due to a bug or misconfiguration) or pods that are simply failing to become ready make this task much harder. Any eviction request will fail due to violation of a PDB, when all pods of an application are unhealthy. Draining of a node cannot make any progress in that case. On the other hand there are users that depend on the existing behavior, in order to: prevent data-loss that would be caused by deleting pods that are guarding an underlying resource or storage achieve the best availability possible for their application Kubernetes 1.26 introduced a new experimental field to the PodDisruptionBudget API: .spec.unhealthyPodEvictionPolicy . When enabled, this field lets you support both of those requirements. How does it work? API-initiated eviction is the process that triggers graceful pod termination. The process can be initiated either by calling the API directly, by using a kubectl drain command, or other actors in the cluster. During this process every pod removal is consulted with appropriate PDBs, to ensure that a sufficient number of pods is always running in the cluster. The following policies allow PDB authors to have a greater control how the process deals with unhealthy pods. There are two policies IfHealthyBudget and AlwaysAllow to choose from. The former, IfHealthyBudget , follows the existing behavior to achieve the best availability that you get by default. Unhealthy pods can be disrupted only if their application has a minimum available .status.desiredHealthy number of pods. By setting the spec.unhealthyPodEvictionPolicy field of your PDB to AlwaysAllow , you are choosing the best effort availability for your application. With this policy it is always possible to evict unhealthy pods. This will make it easier to maintain and upgrade your clusters. We think that AlwaysAllow will often be a better choice, but for some critical workloads you may still prefer to protect even unhealthy Pods from node drains or other forms of API-initiated eviction. How do I use it? This is an alpha feature, which means you have to enable the PDBUnhealthyPodEvictionPolicy feature gate , with the command line argument --feature-gates=PDBUnhealthyPodEvictionPolicy=true to the kube-apiserver. Here's an example. Assume that you've enabled the feature gate in your cluster, and that you already defined a Deployment that runs a plain webserver. You labelled the Pods for that Deployment with app: nginx . You want to limit avoidable disruption, and you know that best effort availability is sufficient for this app. You decide to allow evictions even if those webserver pods are unhealthy. You create a PDB to guard this application, with the AlwaysAllow policy for evicting unhealthy pods: apiVersion : policy/v1 kind : PodDisruptionBudget metadata : name : nginx-pdb spec : selector : matchLabels : app : nginx maxUnavailable : 1 unhealthyPodEvictionPolicy : AlwaysAllow How can I learn more? Read the KEP: Unhealthy Pod Eviction Policy for PDBs Read the documentation: Unhealthy Pod Eviction Policy for PodDisruptionBudgets Review the Kubernetes documentation for PodDisruptionBudgets , draining of Nodes and evictions How do I get involved? If you have any feedback, please reach out to us in the #sig-apps channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: kubernetes-sig-apps@googlegroups.com

This type of devastating scheme ensnares victims and takes them for all they’re worth—and the threat is only growing.

These apprentice tailors learn backwards: first the last thing you do (sewing buttons, hemming), and then the thing before that, until finally learning to cut. Understand the ramifications of what you're doing before you do it. Like if you learned to support software before you learned to deploy it, and only then did you try cutting code https://podcast.oddly-influenced.dev/episodes/legitimate-peripheral-participation