False and false. Relativity matters when you care about nanosecond timing.

I suppose it's up to the manufacturer, but I'd be very surprised if anyone did. The ChromeOS firmware is designed so that, if you flip the switch back out of developer mode, it prompts you to confirm that it's going to wipe the disk and that you need to provide it with a signed OS image to install. The whole idea of the dev-mode switch is that, no matter what you've done to a ChromeOS device software-wise, you can always get it back to a pristine state. (AIUI, the firmware itself cannot be overwritten by the OS or the user, even in developer mode.)

Disclaimer: I work at Google but not on ChromeOS, Chrome, or anything remotely related to that, so I have no particular insider knowledge of it. I am the owner of an Acer AC700 Chromebook, however, purchased of my own free will. (I did boot the thing into developer mode once, out of curiosity, then I put it back.)

I suppose a manufacturer could go by different rules, but ChromeOS is specced to the manufacturers such that there's no way to brick it so bad you can't reimage back to the pristine signed-boot OS. (Unlike the OS, the bootloader isn't user-replaceable AIUI.) And the hardware is really not that different from a PC. It would be roughly equivalent to a PC maker refusing to honor your hardware warranty because you booted a Linux LiveCD once. Stranger things have happened, I suppose, but I would expect such a manufacturer to lose in court.

Disclaimer: I work at Google but not on ChromeOS, Chrome, or anything remotely related to that, so I have no particular insider knowledge of it. I am the owner of an Acer AC700 Chromebook, however, purchased of my own free will. (Principal complaint: the AC700 was sloooow. But it ran Netflix... so long as you weren't hoping to go fullscreen without stutter. Oh, and the built-in SSH terminal blew chunks; the new Secure Shell app is still rough but far better.)

Chrome uses a passphrase to encrypt sync data. By default it will use your Google account password, but you can change it to use any passphrase. If the Chrome devs are doing it right, they should be running the passphrase through PBKDF2 to derive an AES symmetric key. It's worth noting, though, that the Dashboard for "Chrome sync" shows counts for the number of synced items of each type. Assuming they're doing the crypto correctly, I see only two ways the Dashboard could know those numbers: (a) if Chome sends the counts in plaintext as part of the sync, or (b) if the items are individually encrypted (which is generally a bad idea due to known plaintext).

I do know from personal experience that you're SOL if you lose the Chrome sync passphrase (or if you simply want to change it). You have to click the "Stop sync and delete data from Google" link in the Dashboard, wait 5 or 10 minutes for the delete to finish, then set up sync again for all your Chrome instances. Oh, and Chrome sync still doesn't support OAuth login, so setting up sync is a pain if you have 2-factor auth set up on your account (as you should).

Disclaimer: I happen to work at Google, but I don't interact with Chrome except as a user. I'm using knowledge gleaned only from using Chrome sync with my personal account.

No, that's actually not bad. Online cost of living calculators don't grok SF. When I moved to SF 5 years ago for a tech job I started out on $75k/year, and I did fine for myself living solo. Sure, you're probably going to drop an extra $15k-$20k/year on rent -- I moved into a ~650ft 1BR apartment for $2100/month, a bit of a premium for a good neighborhood -- but Craigslist is booming with roommate offers, and most other living expenses are about the same as other cities. Utilities are less (milder weather), eating out is more (higher wages, trendier places), groceries are the same. Entertainment is less (lots of free/cheap shows) but there's more of it, so you may wind up spending more.

Beyond rent, the only other thing that's noticeably more expensive than elsewhere is car ownership; parking garage fees of $300/month aren't uncommon if you work downtown and expect to park there every day, and there's the perennial delight of California gas prices if you're moving from out of state. But even before costing out the parking surprise, a $65/month Muni "M" pass is hella cheaper than gas + insurance + maintenance for owning your own car anyway. Throw in a ~$4/month ZipCar annual membership (partially or fully subsidized by some employers) and you can still have access to a car when transit won't cut it; the rental itself runs about $12/hour, which includes the cost of gas, insurance, and all the maintenance headaches. Even without an employer subsidy, that annual ZipCar fee is 1/3 the price of a WoW subscription, i.e. totally worth it at $75k/year.

Not quite. You've never had the experience of remembering having done something, then having someone contradict you, then asking around and finding out that your memory is faulty? If you were certain of your memory, no finite amount of evidence would ever convince you that you were mistaken. Your example instead demonstrates that we pick the most probable (most "familiar") explanation without conscious consideration of alternatives, and we only backtrack to alternatives when the first explanation is sufficiently falsified to demote it from the best explanation.

That's not to say that this has any bearing on Judea Pearl's research into causal networks. Causal networks complement a probabilistic approach, as each causal node operates on purely Bayesian principles; the only difference is the added operation of graph surgery to represent counterfactuals. It's certainly true that the naïve extension of Bayesian probability to a decision theory (Evidential Decision Theory) is silly -- it results in "Speeding on the way to work is correlated with being late to work, therefore if I don't speed I can't be late!", and it's also true that causal graphs naïvely extend to a decision theory (Causal Decision Theory) that fixes the most egregious silliness. But Bayesian probability is still a key piece of CDT, and even CDT doesn't fix everything (look up Newcomb's paradox).

Uh, no. MaCHOs were supposed to be Jupiter-size to brown dwarf-size lumps of mass, careening through galaxies without being associated with stars or other luminous matter. A black hole *can* count as a MaCHO *if* it has no accretion disk, but we think most black holes have accretion disks and therefore emit X-rays (and thus don't count as dark matter). This black hole is firmly in the not-a-MaCHO category; for that matter, what we today know about Big Bang baryogenesis pretty strongly rules out MaCHOs being the dominant type of dark matter, so they've mostly fallen by the wayside in modern cosmological thinking.

Believe me, that's a risk I worry about every day. But I recently discovered that there are other frequencies that can cause such damage! I now refuse to allow my family within a mile of any restaurant with so-called "heat lamps" (or as I prefer, "death lamps"), and I'm seriously considering banning from my household anything that emits between 400 and 790 THz. I heard one of my neighbors actually bought an Easy-Bake Oven for their kids. An Easy-Bake Oven! Won't somebody please think of the children?

(Seriously, though, if you pour significantly more than a kilowatt per meter square of EM into living tissue, you're gonna have a bad time. There are a handful of cases, e.g. VHF, where you might be able to bump that figure by an order of magnitude (maaaybe two) because humans are reasonably transparent at those frequencies. But as a rule of thumb, all non-ionizing EM from visible light down cooks you the same way.)

Uhh, that sounds like an extremely convoluted reinvention of TCP SACK (RFC 2018) using some knockoff of Reed-Solomon instead of, y'know, "I got packets 1-4 and 6-10, please retransmit #5".

The scheme you describe is a Message Authentication Code, not a salted hash. If you use a salted hash when you actually need a MAC, you're potentially compromising your system's security.

You don't bring nukes to a knife fight. Sure, you win the knife fight, but now everyone else knows to nuke you first and ask questions later.

No, that's "non-coding DNA". The Ars Technica article has a very nice Venn diagram. In short, we infer that most non-coding DNA is junk DNA because it shows signs of neutral drift (i.e. it doesn't matter to reproductive fitness), but non-coding DNA is different from junk DNA, and regulatory DNA is always non-coding but can be either junk or non-junk.

Some concrete examples (with Venn diagram colors in parens):

• Coding DNA that isn't junk (white): a gene.
• Coding DNA that is junk (blue): an endogenous retrovirus.
• Regulatory non-coding DNA that isn't junk (orange/yellow): a promoter for a gene.
• Regulatory non-coding DNA that is junk (orange/yellow/blue): a promoter for a pseudogene.
• Non-regulatory non-coding DNA that isn't junk (yellow): hmm... an intron, I guess.
• Non-regulatory non-coding DNA that is junk (yellow/blue): the letters "CGG" 30 times in a row on the X chromosome. (See aside below for more info.)

(Terminology: a "pseudogene" is a gene damaged so badly by frame shifts or early stop codons that it can't code for protein anymore. Before they break and become pseudogenes, they're often duplicates of some existing gene, which is why breaking them can be fitness-neutral. DNA transposons and sloppy cross-overs in meiosis make gene duplication reasonably common. Gene duplication is important for evolution as well: duplicated genes are free to mutate in random directions until they stumble on a new useful function, with the original free to keep the old one. For instance, the vertebrate blood clotting cascade was clearly formed from several rounds of dupe-then-mutate, and similarly with the huge family of myosin muscle proteins.)

(Terminology: an "intron" is a stretch of DNA that gets snipped out of the resulting RNA before the RNA can code for protein. It's not quite junk: an intron has recognition signals that say "please cut RNA here", and IIRC the intron needs to have roughly the correct length, but most of the intron is arbitrary nonsense. Some genes have alternative splices, where the same gene can code for different proteins by swapping in different coding regions -- "exons" -- like lego bricks. Alternative splices are important in the immune system, for instance: they're how antibodies work. And the alternative splicing stuff wouldn't be possible without introns, including the nonsense filler that helpfully spaces out the exons so the splice enzymes can operate correctly.)

(Aside: long sequences of repetitive DNA can trip up the DNA polymerase enzyme that copies DNA, causing the stretch of DNA to lengthen itself in the next generation... and the longer it gets, the better the chance is that DNA polymerase will screw up and make it longer still. The ...CGG-CGG-CGG... sequence I mentioned has about 30 repeats in healthy individuals; but if the number of repeats climbs high enough, it causes Fragile X syndrome. Apparently the nucleus tries to silence the repeat by attaching methyl groups (CH3), which is standard procedure in the nucleus for turning off misbehaving DNA, but methylation isn't terribly precise and a nearby promoter happens to live nearby. This promoter is responsible for a nearby gene that's important in brain development; if the promoter is silenced by methylation, the reduced gene expression causes a form of severe autism.)

Er... I stand corrected: http://www.ssa.gov/history/hfaq.html Q20.

SSNs are recycled. They're only unique among the living.