UpFront

diff -u: What's New in Kernel Development

Zack Brown

Issue #236, December 2013

There have been a number of attempts to make Linux able to isolate CPUs and other hardware resources, effectively guaranteeing access to those resources to the particular processes that need them.

Christopher Lameter recently posted his own attempt. His code operated very early in the boot cycle, so it could prevent any startup dæmons from getting onto the CPUs in question.

There immediately was a discussion of whether to redo these patches as enhancements to things like isolcpus and cpusets, which provided similar features. Everyone seemed to be in favor of the feature set, but no one seemed satisfied with the existing solutions or with Christopher's version.

According to Mike Galbraith, isolcpus, for example, apparently is being taken out of the kernel at some point, although like Christopher's code, it operates at a very early stage of the boot cycle. But, as Gilad Ben-Yossef said, cpusets, on the other hand, started later in the boot cycle and wasn't able to handle certain types of process migration, but it was more elegantly written, which counts for a lot, in Linux.

One possibility was to keep isolcpus around and enhance it with Christopher's code, but take out most of the rest of its code, leaving it just a configuration tool for cpusets. But Christopher nixed that idea, saying that isolcpus was actually broken and insane, and simply had to go.

As it turned out, even cpusets was not immune and was slated to be replaced by cgroups, a Google project to provide similar features not just for CPUs, but for memory and all other resources on the system.

The real difficulty with any of these solutions seems to be correctly handling all the various cases that may arise. Migrating threads may leave child threads behind that also need to be migrated. There are potential race conditions. And some groups of users, like banks and financial institutions, want these features to co-exist with nearly bare-metal control over the system as possible. How can all this be arranged?

It remains unclear. But ideas keep bubbling up, code keeps getting written, and at some point, something is bound to strike a chord with everybody.

In case you're wondering, Linus Torvalds doesn't use backups. He had a hard disk crash recently and talked about it, so we got to see a bit of how he deals with such things.

Apparently, the crash did cost him a few days of work. But he remarked, “I long ago gave up on doing backups. I have actively moved to a model where I use replaceable machines instead. I've got the stuff I care about generally on a couple of different machines, and then keys etc backed up on a separate encrypted USB key.”

And, H. Peter Anvin said he did a similar thing, because disk drives just weren't reliable enough. He said he always mirrored his main system disk onto other computers.

It's unusual for a whole hardware architecture to be taken out of the kernel tree, but it can happen. Guenter Roeck recently pointed out that the H8/300 architecture hadn't worked for years and wouldn't even compile.

Guenter posted a patch to gut the code, but he also invited discussion to make sure no one was working on resuscitating it. Through a fluke, he left the H8/300 maintainer, Yoshinori Sato, off the cc list, but Joe Perches caught that and added him back in.

Barring any objections, Greg Kroah-Hartman said he fully supported the patch and pointed out that they always could undo the git commit if it turned out someone wanted it back. David S. Miller also saw no need to keep dead code alive, as did Wim Van Sebroeck.

Linus Torvalds said he was fine with taking out the code. It was a big patch, but because it was a whole architecture, it was relatively isolated from the rest of the kernel and posed little threat to anything else.

It's possible there may be a delay, as Geert Uytterhoeven wanted to give Yoshinori a chance to discuss the issue in person at the Kernel Summit.

Miklos Szeredi has introduced a new system call to swap the names of two files. His rename2() system call made certain kinds of filesystem operations atomic, where they hadn't been before. He gave the example of replacing a directory tree with a symlink.

Another value of the patch, Miklos said, was its ability to handle whiteouts in union filesystems. In a union filesystem, where multiple filesystems are overlayed, a whiteout allows the user to delete a file in the visible union, even if the file itself happens to be on a read-only filesystem. The file is “whited out” of the overlay, so the user no longer sees it.

His rename2() system call would make that type of situation much cleaner, although Miklos acknowledged that there were some cases that still would have problems.

There was some talk of extending rename2() to allow a more complex, yet more flexible behavior, but Linus Torvalds said that Miklos's patch was actually a simplified version of an earlier effort that had been too complicated for Linus' liking. Linus said, “I was actually very relieved to see this much simpler and cleaner model, because the alternative really was nasty.”

Android Candy: Free, Family, Fun—Fantastic

Shawn Powers

Issue #236, December 2013

I've mentioned geocaching before, but if you've never taken the time to go out and do it, you're really missing out. Whether you're dragging your family through two feet of snow in the middle of the woods (yeah, I did that last year, I'm still not sure they've forgiven me) or following your GPS around a parking lot looking for a tiny micro-cache, geocaching is fun. You need only a few things to go geocaching:

  1. A sense of adventure.

  2. Friends or family (not required, but more fun).

  3. A sharp mind (there often are brain puzzles involved).

  4. A GPS or smartphone app to guide you.

