You don't seem to be listening. I'm well aware of what PAE is for. As you seem to admit -- "Windows isn't keeping up with the basics." -- I'm simply pointing out that there is, in fact, a 4 GB memory limit in (most) versions of 32-bit Windows, PAE or no, and it exists for technical reasons. The technical reason is not "it's not possible to address more than 4 GB with PAE", but it's still a technical reason.
The problem is that the pointers *aren't* all 32-bit. Virtual address pointers are, so 32-bit processes don't have to care if it's PAE or not. Physical address pointers are longer than 32 bits. Drivers use physical address pointers. Drivers care whether you're using PAE. It's an easy problem to address if you can just recompile the driver, but this isn't an option for Microsoft. As a result, they limited physical memory on 32-bit systems to only 4 GB, even on PAE systems, so that even physical address pointers will fit in 32 bits. It's straightforward to understand and documented.
This is why you shouldn't run 32-bit Windows, even though it supports PAE.
There are many, many few third-party, binary-only drivers for 32-bit Linux, and I'd be willing to bet that a number of them don't work properly on PAE systems.
It's not that you can't have 32-bit PAE systems with more than 4 GB of memory, it's that precompiled third-party Windows drivers crash on such systems.
For that matter, a process can only use 2 or 3 GB of memory, since the kernel shares address space with the process. And the system as a whole can't have a full 4 GB of memory -- it's restricted to 4 GB of address space, some of which is consumed by device memory.
Note that some versions of Windows 2000, Windows Server 2003, and Windows Server 2008 lift this fake limit, allowing you to use more than 4 GB physical memory on 32-bit systems (with PAE).
This is all covered in Windows System Internals. You can also read a bit about the driver issues here.
However, PAE drivers have to use 64-bit physical addresses, or they won't work properly. In testing, Microsoft found that too many drivers crashed on PAE systems with more than 4 GB of memory, so they limited usable physical address space to 4 GB on PAE systems.
How "suboptimal" are you talking? Hopefully you're not simply trying to make the claim that an engine can't be optimized for two things at once. That's sort of how optimization goes.
You seem to be confusing a complete lesson on electromagnetic radiation with an experiment to determine the speed of light. An experiment only does the one thing, and the instructions are just for how to perform the experiment. (It is lacking in theoretical hints, but does tell you to look into standing waves.)
It's stated on the microwave (or in its documentation). They don't get that by knowing the speed of light, but rather by the construction of the device. You could build your own microwave generator to be sure, but assuming that the manufacturer is giving you the correct value is good for an estimate.
It depends on how the power is generated, of course. If it's something like coal, you're actually playing "efficiency of large-scale centralized power facilities".
You should use Disk Utility to create a large sparsebundle file. Sparsebundles play reasonably well with Time Machine (which is why they exist) -- although as far as I know there's no solution that is both ideal for Time Machine and also doesn't leak file metadata.
FileVault exclusively uses features present in the Disk Images framework (which you can access with hdiutil), except for the trick where it automatically mounts and dismounts the image when you log in and out, using your login password.
While the FileVault system is proprietary, all of the cryptography is just done through OpenSSL, and what cryptographic routines it uses are documented. (To be fair, they're not documented by Apple, they were reverse-engineered.)
I wouldn't call 128-bit AES "weak encryption", and FileVault supports 256-bit AES. The component that is weak is that you are required to use your login password as the FileVault password. FileVault only uses 1000-round PBKDF to generate a key from your password as it is, and elsewhere your password is hashed less securely, making a dictionary attack reasonable. There's also a second access key stored in the FileVault backup keychain.
The "get your space back" and "long waiting times at logout" seem to conflict. He claims that the long wait time is because unused space is recovered from the sparsebundle File Vault uses to back your home directory -- so you should have your space back. It seems unlikely that you need that space back *right now*, before you log out.
On the other hand, EncFS leaks a ton of metadata -- probably enough metadata for someone to get a very good idea of what your collection of files represent. (Granted, if you're not using full-disk encryption, you're leaking data into unencrypted space anyway.)
Red and blue shift are not caused by moving faster than the speed of light in the local medium (though Cherenkov radiation is), but rather by motion of the emitting object relative to the observer. (Not to mention cosmological and gravitational shifts.)
It shouldn't shock you to learn that the fundamental constants that influence the behavior that drives the clock are different from the fundamental constants whose change they're interested in measuring.
They're probably not permitted to guess what the proper orientation of technical drawings is.
I think it's interesting that all of the comments are "government workers are too stupid to rotate the fax" and not "patent attorneys are too stupid to use a fax machine properly". You know it must've been the patent attorney, because a secretary would've known how to send faxes right side up.
I actually said that: there's not an established toxicity for ethylmercury, it's thought to be less toxic than methylmercury, so the limits for methylmercury are used.
These are chronic exposure limits, though. It is acceptable to exceed the chronic exposure limit in a single day, provided the average over a reasonable time frame is still below the chronic exposure limit.
This is good news to eaters of tuna: the daily chronic exposure limit of methylmercury is met by a quarter pound of tuna.
Slashdot Mirror
You don't seem to be listening. I'm well aware of what PAE is for. As you seem to admit -- "Windows isn't keeping up with the basics." -- I'm simply pointing out that there is, in fact, a 4 GB memory limit in (most) versions of 32-bit Windows, PAE or no, and it exists for technical reasons. The technical reason is not "it's not possible to address more than 4 GB with PAE", but it's still a technical reason.
The problem is that the pointers *aren't* all 32-bit. Virtual address pointers are, so 32-bit processes don't have to care if it's PAE or not. Physical address pointers are longer than 32 bits. Drivers use physical address pointers. Drivers care whether you're using PAE. It's an easy problem to address if you can just recompile the driver, but this isn't an option for Microsoft. As a result, they limited physical memory on 32-bit systems to only 4 GB, even on PAE systems, so that even physical address pointers will fit in 32 bits. It's straightforward to understand and documented.
This is why you shouldn't run 32-bit Windows, even though it supports PAE.
There are many, many few third-party, binary-only drivers for 32-bit Linux, and I'd be willing to bet that a number of them don't work properly on PAE systems.
It's not that you can't have 32-bit PAE systems with more than 4 GB of memory, it's that precompiled third-party Windows drivers crash on such systems.
For that matter, a process can only use 2 or 3 GB of memory, since the kernel shares address space with the process. And the system as a whole can't have a full 4 GB of memory -- it's restricted to 4 GB of address space, some of which is consumed by device memory.
Note that some versions of Windows 2000, Windows Server 2003, and Windows Server 2008 lift this fake limit, allowing you to use more than 4 GB physical memory on 32-bit systems (with PAE).
This is all covered in Windows System Internals. You can also read a bit about the driver issues here.
However, PAE drivers have to use 64-bit physical addresses, or they won't work properly. In testing, Microsoft found that too many drivers crashed on PAE systems with more than 4 GB of memory, so they limited usable physical address space to 4 GB on PAE systems.
Well, as long as we're on the same page.
Great username, by the way!
There are only diminishing returns for people not on the ship. For the people on the ship, the returns are non-diminishing, due to time dilation.
I'm not convinced you actually understand how entanglement and quantum teleportation work. :-)
Probably the x-ray radiation produced would kill you before you got close enough to stand in front of it.
For large objects, that is. We regularly accelerate small particles to large fractions of lightspeed.
Free momentum going in the wrong direction!
How "suboptimal" are you talking? Hopefully you're not simply trying to make the claim that an engine can't be optimized for two things at once. That's sort of how optimization goes.
But effects that aren't homogeneous and monotonic are hard to understand!
That's true, mostly -- but the explanation of the theory is not part of the description of the experiment.
You seem to be confusing a complete lesson on electromagnetic radiation with an experiment to determine the speed of light. An experiment only does the one thing, and the instructions are just for how to perform the experiment. (It is lacking in theoretical hints, but does tell you to look into standing waves.)
It's stated on the microwave (or in its documentation). They don't get that by knowing the speed of light, but rather by the construction of the device. You could build your own microwave generator to be sure, but assuming that the manufacturer is giving you the correct value is good for an estimate.
It depends on how the power is generated, of course. If it's something like coal, you're actually playing "efficiency of large-scale centralized power facilities".
You should use Disk Utility to create a large sparsebundle file. Sparsebundles play reasonably well with Time Machine (which is why they exist) -- although as far as I know there's no solution that is both ideal for Time Machine and also doesn't leak file metadata.
FileVault exclusively uses features present in the Disk Images framework (which you can access with hdiutil), except for the trick where it automatically mounts and dismounts the image when you log in and out, using your login password.
While the FileVault system is proprietary, all of the cryptography is just done through OpenSSL, and what cryptographic routines it uses are documented. (To be fair, they're not documented by Apple, they were reverse-engineered.)
I wouldn't call 128-bit AES "weak encryption", and FileVault supports 256-bit AES. The component that is weak is that you are required to use your login password as the FileVault password. FileVault only uses 1000-round PBKDF to generate a key from your password as it is, and elsewhere your password is hashed less securely, making a dictionary attack reasonable. There's also a second access key stored in the FileVault backup keychain.
The "get your space back" and "long waiting times at logout" seem to conflict. He claims that the long wait time is because unused space is recovered from the sparsebundle File Vault uses to back your home directory -- so you should have your space back. It seems unlikely that you need that space back *right now*, before you log out.
On the other hand, EncFS leaks a ton of metadata -- probably enough metadata for someone to get a very good idea of what your collection of files represent. (Granted, if you're not using full-disk encryption, you're leaking data into unencrypted space anyway.)
The google search engine results pages page? What the hell is that?
Yes, but it's due to the pressure changes and release of dissolved CO2. :-)
You did not temporarily become autistic and then recover, and it doesn't sound like mercury at all.
Which the hell vaccinations did you have that even have thimerosal? Flu?
It's actually quite common to get sick from vaccinations, but that's due to the virus, not the preservative agent.
Red and blue shift are not caused by moving faster than the speed of light in the local medium (though Cherenkov radiation is), but rather by motion of the emitting object relative to the observer. (Not to mention cosmological and gravitational shifts.)
It shouldn't shock you to learn that the fundamental constants that influence the behavior that drives the clock are different from the fundamental constants whose change they're interested in measuring.
They're probably not permitted to guess what the proper orientation of technical drawings is.
I think it's interesting that all of the comments are "government workers are too stupid to rotate the fax" and not "patent attorneys are too stupid to use a fax machine properly". You know it must've been the patent attorney, because a secretary would've known how to send faxes right side up.
7 TeV is about a microjoule.
I actually said that: there's not an established toxicity for ethylmercury, it's thought to be less toxic than methylmercury, so the limits for methylmercury are used.
These are chronic exposure limits, though. It is acceptable to exceed the chronic exposure limit in a single day, provided the average over a reasonable time frame is still below the chronic exposure limit.
This is good news to eaters of tuna: the daily chronic exposure limit of methylmercury is met by a quarter pound of tuna.