Here’s my experience using the Ripple emulator for BlackBerry WebWorks.

There’s a bunch of awesome BlackBerry developers at the hackathon, but I’m determined to work this out without them walking me through it. After all, developers don’t normally have the opportunity to ask directly for help. And this way I get to discover all the dark corners of the BlackBerry developer experience.

Again, Ripple comes as a non-native installer. This time, the installation goes into /Applications/Research in Motion/ – I would prefer to have everything in /Developer/SDKs/Research In Motion/ so everything is in one consistent place. Or, since Ripple is an emulator for more than just WebWorks, just leave it in /Applications but drop the “Research in Motion” folder. And tidy up the app so the resources are all inside the app bundle. Basically, follow Mac best practice.

Launching the Ripple emulator application the first time results in a prompt in the middle of the screen, asking what platform you want to emulate:

Selecting “WebWorks” results in a a huge emulator window with the device running off the bottom of the screen – this on my Macbook Pro running at 1680×1050. Are mobile screens really so big?

In discussion with some folks at the hackathon, it turns out the Windows version of Ripple has the option to scale the UI, but not in the Mac version.

I’ve got my packaged app from the previous exploration of creating a WebWorks app, but there doesn’t seem to be an obvious way to load it into the emulator.

Reading “Packaging your app with the BlackBerry WebWorks SDK” tells me about the different formats of files I discovered when creating my own app:

• .cod file for wireless distribution or distribution from a web page
• .alx file for distribution using BlackBerry Desktop Manager
• .jad file for distribution from a web page
• .cso file for application signing
• .csl file for application signing

Apparently there’s also a .bar file for a BlackBerry tablet. I can’t help but feel I’d like a single fat package for all eventualities.

There’s instructions on running your application on a smartphone simulator, but the simulator is a VM and does not appear to be the Ripple emulator.

Reading Packaging your app in Ripple, you can package from within the emulator. You have to click the tiny wrench icon in the top-right corner of the emulator window. This should be much more prominent if this is a common task.

Unfortunately, clicking on the wrench prompts me for lots of configuration: SDK path, Project Root, archive name … all as text fields, and not file/folder pickers. There’s also no support for tab-completion of paths in the fields, so you’ll have to enter them long-hand:

Given RIM only recently acquired Ripple, I’ll cut them some slack. But I’d like to see for example a wrapper script that launches Ripple with all the correct configurations for SDK, project, etc.

The settings for smartphones are on the packaging page.

I’m guessing that my settings should be:

• SDK Path: /Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9
• Project Root: /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/UIExamples
• Archive Name: UIExamples
• Output Folder: /tmp/Ripple

Trying with these settings, I got the familiar config.xml not found error:

Tweaking the settings,

• SDK Path: /Developer/SDKs/Research In Motion/BlackBerry WebWorks SDK 2.3.0.9
• Project Root: /Users/savs/Downloads/blackberry-WebWorks-Samples-0a5693e/ProjectRoot
• Archive Name: UIExamples
• Output Folder: /tmp/Ripple

That worked:

I ended up with UIExamples.zip inside /tmp/Ripple, and an “OTAInstall” folder and a “StandardInstall” folder.

The OTAInstall folder contains UIExamples .cod files, split into ten separate packages:

Apparently this is for backwards-compatibility reasons, with only packages of ~60k or less being allowed for an OTA install. This means that, when you deploy to a phone, you get to watch 10 different packages being installed before your app is ready for testing. Ouch.

Now I’ve build the packages, it’s not clear how to actually use the built application. The “Package and Launch” menu option is greyed-out.

Looking at the settings screen again, at the bottom beside Simulator it says “No simulators found “.

During the hackathon, the network failed. This results in some fairly unhelpful problems with Ripple, where you’ll see a blank loading screen for a long time followed by an error message:

This all went away when the network came back.

Reading the docs suggests another way to view your app in Ripple is to stick it on a web server and point Ripple at that. If you’ve got a local server, the benefit is a much quicker development cycle, without having to go through the packaging process first. Indeed, this did work and allowed me to see my app:

The downside on a Mac is that you can’t easily symlink your content from the web root to your development location (at least, not without making a ton of parent directories more widely accessible). See Creating a symbolic link in Sites directory on StackOverflow for more details.

Anyway, success of sorts: I got my app packaged, and I got to view the development files via HTTP.

Next up: signing.

Inevitably, there’s been a lot of chatter about the Nikon D800 today and it ranges all over the spectrum. In addition to showing up all over the web, it’s also invaded my inbox. “Dude! There’s so many megapixels!” is one common refrain. “Dammit, they didn’t make a stripped down D4 this time!” is another. Me, while I have a love/hate relationship talking about gear—in large part because so many people think it’s just about the gear—I have to say that I’m pretty stoked by the D800. I think a lot of good photographers are going to put this camera to excellent use.

