Topic navigation

Blog Articles

Infrastructure

Red Hat has actively participated in the ISO group defining the C++ standard for many years, and continues to make a significant contribution. The Red Hat toolchain team was well-represented at the spring meeting of the standardization committee (technically JTC1/SC22/WG21) in Bristol, UK, last month: we had three people there for the full week, with one other visiting a couple of times during the week. In this article, Jason Merrill summarizes the main highlights and developments of interest to Red Hat’s customers and partners:

RPM Package Manager (RPM) was created to deliver software to workstations and servers. Besides being an efficient software delivery mechanism, RPM also provides security features that assist system administrators with managing their software and trusting the code that is going into their infrastructure.

What is an RPM?

RPM is a package management system that bundles software source code or binaries together for easy installation on a computer. These files are tracked and allow for easy installation, upgrading, and removal. Since the RPMs have been built specifically for the operating system and platform they are installed on, the software is expected to operate in a predictable and consistent manner.

RPMs not only make it easy for the user to install software on their computer but also for the developer to deliver the software. RPMs makes it easy to pull in dependencies, other bits of code needed by the software to function properly, and to provide updates to the software in question. The ability to apply patches for security fixes makes RPMs an especially good tool for maintaining secure computer environments as code fixes can easily be verified by system administrators prior to installation.

WebSockets are a rising technology that solves one of the great needs of web development – full duplex communication between a browser (or a different client) and a server.

Let’s imagine a simple scenario – live web chat. In the past, you’d probably use AJAX and polling to make new posts appear in realtime. The downside is that implementing all that is not entirely easy and it tends to put a lot of strain on the server.

This article will show you how to implement a simple web chat using WebSockets, thus eliminating the above problems. We will be using the Tornado web server with the Flask framework, producing a pure Python solution. To get the maximum out of Python 2.x, we will utilize the python27 Software Collection (SCL). We will also need a newer version of Firefox that supports WebSocket technology, so that we can test from the RHEL 6 machine that we’re developing on.

As I stare at this blank screen to start writing my first blog entry I have that same feeling that so many developers have when starting with an unfamiliar programming language or application. The developers in our group realize that it is not easy starting from nothing and we strive to make it easier to productively use SystemTap to investigate performance problems.

Unfortunately, not every application is packaged for every distribution. What do you do when you can’t find it packaged for Red Hat Enterprise Linux? If you are like most people, you give up or attempt to install it from source. What happens when installing from source goes badly? If you are like most people, you definitely give up. How do you keep up with application improvements or, perhaps more importantly, security fixes? If you are like most people, you periodically try and check on the application status (especially when your version stops working 🙂 ), and then try and rebuild it. What is the solution to all of these issues? Proper packaging. Well, this post is meant to help you get started.

Recently, I needed to get Django installed with Python 2.7 on Red Hat Enterprise Linux 6. As this is not a directly supported activity, I wanted to document how I went about it. As you might imagine, the generally expected method for install would be to grab the Python 2.7 source tree and then build it. Obviously, that can be a lot of work; is not particularly repeatable; and, potentially, exposes you to more security flaws. As a result, I decided to try to leverage a “new’ish” technology developed (in the open) by Red Hat called Software Collections. An in depth discussion of Software Collections is for another post, for now we just need to know that Software Collections are rpms that contain all (or most) of their supporting libraries, install under /opt, are updatable through yum, and, the core software collections code (scl-utils) is supported by Red Hat. A number of collections have been created and released by the community at http://bit.ly/fedora-scl.

OK, getting started. I created a new VM using a RHEL 6.3 image on an instance of RHOS (Red Hat Open Stack),

This technical article covers a subtlety in C++ array allocation and how we changed the GNU C++ compiler to deal with it properly. When a programmer writes

T *p = new T[3];

the C++ compiler allocates room for at least three copies of objects of type T on the heap. These objects require 3 * sizeof(T) bytes. For this example, assume sizeof(T) is 12, then it is straightforward to allocate 36 bytes (for example, using malloc). But what happens if the array length is 3937053355 (or 16909515400900422315 on a 64-bit architecture)? Then 47244640260 bytes are required. This number cannot be expressed in 32-bits, so if 32-bit arithmetic is used to perform the multiplication, the result is a mere 4. Unless special care is taken, a C++ implementation will provide a pointer to a heap area that is much too small for holding the requested number of objects (4 bytes instead of 47244640260 bytes).

While Red Hat Enterprise Linux is known for its stability and flexibility, you might not think of it first when looking for the latest version of your web application framework. If you’re a developer working with Ruby and Ruby on Rails, you probably want to take advantage of their new features. Sure, you can use RVM, but sometimes you just want to get supported system packages.

Software Collections (often abbreviated as SCL) allows you to run more recent versions of software than what ships with your current version of Red Hat Enterprise Linux. This article will show you how to start development of a Rails 3.2 application running on Ruby 1.9.3 – all on RHEL 6, using only RPM packages, alongside your default Ruby installation. This tutorial assumes that you are familiar with Ruby on Rails basics, such as creating a new application and using bundler. It is also beneficial (although not necessary) to understand how Software Collections work in general.

Did you ever wish you had newer versions of the software on your Red Hat Enterprise Linux machines? You are probably not alone. Providing new versions of software in rpm is hard, because rpm supports only one version installed on your computer at a time. Multiple versions on one machine can conflict with each other or create unpredictable behaviour in applications that you might not have considered dependencies.

Last year, we developed Software Collections to allow you to install newer versions of software in rpm safely into /opt and switch between new and old releases. This allows your Red Hat Enterprise Linux system applications to continue to run with the old version, while new apps can work with the new version. A good example of this is Python; many essential packages are written in Python. How can you update to the latest release of Python without causing half your system to break? Through Software Collections, you can install a newer version of Python – for example python-3.3 – into /opt avoiding conflicts in files and strange behaviour of apps that depend on an older version of Python.