Home Blog Page 1652

IBM Plots Sixth-Generation X86 Systems

Big Blue’s so called X6 Architecture is designed to boost performance of x86 servers so they can better handle workloads such as big data analytics. virtualization and enterprise resource planning.

Valve’s VOGL OpenGL Debugger Should Be Great

As a follow-up to Steam Dev Days Is Off To A Great Start, Valve’s new OpenGL debugger is looking great! Here’s some more details…

Read more at Phoronix

Linux 3.14 Officializes Broadwell, Deprecates Legacy UMS

As usual, Intel’s preparing to land a lot of exciting changes within the Linux 3.14 kernel as soon as its merge window opens in the coming days…

Read more at Phoronix

Intel Does ARM: Citi ‘Identifies’ Another Possible Customer

Marvell is cited as a likely chip customer for Intel. If the analysis pans out, it would be Intel’s third ARM customer. [Read more]

 
Read more at CNET News

Convirture Announces Easy-to-Use Hyper-V Management platform

Managing virtual machines and hypervisors can be a real pain. Managing multiple ones across multiple platforms is even worse Convirture is easing the headaches.

HP Launching Android Voice-Enabled Tablets for India

There are rumors that HP might yet try again with phones and today we see tablets with voice capability launching in February in India.

How to Build a Contextual Menu in Android App Development

Creating appropriate menus for your app is vital to creating a good user experience. In the last tutorial, we looked at creating the options menu with XML and also at adding items programmatically. In this tutorial, we’ll look at contextual menus — menus which relate to a particular part of the view.

As of Android 3.0, there are two types of contextual menu: old-style floating menus, which float on the screen, anchored to the element clicked on; and contextual action mode (Android 3.0 and up), in which a contextual action bar (CAB) appears at the top of the screen. The CAB is now the preferred way of providing a contextual menu, but if your code is compatible with Android 2.3 or earlier, you should also provide a floating version to fall back to. We’ll cover both options and also look at how to include both in your code.

We’ll use the same basic GridView code as in the last tutorial, and our contextual menu entry will use the Intent code from the GridView tutorial, which fires a URL associated with the image clicked on.

Floating Menus

We’ll start with the floating contextual menu, which you’ll use for devices running a version older than API 11. First, let’s create our XML menu, res/menu/grid_element_menu.xml:

<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android" >
    <item 
         android:id="@+id/showUrl"
         android:title="@string/showUrl_title"/>
</menu>

Next, we handle it in the GridViewTestActivity code. We need to add a call to register the grid items for the context menu, and implement onCreateContextMenu():

protected void onCreate(Bundle savedInstanceState) {
 // as before
 gridview.setAdapter(gridadapter);
 registerForContextMenu(gridview);
 // rest as before
}
public void onCreateContextMenu(ContextMenu menu, View v,
                                ContextMenuInfo menuInfo) {
  super.onCreateContextMenu(menu, v, menuInfo);
  MenuInflater inflater = getMenuInflater();
  inflater.inflate(R.menu.grid_element_menu, menu);
}

registerForContextMenu() associates the provided View (gridview) with a context menu. If the View is GridView or ListView, doing this registers all its items for the same context menu. For other Views, you would need to register each View for its own individual context menu. onCreateContextMenu() works exactly the same way as the last tutorial’s onCreateOptionsMenu(), inflating the menu from XML.

Finally, in order to do the right thing when the user clicks on a menu item, we need to implement onContextItemSelected():

public boolean onContextItemSelected(MenuItem item) {
  AdapterContextMenuInfo info = (AdapterContextMenuInfo) item.getMenuInfo();
  switch (item.getItemId()) {
    case R.id.showUrl:
      Intent i = new Intent(Intent.ACTION_VIEW);
      i.setData(Uri.parse(gridadapter.getItem(info.position).
                          getImageUrlString()));
      startActivity(i);
      return true;
    default:
      return super.onContextItemSelected(item);
  }
}

Here we only have one menu item so far, but we allow for adding more by using a switch statement. This also allows for handing menu items up to a superclass.

Compile and run, and you’ll see your floating menu when you long-click on an item. 

android floating menu

Contextual Action Menu

Moving on from the floating contextual menu to the now-preferred contextual action bar (CAB). There are two ways to create a CAB. If you want to attach the CAB to a specific single view, you can use ActionMode.Callback. (This is discussed in detail in the Android menus docs.) However, this doesn’t work so well with a ListView or GridView. For those, you’re better off implementing a MultiChoiceModeListener. This allows the user to pick multiple items and then apply a single option to them. Here however we’re only applying our sample choice to a single item, to demonstrate the interface. When creating your app, consider carefully which menus to use under which circumstances to create the best user experience.

