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?

• 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)

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

Google's Adam Langley explains why, and this Ars Technica article adds some more context.

As Langley says:

So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.

While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy. The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.

Seems like pretty good reasoning to me.

Biashara Street
February 5, 2012 From WeekendWordsmith.com

Step away from the
odour of bodies and exhaust into a

chutney of cardamom
cinnamon
ginger
garlic

Sacks of
cashews overflow onto
floors covered with boxes,
cartons,
and more heaps of
burlap bags
full of jasmine rice,
basmati rice,
long brain brown rice
from exotic places I
dream of going, some day.

In this quarter mile of
dusty street
are gathered all the spices of the world,

from Sri Lanka,
Singapore,
and far-away San Francisco.

Tea, coffee and
cocoa pods
lend their aroma to the
general cacophony of smells,
discordant, but, somehow

a symphony in a thousand voices.

Knowing that school uniforms
are only a street or two over,

I stand and breathe deeply
of the cloves,
curry powder,
and saffron.

For the Weekend Wordsmith - Chutney

I've been long thinking about an ideal free secure open source OS.

Now here's a tough question I haven't been able to resolve.
I absolutely demand the universal freedom to know.
Yet I do not want the bad guys to take over computers.

I want to be able to hack my computer myself.
I want nobody else to be able to hack it.

How do I achieve both? Where's the balance?
I do not know. If you do know I'd like to hear from you.

Sander Temme wrote:
This situation paints for me the following picture: a tap is running, malware flowing like water into a sieve and onto the floor. The security industry is frantically mopping the floor, trying to stem the flow of malware. They are paid well for their trouble, but meanwhile the expensive rug that represents your business is getting awfully wet. It would be nice if someone could turn off the tap, or design an operating system that doesn’t leak like a sieve

Barrelfish?

A secure OS gotta be capability based.
It's gotta be peformant on multi-cpu boxes.
Barrelfish might be both.

Warning: capability based OS can be really restrictive.
It can be very non free (RMS will hate it).

Remote attestation peformed by a TMP chip is the issue.

BIOS tells the TPM chip the hashcode of the OS. The OS tells the chip the hashcode of your movie player. TPM chip signs the hashcode with a secret key. An MPAA member checks the signature against a database of all TPMs ever produced. If satisfied it provides you with a personal copy of a movie. To watch the movie you need a one-off key. This key is given to you. But the key is itself encrypted. Only your TPM can decrypt it. And your TPM will only decrypt it if correct hash-sums have been provided to it after the last machine restart. Unless BIOS has been broken a 3rd party can really verify what software you're running!

The only reason this is not happening now is that a myriad of drivers are running in kernel mode. It is not possible to check that your particular combination of drivers + OS comply with MPAA requirements.

But with a capability based OS there would be a very small OS core.
And it would be possible to sign it.
The 3rd parties would be able to check that it hasn't been hacked or deny useful services.
The TMP chips would lock us from our own computers!
We would no longer have the freedom to hack, the freedom to know.

Solution?

Programmers of good will should create a practical capability based OS
before commercial vendors do. They should make it so popular that nobody in
a right mind would want to repalce it with a commercial alternative.

And it should be both secure and free.
Free as in GPL v3.
Free as in free to hack.

Both secure and free to hack. That's a challenge. More on this later.

Mathemagician Vi Hart explains why the color pink exists even though pink doesn’t exist in the rainbow. Quote: “Speaking in terms of light, pink should probably be called ‘minus-green,’ because pink is just the leftovers of white light when you take out the green.”

Linked by James Duncan Davidson.

When Nikon released the D3 in 2007, and then the D700 a year later with the same sensor, the distinction between the top two cameras in the line up boiled down to size, build, viewfinder coverage, maximum frame rate, and a few other little niggles. It made perfect sense at the time. Up until the D3, Nikon had been lagging behind Canon in low-light performance and they desperately needed to get that capability to a wider set of users and not just keep it reserved to those that bought the flagship. The fastest way to do that was to leverage the inevitable efficiencies which come with volume production of known tech. Hence a D700 that gave the same image quality but in a smaller and slightly less robust package.

Then came the D3S in late 2009, a nominally minor update which brought an amazing full stop of extra low-light performance. If you needed a camera to make still images in the most challenging light environments on the planet, the D3S was the clear option. Many figured that the D3 to D700 pattern would repeat and a D700S would soon be in the works, but months stretched on and there was no D700S to be seen.

