It's not clear, but "as the hosted OSes run natively on Intel" is almost certainly referring to the fact that your VMs must be x86(-64) and not some other architecture.
Considering a major concern is that the non-sensitive system becomes compromised, running the sensitive system as a VM within the non-sensitive system isn't a very good plan. A compromised host can trivially compromise a guest.
Running the sensitive system as the host works, but it means that the sensitive system is always running. Running both systems as VMs under a host OS that's not used for anything else is a better solution, but is more resource-hungry. This lets you turn off the sensitive system when you're not using it, which is particularly useful if you're using encrypted storage for it (as you should).
Depending on the virtualization software, setting up the networking as OP requested could be a bit of a pain.
The only reason any other OS can read HFS+ is because someone reverse-engineered the structure and wrote drivers.
As someone who has done exactly that: there's very little reverse engineering involved. The main points of the filesystem are well-documented in Tech Note 1150. For the newer features and some details, you need to look at the publicly-available kernel source. A few features, like file compression, are not well-documented and require reverse engineering, though you can get pretty far with existing third-party documentation (like the Singh book).
I mean there are a lot of open-source software projects relevant to their interests that are conspicuously lacking in attribution. REDHAWK, for example.
Encryption implemented in hardware is fast. Note that there are plenty of embedded devices that do encryption and decryption at high bit rates (Blu-ray player, HDCP endpoint, encrypted hard disk, link-layer network encryption).
A fast flash storage card for a camera has a write speed of about 100 MB/s. It's pretty easy to get hardware AES implementations that are around a gigabit/sec.
CPUs are slow to perform encryption because it's a lot of bit-level modification. CPUs don't have the instructions necessary to do those operations efficiently. That's why they added AES-specific instructions to x86. You can implement encryption in hardware, though, in which case it is very fast. High performance in hardware implementations is a major design feature -- it was required in DES, and it was required in AES.
It's not just overkill, it's ineffective. Encryption is to create confidentiality: making an unauthorized party unable to obtain the information contained in the message. Encrypting a public database is worthless. If you're making it publicly accessible, there are no unauthorized parties. (This is different from encrypting the data transmissions of users, which is done to prevent third parties from learning what data is being accessed by a particular user.)
What you'd want to prevent unauthorized tampering is authenticity and integrity controls, like digital signatures.
A company, BitTorrent, created a piece of software, BitTorrent, which used the protocol, BitTorrent, for P2P filesharing.
The BitTorrent company at least was created by the guy who created the BitTorrent protocol. I think their early "BitTorrent" software was not, however, the original implementation of that protocol. (Don't quote me on those facts, I'm going off of memory here.)
Later, BitTorrent the company bought/licensed the uTorrent software and distributed it under the name "BitTorrent". (They mercifully incremented the major version number and stopped distributing their earlier software.)
Also perhaps interesting- do men whose gender are not made apparent statistically do better than those who do?
You know the study itself is a pretty short read, right?
Anyway, yes. Everyone, both male and female, who have "gender-neutral" GitHub profiles had pull requests accepted at a higher rate than everyone who had "gendered" profiles. The difference between gendered vs. gender-neutral profile was larger than the difference between genders. Note that all that is for "outsiders" -- insiders have a higher acceptance rate overall with seemingly little difference between (male, female) x (gendered, gender-neutral).
It doesn't appear that the study considered "pointing out their gender" at all.
Rather, they tried to determine whether the gender of a GitHub profile was readily apparent.
Per the description of their methodology, if you use a profile image (rather than an identicon), you are automatically considered "gender is readily apparent". If that test fails, they look at the confidence level output by a gender-guessing bot of some kind. If that fails, they have a method for estimating the confidence level of a panel of three humans.
Chart on page 10 is completely acceptable. It contains a lot of data, all of which is constrained to the 60-90% range, the range is clear, and the chart isn't really deceiving.
Page 13 similarly has a lot of data and doesn't really deceive. All extending the bars down to 0% and up to 100% would do is make it harder to read. However, it would work better as a table.
Chart on page 15 is a standard example of data that doesn't need a bar chart. Even with the narrowed range, most differences are difficult to see. Here, the major visual message is that insiders get pull requests accepted much more than outsiders, but it's not as big a difference as it seems. Unfortunately, that's not what's interesting about the data -- it's that outsider females whose gender is apparent have a lower acceptance rate than males, but outsider females whose gender isn't apparent have a higher acceptance rate, while insiders seem to be nearly gender-agnostic in both cases. (One wonders why the acceptance rate for non-gender-apparent outsiders of either gender is significantly higher than for gender-apparent outsiders of either gender.) This would all be much better displayed in a table.
Let's say the US banned strong encryption tomorrow. What's to stop someone in another country from posting the source code to a strong encryption scheme?
Maybe he realizes that this is part of how we got rid of "export grade" encryption in the US. Everyone was just writing software in a foreign country and people were importing it. Once you have the Internet, you can't realistically regulate software imports. Not if you're the US and the software is free. So export-grade encryption became simply a penalty for US businesses with little practical effect. At that point, you might as well accept it and change the laws to get rid of the business penalty.
I respectfully disagree re: safety, for various reasons, but it's a moot point. To my knowledge, the backscatter has been completely eliminated now (it was done gradually), as has the "nudie" mode of the microwave scanners. I've seen that cited as justification for this policy change. Which seems fair to me -- those were legitimate concerns that one should be able to use to opt out, but those concerns have been eliminated.
The microwave scanner system actually seems pretty decent. You can see the monitor that they see. The only problem I've had is that it's really sensitive -- not only do you need to completely empty all pockets, but moderately baggy jeans will easily set it off, virtually guaranteeing a pat-down.
Hill had the ability to pay her taxes and didn't. They will jail you for choosing not to pay them. They can't jail you just because you don't have the money to pay them. They can, as you point out, take all your stuff, plus your future stuff, which is ugly.
they will put you in prison unless you get some dollars to pay them with
We eliminated debtor's prisons in this country, actually. While individual states and smaller jurisdictions are, recently, pushing at the borders of this principle, the Federal government still follows it. You can be jailed for cheating the IRS, but you can't actually be jailed just for owing them money.
It's immigration (and emigration) whenever a group of people migrate from one region to another, regardless of what the reason is or how they're treated.
It's a little bit of a tricky word territory because it would be inaccurate to call them "immigrants". That word is usually used in modern English to refer to non-forced migration, so could make the reader draw inaccurate conclusions.
It is, though, completely reasonable to put the event under a discussion of "Patterns of Immigration", because that is clearly referring to large-scale movements of people with important sociological and historical impacts. Historically, many major human migrations have been the result of slavery, exile, genocide, and other such unpleasant and rather non-voluntary reasons. They're still called migrations.
According to this article (okay, okay, the summary), GPS error causes measured distances to be systematically overestimated.
What you're talking about -- a different but noticeable factor -- is that GPS polling frequency causes measured distances to be systematically underestimated. Because it's only sampling once every N seconds and then, because there's quite a bit of noise, applying a smoothing function to the result, it cuts the corners off of paths. It can cause pretty substantial underestimation, even when moving relatively slowly along gently curved paths.
Bullshit. Exposure to RF is inducing cancer because it randomly changes DNA. The dose does not matter in this effect.
Bullshit. Wavelength is not a dose.
Long-wavelength RF, below the ionization threshold, does not cause cancer because it lacks the energy necessary to "randomly change DNA". You're right, the dose doesn't matter -- sub-ionization RF doesn't cause cancer.
Slashdot Mirror
It's not clear, but "as the hosted OSes run natively on Intel" is almost certainly referring to the fact that your VMs must be x86(-64) and not some other architecture.
Considering a major concern is that the non-sensitive system becomes compromised, running the sensitive system as a VM within the non-sensitive system isn't a very good plan. A compromised host can trivially compromise a guest.
Running the sensitive system as the host works, but it means that the sensitive system is always running. Running both systems as VMs under a host OS that's not used for anything else is a better solution, but is more resource-hungry. This lets you turn off the sensitive system when you're not using it, which is particularly useful if you're using encrypted storage for it (as you should).
Depending on the virtualization software, setting up the networking as OP requested could be a bit of a pain.
Use afl.
The only reason any other OS can read HFS+ is because someone reverse-engineered the structure and wrote drivers.
As someone who has done exactly that: there's very little reverse engineering involved. The main points of the filesystem are well-documented in Tech Note 1150. For the newer features and some details, you need to look at the publicly-available kernel source. A few features, like file compression, are not well-documented and require reverse engineering, though you can get pretty far with existing third-party documentation (like the Singh book).
I mean there are a lot of open-source software projects relevant to their interests that are conspicuously lacking in attribution. REDHAWK, for example.
Probably, but that's a completely different organization.
FYI, they've had things on Github for a while. Just maybe not under the NSA name.
Encryption implemented in hardware is fast. Note that there are plenty of embedded devices that do encryption and decryption at high bit rates (Blu-ray player, HDCP endpoint, encrypted hard disk, link-layer network encryption).
A fast flash storage card for a camera has a write speed of about 100 MB/s. It's pretty easy to get hardware AES implementations that are around a gigabit/sec.
Cameras already use processors that have nearly the feature set of a general-purpose CPU. (Canon's DIGIC is x86, and DIGIC II is ARM.) They run actual firmware. In fact, they often run an embedded operating system (e.g., VxWorks). That firmware can implement arbitrary features. Take as an example. You can see in the source code that it is not, in fact, simply enabling and disabling existing functions.
CPUs are slow to perform encryption because it's a lot of bit-level modification. CPUs don't have the instructions necessary to do those operations efficiently. That's why they added AES-specific instructions to x86. You can implement encryption in hardware, though, in which case it is very fast. High performance in hardware implementations is a major design feature -- it was required in DES, and it was required in AES.
To detect tampering? (If so, that's overkill.)
It's not just overkill, it's ineffective. Encryption is to create confidentiality: making an unauthorized party unable to obtain the information contained in the message. Encrypting a public database is worthless. If you're making it publicly accessible, there are no unauthorized parties. (This is different from encrypting the data transmissions of users, which is done to prevent third parties from learning what data is being accessed by a particular user.)
What you'd want to prevent unauthorized tampering is authenticity and integrity controls, like digital signatures.
A company, BitTorrent, created a piece of software, BitTorrent, which used the protocol, BitTorrent, for P2P filesharing.
The BitTorrent company at least was created by the guy who created the BitTorrent protocol. I think their early "BitTorrent" software was not, however, the original implementation of that protocol. (Don't quote me on those facts, I'm going off of memory here.)
Later, BitTorrent the company bought/licensed the uTorrent software and distributed it under the name "BitTorrent". (They mercifully incremented the major version number and stopped distributing their earlier software.)
It's not the best naming system.
The margin of error is that little sideways H in the middle of the bar on the chart.
Also perhaps interesting- do men whose gender are not made apparent statistically do better than those who do?
You know the study itself is a pretty short read, right?
Anyway, yes. Everyone, both male and female, who have "gender-neutral" GitHub profiles had pull requests accepted at a higher rate than everyone who had "gendered" profiles. The difference between gendered vs. gender-neutral profile was larger than the difference between genders. Note that all that is for "outsiders" -- insiders have a higher acceptance rate overall with seemingly little difference between (male, female) x (gendered, gender-neutral).
It doesn't appear that the study considered "pointing out their gender" at all.
Rather, they tried to determine whether the gender of a GitHub profile was readily apparent.
Per the description of their methodology, if you use a profile image (rather than an identicon), you are automatically considered "gender is readily apparent". If that test fails, they look at the confidence level output by a gender-guessing bot of some kind. If that fails, they have a method for estimating the confidence level of a panel of three humans.
Chart on page 10 is completely acceptable. It contains a lot of data, all of which is constrained to the 60-90% range, the range is clear, and the chart isn't really deceiving.
Page 13 similarly has a lot of data and doesn't really deceive. All extending the bars down to 0% and up to 100% would do is make it harder to read. However, it would work better as a table.
Chart on page 15 is a standard example of data that doesn't need a bar chart. Even with the narrowed range, most differences are difficult to see. Here, the major visual message is that insiders get pull requests accepted much more than outsiders, but it's not as big a difference as it seems. Unfortunately, that's not what's interesting about the data -- it's that outsider females whose gender is apparent have a lower acceptance rate than males, but outsider females whose gender isn't apparent have a higher acceptance rate, while insiders seem to be nearly gender-agnostic in both cases. (One wonders why the acceptance rate for non-gender-apparent outsiders of either gender is significantly higher than for gender-apparent outsiders of either gender.) This would all be much better displayed in a table.
Let's say the US banned strong encryption tomorrow. What's to stop someone in another country from posting the source code to a strong encryption scheme?
Maybe he realizes that this is part of how we got rid of "export grade" encryption in the US. Everyone was just writing software in a foreign country and people were importing it. Once you have the Internet, you can't realistically regulate software imports. Not if you're the US and the software is free. So export-grade encryption became simply a penalty for US businesses with little practical effect. At that point, you might as well accept it and change the laws to get rid of the business penalty.
I respectfully disagree re: safety, for various reasons, but it's a moot point. To my knowledge, the backscatter has been completely eliminated now (it was done gradually), as has the "nudie" mode of the microwave scanners. I've seen that cited as justification for this policy change. Which seems fair to me -- those were legitimate concerns that one should be able to use to opt out, but those concerns have been eliminated.
The microwave scanner system actually seems pretty decent. You can see the monitor that they see. The only problem I've had is that it's really sensitive -- not only do you need to completely empty all pockets, but moderately baggy jeans will easily set it off, virtually guaranteeing a pat-down.
They've removed all of the backscatter devices already.
Hill had the ability to pay her taxes and didn't. They will jail you for choosing not to pay them. They can't jail you just because you don't have the money to pay them. They can, as you point out, take all your stuff, plus your future stuff, which is ugly.
they will put you in prison unless you get some dollars to pay them with
We eliminated debtor's prisons in this country, actually. While individual states and smaller jurisdictions are, recently, pushing at the borders of this principle, the Federal government still follows it. You can be jailed for cheating the IRS, but you can't actually be jailed just for owing them money.
It's immigration (and emigration) whenever a group of people migrate from one region to another, regardless of what the reason is or how they're treated.
It's a little bit of a tricky word territory because it would be inaccurate to call them "immigrants". That word is usually used in modern English to refer to non-forced migration, so could make the reader draw inaccurate conclusions.
It is, though, completely reasonable to put the event under a discussion of "Patterns of Immigration", because that is clearly referring to large-scale movements of people with important sociological and historical impacts. Historically, many major human migrations have been the result of slavery, exile, genocide, and other such unpleasant and rather non-voluntary reasons. They're still called migrations.
According to this article (okay, okay, the summary), GPS error causes measured distances to be systematically overestimated.
What you're talking about -- a different but noticeable factor -- is that GPS polling frequency causes measured distances to be systematically underestimated. Because it's only sampling once every N seconds and then, because there's quite a bit of noise, applying a smoothing function to the result, it cuts the corners off of paths. It can cause pretty substantial underestimation, even when moving relatively slowly along gently curved paths.
They'll probably call it CyberUL.
Neither visible light nor RF at the cm-wavelength scale are ionizing, and so cannot cause DNA damage.
Ultraviolet light causes skin cancer because it is both ionizing and has a short penetration depth.
Bullshit. Exposure to RF is inducing cancer because it randomly changes DNA. The dose does not matter in this effect.
Bullshit. Wavelength is not a dose.
Long-wavelength RF, below the ionization threshold, does not cause cancer because it lacks the energy necessary to "randomly change DNA". You're right, the dose doesn't matter -- sub-ionization RF doesn't cause cancer.