A new future always coming

A mailing list interested in the trading of securities that I participate in had this thread in the last couple days. My reaction after the setup:

There are API's in big languages that encourage adding calendaring systems. Does anyone want me to think about this

I am interested in your ruminations because I think the most difficult thing in statistical trading is not finding edges or whatever. It is getting good synchronized data. This may not be an issue for people restricting themselves to one time zone, and one data provider with one server with consistent time stamps.

The issue is much more complex than this -- and in part it is a 'trading with perfect future knowledge' one; removal of scratched trades, re-ordering away of reporting lags, and the rest are often found in 'historical' datasets. With 'cleaner' data, different trading possibilities, EX POST, seem more obvious.

I have not yet found a broker who will take the other side of a trade against a 'replay' yesterday's data corpus -- I assume they think the temptation for me to cheat and use my perfect knowledge has something to do with it.

The data as and when you see it is all you can derive trading signals from. One can datestamp it in when it crosses your side of the communication demarcation threshold, and 'game' possible responses against a synchronized corpus; After reduction (another delay), an order may leave your plant.

One can simulate what _should have_ happened on orders leaving your plant, but this simplifying simulation usually 'assumes' that the orderbook (of your counterparties) is not affected by your entries, and that it will stand still for your order to arrive. The markets, speed of light, and data communications networks do not and have never worked that way.

I helped in the discussions underlying this piece some years ago, written in connection with a redesign of a major Air Carrier's on line reservation system, spread across the North American continent:
physics of systems design
What was wanted simply could not be obtained with the then-observed speed of light, let alone processing lags. ;)

Rule 3 -- lots of sprightly little autonomous (loosely coupled) systems can sometimes trump a (monolithic) Big Iron dinosaur is my operative belief, and a centerpiece of most of my designs.

---

Knowing the in-built assumptions and limits of any system is basic to developing a Godel-ian model of the formal weaknesses of a system; finding ways to get inside an OODA frontier is essential to compete effectively against an informed counterparty. This brief John Boyd [pdf] piece on this should be on any systems analyst's periodic re-reading list. The longer, Pulitzer Prize winning Godel, Escher and Bach, by Douglas Hofstadter is a staple for periodic re-reads, slowly and for contemplation, perhaps on the nightstand.

Ironically I was selected to take a survey on RIMM support ...

... and seemingly looking for places where BlackBerry support services can be priced:

Here is your answer: I'll pay almost anything for a fix of a non-functioning product that is 'almost there', and won't continue to pay for a product that cannot be fixed (I'll switch away from the vendor, if the doco is incomplete, the support bad, or the offering bogus; I'll eat my loss and move on).

The survey design NEVER asked if the support received from RIMM worked or had value; what my opinion of the existing RIMM web offerings was; how the responsiveness of support modes were; how RIMM is handling its external interactions doing support.

I assume I was contacted to take a satisfaction survey in light of interactions with RIMM support -- recent ones have been about getting sync through the PocketMac program [not recommended] to work in an OS/X environment. Never could get it to work.

