CAs normally issue certs with 1-year validity. As they may not expire later than 2015-11-01, CAs will mostly stop issuing them on 2014-11-01. I guess you could ask them to cut a cert with a special, shorter lifetime but that would be hassle (and therefore extra cost).

"Beyond that, failure to raise the ceiling would mean missed payments on existing U.S. government debt. And that might have terrifying consequences."

According to what I was told yesterday, this is unconstitutional. Debt payments _will_not_ be missed. http://blogs.reuters.com/breakingviews/2011/06/28/default-not-an-option-under-u-s-constitution/

It would seem that Krugman is basing his entire article on incorrect information. The dollar will not become insolvent. The stock markets may crash, but that would only be due to canceled government contracts and 800 000 people out of governmental work.

For opt-out cookies as a Firefox add-on, allowing cookies that never go away, check here:
https://addons.mozilla.org/en-US/firefox/addon/beef-taco-targeted-advertising/

http://www.ncausa.org/i4a/pages/index.cfm?pageid=71

"Brewed coffee should be enjoyed immediately!
"Pour it into a warmed mug or coffee cup so that it will maintain its temperature as long as possible. Brewed coffee begins to lose its optimal taste moments after brewing so only brew as much coffee as will be consumed immediately. If it will be a few minutes before it will be served, the temperature should be maintained at 180 - 185 degrees Fahrenheit. It should never be left on an electric burner for longer than 15 minutes because it will begin to develop a burned taste. If the coffee is not to be served immediately after brewing, it should be poured into a warmed, insulated thermos and used within the next 45 minutes."

Sounds like McDonalds was doing it right. I guess the woman that burned herself was unfit to experience coffee. Are you?

Note first, I am _not_ saying to replace your call to grep with a call to perl. Perl _is_ fast on assembling strings into a great matching system, but it still takes a _very_ long time to parse, say, 65000 separate strings.

So combine them all into one. Use Regexp::Assemble. With a little bit of fidgetting, it works with GNU grep, as well. Here's an example script, that I've named regex-opt:

!BEGIN regex-opt.pl!
#!/usr/bin/perl
use strict;
use Regexp::Assemble;

my $gnu = 0;
if ((defined $ARGV[0]) && $ARGV[0] eq '-gnu') {
        shift;
        $gnu = 1;
}

my $ra = Regexp::Assemble->new;
while () {
        $ra->add($_);
}

my $string = $ra->as_string();

