That's correct, unless you build a very, very good scanner that can safely unpack even clever packers (which you can do, to an extent, with virtualization trickery). Signature detection really only weeds out the less-advanced malware (or very common trojans).
Fortunately, some of the better virus scaners actually unpack the software before checking it, or look for valid virus signatures instead of a simple Packer.
Unfortunately, advanced packers can detect this and can unpack differently if they are being unpacked by a virus scanner. Part of the point of using a packer for a virus is its ability to disguise the signature, so looking for a signature without unpacking is pointless.
USB storage devices aren't actually eligible for AutoPlay. However, if the device presents itself as if it were, say, a CD-ROM, it is. This is how the U3 devices work, which present both a "CD" and a USB disk. The operating system can't really enforce policies on how USB devices present themselves to the system.
Also, my Vista machine, by default, does not actually run the AutoPlay executable without user confirmation.
Seems more likely to be libel, but in order to be libel, you'd need to show that it was untrue. As the statement about the RIAA is an opinion, that seems unlikely.
Not only did I not say anything about other attacks, but hashing passwords is probably the second-least-interesting application of a hash algorithm. None of the attacks against common hashes (MD5, SHA1) are even applicable to passwords. (The least interesting application is its use as a checksum.)
What does slow down a guessing attack is increasing the computational requirements of generating the hash, as is done with multi-round PBKDF. Alternately, all guessing attacks are rendered useless by selecting passwords out of a space that has sufficiently large entropy -- however, that's largely a nontechnical problem.
Not strictly true. Rainbow tables are only feasible for very small inputs -- like 8-character-or-less passwords. Salting makes the minimum input larger (much larger, since salts are usually full binary, wheras password characters are almost always out of a small subset of possible characters). Of course, rainbow tables are absolutely useless if what you're hashing is, say, an entire file for a digital signature.
I don't know how much benefit adaptive resolution would really get you -- in these cases, you could assume that the render time was cheap, and the limiting resolution was always the hardware. You basically need the same level of resolution everywhere in the goggles, since you have good freedom of vision. (If you had large-FoV goggles, you could have a lower resolution at the edges, where you can't focus effectively, but I don't know of anyone that makes such a thing.)
The really headache-inducing part was the eye tracking -- using your eye motion and focus to perform an actual, intentional task instead of their natural habit. It was quite disconcerting, very difficult to properly control, and ended up causing eyestrain and headache.
The head-tracking is actually reasonable comfortable, provided the VR is done properly. Poorly-done VR will give you a headache from not using a natural focus, and a long time in goggles isn't all that pleasant anyway, as you have reasonably low-resolution screens very near your eyes, which is more fatiguing than one might imagine.
Someone, somewhere is doing it wrong. VR goggles should work fine if you're farsighted. The actual location of the display isn't what matters, it's the distance your eyes need to focus to in order to bring the image into focus. With proper image separation, you should be able to focus on "distant" objects in VR goggles.
On the other hand, often, focusing on any object for someone with normal eyesight using VR goggles is challenging.
I've only seen up to 1024x768 or so, which, since they subtend a much larger portion of your view than a monitor, have much lower resolution than a 1024x768 monitor.
I'm mostly familiar with the hardware we had, which also had a narrow field of view. I don't offhand of any goggles that provide a wider field. I suspect from things that I've read and seen demo'd that there are some floating around out there.
Now, head and eye tracking we did a fair bit of. Head tracking works very well. Eye tracking, on the other hand, was quite tricky to get working properly and particularly tricky to calibrate. We had a 3D version of Asteroids where you looked at asteroids to blow them up. Using eye-tracking turns out to be difficult and headache-inducing. If I were to come up with a system similar to yours, I would make window focus based on head tracking rather than eye tracking. At the very least, you need to combine looking at a window with some non-eye action to focus it -- your eyes wander a lot, and the jitter in eye trackers doesn't help.
While I appreciate that VR stuff is both cool and fun, I seriously would not use it as a replacement for a monitor on everyday work. Visualizations that are designed to be used on a VR display, sure, but regular windows running things like Web browsers? You may very well end up half-blind with a splitting headache in a matter of hours.
The Clemson VR lab uses (or used, at least) Linux workstations to run provide input to their VR goggles. Compatibility shouldn't be an issue, but you basically have to provide content yourself -- things won't automatically be cool. We didn't even use any kind of support in the drivers -- the goggles were two 640x480 screens, but were treated as a single 1280x480 screen. We just used OpenGL to draw two versions of our scenes from slightly different positions and presented them side-by-side so that they mapped properly onto the goggles.
Note: VR goggles are not actually cool to use. They're remarkably uncomfortable, both for your head and your eyes, and they have terrible resolution.
Not only that -- while I'm no Microsoft fan, Windows Update is practically the best update system, from a security standpoint. Everyone running Windows has it, the software source is tightly controlled, and their security is well-done. Having all of their products under a single blanket update prevents you from running the Windows updates but not the IE updates, for example, and limits proliferation of background updater tasks.
There are plenty of valid complaints about IE security, but lack of an auto-update mechanism is not one of them.
Interesting that you bother to quote that, as a) this would not involve Congress in any way b) no law would be made c) the freedom of speech would not be abridged and d) nor would the freedom of press.
I'm not going to bother surveying the democratic nations to see if that statement is accurate. However, your claim is that "by [his] logic, Clinton shouldn't have president either..." because they received a plurality, not a majority. However, his logic -- regardless of whether or not I find it particularly sound -- was not "because that's what other nations do". So, what other nations do with their popular votes doesn't really come in to play here. However, we have plenty of direct popular votes in the U.S., just not for, among other things, President. In nearly all of these elections, the condition for victory is plurality, not majority.
Don't confuse "by [his] logic" with by *your* logic in order to make a snotty point about your opinion on majority vs. plurality.
(For the record, I favor direct popular vote with IRV, but think that as we do have an electoral college, claims that X "should have won" are nonsense.)
There is a global crack (theoretically). BD+ is just software supplied on the disk that runs on your hardware and enables proper interpretation of the data on the disk. There is nothing, theoretically, preventing you from completely emulating a valid BD+ runtime environment or otherwise obtaining the information necessary to properly interpret the data from the supplied software. It's very difficult, since they in essence controlling a component of your hardware by selling Blu-Ray readers containing a proprietary runtime, the behavior of which is not disclosed to you.
Well, okay. I'm fairly certain he didn't actually think you make $12k/hr. But he did entirely misinterpret your numbers.
After the fact, I realized it'd be more reasonable to multiply $3000 by (8 hrs / 15 min) to get your salary, but then I wouldn't have an hourly figure to compare to $12k/hr. Hourly rate depends a little bit on how many days per year are actually worked.
That's not a feature, that's a side effect. Some types of failure cause the liquid helium to warm up until the magnet is no longer at superconducting temperatures. This causes a sudden resistance, which can damage the magnet, heats the whole system up (boiling off the coolant), et cetera. MRI systems generally have an emergency shutoff feature, the side effect of which is magnet quenching.
In this case, a quench is what happened -- resistance in the circuit caused helium boiloff, which destroyed superconductivity. They have many safeguards for this, as this was well-known before the first MRI or superconducting collider was built. Release valves allow the boiling helium to escape, and resistor banks are used to draw off electrical energy from the system. However, their system wasn't sufficient to handle the level of failure that occured.
I'm well aware of that -- that's what I've said elsewhere.
The computer forensic people we have are professionals and generally do not defer to private-industry professionals. But of course there are few of them, there's not much funding for more of them, and they have a huge work backlog.
Slashdot Mirror
It's pretty tough to sandbox things like debug registers.
Both World of Warcraft and PayPal have (optional) two-factor authentication.
That's correct, unless you build a very, very good scanner that can safely unpack even clever packers (which you can do, to an extent, with virtualization trickery). Signature detection really only weeds out the less-advanced malware (or very common trojans).
Fortunately, some of the better virus scaners actually unpack the software before checking it, or look for valid virus signatures instead of a simple Packer.
Unfortunately, advanced packers can detect this and can unpack differently if they are being unpacked by a virus scanner. Part of the point of using a packer for a virus is its ability to disguise the signature, so looking for a signature without unpacking is pointless.
USB storage devices aren't actually eligible for AutoPlay. However, if the device presents itself as if it were, say, a CD-ROM, it is. This is how the U3 devices work, which present both a "CD" and a USB disk. The operating system can't really enforce policies on how USB devices present themselves to the system.
Also, my Vista machine, by default, does not actually run the AutoPlay executable without user confirmation.
Malware, no. Rootkits, yes.
Seems more likely to be libel, but in order to be libel, you'd need to show that it was untrue. As the statement about the RIAA is an opinion, that seems unlikely.
Not only did I not say anything about other attacks, but hashing passwords is probably the second-least-interesting application of a hash algorithm. None of the attacks against common hashes (MD5, SHA1) are even applicable to passwords. (The least interesting application is its use as a checksum.)
What does slow down a guessing attack is increasing the computational requirements of generating the hash, as is done with multi-round PBKDF. Alternately, all guessing attacks are rendered useless by selecting passwords out of a space that has sufficiently large entropy -- however, that's largely a nontechnical problem.
Not strictly true. Rainbow tables are only feasible for very small inputs -- like 8-character-or-less passwords. Salting makes the minimum input larger (much larger, since salts are usually full binary, wheras password characters are almost always out of a small subset of possible characters). Of course, rainbow tables are absolutely useless if what you're hashing is, say, an entire file for a digital signature.
I don't know how much benefit adaptive resolution would really get you -- in these cases, you could assume that the render time was cheap, and the limiting resolution was always the hardware. You basically need the same level of resolution everywhere in the goggles, since you have good freedom of vision. (If you had large-FoV goggles, you could have a lower resolution at the edges, where you can't focus effectively, but I don't know of anyone that makes such a thing.)
The really headache-inducing part was the eye tracking -- using your eye motion and focus to perform an actual, intentional task instead of their natural habit. It was quite disconcerting, very difficult to properly control, and ended up causing eyestrain and headache.
The head-tracking is actually reasonable comfortable, provided the VR is done properly. Poorly-done VR will give you a headache from not using a natural focus, and a long time in goggles isn't all that pleasant anyway, as you have reasonably low-resolution screens very near your eyes, which is more fatiguing than one might imagine.
Someone, somewhere is doing it wrong. VR goggles should work fine if you're farsighted. The actual location of the display isn't what matters, it's the distance your eyes need to focus to in order to bring the image into focus. With proper image separation, you should be able to focus on "distant" objects in VR goggles.
On the other hand, often, focusing on any object for someone with normal eyesight using VR goggles is challenging.
I've only seen up to 1024x768 or so, which, since they subtend a much larger portion of your view than a monitor, have much lower resolution than a 1024x768 monitor.
I'm mostly familiar with the hardware we had, which also had a narrow field of view. I don't offhand of any goggles that provide a wider field. I suspect from things that I've read and seen demo'd that there are some floating around out there.
Now, head and eye tracking we did a fair bit of. Head tracking works very well. Eye tracking, on the other hand, was quite tricky to get working properly and particularly tricky to calibrate. We had a 3D version of Asteroids where you looked at asteroids to blow them up. Using eye-tracking turns out to be difficult and headache-inducing. If I were to come up with a system similar to yours, I would make window focus based on head tracking rather than eye tracking. At the very least, you need to combine looking at a window with some non-eye action to focus it -- your eyes wander a lot, and the jitter in eye trackers doesn't help.
While I appreciate that VR stuff is both cool and fun, I seriously would not use it as a replacement for a monitor on everyday work. Visualizations that are designed to be used on a VR display, sure, but regular windows running things like Web browsers? You may very well end up half-blind with a splitting headache in a matter of hours.
The Clemson VR lab uses (or used, at least) Linux workstations to run provide input to their VR goggles. Compatibility shouldn't be an issue, but you basically have to provide content yourself -- things won't automatically be cool. We didn't even use any kind of support in the drivers -- the goggles were two 640x480 screens, but were treated as a single 1280x480 screen. We just used OpenGL to draw two versions of our scenes from slightly different positions and presented them side-by-side so that they mapped properly onto the goggles.
Note: VR goggles are not actually cool to use. They're remarkably uncomfortable, both for your head and your eyes, and they have terrible resolution.
Not only that -- while I'm no Microsoft fan, Windows Update is practically the best update system, from a security standpoint. Everyone running Windows has it, the software source is tightly controlled, and their security is well-done. Having all of their products under a single blanket update prevents you from running the Windows updates but not the IE updates, for example, and limits proliferation of background updater tasks.
There are plenty of valid complaints about IE security, but lack of an auto-update mechanism is not one of them.
Interesting that you bother to quote that, as
a) this would not involve Congress in any way
b) no law would be made
c) the freedom of speech would not be abridged
and
d) nor would the freedom of press.
I'm not going to bother surveying the democratic nations to see if that statement is accurate. However, your claim is that "by [his] logic, Clinton shouldn't have president either..." because they received a plurality, not a majority. However, his logic -- regardless of whether or not I find it particularly sound -- was not "because that's what other nations do". So, what other nations do with their popular votes doesn't really come in to play here. However, we have plenty of direct popular votes in the U.S., just not for, among other things, President. In nearly all of these elections, the condition for victory is plurality, not majority.
Don't confuse "by [his] logic" with by *your* logic in order to make a snotty point about your opinion on majority vs. plurality.
(For the record, I favor direct popular vote with IRV, but think that as we do have an electoral college, claims that X "should have won" are nonsense.)
What does majority have to do with it? In a popular-vote race, you can win with a plurality.
No, we have multiple engineering libraries.
There is a global crack (theoretically). BD+ is just software supplied on the disk that runs on your hardware and enables proper interpretation of the data on the disk. There is nothing, theoretically, preventing you from completely emulating a valid BD+ runtime environment or otherwise obtaining the information necessary to properly interpret the data from the supplied software. It's very difficult, since they in essence controlling a component of your hardware by selling Blu-Ray readers containing a proprietary runtime, the behavior of which is not disclosed to you.
Well, okay. I'm fairly certain he didn't actually think you make $12k/hr. But he did entirely misinterpret your numbers.
After the fact, I realized it'd be more reasonable to multiply $3000 by (8 hrs / 15 min) to get your salary, but then I wouldn't have an hourly figure to compare to $12k/hr. Hourly rate depends a little bit on how many days per year are actually worked.
No, *you* didn't make any error. Check the parent post. He thought you earned $12k/hr.
That's exactly what happened.
Can't help it if you don't understand superconducting electromagnet failure modes.
That's not a feature, that's a side effect. Some types of failure cause the liquid helium to warm up until the magnet is no longer at superconducting temperatures. This causes a sudden resistance, which can damage the magnet, heats the whole system up (boiling off the coolant), et cetera. MRI systems generally have an emergency shutoff feature, the side effect of which is magnet quenching.
In this case, a quench is what happened -- resistance in the circuit caused helium boiloff, which destroyed superconductivity. They have many safeguards for this, as this was well-known before the first MRI or superconducting collider was built. Release valves allow the boiling helium to escape, and resistor banks are used to draw off electrical energy from the system. However, their system wasn't sufficient to handle the level of failure that occured.
I'm well aware of that -- that's what I've said elsewhere.
The computer forensic people we have are professionals and generally do not defer to private-industry professionals. But of course there are few of them, there's not much funding for more of them, and they have a huge work backlog.