You are making it sound easier than it is.

If its an actual complicated problem, the parts interacts. The complexity is in the interaction.
It is also a matter of "leaky" abstractions. There is always a corner case where the abstractions isn't enough.

Business problems, like all real life problems, are hard- but in a toally different way.
You can't rollback death and not even a spoken word, and you may spend days thinking about unsolvable problems,
but the reality is normally not as rigid and fragile as the abstractions and rules of a computer system.

In real life you can bend the rules.

All tools that tries to remove complexity are fighting against the law of thermodynamics.
Or put in another way, they will make simpler problems simpler, and the rest of the problems harder.

There is probably a sweet spot somewhere around where most popular programming languages are today,
somewhere between assembler code and bpel.

It is possible that the expressability can be improved for some types of problem. It is for instance rather strange that no popular language natively can describe relations between entities, and are forcing us to work with data structures from the 60ies as a workaround for the lack of relational constructs.

Free roads seems to fall out of the fucking sky.

I suspect you would cry about tyrants if you suddenly had to pay per passage for them.

Speaking of Hitler, and roads, you might find a connection there, btw.

Thank you sir. Well said.

A large and complex system will need a manegement and regulatory process that *can* handle requirements that changes (or improves), since the analysis can't be made up front (too complex). An incremental and exploratory process is needed, but I suspect that the processes in place within any government isn't responsive enough, as they are clearly geared for top-down implementation.

Obviously won't the short time frame and political descision vacuum help.

A complex problem won't be simpler just because the tool isn't as powerful. All these ideas comes from a fundamental misunderstanding about what it is that actually makes system development hard.

Well...

As the spot prises go UP when they have to shut down a large part of the total production capacity,
then they may actually make more money from their other plants when that happens.

So there's not exactly any incentives to go check the intake filter too often...

... er, yes. I might be a bit thick here, but isn't the phone authenticating the actual charger?

Well, the problem is that a faulty charger may send +-110 volts as "ground" and -95 to 115 volts as "+5 v" and the phone would be perfectly fine until something or someone touches it and provides a path to true ground.

Extra cheap transformers may also create a phantom ground floating at half the nominal voltage.

> Brillant!

FTFY

I don't know how it is overthere, but here in europe it wouldn't have been blogged about, but instead added to the numerous other stories in the muslim communities and probably - adding to the anger from beeing treated unfairly.

This is so cynically arranged so it makes me think it was the original intention, and the actual security business was used just to fund the agency.

But I guess it's convenient for the copyright police to have swat teams available...

It has nothing to do with redundant systems.

If something goes "outside of the box", the world as the autopilot sees it, it won't notice, or misinterpret the information, and will happily crash without ever noticing that something when wrong.

This may happen with humans too - especially with bad feedback from the airplane, like what happened with the flight AF447, that basically fell out of the sky because the pilots didn't get the full picture of what was going on, [ and because they didn't follow their training, but in their defense, the logic of when the stall warning is deactivated seems a bit counter-intuitive, and perhaps also how much indication the pilot get that he is in fact flying in direct-law mode.]

Currently it's not within our reach to create strong AI that can match humans, and I think it's out of our reach to create a machine that would have done the right things in the AF447 accident. Perhaps it would be possible for a machine to fly safely if someone does the analysis that "well it looks as if the airspeed indicators are gone, probably just ice, please start the "lost airspeed indicator program, high altitude, severe storm" mode.

Today we can only build a machine that merely notices the speeds doesn't match up - *for some reason or another* , and give control to a human, so he or she can figure out what's really happening.

I agree

I'm a programmer, and know a little about AI.

On the surface, it's much easier to build a self-flying machine than a robotic car or even a vacuum cleaner.

The space were you can fly is more or less well known, there are a number of accurate and independent positioning systems available,
the traffic is controlled so nothing should show up in front of the aircraft. The runways are equipped with ILS systems that guides the plane on
a perfect glide slope. The most problematic part might actually be to taxi from the runway and to park, as it's a visual process.
(Doesn't always work even today, I was once in a plane that got pushed into a light pole when leaving heathrow. It tooks some time to sort out, but at least
I can say that I have been in a airplane accident and walked away...)

However, it's a mistake to use these facts to conclude that's it's possible to build an autonomous airplane that's safe enough.

There are algorithms for obstacle avoidance, so it would be possible avoid most of the things that seems to be on a collision course,
  and yes there are fuzzy or neural network based algorithms that seems to be able to adapt to damaged control surfaces and possibly
also missing or erroneous sensor data.

But to handle the sheer number of thing that can go wrong in complicated way, or even figure out that something has gone wrong,
requires more sophistication than we can currently create.

Things that are obvious to a human are surprisingly often extremely complicated to automate, like categorizing things,
detecting shapes, stand on one leg (or two) but stuff that we tend to think is hard normally isn't, like sudoku, long division, geometric calculations etc.
Even chess is just "semi-hard" though beating the best human players requires both clever algorithms and a significant amount of computation, .

We will build these machines, but I'm not flying with them until they are smarter than me.
,
I am certain that that day will come, eventually. Possibly in my own lifetime, and when that happens I think we will have much more interesting topics to discuss on slashdot than airplanes...

Huh? What are you talking about? Jar-files without version numbers in their file names? Maven? IBM including old versions of your favorite tool in their own servers and then implementing randomly behaving class loaders from hell in each release? You had to rename a few variables that happened to be called "enum" ?

  The java api is stable and in almost every sense backwards compatible though. And so is the abi.

So still, moving old java programs to new servers is a walk in the park, compared to some unix related "migrations" i've been unfortunate to deal with.
Yes you need to test, but you don't have to code and code for days and weeks.

I live in Stockholm, Sweden, and here we have cameras in every intersection, scanning all licence plates.

I think the cameras have been there for more than 10 years, and the cameras where installed without any
kind of public announcement,supposedly because they are used for monitoring the traffic flow, and are storing only a hash of the licence numbers.

There is a short notice regarding the cameras on a government website, claiming that there are no privacy issues with the cameras,
as it is impossible to calculate a licence number from a hash.

It does not mention that it is trivial for anyone with access to the system to compute a hash given a license number, and find out wherever your car has been, and how fast it was driving, the last 10 years or so...

In computing, every minor thing can fuck up everything, but there is "not easy" and "totally and utterly fucked up".

Getting old java programs to run is in the "not easy" category...