Here are some snippets from conversations I’ve had about the new camera today:

I’m ready to make the jump to full frame. Should I get a D4 or a D800? First off, the price difference between the two cameras should answer this for a lot of people. If that doesn’t immediately answer it for you, the way I see it is that the D4 is a heavy, rugged, no-compromise camera that lets you work fast, get the image, and be able to use it for publication. The need for speed and grace in challenging-light conditions trumps the need for maximum resolution. The lighter D800, on the other hand, is geared for everyone else and trades off frame-rate and low-light prowess for resolution. Between the two, most people should get the D800.

But I wanted a reasonably sized full frame low-light champ and don’t need all that resolution! The ultimate noise characteristics of the D800 have yet to be determined and I won’t pass my own judgement till I see a lot of test results both on screen and in print. I’ll be surprised, however, if the resulting images don’t look as good as D700 images in the same light conditions when viewed at normal usage sizes from a noise and image-quality perspective.

That said, the D700 is still an amazing low-light camera and the introduction of the D800 doesn’t immediately stop it from making great images. If you can find a good deal on a gently used one, maybe you should consider one?

Those big files are going to stress our computers and storage, aren’t they? Yeah. They will. They’ll eat up space on disk faster and Aperture and Lightroom won’t move as fast as they do with 12 megapixel images. The sad fact is that while folks using word processors have already been taken care of by Moore’s law, we photographers can still use a bit more help. Considering the impact to your workflow goes part and parcel with looking at a camera like this.

I downloaded a sample and at 1:1 it looks like… You really need to stop that thought right there. I know, the first thing many people do when we load up an image is zoom to actual pixels and peep. I confess, I do it too. But, do the math and you’ll find that when you zoom a D800 image to 1:1 on your screen, you’re looking at a small crop of a photograph that’s over 6 feet wide. The only person that is really going to ever see your images that way is you.

Furthermore, comparing 1:1 views of images from cameras with different resolutions will tell you different stories by definition. To really compare different cameras in terms of the kinds of images they make and how useful they are in different shooting conditions, you need to display or print at the sizes that you’ll use them at. Compare at them full screen or print ’em out at a decent size. That’s the only valid way to do it.

36 megapixels! That makes medium format digital obsolete! Not so fast. There are other aspects of medium format beyond simple resolution. The sensor size and the impact it has on the final image is the biggest. The great set of medium format lenses and their unique characteristics is another. Yes, the D800 stretches what a 35mm SLR format camera can do to a higher realm, but cameras from PhaseOne and Hasselblad will still have a place.

You’ll have to use impeccable technique to get good results, won’t you? Well, yes and no. It’s true you’ll notice the sins of your technique more when you zoom into a D800 image than one from a D700. Any camera shake blur will be much more noticeable at 1:1. But, again, 1:1 isn’t reality. Use equivalent technique on a D700 and a D800, print both images at 8x10, and you’ll see equivalent results. That’s not to say that technique won’t matter. It will demand very good shooting technique (not to mention incredible lenses) to get the maximum benefit from what the D800 sensor can give you. But shooting the same way as you always have, your images won’t suddenly get blurrier when you shoot with the D800. You’ll just have more headroom to improve your craft and achieve a sharper result than you’ve seen before.

Lenses? What about lenses? I’ll have to get… Stop right there. I know where you’re going with this. The same argument applies. While you’ll certainly be able to better see what your lenses are capable of when pixel peeping, the D800 won’t make your existing lenses any worse.

Look at it this way. When digital photography first came on the scene in a big way, resolution was limited by what the sensor could provide. Over time, the gap has closed and now we’re at the point where lenses are quite often the limiting factor. With the D800, we’re probably going to see the limits of a lot of lenses. That’s not a bad thing. It’s just part of how everything interacts. It doesn’t require you to go out and replace all of your glass unless you want to win a competition of resolving resolution charts.

OMG, this camera is so much better than my 5D! Should I abandon my Canon kit right now? Probably not. The replacement for the 5D Mark II is certainly on its way and it’s certainly going to be in the same ballpark as the D800. I expect that while one will be better than the other in some ways, it’ll be close enough to be a wash. The only big question mark is whether or not Canon will finally stop putting a crippled AF system into the 5D.

Speaking as somebody who has made the expensive and time-consuming change over from Canon to Nikon, I gotta say that you need to have a clear and present need for it to make any kind of sense. If you have that kind of need, you know it. If you don’t know that there’s a specific reason to make a jump, then don’t ask the question.

