• 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:

1. The scientific laws that describe how you can generate a lift force using an airfoil
2. 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.

Yes we do, in general :) And a stone is 14lbs.

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.