Linux

For this article, I'm moving back into the realm of chemistry software—specifically, the General Atomistic Modelling Graphic Interface, or GAMGI. GAMGI provides a very complete set of tools that allows you to design and visualize fairly complex molecules.

GAMGI has the special ability to make creating repeating structures much easier, which is handy when you're trying to create crystalline structures.

GAMGI should be available in the package repositories of most Linux distributions. For example, on Debian-based distros, you can install GAMGI with the following command:

sudo apt-get install gamgi

There are also data and documentation packages (gamgi-data and gamgi-doc), and when you first start to use GAMGI, it's a good idea to install those packages as well.

Once the packages are installed, you can start GAMGI from the command line or from your desktop environment's menu system. When it starts up, you get a blank canvas to begin your work.

Figure 1. When you start GAMGI, you get a minimal set of tools to help begin your project.

This interface is probably one of the more minimal ones of the chemistry packages that you are likely to use, but it hides all of the functionality that is present within GAMGI. It is object-oriented, in that all of the main elements are treated as independent objects, with properties and relationships to other objects. These elements include atoms, bonds, molecules and crystal planes. Each of them are built up of a number of the earlier ones. One extra piece that GAMGI has is the ability to work with orbitals. Let's walk through an example of a salt crystal (NaCl) to show how you can use GAMGI to do graphical analysis.

When looking at a crystalline structure, you'll want to start by creating a cell in the window. You do this by clicking the Cell→Create menu item. Then you'll get a pop-up window where you can set several properties of the new cell.

Figure 2. When you create a new cell for crystal structures, you can set several different properties on how it will be constructed.

Since salt is a cubic crystal, you'll want to set the system value to c (for cubic), and set the lattice value to F (for face-centered). For each of these, you can get a full set of allowed values by clicking the associated "List" button. Clicking Ok creates the cell.

Dietmar Eggemann posted a patch from Quentin Perret to take advantage of energy-efficient CPUs on asymmetric multiprocessor (AMP) systems. AMP is distinguished from SMP (symmetric multiprocessor) systems in that an SMP system uses several instances of only one type of CPU, while an AMP system might use CPUs of differing speeds, feature-sets and so on.

Quentin's patch was an effort to take advantage of differences in power consumption between the CPUs on an AMP system. It attempted to identify the most efficient CPU that was not already saturated with processes and assign newly awakened processes to it. If no CPUs fit the bill, standard SMP-type methods of processor assignment would be used instead.

Dietmar explained, "The selection of the most energy-efficient CPU for a task is achieved by estimating the impact on system-level active energy resulting from the placement of the task on each candidate CPU. The best CPU energy-wise is then selected if it saves a large enough amount of energy with respect to prev_cpu."

He acknowledged that this algorithm was a brute-force approach that could work well only on systems with a relatively small number of CPUs. He said, "This patch is an attempt to do something useful, as writing a fast heuristic that performs reasonably well on a broad spectrum of architectures isn't an easy task."

Patrick Bellasi and Joel Fernandes had no serious objections to the patch and offered some technical suggestions. The discussion delved into various technical issues and specific ways of addressing them, with no one raising any controversial issues.

This is the type of situation with a patch where it might look like a lack of opposition could let it sail into the kernel tree, but really, it just hasn't been thoroughly examined by Linux bigwigs yet. Once the various contributors have gotten the patch as good as they can get it without deeper feedback, they'll probably send it up the ladder for inclusion in the main source tree. At that point, the security folks will jump all over it, looking for ways that a malicious user might force processes all onto only one particular CPU (essentially mounting a denial-of-service attack) or some such thing. Even if the patch survives that scrutiny, one of the other big-time kernel people, or even Linus Torvalds, could reject the patch on the grounds that it should represent a solution for large-scale systems as well as small.

Learn why at rest encryption doesn't mean encryption when your laptop is asleep.

There are many steps you can take to harden a computer, and a common recommendation you'll see in hardening guides is to enable disk encryption. Disk encryption also often is referred to as "at rest encryption", especially in security compliance guides, and many compliance regimes, such as PCI, mandate the use of at rest encryption. This term refers to the fact that data is encrypted "at rest" or when the disk is unmounted and not in use. At rest encryption can be an important part of system-hardening, yet many administrators who enable it, whether on workstations or servers, may end up with a false sense of security if they don't understand not only what disk encryption protects you from, but also, and more important, what it doesn't.

What Disk Encryption Does

