I wondered that myself. There would be great value if the bacteria could be engineered to maintain a limited population so the host would get a baseline supply of insulin. They would probably still require injections to keep well regulated, but it would be less and with reduced consequences if they were unable to do that for a time.

Perhaps it could even be enough to let a type I diabetic manage their blood sugar more like a type II sufferer.

One is modifying bacteria in a lab to produce a vital medication. The other is modifying plants growing out in the open to make them produce pesticides that they swear won't hurt us when we eat them.

I'm still mad they moved HOVER! to be just a web extension... bastards.

[I]n this context I trust Microsoft about as far as I could throw a heavy old steel-cased 1980s PC.

Being careful with your data isn't just a Microsoft thing. My views of Microsoft and Google are pretty much diametrically opposed -- I have enormous faith in Google and Googlers doing the right thing with respect to protecting the data I share with them, but even in the case of Google -- with whom I share a great deal of data -- I'm selective about what I do share.

Anti-Microsoft, pro-Google, and no stated reason for faith in one "doing the right thing with respect to protecting the data" while the other, apparently, will not.

Except for this:

You may have heard concerns about the sharing of Wi-Fi passwords by Win10. This is largely not a problem in practice, given the details of the implementation.

How this suffices for posting on Slashdot with the headline tease "Privacy Mess" eludes me. Google = Bing. Google Drive = OneDrive. Chrome = Win 8+ windows-account-synced favorites and settings. Pot and Kettle both the same color, black or otherwise.

Excellent question. My first guesses would be that either the Samsung SSDs were doing something a bit out-of-specs, or the Samsung SSDs have something that's missing from other SSDs.

From TFS: "The vendor of the drive did not matter and the previous blacklisting of Samsung drives for broken queued trim support can be most likely lifted after further tests."

If the vendor of the drive does not matter in testing, then there is no relevant difference in specification compliance or other "somethings." It's purely a matter of which anecdotes gain what traction within a small population of users using md raid with multiple SSDs in a raid 0 or 10 configuration, and which of those users circumstantially has the best contacts within the development community.

My first guess is the users trying that configuration were purchasing the fastest available SSDs, which tend to be Samsung drives (large market share) or boutique manufacturers (small market share).

Devices working perfectly in other OSes is no indicator that the device is no at fault. Witness the vast amount of crap laptop hardware, whose disastrous ACPI implementations only worked because their Windows drivers were chock-full of workarounds.

It certainly is an indicator. I think you mean to say "is not conclusive evidence."

But then again, disastrous ACPI implementations are not conclusive evidence that a whole different type of device is at fault.

Your reasoning falls into the very trap GP was pointing out.

"WALP, LINUX IS PERFECT, MUST BE THE HARDWARE GUYS, even though their devices perform perfectly on other OSes"

It was even better. The alleged reason that the hardware didn't fail on other OSes such as Microsoft Windows was that Microsoft had conspired with Samsung to cover up its hardware bugs -- i.e., Microsoft implemented both standard-TRIM support and broken-TRIM support.

No evidence whatsoever that this mechanism existed, but Microsoft engineers must have figured it out and then kept super-duper quiet about changes to their own filesystem-to-device-driver-to-SATA communications chain in order to keep the Linux plebes down.

It's not odd at all.

I wish mine would.

I live in a town with 2500 residents, and I can almost swear that we have at least as many streetlights. From my house (on a street that's literally 4 house-property-sized-lots long), I can count 8 streetlights visible from the property, front and back.

It seems that for things like that, rather than bright streetlights, simple lighted markers should suffice.

"Interested" != Shipping Product.

Call me when they come out with it.

Sadly, they usually get promoted to project management... :(

Good call - you cant' write shitty code if you're stuck in meetings all day. ;)

In all seriousness though, there is a solution against featurization:

1) maintain main product as usual w/ a team dedicated to it.
2) build plugins and/or add-on packages for it that incorporate the new features that management craves. Charge some small nominal price to cover dev costs and maybe a few pennies above that.
3) if the add-ons or plugins really sell (or at least have a ton of demonstrable interest), you incorporate them into the next version of your main product and charge accordingly.
4) features that do not get used as often anymore, or become obsolete, can be refactored or removed.

This way you have a nice darwinian approach... and features that fail to get public attention (and more importantly, their commitment in money and/or time) are the perfect platform from which to point back at management and laugh derisively... but more importantly, they just go away. The ones that succeed improves the product.

It's a method that gets used successfully in a lot of products (usually CG/graphics related ones, though vSphere w/ sVMotion also stands out here), so why is this approach so frickin' hard to grasp for most dev teams?

Actually, I meant in the other sense. The American public has a right to know that an agency of it's government is illegally spying on them. The public has no such overriding interest in the personal details of federal employees.

It could, of course, be that they reviewed the benefits and risks and drew their own conclusions which sometimes match the consensus and sometimes don't.