This moiré stuff sounds scary. Should I get the D800E or stick to the regular one with the anti-aliasing filter? A lot of commentators are quick to point out the potential problem with moiré, especially with textiles, when there’s not an anti-alias filter in the mix. It’s true. Moiré can happen without an anti-alias filter. Talk to somebody with an M9 or an X100 if you want to hear from somebody’s experience about how often it happens.

If you don’t know much about this issue or don’t want to faff about with it, just get the regular D800. Seriously. Don’t worry about it. If, on the other hand, you’re well educated about what’s going on, then you know enough that you’re probably not asking the question.

But really, I just wanted a D700S with the D3S sensor! Ok, fine. Go talk to Nikon about it. Or, you could always wait and see what comes up next. There’s an obvious gap between the D7000 and the D800 that’s going to get filled. The question is whether that will be a DX or a FX camera. It’ll probably be a DX camera, but I could see Nikon start pushing FX further down the line.

Are you getting one? Why yes, I am. I went with the D800E, if you must know. I adore the D3S, but there’s many a time have I longed for a D700-sized body again for travel. Especially when I’m hiking up a hill. And yes, I’ll be sure to let you know what I think of it when it arrives.

All of that said, remember that gear is just one part of the equation. The person that uses it and their skill set is by far more important. Just as a super awesome knife won’t make you a competent chef, a fancy-pants expensive camera won’t make you a competent photographer.

Posted by James Duncan Davidson.

BasicAWSCredentials awsCredentials = new BasicAWSCredentials( AWSAccessKeyId, SecretAccessKey); AmazonEC2Client ec2Client = new AmazonEC2Client(awsCredentials); ec2Client.setEndpoint(ZONE); List<string> instancesToTerminate = new ArrayList<string>(); instancesToTerminate.add("i-0749ea42"); instancesToTerminate.add("i-3353ea16"); ... TerminateInstancesRequest term = new TerminateInstancesRequest(); term.setInstanceIds(instancesToTerminate); ec2Client.terminateInstances(term);

This isn’t so much about access control lists in Solr or Lucene but more about access control lists in an inverted index in general. The problem is as follows. We have a large set of data that is access controlled. The access control is managed by users and they can individual items closed or open or anywhere between. The access control lists on the content, which may be files, or simply bundles of metadata is of the form 2 bitmaps, representing the permissions granted and denied, each pair of bitmaps being associated with a principal and the set of principal/bitmap pairs associated with each content item. A side complication is that the content is organised hierarchically and permissions for any one user inherit following the hierarchy back to the root of the tree. Users have many principals through membership of groups, through directly granted static principals and through dynamically acquired principals. All of this is implemented outside of the Solr in a content system. Its Solr’s task to index the content in such a way that a query on the content for an item is efficient and returns a dense result set that can have the one or two content items that the user can’t read, filtered out before the user gets to see the list. Ie we can tolerate a few items the user can’t read being found by a Solr query, but we cant tolerate most being unreadable. In the ACL bitmaps, we are only interested in a the read permission.

The approach I took to date was to look at each content item or set of metadata when its updated, calculate a set of all principals that can read the item and add those principals as a multivalued keyword property of the Solr document. The query, performed by a user computes the principals that the user has at the time they are making the query, and builds a Solr query that gets any document matching the query and with a reading principal in that set. Where the use of principals is moderate, this works well and does not overload either the cardinality of the inverted index where the reader principals are stored in Solr or the size of the Solr query. In these cases the query can be serviced as any other low cardinality query would be, by looking up and accumulating the bitmap representing the full set of documents for each reader principal in turn. The query then requires n lookups and accumulate operations, where n is the number of principals the user has, to resolve the permissions part of the query.

However, and this is the reason for this post, where this fails is where the cardinality of the reader principals becomes to high, or the number of principals that a user has is too high. Unfortunately those two metrics are connected. The more principals there are in a system, the more a user will need to access information, and so the reader principal mechanism can begin to break down. The alternative is just as unpleasant, where the user only has a single principal, their own. In those scenarios active management of ACLs in the content system becomes unscalable both in compute and human terms, which is why principals representing groups were introduced in the first place. Even if there were not limits to the size of a Solr query the cost of processing 1024 terms is prohibitive for anything other than offline processing.

Image via Wikipedia

