Tux Machines
Posted by Roy Schestowitz on Aug 31, 2023
=> Programming Leftovers | Software: WordPress, Olivia, Video Players, and More
It is fair to say that the DNF package manager is not the favorite tool of many Fedora users. It was brought in as a replacement for Yum but got off to a rather rocky start; DNF has stabilized over the years, though and the complaints have subsided. That can only mean one thing: it must be time to throw it away and start over from the beginning. The replacement, called DNF5, was slated to be a part of the Fedora 39 release, due in October, but that is not going to happen.
DNF sits on top of the RPM package manager and handles higher-level tasks, managing the software mix on the system as a whole. It deals with repositories, manages system updates, and more. On a modern Fedora (or Red Hat) system, DNF is probably invoked by users much more often than RPM is. Given its central role, DNF has to be solid; the alternative would likely lead to the creation of wrecked systems, which is seen as generally undesirable. At its outset, DNF was not as solid as many would have liked, but Fedora users worked the kinks out of it, and it became stable enough to be used in the Red Hat Enterprise Linux products as well.
In September 2022, a system-wide change proposal was posted, describing a plan to replace DNF with the entirely new DNF5 package manager. DNF5, it was said, would ""provide a significant improvement in user experiences and performance"". It is a complete rewrite from scratch, in C++, resulting in a tool that is both smaller and faster than DNF (which is implemented in Python). The new tool would result in less duplicated code on Fedora systems and a more robust method of storing package metadata. It claims better integration with PackageKit — though it is not clear that PackageKit has a long future either. DNF5 was also planned to have full support for Modularity; this also has limited value now that Fedora has given up on Modularity.
=> ↺ What CentOS Discontinuation Means And The Impact On AppViewX
In a surprising turn of events, the open-source community received a significant jolt when the CentOS Project announced the end of life for CentOS in 2020. CentOS, a popular Linux distribution known for its stability, reliability, and long-term support, has been a go-to choice for countless users, businesses, and organizations worldwide. This announcement has left many in the tech industry contemplating implications and seeking alternatives. This blog post will explore the reasons behind CentOS’s end-of-life decision, its impact on the community, and potential alternatives for CentOS users moving forward.
For nearly two decades, CentOS has played a crucial role in the world of Linux distributions. It was known as a reliable, free, and community-driven operating system that aimed to provide a stable platform derived from the downstream source code of Red Hat Enterprise Linux (RHEL). CentOS offered long-term support, security updates, and a platform that was compatible with RHEL, making it an attractive choice for businesses and individuals seeking stable and enterprise-grade Linux distribution without the associated costs of RHEL subscriptions.
=> ↺ Presenting a new Istio operator on OpenShift
A new operator for Istio is now available on Red Hat OpenShift as a developer preview. This new operator, temporarily known as the Sail Operator, will serve as the foundation for Red Hat OpenShift Service Mesh 3, which will be released in the upcoming year.
=> ↺ Red Hat OpenShift | ↺ developer preview
=> ↺ Red Hat OpenShift | ↺ developer preview
=> ↺ Go for C++ developers: A beginner's guide
After years of working on software written in C and C++, I switched to working on a project that is implemented in Go. More developers may find themselves working in the Go ecosystem as more software, such as Red Hat OpenShift and Kubernetes, is implemented in Go. This article discusses the primary language differences between Go and C++, differences in the development environments, and differences in the program-building environment. Examples and code snippets are from the Grafana sources.
=> ↺ C and C++ | ↺ Go | ↺ Red Hat OpenShift | ↺ Kubernetes
=> ↺ C and C++ | ↺ Go | ↺ Red Hat OpenShift | ↺ Kubernetes
=> gemini.tuxmachines.org This content has been proxied by September (3851b).Proxy Information
text/gemini;lang=en-GB