While I'm not an expert in this field, messenger RNA, like all RNAs, is degraded by RNAses, and there's specific complexes of proteins (such as the exosome complex) that target messenger RNA specifically for destruction. If you don't have anything producing more mRNA in the cell, then, eventually the injected mRNA will be degraded and no more translation of it will occur. Because this vaccine isn't rewriting the cell's DNA (unlike the virus itself), there's nothing to produce further mRNA encoding the spike proteins.

The lifetime of mRNA in mammals ranges from a few minutes to a few days; the exact mechanism that controls the lifespan isn't well understood.

Given that this article is an opinion piece from Bloomberg from an author whose articles are about competitive pressures and stock prices in the technology sector, calling him or what he's proposing "socialist" is more than a bit of a stretch, I think.

Instead, I think it's more accurate to say Mr. Culpan is thinking of what will make for Shareholder Value, anti-trust laws be damned. That's not very "socialist" at all.

I remember those days. I was one of the paid community supporters before they went commercial, and when they did, I got free lifetime custom DNS service for a single domain as well as free lifetime premium service for dynamic DNS in the dyndns.org domain. The quality of Dyn as a provider, and their willingness to keep their end of that deal (unlike, say, Joyent), is why I use them as my registrar and why I've recommended them professionally despite the fact that there are far less expensive alternatives (such as AWS Route 53 or Azure DNS).

