May 03, 2003
MyKad, government-backed multi-application SMART card
About two months ago, my wife's handbag was snatched away by 2 motorists (this has become a serious threat to women walking in the streets of KL, it happened e.v.e.r.y.w.h.e.r.e). She had to apply for all losted cards like I/C (Identity Card), driving licenses, all ATM/Credit cards.... We have her I/C applied and two months later, she got her new I/C -- which is our Malaysia's proud chip-enabled I/C MyKad. We have the perception that, since we are going to have both personal information and driving license info stored into the chip of the one and only one card, we should wait for the new I/C and then to apply for the losted driving license.
It turned out that JPJ (Jabatan Pengangkutan Jalan -- Road Transport Department Malaysia) didn't think the same way. We arrived there this afternoon, she got the ticket for queuing up, being instructed to take photo and have her new I/C photostated. What the heck! Why do we need to take photo and photostat a new generation I/C, which supposely having all the info securely stored in a chip? And shouldn't the database have the data already?
With doubt, we still spent the extra money for photo and photostat. Wait patiently and an hour later, we learned that, you could ONLY apply for the lost driving license of the old type, then to apply again to merge the old driving license into your chip-enabled, smart I/C. She got the driving license, and it's almost come to off of office hour, which means, if you want to convert the license, come again next time.
Why the extra process? Isn't it just straight logic you could have I/C and driving license in your MyKad while you're applying for new? What a pain! As a victim, you got a paid leave to apply new I/C, the other leave for driving license, and then some day later you got to merge this together because we have this proud chip-enabled I/C. And we are in process of upgrading all magnetic bank ATM card to chip-enabled bank card. Some days later we got to merge this to I/C, AGAIN. God, when are they going to think INTEGRATION ahead?! Or at least some simplified processes?!
Update on Dinesh/alphaque, Streamyx
Alphaque is back online, their premium 1.5Mbps SDSL Streamyx connection was down for 80 hours. The reason is ridiculous. As Dinesh said,
The problem ? Apparently one of the jumper cables in the MDF room in our building was not plugged in, thus causing the disconnection. Now, access to this MDF room is solely under Telekom Malaysia's control. Not even building management nor maintanence can get in, and the entire room is theirs. If a jumper cable was not plugged in, then it must have been some fuck up by their technician. Perhaps someone came in to get some work done on Tuesday, and either kicked the cable off, or pulled it out and didn't put it back in again.
Could you believe this? That's how TMNet service their premium customer and they don't even apologized for that stupid mistake. No exchange problem, neither whatever technical issues, just a cable unplugged! I laugh full mouth when I read it.
Meanwhile, I finally got Dinesh's update on his MySQL benchmarks, which I was waiting for after reading he gonna to implement a terabyte sized MySQL DB. The result is amazing, with proper tuning, a terabyte sized MySQL could still get minisecond range query latencies and thereotical max 4,000 queries/second. The benchmark was done on a dual CPU, 4GB RAM Asus 1U rackserver, running FreeBSD. The lesson:
- Force index selection with USE INDEX for optimization. You could use FORCE INDEX for version 4.0.9 or greater, which act like USE INDEX but with the addition trying the best to avoid table scan.
- Link MySQL with LinuxThread if you run MySQL under FreeBSD, with multi-processors machine. Jeremy explained it and thought "using LinuxThreads ought to help even on single-CPU FreeBSD boxes."
- Optimization could be dangerous though. Stick with helpful tools and carefully chosen your configuration.
Thanks for the sharing, Dinesh.
