This kind of thing happened to NASA as well: https://www.cnet.com/news/nasa...

What makes Windows slow is usually the antivirus. Linux and Mac is much faster because they don't need that crap. Now, at work we want to use Linux, also to get around the antivirus slowness. Give the MD infested IT department any excuse and they will have antivirus stuff to cripple our Linux installations as well.

Actually here in Denmark many people use "jordvarme", which google translates to geothermal, which it is _not_. It is a AC turned around: you pump heat from the colder ground under your garden into your house using less electrical energy than the heat energy you get into your house. The efficientcy is better than 1:3.

Fortran77 or Fortran 90/95? Fortran 77 is a _pain_. Fortran 90 or later is almost modern language with modules and recursion.

With C++ I try to make the type system catch errors, for instance by using units for length different from time (boost units). And I often set up make to not only build binaries but also run unittests. Thus if unittests fail, the build fails. It is a lot better that the build fails for the developer, than later on during the release test, and must worse if the program is shipped with an error.

It is the American system coming to EU: political decisions decided in the courtroom using law instead of letting the politicians decide. I sympathize with this guy but I will not have neither the courts, nor EU to interfere. I want the our national parliament in Copenhagen to make law saying it is illegal to lay of people for being obese when they otherwise perform their job.

Well, I guess you will say I am one of them. But I still feel it makes sense to use templates in more than a core library or STL.

Quite often I define a method as a template over one of the parameters. Then as it calls another method etc I can specialize. Forinstance, if I have class hiracy with Object at top, I could write a method called foo(Object *obj) {....} , or template foo(Obj *obj) { ... bar(obj); .. }. Now I can compiletime specialize over the type of object depending on where I come from.

Another examble is building classes consisting of one of more objects, which will differ. Doing it the OO way, you will need to do class Foo { Interface *mSomeObject; .... };, whereas with templates it becomes template class Foo { SomeObject mSomeObject; ....}; Thus template saves you an indirection and virtual function, but still leaves your code open to generalize. Thus I build up both type heracies and specializations by templates. Without it you will need references to a interfaces and lots of calls to virtual functions.

Do you make your own list, vector etc?

I have done so as for special cases, but in most cases stl works just fine. In the past it has been buggy but that was 10-15 years ago - and more so in embedded environments.

If you do not use templates and STL, what is the point of C++? You can do the same in C, you just have to make the v-table by hand as is done in the Linux kernel.

My experience:

When I started at my current job 7 years ago I came from C and C++ to Java. I liked Java a lot. We had a little bit of C++ and C utilities but our main application was Java.

Then we needed something running realtime and I went back into C++. It took quite a while to make a relative simple application because I had to start from scratch with basic network and serial interface handling. Also I had to make an interface protocol to speak with the rest of the application writen in Java.

Then we started another much larger add on which needed high performance. C++ was the only realistic choice. I estimated the time to write the code would be 3 times that of our prototype written in Python. I was wrong! It is hard to meassure because the prototype and the production code did not do the same thing, but it certainly did not take 3 times the efford to write it in C++ than Python. And compared to Java it was not much harder to write it in C++. Debugging might be a be harder, but we have no problems with memory leaks, segmentaion faults and other memory issues being the usual problems haunting C++. And note: Java and Python also have memory leaks due to dangling references. These can be very hard to find, too.

C++ is not 3 slower to write code in than Java and Python as I expected. It is almost 1-1 - as soon as you have written the framework of your application. One of the major design rules which definitely helped us was: Avoid multithreading ! Instead our application is split in processes, communicating with sockets. Each process is a loop around a select() call. The split in processes makes it much easier to spot errors. Each process is run in a while loop in a screen such the system can recover from a crash of one of the processes.

We avoid memory leaks by using (now deprecated, I know) std::auto_ptr. It is implicit in our code that the owner have the auto_ptr, while all others jave a plain poitner to the object. The owner have it as a auto_ptr. shared_ptr are rarely needed.

Another thing: We write Java like rather than C like C++: We do not use pointer arithmetic. We use STL or our own containers. We avoid unsafe typecasting. We try to code against interfaces rather than implentations and all the other best practises of object orientated programming. Stuff you only learn properly by coding Java or another OO language.

The network handling in the C++ parts worked almost flawlessly, old bugs keeped appearing in the Java network code. This was because Java per default rely on thread for everything: Befoe select was added to Java you needed a thread for reading a thread for writing for each TCP connection. And getting the threads to work together quite right is hard - in any language. Then it is easier to have one thread and events when the socket changes state.

The major issue with C++ over Java and Python: "Batteries are not included". And no STL is no near the standeard libraries in Java and Python. Not even boost gets close. But in our case, once we had the basic eventdriven framework with sockets and buffers, connection handling build up of logical classes around a select loop it was easy to add new functionality. C++ is not good for writing large monolithic applications because it can be very hard to localize errors - Java handles that much better because it is much easier to localize errors. But Java (and Python) still uses way to much memory when you represent data as objects.

Another thing C++ has is ofcourse templates. It is a really good alternative to object orientated techniques for writing re-useable, generic code. The good thing is it all bindings happens compile time. That means both that many errors are caught compile time, and that the compiler can optimize seemingly very expensive code. When calling a virtual function in an interface the compiler very rarely can figure out which implementation it really is and do optimizations.

All in all: C++ is a good, powerfull and high performance language - but it requires a lot of decipline from the developers (especially when dealing with pointers) to avoid the usual deathtraps in C++. By now I like C++ better than Java. Java was a disappointment for me: You end up with a lot of threads. Garbage collection is not fail-proof against memory leaks anyway. The seemingly ease of writing code in Java only fools you: The code ends up having many bugs but the application can "limb on" even though one thread have thrown say a FloatingPointException.

1) Any country should require that the source code of all software (including embedded) should be sent to the National Library as most already require for printed material. Not to be made public, but for scholars to be able to study it in say 50 years. And to be able to do the following: 2) when the company do not publish security patches within a reasonable time, everybody with a legal copyright license should be allowed to get a copy of the source code to fix the security issues on their own (or hire a consultant to do so).

WRONG: They used GCC and contributed back to the project. But as far as I understood, FSF and RMS stopped accepting their patches because of dislike of Apple. Not really GPLs fault, but FSFs centralized "community" model.

There is nothing wrong using GCC under GPL in a coorporate context. We do it at work all the time. I worked with VxWorks. Wind River sent us a version of GCC (and binutils, gdb etc) as part their development kit and IDE. Nothing wrong with that.

What is wrong with the GNU project is _not_ GPL, but the copyright handover and centralized control, which have a tendensy to impose political constraints on projects. Things like the Linux kernel and git works a lot better under GPL but out of FSFs control.

Wrong: " If you would ever let your software be used by for-profit interests,"

You have totally misunderstood than man: He has nothing against "for-profit." He is against closed source. He want to let everybody to have the freedom of controlling, modifying and hacking their own devices - and sent usefull programs to your friends with no commercial license stopping you. That is the freedom GPL is designed to protect. It is not some "socialist", anti-capitalist ideology, but fighting for freedom of the individual hacker over cooporate profit.

I agree with RMS: All the major tools ought to be GPL. Not necessarily GPLv3 but copyleft. A way to make BSD and GPL coexist: Make a Git repository following the main project, but accept GPL'ed patches. The result will be GPL. If enough developers will only send patches there, that repository will win over the users as well. I think FSF ought to take that approach and help set up such clones. Stop copyright handover and all the other nonsense. Stop controlling the projects. Use Git or whatever technology to allow easy maintainance of copyleft versions of BSD projects.

And the general population is against having such a speed limit. So this is not going to happen.