That's where c:geo comes in. There are several geocaching apps for Android, and they vary in price from free to very not free. The c:geo app is one of the free ones, and it also happens to be one of the best. It will show you clues, help you find local geocaches and guide you on a map to the GPS location you need. Whether you're a hard-core geocacher or just want to go out for a little fun with the family, c:geo is a great tool for your Android device that will make geocaching easier and more enjoyable. You can find it in the Google Play Store.

Because it's such an incredible application, and because it relates to our three favorite F words (Free, Family, Fun), c:geo gets our Editors' Choice award this month. Download it now, and get out there and find stuff: www.cgeo.org.

Non-Linux FOSS: Let's Make Music Together

Shawn Powers

Issue #236, December 2013

Just because you're not on Linux doesn't mean you can't have awesome open-source tools. I was having a conversation with a friend and reader (Don Crowder: @eldergeek) on Twitter the other day about music theory. Yes, I'm not just a computer nerd, but a music/math nerd too. Anyway after our conversation, I started looking for an open-source program for creating sheet music. Not only was I able to find one, but it happens to work for those folks on Windows as well as Linux.

Mind you, I'm a neophyte when it comes to music theory, but thankfully, MuseScore is useful for experts and n00bs alike. Not only can you create sheet music, but you also can download thousands of pieces others have created and shared on the Web site.

If you're a Windows user who wants to dabble in sheet music, but can't afford something like “Finale”, MuseScore is right up your alley. If you're a musician who wants to give back, please join the community of users and contribute some of your music. To see how MuseScore is helping blind musicians, check out Katherine Druckman's article on our Web site: www.linuxjournal.com/content/music-all-open-source-software.

If you want to download MuseScore for yourself, you can download it from your repositories if you're on Linux, or download the installer from the Web site for Windows or OS X: www.musescore.com.

GIMP Shmimp, Give Me a Browser

Shawn Powers

Issue #236, December 2013

Don't get me wrong, I love The GIMP. We all love The GIMP, as our Readers' Choice awards show this month. If I'm being completely honest, however, I rarely have the need for such a powerful application. Usually, regardless of what computer system I'm on, I pick Pixlr as my image editing program.

Pixlr is a Web-based image editing tool that rivals native applications in speed, and more important, in functionality. Powerful tools like “spot heal” that aren't found in most simple image editors are essential for folks like me who still get teenager-like pimples in their late 30s. It also integrates with on-line storage (Flickr, Picasa, Facebook) and allows simple uploads/downloads to your local computer. In fact, you have to look really hard in order to realize Pixlr isn't a native application.

Regardless of what operating system you're on, you can check out Pixlr right now by heading to pixlr.com/editor. It's not GIMP, but it certainly isn't gimpy either.

A Plexible Pi

Shawn Powers

Issue #236, December 2013

If, like me, you've jumped onto the Plex bandwagon with both feet, you've probably discovered how difficult it is to make a standalone Plex player. Sure, you can install an entire OS, then auto-start the Plex program in full screen, but it's not as simple as installing the XBMC distro, or even OpenELEC. If you own a Raspberry Pi, that has all changed.

RasPlex is a custom Linux distribution based on the popular (and awesome) OpenELEC Raspberry Pi port. Rather than installing XBMC on an RPi, however, RasPlex installs the Plex Home Theater application. Granted, the Raspberry Pi does struggle with menu speed in Plex until the cache of thumbnails is built, but with a developer focusing strictly on making Plex work for the RPi, those caching issues will be solved soon!

If you have Plex on your phone, tablet, computer, browser and Roku, but really wish you could make a standalone Plex Home Theater with your Raspberry Pi, check out RasPlex today: www.rasplex.com.

They Said It

The love of learning, the sequestered nooks, / And all the sweet serenity of books....

—Henry Wadsworth Longfellow

All that counts in life is intention.

—Andrea Bocelli

He that climbs the tall tree has won right to the fruit.

—Sir Walter Scott

Wear the old coat and buy the new book.

—Austin Phelps

We can't take any credit for our talents. It's how we use them that counts.

—Madeleine L'Engle

Tinker with Molecular Dynamics for Fun and Profit

Joey Bernard

Issue #236, December 2013

Molecular dynamics computations make up a very large proportion of the computer cycles being used in science today. For those of you who remember chemistry and or thermodynamics, you should recall that all of the calculations you made were based on treating the material in question as a homogeneous mass where each part of the mass simply has the average value of the relevant properties. Under average conditions, this tends be adequate most times. But, more and more scientists were running into conditions that would be on the fringes of where they could apply those types of generalizations.