One solution that has been suggested is to use a Bloom filter to represent the set of principals that the user has and test each indexed principal against this filter. If this is done as part of the query, as the result set is being created there is no gain over scanning all documents since the inverted index would not be used. There could be some benefit in using this approach once a potential set of documents is generated and sorted, since the cost of performing sufficient hashes to fill the appropriate set of bloom buckets is low enough that it could be used as a post query filter. I think the term in Solr is a Collector. In this scenario we are already verifying the user can read a content item or its metadata before delivering to the user, hence its acceptable to have a less that perfect set of pointers being emitted from Solr, provided that the set of pointers we retrieve is dense. We can’t afford to have a situation where the set of pointers is sparse, say several million items, and the only item the user can read is the last one. In that scenario any permissions checking performed without the benefit of Solr would be super expensive.

So, the Bloom filter applied within Solr has the potential to be able to filter most result sets rapidly enough to create a result set that is dense enough for more thorough checking. How dense does it need to be and how large does the bloom filter need to be ? That is an open-ended question, however if, on average you had to read 20% more elements than you returned that might not be excessive if results sets were generally limited to no more than the first 100 items. If that’s the case then 80% density is enough. Bloom provides a guarantee of no false negatives but a probability of a % of false positives, ie items the a Bloom filter indicates are present in a set, but which, are not. For classical Bloom filters 20% is an extremely high probability of false positive, certainly not acceptable for most applications. It has been reported in a number of places that the quality of the hash function used to fill the buckets of the filter is also of importance in the number of false positives since an uneven distribution of hashes over the number space represented by the Bloom bitmap will result in inefficient usage of that bitmap. Rather than doing the math which you will find on Wikipedia, knowing that all fast hashes are less than perfect, and being a pragmatist I did an experiment. In Apache Hadoop there are several implementations of the Bloom filter with 2 evenly distributed and efficient hash functions, Jenkins and Murmur2, so I have used that implementation. What I am interested in is how big a filter would I need to get 80% density to a set of results and how big would that bitmap need to be as the number of inputs to the bloom filter (the users principals) rises. It turns out, that very small bitmap lengths will give sufficient density where the number of input terms is small, even if the number of tested principal readers is high. So 32 bytes of Bloom filter is plenty large enough to test with < 20 principals. Unfortunately however, the cardinality of these bitmaps is too high to be a keyword in an inverted index. For example, if the system contained 256K principals, and we expected users on average to have no more than 64 principals we would need a bloom filter of no more than 256 bits to generate, on average 80% density. Since we are not attempting to index that bloom filter the cardinality of 2^^256 is not an issue. Had we tried to, we would almost certainly have generated an unusable inverted index. Also, that Bloom filter is constructed for each users query, we can dynamically scale it to suit the conditions at the time of the query (number of items in the system, and number of principals the user has). Real system with real users have more principals and sometimes users with more principals. A system with 1M principals that has on average 1024 principals per user will need a bloom filter containing about 8Kbits. Its certain that adding a 8Kbit token ( or a 1Kbyte[] ) as a single parameter to a Solr query circumvents the issue surrounding the number of terms we had previously, but it’s absolutely clear that the cardinality of 2^^8196 is going to be well beyond indexing, which means that the only way this will work is to post filter a potentially sparse set of results. That does avoid rebuilding the index.

From this small experiment I have some questions unanswered:

• Will converting a potentially sparse set of results be quick enough, or will it just expose another DoS vector?
• What will be the practical cost performing 100 (principals) x 20 (I was using 20 hashes) into an 8kbit filter to filter out each returned doc item?
• Will the processing of queries this way present a DOS vector?

Last weekend was FOSDEM and it was a blast! Camila's first and I get that she didn't look forward to it that much - we had some trouble on the way there. As I'm now just on the way to the airport to pick her up (she had a meet-up with some KolabSys people) I dunno if she changed her mind but I bet she did. If only because she got some Brazilian beans from Izabel Valverde ;-)

For me it was the usual - there was little visiting of talks for me. Seriously, 200 hours of talks in 2 days? Attempting to visit the interesting ones just leads to frustration so I've given up on that. There are just too many people to talk to, too much beer to drink and sell and little catch-ups to have. FOSDEM needs to become a week-long event. Seriously.

A cool highlight of FOSDEM was of course the release of Lydia's awesome Open Advice project. It's a book for people who want to participate and make a difference in Free Software, explaining our culture and drawing upon some bright minds for real-world experiences. It is quite a read - I only got as far as the introduction by ex-FSFE Dude Georg Greve and some first paragraphs of a few chapters. But it's worth it if what I've read is any indication. Of course, in true Free fashion, it's open and even ready to edit and improve if you want!

There was a lot of fun around the openSUSE crowd as usual. The crew did a great job selling t-shirts, hats, beer and other stuff all for the benefit of FOSDEM (we donated the proceeds of the sales as usual). The awesome 'Old Toad' beer was as popular as ever - it is indeed a great beer and a good way to keep the fun alive. The Greek(o)s really drove this part as they must've drunk at least half our supply ;-)

