Another reason not to like DAB

It's real! This single track is no longer used; there's a newer double track a tad south, that runs under the Sugar Bowl ski area. There are lots of freight and passenger trains.

What's amazing is that people are allowed to hike and drive up into the old tunnels, miles of tunnel, show shed, and occasional open stretches hugging the cliffs. No guard rails.

Is anybody capable of creating secure software?

Of course! But you have to set that as a goal to begin with! You can't "back-fill" security.

Is anybody capable of creating a reliable power supply?? Surely NOT if your goal at the outset is *inexpensive*, short time to market, planned replacements/upgrades, etc.

Most people are. Few people can create secure software, even when they try.

Really? Almost universally, the item that renders most of the devices that I've purchased "inoperational" is a power supply or power conditioning somewhere in the circuit.

Of course, the reason cited is "cost", expected product lifetime, etc.

Can we start applying the same excuses to software, too? I.e., "boss wanted to keep development costs low -- to keep *product* costs low" (just like saving a few pennies on a power supply amortized over a few million units??)

Tell people you value security, reliability, etc. and they will produce products that meet those goals. Instead, tell people you want a $30 DVD player and you'll end up with a device that will bearly survive its warranty period ("Hey, what did you expect for $30??")

Sure, you can buy the cheapest power supply around, and expect it to be junk. Probably by design.

Do you think that IE, or OSX, or Jeep software, or the software that runs the US government database, was done on the cheap?

"One U.S. official said the breach of data involving more than 4 million past and present federal workers was being investigated as a national security matter. That suggests authorities believe a nation was behind it rather than a more loosely organized gang of cybercriminals. The official was not authorized to discuss an ongoing investigation and spoke only on condition of anonymity.

The breach was an embarrassing showing for the U.S. government's

supposed to detect unusual Internet traffic that might reflect hacking attempts or stolen data being transmitted outside the government."

So, the power supplies in the $200 monitors, $2,000 televisions, $500 printers, $100 DVD players, etc. are ALL junk? I guess the folks designing reliable power supplies just don't cater to the same markets as the folks who expect ALL software to be "bug free", reliable, secure, etc.

How many millions of dollars of failed power supplies are discarded each year? Forget the associated costs of the devices that they were powering (and part of) at the time! But, those are "acceptable losses" -- expectations for hardware are that it *will* need to be replaced due to failure. Yet, software is supposed to magically be perfect -- else the monies spent on it are considered waste (but the dollars spent building those broken power supplies aren't?)

I think you sorely underestimate the complexity of even the most trivial piece of software.

Next time you want to design a piece of hardware, start by growing some silicon wafers. Tell me how long you expect the design process to take. And, how reliable you expect the resulting product to be.

Hardware is relatively easy to create. Look at your "standard components". Two and three terminal devices. Easily characterized. Even highly integrated devices are easily characterized.

Sort of like an *opcode*: take one of these 4 billion discrete values, combine it with another of these 4 billion discrete values and obtain exactly one of a resulting N billion values. (amps, volts, etc.). Put a few MILLION of these components together in a time-significant sequence and you've got a reasonably small (by today's standards) piece of code.

Put a few million GATES together and you've got a processor. Not the sort of thing you knock out in a few weeks on a lab bench. And, most definitely not the sort of thing you can completely and exhaustively characterize (like your few hundred component power supply).

Even the more highly integrated hardware components are far easier to characterize than the most widely used "software components":

- How big is the executable? (on which processor? what compiler options?)

- How much data memory does it require? (for what set of inputs??)

- What is the maximum stack penetration? (for what conditions?)

- How long does it take to execute? (in what environment?)

- What is the expected "result"?

Yet, the software is expected to perform reliably *forever* -- else you get folks complaining that it's buggy, insecure, unreliable. Yet, for a power supply to crap out after a few (tens??) thousand hours is "Wow, look how reliable that *WAS* (past tense)!"

When people place value on security and reliability in software, they

In Kalifornia? No Prop-65 warning either?

