"The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."

Throwing tents into dumpsters, without issuing a 'vacate or your property is forfeit' order seems like a clear violation to a non-lawyer.

Lawyers? Or have I simply missed something requiring the demonstrators to disperse?

No new code (except in the rare case where you are writing a tool to migrate stuff out of the VirtualStore into a new unprivileged user data directory) should reference the VirtualStore. That was created because ignorant devs couldn't wrap their heads around ACLs and didn't listen when MS told them that there's things out there that aren't admins.

This will absolutely not make its way downstream into an existing RHEL release. Maybe future releases.

I agree the wow64 fs and registry direction is confusing as hell. With the benefit of hindsight, I suspect they would have designed that differently (I will just assume it was fundamentally possible, if a bit more work in the short term.)

c:\winnt vs c:\windows vs c:\win vs e:\foo are all theoretically valid windows directories, though. That's why windows has an API for finding the Windows directory.

Red Hat jumped the shark in 1997. Once you go slack, you never look back. You do continue to look forward, though.

While I imagine there are liekly cases where that statement about performance is true, I have generally not seen a performance boon from building 32-bits on 64-bit OSes.

I don't see why linux can't adapt to these boot protection schemes. Self-signed or vendor signed, as long as there's a way to import your key information, what's the issue? Frankly, code signing is a good thing, especially if you can perform it from the ground up.

I understand the anxiety, here, especially given that Sinofsky is not a popular figure and nobody wants to trust any initiative he backs. That having been said, MS (and partners) would be opening themselves up to swift antitrust action again if they were to engage in industrywide attempts to lock out OtherOS.

It's also important to recognize that there are deployments out there where people WOULD like systems where you CAN'T disable secure boot, and have really stringent protections around the boot process. It is unlikely that this type of configuration is one that would be used in the general consumer market; there's too much of a need for boot media and utility software. Imagine not being able to run memcheck or a recovery tool, ever.

Now, really, we need to hear this kind of language from BIOS, mobo, and ready-built systems manufacturers. Overall, an initiative like this is a good thing, but everybody needs to be on the same page. Not foaming at the mouth.

His assumptions about the nature of information sharing and privacy are dangerously wrong.

The problem of information sharing is inequity; if it turns out that he documents his presence at a laundromat on some random dull October day, and later it turns out that some terrorists used to meet up there, his documentation of that random laundromat appearance will put him under scrutiny all over again - without any concrete reason. Meanwhile, some other fellow who rode his bike and paid with cash and didn't document his life on the web will probably never be scrutinized.

There is a fundamental issue with all mass intelligence/data collection: Humans don't understand conditional probabilities.

When we start to use large databases of essentially random data to inform investigations, we greatly increase the likelihood that investigations impact random people.

> You have been able to do this in C for the past twelve years.

While I imagine there may be a way to convince cl.exe to make its peace with c99, it's not immediately obvious to me what it is.
There are other minor conveniences you get, as well.

Windows is C and C++, but mostly C. All native Windows interfaces are C interfaces. Even the COM ones.

Native code in Windows is mostly written in both C and C++, in that you will see both .c and .cpp files, but since all DLL interfaces in Windows are C interfaces (C++ interfaces basically require you to be using the same compiler, though you can use COM to wrap C++ classes to build portable OO interfaces), even the .cpp files tend to be more C-like than C++-like.

There are C++ developers at Microsoft who do very ninja C++ things. But for the most part, people using .cpp files might as well be using C - many people just use .cpp so that they can declare variables in the middle of a scope. Some people have a class they internally use to do state management or implement some algorithm.

Basically, the common reason for use of .cpp is to get language features that increase readability. Very little in richly decorated in C++-but-not-COM faces outward, even in small internal components. I won't say none, because I never conducted an audit to check.

Source: me, worked in Windows for 4 years and change.

Rubber hose cryptography is not unbeatable, but you need to build around that expectation.

More likely:
If my notaries disagree, let me know. Then you can make a decision - whether it's the BOFA problem (thousands of certs), or a genuine anomoly.

Ignoring the lack of a #4, #1 is not always present, and #2 may be confused with #3.

Here's the reality: You fucking sue the TSA if they ever do this to your possessions. The TSA should be experts on bombs, and it should be their job to be professionals at identifying bombs. The fact that they can't only proves their negligence.

You don't get to decide whether something is or isn't dangerous when you haven't got a 12-year old's knowledge of electronics.

you realize that neither of those have anything to do with opendns?