The MultiChoiceModeListener looks like this (in GridViewTestActivity):

private MultiChoiceModeListener modeListener = new MultiChoiceModeListener() {
    	
  int itemSelectedPosition; 
  public boolean onCreateActionMode(ActionMode mode, Menu menu) {
    MenuInflater inflater = mode.getMenuInflater();
    inflater.inflate(R.menu.grid_element_menu, menu);
    return true;
  }
        
  public void onItemCheckedStateChanged(ActionMode mode, int position,
                                        long id, boolean checked) {
    itemSelectedPosition = position;
  }
  public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
 	// Used for updates to CAB after invalidate() request
    return false; 
  }
  public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
    switch (item.getItemId()) {
      case R.id.showUrl:
        Intent i = new Intent(Intent.ACTION_VIEW);
        i.setData(Uri.parse(gridadapter.getItem(itemSelectedPosition).
                            getImageUrlString()));
       	startActivity(i);
       	mode.finish();
        return true;
      default:
        return false;
    }
  }
  public void onDestroyActionMode(ActionMode mode) {
    // do nothing
  }
        
};

If you compare this code to the floating contextual menu or to the options menu, you’ll see a lot of similarities. We inflate the menu when it’s first created, and onActionItemClicked() once again has the switch code we’ve seen before. This time though we need to get the position of the selected item from another method, onItemCheckedStateChanged(). Note that as we only have a single int to store the item position in, every time an item is selected or unselected, this int will be overwritten. This means that we only ever send a single URL (of the item most recently clicked) with the Intent. If we wanted to be able to act on multiple items (eg to delete them, or to share them all), we would need to keep track of all the items selected.

Having created the MultiChoiceModeListener, it just takes two lines to set it up in GridViewTestActivity:

protected void onCreate(Bundle savedInstanceState) {
  // as before
  gridview.setChoiceMode(GridView.CHOICE_MODE_MULTIPLE_MODAL);
  gridview.setMultiChoiceModeListener(modeListener);
}

Compile and run, and a long-click will produce the CAB.

You can also use the ActionMode to make changes in the contextual action bar. For example, you can set a custom title or subtitle:

public boolean onCreateActionMode(ActionMode mode, Menu menu) {
  // as before
  mode.setTitle("Action Bar!");
  mode.setSubtitle("Subtitle");
  return true;
}

This screenshot shows where they’ll appear. See the ActionMode docs for other options. 

android menu cab

 Another improvement in the code would be to change the background color of any selected items, or to set up a checkbox, to show which item(s) have been selected.

Handling Fallback

If you code both the floating menu and the CAB, and run it on an Android device running API 11 or higher, the floating menu will be ignored in favour of the CAB, which is now the preferred option for contextual menus. To make your code run using the floating menu, on earlier API versions as well, you can code an API check:

protected void onCreate(Bundle savedInstanceState) {
  // as before
  // next line replaces setChoiceMode() and setMultiChoice..() lines
  setUpContextualActionBar(); 
}
private void setUpContextualActionBar() {
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    gridview.setChoiceMode(GridView.CHOICE_MODE_MULTIPLE_MODAL);
    gridview.setMultiChoiceModeListener(new MultiChoiceModeListener() {
      // code to set up MultiChoiceModeListener as before
  });
  }
}

You’ll also need to add a note at the start of the class, to suppress API compatibility warnings and allow the code to compile:

@SuppressLint("NewApi") public class GridViewTestActivity extends Activity 

You should only do this if you are very certain that you’ve wrapped all of your new API code in appropriate if clauses or otherwise protected it. For more on supporting multiple platforms and APIs, see the Android docs.

 

For more in this series see:

Android App Development: How to Create an Options Menu

Google’s Latest Chrome Release Tries to Replace the Windows 8 Desktop

This week’s Google Chrome update added some significant new features to its Windows 8 mode, effectively turning the browser into a stripped-down version of Chrome OS, with its own taskbar and window-management tools. But who’s it for, really?

kdbus details

Now that linux.conf.au is over, there has been a bunch of information running around about the status of kdbus and the integration of it with systemd. So, here’s a short summary of what’s going on at the moment.

Lennart Poettering gave a talk about kdbus at linux.conf.au. The talk can be viewed here, and the slides are here. Go read the slides and watch the talk, odds are, most of your questions will be answered there already.