My wife drives a couple of year old Mustang Convertible ('14 model). Nice car. The instruments are *supposed* to be retro. The entire car is supposed to be retro '60s. That's the whole point.

The MY'15 is an entirely new car from the ground up (but looks quite similar) and by all accounts are *really* nice drive.

If all car companies did that, you wouldn't drive anything. All rental cars are the pits.

Yep. Seems to be a common theme with all commercial software. Software development has entered the stone age (maybe).

In theory, no. The "Infotainment" network is supposed to be isolated from the "safety critical" networks. In reality, theory and reality don't match so well (as we've seen in the news recently).

...and Google cars don't scare you?

The answer to your question is simple; "consumer electronics". Yes, it's all junk. It's not designed to last (or perhaps even "designed not to last").

And TCP/IP is *not* a reliable protocol. It guarantees not to deliver data out of order, but it doesn't guarantee to deliver anything within any fixed time window, or to report failure in any time window either.

We had more guard rails in Louisiana, which is absolutely flat, than we have in California, where a second of inattention will toss you 400 feet down into a forest or into the ocean.

We use MeanWell open-frame PFC switchers for something absurd like 20 cents per watt. And Phihong and Samsung wall-warts for $5 to $10 each. They are great.

You can get cheaper stuff if you really want it. The low end warts and USB supplies can't deliver 50% of the nameplate current.

The problem is that it's so complex that nobody can understand it.

Exactly. Most hardware designs don't exceed the definition of "too big to fit in a single braincase" (complexity). OTOH, many software designs easily exceed that!

Try building a piece of hardware that will sort an undefined number of inputs by value. Or, sum a set of values -- each having 200+dB of dynamic range. Make sure it works over the entire operating temperature range without degradation. Expect a customer to requests along the lines of "sum only the values that are multiples of 3 (unless they are also multiples of 5!), after discarding the highest and lowest" -- and to support that retrofit IN THE FIELD... all without disturbing any of the gizmos that are presently "wired" to the circuit. And, marketing has promised it by 5:00PM tomorrow!

If confronted with this sort of request, you'd laugh and, if the client/customer was serious, quote some ridiculous (from the standpoint of the client!) price and delivery schedule. But, software is magically expected to adapt -- without concern or consideration for how many initial assumptions have been violated by that request! And, as there is no "visible" change in the deliverables, any significant change in price is considered gluttony!

I'd say yes, that some people are. But it takes extraordinary care, and a recognition that things must be kept simple, so that all the possible ramifications can be anticipated.

In practice this means that programs that, by their nature, cannot be kept simple, and which have access to critical systems[*], must not receive data from any potentially insecure source.

Some manufacturers do seem to understand that. Too many either do not, or just don't care.

Sylvia.

The problem is that in complex systems, like internet-connected things, people don't write all their own code. They incorporate all sorts of junk from OSs, libraries, compilers, whatever.

It's not too difficult to write secure and bug-free embedded apps, even RTOSs, if one good programmer can do the entire project. But nobody can make millions of lines of code reliable.

The critical stuff in a vehicle should be essentially bare-metal, and its communications to other processors should be serial or SPI or some non-TCP/IP sort of basic thing. Giving an engine control computer an IP address and connecting it to the wireless world is crazy.

People have claimed that they can hack an aircraft FADEC from a passenger seat. I sure hope that's not true.

On Thu, 23 Jul 2015 20:57:02 -0700, John Larkin Gave us:

If you think flight control computers are hackable via passenger in-flight wireless networks you are nuts and so are the hackers who claim they can. They are not merely "two different network segments on the same network", they are 100% completely different networks, and TCP/IP is not even involved. Most are ARINC, which no tcp/ip dopehead is going to be hacking from his passenger seat.. They are typically CLOSED, hard wired systems. Doh!

Despite the fears pilots and airlines, etc. show, one cannot even disrupt such systems with devices using RF means, such as explicit attempts to jam or access.

All this "turn off all devices until airborne" crap is nonsense.

Short of a major EMP pulse it ain't happening ("it" being disruption or takeover control).

Typically, the passenger entertainment system includes a display with aircraft position, altitude and speed. The most obvious source of the data for that is the aircraft's navigation system, which implies a communications link.

Such a link can be made indisputably one-way, and should be in this application, but absent a clear description of the actual mechanism used, we have to take it on trust that the implementation really is one-way.

Sylvia.