Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here.
With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.
A physical memtransistor will be a lot faster than emulating it in software, but you'll also be limited by the original connections and design of the chip. Not as easy to reconfigure as writing new code.
This does suck, but you can actually use From: aliases if you set them up first in the Gmail interface. You also have to enable two factor auth. Hard to be too mad about spam fighting measures.
Yes they do. A Faraday cage is equally good at blocking radio waves going out as coming in. They don't protect against conducted emissions though - along a power cable for example - so they're not a complete solution.
The PWM backlight driver frequency should be much higher. This kind of effect is only perceptible at sub-kilohertz LED switching. The LEDs themselves are happy to be cycled into the megahertz, so the only reason for this on the Macbook is poor electronic design. A low frequency does provide reduced cost, slightly higher efficiency, and reduced auditory/RF noise emissions, but visual effect has to be top priority.
The article abstract (https://www.ncbi.nlm.nih.gov/pubmed/29176609) says that the old "nyquist density" sensor arrays were designed to capture the theoretical maximum amount of data present. But it turns out those models were wrong.
Yes, a user-mode driver is something you would write instead of a kernel mode driver, if you can. Kernel-mode code is the most powerful, but also poses the greatest security and stability threat to the computer, so Microsoft locks it down the hardest. If you don't need the extra power, you can write a use-mode driver that uses Microsoft-provided kernel components (Like Winusb.sys) and you don't have to go through the same security procedures.
A big problem with Youtube's three-strikes approach is that it's the same for all channels, big or small. It doesn't matter how much good content you've produced or how long you've been making it, if you get 3 strikes in a short period, your account is deleted, same as any channel.
So channels that produce a lot of content or upload videos quickly have to be more careful about what they upload. There's no credit for good behaviour or allowance for the extra risk channels take if they post lots of videos, potentially getting a strike with each one.
But little old me only uploads one or two videos a year. So I can afford to have every video copyright striked and I'll suffer no consequences since they expire in 6 months.
I think kernel mode drivers have more stringent signing requirements than user mode drivers. A user-installed CA definitely cannot be used to silently install a kernel mode driver.
My space engineering professor says for what he does (microsatellites mostly, but some science instruments for bigger satillites) they use off the shelf non-radiation hardened parts mostly, and get their reliability though software and hardware redundancy.
This article says that it's easier and better for companies to keep their unfair compensation schemes private than risk employee unhappiness by making them transparent.
Sure, it's easier and better for companies to keep their dirty laundry hidden, but it's better for employees. That's the whole point of transparency: to see the unfairness, and to work to fix it. And if you don't fix it, you won't be able to attract talent.
The concern is that a lot of behaviour that a security researcher would do in the course of their research, taking over C&C server addresses such as with Wannacry, soliciting for samples of malware, such as Hutchins did with the Kronos trojan, and having contacts with black-hat hackers, might look to the DOJ as if he is the culprit who created the malware.
People think that an innocent white hat hacker could get swept up in this kind of arrest, and there has been so little evidence released, nobody knows what actually happened.
The 18 core i9-7980XE is widely thought[1] to be a direct response to the 16 core Threadripper announcement. It was announced late, with much less info. It has a expected release date months later than the rest of the i9 lineup, and is using higher core count silicon that Intel has previously only ever used in Xeons.