Tensegrity

So, this morning my alarm clock was inexplicably set to the central time zone and consequently I arose 2 hours before my regularly scheduled time. Unable or unwilling to go back to bed after my morning "get ready for work" rituals, I settled down to read a few articles from my RSS feeds. The first one I read was a rather odd post on Distributed OSGi - Tilting at Windmills by Roger Voss. Laughing a bit as I read the opening paragraph, I didn't think much more about the post as it really had nothing to do with what the OSGi RFP 119 "Distributed OSGi" really is about. Fortunately or unfortunately, several people started peppering me with tweets, IMs and emails asking if I had read the post in question and what were my thoughts about it. So, here they are.

Basically, I'm not really going to defend the OSGi EEG RFC 119, "Distributed OSGi" as my own interest in the matter rested largely with the acquisition of the so called "registry hooks" which allow infrastructure developers such as myself to hook into the queries of the OSGi service registry and do cool things like manifest services on demand. Once this capability was present and decoupled from the 119 RFC, I felt I had all the tools I needed to do any damn thing I wanted to, regardless of what the 119 RFC was doing. (for background as to how I fell in love with the idea of the registry hooks, see my posts on remote OSGi, which predated the RFC 119 here and here and a post during the formulation of the RFP which led to RFC 119 here)

Continue reading "Distributed OSGi - On The Scent Of Red Herrings" »

Well, after my last blog entry regarding Sun and JSR 277, I received a visit from the enforcers of that fine establishment. Wearing heavy overcoats on a nice sunny day, the elevator door opened and they came rushing out. Like a scene from the Matrix, it seemingly took them forever to pull out their impossibly huge automatic weapons they had hidden under the black leather trench coats. In only several hundred milliseconds, Sun's professional enforcers unloaded 20 or 30 pounds of lead in the form of hundreds upon hundreds of rounds of high powered ammunition into what used to be my body, splattering my physical essence across the interior of the reception area of building 200 on the Geidi Prime campus.

Or not. Rather, what did happen was Alex and Stanley showed up at my office escorted by a fellow member of House Harkonnen and after a slightly awkward moment with Stanley (I had, after all, just blasted across the internet - with the awesome power of my blog - stating that he was an idiot), Stanley and my compatriot excused themselves to work on JSR 277 related specification business leaving Alex Buckley and I in my office, as I watched him finger a menacing looking lead pipe that he pulled from his brief case.

Or not. Rather, we sat down and talked comfortably for quite some time about about everything but the issues surrounding JSR 277 and the reason why Alex even knew of my existence. Eventually, however, we directed the conversation towards the actual issues we really needed to discuss and left the safe domain of my Dr. Who toy collection and the pleasantries of traveling through Heathrow in the U.K.

Continue reading "My Dinner With Andre" »

Stanley Ho shows up for another meeting of the JSR 277 Java Modules Specification with a brand new versioning scheme

Stanley Ho, working on the Java Module System (formerly known as JSR 277) has decided that Sun is so smart that they need to invent yet another versioning system. Now, maybe Stanley Ho really is a super smart dude who makes me look like I was a fifth rate, multiple generation inbred dufus from the white trash mountains of Virginny (many, many people have actually pointed that I actually am a fifth rate, multiple generation inbred dufus from the white trash mountains of Virginny, but I digress), but it seems to me that it is self evident that versioning is what we in the business know as a HARD PROBLEM^tm. And to think that someone even as super intelligent as those people at Sun are known to be will come up with a scheme that doesn't have any unintended consequences that were not foreseen by even their Spice^tm enhanced brains is simply something that I think you'll find many in this industry simply can't conceive.

There will be bugs in what Stanley has designed. There will be unintended consequences. It will only be after years of serious use and abuse by many hundreds of thousands of developers in real world situations that even the Spice^tm enhanced mind of Stanley Ho hasn't dreamed of will the full extent of his hubris become clear.

One might ask the question: "Why, Stanley, didn't you use the OSGi versioning scheme?".

<crickets chirping>

This shit is hard. This path is fraught with peril. In the 21st century, we simply don't go around inventing shit for the hell of it simply because we can. We reuse existing things even though they might not be the correct shade of purple we were dying to have. Simply because the corners are a bit worn.

