Real-time vs async best effort, Data security, OVH, Computer Giveaway, OPT, Data corruption

Post date: Oct 15, 2016 1:55:26 PM

Once again I'm wondering why some customers request for real-time solutions in cases where there is no any real requirement for it. AFAIK, best effort asynchronous quasi-real-time is the best solution for most of background data transfers. Data usually gets delivered with a few seconds max, but it's still not real-time. Requirement for a real-time solution can be a real show stopper in some cases. Because real-time solution can't continue the process until the real-time component has finished. This just makes the system more vulnerable and less robust than it would be without this silly requirement.
For most of critical systems, I've configured one reliable DNS server which isn't ISP's own server. It's so common that 'Internet is down' and only reason for that is that DNS resolvers are failing or are extremely slow.
First we place servers in nuclear blast proof, ultra security, biometric retina scanner data center, blah blah blah. And then we allow remote desktop globally and use credentials Administrator, admin123456. - Now we can feel so secure! Nothing can touch us! - Or if the credentials are more complex, we write everything required to access the server on paper slip and carry it around in our jacket pocket. - No worries, if I lose the paper, I can print a new one. - The reality of data security.
Unfortunately had to deal with OVH rescue mode. I mean unfortunately because Windows blew up, but luckily the OVH rescue mode is pretty darn awesome. Even if I have daily backups in place, it was very nice to recover "all the junk" not being backed up + getting absolutely latest copy of the database, so any data won't be lost. -> Hence no need to restore from backup + manually ask retransmission of lost data. - But then there were bad news, reason for the server not to boot was that the file system had corrupted. Because the file system was corrupted also the data / files stored in the file system were corrupted and that was end of the story. - Still required restore from off-site backup. But phew, at least I had that backup and it was pretty current. - OVH has been having quite lot of issues compared to other service providers I've been dealing with.
Gave away bunch of full solid aluminum cast professional Atom D525 computers with hard drives, touch screens and 4 GB of ram and so on, fully equipped. It was interesting to notice that dozens of devices were given away, but only one taker bothered to send email afterwards telling that the devices were awesome and they're really happy with those. - That gave a good impression. These computers are interestingly a lot slower when running 64 bit OS than running 32 bit one. I guess it comes to the CPU cache sizes, 64 bit code uses more space and therefore caching gets more inefficient.
More interesting algorithm discussions, about OPT caching algorithm and it's particular implementation behavior with cache size 1. When new entry is inserted into cache, can it be the entry being evicted immediately or does it cause the old entry to be evicted. Sure, it doesn't make any sense to run OPT like eviction algorithm with that small cache, but it's still interesting question.
I just hate when people are asking to reboot something. It's not very common, but at times the brown stuff just hits the fan. You'll end up with corrupted file system, and of course after that you'll also have corrupted operating system as well as corrupted database & data. So much joy. - Well, there's something wrong with it, let's just hard boot it. Ouch! It'll work, most of time, but you'll might end up in deeper than you would wish situation with that approach. - Finally the risk realized and had not so fun time revering stuff. Yet DR is something that should be practiced regularly, so maybe it wasn't that bad after all. We found out that the DR procedures worked out 'as planned'. Which was nice to notice.