You should assume 1 gallon of water per person per day. Half a gallon will be consumed, the other half used for sanitiation and other related tasks. Don't skimp on water -- it is used for many things other than drinking, and you can't last as long without it as you can without food.
You should inventory & rotate supplies twice a year. If something will go bad in the next 6 months, rotate it into your non-emergency supplies and replace it with something that will last longer. Handling this when daylight savings time changes is an easy way to remember when you last checked on your supplies.
If you live in territory that can get cold, or rains frequently, add good (as in warm) winter clothing (hat, coat, gloves, etc) and some sort of raincoat to the list.
Add toilet paper and relevant santitation chemicals to the toiletry kit. In an emergency, running water may be disabled so be prepared for scenarios that don't involve the use of a tiolet.
Add candles to the "other essentials", and make sure the matches are waterproofed in some fashion. Having a few trash bags on hand isn't a bad idea either.
I would also add in some sort of time-killer / morale booster. A good book, deck of cards, some sort of portable car-trip game (ex: mini Connect 4, chess, battleship, whatever), maybe your favorite candy, etc. Something small that will cheer you up when the reality of the situation hits.
If you have young children or infants, add supplies needed on a daily basis for them. With children involved, I would ensure relevent supplies are present for each child for 7 days instead of 3.
If you live in earthquake country, take the following additional precautions: - work under the assumption that your house will not be habitable after an earthquake - keep a crowbar under your bed (to pry open any doors that get stuck shut) - assemble multiple 72hour kits with the essentials; each 72 hour kit should be enough to sustain everyone living in your house for 3 days. Distribute non-essential supplies among the various kits, grouping dependent supplies together. Store them in places you think are most likely to survive an earthquake. If you choose wisely, you'll have a 72xN hour kit with all the non-essentials you made available. If you choose poorly, hopefully at least one location will still be accessible, and you'll have one or two niceties to lighten your mood. - store a 24-48 hour kit in your car - if you walk to work, backpack into work with a 24 hour kit - add work gloves to each kit (to protect your hands while sorting through debris) - some sort of post-quake procedures checklist; turn off electricity, water, gas, gather supplies, how to get drain water from household pipes, etc. - (non-essential) camping gear; tent + sleeping bag, chemical heaters, campstoves, boyscout handbook, etc - (non-essential) disposable cups, plates, and silverware (for any supplies you salvage from your residence)
When preparing car and backpack kits, consider where you are likely to be and how accessible home will be from that location and prepare accordingly. Bridges are likely to be out or inaccessable, power lines and trees may have fallen, buildings collapsed, street signals will be out, etc. It would be advisable to stay put (off the roads) as long as possible to keep out of emergency services' way. When preparing a car kit, be prepared to provide for passengers if you tend to have more than one person in the car with you a non-trivial percentage of the time.
The idea is that the interface changes will make your employees more productive, and that you'll recoup the training costs over time through that increased productivity (and eventually come out ahead).
If you're just changing from one unproductive design to another, you won't recoup the training costs.
You don't need WinXP Pro for home use; the additions in pro are primarily around domain related networking functionality and aren't needed by typical home users. For more information on the differences:
I don't think casual gamers will interpret the new input method any differently than the rest of the world. Casual gamers are more interested in game content and design, not input methods and gimmicks.
If they can pull off a successful implementation, it will end up being a "must have" item for the experience. But that's the big gotchya, because it will be incredibly easy to mess up the implementation. My biggest concern is lag... there is nothing worse than having to wait half a second for an action to take effect on the screen (there are similar types of input devices that work with computer projectors to provide mouse input and they're rather laggy).
As I said, time will tell. I've gotta at least give them props for trying something so far out there...
If it ends up being useful, great, but it reminds me of those lame ass guesture based arcade games. It seems really gimmicky to me and I don't find it personally appealing, but time will be the ultimate judge.
Why are you arguing about what's already been decided? Jurisdiction isn't a difficult legal concept to understand, and this case poses absolutely no constitutional questions.
It doesn't matter where Lee lives, the suit was filed in Washington, and the state of Washington has jurisdiction on the matter. As the contract agreed to by Lee stipulates that any violation of the contract will be litigated in Washington state courts, Lee has no legal basis for changing the venue litigation occurs in.
This case isn't under California's jurisdiction. California law is irrelevent.
The contract was entered in the state of Washington. The contract stipulates legal action be brought in the state of Washington. Lee was employed in Washington. Microsoft is based in Washington.
Jurisdiction and venue for the case is Washington.
Note that Google had already agreed to this prior to MS pushing for an injunction.
Conslusions of Law, page 10, paragraph 5:
"Defendants' Stipulation is not a substitute for Plaintiff's request for injunctive relief, especially where, as here, the Stipulation was offered after the suit began and the Court issued the TRO. State v. Ralph Williams' North West Chrysler Plymouth, Inc., 82 Wn.2d 265, 272 (19733)"
You must be used to some pretty shithouse patching systems to make a claim like that.
You must live in some fantasy land where merge conflicts never occur.
If the patches are applied in a defined order, it isn't a problem. It isn't possible to patch a binary in a random order as the GP requested. Hell, we still can't do that on a source level without human intervention every now and then.
Right, because when your mission critical system is compromised because you don't have patch X applied, you're in a MUCH better situation. *rolls eyes*
Vulnerabilities aren't discovered and exploits aren't written to respect the timing of Microsoft in this regard.
Correct and incorrect at the same time. Patches are reverse engineered and exploits are written based off of the changes in the patch. Which means once you release a patch, the clock is ticking for your customers to pick it up and deploy it before some script kiddie writes a worm that brings down your network.
What happens if a vulnerability is discovered and an exploit written for it a couple of days after patch tuesday? Microsoft's whole bug fixing scheme is then set to only handle it 28 days later.
Depends on the nature of the exploit. If it is serious, they'll release the patch out of cycle.
I think this is moron thinking. Each patch should be one small patch to fix that vulnerability and only that vulnerability. no other bug fixes with regards to non security issues, no combining patches, no waiting for days to fix a patch.
What do you do when two patches apply to the same binary? Your "single patches" trash each other. Do you propose deploying untested patches? When is a bug a non-security issue?
What happens when a vulnerability is fixed that needs more testing for many people, but also comes attached to vulnerabilities that can be simply exploited? do we wait for the former before applying the latter, or apply the latter and to hell with the consequences in the former?
A vulnerability is a vulnerability. Wanting to run a partially patched system is idiotic.
Then the monthly updates can be set client side however the client wishes to handle it. daily or weekly or monthly. whatever they wish to handle. at the time.
No, they can't. The changes in Microsoft's patches are reverse engineered. Exploits are written against a patch within 72 hours. Once the patch is released, you MUST deploy it or your are vulnerable to every bot author who wants to add your machine to their zombie army.
I'm still trying to imagine Ballmer throwing a chair across an office. That can't be an easy feat... seriously, you ever try throwing a chair? They're heavy, awkward, and the desk variety do wierd swively things when you pick them up...
(I am of course, assuming that his office is equipped with something more sturdy than a common cafeteria chair)
I can't shake the mental image of an overweight middle aged white bald man who spends most of his time in front of a computer attempting to pick up a chair, falling over in the attempted throw.
He was asking why should we even bother making a car if the bicycle already exists. You pointed out that cars didn't exist, so it isn't worth considering if cars could potentially be better than riding a bike.
You're basically saying that something isn't worth "looking" at until its been invented. If society followed your method of thinking, nothing new would ever be invented. Ever.
Office supports open formats: * html * word-ml (xml) * rtf
The license to word-ml format is GPL incompatible, but anything with a patent covering it is GPL incompatible, so that shouldn't be much of a surprise.
Why the fuck they didn't standardize on *HTML* documents for their WEBSITE is beyond me.
I'm not 100% sure, but I thought that the Xbox 360 used water cooling. Given that they're using some varient of a PowerPC chip, of which the latest versions run to hot to make it into a laptop, and have the clock speed cranked up as well, I wouldn't be surprised if they were using a water cooling system. Can anyone verify this?
It uses heat pipes. It is liquid cooling in the sense that fluid transfers the heat to a different location. The pipes trasfer the heat to fins in the back of the unit (where the air is cooler, and you have better airflow).
I'm guessing that this is the reason for the increased price in the controllers.
Nope. You don't have to pay a license fee based on the number of remotes you have... With the Xbox1, you paid it with the dvd remote (which is why that stupid thing was so expensive). With the Xbox360, you pay for it when you buy the unit.
I don't know if running through the Xbox 360 to a HD TV will result in better visuals or not though
Yes, it will.
Right now I've got my Xbox on the wireless network in my apartment. I could probably just use the current setup and run a cord from ethernet jack to the wireless adapter, but it can get a little laggy at times, especially with the poor internet service. But at $99, the adapter from MS seems a little expensive.
Having a built-in wireless device isn't going to make your connection any less laggy. The $99 adapter is an 802.11a/b/g device, which is one of the reasons why it is expensive. I'd personally stick with the ethernet->wap solution.
I'd like to see a system similar to a PC where each user signs on and has certain permission levels
You'll note that I never made any attempt to refute that point.:)
I've actually had to use them for a project I worked on, and it wasn't a pleasant experience -- though his blog does take some of the 'mystery' out of the process, thankfully.
Perhaps you weren't attempting to address that fact in particular, but it sure read like you were. Hence the ire.
I'd recommend reading Mike Stalls blog (http://blogs.msdn.com/jmstall)... he talks a ton about the debugging aspects in.Net. I wouldn't be surprised if there was some nugget in there somewhere that talks about why they decided to use an in-process debugging model instead of the more traditional debugging model.
My guess is that the reasoning involved is related to having helper threads running in a managed process (JIT compiler + optimizer, garbage collection, finalization, etc) that are hard to deal with out of process (especially when you toss breakpoints into the mix) and needing some sort of mechanism to correlate asmILsource.
1. You are correct, you would need access to RedHat's private key to "fake" a signature. If the file isn't signed, you know that whoever created the binary didn't have access to the private key and that you can't determine the origin of the file. If you choose to believe that the file's origin was from RedHat after RedHat told you that they sign their binaries, then you made a poor decision.
2. Again, poor decision.
At the end of the day, it is up to the user to determine what to trust and what not to trust. They are the only ones who can make the trust decision. Code signing is intended to give users the information they need to make that decision. If you want to take the decision out of the hands of the users, a 3rd party must decide what can and can't be safely run on a machine. That isn't an acceptable solution.
Security is entirely about paranoia. You lock your front door because you're afraid someone is going to walk into your house and steal your stuff. You lock your car because you're afraid someone is going to steal it. You have a logon/password to your computer because you're afraid someone is going to find your porn collection.
If you want to operate a computer in an enviornment that exposes you to to hostile applications, you must be paranoid enough to determine where an executable came from and if you trust that location before running it.
You should assume 1 gallon of water per person per day. Half a gallon will be consumed, the other half used for sanitiation and other related tasks. Don't skimp on water -- it is used for many things other than drinking, and you can't last as long without it as you can without food.
You should inventory & rotate supplies twice a year. If something will go bad in the next 6 months, rotate it into your non-emergency supplies and replace it with something that will last longer. Handling this when daylight savings time changes is an easy way to remember when you last checked on your supplies.
If you live in territory that can get cold, or rains frequently, add good (as in warm) winter clothing (hat, coat, gloves, etc) and some sort of raincoat to the list.
Add toilet paper and relevant santitation chemicals to the toiletry kit. In an emergency, running water may be disabled so be prepared for scenarios that don't involve the use of a tiolet.
Add candles to the "other essentials", and make sure the matches are waterproofed in some fashion. Having a few trash bags on hand isn't a bad idea either.
I would also add in some sort of time-killer / morale booster. A good book, deck of cards, some sort of portable car-trip game (ex: mini Connect 4, chess, battleship, whatever), maybe your favorite candy, etc. Something small that will cheer you up when the reality of the situation hits.
If you have young children or infants, add supplies needed on a daily basis for them. With children involved, I would ensure relevent supplies are present for each child for 7 days instead of 3.
If you live in earthquake country, take the following additional precautions:
- work under the assumption that your house will not be habitable after an earthquake
- keep a crowbar under your bed (to pry open any doors that get stuck shut)
- assemble multiple 72hour kits with the essentials; each 72 hour kit should be enough to sustain everyone living in your house for 3 days. Distribute non-essential supplies among the various kits, grouping dependent supplies together. Store them in places you think are most likely to survive an earthquake. If you choose wisely, you'll have a 72xN hour kit with all the non-essentials you made available. If you choose poorly, hopefully at least one location will still be accessible, and you'll have one or two niceties to lighten your mood.
- store a 24-48 hour kit in your car
- if you walk to work, backpack into work with a 24 hour kit
- add work gloves to each kit (to protect your hands while sorting through debris)
- some sort of post-quake procedures checklist; turn off electricity, water, gas, gather supplies, how to get drain water from household pipes, etc.
- (non-essential) camping gear; tent + sleeping bag, chemical heaters, campstoves, boyscout handbook, etc
- (non-essential) disposable cups, plates, and silverware (for any supplies you salvage from your residence)
When preparing car and backpack kits, consider where you are likely to be and how accessible home will be from that location and prepare accordingly. Bridges are likely to be out or inaccessable, power lines and trees may have fallen, buildings collapsed, street signals will be out, etc. It would be advisable to stay put (off the roads) as long as possible to keep out of emergency services' way. When preparing a car kit, be prepared to provide for passengers if you tend to have more than one person in the car with you a non-trivial percentage of the time.
The idea is that the interface changes will make your employees more productive, and that you'll recoup the training costs over time through that increased productivity (and eventually come out ahead).
If you're just changing from one unproductive design to another, you won't recoup the training costs.
Retailers are the entities creating those bundles, not Microsoft. Microsoft has no control over how individual retailers choose to sell it.
You can get nearly the same functionality out of the remote assistance app.
Get XP Home and save yourself $60.
m e_pro.asp
You don't need WinXP Pro for home use; the additions in pro are primarily around domain related networking functionality and aren't needed by typical home users. For more information on the differences:
http://www.winsupersite.com/showcase/windowsxp_ho
Wait a while....they'll be writing the same article about Google
...
And then, afterwards, Google will refuse to comment on anything to the publisher that printed the article for a period of one year
I don't think casual gamers will interpret the new input method any differently than the rest of the world. Casual gamers are more interested in game content and design, not input methods and gimmicks.
... there is nothing worse than having to wait half a second for an action to take effect on the screen (there are similar types of input devices that work with computer projectors to provide mouse input and they're rather laggy).
...
If they can pull off a successful implementation, it will end up being a "must have" item for the experience. But that's the big gotchya, because it will be incredibly easy to mess up the implementation. My biggest concern is lag
As I said, time will tell. I've gotta at least give them props for trying something so far out there
Hopefully never ...
If it ends up being useful, great, but it reminds me of those lame ass guesture based arcade games. It seems really gimmicky to me and I don't find it personally appealing, but time will be the ultimate judge.
Thought it hasn't stopped the major players from putting miniture joysticks on their controllers ...
I'm afraid it doesn't look good...
o rd1=Larry+Paige%2C+Sergey+Brin+&word2=Gates%2C+Bal lmer
http://www.googlefight.com/index.php?lang=en_GB&w
Why are you arguing about what's already been decided? Jurisdiction isn't a difficult legal concept to understand, and this case poses absolutely no constitutional questions.
It doesn't matter where Lee lives, the suit was filed in Washington, and the state of Washington has jurisdiction on the matter. As the contract agreed to by Lee stipulates that any violation of the contract will be litigated in Washington state courts, Lee has no legal basis for changing the venue litigation occurs in.
This case isn't under California's jurisdiction. California law is irrelevent.
The contract was entered in the state of Washington. The contract stipulates legal action be brought in the state of Washington. Lee was employed in Washington. Microsoft is based in Washington.
Jurisdiction and venue for the case is Washington.
Note that Google had already agreed to this prior to MS pushing for an injunction.
p df
Conslusions of Law, page 10, paragraph 5:
"Defendants' Stipulation is not a substitute for Plaintiff's request for injunctive relief, especially where, as here, the Stipulation was offered after the suit began and the Court issued the TRO. State v. Ralph Williams' North West Chrysler Plymouth, Inc., 82 Wn.2d 265, 272 (19733)"
http://www.metrokc.gov/kcsc/docs/Microsoftprelim.
You must be used to some pretty shithouse patching systems to make a claim like that.
You must live in some fantasy land where merge conflicts never occur.
If the patches are applied in a defined order, it isn't a problem. It isn't possible to patch a binary in a random order as the GP requested. Hell, we still can't do that on a source level without human intervention every now and then.
Right, because when your mission critical system is compromised because you don't have patch X applied, you're in a MUCH better situation. *rolls eyes*
Vulnerabilities aren't discovered and exploits aren't written to respect the timing of Microsoft in this regard.
Correct and incorrect at the same time. Patches are reverse engineered and exploits are written based off of the changes in the patch. Which means once you release a patch, the clock is ticking for your customers to pick it up and deploy it before some script kiddie writes a worm that brings down your network.
What happens if a vulnerability is discovered and an exploit written for it a couple of days after patch tuesday? Microsoft's whole bug fixing scheme is then set to only handle it 28 days later.
Depends on the nature of the exploit. If it is serious, they'll release the patch out of cycle.
I think this is moron thinking. Each patch should be one small patch to fix that vulnerability and only that vulnerability. no other bug fixes with regards to non security issues, no combining patches, no waiting for days to fix a patch.
What do you do when two patches apply to the same binary? Your "single patches" trash each other. Do you propose deploying untested patches? When is a bug a non-security issue?
What happens when a vulnerability is fixed that needs more testing for many people, but also comes attached to vulnerabilities that can be simply exploited? do we wait for the former before applying the latter, or apply the latter and to hell with the consequences in the former?
A vulnerability is a vulnerability. Wanting to run a partially patched system is idiotic.
Then the monthly updates can be set client side however the client wishes to handle it. daily or weekly or monthly. whatever they wish to handle. at the time.
No, they can't. The changes in Microsoft's patches are reverse engineered. Exploits are written against a patch within 72 hours. Once the patch is released, you MUST deploy it or your are vulnerable to every bot author who wants to add your machine to their zombie army.
I'm still trying to imagine Ballmer throwing a chair across an office. That can't be an easy feat ... seriously, you ever try throwing a chair? They're heavy, awkward, and the desk variety do wierd swively things when you pick them up ...
(I am of course, assuming that his office is equipped with something more sturdy than a common cafeteria chair)
I can't shake the mental image of an overweight middle aged white bald man who spends most of his time in front of a computer attempting to pick up a chair, falling over in the attempted throw.
He was asking why should we even bother making a car if the bicycle already exists. You pointed out that cars didn't exist, so it isn't worth considering if cars could potentially be better than riding a bike.
You're basically saying that something isn't worth "looking" at until its been invented. If society followed your method of thinking, nothing new would ever be invented. Ever.
Out of all of the DRM technology out there, wouldn't you WANT the one the entertainment industry picks to be something Microsoft wrote?
Office supports open formats:
* html
* word-ml (xml)
* rtf
The license to word-ml format is GPL incompatible, but anything with a patent covering it is GPL incompatible, so that shouldn't be much of a surprise.
Why the fuck they didn't standardize on *HTML* documents for their WEBSITE is beyond me.
I'm not 100% sure, but I thought that the Xbox 360 used water cooling. Given that they're using some varient of a PowerPC chip, of which the latest versions run to hot to make it into a laptop, and have the clock speed cranked up as well, I wouldn't be surprised if they were using a water cooling system. Can anyone verify this?
... With the Xbox1, you paid it with the dvd remote (which is why that stupid thing was so expensive). With the Xbox360, you pay for it when you buy the unit.
It uses heat pipes. It is liquid cooling in the sense that fluid transfers the heat to a different location. The pipes trasfer the heat to fins in the back of the unit (where the air is cooler, and you have better airflow).
I'm guessing that this is the reason for the increased price in the controllers.
Nope. You don't have to pay a license fee based on the number of remotes you have
I don't know if running through the Xbox 360 to a HD TV will result in better visuals or not though
Yes, it will.
Right now I've got my Xbox on the wireless network in my apartment. I could probably just use the current setup and run a cord from ethernet jack to the wireless adapter, but it can get a little laggy at times, especially with the poor internet service. But at $99, the adapter from MS seems a little expensive.
Having a built-in wireless device isn't going to make your connection any less laggy. The $99 adapter is an 802.11a/b/g device, which is one of the reasons why it is expensive. I'd personally stick with the ethernet->wap solution.
I'd like to see a system similar to a PC where each user signs on and has certain permission levels
That's essentially what they're describing.
You'll note that I never made any attempt to refute that point. :)
I've actually had to use them for a project I worked on, and it wasn't a pleasant experience -- though his blog does take some of the 'mystery' out of the process, thankfully.
Perhaps you weren't attempting to address that fact in particular, but it sure read like you were. Hence the ire.
.Net. I wouldn't be surprised if there was some nugget in there somewhere that talks about why they decided to use an in-process debugging model instead of the more traditional debugging model.
I'd recommend reading Mike Stalls blog (http://blogs.msdn.com/jmstall)... he talks a ton about the debugging aspects in
My guess is that the reasoning involved is related to having helper threads running in a managed process (JIT compiler + optimizer, garbage collection, finalization, etc) that are hard to deal with out of process (especially when you toss breakpoints into the mix) and needing some sort of mechanism to correlate asmILsource.
1. You are correct, you would need access to RedHat's private key to "fake" a signature. If the file isn't signed, you know that whoever created the binary didn't have access to the private key and that you can't determine the origin of the file. If you choose to believe that the file's origin was from RedHat after RedHat told you that they sign their binaries, then you made a poor decision.
2. Again, poor decision.
At the end of the day, it is up to the user to determine what to trust and what not to trust. They are the only ones who can make the trust decision. Code signing is intended to give users the information they need to make that decision. If you want to take the decision out of the hands of the users, a 3rd party must decide what can and can't be safely run on a machine. That isn't an acceptable solution.
Security is entirely about paranoia. You lock your front door because you're afraid someone is going to walk into your house and steal your stuff. You lock your car because you're afraid someone is going to steal it. You have a logon/password to your computer because you're afraid someone is going to find your porn collection.
If you want to operate a computer in an enviornment that exposes you to to hostile applications, you must be paranoid enough to determine where an executable came from and if you trust that location before running it.