If you don't publish papers, you don't get funding. Sucks, but that's what we get for budget cut after budget cut, tax cut, after tax cut.

The big question appears to be if the latent infected cells can clear or deactivate HIV, or if they'll happily activate, travel to the site of an infection of some other kind, then start spewing HIV everywhere.

This process is basically cells realizing they are being infected (virus) or eaten (bacteria) by a foreign organism, and responding by killing themselves and spewing massive amounts of chemicals that alert the immune system to the problem. Normally, this recruits other immune cells to the site and is probably the right strategy 99% of the time. The problem is when the infected cells are immune cells themselves, their death just recruits more immune cells to an area with a higher chance of picking up HIV. What they found was that the body's stockpile of immune cells in the spleen, etc (normally dormant, awaiting an infection) get infected by HIV, but don't replicate the virus due to being inactive, however they are active enough to sense the virus in their DNA and kill themselves before repair mechanisms can remove or deactivate the virus genes.

The drug mentioned apparently shuts down or reduces this pathway, opening you up to a higher risk of bacterial infection but slowing or stopping the massive die-off of immune cells (assuming they are able to clean themselves up).

This isn't just wrong, it's laughably wrong. ZFS has proven that a wide variety of chipset bugs, firmware bugs, actual mechanical failure, etc are still present and actively corrupting our data. It applies to HDDs and flash. Worse, this corruption in most cases appears randomly over time so your proposal to verify the written data immediately is useless.

Prior to the widespread deployment of this new generation of check-summing filesystems, I made the same faulty assumption you made: that data isn't subject to bit rot and will reproduce what was written.

ZFS or BTRFS will disabuse you of these notions very quickly. (Be sure to turn on idle scrubbing).

It also appears that the error rate is roughly constant but storage densities are increasing, so the bit errors per GB stored per month are increasing as well.

Microsoft needs to move ReFS down to consumer euro ducts ASAP. BTRFS needs to become the Linux default FS. Apple needs to get with the program already and adopt a modern filesystem.

Apple's influence on the industry strikes again. Even if Apple isn't the first to take up some technology or improve a design, they are a trendsetter.

Once Apple ships magnetic power connectors that stop laptops from being pulled off desks or they ship a solid metal, reversible, extensible/future-proof connector, everyone else decides to jump on the bandwagon. Ultrabooks (read: MacBook Air clone) are another example.

Honestly, look at the USB 3 micro connector... it has to be the ugliest connector design ever imagined. They waited until after releasing that abomination on the world to suddenly decide reversibility and future-proofing were a good idea. I hope their wonderful redesign adopts the Lightning-style solid metal shape. The plug itself is much stronger, less subject to getting bent, smashed, etc, and naturally allows the socket to be sturdier. Smart moves when you are talking about a billion hairless apes smashing connectors into sockets as if they were rocks. How can you see the images of people putting coffee cups in their CD-ROM trays, busted-off mini-TOSlink connectors, etc and think any of the existing USB connectors are intelligently designed?

Apple thinks primarily about user's experience and is willing to toss legacy technology in the trash to streamline it. The USB-IF decided that USB 3 mircro had to be backwards-compatible with USB 2 micro so they just slapped a second port on the side and called it a day. If Apple makes a change, you're stuck with it so get over your floppy disk obsession and buy a USB memory stick. For everyone else, if Generic Vendor #9548 doesn't keep supporting your $9.99 USB 2 micro car charger, someone else will so any changes risk alienating users and failing to see any adoption, making manufacturers risk-averse.

When the first retina models went to soldered-on RAM, it was obviously that all MacBook Pros would ship this way in the future.

I miss the upgradability, but I ran the numbers on my non-retina 15" into which I installed two 512GB SSDs and 16GB RAM (the max you can do with two SODIMM slots due to current DRAM density and JDEC standards). It turns out that an equivalent retina MBP with 1TB SSD and 16 GB RAM is roughly the same price (within 10% of the cost).

