C and ADA are the two languages I've run into for actual safety-critical projects

For Non-safety-critical, non-flying software, mostly C.

For testing environments (runs tests on the software/hardware and collects the results) C# and Python seem to be the popular choices. However very few of them have been "Tool Qualified" (i.e. proven to be 100% accurate in their assessment of if a test passed or failed), mostly out of laziness and managers being scared of the toolqual process.

As stated, these are the reasons others at my company have given me for why they don't use it. I don't have the direct experience to challenge this, nor do I have the authority to make a decision to use C++ on a project, I'm brought in after those decisions are made and the work is started.

I would actually love to learn more about the language and use it, especially if it actually has application to the Avionics world.

This must be prefaced by mentioning that I have little experience with C++ code, the industry that I am in (Safety Critical Avionics software) absolutely refuses to use the language. In fact, the only thing I can really comment on are the reasons given to me as to why it is not used in this industry.

Compiling repeatability
Part of Safety Critical Avionics is that the binary must be perfectly re-creatable. At any time if an issue comes up someone must be able to rebuild the configuration used for compiling (versions, software packages, patches, etc.) and get a perfect match to the released binary, bit-for-bit perfect. Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.

Code-to-binary and structural coverage analysis
For DO-178B Level-A software (paraphrase: "If this software fails, people die.") there is an analysis performed matching every line of code to a block of assembly, verifying that the compiler didn't add anything in that will cause issues. This prevents using some optimization options in C as that makes things too unreadable. However that also excludes C++ STLs and Boost libraries, as once you get into those libraries the traceability breaks down into impossibility very quickly.

Internationalization
On the side our company works on non-safety-critical software projects as companies need our help and we are looking for work. One of those side jobs is taking an application written over several years for a research facility and making it ready to be sold internationally. The project uses C++ and is converting X11 and Motif to QT, at the same time updating it to go from hard-coded English to strings that can be translated to multiple languages. The amount of cursing I hear from those engineers dealing with the internationalization of C++ far outweighs everyone else in the company on all other projects, apparently the design of the C++ language made many decisions that make such efforts very difficult.

So, mostly hear-say but from trustworthy and knowledgeable people, which is why I rarely touch the language.

This should really be looked at by those producing Diesel engines for Airplanes.

The biggest problem tinker's face when trying to put a Diesel engine on an airplane is that the Diesel has very massive "power surges" each time a cylinder fires, and a nasty power "stall" when it's compressing a cylinder. This isn't a huge deal with the other applications of Diesel engines, they just add mass to the fly-wheel and transmission and that takes care of it. In Airplanes however, the mass costs too much (in terms of airplane weight) so they try to reduce it as much as possible, however if you reduce it too much the propeller is literally torn apart by the surges and stalls. Early tests had the propeller lasting only hours when running on a 4 or 6 cylinder diesel. If there is a reduction drive on it to bring the RPMs further down they too like to self destruct with a Diesel.

If they could use a low-weight magnetic coupler to absorb the surges and stalls and provide smooth power that would solve the biggest problem putting a diesel on an airplane and would really boost that market!

Thanks for the reasonable response.

I am personally for the death penalty, I believe your actions have consequence and you have to pay for that consequence (a liberal nightmare). There are crimes that are so horrendous that the only consequence that can be fitting is death. Considering the crimes that these men have been convicted of I think the penalty is correct.

As for the method of going about the death penalty, I think the current system is so overly complicated that it's almost designed to fail, and when it does fail it creates a terrible situation. Going back to something like the guillotine would be a good idea, while messy it is a quick, clean kill that is hard to botch.

I'm at that point however. I have a Nest thermostat which I love, but now that Google owns it I'm wondering what my options are. I'd love it if I could break into it and load my own firmware, or even an opensource firmware. I think the JTAG pins are exposed as pads on the main board so I should (in theory) have some access, I just have to figure out what exactly that access is...

I think right now this situation is so complex and muddied that no-one is in the right, and no-one has all the information.

Accusations have gone back and forth like crazy but I still haven't seen any of them from either side backed up by evidence beyond "it's obvious", which, in this situation, I highly doubt.

As for these supposed Russian commandos... I really doubt they are what the report says they are. Whenever you send agents (either Spies or Commandos) into the field you strip them of anything that would identify them as spies/commandos, having ID cards for "Spetsnaz" sounds like a plant to me.

"We found the enemy's agents doing bad things so we have reason to attack!" when they are nothing more than your own agents planted to make them look like the enemy.