The absolute last thing we need from Sun in the Java Modules is Yet Another Brilliant Sun Shiny Invention that we'll have to suffer though for years until all the bullshit is extracted from the hubris that went into creating.

Geebus. Please. Dear God. Please.

Stop the madness. Someone please hold an intervention with these people. The industry simply cannot stand to have this crap thrown at them, especially in something as fundamental and as far reaching as the frickin' base Java module system.

See Peter Krien's rant on the hubris that is Stanley Ho.

Sometimes a turd is just a turd

So I finally have what I consider to be the minimum - bare minimum, mind you - bar of the 3rd Space gaming framework finally passed. What I have working is a Predator/Prey simulation using the Boid rules for modeling flocking behavior. Boids were invented by Craig Reynolds to model the flocking behavior we see in birds, fish and other herd animals. The rules in Boid are actually butt simple and all local - i.e. simulating the flocking behavior only relies on the emergent behavior of the individual's action, not some "higher authority" guiding the individuals, keeping them in formation.

In any event, what you find if you look for any Java code which implements Boids, the seeming universal implementation is to actually keep a global list of the boid positions - i.e. an implicit "global" which really shouldn't be present. The reason why this is so is, of course, because Area Of Interest management (AOI, for short) is a tough thing to do, even if you are simply running the simulation in a single process.

I really needed a non trivial simulation to use as the driver test case for the 3rd Space gaming framework I've been working on. Flocking behavior is, as one expects, quite common in games and is something that the human players do quite frequently as well - they don't call humans sheep for nothing. As it turns out, managing the area of interest for simulated entities and human's avatars is rather difficult precisely because of this tendency to flock. Moving, flocking simulated entities is therefore the de facto test case that one should be using as a model when developing the basics of a large scale, distributed simulation and gaming infrastructure - i.e. if you can't handle this, then you have no hope of handling anything more complicated.

So, it's kind of cool. I now have a non trivial simulation which runs under both the event driven framework and makes use of the voronoi based AOI management. Next step is to now distribute the simulation using Coherence so I can see how well my theories of how to massively scale this framework will work.

(Part I - Preliminaries, Part II - The Long Kiss Goodnight)

<sigh> Sorry. I tend to talk more about the surrounding atmosphere than the thing itself. In this post I hope to remain focussed and actually discuss the actual meat of the architecture and the skeleton upon which it is based. Apologies for not providing the color and fluff of life that actually surrounded the process ;)

Point 1 Humans are good at making declarative statements and woefully incompetent at micromanagement.

This is one of those points that one shouldn't have to make, but the simple fact that bears repeating is that Humans are really good at figuring out what should be done, but really shitty at actually - you know - doing what they think should be done. In keeping with the spirit of the theme of this post, I leave it to the reader to reflect upon the profound reality that it is far easier to see the goal than the path to it. The profound insight I have (not singular, as I'm sure you're aware) is that a management system which caters to the micro-manger who actually is competent at orchestrating a complex series of transformations under chaotic conditions are few and far between - so rare as to be non-existent to several orders of approximation (or so expensive, which amounts to the same thing).

The take away is simply that any system which depends on a human to do the actual work is simply not going to work - by definition. Seeing as how this is one of my premises, it's not something I can really argue. It's a premise derived by years of observations of not just other humans but also myself. Again, I'm not making the claim that there are not humans who are absolutely brilliant at micro-managing large scale distributed systems - let's be crystal clear on that point. No. My point is simply that these people are incredibly rare and you - the actual person paying the price - will have to pay through the nose if you find such a person. And, quite frankly, the chances of you actually finding such a person is so miniscule as to be almost unmeasurable. Most likely, what you'll do is find someone who claims to be such a person or someone whom someone you trust claims to be such a person. And the odds are overwhelmingly that you are just a complete maroon and have been hoodwinked into paying a lot of money for a cheap imitation of such a being. Get used to it. It's just a simple fact of reality.

Continue reading "Event Driven Autonomic Management - The First Cut Is the Deepest" »