UpFront

Linux capabilities are one of the more fluid and less defined regions of kernel development. Linus Torvalds typically has no trouble violating POSIX standards if he sees a better way of doing something. In the case of filesystem capabilities, however, there's no standard to violate. The best we've got is a POSIX draft document that was discarded before becoming official. So really, anyone with a good idea can come along and make big changes in that part of the kernel.

Filesystem capabilities refer to a finer-grained set of permissions than the traditional choice between running something as a regular user or running as root.

Recently, Eric W. Biederman and Andy Lutomirski found themselves tackling filesystem capabilities from opposite directions. Eric wanted to allow a process that's been granted one set of capabilities to invoke system calls using an even more constrained set of capabilities. Presumably, the goal would be to increase security by preventing system calls from being abused for nefarious purposes. And, Andy wanted to allow one process to allow a completely separate process to perform system calls on its behalf. This might allow the formation of system call services to centralize all system call usage and make it easier to secure those uses.

The discussion went round and round. Eric's idea, as he later clarified, was actually a bit broader than it appeared at first glance—he wanted to convert the Linux implementation of POSIX capabilities into “Real Capabilities”. The term Real Capabilities refers to a computer science concept that pre-dates POSIX capabilities. It refers to the idea of giving a process some sort of token that allows it to perform a specified action on a specified object.

Ultimately, nothing about capabilities, or any new patches in that area, can have real clarity until they go into the kernel. Before then, there's always the possibility that they'll violate something important or aim in the wrong direction. But, it's cool to watch Eric and Andy, and lots of other folks, trying to figure it out.

One recurring problem with Linux is the need for backward compatibility. Actually, this affects virtually the whole Open Source world, but Linus Torvalds takes a particular strict stance on the issue with regard to the Linux kernel. If there's a compiled piece of user software out in the wild that relies on a kernel feature, even a dumb kernel feature, then future kernels have got to support that feature, so that the piece of user software will continue to run after a kernel upgrade.

It makes sense. But as Andy Lutomirski recently said, the result was a batch of features that existed only to support old programs. And by carrying these features perpetually into the future, he said, newer software ran the risk of accidentally using those features or even becoming reliant on them.

He proposed allowing new software to turn off those compatibility features explicitly, but that turned out to be more complex than he'd originally thought. Specifically, one of his cornerstone ideas—granting the ability of newer software to turn off the vsyscall page—was not easy to arrange. Andy's initial idea was to have the compiler identify at compile time software that used newer versions of libc, and then have that piece of software elect to disable vsyscall at runtime. But, he didn't see a good way to accomplish that, and Brian Gerst pointed out that vsyscall was globally shared and couldn't be shut off for individual processes.

This actually turned out not to be 100% true. Although Andy agreed that vsyscall was shared globally, the mechanisms to execute it were all emulated in the kernel, and those could be disabled on a per-process basis.

Rich Felker proposed another workaround for vsyscall's global availability. He said the kernel could simply unmap all means of executing vsyscall. Any older software that tried to access it would generate a page fault, which the kernel could then catch and emulate vsyscall just for that program.

But, Andy didn't go for that idea. He said that modern instrumentation tools might want to read the targets of calls, and a page fault would prevent that. Any vsyscall solution, Andy said, had to maintain compatibility for those tools.

On the other hand, as Rich said, those modern tools might never be used on ancient binaries in practice. And even if they were, it might be possible to code up specific kernel workarounds for each use case in a less invasive way than trying to come up with a complete solution for vsyscall.

It's a robust debate, complicated by the fact that it's difficult to know for sure if anyone is actually running old binaries that depend on this or that kernel compatibility feature. But, Andy made it clear that cleaning out compatibility features was not really his primary goal, so much as it was to eliminate potential security holes. Apparently, Google's Project Zero had identified more exploits: googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html.

The Linux framebuffer, once a bastion of innovation, is now on the chopping block, in favor of the Direct Rendering Manager (DRM) subsystem. The fbdev maintainer, Tomi Valkeinen, has asked everyone to stop submitting new fbdev drivers and to aim their efforts at DRM instead.

It was not as uncontroversial as you might think. It turned out, as folks like Thomas Petazzoni said, that it still was easier to write very simple drivers for fbdev, than it was for DRM. Just in terms of lines of code, Geert Uytterhoeven noticed that the simplest fbdev drivers were just a few hundred lines of code, while the simplest DRM drivers might require a couple thousand.