(URL was: http://www.blackberry.com/redirect/rdr?sap-client=110& ... etc )

header was:
**********************************
Happy with your BlackBerry solution?
Please help us serve you better.
**********************************

and what looks like the contact data I enter when using the BB website.

Executive summary:

No -- I am not happy.

I have found RIMM support for the PocketMac backup of the BB device to be incredibly frustrating and 'live' support useless [on line doco is clearly incomplete, and email requests seeking clarification have gone ignored]

Ticket handling techs using canned replies, with absolutely NO interest in follow through, or ACTUALLY FIXING and confirming a fix for the issue. The RIMM emphasis seems to be on closing the ticket, seemingly within three days, without a confirmation that the issue is fixed.

This leaves a very bad taste behind -- ticket numbers on request.

And the product Pocket Mac so bad that I have abandoned it for third party vendors' approaches (MarkSpace, and Google Sync)

Still not right, but at least partially usable -- and what do you know -- MarkSpace is running a beta [of its upcoming update to its BB synchronization tool], and opening and following bugs I file.

ps -- The blackberry.com website very safely and skillfully hides email addresses, so that all contact can come in only through avenues (webform inserts into databases) likely to be able to 'close and ignore' issues. I assume there is no post-close QA review, as I have seen no sign of it.

Sad -- I thought the 'killer app' that lead to the BB was
pervasive contact capabilities.

I sent copies of this to each of the co-CEO's seeming email addresses for the exec suite pulled from a bit of google searching -- Please share or redirect as needed. Call if you want to talk; I'll answer any email as well. [I received a phone call from 'customer retention' and a 'follow the call email' with a 'role account' email address, and no telephone number for me to use. RIMM just does NOT want communication to be initiated to it except on its terms.]

For what it is worth, prior live support by RIMM, gated through T-Mobile (where I have the ability at the end of the transaction to say: 'We both see that it just does not work -- cancel the service as you cannot deliver that you have sold me') had been fine.

There's a message there, I think.

'Every move you make, every step you take'

A while back I commented on the fact that the computers of the world seem to have issuance of traffic citations well integrated; After this piece about Italian parking citations, I received yet another citation advice, from the Milan area through the vehicle rental firm, Europcar, asserting the vehicle I was driving was noted traveling over limit.

Maybe, but I also carry a commercial driver's license [and so drive very conservatively from habituation driving very dangerous large trucks at one time in my life]. I regularly am ridiculed by family members for never speeding, coasting up to red signals, and easing away rather than 'jack-rabbiting' off the line at a green light. As it had already been charged against my credit card, there was no sense worrying about it.

The takeaway from this article:
Smart traffic lights rigged to trap drivers is clear. I have no reason to suspect a more fastidious level of care to avoid error elsewhere in the electronic traffic citation system.

... typo fix: Parking, not Packing citations

'Money for nothing, and the chicks for free'

The weekend started with a private email from a long time friend, wanting to rebuild a semi-FOSS mixed commercial and community project, and asking for some analysis of what such a project would entail. It turns out to be partially Debian based. We'll be talking later today on the matter to see if he needs some consulting services to get the project done.

Unrelated to that, I watch the mailing list traffic in another project, which is designed to be a short lifespan, bleeding edge 'proving grounds'. One of the perennial threads that resurfaces is a proposal to take one of the 'better' releases (under some unclear metric of 'goodness' -- time based is most often seen [consider Ubuntu's LTS every N'th release]), and for 'the community' to support it for a longer time frame.

A poster unfamiliar to me, Marc Schwartz, noted this over the weekend:

Keating quote in C|Net about the end of 'Fedora Legacy'

"Nobody has responded to our calls for help," Keating said. "There are a good number of consumers, people who will happily consume until the project ends; however they are not willing to actually do any of the work necessary to keep the project alive."

In other words, FL had a parasitic, not a symbiotic, relationship with its users.

If Scott is willing to do the heavy lifting and he has people that will step up with him to do the heavy lifting, then this project might have a chance. On the other hand, if people just want the output, but are unwilling to step up to contribute to the input, then this project, like FL will fail. It might take months, but it will fail.

At Owl River, we designed, built and offered a commercial general market product to work in parallel with our 'community side' work with first cAos, and now CentOS. Wings really never caught on, and neither did Ian Murdoch's Progeny venture, each offering commercial SLA post RHL updates offerings. Progeny closed its doors a couple years ago now, and the domain progeny.com looks to have been sold off to a domain linkfarmer.

As it turns out in our consulting, we seem to need just a few packages on top of a CentOS base, and related configuration. It is my thesis that it represents an uneconomic waste of cycles to spin yet another full blown distribution, rather than just solving the remaining ten percent of 'hard parts'. We meet our GPL obligations and our broader sense of giving back in support of FOSS by making our solution SRPM's initially built for customers freely available, and have do so for many many years.

The random drop-in posters on the mailing list, and in the CentOS IRC channel are of course whining that their free updates are slow in coming. How dare we have personal lives, take time to get married, etc.?

It takes discipline and a thick skin to NOT rush a poor product out, but the purpose of CentOS is to replicate its upstream, warts and all, with trademark elidement and the minimal stabilization to get the installer and update tool working properly with our updates mirror solution. We have other checklist items on this QA round as well, and frankly, it will ship when it ships.

For those who cannot wait: Go for it; the wiki documents a non-root build environment, and it is not a dark art to build a limited set of updates. The Source RPM's are freely available upstream. We have documented the comparison scripts long since.

You can solve the build, verification and stabilization issues just fine with just a few months work; if you start now, when the next point updates come out, you won't have to wait at all.

One view of Contacts, everywhere

I've been working through cleaning up my Gmail Contacts entries the last few days. Google released an extension of their mobile application suite which does a basic but workmanlike bi-directional sync between the webbish Gmail Contacts information, and my Blackberry's internal store from the mobile device's point of view. Thanks, Gmail team at Google.

I had looked in to writing a 'third party control' synchronization tool, so that I could have an authoritative store safely behind the firewalls, and in a CentOS LDAP backend. Google publishes the needed API; RIM is less open, but the API and a device simulator is available as well behind some Export Control disclaimers, identity harvesting, and such. In the FOSS world, the fruit from the barry project is maturing nicely as well, but tackling cracking open the datastore blobs (which RIM manipulates with some Java code in their implementation and SDK) is somewhat tricky and it is not for the timid.

I write this having 'bricked' the phone a couple nights ago, and had to fall back to restoring from a backup image. You _do_ take and test Level 0 backups at least weekly, right?

Just as I thanked Google, RIM also deserves 'kudos' for continuing to roll out fixes, and feature set upgrades on the phone chassis; it has added video movie capture, dictation ('voicenote') from them, and as it has a sufficiently 'open' API, I have been able to easily add applications from Google mobile, Remember the Milk, and Jott all co-existing on that chassis. Add Google Docs, and drop.io tools, for mobile productivity completeness.

High recommendation for a high end approach to their portable devices, but the trackball retention ring on my unit is cracked and the dirty trackball issue others mentioned is also there. Apple probably had it right early on, choosing the touch screen approach which the iPhone uses. But Apple and ATT think they can profit maximize with an exclusivity (i.e., non Free and non-discriminatory access to the platform) deal in the US; They are free to their opinion, of course, but not with my support.

Back to the matter at hand, the Blackberry and the Gmail Contacts sync works sufficiently well that I'll leave it running; I need to learn a bit about how to do edits and sync in stages, rather than doing all ACDs ('Adds, Changes, and Deletes') in a single pass, so that I don't end up with 2, then 4, then 8 slightly different records shuttling back and forth. The proper sequence is probably: Edit to a single record first and sync; Delete the strays and sync. Add's seem not to be a problem.

Once I have the process down, I'll still have to face that LDAP and third party local control [CentOS from the office] issue. I'll probably pick up an Apple Mini based on the Intel processors for some other development needs, and so I can retire my trusty PPC eMac, which will not handle the OS/X 10.5 OS level. The later OS/X versions have markedly beter LDAP and synchronization tools, and unlike RIM, Apple is pretty clear about the need to 'keep up' with the hardware franchise in order to get later enhancements.

Only you can prevent forest fires

You say you want a revolution
Well, you know
We all want to change the world
You tell me that it's evolution
Well, you know
We all want to change the world
-- John Lennon, The Beatles

Ted Tso has a blog post commenting about the market capitalization of Sun (stock ticker: JAVA) being 'underwater' relative to its cash on hand:

Sun’s current market cap: $2.40 billion USD. Sun’s cash on hand: $2.63 billion USD

and advancing a concern that a firm hostile to Software Freedom might purchase and kill it. [A bit ironic, thinking about the Cobalt Qube; a PFY I trained a few years ago moved to Portland to work supporting the Qube software, only to have Sun functionally kill the Cobalt product within the year ... oops]

Not surprisingly, there is a maze of intellectual property rights to navigate in considering using an asset so valuable that a company renames its Wall Street 'nickname' from 'SUNW' ("Stanford University Network Workstation") to JAVA

Hopefully, Ted Tso was just playing 'Devil's Advocate' earlier this year in a thread of debate surrounding a proposed adoption of a java (Sun's 'Java' or otherwise) into the Linux standards base upcoming ver. 4.0 release stirred concern