In the context of Linux servers and workstations, disk encryption generally means you are using a system such as LUKS to encrypt either the entire root partition or only a particularly sensitive mountpoint. For instance, some Linux distributions offer the option of leaving the root partition unencrypted, and they encrypt each user's /home directories independently, to be unlocked when the user logs in. In the case of servers, you might leave root unencrypted and add encryption only to specific disks that contain sensitive data (like database files).

In a workstation, you notice when a system is encrypted at rest because it will prompt you for a passphrase to unlock the disk at boot time. Servers typically are a bit trickier, because usually administrators prefer that a server come back up after a reboot without manual intervention. Although some servers may provide a console-based prompt to unlock the disk at boot time, administrators are more likely to have configured LUKS so that the key resides on a separate unencrypted partition. Or, the server may retrieve the key from the network using their configuration management or a centralized secrets management tool like Vault, so there is less of a risk of the key being stolen by an attacker with access to the filesystem.

The main thing that at rest encryption protects you from is data loss due to theft or improper decommissioning of hard drives. If someone steals your laptop while it's powered off, your data will be protected. If someone goes into a data center and physically removes drives from a server with at rest encryption in place, the drives will spin down, and the data on them will be encrypted. The same goes for disks in a server that has been retired. Administrators are supposed to perform secure wiping or full disk destruction procedures to remove sensitive data from drives before disposal, but if the administrator was lazy, disk encryption can help ensure that the data is still protected if it gets into the wrong hands.

Open source software has been around for a long time. But calling it open source only began in 1998. Here's some history:

Christine Peterson came up with the term "open source software" in 1997 and (as she reports at that link) a collection of like-minded geeks decided on February 3, 1998 to get behind it in a big way. Eric S. Raymond became the lead evangelist when he published Goodbye, "free software"; hello, "open source" on February 8th. Bruce Perens led creating the Open Source Initiative later that month. Here at Linux Journal, we were all over it from the start as well. (Here's one example.)

"Open source" took off so rapidly that O'Reilly started OSCON the next year, making this year's OSCON, happening now, the 19th one. (FWIW, at the 2005 OSCON, O'Reilly and Google together gave me an award for "Best Communicator" on the topic. I was at least among the most enthusiastic.)

Google's Ngram Viewer, which searches through all scanned books from 1800 to 2008, shows (see above) that use of "open source" hockey-sticked quickly. Today on Google, "open source" gets 116 million results.

But interest has been trailing off, as we see from Google Trends, which follows "interest over time." Here's how that looks since 2004:

Google's Project Fi is a great cell-phone service, but the data-only SIMs make it incredible for network projects!

I have a lot of cell phones. I have iPhones (old and new), Android phones (old, new, very old and funny-shaped), and I have a few legacy phones that aren't either Android or iPhone. Remember Maemo? Yeah, and I still have one of those old Nokia phones somewhere too. Admittedly, part of the reason I have such a collection is that I tend to hoard nostalgic technology, but part of it is practical too.

I've used phones as IP cameras for BirdTopia (my recorded and streamed bird-feeder collection). I've created WiFi-only audiobook devices that I use when I'm out and about. I've used old phones as SONOS remotes, Plex players, Chromecast initiators and countless other tasks that tiny little computers are perfect for doing. One of the frustrating things about using old cell phones for projects like that though is they only have WiFi access, because adding multiple devices to a cell plan becomes expensive quickly. That's not the case anymore, however, thanks to Google's Project Fi.

Most people love Project Fi because of the tower-hopping features or because of the fair pricing. I like those features too, but the real bonus for me is the "data only" SIM option. Like most people, I rarely make phone calls anymore, and there are so many chat apps, texting isn't very important either. With most cell-phone plans, there's an "access" fee per line. With Project Fi, additional devices don't cost anything more! (But, more about that later.) The Project Fi experience is worth investigating.

What's the Deal?

Project Fi is a play on the term "WiFi" and is pronounced "Project Fye", as opposed to "Project Fee", which is what I called it at first. Several features set Project Fi apart from other cell-phone plans.

First, Project Fi uses towers from three carriers: T-Mobile, US Cellular and Sprint. When using supported hardware, Project Fi constantly monitors signal strength and seamlessly transitions between the various towers. Depending on where you live, this can mean constant access to the fastest network or a better chance of having any coverage at all. (I'm in the latter group, as I live in a rural area.)

The second standout feature of Project Fi is the pricing model. Every phone pays a $20/month fee for unlimited calls and texts. On top of that, all phones and devices share a data pool that costs $10/GB. The data cost isn't remarkably low, but Google handles it very well. I recently discovered that it's not billed in full $10 increments (Figure 1). If you use 10.01GB of data, you pay $10.01, not $20.