Enter molecular dynamics, or MD. With MD, you have to move down almost to the lowest level of matter that we know of, the level of atoms and molecules. At this level, most of the forces you are dealing with are electrical in nature. Atoms and molecules interact with each other through their electron clouds. Several packages are available for doing this type of work, such as GROMACS and GAMESS. In this article though, I take look at TINKER.

Unlike most of the software I've covered in this space, TINKER isn't available in the package systems of most distributions. This means you will have to go out and download it from the main Web site. There are binary files for Linux (32-bit and 64-bit), Mac OS X and Windows (32-bit and 64-bit). Although these should work in many cases, you probably will want to download the source code and build it with the exact options you want. You can download either a tarball or a zip file containing the source code for TINKER.

Once it is unpacked, change directory to the tinker subdirectory. There are a number of subdirectories named after the various operating system options available. Because you're using Linux, you will want to move to the linux subdirectory.

You will find a series of subdirectories for each of a number of possible compilers. For this article, I chose to use the gfortran compiler. Inside the gfortran subdirectory, you will find a number of scripts to handle each of the build steps. The first step is to run compile.make to build all of the required objects. These scripts need to be run from the location where the source code resides, so once you know which set of scripts you are going to use, move over to the subdirectory tinker/source. From here, I ran ../linux/gfortran/compile.make to compile all of the source code I needed into object files.

The next step is to combine these into a single library file by running ../linux/gfortran/library.make. The last step is to do the linking with the system libraries to create a final executable. This is done by running ../linux/gfortran/link.make.

You now will have a full set of executable files, recognizable by filenames that end with .x. These executable files then can be moved to any other location to make them easier to use.

You should find that 61 different executable files have been created. Each of these executables handles some separate task in the analyses that TINKER is designed to do. I look at only a few different executables here to give you a flavor of the types of tasks that you can do.

The first is analyze.x. This executable will ask for a structure file (in the TINKER .xyz file format) and the type of analysis to run. The output you get back includes the following items: the total potential energy of the system; the breakdown of the energy by potential function type or over individual atoms; the computation of the total dipole moment and its components, moments of inertia and radius of gyration; the listing of the parameters used to compute selected interaction energies; and the energies associated with specified individual interactions.

The next executable, dynamic.x, performs a molecular dynamic or stochastic dynamic computation. On an initial computation, it will take a .xyz structure file as input. If a previous computation was check-pointed, you can use the resultant dynamics trajectory file (or restart file) as input too. These two programs are both deterministic in their methods.

The executable monte.x provides a way to apply Monte Carlo minimization methods to molecular dynamics. It takes a random step for either a single atom or a single torsional angle, then applies the Metropolis sampling method.

The scan.x executable takes a .xyz structure file as input and finds an initial local minimum. From this first local minimum, the program starts searching out along normal modes to try to find other minima. Once it has searched along each of these modes, it then will terminate.

A number of these 61 executables are support utility programs that do non-computational work. For example, the executables xyzint.x and intxyz.x convert back and forth between the .xyz structure file format and the .int internal coordinates formatted file.

For all of these programs, the specific details of how they work is determined by a keyword file (with a filename ending with .key). TINKER uses a huge number of keywords to decide the specifics of any particular run. For example, you could set a single bond stretching parameter with the keyword BOND. The keyword CHARGE will set a single atomic partial charge electrostatic parameter. A full listing of the keywords is available in the TINKER documentation.

All of these executables are designed to run as command-line programs. The output tends to be files of numbers, which are hard for a human to evaluate. The group who created TINKER also created a program called Force Field Explorer (FFE).

Figure 1. On initial startup, you will get an empty project window and a TINKER console.

The executables built above are not compiled to interface with FFE as is. If you want to compile your own copy and have it interact with FFE, it requires changing a number of source files. In this case, I would suggest that you go ahead and download one of the installation packages that include FFE. These come as a gzipped shell archive. After gunzipping it, you can run the shell script to start up the Java-based installer. It will let you select which portions to install along with FFE. Once it is all done, go ahead and start up FFE. It will open up the main window and a console window. From within FFE, you can load up structure files and start various TINKER analyses.

When you first open an .xyz file, the structure is rendered and displayed in the main window. You then can select the Modeling Commands tab to select which specific TINKER analysis to run. By default, these TINKER runs happen locally on the same machine, but it doesn't have to be this way. FFE gives you the option of connecting to a remote machine, likely more powerful than your desktop, and getting the actual TINKER programs to run over there.

Figure 2. You have access to all of the TINKER analysis routines, directly from FFE.

Once you have results, you can change the visual details like colors and whether to use wireframe or tube and so on. You also have the option of exporting a visual as an image file in one of several file formats.

I easily could fill the entire contents of Linux Journal just covering the most basic functionality TINKER provides. Hopefully, you will have seen enough to get an idea of whether this software might be of use to you. If so, a rather large amount of detailed documentation is available at the main TINKER Web site.

Resources