Reviewing the bidding;

• LSB weekly conference call chair Jeff Licquia stated the non-Free (OSI or FSF wise) Java Test Conformance Kit concisely in the post call minutes

Jeff: summary, Ted: do a checkpoint two weeks from now, to see that the features are getting in. Jeff: agenda item for August 13th call? Ted: yes. Mats: Java is also an issue. Ted: issues with Java? Mats: which spec? Required methods, classes, etc. Test suite question is also a big deal. Ted: should follow up on these issues before Ron gets back

LSB Committee work happens in part on the mailing list.

• The thread sharpening the Sun Java issues in advance of that call kicked off here
• Alan Cox questioned the wisdom of such an inclusion of a java
• I put together a rather large piece detailing some issues surrounding the present Sun licenses as to distribution of the [Sun] Java's actually in use today as well as the accessing and using the TCK

Note: If one wants the flavor of the thread, read the posts by Tso, Cox and Herrold out of the pipermail archive for August 2008. At one point in that thread, I was asked: Why do you care. I care because FOSS culture matters and needs defenders to stand up and advocate for it. I can live with the balloting results for the 4.0 release

Software Freedom issues are an 'elephant in the room' at the Linux Foundation (current 'owners' of the LSB), and they try to thread a delicate balance to draw the commercial into the FOSS world

