Fedora / Red Hat / IBM Leftovers
-
Open source events: 4 goals to set and how to measure them
Events are an essential component of open source community health. A positive event experience can inspire current contributors and encourage new ones. But how can you tell whether your events are successful?
We at the CHAOSS (Community Health Analytics Open Source Software) App Ecosystem Working Group have considered this question for our events to maintain the health of the communities involved. The CHAOSS App Ecosystem includes several projects focused on developing applications for the Linux platform. While currently dominated by the GNOME and KDE communities, it is not defined by them. The app ecosystem, as it stands today, is primarily driven by volunteers with altruistic goals organized around free software principles. The work we share in this article is an update from our November 2020 article about success metrics for open source events.
We follow the goal-question-metric approach. We first identify several goals that a person or organization might have. We then identify questions we need to answer to achieve those goals. Finally, for each question, we consider quantifiable metrics that provide answers. For event organizers, we established four goals.
-
7 tips for dealing with a narcissistic boss [Ed: IBM explains how to deal with IBM managers, who mistreat staff]
An overblown sense of self. A feeling that they can do no wrong. Perfectionism. Insecurities. Entitlement. No boundaries. Lack of empathy.
These are characteristics of a narcissist.
What happens when you work for someone whose behavior is so challenging to manage that you can’t focus on your work?
Part of a narcissist’s behavior is to belittle or challenge others. They do this to elevate and bring the focus back onto themselves. Narcissists bring up issues for us about ourselves or our past that have nothing to do with them, but we become emotionally activated, regardless.
Below are some tactics that can guide you through reporting to a narcissistic boss.
-
David Rheinsberg: Towards Stable Rust UEFI Firmware
While Tianocore EDKII still dominates the UEFI development world, there has been continuous effort to enable Rust for firmware development. But so far the tools involved have not been stabilised. We now started an effort to remedy this and get stable Rust support for UEFI targets.
-
The business case for supporting EPEL - Fedora Magazine
EPEL stands for Extra Packages for Enterprise Linux. EPEL is a collection of packages built and maintained by the community for use in Red Hat Enterprise Linux (RHEL), CentOS Stream, and RHEL-like distributions like Rocky Linux and Alma Linux.
I am going to make the case that if you use EPEL as part of your organization’s infrastructure, you have an interest in keeping those packages available and as secure as they can be.
Who is this article for? I’m thinking of the team leads, managers, and directors in IT departments who make decisions about the tools their organizations have access to.
If you don’t use or know about EPEL, it’s likely that you don’t have to think about these things. In this case this article isn’t for you. However, it might contain ideas for promoting sustainable uses of free and open source software that you can apply to other situations that are more relevant to you.
-
Dan Winship (Red Hat): Kubernetes’s IPTables Chains Are Not API
Some Kubernetes components (such as kubelet and kube-proxy) create iptables chains and rules as part of their operation. These chains were never intended to be part of any Kubernetes API/ABI guarantees, but some external components nonetheless make use of some of them (in particular, using KUBE-MARK-MASQ to mark packets as needing to be masqueraded).
As a part of the v1.25 release, SIG Network made this declaration explicit: that (with one exception), the iptables chains that Kubernetes creates are intended only for Kubernetes’s own internal use, and third-party components should not assume that Kubernetes will create any specific iptables chains, or that those chains will contain any specific rules if they do exist.
Then, in future releases, as part of KEP-3178, we will begin phasing out certain chains that Kubernetes itself no longer needs. Components outside of Kubernetes itself that make use of KUBE-MARK-MASQ, KUBE-MARK-DROP, or other Kubernetes-generated iptables chains should start migrating away from them now.