Parallel or Sequantial, Radio Signals, Python JIT, HL7 FHIR, UUID, WD, HPKP, USBee

Post date: Oct 9, 2016 5:27:26 AM

• Some times it's really hard to tell before hand which is the best option. When you'll need to run copy jobs A -> B and A -> C is is faster to run those in parallel or sequentially. There are multiple factors affecting that, including caching, disk devices, ports being used for I/O etc. There's no simple answer. This is very simple question, but answer is complex and basically impossible to answer without knowing a lot of specific things. As well as other processes running on the system affect the situation. Is there enough memory, can the disk cache be utilized, what are the storage access patterns and so on.
• Configured IPv4 to use shortish keepalive timer to maintain NAT sessions alive. But with IPv6 there's no NAT and therefore no need to use aggressive keepalive for long term idle TCP connections.
• Studied bunch of high speed USB 3.0 Flash drives. Bought one. Let's see if it's good or bad. Some of the drives have been optimized for FAT, but as I've written earlier, I really want to use NTFS with flash drives.
• Radio signals can be used to see? - Not really surprising. There's passive sonar, traditional passive invention like camera which captures electromagnetic signals. AESA radars and stuff like that. Modern signal processing can give quite awesome capabilities if it's done right. Also if there's a static sound source in a room, you can clearly hear someone moving in the room, because way the sound waves reflect in the room changes. When listening music, just try moving hand around your head. It does create major changes, even if it would be 20 cm away. Just like the TV can work well when your neighbor is in bed, but stops working when someone moves in other room or so on. In radio world, everything affects everything.
• Really nice article about Python JIT's - So far I haven't had real problems with Python performance. I usually use it as glue between systems in my integrations. But of course if there's easy to "plug-in" JIT I would use it. Often if writing just simple random code GIL is bigger problem than lack of JIT. Of course JIT can also improve single thread (or in case of Python process) performance a lot.
• Just a link to HL7 FHIR v1.0.2 bundle specification. Btw, their HTTPS cert is failing. Smile. These samples are XML based, but I prefer the JSON option.
• Safe-mail.net is failing again. Now their outbound email service is totally swamped. Yet when reviewing their history and track record, this isn't anything to be surprised about.
• I could write so much about project critical path and Gantt charts and people thinking that it doesn't matter if one critical part stretches a lot. Yet they don't figure it out that actually some resources might have reserved slot. So pushing one step forward a month, can still lead to four month extension in completion. That's nothing new, and discussion about classic and extremely traditional project management failures are utterly boring. - Then someone bothers to say it's a surprise. - Surprise, it's not a surprise.
• It's just like saying like we need "a unique identifier", without defining it's scope. It's instant karma and fail.
• Even more bugs in Skype for Android. When sharing a link whole Skype application must be terminated between shares. This really sucks because the app is also really slow to cold launch.
• Way to go Western Digital. While testing bunch of old computers I found out that about 15% of the WD disks were fully "working". But it seems to be tradition for WD disks that those get darn slow, even if 'working perfectly' according Smart Data. This just confirms what has been said about storage media manufacturers. They allow crappy products, but the self-diagnostics say everything is ok, so customers wouldn't ask for warranty replacement. - That's really a bleep bleep bleep strategy. It makes me and many frustrated users just so angry. Say FAILED and that's it, it's clear. Instead they'll keep teasing customers with utter junk and won't even confirm it. - I just can't stop really appreciating their attitude and working methods.
• Wrote yet another one data transport specification document for one project, describing multiple transport modes which are well suited for small and large businesses and their system capabilities.
• Nice article about HTTP Public Key Pinning (HPKP) - Solution is more problems? Hmm, nothing new here. Actually I didn't know that HPKP requires backup key. Let's make keys more or less permanent and hard to replace. - Let's make it's trivial to get new keys. Sigh, contradictions. Systems should be really secure, but nobody bothers to administer those properly and follow required procedures. - Business as usual.
• USBee - They said it can't be done. But technically thinking, it's pretty straight forward. - Nothing new, data leak over a channel, this time RF using USB as transmitter. Something new? TEMPEST is old stuff and different cases of unencrypted data leak with RF devices is even older than TEMPEST.