I think the lack of a D700S was a hint of things to come.

The common feature needed in both the D3 and D700 replacements was a set of video features that can compete with Canon’s cameras. After that, however, needs diverge. Making some broad generalizations, the kind of users that gravitate towards a D3 are, by and far, those that need (or simply want) a camera that can take both hard knocks and deliver publishable images in any kind of light. The D3S was a clear improvement in that direction from the D3. A D4 had to continue that mission with no compromise.

A D700 user looking for an upgrade, on the other hand, might be the type that would appreciate or even demand a serious step up in resolution. Resolution may not be the only thing that counts, but all other things equal, it certainly doesn’t hurt. And, given that Nikon wasn’t sucking wind in the low-light performance department any more, well, diverging the primary mission for the two lines would make sense from a market perspective as long as they roughly met the bar set by the D700 at equivalent usage sizes.

Today’s announcement of the D800 following the D4 announcement in January is the crystalization of that divergence. The D4 is the clear successor to the throne for the best photojournalism camera on the planet. The D800 looks like it’s destined to compete head-to-head with Canon’s 5D Mark III (or whatever they end up calling it) on the resolution front. The addition of the D800E—which comes sans-antialias filter—is the frosting on the cake for those looking to wring the last bit of resolution out their Nikkor lenses.

Where does that leave a successor to the D3x, the previous Nikon high-resolution champ in a super-rugged body? I may be crazy, but I don’t think there will be one. There certainly isn’t a good place for one barring some big jump in sensor technology that’s not already on the table.

Posted by James Duncan Davidson.

Thom Hogan is pretty positive on the new D800, as positive as one can be without a copy in hand. The open questions for him are what does the output from high ISOs at display sizes look like—remember kids, 1:1 pixel peeping isn’t how you should be evaluating image quality—and where the heck does Nikon go from here?

Linked by James Duncan Davidson.

I recently attended a keynote address by the CTO of a leading anti-virus firm. His company is fighting the good fight. Having recognized that signature-based malware detection no longer suffices, they have turned to a combination of detection and prevention to find and weed out bad actors. Big Data is crunched in The Cloud to find the malware which is then manually investigated to find out what it does. Once identified, sites serving malware are blacklisted for the benefit of this firm’s customers. The CTO proceeded to show an example of a piece of malware that changed the Windows hosts file to point a list of banking URLs to a single IP address, where one presumes the unsuspecting user would find a rogue copy of their banking website intent on stealing the user’s credentials or worse.

Now, this is only one example of the forty-thousand-odd unique malware infestations spotted in a depressingly short time, but my question is thus: why was a piece of malicious software running (inadvertently one assumes) on behalf of a user allowed to change a system-wide file like hosts? Shouldn’t there be a sandbox for code downloaded from the network that, if it needs to be run at all, prevents it from damaging the underlying operating system?

This situation paints for me the following picture: a tap is running, malware flowing like water into a sieve and onto the floor. The security industry is frantically mopping the floor, trying to stem the flow of malware. They are paid well for their trouble, but meanwhile the expensive rug that represents your business is getting awfully wet. It would be nice if someone could turn off the tap, or design an operating system that doesn’t leak like a sieve.

The signs are that the fortunes of Distributed OSGI are looking good.

Distributed OSGI RI based on Apache CXF (Apache CXF DOSGi RI) has been around for a while, and quite a few OSGI developers have experimented with and built custom applications on top of it successfully.

However, it's been more than a year since DOSGi RI 1.2 has been released and this project has been inactive recently. In meantime, two more Distributed OSGi implementations have been announced by two OSGI heavyweights, one by my colleague JB, and another one by Guillaume Nodet.

Now, as far as Apache CXF DOSGi RI is concerned, we are seeing users asking the questions quite regularly and this is a sign this implementation and the whole idea of the Distribured OSGI is of interest to some OSGI developers, more on it below.

So after getting some of issues reported against DOSGi RI 1.2 for the last couple of months, we have released Apache CXF DOSGi 1.3. Please see the release notes for more information (note there is a minor typo in the release notes, it is CXF 2.5.2 which this release is based upon, not CXF 2.5.1).

The major improvement in this release is that it is now possible to register custom CXF interceptors (pre-configured if needed) as service properties with the underlying JAX-WS and JAX-RS frontends.

WSDL-first approach is also supported now which is a good news for SOAP developers, see this project for an example. Of course, the JAX-RS frontend was trying to offer something similar :-), so a new org.apache.cxf.rs.wadl.location property has been added. Please see this updated page for more information on all the new properties.

