The Java community has demonstrated time and time again its ability to evolve, improve, and adapt to meet the needs of its developers and users. Even after 25 years of language and framework choices, Java has consistently ranked in the top languages in use today due to its strong track record and capabilities in enterprise use cases. Red Hat has long been a strong leader in Java and open source software development and remains committed to being at the forefront of Java as it continues to evolve.
Today, Red Hat and the GraalVM community jointly established a new downstream distribution of GraalVM, called Mandrel. This distribution will power the Red Hat build of Quarkus, a recently announced addition to Red Hat Runtimes. This article explains what Mandrel is and why it is necessary.
Continue reading “Mandrel: A community distribution of GraalVM for the Red Hat build of Quarkus”
I’ve had many proud moments in my role here at Red Hat over the years. Examples include when we released the first version of WildFly, when we acquired the Camel team, when we worked with other vendors to create Eclipse MicroProfile, the great work the Strimzi team did to get into the Cloud Native Computing Foundation, our entire Red Hat Managed Integration effort, Kogito, and the list goes on. I feel like I add to this list of examples on an almost weekly basis.
Well, I can now update this list with the first product release of Quarkus, formally called the Red Hat build of Quarkus. (You can also find more support options on the Quarkus project site.) It should come as no surprise that Quarkus is on this list. I suppose what might surprise some people is that Quarkus is only just a product now. Given all of the activities since we officially launched the Quarkus project in 2019, you could be forgiven for thinking it was already a product.
Continue reading “The road to Quarkus GA: Completing the first supported Kubernetes-native Java stack”
Red Hat Software Collections 3.5 and Red Hat Developer Toolset 9.1 are now available for Red Hat Enterprise Linux 7. Here’s what that means for developers.
Red Hat Software Collections (RHSCL) is how we distribute the latest stable versions of various runtimes and languages through Red Hat Enterprise Linux (RHEL) 7, with some components available in RHEL 6. RHSCL also contains the Red Hat Developer Toolset, which is the set of tools we curate for C/C++ and Fortran. These components are supported for up to five years, which helps you build apps that have a long lifecycle as well.
Continue reading “Red Hat Software Collections 3.5 brings updates for Red Hat Enterprise Linux 7”
It isn’t always easy to understand how Open vSwitch (OVS) cycles are spent, especially because various parameters and configuration options can affect how OVS behaves. Members of the Open vSwitch community are actively working to understand what causes packets drops in Open vSwitch. Efforts so far have included adding a custom statistic for vHost TX retries, tracking vHost TX contention, and adding a coverage counter to count vHost IRQs. We are particularly interested in the user space datapath that uses the Data Plane Development Kit (DPDK) for fast I/O.
Adding these statistics is an ongoing effort, and we won’t cover all of the corners. In some cases, the statistics leave doubts about what is causing a behavior.
In this article, I will introduce a new counter we’ve added to learn more about contention in the vHost transmission path. I’ll also show you how to use the new counter with
perf, and I’ll discuss what’s next for our ongoing efforts.
Continue reading “Debugging vHost user TX contention in Open vSwitch”
In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing
-fstack-check mechanism is insufficient for protection.
So, what should we do? Clearly we want something similar to
-fstack-check, but without the fundamental problems. Enter a new option:
The key principles for code generation to prevent a stack clash attack are:
Continue reading “Stack clash mitigation in GCC, Part 3”
On April 21st, Node.js released its latest major version with Node.js 14. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October 2020. This release brings a host of improvements and features, such as improved diagnostics, a V8 upgrade, an experimental Async Local Storage API, hardened the streams APIs, and more.
While Red Hat will release a Universal Base Image (UBI) for Node.js 14 in the coming months for Red Hat OpenShift and Red Hat Enterprise Linux, this article helps you get started today. If you’re interested in more about Node.js 14’s improvements and new features, check out the article listed at the end.
Continue reading “Use Node.js 14 on Red Hat OpenShift”
We’re expanding tooling support for containers and servers in different development environments. Our existing VS Code extension, Red Hat Server Connector, only provides functionality for Red Hat servers and runtimes like WildFly, Minishift, Red Hat JBoss Enterprise Application Platform (JBoss EAP), and Red Hat Container Development Kit. In this article, we introduce Red Hat Community Server Connector, the newest addition to our Visual Studio Code (VS Code) extensions.
Community Server Connector makes it easier than ever to deploy, run, debug, and test Open Service Gateway initiative (OSGi), Java EE and Jakarta EE, and other projects targeting diverse servers and runtimes. This new VS Code extension allows you to control Apache Felix, Apache Karaf, and Apache Tomcat with the same user interface (UI) and flexibility that you have in Server Connector. And don’t worry, we’ll continue to enhance Red Hat Server Connector as well.
This article offers a general introduction to Red Hat Server Connector. For a more detailed introduction, see my video demonstration, which includes use cases for Apache Felix, Apache Karaf, and Apache Tomcat.
Continue reading “Deploying projects to Apache Felix, Tomcat, and Karaf in VS Code”
The Time Zone Database (
tzdata) provides Red Hat Enterprise Linux (RHEL) with data that is specific to the local time zone. Applications in the Linux operating system use this data for various purposes. For instance, the GNU C Library (
tzdata to ensure APIs such as
strftime() work correctly, while applications such as
/usr/bin/date use it to print the local date.
tzdata package contains data files documenting both current and historic transitions for various time zones around the world. This data represents changes required by local government bodies or by time zone boundary changes, as well as changes to coordinated universal time (UTC) offsets and daylight saving time (DST).
This article is a quick update about changes to the
tzdata package in 2019, as well as possible time zone changes that we are monitoring for package updates in 2020.
Continue reading “What’s new with tzdata: The time zone database for Red Hat Enterprise Linux”
Red Hat Universal Base Images (UBIs) allow developers using Docker on Windows and Mac platforms to tap into the benefits of the large Red Hat ecosystem. This article demonstrates how to use Red Hat Universal Base Images with Docker from a non-Red Hat system, such as a Windows or Mac workstation.
Red Hat Enterprise Linux and Docker
When Red Hat Enterprise Linux (RHEL) 8 was released almost a year ago, and it came with lots of new features related to containers. The biggest ones were the new container tools (Podman, Buildah, and skopeo) and the new Red Hat Universal Base Images. There was also confusion because RHEL 8 dropped support for the Docker toolset. Some developers thought that they could not work with Docker anymore, and had to either migrate to a Red Hat-ecosystem Linux system such as CentOS or stay away from Red Hat customers.
Continue reading “Red Hat Universal Base Images for Docker users”
Several months ago, the LLVM project blog published an article, Closing the gap: cross-language LTO between Rust and C/C++. In it, they explained that link-time optimization can improve performance by optimizing throughout the whole program, such as inlining function calls between different objects. Since Rust and Clang both use LLVM for code generation, we can even achieve this benefit across different programming languages.
In Red Hat Developer Tools, we have the Rust and LLVM Toolsets, which can easily be used together for cross-language link-time optimization (LTO), so let’s try it out.
Continue reading “Cross-language link-time optimization using Red Hat Developer Tools”