There's an ongoing impulse among a diversity of developers to be able to compile some or all of the Linux kernel as a library, so that a piece of software could use kernel services and APIs while running under a different kernel entirely, or a different operating system.
This time, the impulse came from Octavian Purdila, creator of the Linux Kernel Library (LKL), essentially an entire kernel compiled as a static library. He distinguished LKL from projects like User Mode Linux (UML), saying that LKL was more lightweight, having no infrastructure requirements or needing any particular sort of runtime environment.
A bunch of folks expressed interest, especially in terms of interacting with similar projects like libOS and libguestFS. And, Richard Weinberger remarked that LKL seemed to solve UML's biggest pain points: the need to use ptrace() to handle system calls and to do virtual memory management using SIGSEGV.
In a device-centric world with heavy, inefficient battery technology, there's a big incentive to figure out ways to save power. One possibility is to turn off portions of hardware when they're currently not in use, like a phone's touchscreen when the phone is in your pocket.
The difficulty lies in knowing exactly which piece of hardware to turn off, and when. If there's a clear user action, like flipping closed a flip-phone, the problem is simplified. Irina Tirdea recently tried to recognize such actions and come up with mechanisms to respond to them properly. She posted some patches to do this.
Octavian Purdila, also working on the project with Irina, described a target scenario as being when a touchscreen has been blanked but is still aware of the user's touch—through the fabric of a pocket, for example. The goal of the patches, he said, would be to save power by turning off all the hardware associated with that screen, and turn everything on again when the user activates the device.
The problem with this sort of feature is that it could be implemented along any of a number of different layers of the kernel code. The ideal location could make the difference between a complex, easily broken implementation and a simple, efficient implementation. Several folks felt that Irina and Octavian's approach was in the wrong part of the kernel, and the discussion devolved into a consideration of completely different approaches.
No consensus arose, although the allure of power-savings will undoubtedly keep the debate alive.
Mounting a filesystem under a virtual machine can be tricky. Security privileges and restrictions need to be respected, or else a filesystem could become a vector of attack by a malicious user. This particular area of kernel development also tends to have a wide appeal among companies trying to support their products, so it's possible for a variety of developers to find themselves working at cross purposes and need to accommodate each other before their patches can be accepted.
Seth Forshee and Eric Biederman, for example, recently wrote some patches to allow mounting Ext4 and FUSE filesystems by unprivileged users, ignoring the security information that otherwise might prevent those users from accessing that data.
Meanwhile, Lukasz Pawelczyk was working on code specifically to support that same security information.
A debate sprang up over the particular context involved. Andy Lutomirski suggested that if a filesystem contained a user's own data, it would be fine to override security features, on the grounds that users should be able to do what they wanted with their own data. While Casey Schaufler replied that the kernel shouldn't care what the user knew about the data, it had to follow the security protocols or else it wouldn't be able to enforce them at all.
On the other hand, as Eric pointed out, filesystems like FAT and Minix weren't capable of storing the same type of security information as more modern filesystems. There had to be a way, he said, to mount such filesystems without requiring them to support security features they couldn't support.
It's an ongoing debate. Security trumps all other considerations, including dire need, so an issue like unprivileged filesystem mounts inevitably will involve a consideration of the specific context in which a user might try to do something. Often there's some kind of crazy nuance that makes something feasible when you could have sworn it never would be feasible.
The single largest group of users on high-performance computing clusters has to be the chemists. Their CPU-year count is definitely at the very top of the list. Because of this heavy use, several different packages have become standard tools that most computational chemistry researchers use. So in this article, I take an introductory look at one called ABINIT (www.abinit.org).
ABINIT calculates the energy and structure of groups of nuclei and electrons. The method used to make these calculations is Density Functional Theory (DFT, https://en.wikipedia.org/wiki/Density_functional_theory). If you want to know more about the underlying theory, feel free to go talk to your nearest computational chemist.
Although my exposure has been with people running ABINIT on scores of machines in parallel, at least in a learning environment or for small systems, nothing is stopping you from running it on your own desktop. The first step, of course, is to install it on your machine. You may have packages within your distribution to make installation easier. For example, on Debian-based systems, you can install it with:
sudo apt-get install abinit abinit-data abinit-doc
The only issue with that method is you probably will get an older version of ABINIT. At the time of this writing, the Ubuntu package installs version 7.8.2, while on the Web site, you can download version 7.10.5.
If you need the latest available code, you always can get the source code from the main home page and compile it yourself on your local machine. In order to build it yourself, you need the usual utilities to build other packages, such as make, libtool and autoconf. Because the majority of the code is written in FORTRAN, you also need a compiler capable of compiling F90 code. This will allow you to build a basic version of ABINIT. You can include extra functionality, such as MPI or NetCDF, if you have them available on your system.
The main executable to run these calculations is called abinit. It takes a number of input files in order to do the actual calculation. One of these input files is actually a file of files. It is a file that contains a list of other input files that abinit needs to read in. The usual filename ending is “.files”. If you have this input file, you can run your simulation with:
abinit < my_input.files >& log
This tells abinit to read the input data from standard input (attached to the file my_input.files) and to write its results to standard output (attached to the file log). The log file only captures output that gets written out to the standard output stream. There is a lot more output that is written out. These other output files are defined in the my_input.files file. The following list is a more-detailed description of the contents:
ab_in — main input file.
ab_out — main output file.
abi — root filename for other input files.
abo — root filename for other output files.
tmp — root filename for temporary files.
my.psp — the pseudopotential used for this run.
The root names “abi”, “abo” and “tmp” are used to create the multiple files for each of those sections.
There are a few rules around the input files that may cause problems if you don't follow them. The first is that you can't have tab characters in your input file. So, be sure that your editor uses space characters when you press the tab key. The second rule has to do with using negative numbers. There can't be any spaces between the negative sign and the first digit of the number. The last formatting rule is that no line can be more than 132 characters. If any lines end up longer than that, ABINIT simply will ignore the extra content. If you get errors when trying to run your own jobs, those are the first few places you should check.
There are a massive number of input variables that allow you to control parameters around file handling, geometry, structure optimization and response functions, among many others. These input variables can be in any order. The entire file gets parsed before the calculations start. When you start creating your own input files, you probably will want to be able to check them somehow. Luckily, you can use ABINIT itself to do this. The abinit executable includes an option (-d or --dry-run) to take your input files and validate them without starting the calculations. This allows you at least to catch major typos before wasting the time involved in doing a partial run and having it fail.
Along with your own input files, describing the geometry and other descriptive variables, ABINIT needs input files that describe something called the pseudopotential for your system. There are different types, such as Troullier-Martins or Hartwigsen-Goedecker-Hutter pseudopotentials, that can be used for different situations. Luckily, ABINIT includes pseudopotentials for the entire periodic table. This means you simply can build up your molecule by including the pseudopotentials for each of the different types of atoms in your system. Although it isn't necessary in most cases, you can create your own for some very specialized system if needed.
The other thing to be aware of is that ABINIT is released under a GPL license. This means you have access to all of the source code and can investigate exactly how the calculations are being done. When doing fundamental scientific research, that can be very important. You may be trying to do calculations in a region where the available algorithm is no longer valid. All of these calculations make assumptions to try to simplify the calculations so that they are actually doable, and it is very important to keep that in mind. But, with access to the code, you have the opportunity to make changes to those algorithms to fit the assumptions better that are valid for your problem. This open-source code gives you the ability to build on all of the past work and push it into new areas of research. Just remember to pass these extensions and improvements on to the next group of researchers to keep pushing our understanding forward.
Interpreting the output from ABINIT can be a bit of a job. There is a lot of output describing how the calculated values progressed until they reached the requested accuracy to the actual answer. For example, if you are calculating the energy for a molecular configuration, you probably are interested in when the energy is at its lowest value. This will be the most stable configuration for these nuclei and electrons. But, how do you interpret this output? Several tools are available to take the geometric portion of this output and plot it so that you can see what the configuration actually looks like. There also will be output describing how strong the various connections are between the nuclei, which you can use to see how reactive your molecule may be.
This is just a very basic introduction to what is involved when using ABINIT. Hopefully, you now feel a bit more comfortable digging in to the massive documentation and using ABINIT to solve whatever molecular problem you have. When you are ready, you can move on to much larger problems by using the MPI capabilities in ABINIT to use as many machines as you have available.
This is the season of resolutions, and in the technological world we live in, spending time off-line is a difficult but healthy activity. The problem is our lives have become so intertwined with our phones that it's easy to whip out our cell phones inadvertently to check our social networks quickly.
The QualityTime app is designed to help curb the habit just a bit. Ironically, it's an Android app designed to help you stop using Android apps so much. Still, it's just geeky enough to make limiting technology time a fun endeavor. If you like graphs, data, numbers and goals, QualityTime can help you identify where you spend most of your time on-line and then assist in lessening your face time with FaceTime (okay, not actually FaceTime, since that's an Apple app, but the word play was too fun to leave out).
(Photo from qualitytimeapp.com)
If you're forgetting what your family members actually look like, or if you're surprised to see your friends as anything but their on-line avatars, you really need to give QualityTime a try. If you just want to see how much time you spend on various applications on your Android device, you should try QualityTime as well. I found the data alone worth the installation, and it inspired me to spend a little less time texting my kids and a little more time talking to them (while they text their friends—baby steps...).
Check it out at qualitytimeapp.com.
I have mixed emotions about ReactOS. It's open source. It's freely available. But, its goal is to be binary-compatible with Windows! ReactOS is not a Linux operating system. In fact, it doesn't share the UNIX architecture at all. It looks like Windows NT, and it behaves much like Windows NT.
It's just odd!
The best way I can think to describe it is to imagine if Wine evolved into an entire operating system that booted on hardware instead of running inside Linux. That's basically what ReactOS feels like. It's not ready for prime time (and the developers make that very clear—it's alpha software), but it's worth checking out. Since it's early in the development process, if you get involved now, you can have a say in what compatibilities get priority.
ReactOS is the perfect solution for folks who need to run Windows apps, but absolutely refuse to run Microsoft code. I'm personally not convinced that ReactOS is a better idea than Wine running inside Linux, but I'm sure running it as its own operating system will provide possibilities that just can't happen in a Wine environment. The folks at ReactOS provide installers and prebuilt VM instances that can be launched in order to try it out on your existing system. Whether you are just morbidly curious about a non-Windows Windows or are interested in getting involved in the development, go to reactos.org for more details.
I love Kodi. (This is just an evolution of my love for XBMC, since it's the same thing with a new name.) In fact, although I've expressed my love for Plex over and over (and over) the past few years, I still use Kodi as my main interface for the televisions in my house. We gave Plex a try as our main media center software when it was released for TiVo, but after several months, we found its interface to be cumbersome and the transcoding for local media frustrating.
So during the holidays, I once again installed Kodi on Raspberry Pi devices around my house. Using OpenELEC, the installation process itself is painless. Heck, even centralizing the library database was painless. The frustrating part was getting 5.1 surround sound to work.
On the bedroom televisions, surround sound is a moot point, because I just use whatever stereo speakers are included in the TV. For our main media center, however, I have a fancy Sonos PLAYBAR with subwoofer and rear channel speakers. The only audio connection the PLAYBAR accepts is optical audio, so I bought an inexpensive HDMI audio extractor. (This one works great: smile.amazon.com/dp/B00BIQER0E.)
The problem is that when Kodi is set to 5.1 audio output, the center channel is missing! There's a bit of disagreement as to whether it's a bug in Kodi/OpenELEC or just a result of optical audio supporting only two channels of audio. (If that seems odd to you, it was to me too. But apparently, it supports only two channels, which contain all the surround information, or something like that.) The non-intuitive solution is to force Kodi to 2.0 audio. Although it doesn't seem to make sense, I can vouch for it working. Kodi sends the audio as 2.0 stereo, which is transferred over optical (or HDMI, whatever you're using), and then the receiver decodes the surround information from that two-channel signal.
The tl;dr version is that Kodi will send the surround sound information over two-channel audio, so if you are missing your center channel, try switching to 2.0 audio.
If you're anything like me, the holiday season is spent fixing Wi-Fi and removing spyware. Occasionally, I get to install Linux for a relative who is ready to give up Windows or needs something that will run on a circa-Windows 2000 computer (Xubuntu is usually my choice). The problem with helping friends and relatives with their computers over the holidays is that you become their first call when something goes wrong. You either can fight it or make it easier on yourself by preparing in advance.
I love Team Viewer. It's not an open-source program, but it's free for personal use with no frustrating limitations. Plus, it runs on Windows, OS X and Linux. The best part is how easy it is to use. I generally don't set up the “automatic availability” feature that logs the computer in to the Team Viewer network automatically on boot. I like to use the standard startup, which requires users to call me with the code on their screen.
The best thing about Team Viewer is how easily it handles NAT situations. Since the software connects to the Team Viewer servers, those servers act like a connection broker, meaning there are no router ports to forward and no proxies to set up. As long as the computer is on-line, you should be able to take over and help someone. Again, you might not like the ease with which you'll be able to help, but having access to a user's computer in real time is so much nicer than explaining to Uncle Harry what “right click” means.
Due to its free license for personal use, cross-platform compatibility and incredible ease of use, Team Viewer gets this month's Editors' Choice award. It's not new software, but after a stretch of holidays, I'm reminded just how nice it is to have installed on all my relatives' computers. Be sure to install the client before you leave their houses, or else be prepared to explain software installation over the phone! Get your copy at teamviewer.com.
Don't watch the clock; do what it does. Keep going.
—Sam Levenson
What you do today can improve all your tomorrows.
—Ralph Marston
Life is 10% what happens to you and 90% how you react to it.
—Charles R. Swindoll
It does not matter how slowly you go as long as you do not stop.
—Confucius
Keep your eyes on the stars, and your feet on the ground.
—Theodore Roosevelt