Language Selection

English French German Italian Portuguese Spanish

IBM/Red Hat: RHELvolution, Command Line Heroes, Eclipse and OpenShift

Filed under
Red Hat
  • RHELvolution: A brief history of Red Hat Enterprise Linux releases from early days to RHEL 5

    The launch of Red Hat Enterprise Linux 8 (RHEL 8) at Red Hat Summit 2019 was a jubilant event. Not only for the many team members around the world who worked to make the next-generation of the world?s leading enterprise Linux platform a reality, but also for customers who are excited to utilize its new capabilities in driving business innovation.

    This is a great time to reflect on what is so special about RHEL 8 by taking a walk through time on the evolution of RHEL. The RHELvolution, if you will. I'll be your guide on this journey, having been at the helm for RHEL engineering since the beginning (2001), starting with Red Hat Enterprise Linux 2.1. And yes, we'll explain why it started with 2.1.

    It has been thrilling to be part of the RHEL team all these years. Having worked on proprietary UNIX operating systems before being at Red Hat, constructing RHEL offered a first hand view of the power of open source. Through collaboration with customers, community and a highly motivated team, we have had a global impact on the IT landscape. Evolving from "lighting up the box" to dynamic infrastructure that helps to advance the state of the art while liberating customers from vendor lock-in (originally at the hardware level, later expanded to hybrid cloud).

  • Command Line Heroes season 3 episode 4: Diving for Perl
  • How Developers Can Survive the Last Mile with CodeReady Workspaces

    As a way to piece together this explosion of available open source tools into simple and coherent single interface for cloud native deployments, the Eclipse Foundation offers the Eclipse Che integrated development environment (IDE).

    Today’s often desperate need for Eclipse Che can be traced back to the evolution of open source tools during the past 10 years. Not only have these tools been evolving, but in many cases, they have been outright created from scratch. That’s posed a bit of a problem for those out on the cutting edge of scalable microservices as the stable infrastructure components of old gave way to a hodgepodge of brand new open source and commercial products and tools.

    Inside each cloud provider, a host of tools can address CI/CD, testing, monitoring, backing up and recovery problems. Outside of those providers, the cloud native community has been hard at work cranking out new tooling from Prometheus, Knative, Envoy and Fluentd, to Kubenetes itself and the expanding ecosystem of Kubernetes Operators.

    Within all of those projects, cloud-based services and desktop utilities is one major gap, however: the last mile of software development is the IDE. And despite the wealth of development projects inside the community and Cloud Native Computing Foundation, it is indeed the Eclipse Foundation, as mentioned above, that has taken on this problem with a focus on the new cloud development landscape.

  • IBM is bringing Red Hat OpenShift to Its Platforms

    IBM is fully embracing Red Hat OpenShift. The company recently announced that it will use Red Hat OpenShift as the primary container environment for all its hybrid cloud offerings. This includes IBM Cloud, IBM Cloud Paks running on OpenShift, an entire field of IBM consultants and services people being trained on OpenShift, and OpenShift on IBM Power Systems and Storage, IBM Z and LinuxONE enterprise platforms. With this move, Red Hat OpenShift has become the preferred Kubernetes platform for IBM to address the needs of increasingly critical container workloads.

    With Red Hat OpenShift running on top of IBM’s cloud and systems, existing IBM customers can unlock the hybrid cloud model for software developers and systems architects. OpenShift can transform IBM systems that have been optimized for data, transaction processing and AI workloads into another resource for container-based infrastructure, inside the fold when it comes to networking, APIs and data access controls.

  • Disaster Recovery Strategies for Red Hat OpenShift

    As increasingly complex applications move to the Red Hat OpenShift platform, IT teams should have disaster recovery (DR) processes in place for business continuity in the face of widespread outages. These are not theoretical concerns. Many industries are subject to regulations that require data protection even in the event of massive failures. For instance, CFR 164.308(7)(ii)(Cool of the HIPAA regulation stipulates that companies must be able to “restore ANY loss of data” (emphasis added) in the event of a failure. Thus for some truly mission critical applications to run on OpenShift, disaster recovery is essential.

More in Tux Machines

Debian: Salsa, Promoting Debian LTS and Debian Patch Porting System

  • salsa.debian.org: Postmortem of failed Docker registry move

    The Salsa admin team provides the following report about the failed migration of the Docker container registry. The Docker container registry stores Docker images, which are for example used in the Salsa CI toolset. This migration would have moved all data off to Google Cloud Storage (GCS) and would have lowered the used file system space on Debian systems significantly. [...] On 2019-08-06 the migration process was started. The migration itself went fine, although it took a bit longer than anticipated. However, as not all parts of the migration had been properly tested, a test of the garbage collection triggered a bug in the software. On 2019-08-10 the Salsa admins started to see problems with garbage collection. The job running it timed out after one hour. Within this timeframe it not even managed to collect information about all used layers to see what it can cleanup. A source code analysis showed that this design flaw can't be fixed. On 2019-08-13 the change was rolled back to storing data on the file system.

  • Raphaël Hertzog: Promoting Debian LTS with stickers, flyers and a video

    With the agreement of the Debian LTS contributors funded by Freexian, earlier this year I decided to spend some Freexian money on marketing: we sponsored DebConf 19 as a bronze sponsor and we prepared some stickers and flyers to give out during the event. The stickers only promote the Debian LTS project with the semi-official logo we have been using and a link to the wiki page. You can see them on the back of a laptop in the picture below.

  • Raphaël Hertzog: Freexian’s report about Debian Long Term Support, July 2019

    Like each month, here comes a report about the work of paid contributors to Debian LTS.

  • Jaskaran Singh: GSoC Final Report

    The Debian Patch Porting System aims to systematize and partially automate the security patch porting process. In this Google Summer of Code (2019), I wrote a webcrawler to extract security patches for a given security vulnerability identifier. This webcrawler or patch-finder serves as the first step of the Debian Patch Porting System. The Patch-finder should recognize numerous vulnerability identifiers. These identifiers can be security advisories (DSA, GLSA, RHSA), vulnerability identifiers (OVAL, CVE), etc. So far, it can identify CVE, DSA (Debian Security Advisory), GLSA (Gentoo Linux Security Advisory) and RHSA (Red Hat Security Advisory). Each vulnerability identifier has a list of entrypoint URLs associated with it. These URLs are used to initiate the patch finding.

Android Leftovers

Marek’s Take: Why open source communities are critical to operators

Open source locks down standards in code and makes sure it is interoperable, Rice said. “That’s why it’s symbiotic. Standards are options but they come together because they are built on one another.”

And, similar to standards bodies, where delegates work side-by-side with competitors to develop global specifications, the same occurs in open source groups.

Read more

The infrastructure is code: A story of COBOL and Go

But what about today? With the decline of mainframes and the rise of newer and more innovative languages designed for the web and cloud, where does COBOL sit? As last week's episode of Command Line Heroes mentioned, in the late 1990s, Perl (as well as JavaScript and C++) was outpacing COBOL. And, as Perl's creator, Larry Wall stated then: "COBOL is no big deal these days since demand for COBOL seems to be trailing off, for some strange reason." Read more