I have an important distinction to make clear... Cross Compiling is using a machine with a different processor type than the target machine for your program. So, you have a PC with an Intel Core 2 Duo in it, and you use a compiler to output an ARM executable, that is cross compiling. If you're on an Intel Core Duo toting 15" MacBook pro (from 2006 ) and you use that to produce the same ARM executable, that's still cross-compiling. BUT if you use that MacBook to generate a windows executable it's not cross compiling, as the processor is the same in both targets, you're not crossing over... Some folks argue this differently, because you're crossing between the Windows and Apple OS's you're cross-compiling. In my book, and by the definition given elsewhere, you're not, in this case you are cross-platform (the platform being the OS) but you're not cross compiling because the processors are the same family. That's all, I just wanted this out t...
How robust is your back up solution? Go on, be honest with yourself, how good is it?... Because I've seen a whole host of them and, at this very moment, this is the screen up on one of my servers.... Yes, my raid 5, just a test raid 5 with three really bad recycled SAS drives in it has failed; this doesn't surprise me, but it does delay me because I now have to rebuild the data... However, I know my data is good.... Lets see how good my back up is. This back up is coming from a DD created raw image of the virtual disk, stored to and soon lifted from my NFS accessible ZFS mirrored back up server. Therefore you would be right to ask, why are you rebuilding the virtual RAID disk in the above screen shot? Well, I'm going to test my back up strategy! I popped the known bad disk and the good disks out, replaced all three and I'm able to test a restore to a new virtual disk set, I have a USB boot drive ready, this is a test. This kind of test, a real live restore, is sorely ...
I was wondering around in some system code and found a strange behaviour between two modes in a piece of code, where the code switches from double to triple buffer mode there's a problem, we've already got two buffers of everything we just want to allocate another but the underlying structure for sets of buffers wants to own them all... So the code went from: SetOfBuffers { Buffer* one; Buffer* two; } To: SetOfBuffers { Buffer* one; Buffer* two; Buffer* three; } Creating the third buffer is fine: SetOfBuffers::three = malloc(X); But, the first two is a re-alloc, to reuse the existing buffer: SetOfBuffers::One = realloc(OldSet::one, X); SetOfBuffers::Two = realloc(OldSet::two, X); The problem? I'd start to modify the values in the new set of buffers, the third buffer being used and present. Then the first buffer would be changed present... The second buffer changed present and the information is wrong (I over simplify massively here). Anyway, I was remotely SSH'd ...
Comments
Post a Comment