According to a report I saw (following a link from the Drudge Report yesterday):

1)The early symptoms of Ebola are very similar to those of Malaria, to the point that people with malaria are being thrown into the ebola quarantine camps. (Also: Many of the people who HAVE ebola, or their support network, may THINK thay have malaria.)
2) The camp ran out of gloves and other protective gear - leaving the staff and patients unable to clean up after and avoid contagin from the body fluid spillages of the actual ebola patients. Come in with SUSPECTED ebola and you soon have ebola for sure.

That, alone, would make it rational for someone not yet sick or mildly sick, incarcerated in the camp, to break out and hide out.

3) Stories are circulating in the area that ebola is a myth and the oppressive government factions/first worlders/take your pick of enemies are using this story, plus the odd malaria case here and there, to create death camps and commit genocide in a way that gives them plausible deniability.

That idea, of course, can lead to mass action by some of the local population to "rescue" their fellows and sabotage the camps.

The whole think is a real-world example of the cautionary tale "The Boy who Cried 'Wolf'". When the officials lie to the people for their own benefit, repeatedly, until the people come to expect it, the people won't believe them when they are telling the truth about a real threat - and all suffer.

Ebola is one mutation away from being airborne transmissable. It already happened with Ebola Reston -- fortunately for us all, that turned out to be transmissable to monkeys but not humans.

I've heard reports that it may have happened with this one, too.

It doesn't have to be as GOOD at doing airborne transmission as, say, the common cold, to be a BIG problem.

Yeah, I can't complain about the EOD bots. Actually, I'd think those would also be ideal for some kinds of wacko-with-a-gun situations. If the wacko is alone you can send in the robot to talk to him, and the guy could surrender the gun to the robot. That lets you disarm the wacko while reducing the risk of a situation where a cop would have to shoot the wacko in self-defense. Sure, it won't be able to subdue him on its own, but that isn't the point - you want to talk to them, calm them down, and get them to put the gun on the floor and walk away from it. This lets you do it without putting a person in harms way, which means you can be more patient and not fire as soon as the guy twitches.

Yup. We really need to crack down. If we keep up this laxity before we know it people will feel like it is OK to change religions, marry somebody of a different religion, or teach a girl how to read.

Like file downloads vs. interactive sessions, some power loads just need a long-term average and can be adjusted in time, without noticable impact, to shave peaks and get a closer match to generation - even if some of the generation, itself, is uncontrollably varying.

In fact, this is already being done. A prime example is in California, where a large part of the load is pumping of irrigation and drinking water. California utilities get away with far less "peaking generation" than they'd otherwise need by pumping the water mostly at off-peak hours. Cost: Bigger pumps, waterways (and in some cases "forebay" buffer reservoirs, below the main reservoir) than would be needed if the water were pumped continuously. This is practical because it was cheaper to upsize the water system than build and run the extra peaking plants. (Also: The forebay-to-reservoir pump generates when water is drawn down. It can also be run as a peaking generator, moving reserevoir water down to the forebay during peak load hours.) Similar things can be (and are being) done with industrial processes - such as aluminum smelters.

But there's a limit to load flexibility. Sure you can delay starting your refrigerator, freezer, and air conditioning for a few minutes (or start a little early, opportunistically), to twiddle the load. But you can't use such tweaks to adjust for an hours-long mismatch, such as the evening peak, or an incoming warm front leading to calm air and overcast skies on a chunk-of-the-continent basis. Try it, and your food spoils and your air conditioner (or heat-pump heating system) might as well be broken, or too small for your living area. Sure you can tweak factory load some. But do it too much and you reduce the production of billion-dollar factory complexes and workers who are still getting paid full rate.

Renewable energy actually helps - because its large-scale variations are driven by some of the same phenomena that affect heating and air conditioning loads. More wind means more heating and air conditioning load due to more heat transfer through building insulation. More sun means more air conditioning. Solar peaks in the day and wind in the evening (due to winds driven by the "lake effect" on a subcontinental scale), so a mix of them is a good match for the daily peak. But it's nowhere near "tweak to match generation and load without waste".

Special driving license, maybe...

If we were talking about busses I'd definitely buy in. They're larger than normal cars, and there are issues with evacuation, and situations that just don't come up with cars.

However, driving a taxi safely is no harder than driving a car safely. Maybe just a special endorsement after taking a quiz would make sense. If somebody can't drive a few passengers safely, they can't drive a family safely, or even themselves safely without putting others at risk.

