Seriously, did the roaches actually evolve and pass it to their young, or did the specific roaches which HAD the sugar aversion trait simply avoid being poisoned and passed along said aversion to their offspring?

I'm kinda thinking it's the latter.

I use all three daily! Dual-boot Windows 7 and Ubuntu on my desktop at home. MacBook Pro at work (no boot-camp), along-side a RHEL 5 desktop, Ubuntu laptop, and a Windows 7 desktop. Where I work, folks regularly use two OSes between their laptops (Win/Mac/Ubuntu) and development desktops.

Thus, there really was no migration path, unless you count giving up Windows 7 for a Mac 4 years ago as my primary work machine.

Despite export controls, one has to wonder if they'd be better off protecting themselves w/ encryption on these drives, in case of undesired interception. It's unfortunate that encryption bans can't distinguish between malicious government intent and citizens avoiding the restrictions applied by the same oppressive government.

You'd be mistaken. The large company I work for has indeed learned from these mistakes.

I find it hard to believe anyone who maintains such a large fleet of services wouldn't have setup some sort of trivial monitoring (I know they own a product or two) that would include SSL Certificate expiration warning. 30+ days out, a ticket (or some sort of actionable tracking mechanism) should have been generated, alerting those responsible to start taking action. Said ticket should have become progressively higher severity as the expiration date loomed (meaning nothing had been updated), which in any sane company, would have implied higher and higher visibility.

That way, if an extensive test plan for such a simple operation was required, they had plenty of time to execute upon it and still not miss the boat.

Working with MS in other ways, and combined with both the lack of foresight and inability to act quickly, just shows that this sort of customer-forward thinking just doesn't exist inside the MS mind.