if ($gnu) {
        $string =~ s/\\d/[0-9]/g;
        $string =~ s/\(\?:/\(/g;
        $string =~ s/([()?|]{})/\\$1/g;
}
print $string;
!END!

So, you have a file with your tens of thousands of lines of patterns to match. Ok, ./regex-opt < patterns.txt > matchpattern.re. This may work with egrep, but it's perl regex syntax, so maybe not completely -- procmail | egrep -f matchpattern.re

With 65000 lines, GNU grep takes about half an hour for the tasks I give it. After assembling all 65000 lines into one expression, even when that expression is _megabytes_ in size, it loads quickly and has the speed of a decision tree.

So, as you accumulate new patterns, output them to a file. Also, _always_ keep your list of separate match patterns -- I'm not sure how well this package can handle reparsing a regex back into itself. Do matches like so:
egrep -f <(cat matchpattern.re newpatterns.txt)

and once a week,
cat allpatterns.txt newpatterns.txt | regex-opt > matchpattern.re; sort -u allpatterns.txt newpatterns.txt > temp.txt && mv temp.txt allpatterns.txt && rm newpatterns.txt

The last meaningful America's Cup races were held in the late '80s. Somebody squinted hard enough at the 12-meter rules and entered a multi-hull. Now it's just a matter of who spends the most money on a carbon fiber boat with a wing sail. This is a sailing race of fundamentally unseaworthy vessels. It would be literally be safer to cross an ocean in a dinghy than in one of these monstrosities.

Come September, do yourself a favor. Watch Deep Water on Netflix. Read any book on Ernest Shackleton. Read any Lin and Larry Pardey book. You'll finish all three before the America's Cup race is over, and you'll know more about sailing than watching every second of the America's Cup races.

I have a late 2008 15" MBP on Mountain Lion. It's fine.

Upgrade to the maximum RAM you are capable of. (A good practice at all times.) Mavericks will be a different beast, and it's well worth waiting to see on a 5+ year old machine, but you're probably fine.

So what? Concern where concern is due. Do you really think that Google is going to be fetching your phone backups, hoping for a wireless password, then driving to your house and connecting to your wifi so that they can... sniff your traffic? Impersonate you on the internet?

How does this in any way matter? even if the password _were_ encrypted, it's reverseable encryption -- it _has_ to be. So they could just decrypt it, anyway. This is the same as on Windows: you can get a wireless key viewer that gives you the password of every network that Windows has memorized. Further, your computer is probably a great deal more accessible to anyone, especially those who are interested in your wireless network, than Google's phone backups.

As for those who are going to say, "Let the user encrypt it with a password!" ... most don't do that. Most people won't put one in, many will forget it if they do, you can't link it to a phone identifier because part of the purpose is in case the phone is lost, and part of the functionality is syncing to Google services -- so it has to be decrypted anyway. Wake me up again when Google syncs all the pictures you've taken with your camera to Picasa and posts them on your auto-created Google+. That'll be a fun day.

http://www.youtube.com/watch?v=vP0cUBi4hwE

Interesting. You've provoked a response from me, a theoretical hobbyist. :-)

Matter reaching a black hole: by the laws of relativity, which I only know in a casual sense, the matter should become ever close to the event horizon, where all the disassembly and modification will occur. As the matter hits the speed of light, either while orbiting or sinking through the event horizon, the relativistic effects mean that the matter will require an infinite amount of time to change _internally_ -- but externally, from our view, it reaches the speed of light and proceeds into the block hole.

So basically, whatever particle that's entered the event horizon or met the speed of light just before it will not change after it's inside the black hole. But at that point it's pure energy, anyway -- what happens at this matter -> energy conversion stage, who knows. (Does the energy contain a complete snapshot to be able to return to exactly the same state of matter should it be slowed down?) The more interesting result here, I think, is that a black hole is made of dense _energy_, not matter. At least, it was converted to energy at the event horizon and perhaps mashed back to matter at the singularity. Probably a quasi big bang soup-like-state, if anything.

Second, gravitons escaping: I came across an article recently, which I can't find now. It went over subatomic particles, how they interact, what they interact with, etc. Photons are force-carriers that do not interact with other photons. But photons _do_ interact with electrons and other subatomic particles and force carriers. Gravity interacts with basically everything, including the Higgs and photons. It's probable that gravitons do not interact with gravitons, and so there is nothing restricting gravity from exiting a black hole.

More interestingly, if gravitons interact with everything _except_ gravitons, then how are gravitons not blocked after they interact with _one_ thing, such as how we can put up basically anything as a wall against photons? The denser the item, the more photons are blocked. I believe this would apply to anything -- like with neutrinos, put a denser block, and you capture more of them. Except with gravity. It seems to hit the object, interact, and keep on going. (Maybe they just interact far more weakly than any known neutrino, and so many, many, MANY interact, and many magnitudes of order more make it through the object. Perhaps we _could_ place a wall against gravitons. I fear the resultant energy exerted on such a wall.)

SINCE gravitons interact with the matter _and_ energy in the black hole, it would seem the gravity, too, should never be able to escape -- but it does. But then, it feels like the gravity holding a planet together should interact with the planet, and never escape. But it does. Something feels wrong with the graviton.

My personal conundrums: the LHC creators said that any black holes created by the LHC would instantly evaporate. How? If nothing can escape a black hole, then the only energy that can be emitted from a block hole is the gravitons. But how can you get so many gravitons from even a small black hole that it will dissipate in a short time? It sems like even for infintessimally small black holes, it would remain around long enough to interact with _something_ -- and if it interacts with _anything_, then it has that much longer to achieve what it already has -- interaction with something else. Clearly this did not happen, which to me would suggest that there are no black holes. But how can they say that the black holes would evaporate?

It's actually fairly common for construction projects to run into changes. While nobody requests to turn a shed into a skyscraper, large changes that touch many disciplines occur quite regularly.

The difference between AEC and programming projects is a long history and legal framework that deals with these changes. Projects are given a budget, and that budget is often paid out at milestones--design development, 95%, construction documents, etc. If the owner requests a substantial change, or if a change is required because of unknowable circumstances, the budget is either revised or the work is value-engineered to fit--and this reality is reflected in the contract signed at the beginning.

The problem with programming projects is that there are not very many really good programmers, and programming is not suited to throwing more warm bodies at the problem. AEC is plate spinning, while programming is juggling. You can hire a bunch of folks to help keep the plates spinning, but you can't just send in somebody to help juggle.

If you don't like the 2nd Amendment, perhaps we can interest you in gutting the 1st Amendment?

Come come, now, we can all agree that those evil GUNS and evil VIDEO GAMES are ultimately culpable. Let's all come together and blame things that we don't like.

'Merica.

Auto-documentation is good stuff nowadays. Everything changes so much, and so quickly, that enforced documentation standards lead to better understanding of the underlying API or intent.

(As an example, why is PHP so popular? It's not because it's beautiful, or elegant. It is, however, very accessible, largely due to good documentation.)

Good comments--that are not prescriptive for whatever autodoc tool you use--are invaluable, but bad or marginal ones do more harm than good, especially in interpreted languages. You can condense 4 lines of comments into a 22-character, well-constructed function call/local variable and accomplish the same goal.

This is the answer, more or less. For small-to-middling forums, reducing spam is pretty easy. A few volunteers to delete the ones that get through suffices for the rest.

It breaks down to 1) keep out easy drive-by spammers, which means registration with a valid email address and some kind of barrier to detour the smarter bots (ReCaptcha and the like); 2) filter posts through Akismet or similar method; 3) have a community large enough and engaged enough to want to zero out spam posts.

The third step is the hardest, and has nothing to do with spam posts.