My personal opinion is that LF need not worry so: The 'should we have a FOSS strategy' discussion is over; 'of course,' being the outcome. Market forces will solve adoption because the firms in an given industry NOT using FOSS properly will have higher cost structures, and go extinct

Oh, and you too can make a difference; by showing up, participating with considered intent, doing justice, loving kindness, and walking humbly, all the while remembering that "politics ain’t beanball"

Behind Blue Eyes

Dateline: U.S. Department of Labor

The largest increases in initial claims for the week ending Nov. 1 were in Ohio (+3,885), Michigan (+2,619), Pennsylvania (+2,155), Wisconsin(+2,119) ...
-- UNEMPLOYMENT INSURANCE WEEKLY CLAIMS REPORT (week ending Nov. 8 2008)

A friend wrote:

All this proves is that when someone crosses a state line to register to vote it is just as easy to register for unemployment while you're at it.

I think it is probably much worse than that

It is easy enough for anyone to set up a (several!) new 'employers' and then walk away from them 8 weeks later with no individual financial responsibility for the 'tail' -- after all, we encourages formation of 'small business, the engine of economic growth' and barriers to entry should be small, right?

Unemployment benefits may be had at full rate for 6 months after 6 weeks employment at a given 'employer' if one is otherwise qualified; when an 'employer' goes out of business, the employees are eligible for benefits Several telephone poles in central Ohio had signs, with differing phone numbers, for what appeared to be short term 'jobs' working to elect Obama and 'make Change'. I snapped a picture with my mobile device, and will see if I can find it for the exact text; I recall thinking at the time:

-- Don't the 'employee candidates' KNOW they will be let go the day after the election

Now, I think the answer is:

-- Sure -- indeed they were TOLD by the recruiter at the other end of the phone, that this was a way to get rid of a pesky 'termination for cause' {disqualifying} black mark which was keeping them from what they were 'entitled to'

As the One won, and 'We can do it!' if the system is properly 'gamed', I think there will be no investigations after Jan 20 to 'connect the dots', and the Lame One will just snooze out his term. 'No law will prevent it'

And so the Republic was lost. "Meet the new boss; same as the old boss"