Well, just to be a nitpicker:
In general, "ex post facto" simply refers to changing any of the rules of the game after the action (the facto, if you will) has occurred.
However, in constitutional law, you are correct: the narrower definition applies.
Granted, ol' Al would have been 61 years older than Chuck. But geez, is it really that hard to Google something before making an easily-checked claim like, "whom, I believe was long dead by the time Norris was conceived"?
What if you merely have a radio, I mean c'mon; who doesn't like their extremely liberal talk-radio show? A metal tanket of water or a u/vhf 2-way does not a soldier make.
Um, just 'cause I like quibbling...
If I'm a soldier on the field, and I see someone in the enemy's uniform carrying a radio? Damn skippy, he's the first person I'm gunning for. Because odds are that radio is controlling much larger guns than I'm carrying. Canteens and med kits, sure, those alone do not a reasonable target make.
Here's the killer argument: file locking gives a false sense of security. Imagine: Developer A has foo.h checked out, while developer B has foo.c checked out. Developer A makes changes in foo.h that break foo.c. Notice that developers A and B both had locks on their respective files, and a conflict still arose. So locking is as bad a solution - or worse - than concurrent versioning. At least with concurrent versioning, developer A can change foo.h and foo.c at the same time, then merge his changes with Developer B's foo.c. In fact, subversion is remarkably adept at handling those merges... but that's only relevant after you've won them over from their file locking tools.
Slashdot Mirror
Well, just to be a nitpicker: In general, "ex post facto" simply refers to changing any of the rules of the game after the action (the facto, if you will) has occurred. However, in constitutional law, you are correct: the narrower definition applies.
Albert Einstein: died 18 April, 1955.
Granted, ol' Al would have been 61 years older than Chuck. But geez, is it really that hard to Google something before making an easily-checked claim like, "whom, I believe was long dead by the time Norris was conceived"?
Kids these days.
What if you merely have a radio, I mean c'mon; who doesn't like their extremely liberal talk-radio show? A metal tanket of water or a u/vhf 2-way does not a soldier make.
Um, just 'cause I like quibbling... If I'm a soldier on the field, and I see someone in the enemy's uniform carrying a radio? Damn skippy, he's the first person I'm gunning for. Because odds are that radio is controlling much larger guns than I'm carrying. Canteens and med kits, sure, those alone do not a reasonable target make.
VirUSES. VIRUSES. Not virii. Not virus'. VIRUSES. Jeebus. That is all.
Here's the killer argument: file locking gives a false sense of security. Imagine: Developer A has foo.h checked out, while developer B has foo.c checked out. Developer A makes changes in foo.h that break foo.c. Notice that developers A and B both had locks on their respective files, and a conflict still arose. So locking is as bad a solution - or worse - than concurrent versioning. At least with concurrent versioning, developer A can change foo.h and foo.c at the same time, then merge his changes with Developer B's foo.c. In fact, subversion is remarkably adept at handling those merges ... but that's only relevant after you've won them over from their file locking tools.
Um, how about "News for Nerds"?