For those who don’t want to take the time watching the talk, lwn.net wrote up a great summary of the talk, and that article is here. For those of you without a lwn.net subscription, what are you waiting for? You’ll have to wait two weeks before it comes out from behind the paid section of the website before reading it, sorry.

There will be a systemd hack-fest a few days before FOSDEM, where we should hopefully pound out the remaining rough edges on the codebase and get it ready to be merged. Lennart will also be giving his kdbus talk again at FOSDEM if anyone wants to see it in person.

The kdbus code can be found in two places, both on google code, and on github, depending on where you like to browse things. In a few weeks we’ll probably be creating some patches and submitting it for inclusion in the main kernel, but more testing with the latest systemd code needs to be done first.

If you want more information about the kdbus interface, and how it works, please see the kdbus.txt file for details.

Binder vs. kdbus

A lot of people have asked about replacing Android’s binder code with kdbus. I originally thought this could be done, but as time has gone by, I’ve come to the conclusion that this will not happen with the first version of kdbus, and possibly can never happen.

First off, go read that link describing binder that I pointed to above, especially all of the links to different resources from that page. That should give you more than you ever wanted to know about binder.

Short answer

Binder is bound to the CPU, D-Bus (and hence kdbus), is bound to RAM.

Long answer

Binder

Binder is an interface that Android uses to provide synchronous calling (CPU) from one task to a thread of another task. There is no queueing involved in these calls, other than the caller process is suspended until the answering process returns. RAM is not interesting besides the fact that it is used to share the data between the different callers. The fact that the caller process gives up its CPU slice to the answering process is key for how Android works with the binder library.

This is just like a syscall, and it behaves a lot like a mutex. The communicating processes are directly connected to each other. There is an upper limit of how many different processes can be using binder at once, and I think it’s around 16 for most systems.

D-Bus

D-Bus is asynchronous, it queues (RAM) messages, keeps the messages in order, and the receiver dequeues the messages. The CPU does not matter at all other than it is used to do the asynchronous work of passing the RAM around between the different processes.

This is a lot like network communication protocols. It is a very “disconnected” communication method between processes. The upper limit of message sizes and numbers is usually around 8Mb per connection and a normal message is around 200-800 bytes.

Binder

The model of Binder was created for a microkernel-like device (side note, go read this wonderful article about the history of Danger written by one of the engineers at that company for a glimpse into where the Android internals came from, binder included.) The model of binder is very limited, inflexible in its use-cases, but very powerful and extremely low-overhead and fast. Binder ensures that the same CPU timeslice will go from the calling process into the called process’s thread, and then come back into the caller when finished. There is almost no scheduling involved, and is much like a syscall into the kernel that does work for the calling process. This interface is very well suited for cheap devices with almost no RAM and very low CPU resources.

So, for systems like Android, binder makes total sense, especially given the history of it and where it was designed to be used.

D-Bus

D-Bus is a create-store-forward, compose reply and then create-store-forward messaging model which is more complex than binder, but because of that, it is extremely flexible, versatile, network transparent, much easier to manage, and very easy to let fully untrusted peers take part of the communication model (hint, never let this happen with binder, or bad things will happen…) D-Bus can scale up to huge amounts of data, and with the implementation of kdbus it is possible to pass gigabytes of buffers to every connection on the bus if you really wanted to. CPU-wise, it is not as efficient as binder, but is a much better general-purpose solution for general-purpose machines and workloads.

CPU vs. RAM

Yes, it’s an over simplification of a different set of complex IPC methods, but these 3 words should help you explain the differences between binder and D-Bus and why kdbus isn’t going to be able to easily replace binder anytime soon.

Never say never

Ok, before you start to object to the above statements, yes, we could add functionality to kdbus to have some blocking ioctl calls that implement something like: write question -> block for reply and read reply one answer for the request side, and then on the server side do: write answer -> block in read That would get kdbus a tiny bit closer to the binder model, by queueing stuff in RAM instead of relying on a thread pool.

That might work, but would require a lot of work on the binder library side in Android, and as a very limited number of people have write access to that code (they all can be counted on one hand), and it’s a non-trivial amount of work for a core function of Android that is working very well today, I don’t know if it will ever happen.

But anything is possible, it’s just software you know…

Thanks

Many thanks to Kay Sievers who came up with the CPU vs. RAM description of binder and D-Bus and whose email I pretty much just copied into this post. Also thanks to Kay and Lennard for taking the time and energy to put up with my silly statements about how kdbus could replace binder, and totally proving me wrong, sorry for having you spend so much time on this, but I now know you are right.

