Usually the flu follows a very predictable seasonal cycle. As a result, the most likely prevalent strains can be predicted well in advance and a vaccine production started well in advance. (I wouldn't call it development, as the process is the exact same every year, which is why I think the people claiming the H1N1 vaccine was "too new" and "risky" don't have a clue what they're talking about - the H1N1 vaccine had MORE testing done than the seasonal vaccine does despite being produced with the exact same process.)
Since the prevalent strain can be predicted, production of vaccine can be started early. It's a long-lead thing - the virus has to be given quite a while (months I think?) to grow in chicken eggs.
The H1N1 virus popped up and started propagating without much warning, and also was propagating outside of normal seasonal patterns. As a result, even though vaccine production started almost immediately, it took a while for the process to complete. Also, as I understand it, this particular strain didn't like growing in chicken eggs that much, and as a result was harder to produce/took longer.
The biggest problem with this flu is that those who DID have preexisting medical conditions (like myself) couldn't get vaccine until it was too late and numerous large outbreaks had come and gone already.
Usually we can get our vaccines long before peak season starts.
Honestly, there were some pretty nasty outbreaks in Fall 2009 (like the one at Cornell University), at least in terms of number infected. Yes, it was not as bad as seasonal flu in terms of severity, but there was a problem:
Due to lack of any vaccine, it was spreading rapidly at its peak. If you're at risk for complications like myself, any flu is a bad flu. (I'm Type I diabetic)
Seasonal flu won't be much of a problem this season, just like most, because those who are at the highest risk for problems could get the vaccine for that in time. In the case of swine flu, the vaccine didn't become available until it was too late and the disease had already burned itself out in many areas. By the time I got my vaccine, large outbreaks in multiple local schools had come and gone. Since many of my coworkers have kids at said schools, I was honestly pretty worried.
I don't disagree with you that swine flu has been grossly mishandled. It was a media sensation when it wasn't a problem, and by the time it actually became a problem, it was a "boy who cried wolf" scenario.
30FPS with shutter glasses was too much flicker for some people.
Pretty much all of the upcoming 3D TVs are in one of two categories: 1) Alternating polarization of each line, so half resolution in 3D mode 2) 120 Hz TVs with shutters. Right now this is the approach NVidia is backing. Problem is that apparently a lot of the 120 Hz TVs out there only do internal "mocomp" processing of 60 Hz inputs, and don't allow for native 120 Hz input.
That's why it died for a few years, until display technology improved.
There's a reason why NVidia's new 3D Vision system requires a 120 Hz display - it isn't much different than the old shutter-based glasses for NV cards, BUT it's double the refresh rate.
It's a lot cheaper to produce two tiny little squares and some drive electronics than to add a whole additional layer to a 32"+ diagonal TV, especially now that it has become easy to drive the TV to the refresh rates required. (And even the approach you suggest would still require the TV to have the high refresh rate needed for shutter style glasses.)
The problem is that it's next to impossible to find these specs. Hell, with many of these drives it's difficult to identify whether it even has true hardware encryption.
It's a bad sign when the "flagship" products in three different manufacturer's lines had the key management scheme botched this severely.
Enterprises designing security are basically screwed now: 1) TrueCrypt has the issue of the fact that, as you say, users can accidentally store stuff unencrypted. Plus there's the admin rights issue. 2) All of these hardware-based solutions are closed-source/closed-hardware, and as a result don't have the peer review TC does. Without peer review, you get shit like this incident.
Also, these drives (in theory) force the user to encrypt the drive. They can't accidentally forget to use TrueCrypt.
You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except: 1) Aforementioned admin privs issues 2) A user could just reformat the USB drive partition, making it a normal non-encrypted drive.
Yup, in this case the crypto algorithm has no issues. Nor is it an implementation issue of the algorithm itself.
The greatest crypto in the world means nothing if your key management scheme sucks and it's easy for an attacker to get the key. In this case, it sounds like the key is common to all drives, so an attacker just needs to buy a drive, figure out their own key, and then use that key to attack all other drives.
I would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.
Yup. And for a while, Pentium meant "Core Duo, not Core 2 though".
It's why I've been VERY wary of anything but "Core whatever" branded CPUs, to Intel's detriment - I've held off on an HTPC purchase for a while because the cost was more than I was willing to justify, and Adobe Flash is iffy unless you have a LOT of CPU horsepower...
It's decent in suburban areas, but enjoy when you have to make an emergency call and your phone has no service.
The T-Mobile marketing that claims you can roam on AT&T towers is lies. Putting a T-Mobile SIM into a phone anywhere within 15 miles or so of where I live will result in that phone's IMEI being blacklisted with the tower for at least 15 minutes - even if you put an AT&T SIM back into the phone. (A SIM which received 5 bars of service prior to putting the T-Mo SIM into the phone.)
Or at least this was the case for the majority of the end of 2008/beginning of 2009. My ex was a T-Mo customer and her phone stopped working anywhere west of Exit 67 on New York State Route 17 (a major highway, soon to be Interstate 86). We put her SIM into my unlocked quadband GSM phone (AT&T Tilt) and it received no signal - even after swapping my SIM back in it wouldn't work for 15-20 minutes.
She managed to convince T-Mo to let her out of her contract without a penalty after that incident.
At least in the past, Sprint required you to have more than a certain percentage of your usage be on Sprint towers.
Either way, never rely on roaming agreements for phone service. Roaming agreements break (often unofficially) - See, for example, the fact that T-Mobile service will become unavailable to anyone within 15 miles of where I live/work for months at a time, despite AT&T phones working perfectly and T-Mo supposedly having a roaming agreement.
Your post completely missed the original poster's point - the Intel GMA500 is a major outlier in terms of Linux support.
The GMA950 series is well supported by Linux (with the exception of the re-architecture issues that hurt Ubuntu 9.04 so badly).
The GMA500 is simply minimally supported in Linux and all indications state that it will stay this way. The GMA500 graphics core was outsourced to another company, as was driver development.
As to SSE2/3/4 - They only benefit for certain operation types. Most kernel ops won't benefit, and also, using SSE usually means hand-coding in assembler - compilers that generate good vector SIMD code are rare. The kernel developers tend to prefer to avoid hand-coded ASM whenever possible.
However, I do recall that RAID checksumming code and memcpy() were once implemented using MMX to improve them, so these sections might benefit from SSE (and might already do so.)
There's also the fact that a lot of parts used back then are long-EOL.
As I understand it, Constellation recycled many of the key mechanical aspects of the old Apollo-era designs, because they Just Plain Worked.
However, the avionics have to be pretty much designed from scratch, for two reasons: 1) Nearly all components used in the past are no longer available 2) Modern electronics can achieve far greater performance at a fraction of the power/weight 3) Modern space missions have significantly more requirements in terms of communications capability and such
LAME was a pretty good example of this for MP3 - Eventually it was able to achieve (somewhat) better quality at (somewhat) lower bitrates than the reference encoders.
Vorbis, similarly, had the AoTUV tuning - This provided significant rate/distortion tradeoff improvements compared to a "vanilla" encoder, without changing the decoder.
However, 40% reduction in bitrate with an increase in quality is very difficult unless the original encoder was CRAP. (Which is actually a definite possibility for a realtime hardware encoder.) Also, it's far more likely to have such improvements with H.264 or MPEG-4 ASP, not nearly as likely with MPEG-2, which had a far less flexible encoding scheme.
Also keep in mind that receiving this means comparatively easy to spot antennas or sat dishes.
So to gain access to video that likely may not have location info (hard to tell EXACTLY what you're looking at without such info), these guys may have to give up their own location.
Because AES didn't exist when this system was designed, and design changes during the design process are really expensive and have a bad habit of killing programs, with post-deployment design changes being even more expensive?
Slashdot Mirror
Usually the flu follows a very predictable seasonal cycle. As a result, the most likely prevalent strains can be predicted well in advance and a vaccine production started well in advance. (I wouldn't call it development, as the process is the exact same every year, which is why I think the people claiming the H1N1 vaccine was "too new" and "risky" don't have a clue what they're talking about - the H1N1 vaccine had MORE testing done than the seasonal vaccine does despite being produced with the exact same process.)
Since the prevalent strain can be predicted, production of vaccine can be started early. It's a long-lead thing - the virus has to be given quite a while (months I think?) to grow in chicken eggs.
The H1N1 virus popped up and started propagating without much warning, and also was propagating outside of normal seasonal patterns. As a result, even though vaccine production started almost immediately, it took a while for the process to complete. Also, as I understand it, this particular strain didn't like growing in chicken eggs that much, and as a result was harder to produce/took longer.
The biggest problem with this flu is that those who DID have preexisting medical conditions (like myself) couldn't get vaccine until it was too late and numerous large outbreaks had come and gone already.
Usually we can get our vaccines long before peak season starts.
Honestly, there were some pretty nasty outbreaks in Fall 2009 (like the one at Cornell University), at least in terms of number infected. Yes, it was not as bad as seasonal flu in terms of severity, but there was a problem:
Due to lack of any vaccine, it was spreading rapidly at its peak. If you're at risk for complications like myself, any flu is a bad flu. (I'm Type I diabetic)
Seasonal flu won't be much of a problem this season, just like most, because those who are at the highest risk for problems could get the vaccine for that in time. In the case of swine flu, the vaccine didn't become available until it was too late and the disease had already burned itself out in many areas. By the time I got my vaccine, large outbreaks in multiple local schools had come and gone. Since many of my coworkers have kids at said schools, I was honestly pretty worried.
I don't disagree with you that swine flu has been grossly mishandled. It was a media sensation when it wasn't a problem, and by the time it actually became a problem, it was a "boy who cried wolf" scenario.
30FPS with shutter glasses was too much flicker for some people.
Pretty much all of the upcoming 3D TVs are in one of two categories:
1) Alternating polarization of each line, so half resolution in 3D mode
2) 120 Hz TVs with shutters. Right now this is the approach NVidia is backing. Problem is that apparently a lot of the 120 Hz TVs out there only do internal "mocomp" processing of 60 Hz inputs, and don't allow for native 120 Hz input.
Less. Typical cell towers are 30-45W average power.
The el cheapo heaters in Wally World/Target/etc. are usually 1500W at full power.
I wouldn't directly touch the antenna though, just like touching the heating element of above heater directly is probably a bad idea.
That's why it died for a few years, until display technology improved.
There's a reason why NVidia's new 3D Vision system requires a 120 Hz display - it isn't much different than the old shutter-based glasses for NV cards, BUT it's double the refresh rate.
It's a lot cheaper to produce two tiny little squares and some drive electronics than to add a whole additional layer to a 32"+ diagonal TV, especially now that it has become easy to drive the TV to the refresh rates required. (And even the approach you suggest would still require the TV to have the high refresh rate needed for shutter style glasses.)
The problem is that it's next to impossible to find these specs. Hell, with many of these drives it's difficult to identify whether it even has true hardware encryption.
It's a bad sign when the "flagship" products in three different manufacturer's lines had the key management scheme botched this severely.
Enterprises designing security are basically screwed now:
1) TrueCrypt has the issue of the fact that, as you say, users can accidentally store stuff unencrypted. Plus there's the admin rights issue.
2) All of these hardware-based solutions are closed-source/closed-hardware, and as a result don't have the peer review TC does. Without peer review, you get shit like this incident.
Also, these drives (in theory) force the user to encrypt the drive. They can't accidentally forget to use TrueCrypt.
You can use a U3 drive to make a TrueCrypt drive that is nearly identical to these drives except:
1) Aforementioned admin privs issues
2) A user could just reformat the USB drive partition, making it a normal non-encrypted drive.
No, Traveler Mode (running on a machine without TrueCrypt installed) requires admin privileges.
If TrueCrypt was installed by someone with admin privs, non-admins can then mount TrueCrypt volumes.
Because then they wouldn't be able to charge double the price of a "normal" drive.
Yup, in this case the crypto algorithm has no issues. Nor is it an implementation issue of the algorithm itself.
The greatest crypto in the world means nothing if your key management scheme sucks and it's easy for an attacker to get the key. In this case, it sounds like the key is common to all drives, so an attacker just needs to buy a drive, figure out their own key, and then use that key to attack all other drives.
I would expect that the same thing that makes it cross-platform (drive handles authentication and unlocking, not the software) would make this particular attack (some dumbass offloaded authentication to the software) irrelevant.
Actually, the way I read it, these drives all do use hardware crypto... But they use the SAME DAMN KEY. Authentication is handled in software.
Key management FAIL.
Yup. And for a while, Pentium meant "Core Duo, not Core 2 though".
It's why I've been VERY wary of anything but "Core whatever" branded CPUs, to Intel's detriment - I've held off on an HTPC purchase for a while because the cost was more than I was willing to justify, and Adobe Flash is iffy unless you have a LOT of CPU horsepower...
Correct. SSE is MOSTLY float-based, but each iteration of SSE has contained a limited number of integer instructions added to the mix.
It's decent in suburban areas, but enjoy when you have to make an emergency call and your phone has no service.
The T-Mobile marketing that claims you can roam on AT&T towers is lies. Putting a T-Mobile SIM into a phone anywhere within 15 miles or so of where I live will result in that phone's IMEI being blacklisted with the tower for at least 15 minutes - even if you put an AT&T SIM back into the phone. (A SIM which received 5 bars of service prior to putting the T-Mo SIM into the phone.)
Or at least this was the case for the majority of the end of 2008/beginning of 2009. My ex was a T-Mo customer and her phone stopped working anywhere west of Exit 67 on New York State Route 17 (a major highway, soon to be Interstate 86). We put her SIM into my unlocked quadband GSM phone (AT&T Tilt) and it received no signal - even after swapping my SIM back in it wouldn't work for 15-20 minutes.
She managed to convince T-Mo to let her out of her contract without a penalty after that incident.
At least in the past, Sprint required you to have more than a certain percentage of your usage be on Sprint towers.
Either way, never rely on roaming agreements for phone service. Roaming agreements break (often unofficially) - See, for example, the fact that T-Mobile service will become unavailable to anyone within 15 miles of where I live/work for months at a time, despite AT&T phones working perfectly and T-Mo supposedly having a roaming agreement.
Your post completely missed the original poster's point - the Intel GMA500 is a major outlier in terms of Linux support.
The GMA950 series is well supported by Linux (with the exception of the re-architecture issues that hurt Ubuntu 9.04 so badly).
The GMA500 is simply minimally supported in Linux and all indications state that it will stay this way. The GMA500 graphics core was outsourced to another company, as was driver development.
As to SSE2/3/4 - They only benefit for certain operation types. Most kernel ops won't benefit, and also, using SSE usually means hand-coding in assembler - compilers that generate good vector SIMD code are rare. The kernel developers tend to prefer to avoid hand-coded ASM whenever possible.
However, I do recall that RAID checksumming code and memcpy() were once implemented using MMX to improve them, so these sections might benefit from SSE (and might already do so.)
There's also the fact that a lot of parts used back then are long-EOL.
As I understand it, Constellation recycled many of the key mechanical aspects of the old Apollo-era designs, because they Just Plain Worked.
However, the avionics have to be pretty much designed from scratch, for two reasons:
1) Nearly all components used in the past are no longer available
2) Modern electronics can achieve far greater performance at a fraction of the power/weight
3) Modern space missions have significantly more requirements in terms of communications capability and such
Depends on your definition of "almost" and what precision you're rounding to.
LAME was a pretty good example of this for MP3 - Eventually it was able to achieve (somewhat) better quality at (somewhat) lower bitrates than the reference encoders.
Vorbis, similarly, had the AoTUV tuning - This provided significant rate/distortion tradeoff improvements compared to a "vanilla" encoder, without changing the decoder.
However, 40% reduction in bitrate with an increase in quality is very difficult unless the original encoder was CRAP. (Which is actually a definite possibility for a realtime hardware encoder.) Also, it's far more likely to have such improvements with H.264 or MPEG-4 ASP, not nearly as likely with MPEG-2, which had a far less flexible encoding scheme.
Also keep in mind that receiving this means comparatively easy to spot antennas or sat dishes.
So to gain access to video that likely may not have location info (hard to tell EXACTLY what you're looking at without such info), these guys may have to give up their own location.
Because AES didn't exist when this system was designed, and design changes during the design process are really expensive and have a bad habit of killing programs, with post-deployment design changes being even more expensive?
Please provide a link to Parallels Desktop 5 for Windows, then.
I only see a Mac release for Desktop 5 on Parallels products page, which was in fact mentioned in TFA, had you bothered to read it.