No one argued that this would be a permanent problem. If anything, the discussion highlighted the need to write some supporting libraries for DRM and help speed up the ultimate elimination of fbdev.

I freely admit I learned about this app from my wife. In fact, I saw a few nostalgic posts on her Facebook timeline and investigated where they came from. It turns out she had installed an app called Timehop. I normally wouldn't write about something that at first glance seems like an ego-stroking shot of nostalgia, but I had so much fun looking at the posts it dug up, I couldn't help myself.

Timehop is a free app in the Google Play Store. Once you install it, you're guided through connecting to all the major social-media networks (Twitter, Facebook, Instagram and a few others I didn't recognize). Then, using some sort of popularity algorithm (or magic, I'm not sure which), it finds funny and/or memorable posts and photos from the past and shows them to you. You are able to share those old posts from the app and allow others to experience your little hit of nostalgia as well.

I still feel a little silly sharing this app with the Linux Journal community. But really, it's so much fun, if you're having a bad day, give it a try and see if a three-years-ago-you can cheer you up. I know two-year-ago Shawn made me smile!

A few years ago there was a project designed to boot generic laptops so they functioned as Chromebooks. It was a cool project, but unfortunately, the compatibility wasn't great, and it wasn't reliable to use on a daily basis. Although Chromebooks are old news these days, it still would be quite useful to transform aging laptop computers into Chromebooks. Because they have such low system requirements, older laptops running the ChromeOS can become quite useful again.

Thanks to the folks at Neverwhere, you can get the CloudReady installer that installs Chromium onto a wide variety of laptops from various manufacturers. (A long list of tested models is available at go.neverware.com/certifiedmodels.) I actually have a Dell D420 that is getting very long in the tooth as a Linux machine, but as a Chromebook, it's still quite effective. If you have an aging laptop, give CloudReady a try. It's free, and you even can boot off USB to check it out before installing.

CloudReady from Neverwhere: www.neverware.com/free.

I love Sonos. There probably are some audiophiles reading this who rolled their eyes at my lack of auditory prowess, but honestly, the speakers sound wonderful to my 1980s-damaged eardrums. Granted, the Wi-Fi-enabled speakers are very expensive, thus limiting my supply. I'm amazed at the ability for the speakers to sync a single audio source throughout my house perfectly without the need for wires. At all.

The problem (apart from the price tag) is the limited options for music sources. You can stream radio stations, Pandora radio and even MP3 music files from a central network-accessible server. For my family of teenage girls, however, the inability to stream via Airplay (yes, my family has many Apple products) is a showstopper. So in their upstairs bathroom there's a $300 speaker on the shelf, and they just listen to their phone speakers while in the shower. It breaks my heart. Sonos offers line-in options for its larger speakers, but it's really a kludge and doesn't work well.

Enter Airsonos. An open-source project, Airsonos is a Node.js-based application that runs on a server and probes the network for on-line Sonos speakers. It then creates Airplay devices for each speaker, and an iPhone or iPad easily can stream to a Sonos speaker. I personally run Airsonos as a Docker app, and it's a “set it and forget it” sort of application. In fact, Airsonos has all the makings of an Editors' Choice award-winning project:

So, this month's Editors' Choice award goes to Airsonos, with shared award status to the Dockerized app version maintained by “justintime”—thank you for making my nerdy world a better place!

I'm just starting out in the world of development, and many of the projects I'm interested in exploring are written in Node.js. If you're an old hand at such things, you already know that which version of Node you use on a particular application is vitally important. (This is actually one of the reasons Docker is so amazingly amazing when it comes to deploying Node apps, but I digress.)

For folks like me, the version issue can be confusing and frustrating. Thankfully, I ran across a simple tool with a simple name: n. Once you have Node.js installed on your system, using n, it's possible to download and make active a very specific version of the program, so your specific application works properly. In fact, when I was installing the NOMP stratum server for Bitcoin mining recently, I had to use n to try more than a dozen versions before I found the one that worked as expected.

Node.js is a powerful, incredible language that is used by many smart developers. Those of us who are just getting started, however, are easily intimidated by version needs. If that describes you, or if you understand the nuances but just want a quick and easy way to manage it, check out n today. There are instructions on the Github page: https://github.com/tj/n.

The secret of being boring is to say everything.

—Voltaire

It's not enough that we do our best; sometimes we have to do what's required.

—Winston Churchill

The best way to escape from a problem is to solve it.

—Alan Saporta

To avoid criticism do nothing, say nothing, be nothing.

—Elbert Hubbard

The vitality of thought is in adventure. Ideas won't keep. Something must be done about them.

—Alfred North Whitehead

Previously in this space, I have covered software packages like Maxima that can be used to solve symbolic mathematics problems. Several packages are available that can do those types of calculations. In this article, I discuss Xcas/Giac. Xcas is the GUI interface to the system. Giac is the command-line program that provides access to the core engine. Xcas has the functionality to handle symbolic algebra, two-dimensional and three-dimensional graphing, spreadsheets and statistics. It even has its own programming language that you can use to add extra functionality of your own. Although you can use the default interface that comes with Xcas, you also can link the CAS (Computer Algebra System) engine as a shared library to your own C++ code.

Packages are available for many different Linux distributions, but they usually aren't available via the default package management systems. For example, in Ubuntu, you need to add an APT source that points to the home page for Xcas. Then you can use the following to install it on your system:

sudo apt-get install giac python-giacpy

Once it is installed and you start it up, Xcas asks what mode you want to work in. You can select from spreadsheet, CAS, programming or geometry. Whenever you start a new session within Xcas, you get this same initial interface. If you want to change it later, select the Cfg→General Configuration menu option. This pops up a new window where you can select the Level option. If you choose the CAS option, you get the starting window shown in Figure 1.

Figure 1. This the opening window in CAS mode.

To open a new tab with the same level, click the File→New Session menu item. You also can open a new tab using any of the available levels, or modes, using menu commands. They are a bit hard to find though. For example, you can get a new spreadsheet with the Spreadsheet→New Spreadsheet menu item.

There is far too much functionality available within Xcas to explain how everything works in such a short article, but I'll try to cover some of the most interesting parts.

Let's start by looking at the command level. This operates in a form similar to the worksheet in Maple or Mathematica. You start with the first empty command line and enter the mathematical expression you want to evaluate. Pressing Enter runs the command, displays the output in a new pane, and creates a new command line and drops the cursor there, ready for your next command. This style should be comfortable to anyone with even a little bit of experience.

The keyboard panel at the bottom of the window gives you a selection of common elements that you will likely use within your commands. If you don't need to use it, you can remove that pane by clicking the Kbd button at the top of your session window.

The library of available commands is very large. Luckily, you can find the majority of them by clicking on the Cmds menu item. Here, you can find sections for several different areas, such as complex numbers, group theory, calculus or probability.

No system has everything that you may possibly need when you start doing any kind of scientific computing. This means that you need to be able to add new functionality of your own devising. With Xcas, you can create a new function by clicking on the Prg→New program menu item. This pops up a new window where you can define the name, arguments, locals and a return value. Once you are happy with these settings and click the OK button, you will get a new program pane with a template ready for you. You then can add in any other code that is required by your new functionality.

Figure 2. You can create your own functions in Xcas.

There are menu options within the programming pane to help you with the syntax of programming structures, such as loops, conditionals and IO. In Xcas, functions need to be compiled before they can be used. This compiling step happens when you click the OK button in the programming pane. If there are any errors, you will get a message in the output pane. If there are no errors, you will get a “Success compiling” message.

You can include graphics inline within a session. If you want a general graphics pane, click the Geo→New figure 2d or Geo→New figure 3d menu item. This gives you a graphics pane along with an associated command pane where you can enter the plotting commands you want drawn. If you have a specific item drawn, you can select one of the other items in the Geo menu section. For example, if you want to graph a function, you can go to Geo→Graph→Function. This pops up a new window where you can enter the function you want to graph, along with the limits of the independent variable. When you click OK, you get the graph drawn inline within your current session.

Figure 3. Graphing functions is pretty easy.

Figure 4. Graphs show up inline within your session.

Xcas is designed to be reasonably good at interacting with other CAS software. With this idea in mind, it is no surprise that you can import and export worksheets using several different formats. Xcas will handle Maple and Mu PAD file formats fairly well. It also can handle the file format used by TI calculators (like the TI-89 or the Voyage 200). With this type of support, you should be able to share your work with many other people.

With Xcas, you can work on almost any system that you have access to. You can use your Linux system to do major amounts of work, and then you can continue that work on your Android or Apple device, or even use your Texas Instruments calculator. Although the interface is a bit confusing, and the learning curve is rather steep, there is no denying just how powerful Xcas is.