Guess what? Cold places use MORE energy than warm ones. While people like to hate on ACs as some excess, they are actually quite efficient. Since they move heat, they can move more energy than they use. A good AC can easily move 3-5 watts of heat for each watt of energy it requires to operate. No such luck with heating systems, they at best get you 1 watt of heat for each watt they take.
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.
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.
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.
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 de
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).
If LLVM had not been under a BSD license they wouldn't have used GCC, it's corporate poison, they would have rather licensed Intel's C compiler or something and the community would have gotten absolutely nothing.
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.
This just demonstrates that we rely way too much on GPS, which is easy to jam. Maybe it is about time the civilian society also do "exercises" where GPS is jammed and see how we cope? If it is that dangerous for the navy to jam GPS, then it must be real tempting for terrorists to do so..
Linux with PREEMPT_RT is as predictable (but not as fast) as VxWorks in the mentioned categories, you just have to make sure that all the RT tasks have SCHED_FIFO or SCHED_RR to behave correctly. VxWorks doesn't have (or at least didn't in version 5.4-5.5 which I used to code for) SCHED_OTHER. And that is a huge drawback for VxWorks because very often you have a lot of application threads running with no hard deadlines and might fluctuate a lot in how much CPU they use (webserver and other user interfaces). In VxWorks you have to give all such tasks priority 255 and use time slicing. Otherwise one task suddenly taking a lot of CPU will starve all tasks with lower priority until it is done.
Another problem I have seen in VxWorks is the priority inheritance: It doesn't work correctly for nested locks: A low priority task takes a lock A, runs it's own code for and then it calls into say a driver and takes lock B. Now some high-priority task wants to access the same driver and tries to lock B. The first tasks is then boosted in priority and soon finishes the driver call and unlocks B. But it is not unboosted before it release A. That is a huge problem in a RTOS: Suddenly the timing of the high priority task depends on how long a low priority tasks keeps the completely irrelevant lock A. You don't get the decoupling, that the timing of a high priority tasks only depends on the tasks of equal or higher priority, which is so important in a RTOS.
Basicly, I think core of Linux with PREEMPT_RT is a better (more deterministic) RTOS than VxWorks, but slower (longer maximum latencies for especially interrupts); but all subsystems around the scheduler etc. aren't coded for RT use - i.e. it has non-deterministic code-paths and might even make blocking calls. So an RT application on Linux/PREEMPT_RT can basicly only use basic highres timers, simple serial ports and memory mapped devices. Use of the netstack, disk IO is a no-go. But then again, the same applies to VxWorks...
I have actually seen such a problem myself: Controllers crashing because someone was testing the network. The problem was, ofcourse, that the CPU spent a lot of time to handle the amount of packages on the network and therefore didn't have time enough for it's real-time application. (It didn't help that the platform didn't support DMA.)
Solution: Make the network interrupt handler threaded and prioritize it below the real-time application. Sure, that doesn't help the SCADA performance, but you have to make sure that the real-time application meets it's deadlines no matter what is going on on the network. I simply don't buy that you can secure a network stretching over more than 1 meter against "data storms."
Memory protection isn't a big issue in embedded programming. It is only a issue when somebody has a pointer bug - and you simply can't allow for pointer bugs if every application is critical, can you? Memory protection is much more usefull on general perpose machines and handhelds. Maybe on large embedded system where you want to add something like a webserver, which you can allow to restart once in a while - but I don't think they have that in a racing car.
I know at least one F1 team used VxWorks. At that point at least it didn't have any form of memory protection, either, just one big virtual segment where everything would run in kernel mode. They had at that point something called VxWorks AE with memory protection, but they pulled it from the market because it was a flop. I am pretty sure it wasn't used in the F1 car. They have later on made a more standeard version with "realtime processes" with full memory protection, closer to how Unix behaves.
> If road racing turned to recumbents, such tactics would virtually disappear due to the shelter advantage > being reduced to minimal.
I don't think so. The shelter effect would still be there, just at mush higher speeds. And therefore the sport would be much more dangerous than it already is. Now the riders ride very close and only a small misshap make a large group fall over at maybe 50 km/h. With the recumbents it would be at 80 -100 km/h!
The top riders in the Tour have sustained power output over 500 watts. I used to be fairly good at racing but not anywhere near the elite, I could do 350 watts, maybe a little bit more. I wonder in what range these recumbents guys are? The 350-400 watts range would probably be a good guess.
> This whole "get the facts" campaign is just silly. I don't know why they keep on with it. > I've been working with Linux for years and never run into any of the problems they have > "documented".
I know why: Windows people believe it in. At least my colleages (all Windows people) site those reports whenever I claim that Linux is better. They have lived with MS so long, they can't understand that other systems doesn't are not born with the same problems. They also have to defend themselves for their choice of system, so they readily believe those reports. A IT manager can also use them against their bosses, if they start to ask questions about, why you don't use this Linux system and save a lot of money. Many people don't want to move! Microsoft provides them reports to convice themselves and their bosses they shouldn't.
Slashdot Mirror
Guess what? Cold places use MORE energy than warm ones. While people like to hate on ACs as some excess, they are actually quite efficient. Since they move heat, they can move more energy than they use. A good AC can easily move 3-5 watts of heat for each watt of energy it requires to operate. No such luck with heating systems, they at best get you 1 watt of heat for each watt they take.
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.
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.
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.
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 de
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).
If LLVM had not been under a BSD license they wouldn't have used GCC, it's corporate poison, they would have rather licensed Intel's C compiler or something and the community would have gotten absolutely nothing.
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.
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.
but you can patent the application in a specific area to solve a specific problem. Nothing new there.
becomming a lawyer than an engineer isn't she?
hell breaks loose
This just demonstrates that we rely way too much on GPS, which is easy to jam. Maybe it is about time the civilian society also do "exercises" where GPS is jammed and see how we cope? If it is that dangerous for the navy to jam GPS, then it must be real tempting for terrorists to do so..
Another problem I have seen in VxWorks is the priority inheritance: It doesn't work correctly for nested locks: A low priority task takes a lock A, runs it's own code for and then it calls into say a driver and takes lock B. Now some high-priority task wants to access the same driver and tries to lock B. The first tasks is then boosted in priority and soon finishes the driver call and unlocks B. But it is not unboosted before it release A. That is a huge problem in a RTOS: Suddenly the timing of the high priority task depends on how long a low priority tasks keeps the completely irrelevant lock A. You don't get the decoupling, that the timing of a high priority tasks only depends on the tasks of equal or higher priority, which is so important in a RTOS.
Basicly, I think core of Linux with PREEMPT_RT is a better (more deterministic) RTOS than VxWorks, but slower (longer maximum latencies for especially interrupts); but all subsystems around the scheduler etc. aren't coded for RT use - i.e. it has non-deterministic code-paths and might even make blocking calls. So an RT application on Linux/PREEMPT_RT can basicly only use basic highres timers, simple serial ports and memory mapped devices. Use of the netstack, disk IO is a no-go. But then again, the same applies to VxWorks...
I have actually seen such a problem myself: Controllers crashing because someone was testing the network. The problem was, ofcourse, that the CPU spent a lot of time to handle the amount of packages on the network and therefore didn't have time enough for it's real-time application. (It didn't help that the platform didn't support DMA.)
Solution: Make the network interrupt handler threaded and prioritize it below the real-time application. Sure, that doesn't help the SCADA performance, but you have to make sure that the real-time application meets it's deadlines no matter what is going on on the network. I simply don't buy that you can secure a network stretching over more than 1 meter against "data storms."
Well, a typical modern turbine gives 3MW when the wind blowes more than 12 m/s. 341 of them gives approximatele 1 GW.
I know at least one F1 team used VxWorks. At that point at least it didn't have any form of memory protection, either, just one big virtual segment where everything would run in kernel mode. They had at that point something called VxWorks AE with memory protection, but they pulled it from the market because it was a flop. I am pretty sure it wasn't used in the F1 car. They have later on made a more standeard version with "realtime processes" with full memory protection, closer to how Unix behaves.
> If road racing turned to recumbents, such tactics would virtually disappear due to the shelter advantage
> being reduced to minimal.
I don't think so. The shelter effect would still be there, just at mush higher speeds. And therefore the sport would be much more dangerous than it already is. Now the riders ride very close and only a small misshap make a large group fall over at maybe 50 km/h. With the recumbents it would be at 80 -100 km/h!
The top riders in the Tour have sustained power output over 500 watts. I used to be fairly good at racing but not anywhere near the elite, I could do 350 watts, maybe a little bit more. I wonder in what range these recumbents guys are? The 350-400 watts range would probably be a good guess.
> This whole "get the facts" campaign is just silly. I don't know why they keep on with it.
> I've been working with Linux for years and never run into any of the problems they have
> "documented".
I know why: Windows people believe it in. At least my colleages (all Windows people) site those reports whenever I claim that Linux is better. They have lived with MS so long, they can't understand that other systems doesn't are not born with the same problems. They also have to defend themselves for their choice of system, so they readily believe those reports. A IT manager can also use them against their bosses, if they start to ask questions about, why you don't use this Linux system and save a lot of money.
Many people don't want to move! Microsoft provides them reports to convice themselves and their bosses they shouldn't.
If Linus believed this he would drop Linux and buy SCO's UnixWare. Isn't Linux just an reverse engineering of Unix??