UpFront

Linus Torvalds reported on some GCC compiler warnings that he felt were unnecessary, and he gave his opinion on how they should work instead. Specifically, GCC 5.1 would issue a warning against using a switch statement with a boolean variable, presumably because a boolean would be better handled by a simple if statement.

Linus posted the following counter-example:

switch (a) {
case 1:
    A;
    if (b)
         break;
    B;
    /* fallthrough */
case 2:
    C;
}

And he said:

Linus said that a more appropriate warning from GCC would be when the data type of the switch variable was different from the data type of the case variable. In that case, he said, a warning would make perfect sense. But warning against using a boolean variable in a switch at all, he felt, was going overboard. He said that:

switch (boolean) {
case true:

made far more sense than following the recommendation in the GCC documentation of casting to an integer:

switch ((int)boolean) {
switch 1:

He said anyone who preferred the latter over the former “clearly has absolutely zero taste and is just objectively wrong”.

Tadeusz Struk has proposed some patches to implement a new public key encryption API. The idea is to have software routines in place when no encryption hardware is available, but to offload the work to hardware when possible. In general though, any module could provide its own RSA and DSA implementation.

It's not entirely a new concept—the kernel already supported public key encryption for verifying digitally signed driver modules. But, Tadeusz's code is intended to replace the old crypto code. Along with his patches implementing the feature, Tadeusz submitted patches migrating older usages to the new service.

There were some technical suggestions and some minor objections, but ultimately, it does seem as though the old crypto code will be replaced by Tadeusz's new stuff. The biggest problem seemed to be how to make it easy for user code to handle drivers that implemented only a partial subset of the RSA and DSA API. Initially, Tadeusz planned to allow drivers simply to encode a list of the features they provided, but Herbert Xu convinced him to require drivers to implement at least a complete minimal subset of features, so users could rely on them without doing lots of tests.

Filesystem capabilities still have not come into their own. Originally intended as a way to loosen targeted security constraints on user processes without going all the way to the extreme of running as root, the poor initial design of capabilities has sometimes led to more security problems than it solved.

One problem has been capability inheritance—the ability of one process to pass along its same set of capabilities to processes it invokes. This is the equivalent of user processes running sub-processes as that user, or root processes running sub-processes as root—something UNIX always has supported. But capabilities haven't implemented that feature properly, and the available workarounds have tended to make it easier for hostile users to gain root privileges on a system.

Recently Andy Lutomirski, working off ideas by Christoph Lameter and Serge Hallyn, produced some patches that re-envisioned capability inheritance in a way that, without breaking current usage, they claimed would provide a saner and more secure form of inheritance.

Capabilities work by identifying secure abilities that are available to a given process. A process has a certain set of capabilities, which can then be masked off, leaving only the ones that actually will be needed by that process. One of these masks is the “inheritable” mask, called pI. The pI mask is supposed to control which capabilities are inheritable by sub-processes. The problem is that it doesn't do that properly, although changing its behavior could break existing user code.

Andy's code got around this dilemma by introducing a new pA mask, which he said would do what pI should have done originally. The pA mask, Andy said, would introduce new logic and some nuanced behaviors to allow a predictable form of inheritance that would avoid the security exploits that had been plaguing users.

Several folks pointed out, and Andy acknowledged, that this wasn't a perfect solution and left certain problems unsolved. But the bottom line, he said, was that his code represented a real improvement and better overall direction in a situation where no one else was able to offer any alternatives beyond the status quo.

If you're excited to try the ZNC IRC bouncer I highlighted in another UpFront article this month, you really should test its flexibility using an Android IRC client. I've never actually used IRC on Android, because connecting temporarily isn't really how IRC works best. And, the thought of staying logged in via my phone's data plan sounds unpleasant.

I tried a few IRC clients for Android, and although most are functional and intuitive, Rice IRC stood out above the rest. It's completely free, has no ads, and it has an interface that makes perfect sense. It also has all the features you'd expect in a mobile chat client, including notifications, background tasks and so on.

An IRC client is one of those apps where simplicity is better. IRC is simple, and so should be the interface you use to connect with it. Rice IRC ticks all the boxes. Get your copy today from the Google Play store: https://play.google.com/store/apps/details?id=it.mneri.android.rice.

One of the things that makes Python so powerful is that you can find a module for almost anything. In this article, I cover Astropy, which was originally developed by the Space Telescope Science Institute for doing astronomy calculations like image processing and observatory calculations. Because this is a Python program, you can install it with either pip or easy_install. Your Linux distribution already should have a package included. For example, in Debian-based distributions, you can install it with this:

sudo apt-get install python-astropy

There is also a separate package, python-astropy-doc, that contains extra documentation for Astropy. Because Astropy is a fairly large system, it is broken into smaller sub-packages. This should be familiar to anyone who has worked with packages like SciPy or NumPy before. So, simply using the following actually isn't very useful:

import astropy

You more likely will need to import individual sub-packages with commands like this:

from astropy.io import fits

There are sub-packages to handle file IO, cosmological calculations and coordinate systems, among many other topics. Let me provide a basic introduction to some of the available functionality so you have an idea of what you can do.

First, let's look at how to deal with data files. The common file format used in astrophysics and astronomy is the FITS file format. The PyFITS Python package was written to read and write FITS files. This code is actually the same as the code in the sub-package astropy.io.fits, so you can use it in the same way. You actually can even just drop Astropy in as a plugin with the following:

from astropy.io import fits as pyfits

This way, you can use existing file management code without having to make any changes.

The first thing you need to do is open your data file with:

from astropy.io import fits
hdulist = fits.open("My_File.fit")

This returns an object that behaves like a list. Each element of the returned object maps to a Header-Data Unit (HDU) in the file. You can get more information on the file with this command:

hdulist.info()

Each of the individual elements has a header and data portion. You can access them to see details about the data you are about to process.

Along with all of the library functions, Astropy includes a series of command-line utilities to work with FITS files. You can check the headers of a FITS file with the fitsheader utility. You can check your FITS file with fitscheck, and you even can find the differences between two files with fitsdiff.

A common computational process in astronomy is image processing. The convolution sub-package provides two categories of convolution operations: direct and FFT. You can do one-, two- and three-dimensional convolutions. The visualization sub-package handles more basic image processing like normalization and stretching. You can combine multiple transformations very easily. The + operator is overloaded to apply transformations that are “added” together in series. So, a command like this:

transform = SqrtStretch() + PercentileInterval(90.)

gives you a new function, transform, that combines the two separate transformations in a single step. This sub-package also includes a script, fits2bitmap, that can do conversions between different file formats.

A second common computational task in astronomy is doing statistics based on observations, and Astropy provides a sub-package called stats. Although the scipy.stats sub-package provides a lot of functionality, some astronomy-focused functions are missing, so the astropy.stats sub-package fills in those missing functions.

Once you have your data loaded, you can use the modeling sub-package. You can do 1D and 2D modeling with astropy.modeling. This includes curve-fitting functionality, where you can do linear and nonlinear function fitting. There are built-in functions to fit Gaussian curves and polynomials. This fitting is handled with a least-squares method. With version 1.0, you can build compound models by combining existing models with arithmetic operators.

When you are ready to start doing calculations, you will need to use constants. Instead of remembering them or using them with potential typos, Astropy includes a complete list of all the standard scientific constants that you will need when doing numerical work. You can import the entire list with this:

from astropy import constants

If you need only a few of the constants, like maybe the speed of light, you can import them individually with this:

from astropy.constants import c

The really cool thing about these constants is that they are actually “Quantity” objects. This means you can do something like change the units being used with a command like the following:

c.to('km/s')

Because it is so prevalent, you can use CGS units with c.cgs.

There are also two sub-packages to handle coordinate systems. Astronomical coordinate systems are handled by the coordinates sub-package, and world coordinate systems are handled by the wcs sub-package. In the coordinates sub-package, the core object is the SkyCoord object. There are methods of this object to handle conversions between coordinate systems or distances from one point to the origin within a given coordinate system. The wcs sub-package allows for mapping data within a FITS file onto a “real-world” coordinate system in order to analyze them correctly. This includes functionality to deal with complications, like projections onto the sphere of the sky.

You even can do cosmological calculations with Astropy. The cosmology sub-package actually includes functionality to model the evolution of the entire cosmos based on a set of initial conditions that you set. Although you can set your own cosmology, several built-in cosmologies are available. These are based on the WMAP and Planck satellite data.

Most functionality is built off a core FLRW object. This object represents a homogeneous, isotropic cosmology defined by the Friedmann-Lemaitre-Robertson-Walker metric from General Relativity. However, this class can't be used directly. You need to subclass it first. There are several included in the cosmology sub-package, such as the FlatLambdaCDM object that includes dark energy. You can look at various values, like the Hubble constant, at various points during the evolution of the cosmology. You also can include contributions to the energy density from matter, dark energy and even photons and neutrinos.

Now that you've seen a bit of what you can do with astropy, if astronomical calculations are on your radar, there is much more available. Additionally, there is the concept of affiliated packages. These are packages that basically are built on top of the core functionality provided by Astropy. Although they aren't part of Astropy, they are being built up into a community-driven environment for doing astrophysics. It definitely will be worth your while to take a look at the extended world of available packages.

Most of the work I do on computers is done via the command line. When I'm off on vacation somewhere, that means shoddy Wi-Fi and cell-phone tethering. Because cell-phone tethering gets expensive quick (I also have three teenage daughters with which I share a data plan), I try to use free Internet whenever I can. The biggest hassle with that method is dealing with broken SSH sessions. Yes, I can use programs like screen or tmux to make sure I don't lose work, but it can be very frustrating to have an SSH session lock up because the “TotallySafeBro” SSID in my hotel goes down. And, don't get me started on lag.

That's where Mosh comes into play. I was lamenting in IRC, and user “bkidwell” mentioned Mosh as being a great terminal client for questionable or often-changing connections. It uses a combination of TCP over port 22 and UDP on a higher port to provide a smooth, flexible terminal session regardless of your connection reliability or performance. Rather than waiting for the remote server to echo what you type, Mosh displays your local typing and edits in real time, then “catches up” with the server as quickly as it can. The coolest part, however, is that Mosh will keep your connection alive and running even if you change network addresses! Switching from McDonald's Wi-Fi to your phone's shared data? No need to log out and back in.

Figure 1. Mosh detects a disconnect and keeps trying to reconnect, even if your IP address changes!

Admittedly, Mosh is lacking in some ways compared to SSH. It doesn't do port forwarding, it doesn't keep a scrollback buffer, and its predictive text is sometimes wrong. That last one is most noticeable on a really poor connection, and it isn't really a problem—the screen just occasionally changes a bit when the server/client syncs up. It's still far nicer than typing eight lines of instructions, only to see a typo when the screen finally updates.

Due to its flexibility with poor connections, cross-platform server/client availability and convenience for mobile admins, Mosh gets this month's Editors' Choice award. Download the application from your Linux repository, or head over to https://mosh.mit.edu for download links and instructions for whatever platform you might be on, including Android. Installation is simple, and the benefits are immediate!

I often get teased for taking so much tech hardware with me on trips—right up until the Wi-Fi at the hotel, conference center or rented house fails. I'm currently on vacation with my family and some of our friends from Florida, and our rental home has a faulty Wi-Fi router. Thankfully, I have a bag full of goodies for just this occasion. I don't really have a set “list” of items I carry, but generally I'll have the following:

The USB-powered options are really due to a single incident where I had to put a Wi-Fi repeater in the middle of a field in order to reach a remote building. I tied the repeater and battery in a double-wrapped grocery bag and charged the battery every couple days. It felt like the wild wild west of networking.

As for our current vacation, my router is working well, and the third floor of the house has Internet access thanks to the repeater I installed on the second floor. At least for the duration of this trip, I don't expect to be teased for bringing so many nerdy accoutrements.

If people only knew how hard I work to gain my mastery, it wouldn't seem so wonderful at all.

—Michelangelo Buonarroti

Real freedom lies in wildness, not in civilization.

—Charles Lindbergh

Things are only impossible until they're not.

—Jean-Luc Picard, Star Trek the Next Generation

The thing about chameleoning your way through life is that it gets to where nothing is real.

—John Green

The only way most people recognize their limits is by trespassing on them.

—Tom Morris

In my discussion on IRC with “bkidwell” (see the Non-Linux FOSS article for more on our talk), we were discussing how we connect to IRC. My main method is to SSH in to my co-located Raspberry Pi in Austria and connect to a screen session I have running that is constantly connected to IRC with Irssi. This works really well for me, and I never miss messages when I'm away. The big problem I have is occasionally I'm away from a laptop, and so I can't efficiently use the terminal to chat. It might be technically possible to IRC chat via an SSH app on my phone, but it would mean super-tiny text and awkward keyboard shortcuts.

That's where ZNC comes into play. I've never used an IRC bouncer before, but the concept is that it stays connected to IRC using your credentials, and it allows you to connect to it with your IRC app and pick up where you left off. Functionally, it's like a screen session, but instead of connecting via SSH, you connect with an IRC client. Since it keeps you logged in, when you connect, you have access to the chats and personal queries that have occurred while you were disconnected. Plus, it allows you to connect from multiple locations at once and use whatever IRC client you want—there's no “client” application you have to use!

(Image from znc.in)

ZNC is really an awesome way to use IRC. It allows me to keep using Irssi too, because I just point Irssi at the ZNC bouncer, and never miss a beat even when I'm remote on my phone. If you use IRC regularly or are hesitant because of the issues I've highlighted here, I urge you to check out ZNC. It's at znc.in and is available for most platforms.