blahg

A Backup is Not an Archive

Shawn Blanc recommends:

use SuperDuper to keep a bootable copy of your main startup drive, and let Time Machine do its thing to archive stuff

When Time Machine was announced, I’ve scratched my head for a while, clueless as to why people were finding it useable at all. One day the realisation finally hit me: I had failed to distinguish between archiving and backing up. To me, this is the same thing, because when I want to make a backup copy of something, I copy it to my archive, which is a somewhat robust data store, with the most important bits copied ‘off site’. Of course I do this way too infrequently, and I still haven’t made a properly searchable index, but when some ancient file is important enough to me to go through the effort, I can find it and get it back. Time Machine doesn’t allow you to do this. A few examples for things you might expect from a proper archiving solution, where Time Machine fails: It haemorrhages old data, it doesn’t allow you to sort your data onto multiple volumes in an intelligent way, it can’t deal with small changes in large files (not in a sensible manner that is). Time Machine does not archive stuff. All it does is make backups, frequently, all the damn time, which is something you’ll never do yourself. That’s why you should use it. Using SuperDuper in addition is also a good tip, as Time Machine can’t make bootable backups.

Macworld prediction

The new subnotebook will definitely be heavier than air.

Sticking with PyPortMIDI for now

Oh wow, MIDI in Python is in a sub-optimal state, at least on the Mac. I was just about to switch from PyPortMIDI to something with a more recent release, as people had complained that they couldn’t get it to run – maybe because it hasn’t been maintained in years, or maybe because you have to muck around with Pyrex in order to build it. Since I’d made the decision to switch (many weeks ago), I’d assumed that there’s something more recent I could use, but it turns out that the one SourceForge project is only about reading and writing MIDI files and the other one is in pre-alpha stage. Another project I found is a bit weird and also non-free. PortMidi, on the other hand, is working just fine, and it’s just the Python wrapping that could use some polishing up – not an incredibly hard task to do, I imagine. So, for now, I’m sticking with that.

The Quake3 Networking Model

The client’s receive logic boils down to:

if ( newState.sequence {
//discard packet
}
else if ( newState.sequence > lastState.sequence )
{
lastState = deltaUncompress( lastState, newState );
ackServer( lastState.sequence );
}


The client then extrapolates movement and whatever other information it needs based on the last game state it received.

It’s even simpler on the server:

deltaCompressState( client.lastAckState, newState, &compressedState );
sendToClient( client, compressedState );


The server never sits around waiting for an acknowledgement. As a result, latencies are much lower than if you have code that sits there twiddling its thumbs waiting for a synchronous ACK.

---

The Q3 networking model obviates the need to even have a discussion about UDP vs. TCP, unreliable vs. reliable, and out-of-order vs. in-order. It’s all unreliable UDP delta compressed against the last known state.

A very elegant and effective architecture, albeit one that is ideally suited to a subset of game types.

Source

Linker trouble again. For me it’s always the linker, never the compiler. In the context of something or other (haven’t investigated details yet, I hope I can fix this without anything as laborious), this comes up:

"cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag"

OK, a bit of context: I’m trying to build a universal binary by invoking a setup.py script. I think the problem is that in the process some lib is linked in, and because I’m building a fat binary, the lib is expected to be fat, too, but isn’t. Now, it’s not that I want to build a universal binary. I’m not making a binary package that should be fit for redistribution, I just want this for myself. Hence, I could do with a PPC only build, but where can I specify this?

Grepping for “arch” or “i386” yields nothing. I’ve always thought that kilometre-long Makefiles are evil, but setuptools or ez_install or whatever it’s called isn’t quite the Egg of Columbus either. It’s supposed to be as easy as invoking the setup script first with the parameter ‘build’, then ‘install’, but when that doesn’t work, I just have no clue what’s what and where to find stuff.

However, in this ancient discussion from some mailing list, I’ve found a nifty clue:

from distutils.sysconfig import get_config_vars
print get_config_vars('CC', 'LDSHARED')

import os
print os.environ.get('LDFLAGS')

AHA, so this, then, is the kernel of the brute! The latter invocation gives me nothing, but the former turns up
['gcc', 'gcc -arch i386 -arch ppc … ']

Now, how do I temporarily get rid of the i386 flag so I can build my PPC-only binary? Where does the configuration information come from? The documentation of distutils’s sysconfig module has the answer:

>>> from distutils.sysconfig import get_makefile_filename  
>>> get_makefile_filename()
'/Library/Frameworks ... python2.4/config/Makefile'

So there is a Makefile involved, after all; you just have to know where to look. In there, I temporarily removed the i386 flag from BASECFLAGS and LDFLAGS, and the build went without a problem.

So, there’s one way to deal with the above-mentioned error message, hereby made public to be indexed by seach engines for posterity. And we’ve learned something about setuptools as well; life is good.

Note to self: “StarCraft requires TCP and UDP port 6112 forwarded to properly join and host games on Battle.net.” Yes, not just for hosting. The weird bit is that you can easily get in a situation where your connection is misconfigured, but you don’t get any error message whatsoever; just extreme lag whenever a game starts.

Update: Turns out this tip is not even wrong; it’s just more complicated than that. I finally got StarCraft working through my router, but I’ll have to break out the sniffer and analyse what exactly is going on before I can post details. I hope I’ll get around to that next week.

When first details about iPhone pricing in Europe emerged, I was quite pleased with myself to find out my prediction of a price around EUR 1000 was holding up. However, that was before the price cuts. Now T-Mobile Germany just announced their price for non-locked, contract free iPhones (usually the only fair data point for comparison, as subsidies vary greatly and you’re paying the difference anyways through the monthly fees), and it’s still EUR 1000. This seems like an arbitrary alibi offer at first, made only to comply with German law. However, it makes sense when you consider that the cheapest contract they’re offering is EUR 50 per month, and you have to sign up for a minimum of two years. EDGE is included in that fee, but the value of that should be EUR 20 per month, tops. And voice calls are so expensive that you’d expect to pay pretty much no monthly fee, instead of 1200 over two years.

So, yes, the iPhone is a EUR 1000 device over here. As long as you don’t make the mistake to think of it as a mere telephone, it’s well worth that price, for a large group of people at least. But don’t tell me it costs EUR 400 – that’s far from the truth.

Gruber recently linked to Greg Knauss, who says:

Are gas pumps really accurate to a thousandth of a gallon? No.

Greg uses Tumblr, so I thought I’d try out tumblrs new (to me, anyways) ‘reblog’ functionality and call bullshit.

That is, I have absolutely no idea how accurate gas pumps are, but the explanation is bullshit. It doesn’t concern itself with the actual question for one bit, instead only stating how accurate gas pumps are required to be by law.

And then there’s this:

Heat can also play a significant role, as all industry tolerances assume 60°F – a gallon of gasoline at 100°F takes up almost 3% more space.

For any commonly used definition of gallon (they’re not the same everywhere), one gallon of anything at any temperature always takes up exactly the same amount of space as one gallon of anything else at any other temperature.

I would really have been interested in a good answer, because the issue is related to the false sense of accuracy you can get when measurements are displayed with an excess amount of digits, and also to the programming I’m doing at the moment. Both animating/simulating scenes in computer games and triggering electronic music instruments (which is what said programming is about) require precise timing. And it just so happens that often you get timestamps in milliseconds, which would be just enough for these purposes, but the actual accuracy of the values is in the tens of milliseconds, which, painfully, is not enough.

And, of course, miscellaneous nerdery is always interesting when you’re procrastinating. Now, the question wasn’t answered, my curiosity is not satisfied, and I’m grumpy. Hence the grumpy write-up.