Shortly after the deal closes and integration begins, I expect that my lifetime service will be terminated ("to better serve our customers"), the cost will skyrocket (because this is Oracle we're talking about), and I'll be forced to move to another provider. It was fun while it lasted, I suppose...

Open Powershell as administrator and type:

set-executionpolicy unrestricted -scope localmachine -force

Alternatively, set it through Group Policy (Policies\Administrative Templates\Windows Components\Windows Powershell\Turn on Script Execution, set to "Allow all scripts").

When sold in Africa, or procured by other organizations, it can be acquired for about 24 cents per pill (International Drug Price Indicator Guide).

Without getting into the dark world of drug pricing, it's clear that $18.58 a pill, which nearly a 75x markup, is probably a wee bit too high, particularly for a drug whose two components aren't exactly on the cutting edge of anti-retroviral therapies.

Beyond the obvious problems with the concept (the cost of goods sold for the coils themselves, the extreme improbability of a kerosene-powered drone built by college students being able to make intercontinental flights, the fact that there's no way in hell the FAA or the State Department would permit such a flight, etc.), there's several big red flags on this that scream "scam:"

1. The creator of the project has put up two projects on KS before. The most recent, the "Banana Project," is either an attempt to troll or the sort of half-baked (pun intended) project I'd expect from someone who wants to get paid to buy a 3-D printer to screw around with. The earlier project, "Super Mario Bros. Z The Movie, was cancelled and pulled, presumably because Nintendo had an issue with some random guy creating what I can only imagine is an amateur animation project. This is not a good track record, especially since the more recent project is from just three months ago.
2. The creator has no information on his bio, has not backed any other projects, and has no other real information available. Accountability seems non-existent.
3. The photo of the putative tesla coil is a vague sketch. There's no other technical information on how they'll be built or what they'll look like. As for the drone, there's no information on how the drone will be built or how it will be controlled. There is no prototype, only hand-waving claims. This screams "vaporware." A good rule of thumb on KS is "never pledge to something unless there's at least a prototype."
4. The submitter of this Slashdot article is an "anonymous submitter." Who wants to bet that the submitter is actually "Trevor Nestor?"

This KS is an excellent example of a KS from which you want to stay far, far away. Most of the time, the KS community is pretty wise to these sorts of things, but I suppose the combination of "North Korea," "tesla coils," and submissions to Slashdot will lure people in. Don't be a sucker.

As much as people complain about its occasionally byzantine bureaucracy and its sometimes lapses into small-time corruption (such as giving open terms to the politically powerful), Memphis Light, Gas, and Water (MLGW) serves over 400k subscribers, rapidly fixes outages in a major metropolitan area prone to thunderstorm damage, repeatedly wins awards for reliability of service and water quality, and has a AA bond rating. It offers extremely favorable terms and payment programs for low-income subscribers. Oh, yeah, and it also has .

But hey, municipal utilities can't do anything right, right?

The problem isn't municipal utilities. The problem is poor process and intentional handicapping. When you have neither of these -- for instance, because your municipal utility is run as an independent organization with elected oversight that has actual skin in the game (after all, if you live in the city and use the utility, you have a good reason to not have it suck) -- the results are positive, and there's some great examples of how this works.

While I'm not a lawyer, I would assume that Microsoft would have to keep that promise by the principles of equitable and promissory estoppel. Reliance upon the promise (which has been around for several years now) is reasonable, and so Microsoft attempting to revoke it and sue would immediately cause damage to those who did so. I think an extremely strong argument could be made in court that the promise more or less permanently estops Microsoft from patent actions regarding the .NET Framework.

We use SCCM extensively at my office, and yes, it's entirely possible to tell it to reimage every single computer. You just need to target the deployment at "All Systems" and make it mandatory. My guess is that some admin picked the wrong collection, which is fairly easy to do in SCCM 2007 (2012 has Collection folders, which helps with that), and there's no warning messages -- just a summary of "this deployment is going to these devices, click Finish to do it." Of course, most other mass management tools assume that the admins know what they're doing, so they don't have much in the way of guard rails either.

One of the more obnoxious elements of SCCM is that there's no real way to recall a command you send out; clients pick up policy at periodic intervals, and without manual intervention, they'll just grab the policy and do what it says even if you kill the server in question. You can block deployments by taking down distribution points (if the clients can't grab content, they won't run the deployment), but you still have to be fairly quick about it to stop it.

What we do to prevent these sorts of disasters is implement process around the use of the ConfigMgr console and ensure only the people who know how to use it actually use it. To prevent an OS reimaging incident, our OS deployments go through a static set of collections by process and are always optional (requiring a manual touch, either at PXE boot or in the UI) except for a specific set of collections that are segregated in their own folder and have names and descriptions with scary words that make it clear what's going to happen. For instance, in our "Clean Reimage" folder, we have a collection that says, "Windows 7 Reimage (Clean, PXE, Forced)" with a description to the effect of, "*** A computer placed in this collection will be REIMAGED and LOSE ALL LOCAL DATA. Local state is NOT preserved or transferred. ***" If we were a larger IT organization, we'd probably use SCCM's role-based security to limit access to clean reimages to a specific group of people.

If you actually bother to read the Federal Register text, you can see in the second paragraph of the introduction that the JOBS Act, and this subsequent regulatory structure, only applies to crowdfunding where the reward is a security. It specifically explains that this is different from the current model of crowdfunding in the U.S., where the donors receive some "token of value" related to the project, not a share of future financial returns. The SEC isn't trying to regulate the current system, but is trying (as directed by that law) to allow crowdfunding where the donor award is a security; the current regulatory structure, based on the Securities Act, largely makes this sort of model impossible due to the various requirements of public offerings.

So, there's nothing to get up in arms about. This is just a move by the SEC to allow something that isn't currently permissible under U.S. law, not an attempt to "tax Kickstarter" or "regulate Indiegogo" or whatever other nonsense people claim.

You have programmers. You have multiple projects. They might be working offline. For this, you really need a Distributed Source Control system such as git or mercurial. I personally recommend mercurial as it's got good Windows tools (TortoiseHg and HgScc for Visual Studio integration). You can put your "pure" repository on your share, then have the programmers push to it -- or, better yet, have an "incoming" for each project to which anyone can push, then a "pure" to which only project leads have write access and into which they can push approved versions.

If, for some reason, you simply can't run source control, Windows offers Offline Files functionality that can sync individual folders if you set them up correctly. What this means is that you need to ditch this "shared drive" concept and set up your file shares correctly -- by which I mean having multiple shares, one for each project. Users then connect to the share in question and choose to make it offline, or you create drive maps and enforce offline files using group policy.

Actually, as the people who found the first RT jailbreak noticed, the only thing keeping Windows RT from running ARM compiled applications (which you can create in Visual Studio, even!) is a policy that mandates that only Microsoft-signed executables can run outside of the WinRT environment. If Microsoft removed that restriction by changing a single registry key, all of that compatibility would suddenly appear. In fact, .NET apps distributed in PE form and compiled for Any CPU would be able to run without being recompiled at all.

Yes. Turn off Secure Boot in the UEFI firmware menu (accessed through Advanced Startup), then boot off the USB Linux boot device of your choice. I expect a modern distribution of Linux will have drivers for most of the hardware inside the Pro. Alternatively, run it in Hyper-V (or VMware, or VirtualBox, or the hypervisor of your choice), since it's an x86 Windows 8 device with hardware virtualization support.

Only the RT has the "permanently locked" Secure Boot setting. The Pro is a full-fledged i5 device that can run Linux just fine.