Is anyone buying this? Really...?

I stumbled across this article that, quite honestly, at first pissed me off. After a little reflection, I can only laugh. It reminds me of someone trying too hard to sell those $150, short gold plated digital Monster audio cables - Oxygen free or whatever. (If the engineer inside you doesn't laugh, then cry for the sake of the suckers, read on).

Maybe I read in to far, but I see snakeskin oil vendors grasping for air! The piece is an obvious response to Steve Hechtman's very different article on the same topic (hosted on Control Engineering) - he should be flattered. You see, the big vendors, GE Faunc in this case, but the exact same applies to Wonderware and Rockwell have been long committed to the concept of Historians, a glorified and expensive datalogger that includes, and is only meant to work with, a custom version of Microsoft SQL Server (of all product choices...). The problem is that now much cheaper products from companies like Inductive Automation and Software Toolbox can do a better job using any RDBMS (database) system. Being vendor-neutral, inexpensive add-on packages also do much better for things like trending, reporting, and data analysis. The biggest mistake of the current generation of Historian is that they tried to implement and include everything themselves - like making a giant Swiss Army knife with a spork, usb memory stick, and a wine glass. Now they're caught with their pants down, desperately scrambling to recovery their enourmous sunk costs (my favorite business term).

• You're data is special and requires "plantwide historian" treatment...their example query “What was today’s hourly unit production average compared to where it was a year ago or two years ago?”. I won't even comment...

• Your database needs to speak specialized industrial protocols (OPC) - There's separation of function by design and for a reason. Besides - this doesn't even make sense.
• Faster speeds and higher data compression - no way! The historian is wasting CPU cycles in both directions, which obfuscates your data (can no longer use external applications), to do something better achieved by a RDBMS system that supports it.
• Robust redundancy for high availability - is this a joke? Maybe Amazon.com should migrate their server farms over to GE-flavor SQL Server.
• Enhanced data security - another losing battle for the historian. The white paper mentions SQL injection attacks - all platforms in question can use stored procedures, and are all subject to this sort of attack. When it comes to up to date patching, arguably the most common vulnerability, SCADA vendors have the absolute worst track record! IT keeps their servers patched as a matter of practice - they're typically afraid to touch the SCADA machines. Ultimately, the "do everything" approach provides many attack vectors.
  

I can't blame them for playing their hand. I just wonder - will anyone read this white paper and take it at face value?

Cheating in Online Poker

I just got back from a Las Vegas weekend trip. The poker gods were good on the cheapest ($1/2) tables Bellagio had to offer. My hourly return wasn't impressive, but I had a great time chatting with a variety of gamblers.

One particular story clung. A player said that his "friend" got a chance to witness someone "win" $13k in one night cheating at online poker. I'm not too impressed with the usual tactics, run a background application to gather statistics on opponents or even the recent Absolute Poker cheating scandal. This one caught my attention because it was so simple, yet incomprehensible to catch. You could multiply the benefit with automation/a program, but that's not necessary.

The scam involved playing 5 of 6 simultanious accounts at an online poker table. It shouldn't take a superstar to see that you could easily squeeze out single unsuspecting victims. You could even use a program to obtain more accurate odds since you see 1/5 of the deck. Connection details seemed obvious. I would use proxy services to route via different cities around the world, consistent from each account. The crux of the scam lies in the fact that you can easily create throw away identities - violating the security pricipal of integrity, that you can verify that someone is who they claim. Online gaming sites do monitor IP addresses (defeated with proxies) and users who constantly collaborate. However, you'd be pretty hard to spot with a pool of accounts that get used for short time periods.

What about the penalty if you do get caught? I can't imagine playing multiple online poker accounts getting you in as much trouble as stealing...

The best protection brings inconvenience - closely couple user accounts with real people. That requires you to give up all the personnal info that you don't want to share: valid ID, bank accounts, SSNs, etc. As an online player I'd feel much more safe if the site required heavy verification. Then again, I only play online for "points".

SQL Standards. And standards.

Who comes up with this shit? Seriously? Is it human nature to try to make everything your own, or a flawed side effect of our culture? (In that case it's royalties). I'm talking standards, of course! Why can't we all just get along? Consider SQL. We like SQL! It's simple, powerful, and has proven to be conducive to interoperability. Don't believe me? Check out all the database frontends that work with so many "flavors" of SQL. There are innumerable database driven applications that could run on any. Why is it so hard to get along? We've got ANSI and ISO SQL (think 7 layer OSI reference model - let's implement that...right...?). Microsoft's gotta be different from Oracle, and MySQL, and IBM DB2, and PostgreSQL - and they're all subtle-ly (is that a word?) different from each other! Cumon M$, why do you have to use the TOP keyword instead of LIMIT to limit returned record sets? You know your programmers could efficiently implement both? Can't just pick on Microsoft, though - they all do it! Going to a unified, or standardized language set, while maintaining backward compatibility, really shouldn't be that big an issue. Everyone's products will be the better for it.

Let me tell you about designating quality codes for object overlays when designing SQLTags in FactoryPMI. We could have chosen whatever quality codes we wanted. My birthday could have been a tragic error! But we chose to follow OPC convention. Why? Standardization. I have no idea why 192 is the quality code for good data. But someone smarter than me said it would be. And so it went...

I was prepping myself for a long rant about standards - I was going to tear Sony a new one. But I'm tired. I'd rather go to sleep.