I don't know... 30 minutes could be a long time for front-line shock troops to establish a beachhead. They can then use regular troops (or the same troops out of the armor) to secure the area until a generator is brought in.
Maybe all of the (surviving) predators that normally kill most of the baby turtles will still be looking for them in the Gulf, and next year there is going to be a turtle plague in Eastern Florida.
By neglecting the roads they become full of potholes, making them more dangerous and forcing drivers to slow down. I guess we could also remove all crosswalks and stoplights in order to encourage pedestrians to cross the roads in random places and at random times. The plentiful potholes will make crossing the road even more difficult; pedestrians will need to zigzag to get across so they'll spend more time in the road. What else could be done? Maybe remove safety netting that prevents rocks from falling into the roadway, and weakening the root systems of roadside trees so they're likely to fall over into the road. Plenty to watch out for there.
Finally, if we really want to spend some money on this "safety improvement": landmines.
As for the Cable-provided set top boxes, yuck. None have the flexibility of what the Tivo can do, including the ability to transfer some shows to your PC. Not much access to anything outside what the Cable provider decides you should have, which is usually the on demand stuff and..uhm..that's it.
I've got one more, which was the final straw for me before I switched to TiVo: the Comcast-provided box had such poor quality Comcast-provided software that it crashed all of the time, wiping out both my existing recordings and all of my schedules. A DVR is really not worth very much if it can only be reliably used to pause live TV.
I loved my MythTV box too, but switched to TiVo when Comcast started moving digital channels around so often that the listings were always coming out wrong, and when it became clear that the analog channels were going away. At least TiVo with cablecards can follow the changes. Comcast still made it very difficult to get the cards; when I called for an installation they said I had to go to my local office to pick it up, and when I went to my local office they looked at me like I had two heads and said they've never dealt with cablecards. Once I finally got a technician to come and install the cards everything was cool, and I've been very happy with my TiVo ever since.
I went for the top of the line model, with the 'lifetime' subscription. I figured that the lifetime subscription is cheaper than the other options after four years, and the box (which the subscription is attached to) should last me that long before it's completely obsolete.
I'm not sure that's true, but my company has only just committed to doing Scrum properly this year so I haven't had the experience yet. But what I'm expecting for larger tasks is to have non-code deliverables, like having some specific portion of a new infrastructure analyzed and designed. Then that portion will be built in a future sprint, while other parts are being designed.
I also expect that my manager will define some deliverables vaguely at the beginning of a sprint, then at the end of the sprint he'll redefine them to be whatever got done and bump the vague deliverable to the next sprint. This is how we'll make continuous progress on open-ended R&D type work, refactoring existing code, doing unpredictable-but-urgent maintenance, etc.
Please explain to me how the government agreeing to take on most or all of the risk financing a business is not a subsidy. It might not be a subsidy for the power industry but it sure is for the financial industry. Its socializing loss and risk, while leaving profits private. Its exactly the kinda thing that is currently gutting our treasury.
I'm pretty sure that most of the risk involved in building a nuclear power plant is the risk that the government (local/state/fed) will shut down the project for some arbitrary reason, like "too many campaign donors complaining about it". So the government is agreeing to deal with the financial consequences of the risk it's creating in the first place, which seems fair. Eliminating the risk would be better, though.
Plumber: Mechanical Engineer specializing in plumbing systems
Electricians: Electrical Engineer
Carpenters: Structural Engineer
Welders: Mechanical Engineer specializing in metal structures
The engineers wouldn't be doing the same work; they'd be doing more advanced work in the same general field. For example, a good plumber can design and install all of the plumbing for a single family home, while an engineer could design the plumbing for a large skyscraper and direct the huge team doing the installation.
This distinction exists in the software industry too, but it's much less formal and less recognized, especially by non-technical management. I think that's due to the relative youth of the industry.
That's only because Saddam re-routed the resources to his favored buds. Plenty of resources went into the country, it's just that they were not being distributed evenly. Saddam used the sanctions as an excuse to rid groups he didn't like.
Since the sanctions were supposed to be hurting Saddam, and not the Iraqi people, and we knew what Saddam was doing with the resources, I'd say that the sanctions were a complete failure. It took two wars and an invasion to remove Saddam from power, and in the process we've destroyed a relatively open society, killed who knows how many innocent people, and created enough anti-US sentiment to last for generations.
This is a civil lawsuit. Individuals who lose civil lawsuits are not incarcerated. They are ordered to pay compensation just as corporations are.
The problem with this was mentioned by the OP: corporations that are ordered to pay 'compensation' often just give out vouchers for their products, rather than cash. Those vouchers are valued at the full suggested retail price of the products, even if the products never are sold for that price, and the actual cost to the corporation is a small fraction of that price. Individuals who lose civil lawsuits do not have this option, and neither should corporations.
Uranus is inclined over on it's side, isn't it? That's halfway to spinning the 'wrong' way like Venus does. Do astronomers know if it's in the process of flipping over, or are we unable to measure changes that small and slow?
Outlook 2007 was the first place I saw the new Ribbon interface, and though it looked odd at first, I got used to it quickly. I think for Outlook it works really well. I'm still having trouble getting used to the Ribbon in Word and Excel though; while a few things are easier, I still find myself hunting for commands. I think those applications simply have complex command sets, and the Ribbon can't put everything in an easy-yo-find place any more than menus can. Effectively, all they've done is re-arrange the menus.
A piece of instant film could be handed directly over to a friend or relative without further hassle. Digital cameras still require you to take the time to get to a computer and do something with the picture via the memory card or the camera itself. Instant sharing isn't as simple or direct as snapping the picture and handing it to someone, like with a Polaroid.
If you use the camera in your cellphone, you can email the picture to your friend, and they can receive it on their cellphone moments later. That's pretty instant, and not only have you shared the picture, you've made an exact duplicate of it so you can both have it. Can't do that with a Polaroid.
What we need are either better quality cameras built into cellphones, or broadband cellphone chips built into digital cameras. The latter is a more viable option; good cameras are too bulky to be reasonable cellphones, while the cellphone electronics can be easily fit into a decent camera.
Is there something stopping Apache from being sped up?
Apache is designed to be extremely modular; every request goes through a series of hooks which call out to modules to give them a chance to do something with the request before it's passed onto the next module on the hook or the next hook on the chain. While this makes Apache incredibly flexible and very easy to extend, it also slows down the request processing.
A less flexible design can be made to perform faster, because it doesn't have to do all of the checking needed to determine how to handle the request. Fewer options == Fewer checks. For my company's web application, I wrote a custom HTTP server in Perl years ago which is still in use today. It handles our application and static files, and that's it. It performs as well as a well-designed Apache/mod_perl application, and better than a FastCGI application. That's pretty good for something that has been virtually unchanged since well before mod_perl existed.
Make it personal: "Memory is like the stuff in your head, Storage is the stuff you write down. When you're turned off (eg: dead) the stuff in your head is gone, but the stuff you wrote down is still available. Now maybe you'll remember to tell your computer to write down the document you're working on before you kill it."
There never were any widely accepted scientific laws that ruled out human flight, but most people, including scientists, still believed it was impossible. They lacked one of two things:
The scientific laws that describe how you can generate a lift force using an airfoil
The audacity of a couple of engineers who decided to build an airplane without #1
The OP's point is that we have to keep our minds open to new possibilities, because not all scientific laws are known yet, and the ones that are known aren't necessarily correct. We only call them 'laws' because they've lasted for a long time as 'theories' without being overthrown... yet.
They all seem to disappear when it rains, which I assume is because they can't get wet. So, they need to be waterproofed, or at least be given big umbrellas.
Umbrellas might work, actually. The umbrella vendors pop up out of nowhere when it rains, like hibernating frogs in the desert. Maybe they could be put to good use covering up the taxis.
I never understood that unit of measurement. Where'd you guys get such regularly-sized rocks? Over here in the colonies, they're all very inconsistent.
The British had for almost a 500 years a fairly simple approach to warfare. It's called "shoot the enemy a lot".
During the American Revolution, the British were also apparently upset by the fact that the American army didn't always stand out in the open to get shot at a lot, like a proper army should. Instead, the Americans hid behind trees and rocks, and rather than shooting back a lot, they just shot back a bit, at the British officers. It was a pretty effective strategy when faced with an enemy who likes to shoot a lot, and has the guns for it. It still works today, too.
Map/Reduce was developed at Google. It's a bit tough to wrap your head around at first, and once you get it you wonder what the big deal is, until you realize how suitable it is for Google's datacenters.
Basically, you take a dataset (a bunch of key/value pairs) and a mapping function, and you run the mapping function over every item in the dataset. This gives you an intermediate dataset with different keys and values. You then run that through a reducing function, which produces your final dataset. This can be a single result, or a dataset that can then be processed with a different map/reduce pair of functions.
The big deal for Google is that many of their problems can be expressed in terms of map and reduce functions that can operate in parallel over their datasets, and that their datacenters can handle absolutely enourmous quantities of parallel operations. So, for the mapping operation, they take the original dataset and mapping function, subdivide the dataset over thousands of servers, and let them run the mapping function in parallel. When these servers return their results, it's common for many different servers to return the same or related keys in the intermediate set. These are collated, so that when the intermediate dataset is distributed with the reduce function, all of the values with the same keys go to the same servers. This helps the reduce function to be run in parallel; it's often counting the number of original items that were assigned to the same key in the intermediate set.
Without any details this sounds like an urban legend. If you designed your system as you would have with a lesser system like a simple "key/value" pair, how would a RDBMS be any different?
The difference is optimization vs generalization. Many problems can be handled using simple key/value pair relationships. You can model this in an RDBMS using two-column tables that you never join across, where all of your queries are SELECT val FROM tab WHERE key=? and INSERT INTO tab (key,val) VALUES (?,?). However, if you use the RDBMS this way, you're paying for the overhead of the SQL engine, (usually) a client/server connection, and your language's library for interacting with an RDBMS.
The alternative is a non-relational database like BerkeleyDB, which is optimized for key/value pair operations. All the fetch and store operations do is fetch and store the value for a given key, with a minimum of overhead. BerkeleyDB is also an in-process database, where your application is accessing the database files directly using the BerkeleyDB library code. (The library handles locking so that multiple processes can use the database files at the same time.) Again, the overhead is kept to a minimum.
BerkeleyDB is much less flexible than an RDBMS, but for the problem domains where that flexibility is not needed, BerkeleyDB is much more efficient. I've easily achieved over 6000 read/write transactions per second on modest hardware in a single-threaded process; a multi-threaded and/or multi-process application can achieve much higher rates. Compare that to a typical Oracle database connection, where you're lucky to get as many as a few hundred transactions per second, just because of the network round-trip.
I'm a US Citizen. While in college, a few of my friends and I went on a road-trip to Canada; our first visit by ourselves. Not knowing the procedure, we parked and walked into the US customs office before crossing the border.
The agents there acted really rude and angry with us; they were intimidating and directly threatening, making a point of the fact that they were all carrying weapons. After questioning us and threating us with incarceration, they let us go and cross into Canada.
The Canadian agent in the booth looked into the car, asked if we had any guns or drugs, and when we said no she welcomed us into Canada.
So, this has been going on a long time, and everyone gets harassed, not just foreigners. The US border patrol must only accept people who couldn't pass the 'interpersonal relationship skills' test to become police officers.
Slashdot Mirror
I don't know... 30 minutes could be a long time for front-line shock troops to establish a beachhead. They can then use regular troops (or the same troops out of the armor) to secure the area until a generator is brought in.
Maybe all of the (surviving) predators that normally kill most of the baby turtles will still be looking for them in the Gulf, and next year there is going to be a turtle plague in Eastern Florida.
By neglecting the roads they become full of potholes, making them more dangerous and forcing drivers to slow down. I guess we could also remove all crosswalks and stoplights in order to encourage pedestrians to cross the roads in random places and at random times. The plentiful potholes will make crossing the road even more difficult; pedestrians will need to zigzag to get across so they'll spend more time in the road. What else could be done? Maybe remove safety netting that prevents rocks from falling into the roadway, and weakening the root systems of roadside trees so they're likely to fall over into the road. Plenty to watch out for there.
Finally, if we really want to spend some money on this "safety improvement": landmines.
When you run "My Country", it lets you see the website on the other computer.
I've got one more, which was the final straw for me before I switched to TiVo: the Comcast-provided box had such poor quality Comcast-provided software that it crashed all of the time, wiping out both my existing recordings and all of my schedules. A DVR is really not worth very much if it can only be reliably used to pause live TV.
I loved my MythTV box too, but switched to TiVo when Comcast started moving digital channels around so often that the listings were always coming out wrong, and when it became clear that the analog channels were going away. At least TiVo with cablecards can follow the changes. Comcast still made it very difficult to get the cards; when I called for an installation they said I had to go to my local office to pick it up, and when I went to my local office they looked at me like I had two heads and said they've never dealt with cablecards. Once I finally got a technician to come and install the cards everything was cool, and I've been very happy with my TiVo ever since.
I went for the top of the line model, with the 'lifetime' subscription. I figured that the lifetime subscription is cheaper than the other options after four years, and the box (which the subscription is attached to) should last me that long before it's completely obsolete.
I'm not sure that's true, but my company has only just committed to doing Scrum properly this year so I haven't had the experience yet. But what I'm expecting for larger tasks is to have non-code deliverables, like having some specific portion of a new infrastructure analyzed and designed. Then that portion will be built in a future sprint, while other parts are being designed.
I also expect that my manager will define some deliverables vaguely at the beginning of a sprint, then at the end of the sprint he'll redefine them to be whatever got done and bump the vague deliverable to the next sprint. This is how we'll make continuous progress on open-ended R&D type work, refactoring existing code, doing unpredictable-but-urgent maintenance, etc.
How do you estimate how much work each piece is going to be, in order to divide the work into proportionally-sized pieces?
What's the difference between that and estimating?
I'm pretty sure that most of the risk involved in building a nuclear power plant is the risk that the government (local/state/fed) will shut down the project for some arbitrary reason, like "too many campaign donors complaining about it". So the government is agreeing to deal with the financial consequences of the risk it's creating in the first place, which seems fair. Eliminating the risk would be better, though.
The engineers wouldn't be doing the same work; they'd be doing more advanced work in the same general field. For example, a good plumber can design and install all of the plumbing for a single family home, while an engineer could design the plumbing for a large skyscraper and direct the huge team doing the installation.
This distinction exists in the software industry too, but it's much less formal and less recognized, especially by non-technical management. I think that's due to the relative youth of the industry.
Since the sanctions were supposed to be hurting Saddam, and not the Iraqi people, and we knew what Saddam was doing with the resources, I'd say that the sanctions were a complete failure. It took two wars and an invasion to remove Saddam from power, and in the process we've destroyed a relatively open society, killed who knows how many innocent people, and created enough anti-US sentiment to last for generations.
The problem with this was mentioned by the OP: corporations that are ordered to pay 'compensation' often just give out vouchers for their products, rather than cash. Those vouchers are valued at the full suggested retail price of the products, even if the products never are sold for that price, and the actual cost to the corporation is a small fraction of that price. Individuals who lose civil lawsuits do not have this option, and neither should corporations.
Uranus is inclined over on it's side, isn't it? That's halfway to spinning the 'wrong' way like Venus does. Do astronomers know if it's in the process of flipping over, or are we unable to measure changes that small and slow?
Outlook 2007 was the first place I saw the new Ribbon interface, and though it looked odd at first, I got used to it quickly. I think for Outlook it works really well. I'm still having trouble getting used to the Ribbon in Word and Excel though; while a few things are easier, I still find myself hunting for commands. I think those applications simply have complex command sets, and the Ribbon can't put everything in an easy-yo-find place any more than menus can. Effectively, all they've done is re-arrange the menus.
If you use the camera in your cellphone, you can email the picture to your friend, and they can receive it on their cellphone moments later. That's pretty instant, and not only have you shared the picture, you've made an exact duplicate of it so you can both have it. Can't do that with a Polaroid.
What we need are either better quality cameras built into cellphones, or broadband cellphone chips built into digital cameras. The latter is a more viable option; good cameras are too bulky to be reasonable cellphones, while the cellphone electronics can be easily fit into a decent camera.
Apache is designed to be extremely modular; every request goes through a series of hooks which call out to modules to give them a chance to do something with the request before it's passed onto the next module on the hook or the next hook on the chain. While this makes Apache incredibly flexible and very easy to extend, it also slows down the request processing.
A less flexible design can be made to perform faster, because it doesn't have to do all of the checking needed to determine how to handle the request. Fewer options == Fewer checks. For my company's web application, I wrote a custom HTTP server in Perl years ago which is still in use today. It handles our application and static files, and that's it. It performs as well as a well-designed Apache/mod_perl application, and better than a FastCGI application. That's pretty good for something that has been virtually unchanged since well before mod_perl existed.
Make it personal: "Memory is like the stuff in your head, Storage is the stuff you write down. When you're turned off (eg: dead) the stuff in your head is gone, but the stuff you wrote down is still available. Now maybe you'll remember to tell your computer to write down the document you're working on before you kill it."
There never were any widely accepted scientific laws that ruled out human flight, but most people, including scientists, still believed it was impossible. They lacked one of two things:
The OP's point is that we have to keep our minds open to new possibilities, because not all scientific laws are known yet, and the ones that are known aren't necessarily correct. We only call them 'laws' because they've lasted for a long time as 'theories' without being overthrown... yet.
They all seem to disappear when it rains, which I assume is because they can't get wet. So, they need to be waterproofed, or at least be given big umbrellas.
Umbrellas might work, actually. The umbrella vendors pop up out of nowhere when it rains, like hibernating frogs in the desert. Maybe they could be put to good use covering up the taxis.
I never understood that unit of measurement. Where'd you guys get such regularly-sized rocks? Over here in the colonies, they're all very inconsistent.
During the American Revolution, the British were also apparently upset by the fact that the American army didn't always stand out in the open to get shot at a lot, like a proper army should. Instead, the Americans hid behind trees and rocks, and rather than shooting back a lot, they just shot back a bit, at the British officers. It was a pretty effective strategy when faced with an enemy who likes to shoot a lot, and has the guns for it. It still works today, too.
Map/Reduce was developed at Google. It's a bit tough to wrap your head around at first, and once you get it you wonder what the big deal is, until you realize how suitable it is for Google's datacenters.
Basically, you take a dataset (a bunch of key/value pairs) and a mapping function, and you run the mapping function over every item in the dataset. This gives you an intermediate dataset with different keys and values. You then run that through a reducing function, which produces your final dataset. This can be a single result, or a dataset that can then be processed with a different map/reduce pair of functions.
The big deal for Google is that many of their problems can be expressed in terms of map and reduce functions that can operate in parallel over their datasets, and that their datacenters can handle absolutely enourmous quantities of parallel operations. So, for the mapping operation, they take the original dataset and mapping function, subdivide the dataset over thousands of servers, and let them run the mapping function in parallel. When these servers return their results, it's common for many different servers to return the same or related keys in the intermediate set. These are collated, so that when the intermediate dataset is distributed with the reduce function, all of the values with the same keys go to the same servers. This helps the reduce function to be run in parallel; it's often counting the number of original items that were assigned to the same key in the intermediate set.
The difference is optimization vs generalization. Many problems can be handled using simple key/value pair relationships. You can model this in an RDBMS using two-column tables that you never join across, where all of your queries are SELECT val FROM tab WHERE key=? and INSERT INTO tab (key,val) VALUES (?,?). However, if you use the RDBMS this way, you're paying for the overhead of the SQL engine, (usually) a client/server connection, and your language's library for interacting with an RDBMS.
The alternative is a non-relational database like BerkeleyDB, which is optimized for key/value pair operations. All the fetch and store operations do is fetch and store the value for a given key, with a minimum of overhead. BerkeleyDB is also an in-process database, where your application is accessing the database files directly using the BerkeleyDB library code. (The library handles locking so that multiple processes can use the database files at the same time.) Again, the overhead is kept to a minimum.
BerkeleyDB is much less flexible than an RDBMS, but for the problem domains where that flexibility is not needed, BerkeleyDB is much more efficient. I've easily achieved over 6000 read/write transactions per second on modest hardware in a single-threaded process; a multi-threaded and/or multi-process application can achieve much higher rates. Compare that to a typical Oracle database connection, where you're lucky to get as many as a few hundred transactions per second, just because of the network round-trip.
I'm a US Citizen. While in college, a few of my friends and I went on a road-trip to Canada; our first visit by ourselves. Not knowing the procedure, we parked and walked into the US customs office before crossing the border.
The agents there acted really rude and angry with us; they were intimidating and directly threatening, making a point of the fact that they were all carrying weapons. After questioning us and threating us with incarceration, they let us go and cross into Canada.
The Canadian agent in the booth looked into the car, asked if we had any guns or drugs, and when we said no she welcomed us into Canada.
So, this has been going on a long time, and everyone gets harassed, not just foreigners. The US border patrol must only accept people who couldn't pass the 'interpersonal relationship skills' test to become police officers.
Here's another graph which shows the upward trend in global temperature since the late 1800s; that period is the clearly upward-sloped line on the right. The other graphs in the series are also very informative. These graphs are from the paper Environmental Effects of Increased Atmospheric Carbon Dioxide.