Also thanks to Daniel Mack and Kay for doing so much work on the kdbus kernel code, that I don’t think any of my original implementation is even present anymore, which is probably a good thing. Also thanks to Tejun Heo for help with the memfd implementation and cgroups help in kdbus.

Tackling Cancer Through Big Data and the Cloud

If ever there was a goal with universally undisputed support, it’s finding a cure for cancer. Making that happen, of course, is the trick, thanks in no small part to the sheer volumes of data involved.

Cancer is not a single disease, George Komatsoulis, deputy director of the National Cancer Institutes’s Center for Biomedical Informatics and Information Technology, told Linux.com.

george komatsoulisThough it’s traditionally been categorized based on where in the body it appears, “the trouble is that it’s not like an infectious disease” with a single infectious agent, Komatsoulis explained. “Here, there are dozens if not hundreds of possible mutations. Pragmatically, we need to molecularly categorize these tumors — and lots of them — so we can start classifying the ones that will respond well to treatment.”

Translate that imperative into IT terms and what do you get? That’s right: a whole lot of data.

2.5 Petabytes of Data

Back in 2005, NCI and the National Human Genome Research Institute launched The Cancer Genome Atlas, a project to collect detailed molecular characterizations from 11,000 tumors, among other data. By the end of fiscal year 2014, some 2.5 petabytes of data will have been collected.

That’s surely a good thing, but here’s the catch: Only researchers at the wealthiest institutions can afford to access it.

“It costs millions of dollars to store that much data, even before you put in the computing resources to analyze it,” Komatsoulis explained — and that’s to say nothing of how long it would take to download the data from the Genome Atlas repository even under the best bandwidth conditions. It’s a download you’d measure “with a calendar, not a stopwatch,” he pointed out.

The Cancer Genomics Cloud

Enter the NCI’s proposed Cancer Genomics Cloud, an effort now being planned not just to make this treasure trove of data available to researchers at a more reasonable cost but also, on a higher level, to democratize that access.

“The situation right now is that if a smart graduate student comes along with a good idea, they have to go to their institution and ask for a couple million dollars in IT equipment and then take a year to get an answer,” Komatsoulis said. “That’s not where we want to be.”

Toward that end, the NCI has issued a Broad Agency Announcement for three Cancer Genomics Cloud pilot tests, for which it plans to award contracts this year. Those pilots will then be evaluated and used to figure out what a production scale cloud would look like.

The overriding goal for the cloud-based initiative is that researchers will be able to access the data via a Web browser and analyze it remotely. A standard application programming interface and analysis tools are planned to help make that happen.

Open Source Licenses

While it’s too early to say what types of technologies might be involved in the end result, the NCI began with a relatively open approach, including tapping the IdeaScale crowdsourcing platform for public input on the technology’s requirements.

It’s also chosen not to constrain the technology solution, so that public clouds, private clouds and/or dedicated hardware using open or closed source can all be acceptable.

“We are tech-agnostic,” Komatsoulis explained. “We’re asking groups out there to propose their best tech solutions, and we’ll see which work best.”

That said, however, there is a requirement that designs be released to the government under a non- viral open source license. Any new software must be developed and distributed under a non-viral open source license as well. Commercial items will be permitted as long as they are available under standard commercial terms.

The NCI wants to ensure that any third party can build a replica of any of the clouds if that design meets their needs, Komatsoulis noted. It also wants to see the clouds developed as pre-competitive technology that can be reused for commercial or non-commercial, open or closed source derivative works. Avoidance of vendor lock-in is another goal.

A Significant Role

Cloud computing represents “a way for large enterprises and service providers to reduce IT waste and increase speed and efficiency, so it is no surprise to see the NCI doing the same thing, particularly as it confronts the vast amounts of Big Data involved in its work,” Jay Lyman, senior analyst for enterprise software with 451 Research, told Linux.com.

“In terms of open source software, it has taken time for open source to become part of the health care and research technology, but it is increasingly on the radar of health IT organizations,” Lyman added. “In addition, the NCI work involves cloud computing and creating an efficient API, which means open source software will likely play a significant role since it is a huge part of cloud and API creation, management and integration.”

Ultimately, the NCI’s overriding goal is to create a brighter future for those afflicted with cancer.

“The nation’s cancer patients shouldn’t have to wait because of technological limitations,” Komatsoulis concluded. “While this won’t remove all the limitations, I think it will be a good start.”