Oh and after being pressed Frank promised that he'll ensure ownCloud has a good booth next year. So, ownCloudies (can't think of a better name atm) - you guys & girls really have to take that dive in 2013!!! Don't let Frank pull it alone. Not that His Baldiness can't do that, it's just that he'd look lonely. We can't have that.

And at night the usual great dinners - Thai food one night, Japanese Tepan Yaki or something (fiery, dang) another. Finishing it off properly with a few beers.

By the way, I've set up the LinuxTag wiki page for the openSUSE gang, sign up!

hugs,
Jos

I am incredibly honored to have been selected to speak at the upcoming DrupalCon Denver on the topic of International NGOs Leveraging Drupal for Social Change. 

As part of the amazing support in the Drupal Community, all presenters have been requested to attend (or watch recordings of) webinars on how to give good presentations, led by Emma Jane Hogbin of Design to Theme.

Below is a summary of the two hour-long videos, which I initially intended as personal notes, but later realized others might find useful as well.

read more

• lrzip : ‘Lrzip uses an extended version of rzip which does a first pass long distance redundancy reduction. The lrzip modifications make it scale according to memory size. [...] The unique feature of lrzip is that it tries to make the most of the available ram in your system at all times for maximum benefit. It does this by default, choosing the largest sized window possible without running out of memory.’
  (tags: zip compression via:dakami gzip bzip2 archiving benchmarks)

Last year I officially went independent, turning Logrus into a boutique consulting shop specializing in the skills and knowledge I have to offer big players in the Drupal world. So far, things have gone fantastically well and it has allowed me to branch out a little more in the things I do, and has also helped fund several awesome projects that will benefit the community. Notably the Panelizer, Fieldable Panel Panes and ERS modules are completely funded by clients, as well as improvements to Panels such as the pane locking features.

BlogDrupal · DrupalCon

Quite some time ago I wrote a post about how patching makes you feel good in which I talked about the motivations for, and benefits of submitting patches on drupal.org (d.o). I concluded by suggesting that project maintainers should be generous in recognising the efforts of those who submit patches.

Well, now that d.o has its magnificent git infrastructure, project maintainers have even better tools for giving credit to contributors who help fix or improve the code. There is still the well-established convention for commit messages which encourages that "others [who] have contributed to the change you are committing" are credited by name. e.g.

Issue #123456 by dww, Dries: Added project release tracking.

Similar messages are often added to the project's changelog too.

The new tool that perhaps not everyone knows about yet is the ability to assign the authorship of the commit to another user e.g.

git commit --author=[username]@[uid].no-reply.drupal.org

This is appropriate when committing a patch that is entirely somebody else's work. Perhaps some maintainers will be generous and attribute authorship even if they've had to make a few tweaks to the patch, but somebody else did the majority of the work to identify and fix a bug, for example.

When a user is credited as the author in this way, the commit will show up on their drupal.org profile page, which I think many people will feel is a great reward for the time they spent putting a patch together.

There are however some limitations and drawbacks to the system. The committer of the patch is not rewarded by seeing their commit count incremented, which some may find a disincentive for generosity in attributing authorship.

Where the maintainer might split the credit in a commit message for a fix where a user was helpful by giving a detailed bug report in the issue queue, but where they themselves had to actually fix the problem, for example, they're probably justified in leaving themselves as the author of the commit. Of course they can still mention the helpful user in the commit message and changelog.

There will surely also be less monochrome cases where authorship of the code being committed should be split between multiple users. As far as I'm aware, the git infrastructure on d.o doesn't cater for this situation, and messy workarounds such as breaking the commit up to split authorship have been suggested.

There are undoubtedly some limitations, and project maintainers will occasionally find themselves with tricky decisions to make. However, for the reasons I detailed in my patching makes you feel good post, I really encourage maintainers to be generous with the credit when it comes to patches which have been submitted in issue queues, and the option to set an author for a commit in git is a great way of doing so.

Sometimes the decision of how a program should behave is not right or wrong technically but based on the user expectation.

In Okular we are asking ourselves what should happen when you have two lines with the following text

This is an ex-
ample

and copy it. Should it return "This is an ex-\nample" or "This is an ex-ample" or "This is an example"?

Head over to the KDE forums and vote!

