Andy Tanenbaum, the author of Minix, had a very interesting story about another SCO frontman, Ken Brown. http://www.cs.vu.nl/~ast/brown/ Tanenbaum is somewhat famous for his advocacy of microkernel operating systems. The Linus Torvalds vs Andy Tanenbaum debates on the merits of microkernel (MINIX) operating systems versus monolithic (Linux) operating systems is something of a legend. Nevertheless, Tanenbaum defends Linux fairly vigorously, and this is another comment on SCO's, Dan Lyon's, and Ken Brown's general lack of research.
Ahh, the "when in doubt claim OO is expensive" defense. Please tell me, how long does a modern CPU need to take a branch to an address in a well known fixed memory cell which is guaranteed to be in L1-cache? Do you think it is longer than a conditional branch needed to handle the case single core dual core? Is it longer than the combined times needed to additionally handle the case one CPU-chip two CPU-chips?
The reason why the scheduler is so performance sensitive, is that it uses close to the worst case branching behavior possible. The following steps happen:
1. An interrupt occurs. The entire register set is pushed, page tables in the MMU are reloaded, and kernel code is executed. L1 and L2 cache are reloaded with kernel code and data.
2. Kernel code is executed. Hardware response issued.
3. Scheduler is executed. Per scheduling rules based on waiting processes, new process awakes.
4. New process executes. L1 and L2 caches reloaded. Page tables reloaded.
Massive amounts of CPU data are flushed and reloaded as the ISR / scheduler process executes. Additionally, the scheduler executes frequently. Sometimes the scheduler executes and changes processes once per interrupt, depending on what processes are waiting on what resources. Interrupt frequency significantly affects affects system performance, and the schedulers performance directly affects expensive activities like reloading the page table and reloading the L1 and L2 caches.
The last time I benchmarked the effect of interrupts on system performance, the numbers were like this:
At 1 kHz interrupt rate, the effect of a short background ISR on foreground performance was minimal. About 5% - 10%, depending on the computer.
At 10 kHz interrupt rate, the effect was significant (about 50%).
Between 20-30 kHz interrupt rate, almost all CPU time was being devoted to the ISR. Foreground processes almost stopped.
Testing was on a fast P-III machine or a slow P-4 machine. It has been a few years.
Modern multi-tasking 32-bit CPUs just can't handle very many interrupts per second. The problem is that both the L1 and L2 caches and the memory management tables get reloaded every time a major task switch occurs.
Even if the scheduling penalties were not significant, it is still not desirable to have a pluggable object oriented scheduler. A normal function call is:
CALL function_address
A call to a virtual function in an OO langauge is usually implemented as:
MOV EBX, vtable_address CALL [EBX]// Indirect call
The OO code uses a fully indirect jump, which is significantly slower. However, the big issue is reliability. If the vtable accidentally gets clobbered due to bad code or a hardware fault, then the CALL instruction is a branch to nowhere. Your computer will crash. This fault is non-recoverable since it is in the scheduler itself. If instead we use the faster direct CALL instruction, we know that the scheduler always executes and hopefully some task will run (even if it is the wrong one.) Thus a reliability penalty is paid if we use an object-oriented pluggable scheduler approach.
For performance reasons, and for reliability reasons, it is a really good idea not to have indirect function calls in the scheduler code.
For high reliability code, you write code on the assumption that other code may have problems. You write code defensively. For any kind of complex system, people will make mistakes. Thus you have to continually verify program integrity and security in a multiply redundant manner. You don't wait until a trust barrier is crossed.
For example, if I have an application controlling a power plant, even if the computer is already running "foreign" code at my privilege level, the control application may still be up. It isn't until the foreign code impacts on the control application that a major security problem exists. Unfortunately, Microsoft makes it easy for the foreign code to impact the control application. The code could consume all available CPU resources, it can consume almost all available disk bandwidth, it can run Windows out of Virtual Memory or Handles. None of these attacks are easily blocked by existing Windows security. Of course, when the ability to inject code into the control system is considered, rogue program security gets worse.
Microsoft's threat model does not even consider the effect of "friendly" code, to impact on critical code. If you can't detect adverse interactions with friendly code, then I really question the ability to survive malicious code impacts.
At least two levels of redundancy are required. Malicious code almost always starts as an unexpected consequence of a friendly application, and the first level of redundancy is that the authors write the friendly application in a secure manner. In practice, relying solely on this level of redundancy is fraught with peril. As such, additional levels of redundancy are required. A key second level of redundancy is that even if a friendly application runs amok, the control system should keep running. This implies isolation between applications running at the same privilege level.
The intent of multi-tasking operating systems is to prevent applications at the same privilege level from affecting each other both directly and indirectly. Applications should not be able to affect each other either directly (application to application) or indirectly (via slowing the computer to a crawl.) By only looking at trust escalation issues, Microsoft has a key areas of redundancy and security.
The fast track process does not officially end until after the next ballot resolution meeting (BRM). According to the ISO press release http://www.iso.org/iso/newsandmedia/pressrelease.htm?refid=Ref1070, if Microsoft scrapes together enough support at the BRM, then the OOXML standard will be accepted.
On the other hand, if Microsoft doesn't get the support at the BRM, then OOXML is out of the fast track process and referred back to committee for development.
One way to cause dramatic performance problems on a Windows machine is to simply write a program that accesses lots of files. Performing a network backup with the Windows Networking API is a good example of this. Windows responds by fetching the files from disk and using system memory as a cache. In the process, the working set of programs running on the computer is paged out. The result is that low-priority activities can dramatically slow down potentially important activities on the computer. A good example of this is doing a network backup or a background virus scan on a Windows computer while trying to do any foreground activity (like browsing the web or using Microsoft Word).
So far, in my experience, Linux seems pretty immune to these priority inversions. Will the new scheduling algorithms allow low-priority processes to cause priority inversions by abusing non-processor resources like the network or disk drives?
NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security. One of NT4's design goals was Military security ratings. I liked the feature where you could tell the system to only run 9 different preset executables. It made it really tough to crack (until ActiveX and Internet Explorer came out.)
Generally, SCADA systems are not trusted. All systems have failsafe hardwired I/O that is designed to shutdown on failure. Unfortunately, the shutdowns can cost money.
I just got through getting a cell working after an extensive blast of repetitive downtime. I never did work out what exactly caused the failure, however high on my list of suspects is a router that may have been dropping packets due to excessive network load. When the router shutdown, the PLCs shutdown too. I'm just not clear on what caused all the excessive error packets on the network... I have lots of theories, but no evidence.
These SCADA networks are designed to be operated in a fairly secure environment. They can't withstand errors or high network load. Botnet attacks, virus outbreaks, or someone hacking in can cause trouble. However, mostly I worry about much more mundane causes of downtime.
Microsoft Windows updates, particularly XP SP2, are notorious causes of SCADA system problems. Automatic installation of anti-virus software that triggers system reboots causes system to shutdown unexpectedly. Employees installing CPU-intensive screen-savers also cause headaches. Unexpected system changes result in unexpected system shutdowns. These unexpected shutdowns are what cause the economic disruptions.
Personally, I wonder how much longer we can deploy Microsoft Windows as a SCADA platform. Fast, simple and straightforward are key system goals for SCADA applications. Vista, which effectively requires networking, is a step in the wrong direction. Linux is much more secure, and can easily be set up with read-only partitions. Read-only memory seems to make the systems much more stable, as every reboot always reloads a secure, known-correct program image.
I think you hit the nail on the head. Drawing out creationists into an intelligent academic discussion holds their faith up for questioning. By definition faith must be accepted and cannot be proven or questioned. The creationists know they are correct. You can't question faith.
Digraphs would have come in really handy about 30 years ago when I was working with equipment that lacked a full keyboard and lower case letter support. After the invention of the IBM PC, lower case letter support became standard. Some CNC machines (notably Fanuc lathes and mills) still choke on lower case letters, but they only run G-Code programs and are not used for writing C software.
Platforms that both lack full keyboard support, and run C compilers are few and far between currently.
IMHO, I think:
a) If you want garbage collection, you have to leave C++ and go to a truly safe language like Java or one of the.NET languages. You can't have the ability to do whatever you want to a variable, and the ability to be safe from it simultaneously.
b) If you are trying to code a GUI application with cool RAD development tools (like VisualBasic and Eclipse), then C++ is the wrong language. It was never built to be quick and easy for the programmer. Additionally, the windows based object-oriented metaphor makes proper memory management difficult.
c) If you try to use all of C++ in one program, you deserve to be shot. C++ should be used with strict coding guidelines on what features will be used, and what features won't be used. These features can be picked on a per application basis, and thus the language can be customized for almost anything. Just don't try to do everything simultaneously.
What C++ excels at are projects that require complete control of the machine. If you need the asm directive, its there. If you need funky type unions, you have them. If you need to organize your code, so people can understand it, you have objects and namespaces. If you need to customize the behavior of new(), you can do it. If you need C language compatibility with your header files, it can be done. C++ gives you every option that you may need. Just don't use all of them simultaneously.
Do you code C++ only for PC-class or bigger machines? Or do you also code C++ for an embedded system with small (e.g. 256 KiB) RAM? If so, have you figured out how to compile a program (even Hello World) and statically link it against a Free implementation of the C++ standard library so that the executable is smaller than 200 KiB? I tried GNU libstdc++ with MinGW and (more to the point) devkitARM, and in each case, I got a binary roughly 250 KiB in size.
I have compiled C++ code down for a PIC microcontroller with 8 kB of RAM. The trick is to use only stuff from the C99 standard. Then you compile the code using VC++ on a Microsoft PC and do your unit testing. You can then rename all the CPP files to C files, and recompile under the PIC compiler and generate valid code.
In practice, the VC++ compiler is fairly non-standard, and the renaming of files business sucks. My solution was to move all the code into header files (.h), and then include the headers from stub.CPP and.C files.
The interesting thing was, the development time on the project where I did this was drastically reduced. A full fledged C++ compiler, like Microsoft C++, made program test much simpler. Development time was dramatically reduced because of a much simpler test cycle. This resulted in much more reliable code being given to the PIC, further simplifying the embedded development/test cycle. Debugging an embedded platform is much tougher than debugging on a PC, so any debugging that can be done on the PC is really big bonus.
Another interesting point is that for an embedded platform, particularly the really small chips, you may be better off turning off the entire C Run-Time Library. You aren't going to use any functions from it anyways. Calls like printf() and iostream make little sense on devices lacking basic terminal I/O commands.
Additionally, on devices without virtual memory, you want to avoid calls like new and malloc(). Make everything possible stack based, allocated only once at known program points, or allocated statically. Minimize the number of random allocations and deallocations. If you are trying to prove correctness for long uptimes, you need to prove that malloc() always succeeds. That is a very difficult thing to do given the potential complexities of external memory fragmentation and memory leaks. There is no Virtual Memory available to cover up inefficiencies in your code, in new, or in malloc(). Exceptions are also bad, because you have to prove that every single one of them is handled correctly and won't cause run-time issues. Besides, exceptions, new and malloc() are big sources of random uninitialized memory variables, and often result in slower code. All unexpected behavior on an embedded platform is bad.
On an embedded platform, for long up-times, you must also consider the possibility of hardware memory corruption. As such, statically allocated variables (non-indexed) are nice. You can read directly from a fixed memory location, and effectively verify allowed values. It is also desirable to keep the program simple and straightforward. This makes it easier to prove correctness and simplifies unit testing.
To any potential coders out there: this approach is completely non-standard, and I don't really recommend it unless you are working with embedded devices. My coding style on a PC platform differs significantly from my coding style on memory constricted embedded devices (like PICs). Also, on an embedded device, program length is usually small (for speed). As such, fast obtuse fragments of code are tolerable (if they are commented.) For a PC, programs are bigger, and obtuse code is not nice.
If Google integrated on-line and off-line storage for documents in an easy to use package, that might just be the feature that gets people off of Microsoft Office. Combined off-line and on-line storage might be enough of a feature to force a paradigm shift.
Directly feeding oxygen to the engine will likely dramatically increase horsepower, for as long as the oxygen tank lasts. As such, it isn't to practical for anything other than short distances.
On the other hand, it turns out that nitrous burns even better than air, hence the popularity of nitrous systems to give the extra bit of horsepower boost.
For this application, they will be using an induction AC motor. This is not a synchronous AC motor. Induction motors eliminate the permanent magnets of Brushless DC motors and the rotating electromagnets of synchronous motors. Replacing the rotating magnets with a "squirrel cage" results in a small net weight savings, and a considerable inertia reduction.
In all likelihood the locomotives that you are talking about are also using induction motors. At locomotive power levels, induction motors allow for some nice tricks that blur the line between a conventional induction motor and a conventional synchronous motor. Specifically, if you have a separate power source / load for the inductive rotor, the resulting motor design looks like a synchronous motor, but is really a specialized induction motor. GE even has patents on this technology.
The power research group at my local university even did a research contract with a major multinational on how to exploit induction motor properties for use in new electric car designs. For weight sensitive applications (like a car) over 1 kW, almost all the motors are induction. Even for high-accuracy applications with servo capability, like CNC machines, all the large spindle motors are induction motors. With modern control electronics, an induction motor is all you need.
The pressurized helium/oxygen mixture allows the fuel cells to generate more power than ambient air because of its higher oxygen content, and high-pressure storage eliminates the need for an air compressor
Nice. I expect the common press to make that kind of mistake, but you'd think that Popular Mechanics would get it right.
I think you misinterpreted the article. The oxygen cylinder contains a helium/oxygen mix. They have 2 additional cylinders to get the hydrogen from. The compressed oxygen is used so the fuel cells can absorb oxygen at a much faster rate than if they were burning regular air. Likely the fuel cells can't absorb 100% oxygen, hence they dilute the oxygen with a light inert gas like helium.
Using a dedicated helium/oxygen tank is not likely to be economical for a conventional car.
Installing a motor in every wheel is intuitively a nice idea. Unfortunately, electric motors have a great deal of inertia. At high speeds, the effects of this rotational inertia dramatically affect the stability of the vehicle when it hits a bump.
At lower speeds, vehicle performance is maximized when the motors torque/speed curve is matched to the maximum speed of the vehicle while simultaneously matching motor diameter to wheel diameter. Unfortunately, the wheel diameter, tire diameter, motor diameter, and peak motor RPM rarely agree. Thus mechanical gearing often helps.
An AC induction motor has the highest power/weight density of all electric motors. Brushless DC motors are only competitive for very small motors. Even so, they could probably get a better power/weight number by burning the hydrogen in a modified internal combustion engine or in a jet engine.
Math still has its place. If you want to go to graduate school in humanities, then you may still need some advanced math. In particular, many students from medicine, political science, humanities, and the arts, do advanced multi-variate statistical studies as part of their post-graduate studies. Understanding the tools used in these advanced statistical studies typically requires first or second year statistics skills. If you want your Master's degree, you need your undergraduate math.
As such, a significant number of undergraduate degrees require "Math for Humanities" or "Statistics for Non-stats Major" courses. It is a good idea to keep math throughout high school. It gives you many more options when you reach university.
The xxAA stuff has yet to make it to trial in a civil case. For the people that fight, most of the cases have been thrown out in the disclosure stage. The RIAA must show the defendant might have done something before the case can go to trial. This is proving difficult for them.
Most prosecutors would automatically bounce stupid charges like this. It wastes their time. My guess is that this case never makes it to trial. Even the judge will have a hard time handing out a 1 year jail sentence for 20 seconds of video taping. I'm not entirely sure of U.S. law, but I don't think you would get that kind of jail time for vandalism or petty theft. You would have to do something significant to get 1 year in jail. The punishment doesn't fit the crime.
When the V-Chip was being proposed and designed, I knew that was going to happen. I didn't know of any parents capable of setting the time on the VCR, let alone being able to program it to record a show. The only ones that could use computers were the kids.
It is nice to know that 25 years later, the kids are still outsmarting the results. Way to go youth!!!
In the common law system, Juries are the equalizer against stupid laws. Sure she broke the law. Try to get a Jury to convict, when they work out the trial is about recording 20 seconds of video.
After a few juries acquit, precedents slowly get set, and the law is quietly abandoned.
Slashdot Mirror
Andy Tanenbaum, the author of Minix, had a very interesting story about another SCO frontman, Ken Brown. http://www.cs.vu.nl/~ast/brown/ Tanenbaum is somewhat famous for his advocacy of microkernel operating systems. The Linus Torvalds vs Andy Tanenbaum debates on the merits of microkernel (MINIX) operating systems versus monolithic (Linux) operating systems is something of a legend. Nevertheless, Tanenbaum defends Linux fairly vigorously, and this is another comment on SCO's, Dan Lyon's, and Ken Brown's general lack of research.
The reason why the scheduler is so performance sensitive, is that it uses close to the worst case branching behavior possible. The following steps happen:
1. An interrupt occurs. The entire register set is pushed, page tables in the MMU are reloaded, and kernel code is executed. L1 and L2 cache are reloaded with kernel code and data.
2. Kernel code is executed. Hardware response issued.
3. Scheduler is executed. Per scheduling rules based on waiting processes, new process awakes.
4. New process executes. L1 and L2 caches reloaded. Page tables reloaded.
Massive amounts of CPU data are flushed and reloaded as the ISR / scheduler process executes. Additionally, the scheduler executes frequently. Sometimes the scheduler executes and changes processes once per interrupt, depending on what processes are waiting on what resources. Interrupt frequency significantly affects affects system performance, and the schedulers performance directly affects expensive activities like reloading the page table and reloading the L1 and L2 caches.
The last time I benchmarked the effect of interrupts on system performance, the numbers were like this:
At 1 kHz interrupt rate, the effect of a short background ISR on foreground performance was minimal. About 5% - 10%, depending on the computer.
At 10 kHz interrupt rate, the effect was significant (about 50%).
Between 20-30 kHz interrupt rate, almost all CPU time was being devoted to the ISR. Foreground processes almost stopped.
Testing was on a fast P-III machine or a slow P-4 machine. It has been a few years.
Modern multi-tasking 32-bit CPUs just can't handle very many interrupts per second. The problem is that both the L1 and L2 caches and the memory management tables get reloaded every time a major task switch occurs.
Even if the scheduling penalties were not significant, it is still not desirable to have a pluggable object oriented scheduler. A normal function call is:
CALL function_address
A call to a virtual function in an OO langauge is usually implemented as: // Indirect call
MOV EBX, vtable_address
CALL [EBX]
The OO code uses a fully indirect jump, which is significantly slower. However, the big issue is reliability. If the vtable accidentally gets clobbered due to bad code or a hardware fault, then the CALL instruction is a branch to nowhere. Your computer will crash. This fault is non-recoverable since it is in the scheduler itself. If instead we use the faster direct CALL instruction, we know that the scheduler always executes and hopefully some task will run (even if it is the wrong one.) Thus a reliability penalty is paid if we use an object-oriented pluggable scheduler approach.
For performance reasons, and for reliability reasons, it is a really good idea not to have indirect function calls in the scheduler code.
For high reliability code, you write code on the assumption that other code may have problems. You write code defensively. For any kind of complex system, people will make mistakes. Thus you have to continually verify program integrity and security in a multiply redundant manner. You don't wait until a trust barrier is crossed.
For example, if I have an application controlling a power plant, even if the computer is already running "foreign" code at my privilege level, the control application may still be up. It isn't until the foreign code impacts on the control application that a major security problem exists. Unfortunately, Microsoft makes it easy for the foreign code to impact the control application. The code could consume all available CPU resources, it can consume almost all available disk bandwidth, it can run Windows out of Virtual Memory or Handles. None of these attacks are easily blocked by existing Windows security. Of course, when the ability to inject code into the control system is considered, rogue program security gets worse.
Microsoft's threat model does not even consider the effect of "friendly" code, to impact on critical code. If you can't detect adverse interactions with friendly code, then I really question the ability to survive malicious code impacts.
At least two levels of redundancy are required. Malicious code almost always starts as an unexpected consequence of a friendly application, and the first level of redundancy is that the authors write the friendly application in a secure manner. In practice, relying solely on this level of redundancy is fraught with peril. As such, additional levels of redundancy are required. A key second level of redundancy is that even if a friendly application runs amok, the control system should keep running. This implies isolation between applications running at the same privilege level.
The intent of multi-tasking operating systems is to prevent applications at the same privilege level from affecting each other both directly and indirectly. Applications should not be able to affect each other either directly (application to application) or indirectly (via slowing the computer to a crawl.) By only looking at trust escalation issues, Microsoft has a key areas of redundancy and security.
The fast track process does not officially end until after the next ballot resolution meeting (BRM). According to the ISO press release http://www.iso.org/iso/newsandmedia/pressrelease.htm?refid=Ref1070, if Microsoft scrapes together enough support at the BRM, then the OOXML standard will be accepted.
On the other hand, if Microsoft doesn't get the support at the BRM, then OOXML is out of the fast track process and referred back to committee for development.
One way to cause dramatic performance problems on a Windows machine is to simply write a program that accesses lots of files. Performing a network backup with the Windows Networking API is a good example of this. Windows responds by fetching the files from disk and using system memory as a cache. In the process, the working set of programs running on the computer is paged out. The result is that low-priority activities can dramatically slow down potentially important activities on the computer. A good example of this is doing a network backup or a background virus scan on a Windows computer while trying to do any foreground activity (like browsing the web or using Microsoft Word).
So far, in my experience, Linux seems pretty immune to these priority inversions. Will the new scheduling algorithms allow low-priority processes to cause priority inversions by abusing non-processor resources like the network or disk drives?
NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security. One of NT4's design goals was Military security ratings. I liked the feature where you could tell the system to only run 9 different preset executables. It made it really tough to crack (until ActiveX and Internet Explorer came out.)
Generally, SCADA systems are not trusted. All systems have failsafe hardwired I/O that is designed to shutdown on failure. Unfortunately, the shutdowns can cost money.
I just got through getting a cell working after an extensive blast of repetitive downtime. I never did work out what exactly caused the failure, however high on my list of suspects is a router that may have been dropping packets due to excessive network load. When the router shutdown, the PLCs shutdown too. I'm just not clear on what caused all the excessive error packets on the network ... I have lots of theories, but no evidence.
These SCADA networks are designed to be operated in a fairly secure environment. They can't withstand errors or high network load. Botnet attacks, virus outbreaks, or someone hacking in can cause trouble. However, mostly I worry about much more mundane causes of downtime.
Microsoft Windows updates, particularly XP SP2, are notorious causes of SCADA system problems. Automatic installation of anti-virus software that triggers system reboots causes system to shutdown unexpectedly. Employees installing CPU-intensive screen-savers also cause headaches. Unexpected system changes result in unexpected system shutdowns. These unexpected shutdowns are what cause the economic disruptions.
Personally, I wonder how much longer we can deploy Microsoft Windows as a SCADA platform. Fast, simple and straightforward are key system goals for SCADA applications. Vista, which effectively requires networking, is a step in the wrong direction. Linux is much more secure, and can easily be set up with read-only partitions. Read-only memory seems to make the systems much more stable, as every reboot always reloads a secure, known-correct program image.
For us non-New Yorkers, can you clarify your point? Are we walking into traffic hell?
I think you hit the nail on the head. Drawing out creationists into an intelligent academic discussion holds their faith up for questioning. By definition faith must be accepted and cannot be proven or questioned. The creationists know they are correct. You can't question faith.
Thanks.
Is this a new D language?
Wasn't there a D for Data language in the mid-1980's? Byte even did an article on it ... Can anyone enlighten me further?
Digraphs would have come in really handy about 30 years ago when I was working with equipment that lacked a full keyboard and lower case letter support. After the invention of the IBM PC, lower case letter support became standard. Some CNC machines (notably Fanuc lathes and mills) still choke on lower case letters, but they only run G-Code programs and are not used for writing C software.
Platforms that both lack full keyboard support, and run C compilers are few and far between currently.
IMHO, I think: .NET languages. You can't have the ability to do whatever you want to a variable, and the ability to be safe from it simultaneously.
a) If you want garbage collection, you have to leave C++ and go to a truly safe language like Java or one of the
b) If you are trying to code a GUI application with cool RAD development tools (like VisualBasic and Eclipse), then C++ is the wrong language. It was never built to be quick and easy for the programmer. Additionally, the windows based object-oriented metaphor makes proper memory management difficult.
c) If you try to use all of C++ in one program, you deserve to be shot. C++ should be used with strict coding guidelines on what features will be used, and what features won't be used. These features can be picked on a per application basis, and thus the language can be customized for almost anything. Just don't try to do everything simultaneously.
What C++ excels at are projects that require complete control of the machine. If you need the asm directive, its there. If you need funky type unions, you have them. If you need to organize your code, so people can understand it, you have objects and namespaces. If you need to customize the behavior of new(), you can do it. If you need C language compatibility with your header files, it can be done. C++ gives you every option that you may need. Just don't use all of them simultaneously.
Have you worked with some of these compilers?
I am still really from:
162 % 80 = 66
and
162 / 80 = -1
Hint: cast 162 to a signed char before doing the mod 80 operation. Yes, this bug is in a C compiler sold by a major embedded chip company.
I have compiled C++ code down for a PIC microcontroller with 8 kB of RAM. The trick is to use only stuff from the C99 standard. Then you compile the code using VC++ on a Microsoft PC and do your unit testing. You can then rename all the CPP files to C files, and recompile under the PIC compiler and generate valid code.
In practice, the VC++ compiler is fairly non-standard, and the renaming of files business sucks. My solution was to move all the code into header files (.h), and then include the headers from stub .CPP and .C files.
The interesting thing was, the development time on the project where I did this was drastically reduced. A full fledged C++ compiler, like Microsoft C++, made program test much simpler. Development time was dramatically reduced because of a much simpler test cycle. This resulted in much more reliable code being given to the PIC, further simplifying the embedded development/test cycle. Debugging an embedded platform is much tougher than debugging on a PC, so any debugging that can be done on the PC is really big bonus.
Another interesting point is that for an embedded platform, particularly the really small chips, you may be better off turning off the entire C Run-Time Library. You aren't going to use any functions from it anyways. Calls like printf() and iostream make little sense on devices lacking basic terminal I/O commands.
Additionally, on devices without virtual memory, you want to avoid calls like new and malloc(). Make everything possible stack based, allocated only once at known program points, or allocated statically. Minimize the number of random allocations and deallocations. If you are trying to prove correctness for long uptimes, you need to prove that malloc() always succeeds. That is a very difficult thing to do given the potential complexities of external memory fragmentation and memory leaks. There is no Virtual Memory available to cover up inefficiencies in your code, in new, or in malloc(). Exceptions are also bad, because you have to prove that every single one of them is handled correctly and won't cause run-time issues. Besides, exceptions, new and malloc() are big sources of random uninitialized memory variables, and often result in slower code. All unexpected behavior on an embedded platform is bad.
On an embedded platform, for long up-times, you must also consider the possibility of hardware memory corruption. As such, statically allocated variables (non-indexed) are nice. You can read directly from a fixed memory location, and effectively verify allowed values. It is also desirable to keep the program simple and straightforward. This makes it easier to prove correctness and simplifies unit testing.
To any potential coders out there: this approach is completely non-standard, and I don't really recommend it unless you are working with embedded devices. My coding style on a PC platform differs significantly from my coding style on memory constricted embedded devices (like PICs). Also, on an embedded device, program length is usually small (for speed). As such, fast obtuse fragments of code are tolerable (if they are commented.) For a PC, programs are bigger, and obtuse code is not nice.
Mod Parent Up!
If Google integrated on-line and off-line storage for documents in an easy to use package, that might just be the feature that gets people off of Microsoft Office. Combined off-line and on-line storage might be enough of a feature to force a paradigm shift.
Directly feeding oxygen to the engine will likely dramatically increase horsepower, for as long as the oxygen tank lasts. As such, it isn't to practical for anything other than short distances.
On the other hand, it turns out that nitrous burns even better than air, hence the popularity of nitrous systems to give the extra bit of horsepower boost.
For this application, they will be using an induction AC motor. This is not a synchronous AC motor. Induction motors eliminate the permanent magnets of Brushless DC motors and the rotating electromagnets of synchronous motors. Replacing the rotating magnets with a "squirrel cage" results in a small net weight savings, and a considerable inertia reduction.
In all likelihood the locomotives that you are talking about are also using induction motors. At locomotive power levels, induction motors allow for some nice tricks that blur the line between a conventional induction motor and a conventional synchronous motor. Specifically, if you have a separate power source / load for the inductive rotor, the resulting motor design looks like a synchronous motor, but is really a specialized induction motor. GE even has patents on this technology.
The power research group at my local university even did a research contract with a major multinational on how to exploit induction motor properties for use in new electric car designs. For weight sensitive applications (like a car) over 1 kW, almost all the motors are induction. Even for high-accuracy applications with servo capability, like CNC machines, all the large spindle motors are induction motors. With modern control electronics, an induction motor is all you need.
I think you misinterpreted the article. The oxygen cylinder contains a helium/oxygen mix. They have 2 additional cylinders to get the hydrogen from. The compressed oxygen is used so the fuel cells can absorb oxygen at a much faster rate than if they were burning regular air. Likely the fuel cells can't absorb 100% oxygen, hence they dilute the oxygen with a light inert gas like helium.
Using a dedicated helium/oxygen tank is not likely to be economical for a conventional car.
Installing a motor in every wheel is intuitively a nice idea. Unfortunately, electric motors have a great deal of inertia. At high speeds, the effects of this rotational inertia dramatically affect the stability of the vehicle when it hits a bump.
At lower speeds, vehicle performance is maximized when the motors torque/speed curve is matched to the maximum speed of the vehicle while simultaneously matching motor diameter to wheel diameter. Unfortunately, the wheel diameter, tire diameter, motor diameter, and peak motor RPM rarely agree. Thus mechanical gearing often helps.
An AC induction motor has the highest power/weight density of all electric motors. Brushless DC motors are only competitive for very small motors. Even so, they could probably get a better power/weight number by burning the hydrogen in a modified internal combustion engine or in a jet engine.
Math still has its place. If you want to go to graduate school in humanities, then you may still need some advanced math. In particular, many students from medicine, political science, humanities, and the arts, do advanced multi-variate statistical studies as part of their post-graduate studies. Understanding the tools used in these advanced statistical studies typically requires first or second year statistics skills. If you want your Master's degree, you need your undergraduate math.
As such, a significant number of undergraduate degrees require "Math for Humanities" or "Statistics for Non-stats Major" courses. It is a good idea to keep math throughout high school. It gives you many more options when you reach university.
The xxAA stuff has yet to make it to trial in a civil case. For the people that fight, most of the cases have been thrown out in the disclosure stage. The RIAA must show the defendant might have done something before the case can go to trial. This is proving difficult for them.
Most prosecutors would automatically bounce stupid charges like this. It wastes their time. My guess is that this case never makes it to trial. Even the judge will have a hard time handing out a 1 year jail sentence for 20 seconds of video taping. I'm not entirely sure of U.S. law, but I don't think you would get that kind of jail time for vandalism or petty theft. You would have to do something significant to get 1 year in jail. The punishment doesn't fit the crime.
When the V-Chip was being proposed and designed, I knew that was going to happen. I didn't know of any parents capable of setting the time on the VCR, let alone being able to program it to record a show. The only ones that could use computers were the kids.
It is nice to know that 25 years later, the kids are still outsmarting the results. Way to go youth!!!
In the common law system, Juries are the equalizer against stupid laws. Sure she broke the law. Try to get a Jury to convict, when they work out the trial is about recording 20 seconds of video.
After a few juries acquit, precedents slowly get set, and the law is quietly abandoned.