If you are an existing user of the DOSGI RI then please try this new release.

If you have never tried it and wonder what is the story with DOSGI then try it too. DOSGI RI is quite sophisticated in that not only the basic endpoint and consumer creation is supported but also a mechanism for the distributed discovery is wired in.

But it is this fact that the OSGI programming model is used to drive the creation of the web service endpoints and consumers which is appealing to some developers and that is what one should focus upon first when experimenting with DOSGi.

If you think about it, the way to create a new web service endpoint or stop the old one in OSGI is typically to deploy a new bundle or stop the existing one from the shell or possibly from the UI management console. I guess it is quite rare that the custom application bundle will deal with updating the bundles itself.

In DOSGI, the creation if web services endpoints and consumers is actively driven by the typical OSGI BundleContext and ServiceTracker calls. If this style of managing the web services indirectly by the custom application registering or looking for OSGI services does appeal to you then DOSGI could become a perfect fit for your project.

In DOSGI 1.3 we fixed some basic blockers to get the project active again. The future releases will likely focus on making the distributed discovery working really well and also on improving the way the custom configuration can be applied.

One more thing which I'd like to mention is that if you are interested in OSGI in general and possibly in DOSGi and looking for a way to get involved in the open-source project and make a difference then please think of contributing to this project.

The slides from my From Dev to DevOps talk at FOSDEM 2012 Brussels are up in Slideshare. The material is also in the Lanyrd page.

The conference was huge, I’ve heard that over 4000 people showed up this year, for this free (as in both software and beer) event, organized on several tracks. Not bad considering that the temperature was between -15 and -6C (5 and 23 Fahrenheit) and got a lot of snow.

I spoke on the main auditorium with capacity for 1400 people, there was plenty of space. Unfortunately (for me, but great for the other speakers and the organization) some other devrooms got filled quickly, and couldn’t get into the Configuration and Systems Management Devroom, which should have been really good as nobody left as I was waiting outside between talks

A lot of care by the organization, including a note with a 24/7 phone number in case I got “lost/confused/arrested” (which makes me think it must have happened before), and a full commitment to promote belgian beer

And thanks to the people that attended my talk and engaged through twitter, got great feedback and hints for improvements on the future of development and infrastructure automation!

I absolutely cannot stop watching OK Go's newest video: Needing/Getting.

Is it music? Is it art? Is it advertising? Is it promotional marketing (for the band, for the car)? Why, yes, it is! It is all those things.

Most importantly, though, it's a great video!

OK Go set up over 1000 instruments over two miles of desert outside Los Angeles. A Chevy Sonic was outfitted with retractable pneumatic arms designed to play the instruments, and the band recorded this version of Needing/Getting, singing as they played the instrument array with the car. The video took 4 months of preparation and 4 days of shooting and recording. There are no ringers or stand-ins; Damian took stunt driving lessons. Each piano had the lowest octaves tuned to the same note so that they'd play the right note no matter where they were struck. For more information and behind-the-scenes footage, see http://www.LetsDoThis.com and http://www.okgo.net.

There were a number of automobile commercials during the Super Bowl; I loved some (the OK Go commercial, the Fiat Abarth, the Audi vampires) and hated others (post-apocalyptic Chevy pickup trucks, Chrysler's "halftime in America").

What ones did you like, and why?

It appears that winter never came to the U.S.A. this year, but now we know where winter went instead: Europe.

[Copied from my post on G+]

I'm drowning in paper. I'm very definitely in the market for a portable document scanner. (Portable, as in doesn't have to reside permanently on a desk, but not hand-held either. Stick it in a drawer when not in use.)

My ideal solution would work with both Linux and Windows, at least 3PPM, store locally to a removable flash card in JPG, TIFF, or PDF, preferably able to handle multiple stacked input sheets (nice-to-have, not required) and get power from batteries/USB/wall transformer. It would also be TWAIN-compatible for dumping directly to a computer, but could scan without being hooked up.

Oh, and it wouldn't cost thousands of dollars.

Anyone have any suggestions?

Recently query time joining has been added to the Lucene join module in the Lucene svn trunk. The query time joining will be included in the Lucene 4.0 release and there is a possibility that it will also be included in Lucene 3.6. Lets say we have articles and comments. With the query time join you can store these entities as separate documents. Each comment and article can be updates without...