So I've been playing with cutting down OpenGLContext into something like a modern scenegraph engine.  The first step there is to eliminate the old tree-traversal rendering mechanism, as the "flat" rendering engine is both simpler and much more easily optimized.  No big problem, really.  A lot of OpenGLContext's demos/tests just ran with only minimal changes, a few of the very old ones were using the customization points (e.g. Background) that were dependent on the old rendering model, but they could generally be ported to the new model by moving a few lines of code into their "Render" method.  The surprising corner case was one of the most recent tutorials, namely shadows.  As I was writing that tutorial I took a shortcut by using the legacy visitor in the middle of the rendering process to traverse and output the geometry for each sub-pass, and the modifications to the flat renderer mean that the "Context" is now a rendering node... which means the flat renderer includes it in the set of things to render when I do a query on the scenegraph for what should be rendered... queue infinite recursion.  Oh well, gives me something to work on tomorrow .

Sometime, when moderating some Apache mails, you find jewels like this one :


LinkedIn
------------

Apache,

I'd like to add you to my professional network on LinkedIn.

- Chris

Chris XXX Lead XXXXXX Technical Recruiter at YYYYY
San Francisco Bay Area

FOSDEM 2012 was very nice, as expected.

This year, I decided to stop consuming only and getting more involved. I helped staff the token sale and held two Lightning Talks. This turned out to be an awesome experience.

During the beer event, we sold 4600 beer tokens (FOSDEM does not earn anything from this; all proceeds go to Cafe Delirium). The sale was staffed with one to three people at all times which made for a constant but mostly bearable workload. While the others made good-natured fun of me and my German efficiency, I like to think that I helped make things run a tad more smoothly. Along those lines, we will have a sign asking people for exact change and/or to buy stacks that can be paid in bills if possible, next year; that should help streamline the whole thing even more. All in all, it turned out to be quite stressful, but tons of fun. I am looking forward to chuck in again next year.

The two Lighting Talks (vcsh on Saturday and git-annex on Sunday) I held very rather well received. Feedback after the talks and online was very positive which is always nice. There's been a slight increase in help requests and generic questions, so I assume people are trying vcsh and git-annex as a consequence of those talks, which is even nicer.

Also, I met a lot of people. Most of the meetings were pre-arranged, some by chance. Carrying a name tag at all times, I was approached by several people who knew me online but didn't know my face. I will try to always carry a name tag on conferences now and I suggest others do the same.

Finally, a huge thank you to everyone who helped make FOSDEM happen; you rock!

At the end of a long day here are some photos from KDE at FOSDEM 2012. Pradeepto says "3.24 AM here, am in office, those pictures made my day/night/whatever itis now".

KDE Love as Claudia sells t-shirts

Paul demos KDE Software on every form factor: mobile, tablet, desktop, Windows, cloud and server.

Corridor chat with Frank

Cross-Desktop room group photo (missing lots of people who were at other talks)

KDE dinner - had to turn away quite a lot of people who were too late to get a seat. I may be concussed but I'm still able to herd KDE cats better than anyone else did.

A business man pose from Paul

Lydia Launches the Open Advice book on which I am a contributing author

FOSDEM reminded me why I love KDE, great people and friends working on great technology.

There appears to be some confusion regarding the meaning of yesterday’s announcement that Kubuntu 12.04 is going to be the last release Canonical is offering commercial support for.

For those who have not yet read about it, let me quickly recap the situation. Up until now Kubuntu was a Canonical supported flavor of Ubuntu. This essentially means that you can buy a support contract from Canonical to help you with your Kubuntu infrastructure. Every once in a while Canonical would stamp ‘LTS’ on a Kubuntu release to indicate that they would support this release for 3 or 5 of years to come (delivering security and major bug fixes primarily). The upcoming 12.04 will be the last release for which Canonical offers these services. As a direct consequence Jonathan Riddell, a good friend of mine and fearless leader of Kubuntu, will work on other technology during work hours.

You might have noticed that I was writing a lot about Canonical just now, and the reason for this is that the change mostly is about Canonical and not Kubuntu.
Kubuntu is and always has been a mostly community driven project. To give you an idea what mostly means in this case: out of the 25 people who notably contributed in the past year, 1 person was employed by Canonical to do so (i.e. 4% of general Kubuntu work was financed by Canonical). Please do not get me wrong though. Jonathan is a great developer and does a considerable amount of work, particularly in those areas where the community currently lacks motivation, hence some workflow revision is in order to make the ‘new’ Kubuntu equally efficient.

So what changes for real?

• No commercial support from Canonical past 12.04.
• Jonathan Riddell will work on non-Kubuntu stuff during work hours.
• Alignment of Kubuntu with other siblings like Edubuntu, Lubuntu and Xubuntu.
  For those who care: on a technical level this means that a considerable amount of Kubuntu maintained software will be moved from the main to the universe archive.