Not having swappable batteries and RAM means you don't need a reinforced frame, rugged connectors, screw holes, and cover. That's all space that can be used for more battery and/or reducing size and weight. It's a trade-off, but ultimately I consider it to be worth it.

Plus I rather enjoy having a nice Mac OS GUI that I don't have to worry about, but can run macports and build Unix utilities from a terminal window.

This varies a lot by state. In Arizona, any excess is carried over into the next month to offset your usage at the retail rate. At the end of the year, if you still have excess then the excess is cashed out at the wholesale rate, which is far lower. In Texas, any excess is simply gifted to the power company for free.

In reality, almost no one generates enough solar to totally offset their bill because such a large panel install is still cost-prohibitive unless you are willing to make some large sacrifices on the usage side (and with your wallet). Further, solar generates its maximum energy during the most expensive peak hours (in the south/southwest, A/C is the largest electric load by far and matches up roughly with peak sunshine on most days). At that time of day, the utility may even pay more than your retail rate for at least a few hours due to high demand, resulting in free money for the utility!

If they made this fee contingent on zeroing out your bill then perhaps it would be justified (e.g.: if you had carryover, then they can deduct $5 from the carryover to pay for infrastructure). In Texas, it would never be justified because excess power is free to the utility.

The reality is they want to charge this fee to pad their profit margin. It really is that simple.