I also find it interesting that this bit of 'news' hasn't shown up on any even remotely neutral news sources. I frequent the BBC and have been watching their coverage of this Cluster F*** closely, and while they have agreed with USA in many of their stances and statements concerning this, they have no mention of this bit of news... makes me very suspicious of it's authenticity.

All that being said, I really think Russia is going to far and should back off, let things settle, allow the "newly independent Crimea" to exist for a while to prove it's not a Russian puppet but actually something it's people want.

Actually, what you are seeing is criminals taking over the exploitation of exploits, before it was hackers having fun and sending "it's my birthday" messages around, now it's serious criminals using exploits to steal serious money. These people don't advertize their finds, they use them to the fullest extent possible. When PHD's find an exploit you can be sure 90% of the time it's already known to criminals who have used it for a while.

If you wonder at the accuracy of that, just look around at how many viruses are out there and start counting the news reports for companies compromised.

It's both interesting and very sad that this has to be spelled out in a license agreement, makes me think that they've run into OEMs purposefully building 'bombs' to keep people buying new phones.

Southern WI got hit with 2 inches of "Wintery Mix" yesterday, along with blowing/drifting snow from the 2-3ft of it already on the ground (winds were around 20mph).

However, this is a state of people who have experienced the above a couple times a month during the winter season. We know how to drive and handle the conditions, and WI has really amazing road crews that work very Very hard to keep the roads drivable and are very well equipped for what they are doing. I wouldn't want to be in your shoes, that same "wintery mix" with millions of people inexperienced in driving in those conditions and road crews who have rarely if ever faced such a mess and are ill equipped to make much of it. I am not patronizing you in any way, those conditions are legitimately terrible.

Were I down in that area during the storm, I'd likely have taken the day off or worked from home. If I had been at work when that hit and told to go home, I'd probably have found the closest friend to work and crashed their couch instead of trying the full trip home.

Then again I'm usually driving with a blanket or sleeping bag in the car in case I get stranded in the snow. Northern winters are not something to take lightly. It doesn't have to be snowing for there to be white-out conditions, all we need is snow already on the ground and a good wind. We also get a decent amount of real cold around here, while this year is especially bad, it's a rare year that we don't go down to -20f for a few days or a week. Most people here who do any driving outside the cities/towns will have gear in the car to survive being stranded in the snow overnight in -10 to -20 conditions, it's part of living here.

You see them more often in the Embedded world than on full computers. A big one I ran into recently was with Freescale 68HC12, an ancient processor and compiler. It would randomly decide if incrementing or decrementing (var++; or var--;) would be done as integer increment/decrement (add/subtract 1) or pointer increment/decrement (add/subtract 2). We had a lot of interesting bugs where it would randomly decide that a for loop would do pointer math instead of integer math and we'd skip half the work.

This was very recent, and with latest patches (for some definition of latest... they were concentrating on their new eclipse based IDE with it's GCC compiler so this one wasn't being worked on).

I am ready to look into that, I have a nest (1st gen) and experience and tools in embedded development, looking at the mainboard (reverse side) for the nest there are plenty of touchpoints and even a set of contacts, how much you want to bet the JTAG interface for the Microprocessor is exposed letting someone (like me) install my own software?

Right now I'm looking around to see if anyone else has started this effort, no takers thus far but maybe that's just my search-fu being weak.

The target audience for this site is American English speaking technical people, just because other people read the site doesn't mean they should change things from the target audience to pander to a minor fraction of readers.

You want an American site to pander to you and you call us arrogant and self-important.

A wiring harness may just be easier to build yourself, there are places you can get the color coded wires and the wrap for bundling them together, and there are likely plenty of sources for wiring diagrams, worst case you can tear apart your old harness to make a diagram of your own. (speaking from the standpoint of someone who has looked into this for my '64 p1800)

Making other car parts is a different issue entirely, at least for the engine... most likely one that will stay in the realm of casting and machining instead of 3D printing.

An engine part often has very very tight tolerances, down to 1/1000th of an inch for mounting surfaces and alignments, something I don't see 3D printing replicating anytime soon, then to add to the fun engine parts have to hold up under stress from the combustion process, lots of heat and vibration.

Now, that's not to say it will never happen, there may be a 3D printer capable of laying down metal with strength comparable to cast or forged counterparts, with an accuracy capable of a mirror finish, but I'm not expecting it anytime soon or for a price that's less than the value of the entire car.

However, if you want to print cosmetic components of a car (rear-view mirror mountings, gauge faces, handles, etc) that is very likely possible now.