If an exploit is in the wild, it causes an exception to the patch-Tuesday and the release goes out.
The problem is that for bugs which are NOT being exploited yet, the patch is a a big flashing red sign saying "Bug here, exploit it before anyone patches it!"
I've yet to find an IT department that only wants to work on one day a month on patching -- Most are lucky to pull the man power to get patching done once a month.
Personally, my calendar has my schedule cleared on Patch Tuesday afternoon/evening to test and release the patches for deployment so that workstations can update at the 4am Wednesday update schedule (set by group policies) -- This generally gets the patching done in under a business day, with a minimum of disruption to users, without me needing to be available 24/7 to review and approve patches.
Unfortunately, when a patch comes out it's like a giant red arrow saying "Formerly exploitable code located here" -- Anyone who is looking for a vulnerability to exploit who can find it before your average company has time to patch can take advantage of it.
By scheduling the day patches come out, but not revealing the contents of the patches until that day, you allow IT departments to schedule their patch testing and deployment well in advance.
No -- Most computer users don't leave their computer doing anything productive or useful overnight, and the default avoids the "Hey, you need to reboot now" dialogs that were a constant complaint in the past.
If you need software to run at all times while your system is on, not just when a user is logged in, install it as a service.
If you don't want automatic updates to reboot on demand, configure it appropriately.
Try managing patches for a hundred thousand systems and you'll understand why less frequency is more important.
So, why not release them as they make them? Two factors
1) Your average large IT department is going to schedule the deployment,
2) Once the patch goes out, all you have to do is look at the patch to see what it changed and you know there was an exploit in the previous version. As a result, looking at patches actually make it easier to find exploits.
So combining the two, it's more IT friendly to release patches on a fixed schedule which IT departments can plan around, rather then giving the patches to the blackhats right away, knowing the end users won't generally be able to install them until later anyway.
In general, once a bug is being exploited, the patch goes out ASAP. However, if it is not yet being exploited, there is little harm in delaying a week or two (up to four weeks, the next monthly cycle).
Ahh but CD/DVDs are different -- You are licensing the content rather then buying the product.
Another way to look at it, if you scratch your car, you can have just the part you scratched replaced. With a DVD, you cannot purchase the media independently of the license (and the license is the expensive part)
It would be nice if you could buy a replacement for the actual product cost, without the license, but it's too much hassle with little ROI for the company.
In the mean time, use your fair-use rights, make a backup and get on with life.
Sure, until a (deer|child|other) runs out in the middle of a vehicle somewhere, then without enough time to react, every single one of the drivers at 10cm rear-ends the one in front.
Unfortunately you still need to factor in both reaction time (with human drivers), and stopping distance (regardless).
Even if you had a network of computers driving, if the front-most car in a line of cars at 1" were to stop suddenly, if every car has the same stopping distance, all is well.
In the real world, one car will have bald tires, one will have better brakes, one will have four six guys and 400lbs of cat litter in the back, one will be on a gravelly patch, one will be going through a puddle, and they'll all have different weights, and most will either crash into the one in front, or get hit from the rear and get knocked into the one in front of them anyway.
Now do some combinations of the above and enjoy the 400 car pile up.
Some places do have alternate limits. Heck, not more then a 15 minute drive from my house there is a highway with a slower speed at night then during the day.
You missed the point. If you have to stop anyway, then you can't avoid pushing the brake. The point was that if you can avoid pushing the brake (by coasting, rather then accelerating, braking, accelerating, braking), you'll use less fuel.
Saying "the brake pedal...uses up fuel" obviously isn't literally true, nor does it take into account friction, wind resistance, or gravity (or anything else that might slow you down), so it obviously simplifies the problem.
Or the guy eight cars back who didn't make it to the red light (to turn on red) because the guy seven cars back didn't make it through at all because you delayed everyone?
Unless Parallels emulates the same hardware as VPC, XP will see a hardware change and request reactivation. Since the key used cannot be activated, you've run into a wall.
Instead of turning it off, set it to elevate automatically. This gives you many of the security advantages (IE7's protected mode, as well as running other apps in virtualized paths, making cleanup from a small compromise, assuming binary code wasn't executed, substantially more possible) while bypassing many of the nags.
The mail isn't rude... Not even the words. Rather, the letters they used.
Probably too many "T"s, those are very rude letters.
Re:Things like this are easy to fix.
on
Google's Evil NDA
·
· Score: 1
That was in the first.com boom, there wasn't much of a decision on my part -- They just had to decide if they wanted a new employee or not, there were far more employers then employees...
Slashdot Mirror
If an exploit is in the wild, it causes an exception to the patch-Tuesday and the release goes out.
The problem is that for bugs which are NOT being exploited yet, the patch is a a big flashing red sign saying "Bug here, exploit it before anyone patches it!"
I've yet to find an IT department that only wants to work on one day a month on patching -- Most are lucky to pull the man power to get patching done once a month.
Personally, my calendar has my schedule cleared on Patch Tuesday afternoon/evening to test and release the patches for deployment so that workstations can update at the 4am Wednesday update schedule (set by group policies) -- This generally gets the patching done in under a business day, with a minimum of disruption to users, without me needing to be available 24/7 to review and approve patches.
Unfortunately, when a patch comes out it's like a giant red arrow saying "Formerly exploitable code located here" -- Anyone who is looking for a vulnerability to exploit who can find it before your average company has time to patch can take advantage of it.
By scheduling the day patches come out, but not revealing the contents of the patches until that day, you allow IT departments to schedule their patch testing and deployment well in advance.
No -- Most computer users don't leave their computer doing anything productive or useful overnight, and the default avoids the "Hey, you need to reboot now" dialogs that were a constant complaint in the past.
If you need software to run at all times while your system is on, not just when a user is logged in, install it as a service.
If you don't want automatic updates to reboot on demand, configure it appropriately.
You're not in IT, are you?
Try managing patches for a hundred thousand systems and you'll understand why less frequency is more important.
So, why not release them as they make them? Two factors
1) Your average large IT department is going to schedule the deployment,
2) Once the patch goes out, all you have to do is look at the patch to see what it changed and you know there was an exploit in the previous version. As a result, looking at patches actually make it easier to find exploits.
So combining the two, it's more IT friendly to release patches on a fixed schedule which IT departments can plan around, rather then giving the patches to the blackhats right away, knowing the end users won't generally be able to install them until later anyway.
In general, once a bug is being exploited, the patch goes out ASAP. However, if it is not yet being exploited, there is little harm in delaying a week or two (up to four weeks, the next monthly cycle).
This isn't piracy related at all, it's just plain and simple old-skool theft prevention.
Ahh but CD/DVDs are different -- You are licensing the content rather then buying the product.
Another way to look at it, if you scratch your car, you can have just the part you scratched replaced. With a DVD, you cannot purchase the media independently of the license (and the license is the expensive part)
It would be nice if you could buy a replacement for the actual product cost, without the license, but it's too much hassle with little ROI for the company.
In the mean time, use your fair-use rights, make a backup and get on with life.
Sure, until a (deer|child|other) runs out in the middle of a vehicle somewhere, then without enough time to react, every single one of the drivers at 10cm rear-ends the one in front.
Unfortunately you still need to factor in both reaction time (with human drivers), and stopping distance (regardless).
Even if you had a network of computers driving, if the front-most car in a line of cars at 1" were to stop suddenly, if every car has the same stopping distance, all is well.
In the real world, one car will have bald tires, one will have better brakes, one will have four six guys and 400lbs of cat litter in the back, one will be on a gravelly patch, one will be going through a puddle, and they'll all have different weights, and most will either crash into the one in front, or get hit from the rear and get knocked into the one in front of them anyway.
Now do some combinations of the above and enjoy the 400 car pile up.
Unfortunately you can still get a ticket for it too, no?
Some places do have alternate limits. Heck, not more then a 15 minute drive from my house there is a highway with a slower speed at night then during the day.
You missed the point. If you have to stop anyway, then you can't avoid pushing the brake. The point was that if you can avoid pushing the brake (by coasting, rather then accelerating, braking, accelerating, braking), you'll use less fuel.
Saying "the brake pedal...uses up fuel" obviously isn't literally true, nor does it take into account friction, wind resistance, or gravity (or anything else that might slow you down), so it obviously simplifies the problem.
How about the guy before him?
Or the guy eight cars back who didn't make it to the red light (to turn on red) because the guy seven cars back didn't make it through at all because you delayed everyone?
Good point -- You should leave your water on 24/7, just to be safe.
Make sure it's on hot too.
You can download both IE6 and IE7 versions, no need to update anything yourself.
Virtualized hardeware is untrusted, for now.
And even if not installed, some malware could just install it, no?
Unless Parallels emulates the same hardware as VPC, XP will see a hardware change and request reactivation. Since the key used cannot be activated, you've run into a wall.
Is it an AD DC? If so, you've got a DNS misconfiguration causing a 8 minute bootup (or the server is vastly overloaded or underpowered)
Or even easier, get a free copy from Microsoft
Instead of turning it off, set it to elevate automatically. This gives you many of the security advantages (IE7's protected mode, as well as running other apps in virtualized paths, making cleanup from a small compromise, assuming binary code wasn't executed, substantially more possible) while bypassing many of the nags.
Microsoft IS learning though, Vista's notepad uses "&Save" and "Do&n't Save" rather then "Yes" / "No"
Keep in mind this is a country that doesn't even know it's own valid current currency.
The mail isn't rude... Not even the words. Rather, the letters they used.
Probably too many "T"s, those are very rude letters.
That was in the first .com boom, there wasn't much of a decision on my part -- They just had to decide if they wanted a new employee or not, there were far more employers then employees...
Why would you be using a Google meeting room if you weren't seeing anyone from Google?
Why would Google allow this?
I'm confused...