Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment Re:Without disabling the warranty? (Score 1) 372

Yes, you can flip a "developer mode" switch to disable the hardware lockdown

Does the developer mode switch also disable the warranty on the hardware? If I have flipped the developer mode switch, and the power connector wears out, am I out the full cost of replacement?

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.)

Comment Re:But will it still be warranted? (Score 1) 372

I could do it; I just worry about whether I'd be able to get hardware problems fixed under the manufacturer's warranty after having done it.

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.)

Comment Re:I miss Firefox in this regard (Score 1) 102

I like firefox though. They tell you you are SOL without the passkey. I have no idea how Chrome encrypts. It looks like it is linked to your google account. Google could easily be holding all the keys.

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.

Comment Re:tech is a fairly broad category (Score 1) 660

BTW 80k to start in SF seems pretty horrible considering the cost of living there [...]

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.

Comment Re:Just more of the same (Score 1) 162

[...] If you read the word Bayesian in this sentence, you know for certain that you did. There is nothing probabilistic about it. [...]

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).

Comment Re:Not that odd... (Score 2) 65

This is just an example of a MaCHO. We've theorized about them for a while. They are a strong candidate for a bulk of the dark matter we've detected. The other candidates are WIMPs.

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.

Comment Re:1st (Score 1) 96

If the microwave radiation is strong enough, it definitely is going to cause skin damage (and also a bit below the skin), by simply boiling the tissue.

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.)

Comment Re:This is cool. But... (Score 1) 357

If the 5th packet was lost, in standard TCP you'd need to retransmit packets 5-10. With this encoding, you could in theory transmit only 1 packet to complete the set, regardless of which was lost, based on how the new ACKs describe the algebraic degrees of freedom remaining in solving for the original packet bytes. That means that you put out 11 packets instead of 15 packets into the same noisy environment, and the existing TCP window controls perceive less losses.

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".

Comment Re:Favorite quote from the article (Score 1) 34

Not that I'm a pro or anything, but junk DNA was anything that didn't encode proteins, right?

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.)

Science

Submission + - "80% Functional" Includes Junk DNA After All

CTachyon writes: "Last week the ENCODE project published a suite of papers, which were announced to the press with a claim that 80% of the human genome is "functional". But according to Ars Technica's science editor John Timmer, himself a Ph.D. in Molecular and Cell Biology, most of what you read was wrong: in their papers, the ENCODE team redefined the word "functional" so that known junk DNA (such as dormant viruses and broken pseudogenes) would meet the definition; and what's more, Timmer accuses individual ENCODE scientists of fostering confusion, rather than clearly explaining the semantic bait-and-switch."

Slashdot Top Deals

They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- Carl Sagan

Working...