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.