[Sat Feb 14 11:07:07 CST 2015]

I've been convinced for a while now that, sooner rather than later, it will be possible to do most of our work from a mobile device that we can easily plug into external devices, such as a monitor, keyboard and mouse. While it's not possible yet, I'd say that they are becoming powerful enough that pretty soon they will be there. So, it wasn't surprising at all to read an article titled In Less Than Two Years, a Smartphone Could Be Your Only Computer on Wired's website. Apparently, the author managed to do just that for a whole week. He definitely encountered problems, but it was feasible. Sure, there is no doubt in my mind that power users will still need a regular desktop or laptop computer but, for the most part, the vast majority of people will be able to get by just with their smartphones and tablets, I think. To some extent, it already happens. {link to this entry}

[Sat Feb 14 10:04:19 CST 2015]

A few weeks ago, I wrote a short blog entry on kenel live patching. Well, now I read in The Register that live patching is set to be merged into the main source tree in the 3.20 release of the kernel. To my surprise, SUSE and Red Hat decided to join efforts to bring the feature to the kernel althogh, come to think of it, it makes perfect sense, especially in an open source environment. After all, once the software is open, any competitive advantage they may wish to gain should be based on the service they provide, and not the software itself. As a consequence of this state of affairs, everybody wins (although, arguably, everybody also makes less money than taking the monopolistic approach). Jiri Kosina, of SUSE, sent an email to the Linux kernel mailing list announcing the patch. He also provided a quick explanation of the two different solutions they had implemented so far:

The principle difference between the two solutions is how they are making sure that the patching is performed in a consistent way when it comes to different execution threads with respect to the semantic nature of the change that is being introduced.

In a nutshell, kPatch is issuing stop_machine(), then looking at stacks of all existing processess, and if it decides that the system is in a state that can be patched safely, it proceeds insterting code redirection machinery to the patched functions.

On the other hand, kGraft provides a per-thread consistency during one single pass of a process through the kernel and performs a lazy contignuous migration of threads from "unpatched" universe to the "patched" one at safe checkpoints.

So, SUSE and Red Hat kernel developers met in Düsseldorf and came up with a common approach:

It provides a basic infrastructure for function "live patching" (i.e. code redirection), including API for kernel modules containing the actual patches, and API/ABI for userspace to be able to operate on the patches (look up what patches are applied, enable/disable them, etc). It's relatively simple and minimalistic, as it's making use of existing kernel infrastructure (namely ftrace) as much as possible. It's also self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code). It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works (adding arch-specific support basically boils down to teaching ftrace about regs-saving).

Once this common infrastructure gets merged, both Red Hat and SUSE have agreed to immediately start porting their current solutions on top of this, abandoning their out-of-tree code. The plan basically is that each patch will be marked by flag(s) that would indicate which consistency model it is willing to use (again, the details have been sketched out already in the thread at [3]).

As far as I can see, Linus Torvalds has not replied yet. Nevertheless, it's exciting news for Linux users. {link to this entry}

[Mon Feb 9 12:08:01 CST 2015]

Not sure why this is so difficult to accomplish, but I was just trying to delete my old wish lists on Amazon and, to my surprise, it was more difficult than I thought. I just couldn't find the way to do it. So, I searched their help section, and found an article titled Delete Your Wish List that is quite misleading. No matter how hard I searched, I couldn't see the "Manage your lists" link. I even used Firefox's own search in a page functionality, and still couldn't find it. In the end, I found the solution somewhere in the Amazon forums:

1. Go to Wish List.
2. Scroll to the bottom of the lists on the left.
3. Clieck on "Manage Your List".
4. Add a checkmark to the list(s) you want to delete.
5. Hit the "Submit" button.

{link to this entry}

[Sun Feb 8 17:25:28 CST 2015]

A friend just asked me how to download books from Google Books. I truly thought Google had configured things to make this impossible, but this document from the wikiHow website explains how to do it. It's pretty easy, and it worked fine for me. {link to this entry}