• Probably some workflow changes that are yet to be discussed.

Is this bad?
It probably is if you wanted to adopt Kubuntu in your company and were counting on a Canonical support contract. However this is probably more of Canonical’s loss than your’s. As noted earlier there is a pool of more than 25 people one could employ directly to get the same result, perhaps even better. It is certainly sad that Jonathan will not be able to continue getting payed for working on his baby though.

Is this good?
Moving to universe bares a great deal of opportunities for Kubuntu. Primarily it gives the community yet bigger control over what the distribution looks like as we do not need to get software approved to be worthy of Canonical’s support. At the same time it also reduces the policy overhead (main inclusion for those who have heared of it). The detanglement allows us to move even closer to KDE without having to worry about conflicting interests, as what is good for KDE is not necessarily what is good for Canonical.
All in all I expect Kubuntu to become more agile and continue to regularly deliver an easy to use Linux distribution featuring the latest and greatest KDE software.

There is an occasional and not very amusing urban myth that Kubuntu is a stepchild of Ubuntu based on the idea that Canonical is not giving the same amount of care to Kubuntu as other flavors of Ubuntu. It’s not true because Canonical has given much more care to Kubuntu than many other flavours. But all those who believe in this myth may now rejoice as the stepchild is moving out and going to share a flat with its much loved siblings \o/

If you ever get this cryptic error when loading an Android native app:

FATAL EXCEPTION: main java.lang.RuntimeException: Unable to start activity ComponentInfo{org.wikibooks.OpenGL/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/data/org.wikibooks.OpenGL/lib/libnative-activity.so at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1768) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784) at android.app.ActivityThread.access$1500(ActivityThread.java:123) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:130) at android.app.ActivityThread.main(ActivityThread.java:3835) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:507) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605) at dalvik.system.NativeStart.main(Native Method) Caused by: java.lang.IllegalArgumentException: Unable to load native library: /data/data/org.wikibooks.OpenGL/lib/libnative-activity.so at android.app.NativeActivity.onCreate(NativeActivity.java:199) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722) ... 11 more

This may mean that Java couldn't find the ANativeActivity_onCreate function in your code, because it was stripped by the compiler.

If you use the native_app_glue NDK module, you may have noticed this strange code:

// Make sure glue isn't stripped. app_dummy();

Let's experiment what happens with and without this line:

Calling app_dummy:

$ arm-linux-androideabi-objdump -T libs/armeabi/libnative-activity.so | grep ANativeActivity_onCreate 000067fc g DF .text 000000f8 ANativeActivity_onCreate

Not calling app_dummy :

$ arm-linux-androideabi-objdump -T libs/armeabi/libnative-activity.so | grep ANativeActivity_onCreate $ # nothing

native_app_glue mainly defines Android callbacks. Since none of them are called directly by your code, the compiler strips the android_native_app_glue.o module entirely. If you use app_dummy however, it embeds it. Fortunately the compiler cannot strip the module on a per-function basis

That's why you need to call app_dummy when using the native_app_glue NDK module.

This looks like a ugly work-around though - isn't there a cleaner way?

If you ever get this cryptic error when loading an Android native app:

FATAL EXCEPTION: main java.lang.RuntimeException: Unable to start activity ComponentInfo{org.wikibooks.OpenGL/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/data/org.wikibooks.OpenGL/lib/libnative-activity.so at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1768) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784) at android.app.ActivityThread.access$1500(ActivityThread.java:123) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:130) at android.app.ActivityThread.main(ActivityThread.java:3835) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:507) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605) at dalvik.system.NativeStart.main(Native Method) Caused by: java.lang.IllegalArgumentException: Unable to load native library: /data/data/org.wikibooks.OpenGL/lib/libnative-activity.so at android.app.NativeActivity.onCreate(NativeActivity.java:199) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722) ... 11 more

This may mean that Java couldn't find the ANativeActivity_onCreate function in your code, because it was stripped by the compiler.

If you use the native_app_glue NDK module, you may have noticed this strange code:

// Make sure glue isn't stripped. app_dummy();

Let's experiment what happens with and without this line:

Calling app_dummy:

$ arm-linux-androideabi-objdump -T libs/armeabi/libnative-activity.so | grep ANativeActivity_onCreate 000067fc g DF .text 000000f8 ANativeActivity_onCreate

Not calling app_dummy :

$ arm-linux-androideabi-objdump -T libs/armeabi/libnative-activity.so | grep ANativeActivity_onCreate $ # nothing

native_app_glue mainly defines Android callbacks. Since none of them are called directly by your code, the compiler strips the android_native_app_glue.o module entirely. If you use app_dummy however, it embeds it. Fortunately the compiler cannot strip the module on a per-function basis

