Feature

Red Hat Enterprise Linux 8 developer cheat sheet

Red Hat Enterprise Linux 8 developer cheat sheet

With the release of Red Hat Enterprise Linux 8, I’m pleased to introduce our new RHEL 8 cheat sheet for developers. This version has been updated from the beta version to reflect the final updates in RHEL 8. This document is intended for those of you who are:

  1. Already familiar with Red Hat Enterprise Linux, but you want a quick reference for new RHEL 8 commands.
  2. New to Red Hat Enterprise Linux and want to start exploring RHEL 8.

Here’s a sample of some of the common module commands you’ll find in this cheat sheet. 

Continue reading “Red Hat Enterprise Linux 8 developer cheat sheet”

Share
Red Hat Enterprise Linux 8 now generally available

Red Hat Enterprise Linux 8 now generally available

I think Red Hat Enterprise Linux 8 is the most developer-friendly Red Hat Enterprise Linux that we’ve delivered, and I hope you agree. Let’s get down to business, or rather coding, so you can see for yourself. You can read the Red Hat corporate press release.

For this article, I’ll quickly recap Red Hat Enterprise Linux 8 features (architecture, containers), introduce the very new and cool Red Hat Universal Base Image (UBI), and provide a handy list of developer resources to get you started on Red Hat Enterprise Linux 8.

TL;DR

Download RHEL 8 now

Download RHEL 8 image

Continue reading “Red Hat Enterprise Linux 8 now generally available”

Share
Podman basics cheat sheet

Podman basics cheat sheet

Here and elsewhere, we get a lot of questions about post-Docker container tools in Red Hat Enterprise Linux 7.6 and Red Hat Enterprise Linux 8 beta. Tools like podman, buildah, and skopeo enable you to create and manage rootless containers, which are containers that don’t require root access to be built and deployed. To help you master the basics, we’re happy to offer a new podman basics cheat sheet.

Continue reading “Podman basics cheat sheet”

Share
Not all OpenJDK 12 builds include Shenandoah: Here’s why

Not all OpenJDK 12 builds include Shenandoah: Here’s why

OpenJDK 12 is now out, and it has new features. These are:

189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
230: Microbenchmark Suite
325: Switch Expressions (Preview)
334: JVM Constants API
340: One AArch64 Port, Not Two
341: Default CDS Archives
344: Abortable Mixed Collections for G1
346: Promptly Return Unused Committed Memory from G1

When I follow the link from the OpenJDK 12 project page to the open source builds page, I see the downloadable binaries. I download the Linux binary and install it, then see if the first item on the feature list, Shenandoah, works:

$ ./jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -cp ~ Hello
Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

Oh! What is going on?

Continue reading “Not all OpenJDK 12 builds include Shenandoah: Here’s why”

Share
Introduction to Kubernetes: From container to containers

Introduction to Kubernetes: From container to containers

After being introduced to Linux containers and running a simple application, the next step seems obvious: How to get multiple containers running in order to put together an entire system. Although there are multiple solutions, the clear winner is Kubernetes. In this article, we’ll look at how Kubernetes facilitates running multiple containers in a system.

Continue reading “Introduction to Kubernetes: From container to containers”

Share
Migrating Java applications to Quarkus: Lessons learned

Migrating Java applications to Quarkus: Lessons learned

Migrating applications from a well-grounded framework to a completely new framework just a few days after its public release sounds crazy, right? Before doing so, I asked myself several questions, such as: Why should I do that? Is this new framework stable? What would be the gain? To me, the most important of these is: Why?

To help answer that question, I started thinking about my application’s performance—in this case, the bootstrap time—and asked myself whether I was happy with the actual time my application took to start up. The answer was no. And, nowadays, this is one of the most important metrics to be considered when working with microservices, mainly on a serverless architecture.

The goal of this article is to provide a point of reference for a basic migration of an existing Java EE application to Quarkus. For this reason, I’ll save a few lines of the article by not introducing Quarkus and focus mostly on the migration part. If you don’t know what Quarkus is, then I recommend reading this article and visiting the Quarkus homepage.

In this article, I’ll try to illustrate all the changes, or at least the most important changes, that I had to do on my existing application to make it run well with Quarkus.

Continue reading “Migrating Java applications to Quarkus: Lessons learned”

Share
Understanding when not to std::move in C++

Understanding when not to std::move in C++

One of the most important concepts introduced in C++11 was move semantics. Move semantics is a way to avoid expensive deep copy operations and replace them with cheaper move operations. Essentially, you can think of it as turning a deep copy into a shallow copy.

Move semantics came along with several more or less related features, such as rvalue references, xvalues, forwarding  references, perfect forwarding, and so on. The standard C++ library gained a function template called std::move, which, despite its name, does not move anything. std::move merely casts its argument to an rvalue reference to allow moving it, but doesn’t guarantee a move operation. For example, we can write a more effective version of swap using std::move:

template<typename T>
void swap(T& a, T& b)
{
  T t(std::move (a));
  a = std::move (b);
  b = std::move (t);
}

This version of swap consists of one move construction and two move assignments and does not involve any deep copies. All is well. However, std::move must be used judiciously; using it blithely may lead to performance degradation, or simply be redundant, affecting readability of the code. Fortunately, the compiler can sometimes help with finding such wrong uses of std::move. In this article, I will introduce two new warnings I’ve implemented for GCC 9 that deal with incorrect usage of std::move.

Continue reading “Understanding when not to std::move in C++”

Share