I heard a story about another "killer building" near Chicago. (Haven't checked the claims for truth - just repeating it as I heard it.)

Seems there was this nice commercial builing next to O'Hare Airport. Curved walls, lots of lawn, nice walkway up to the door in the middle. Great view through the space over the airport runways.

There was this one spot on the walkway where more than one person was found unconscious or dead of apparent heart failure. There were enough that somebody looked into the coincidences.

Turns out the building's curve was parabolic and it faced a runway. If you happened to be at the focus when a jet taking off crossed the axis, the building concentrated the sound of the engines on you...

Is this REALLY something that needs to be regulated by law? I can understand the need for insurance, basic safety, etc. However, if it takes you a few minutes longer to get to the destination to save $5, shouldn't that be a choice you can legally choose to make.

I mean, I'd hope that the UPS driver wouldn't get lost finding my house and delay the shipment for a month, but if UPS did that routinely they'd be out of business, so it isn't necessary to regulate it.

Well, no doubt they have standards, but they are their own standards.

I'm all for basic requirements around liability insurance and such as long as they aren't over the top (you shouldn't need a million dollar policy to carry a few passengers).

The thing is, it is in Uber's interest to ensure a decent level of quality everywhere. If somebody gets mugged by an Uber driver in Italy, they will lose customers EVERYWHERE. If somebody gets mugged by an Italian taxi driver, it won't affect the revenues of the London taxi drivers all that much. It is really a different model to quality - it isn't necessarily worse, just different. I think it needs to be regulated differently, but I don't suggest that we should accept unsafe conditions.

I think the point is that Uber is a global brand. Thialand Taxi Company or whatever they call it isn't. I have no idea if their Taxis are good or not, but I know what Uber is. Maybe Thailand Taxi is better, but it is an unknown quantity for somebody new to the country.

If I go to Uzbekistan and need to mail a package back to the US, maybe the Uzbekistan post office is decent. But, if I see an office labeled "UPS" I have some kind of expectation about what kind of service it will provide, and if UPS wants to remain competitive as a global provider they're going to strive to meet that level of service everywhere. Global companies stay in business by offering their customers a uniform experience that they can't get without being experts in every country on earth.

The concept is like a film camera. You capture the data first, and deal with it later. No CPU is involved in the actual collection of each frame, and they capture a VERY limited number of frames as a result.

When they did bullet time in the first matrix movie they just lined up a whole bunch of cameras and triggered them at very short intervals. Each camera only recorded a single frame. You can collect/process the data later - the critical part was capturing the data. Most high-speed data collection works the same way - extremely fast sampling times, but capture is done into a small buffer and then offloaded later.

Well, they don't transport anything anywhere with their solution. But, if you had a technology that could actually offload the data to bulk storage and thus operate "indefinitely" the speed of light would not create any problems whatsoever.

Just send the data down a wire or fiber optic cable. Sure, the first byte will only travel a few mm before you have to send the second, but there is no law saying that you can only have one packet of data in the cable at a time. Speed of light impacts latency, not bandwidth. If you want to be able to retransmit lost packets/etc then that latency will have a HUGE impact on your buffering requirements at both ends. We're talking transmitting trillions of data points before getting the first ack.

The reality is that it will be a long time before this technology could be operated for more than a handful of frames at a time. We don't have any technologies with the necessary bandwidth to transfer this kind of data volume quickly. Even if a frame only required a kilobyte of space to store, you're talking about petabytes per second here. Still, the speed of light is not a fundamental limitation on bandwidth.

Bjarne: There really is a question at the end of this, but it takes some setting up. Please bear with me.

In the late '80s I came to Silicon Valley for a startup, which was using C++ for a major project. I learned the language then and got over the "doing it the object-oriented way" hump. In the process I analyzed what cfront was producing and got a good understanding of what was under the hood (at the time).

The project was very ambitious. Much of it was creating a data base engine for a complicated indexing mechanism. The result was that transactions occurred by creating a transient structure. The bulk of the work occurred during its construction, and errors during this stage had to be unwound carefully.

In those days C++ didn't have exception handling - "catch" and "throw" were reserved words, to be defined later. (So I built a set of exception handling classes that unwound even errors thrown from deep in construction and destruction correctly.)

Some of the architectural types had come to OOP via Xerox PARC and Smalltalk, and didn't want to be "slowed down" by getting "manual" memory management right. So we built a set of classes (incluing "smartpointers") and a preprocessor (to automatically generate pointer-identifying virtual functions) and got garbage collection working just fine. (We did a similar thing for remote procedure calls, and so on. We may still hold the record for layers of preprocessing between source and object...)

C++ WOULD have been the ideal language for it. But we found a little hole in the spec that caused BIG problems. The language got it SO ALMOST right that it was painful.

Consider construction of a subclass with virtual functions. Suppose the base class exports a pointer to itself (say, putting it into an external list). Then suppose that, at some time during the execution of the constructor of a member object of the derived class (or other initialization of the derived class), something gets hold of that pointer and calls a virtual function of the base class that is overridden by the derived class. Does it get the base class or derived class version of the function?

IMHO it should get the BASE class version during the initialization of the derived class UP TO the execution of the first user-written statement of the constructor, and the derived class version once the constructor's guts are executing. Getting the derived version before the constructor proper is entered means attempting to use functionality that has not been initialized. (Before the constructor is enetered you're still initializing the component parts. During the constructorf you initialize the assembly, and the author can manage the issue.) Similarly, during destruction it should get the derived version through the last user written line of the destructor, the base class version after that (as first the object-type members, then the base class(es), are destroyed).

Examples of how this would work in real problems:
  - Object represents a an object in a displayed image. The base class is a generic displayable object, which hooks the object into a display list. It has a do-nothing "DrawMe()" virtual function. The derived class adds the behavior. When the display finishes a frame the list is run, calling the "DrawMe()" methods of all the objects. If one is still under construction and the derived class overriding is clalled, uninitialized memory is accessed (including pointers containing stack junk).
  - Object is heap-allocated. Virtual functions are the "mark()" or "sweep()" pointer enumerator for the garbage collector. Base classs is the generic "I'm a heap allocated object" substrate, hooking into an "allocated objects" list with do-nothing virtual functions. At each level of object derivation the new version of the function enumerates, for the mark and sweep phases, the member variables that are pointers (and calls the base class version to also enumerate the pointers at the more baseward layers. The pointers' own initialization clears them to NULL before this can happen. If a derived class constructor exhausts memory and triggers a garbage collection before all the pointers are set to null, getting the derived-class version of an enumeration routne means following stack-junk pointers. Crash!
  - Exception-handling during constructors involves a similar mechanism to identify what levels of DEstructor need to be called to unwind the construction. Again a virtual function (this time the actual destructor) identifies the level of construction that needs unwinding. Again, getting the derived class overriding before the constructor is entered means calling the destructor for an uninitialized level. Oops!
There are, no doubt, many similar real-world patterns, since the problem is fundamental.

So when we discovered the wrong level was getting called in some cases, I did a survey of available compilers, looking for one that got it "right". WIth both constructor and destructor behavior to be done right or wrong, there were three wrong ways and one right way:
  - cfront (and the cfront-derived compilers got it wrong one way.
  - the three commercial compilers for PCs got it wrong a second way.
  - gnu g++ got it wrong the third way.

So we had to program around it. We were able to get the exception handling to operate correctly. But both exception handling and garbage collection required that all nontirival processing had to be moved from initialization to constructors. Member variables of object type had to be moved to the heap - replaced by smartpointers - and allocated by the constructor. Compact composite objects allocated and freed as a unit became webs of pointer-interconnected heap objects, allocated separately (thus multiplying allocations and frees). In addition to the extra memory management, the number of pointers that had to be followed by the garbage collector exploded. Efficiency went out the window.

Of course, since the published language definition didn't actually DEFINE the behavior, "right" or "wrong" were not official.

This was during the ANSI deliberations for the first generation of standards. The current draft explicitly left open the issue of which overriding you got in this circumstance. So I petitioned the committee to define it - "correctly". I had high hopes, since everybody would have had to make a change so it wouldn't favor some vendors over others. But on the second round of email replys I got somethint that seemed strange - saying something about it not being important because "C++ doesn't have an object model". (Say WHAT?) I was too busy to pursue it further, let it drop, and the standard came out with the behavior explicitly undefined.

When the second round of ANSI standard came by (after my participation in the project was over) I tried again, just to "fix the language" to avoid this sort of subtle bug. Still no luck: This time the standard not only left it open, but explicitly said (approximately) "Don't write code where this could happen."

By the third round I had "gone over to the hard(ware) side of the force" and didn't pursue it.

IMHO this is the one thing in C++ that is a real language killer (of the sneak-up-behind-and-knife-the-developer variety).

So, FINALLY, the question:

Has this been fixed yet by the newer standards? If not, is there a chance that it will be at some future time? (Perhaps if YOU brought it up there might be more attention paid to it.)

While I agree with you that most people cannot tolerate hipsters, I disagree with your assertion that most people will put up with unlicensed taxi drivers.
I travel all over Europe and Asian as part of job and for personal reasons and I have learned one thing..NEVER take unofficial taxis. EVER.
Oversight and regulation of certain industries are not a bad thing.