That's why you need to call app_dummy when using the native_app_glue NDK module.

This looks like a ugly work-around though - isn't there a cleaner way?

Almost every server I work with is a virtual machine;  accordingly I like to do one small install with all the packages that I always want [like pam-nss-ldapd, snmp-utils, dstat, etc...] but don't install by default.  Then I make sure VMware tools is installed an operational.  From that point forward I can just clone that one VM and add to it when I want a new instance of something.
The only downside to this is that all the machines end up with the same volume group name: typically VolGroup0 or some such thing.  That's ugly and limits the ability to move volume groups around - these are virtual disks after all.  Renaming a volume group is straight forward:
vgrename /dev/VolGroup0  /dev/Carazon
Text 1: Rename the volume group VolGroup0 to be named Carazon. Hold it!  Now the machine won't boot anymore!  You get the pleasure of rebooting into "Kernel Panic:  blah blah blah".  If you rename the volume group containing the root filesystem and swap space you also have to update that name in two places -

1. In /etc/fstab.  This one is obvious and I usually remember.
2. In /etc/grub.conf.  Otherwise the kernel tries to mount the root file-system using the old volume group name.

Done this so many times... always forget.

&amp;lt;p&amp;gt;&amp;amp;lt;a href="http://www.formspring.me/deepsky28"&amp;amp;gt;http://www.formspring.me/deepsky28&amp;amp;lt;/a&amp;amp;gt;&amp;lt;/p&amp;gt;

Award for the Advancement of Free Software

The Free Software Foundation Award for the Advancement of Free Software is presented annually by FSF president Richard Stallman to an individual who has made a great contribution to the progress and development of free software, through activities that accord with the spirit of free software.

Last year, Rob Savoye was recognized with the Award for the Advancement of Free Software for his contributions to compiler and testing tools, and his leadership of the GNU Gnash project, a fully-free replacement for Adobe Flash. Savoye joined a prestigious list of previous winners including John Gilmore, Wietse Venema, Harald Welte, Ted Ts'o, Andrew Tridgell, Theo de Raadt, Alan Cox, Larry Lessig, Guido van Rossum, Brian Paul, Miguel de Icaza and Larry Wall.

Award for Projects of Social Benefit

Nominations are also open for the 2011 Award for Projects of Social Benefit.

This award is presented to the project or team responsible for applying free software, or the ideas of the free software movement, in a project that intentionally and significantly benefits society in other aspects of life.

We look to recognize projects or teams that encourage collaboration to accomplish social tasks. A long-term commitment to one's project (or the potential for a long-term commitment) is crucial to this end.

This award stresses the use of free software in the service of humanity. We have deliberately chosen this broad criterion so that many different areas of activity can be considered. However, one area that is not included is that of free software itself. Projects with a primary goal of promoting or advancing free software are not eligible for this award (we honor those projects with our annual Award for the Advancement of Free Software).

We will consider any project or team that uses free software or its philosophy to address a goal important to society. To qualify, a project must use free software, produce free documentation, or use the idea of free software as defined in the Free Software Definition. Work done commercially is eligible, but we will give this award to the project or team that best utilizes resources for society's greater benefit.

Last year, The Tor Project received this award, in recognition of its work to fight against surveillance inflicted by increasingly restrictive governments and to improve the safety and wellbeing of all Internet citizens.

Previous winners have included the Internet Archive, Creative Commons, Groklaw, the Sahana project, and Wikipedia.

Eligibility

In the case of both awards, previous winners are not eligible for nomination, but renomination of other previous nominees is encouraged. Only individuals are eligible for nomination for the Advancement of Free Software Award (not projects), and only projects can be nominated for the Social Benefit Award (not individuals).

The award committee has not been finalized, but is made up of previous winners, free software activists and FSF president, Richard Stallman.

Please send your nominations to award-nominations@gnu.org, on or before Monday, November 7th, 2011. Please submit nominations in the following format:

• In the email message subject line, either put the name of the person you are nominating for the Award for Advancement of Free Software, or put the name of the project for the Award for Projects of Social Benefit.

• Please include, in the body of your message, an explanation (40 lines or less) of the work done and why you think it is especially important to the advancement of software freedom or how it benefits society, respectively.

• Please state, in the body of your message, where to find the materials (e.g., software, manuals, or writing) which your nomination is based on.

Information about the previous awards can be found at http://www.fsf.org/awards. Winners will be recognized at an awards ceremony at the LibrePlanet conference tentatively scheduled for March 2012, in Boston, Massachusetts.