If a whole-home solar install ever got down to $10,000 (to cover 75-80% of the home's electric usage) you can expect to see utilities everywhere engaging in all sorts of nasty tricks to jack up fees, taxes, get burdensome regulations passed, etc to make sure the barriers to entry are still very high. At that price, all new homes will simply start including solar and it will become a common remodel ala replacing windows and floors. In that scenario, the $3 million+ they spent will pale in comparison to the flood of lobbying dollars.

Couple of details here:

Toyota had no software testing procedures, no peer review, etc. The secondary backup CPU code was provided by a third party in compiled form, Toyota never examined it.

Their coding standards were ad hoc and they failed to follow them. Simple static analysis tools found massive numbers of errors.

They used over ten thousand global variables, with numerous confirmed race conditions, nested locks, etc.

Their watchdog merely checked that the system was running and did not respond to task failures or CPU overload conditions so would not bother to reset the ECU, even if most of the tasks crashed. Since this is the basic function of a watchdog, they may as well not have had one.

They claimed to be using ECC memory but did not, so anything from single bit errors to whole page corruption were undetected and uncorrected.

A bunch of logic was jammed in one spaghetti task that was both responsible for calculating the throttle position, running various failsafes, and recording diagnostic error codes. Any failure of this task was undetected by the watchdog and disabled most of the failsafes. Due to no ECC and the stack issue below, a single bit error would turn off the runnable flag for this task and cause it to stop being scheduled for CPU time. No error codes would be recorded.

They did not do any logging (eg of OS task scheduler state, number of ECU resets, etc), not even in the event of a crash or ECU reset.

The code contained various recursive paths and no effort was made to prevent stack overflows. Worse, the RTOS kernel data structures were located immediately after the 4K stack, so stack overflows could smash these structures, including disabling tasks from running.

They were supposed to be using mirroring of variables to detect memory smashing/corruption (write A and XOR A to separate locations, then compare them on read to make sure they match). They were not doing this for some critical variables for some inexplicable reason, including the throttle position so any memory corruption could write a max throttle value and be undetected.

Instead of using the certified, audited version of the RTOS like most auto makers, they used an unverified version.

Thanks to not bothering to review the OS code, they had no idea the OS data structures were not mirrored. A single bit flip can start or stop a task, even a life-safety critical one.

These are just some of the massive glaring failures at every level of specifying, coding, and testing a safety-critical embedded system.

I am now confident in saying at least some of the unintended acceleration events with Toyota vehicles were caused by software failures due to gross incompetence and negligence on the part of Toyota. They stumbled into writing software, piling hack on top of hack, never bothering to implement any testing, peer review, documentation, specifications, or even the slightest hint that they even considered the software something worth noticing.

Total sales worldwide:

1989 - 2003 GameBoy / Color / Advance / SP: 200 million ~14.2m/yr
2004 - 2010 Nintendo DS: 153 million ~21.8m/yr
2011 - Present Nintendo 3DS / XL / 2DS: 32 million ~10.6m/yr

The GameBoy had a slower ramp up as handheld gaming started getting mainstream traction. Nintendo DS appears to have been the peak. Something happened during its release... around 2007 I think, though I'm having trouble recalling just what was released around then... oh wait, the iPhone followed shortly after by Android. The 3DS can't even match the GameBoy's sales figures and continues to fall.

The question is how big is the market for handheld gaming systems given that cell phones are eviscerating the market and a generation of kids is growing up without knowing who Nintendo is or why they should care (hint: more 10 year olds know what Angry Birds is than who Mario is!)

My contention is that the market is not large enough to sustain Nintendo's hardware development costs and they will be forced to exit the market after the next handheld system flops (or possibly the system after that). People who think everything is just fine must believe Nintendo can survive on ~2 million/year sales or possibly even less. If they do survive, the systems will be limited to almost entirely Nintendo games with relatively few 3rd party titles due to the small install base.

There is a short window of opportunity where those of us who grew up with Nintendo are young enough to buy games for nostalgia or are just starting to have kids and be looking to introduce them to gaming. If Nintendo were to release a Mario game designed for iOS now (and charge a premium price, say 7.99-9.99) we'd all buy it, sending it rocketing to the top of the charts. This would bring it to the notice of current young gamers, introducing a new generation to Nintendo characters, setting them up for sequels. Some of them might become hardcore Nintendo fans, willing to shell out for Nintendo hardware (controller accessories, cases, or even dedicated handheld gaming systems) thus expanding Nintendo's market. The point of Mario on iOS isn't to match the revenue of the 3DS; much like Google and Android, it exists to ensure their continued survival, access to the market, and expand their potential customer base and brand awareness. Once that window closes (sometime in the next 5 years), it may be gone forever.

TL;DR: My first kid was just born. I will never buy him a handheld gaming device, even though I owned a GameBoy, GB Color, and GB Advance in my day. I will just give him my old cell phone. The games are $1-10, if he drops it in the toilet I can just re-download his games for free, etc. Everyone I know with kids is doing the same thing. When I say "Mario" to my 7 yr old nephew, he asks me "Who's that?". You know what he does have? Angry Birds posters, because that's what all his friends have.

Does anyone know if they handle the look-alike issue or are we still stuck with URLs that appear to be latin "paypal.com", but with the "y" replaced by a greek lower gamma (Î) #x3b3, "p" replaced with cyrillic Er (Ñ) #x440, or some other equivalent that appears identical?

I understand why it's a hard issue: the cyrillic lowercase Er looks *identical* to latin p so they can be mapped to the same character, but the greek lower gamma isn't the exact same glyph as latin lower y, they just look close enough that a user might not notice. Would it be a slight to greek users to force greek domain names to use a misshapen lower gamma? Then what do you do with greek alpha, where the capital matches the latin glyph exactly but the lower does not?

Then there's the issue that every computer everywhere can enter latin characters, but not everyone has software for or how to use stuff like Chinese characters or Japanese Hirigana. Keeping to basic latin characters makes entering domain names universal, though I understand why that's convenient for an English speaker like me to say. I'd be curious to hear from some people who have non-European first languages how much having to use latin domain names seems to bother the average computer user and whether there is any actual cry for international domain names in their country? How difficult/easy is it to enter latin characters on your keyboard layout? Does it present a barrier to entry for the less educated/literate, or does everyone remember their English classes from school?

This may just be some crossed wires; the company tasked with handling the trademarks, legal papers, etc is just doing what they believe they are supposed to do: stop anyone from getting a Vendor ID, then subverting the normal USB process by sublicensing Product IDs. It is totally understandable that this would subvert the process and take control away from the USB-IF.

USB-IF does offer some VID blocks for testing, hobbyist, etc purposes.

They are also more than happy to sell you a VID block for $5000, even if you never bother to get a device certified or use the USB logo and trademarks.

What they are not currently setup to do is offer a "small" block at a cheaper price to someone who wants to sell a product commercially, but one that has a very limited run. It seems like they could easily set aside one VID for this purpose, then "subnet" that into different PID blocks. Offer a set of 10 PIDs for $100 for small companies. Would that not solve the problem?

You have to remember: USB-IF is not making money here; it is a non-profit itself. The fees go toward covering their costs.

The system appears secure; hacking it requires injecting your own certificate into the trusted roots on the device.

Further, forging messages requires you compromise the private key which is only contained on the device (Apple doesn't know it). The public key is submitted to Apple's push CA which generates a certificate. The public part of your key is what other devices see when they get a copy of your certificate. So far, so good.

The issue is, of course, that Apple controls the CA so in theory if the government ordered them to issue a certificate in your name to the government, the gov could then monitor your communications or forge your identity.

Apple claims not to be able to read iMessages and that appears to be true, and as far as I'm aware not even the Patriot act requires them to issue forged certificates (aka allow the government to impersonate you digitally). So insofar as the law works and is followed, there is no legal authority to compel Apple to issue bunk certificates.

For the curious, when you send a message it contacts Apple and requests the list of public certs for a given URI (telephone number, email address, etc). Apple responds with a list of the public certs issued to each of your registered devices, which the client then uses to send messages encrypted with that public key to each, and also signed with your own private key. The receiver does a similar lookup and uses your public key to validate the signature (proving you sent the message and that it was sent from the correct device even), then uses its own private key to decrypt the message you encrypted with the public key.

I'm not sure how this could be improved. No matter what you do, someone has to be in charge of saying "The certificate for mobile number xxx-yyy-zzzz is ..." and that gives you a chain of trust problem. The alternative is requiring every iMessage user to meet face-to-face to exchange keys before sending any messages.

Google can read your email!

Jabber servers can read your IMs! So can Yahoo! So can AOL!

Oh wait, this is Apple. Nevermind, carry on with the hysterics.

(FYI: No matter what scheme you devise, key management always gets you because if Apple doesn't have the keys, it makes iMessage much, much harder to use. If they do, then someone can snoop the messages. If you use a chain of trust, who ever sits at the top of the chain can be compromised. In an ideal world, people would learn about crypto keys and understand how to manage them, but you'd have to meet face to face to avoid mistaken identities).

Why is SciAm claiming the post was off-topic (clearly a bullshit excuse given other bloggers posts) then claiming it was due to legal reasons?

Oh and blaming not telling the author on poor cell phone reception... Right. Someone can click the delete button but can't be bothered to send an email?

It's just lies and more lies, a non-apology, and bullshit. I don't buy it for a second.

My bet: someone at biology online emailed SciAm to complain and SciAm was more than happy to censor Dr Lee. Now that they've been caught, they are furiously trying to backpedal and pretend it's all just a big misunderstanding.

I'm canceling my subscription, I don't want any part of such a two-faced crappy organization.

I cannot let this comment pass. Sorry, but anyone who's worked for a large corporate beauracracy knows this is nonsense. They are just as large, Byzantine, and wasteful. That's simply how large human organizations function.

If admins aren't allowed to check log files, what happens if you experience a hack? What if a new zero-day vulnerability is released during the shutdown? What if the server room AC goes out?

The only safe thing to do is shut it down until the Republicans stop trying to negotiate with a gun to everyone's head.

If you check the design, the fingerprint image itself is never stored anywhere. The fingerprint profile is only stored on silicon in the A7 chip. There is no API to access that data, only flags to tell you that it exists (so the OS can discover there are four stored prints and their names, but nothing about the actual fingerprints themselves).

Apple touts the fact that the fingerprint is never sent over the network as a feature but in reality it can't send it over the network even if it wants to, nor can any application access it.

If you think Apple is lying... well... There must be some level of trust somewhere or we may as well give up. I tend to draw the line at the CPU because if that is compromised or includes back doors, we are all screwed anyway.