Language Selection

English French German Italian Portuguese Spanish

Was I Too Tough on RHEL 5?

Filed under
Linux

In the April 2/9, 2007, issue, I gave Red Hat's Red Hat Enterprise Linux 5 and its brand-new Xen virtualization features a bit of a hard time with regard to the limitations of its management tools. Relative to the products of VMware, the current market/mind share leader in x86 server virtualization, Red Hat's Xen implementation has a decidedly do-it-yourself nature—less pointing and clicking and more configuration file editing and documentation digging.

During an e-mail exchange about the review, a reader challenged me on whether it was fair to criticize RHEL 5's graphical user interface limitations and remarked on his disgust at finding how many tasks in VMware are point-and-click-oriented. Disgust seems to me like a pretty extreme reaction to a software interface, but I think that people chafe at the idea that an inferior product with a newbie-oriented interface—the archetype of which being Windows—might trump an arguably technologically superior option that greets you instead with a blinking command-line cursor and a trove of config files.

As the reader also pointed out, GUIs typically make things easy by limiting flexibility, and having your hands tied isn't fun, even if the binding is being done by a friendly wizard. To be sure, I felt my own GUI-borne pain during my testing of VMware's Virtual Infrastructure 3, which regresses significantly from VMware's typically good cross-platform compatibility record by supporting only Windows for its VI3 management client. Along similar lines, while testing Virtual Iron 3.5, I felt the pinch of lacking direct control of the virtualization nodes that Virtual Iron governs instead through the graphical interface to its management server.

Full Story.

More in Tux Machines

GNU Privacy Guard (GnuPG), GNU Radio, and BPF Compiler Collection

  • Future directions for PGP
    Back in October, LWN reported on a talk about the state of the GNU Privacy Guard (GnuPG) project, an asymmetric public-key encryption and signing tool that had been almost abandoned by its lead developer due to lack of resources before receiving a significant infusion of funding and community attention. GnuPG 2 has brought about a number of changes and improvements but, at the same time, several efforts are underway to significantly change the way GnuPG and OpenPGP are used. This article will look at the current state of GnuPG and the OpenPGP web of trust, as compared to new implementations of the OpenPGP standard and other trust systems. GnuPG produces encrypted files, signed messages, and other types of artifacts that comply to a common standard called OpenPGP, described in RFC 4880. OpenPGP is derived from the Pretty Good Privacy (PGP) commercial software project (since acquired by Symantec) and today is almost synonymous with the GnuPG implementation, but the possibility exists for independent implementations of the standard that interoperate with each other. Unfortunately, RFC 4880 was released in 2007 and a new standard has not been published since then. In the meantime, several extensions have been added to GnuPG without broader standardization, and a 2017 IETF working group formed to update RFC 4880 ultimately shut down due to lack of interest. GnuPG 2 is a significantly heavier-weight software package than previous GnuPG versions. A major example of this change in architecture is GnuPG 2's complete reliance on the use of the separate gpg-agent daemon for private-key operations. While isolating private-key access within its own process enables improvements to security and functionality, it also adds complexity. In the wake of the Heartbleed vulnerability in OpenSSL, a great deal of scrutiny has been directed toward the maintainability of complex and long-lived open-source projects. GnuPG does not rely on OpenSSL for its cryptographic implementation, instead it uses its own independent implementation: Libgcrypt. This leads to the question of whether GnuPG's cryptographic implementation is susceptible to the same kinds of problems that OpenSSL has had; indeed the concern may be larger in the case of GnuPG.
  • Foundations of Amateur Radio - Episode 137
    I've been playing with a wonderful piece of software called GNU Radio, more on that in a moment.
  • An introduction to the BPF Compiler Collection
    In the previous article of this series, I discussed how to use eBPF to safely run code supplied by user space inside of the kernel. Yet one of eBPF's biggest challenges for newcomers is that writing programs requires compiling and linking to the eBPF library from the kernel source. Kernel developers might always have a copy of the kernel source within reach, but that's not so for engineers working on production or customer machines. Addressing this limitation is one of the reasons that the BPF Compiler Collection was created. The project consists of a toolchain for writing, compiling, and loading eBPF programs, along with example programs and battle-hardened tools for debugging and diagnosing performance issues. Since its release in April 2015, many developers have worked on BCC, and the 113 contributors have produced an impressive collection of over 100 examples and ready-to-use tracing tools. For example, scripts that use User Statically-Defined Tracing (USDT) probes (a mechanism from DTrace to place tracepoints in user-space code) are provided for tracing garbage collection events, method calls and system calls, and thread creation and destruction in high-level languages. Many popular applications, particularly databases, also have USDT probes that can be enabled with configuration switches like --enable-dtrace. These probes are inserted into user applications, as the name implies, statically at compile-time. I'll be dedicating an entire LWN article to covering USDT probes in the near future.

openSUSE Tumbleweed Users Receive Important Mesa Linux Graphics Stack Update

Four snapshots were released this week for OpenSuSE Tumbleweed, which is a rolling release GNU/Linux distribution where users install once and receive updates forever. Probably the most important change added in these snapshots was related to the graphics stack, which was updated to Mesa 17.3.2, a release that neede to be split into two parts to improve the build performance of the distribution. "In order to improve the distro build performance, Mesa was split into two parts to be built. Users that updated their system using “–no-recommends” did not get Mesa-dri auto-installed, resulting in the graphical system possibly not starting up. Simply install Mesa-dri for now manually (dependency chain fixes are underway)," said Dominique Leuenberger in the mailing list announcement. Read more

EXT4 vs. XFS vs. Btrfs vs. F2FS With Linux 4.15 Comparing KPTI/Retpoline

The latest in our benchmarking with KPTI and Retpoline for Meltdown and Spectre mitigation is comparing the performance of the EXT4, XFS, Btrfs and F2FS file-systems with and without these features enabled while using the Linux 4.15 development kernel. Read more

Raspberry Pi HAT connects up to three Pmod modules at once

Digilent and RS Components have launched a $15, Python supported “Pmod HAT Adapter” for the Raspberry Pi that can connect up to three Digilent Pmod peripheral modules at a time while also extending the 40-pin adapter. Digilent has joined with distributor RS Components to co-launch a $15 DesignSpark Raspberry Pi Pmod HAT Adapter board that brings Digilent’s Pmod peripheral boards to the Raspberry Pi. The 65 x 56.5mm HAT compliant board offers three 2×6-pin Pmod ports with support for I2C, SPI, UART and GPIO interfaces. The Raspberry Pi’s 40-pin adapter is extended to make full use of the SBC’s interfaces. Read more