I'm not the OP, but in my case, At least 7GB of the ~13GB available on /sdcard (partition, not actual removable media) in my Nexus S is music which I listen to on occasion - mostly in my car or on a flight. The balance (when closer to full) is pictures before transferring to local network or cloud storage or Apps installed to USB (no longer required for Nexus 4's monolothic partition), etc. Amazon MP3 with CloudDrive storage solves the balance of my music problem (you don't have to marry yourself to Google Play for everything). For most, it's simply silly to carry around your entire collection. It's unlikely you'll want all of it available, thus learning to place effective selection criteria when picking what goes to your device helps manage the size constraint.

Personally, I'd feel constrained by 8GB, but not by 16GB once you realize that even 8GB of "music" is more than anyone needs unless they're spending a TON of time away from the balance of their library. What will put the squeeze on things are 8MP photos and full HD video. Provided I can offload my photos to cloud storage (via Wifi thanks) or home storage, I can live with this level of storage. Thus, I'll be buying the 16GB version to replace my Nexus S.

Now if they had 32GB at $429, this would be a compelling compromise/price point, and would shut down many of the "it's too small" comments.

There's a bit missing in those details. $299 buys the 8GB version, and $349 buys the 16GB version. There is no 32GB version, and a CDMA/LTE version was not announced - these are solely Pentaband HSPA+ devices for now. Or... you can ultimately pay more and go T-Mobile subsidized if you can't handle that much out of pocket at once with $199 out of pocket and $20/mo in subsidies for at least 20 months (Value plan, or $20 more/mo for the plan in general over Value for 2 years if Classic plan).

Amazon and Nook are all about consuming content. Initial tear-downs of the Kindle Fire purported them to be built at a loss, or at the very least, sold "at-cost". The profits are in App sales, Kindle books, Newsstand subscriptions, and Music/Video content.

Thus, if their consumers are running iPad minis, Amazon already has most of that taken care of. There's a Kindle app for iPhone and iPad, and they've recently released the Cloud Player (music) for iPhone and Amazon Instant Video app for iPad. Those loyal to their content will still be consuming it, regardless of the device. Amazon doesn't have a foothold in all facets of iPad like they do in Kindle Fire or other Android devices (i.e. Appstore), but it's "good enough", right?

To a lesser extent, same applies for B&N. NOOK apps are available for both.

Now the risk for both of these companies is those who aren't loyal to a content provider and the default presence of iTunes.

I'd argue that the income wasn't tax free. eBay will will report significant amounts of income (>200 transactions or > $20,000) on a 1099-K form, which started in 2011. Either way, someone knew about the income at that point.

This is probably a bit of hindsight advice, but try to understand the license you choose for your work before releasing under said license. Releasing code under GPLv2 w/o understanding how downstream "users" can legally use it doesn't help when you have to question the legality of someone charging money for the work. If they provide the source and attribution to your work, they're good to go.

If this wasn't the intended use, then consider a different license that more agrees with the ideals which the code was released under. Granted - if you reassign your code to AGPL or something of that sort, many people will either not comply or avoid the work entirely to avoid needing to disclose *their* surrounding source too.

::rimshot::

No, seriously - depending on the cloud service, aren't buckets of data encrypted in such a way that only the owner of the data can access them? Cloud service providers may be required to hand over data, but do they have the means of handing over the encryption keys along with it?

For certain cloud services where you're uploading via browser, they may be encrypting your data post-upload, so the request to decrypt may be more trivial. However, if you manage your own (like S3 backups) - or simply use a service that encrypts BEFORE uploading, I'm not sure there's a whole lot Amazon or some other provider could do to hand over the data in any usable form.

Those who are concerned about security of their data should ensure that the backup is encrypted in an acceptable method, or simply stash it in an encrypted container before storing it "online" (I realize there may be limitations of scale with that suggestion).

Bit reducing the video, and capturing core audio (DD out of TrueHD, for example) works just fine for most movies. On most displays you won't notice the difference at a constant quality of RF21 or 22 (using HandBrake in an .h264 encoded MKV as an example). I can tolerate a few GB in storage compared to the whole deal. When I want the full experience, then I'll break out the actual disc, but my kids don't care if some of Tinkerbell's finest detail is slightly obscured through compression, when the trade-off is that they can pick any movie we own any time w/o damaging the original disc.

Obligatory Wikipedia link: http://en.wikipedia.org/wiki/ZigBee

802.15.4 defines the standard that these guys are using - also known as ZigBee. ZigBee is a lower powered WPAN type of "mesh" networking used in things like smart building communications.

There are generally two options for frequency - "900MHz" and "2.4GHz". They operate in a mesh network typically (or virtual star), but usually do so at lower powers. What isn't being fully called out is that most 2.4GHz devices will cause nasty interference to Zigbee, since they typically run at lower powers (0dBm or 1mW) at channel widths of 5MHz (802.11b/g/n uses 20MHz channels by default), using similar encoding as the older 802.11b protocol. Most consumer WiFi routers run between 40mW to 100mW (~16dBm to 20dBm). 1mW (0dBm) will most likely look like noise to WiFi. If the meter operator was considerate, they'd pick one of the few channels that lies between or just outside the typical WiFi 1, 6, or 11 spaces (eff those guys who use channel "3" or "10"). That all said, if the meters are using a ZigBee Pro implementation, they may be transmitting at a much higher level - up to 100mW (20dBm), which would be quite intrusive to WiFi if using a ZigBee channel that overlaps WiFi. Anyone affected by that would HAVE to use a different channel if the meter or meters were constantly transmitting.

In my profession, I'm part of a team that supports the deployment and operation of some very large warehouse WiFi deployments (both 2.4GHz and 5GHz), and thus we're quite protective of the 2.4GHz band within the four walls. I can't tell you how often we've been approached by people who want to deploy ZigBee building controls in this band, each time refusing them since we know we'll make each other's lives miserable. Our 802.11 operation will likely render their equipment useless. We let them know that 900MHz or wired RS422 are both fantastic options in this case.

I bet the power company didn't consider the alternatives... or just didn't know and/or care. Not everyone is an RF expert, and the "wireless" buzz-word wins in may board rooms especially if it saves money.

Maybe instead of a monetary donation to CentOS, consider providing a server mirror to help the cause. May be cheaper than "paying" for Red Hat, and it goes to further the cause.

When it comes to support - consultants are great for implementation. However, if you've got a really large installation and start running into obscure kernel bugs or other software problems unique to your installation, you'll need kernel engineers or other higher caliber software developers or systems engineers to really deep-dive the problem. Red Hat can provide that with support subscriptions (or one-time incidents). Can't say the same for CentOS - you're at the mercy of the community.

Same goes for rapid-paced updates to zero-day problems. Chances are, you're going to get a fix a lot sooner from Red Hat than you would from CentOS.

Do I leverage CentOS for small projects - absolutely. But I understand that while it's 99% Red Hat code, it's not Red Hat in every respect.