For you, the EC certification organization rules things just like the FCC does in the US and Industry Canada does in the Great White North. There is no place on the planet (or, in fact, within about 40,000 km of its surface) that there isn't a wireless standards compliance organization that claims control of the airwaves. One of the reasons that radio works at all as a commercially available communications medium, is that everyone designing and deploying the transmitters is playing by a cooperative set of rules. It would not take too many folks deciding that their transmissions were more important to significantly degrade the utility of wireless systems.
As a current and past employee of several companies that make wireless transceivers subject to FCC licensing, I can tell you that there is no cost effective way to limit a device to FCC restrictions purely in hardware. Example: A cellular radio or any other modern RF link uses a synthesizer to set the transmit frequency. The output frequency of the synthesizer is a function of the reference frequency and the programmed divide ratio, and the total span of achievable output frequencies is dependent on the VCO that the synth is controlling. The maker of the synthesizer is not usually in a position to dictate the exact reference frequency, nor the VCO that it's hooked up to. The VCO vendor doesn't dictate the type of system that it will be installed into, and therefore can't strictly limit the frequency that it will tune to - and even if they did know exactly where it was going to go, then production tolerances dictate that you have some tuning margin in the design to allow all parts to hit the specified span. That means that individual parts will be tunable outside of the specified span on either the high or low side, and if the micro that controls the synthesizer commands a frequency outside the FCC limits, a lot of the time the hardware will have no problem doing it.
The same thing applies generally to power output levels. Sophisticated radios have some spare margin in the transmitter power output, and the actual output power level is calibrated at manufacturing time and then set in a FLASH based lookup table. The output power is then controlled using the embedded micro, driving a DAC. In this system, having open code on the embedded micro means that an uncaring individual could just crank the power output without regard for the FCC requirements.
You can say what you want about the motivations and ethics of the OpenBSD team members - if the source is out there, there will be others that take advantage of any "gains" they could make by tweaking some tuning parameters beyond the design or regulatory limits.
Ask Theo de Raadt how long it took him to get from his buffer-overrun Sun console hacking days to where he is now - almost everyone goes through a phase where "Just because I can" is sufficient justification to do poorly thought out things.
Maybe someone can explain to me why driving above the speed limit is acceptable? There is nothing in the law (at least where I live) that says the left lane is for people that wish to speed.
Generally, the left lane is for people that wish to pass other traffic.
Most places (not Alberta, but we have signs proclaiming "keep right except to pass" or some such thing) have laws that prohibit you from passing on the right. In that case, someone traveling at whatever speed in the left lane presents a legal obstruction to anyone else on the road. Suppose they have a defective speedometer and they think they're doing the limit when they're actually doing ten under?
When I tow my camping trailer on the highway, I travel at about ten under, just to keep the fuel costs somewhat under control. Accordingly, I keep to the right lane. If someone wants to pass me and they stick to the speed limit, then it will take them about ten to 15 seconds to go by. However, if they speed up so that they're going ten over the limit, then their exposure time in the left lane is cut in half, and this frees up the left lane for other traffic. Staying out of the way of other traffic as long as doing so doesn't put you in danger somehow, is just good manners.
Well thought out safety features will save many lives on the occasions that they function effectively... However, there are many cases where safety features are nullified due to the ignorance of the driver and/or passengers, and reducing the incidence of collisions by better driver education (and proper appreciation by the driver of what they're doing) is the cheapest safety of all.
Examples include: Proper adjustment of the seat and headrests for best control and protection; proper wearing of the seatbelt; proper use of child-safety seats; keeping signal lights in proper function and using the turning signals; Taking new drivers on a real high-speed driving course where they actually do accident avoidance maneuvers; teaching new drivers how to recognize treacherous road conditions; more emphasis on cooperative driving instead of purely "defensive driving" (which quickly turns into a passive-aggressive "I can be in the left lane because I'm doing the speed limit" game).
The sun produces blackbody radiation, but the full-spectrum energy gets produced only at the core and radiates out from there. It gets filtered by pretty much the entire sun's radius worth of helium and hydrogen, which produces the spectrum absorption lines. Yes, it's still nearly a continuous spectrum, but the sun's color temperature can be nearly approximated (at least perceptually) by a proper combination of different colored LEDs. There are several patents out there on using the combined output of blue/UV LEDs with fluorescent material (to produce broad spectrum "white" illumination) and backfilling the gaps in the spectrum using red/yellow/green LEDs at the appropriate intensity.
But that's the point... you want to create code that either uses a native feature found on certain CPUs (maybe something that PowerPC architecture is optimal for, as compared to the Pentium architecture), or else something that you KNOW causes bad behaviour under certain compilers. As a long-time embedded software designer, I can tell you that with embedded hardware, OS and compiler suites, there is a BIG difference from one system to the next on the level of optimization. About 10 years ago we were doing competitive analysis on various embedded (or embeddable) CPUs, using standard benchmarks as well as a few processing tasks of our own. If you increased the task complexity a critical amount, you'd cause one CPU to start cache thrashing, and the other CPU, with a slightly bigger cache or better reuse strategy, would be fine. Under the rules of the contest, this would be exactly the kind of thing to exploit.
From the poster: However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent? Equating "talent" with "experience" is going to get him into trouble... anyone that lacks talent (at whatever task) will have a tough time either understanding what a more experienced mentor is trying to get across, or they'll have a problem adopting a suggestion from a brilliant protege.
What would a fully functional independent robot do? How would it improve your lifestyle? What is that worth to you, as a consumer? When you can make a valid business case based on good answers to those questions, the robots will come out of the woodwork.
In some arenas, the technology already exists. Roomba vacuums are fully functional independent robots. You can get (for a price, and with limited capability) robot lawn mowers. Some subway systems use automated trains; they're fully functional and independent within the constraints of their designed task. Fully automated aircraft landing systems have been demonstrated, but they require infrastructure investment and some psychological buy-in by the travelling public. Autopilots (especially as implemented in cruise missiles) are essentially independent survival machines with a dedicated goal.
You can see that the main issue with robotic systems is to get them to have some consideration for human existence, if the mechanical system that they operate is large enough to injure or kill them. Remove that constraint, and it's a lot easier.
One thing that should definitely be avoided is C - for goodness sake teach a safe language like Pascal instead. Beginners should not be dealing with pointers to memory (most developers never need to anyway).
OOP needs to be taught at the start, not as an optional add-on. If beginners shouldn't be dealing with pointers, then don't teach that part until they've grasped all the other aspects of writing procedural code. Pointers don't point to memory... they point to things. If you're using pointers to randomly traverse your machine's guts then you deserve what you're getting. There are some things (such as linked lists) that are far easier to construct using pointers than by doing it by maintaining array indices (for example).
OOP is good for object-oriented tasks. The biggest problem that I see is that when people use C++ they suddenly feel the need to approach everything from an object-oriented perspective, and they begin by picking the wrong objects with the wrong attributes. To pick good object properties, you don't need to understand OOP, you need to understand the problem you're trying to solve and have a clear idea of how you're going to approach it. The key to OOP is design, not the language you're using to do it.
Would the average american want to watch a black and white movie, where you can see the strings, and there's only 6 actors, and the director/producer/editor/cameraman/lighting tech/lead actor is all the same person?
Sounds like Clerks... It was the best thing to hit the big screen in a long time, for a lot of reasons. With the advances in CG animation and home production software, there is no reason a small studio or group of individuals couldn't put together a movie that challenges the big guys on either the storyline or effects fronts - unless you assume that quantity will always outweigh quality.
without a backup. As mentioned by lots of other respondents, RF reception can be affected by any number of external factors, and you'd never know unless you continuously checked your phone's received signal strength indication. Does your phone alert you when it goes into "no service"? No? Better sue the phone maker for putting you at risk of being without a lifeline... or else read your service contract, and the phone's manual, carefully. If you need 100% communication reliability with someone, better stay within arm's reach. Nothing else is totally reliable.
Unless the equipment manufacturer is negligent, the equipment you're all lugging around will be (a) relatively immune to interference occurring outside of it's operating band and (b) relatively quiet outside of it's designated transmitting band.
GPS receivers (at 1575 MHz and 1227 MHz) are typically not affected by emissions from cellular equipment (which operates at 800, 900, 1800, and 1900 MHz for most of the European and North american systems) unless you happened to drop your phone directly on top of the GPS antenna.
Going just to geosynchronous orbit wouldn't hold up the cable. The center of mass of the cable and counterweight need to be past geosynchronous altitude. Going just to 62 miles wouldn't accomplish anything - there isn't enough atmospheric density there to allow a balloon to be used to provide the cable tensioning force, and orbital velocity at that altitude is something like 20,000 mph.
The reason to run the cable out to 62000 miles (far beyond geosynchronous orbit) is to be able to hang a counterweight on the outboard end and to have that provide sufficient tension to keep the cable up.
There was an article in Analog (WAAAAY back when) on the math behind space elevator cables, and they indicated that unless a material such as carbon fibers (nanotubes and the like weren't even on the horizon then) were developed to commercial viability then the required strength to weight ratio would make the cable waaay too wide at its halfway point.
The best thing to do is have everyone agree on the code development method, not the specific language. You can always document your design using the same templates - a function is a function is a function, and you should always have an interface description doc as well as something that describes the code's behavior in more abstract terms than what the source provides.
I'll put in a "me, too" recommendation for this book. Designing with a factor of safety in mind is obvious, but all too often the end result is compromised becasue either the engineers didn't understand the loads imposed or else the builders didn't follow the engineers' design.
Another great book is "Engineer to Win" by the late Carroll Smith. Even if you're not a racing car nut, this book presents a thorough overview of applied materials science and failure analysis, in some very plain language. Get it at any good speed shop.
The cement truck was the most disappointing one in a long time. Everyone who has ever even seen explosives in action knows that you drill a hole in the material (the cemet block in this case) and drop the TNT down the hole before detonating it. They just hung a stick of dynamite above the cemet, and gave up when it didn't do anything.
The idea was (first of all) to try to prove or disprove what the hypothetical truckdriver was supposed to have done - which would not have entailed drilling a hole in the cement. After that failed, the point was to make the biggest bang possible. And they succeeded beyond all expectation - the sound even coming over the TV speakers was incredible. I agree that it would have been interesting to do any number of other experiments, but with explosives you only get one successful shot at it.
The article summary mentioned, among other things, the appliances getting price-of-power and system load information over a broadband Internet connection. So that's where my Internet reference came from. Having the devices use local frequency change information is possible only if they have access to a long-term-stable frequency reference, and even then their reaction time and their local environment would influence the stability of the control loop.
The function of the DC-DC converter is to take the 12V (+/- some tolerance) input, and turn it into regulated 1.8V, 3.3V, 5V, and -12 Volts (or whatever) at much higher current levels. Since it's 96% efficient at doing that, you'll only generate about 5 watts of heat even when you're pumping 115 watts into the CPU, hard drive, and motherboard. Finding or building a 115VAC to 12VDC power brick is pretty easy by comparison, and it's also subject to a lot of regulatory requirements that the DC to DC converter itself isn't. There is a lot of merit to separating out the two parts of the problem, especially since cars and RV's (for example) don't need the 115VAC to 12V step in the first place.
My only question would be, as others have already asked... is the 12V input tolerant of the automotive environment? SAE has a standard (J1211? Can't remember...) that specifies the typical extremes for voltage spikes due to boosting screwups, alternator load dump, and various motor load transients. If this module was designed to survive that stuff, then that would be great.
Two things that together determine the stability of a feedback control system are the loop gain and the loop phase delay. High gain and a long delay in the loop make for a very jittery system and one that's easily driven into oscillation. In the power control system described, adding more and more 'smart' devices would progressively increase the gain, while the delay would be somewhat unpredictable, since it would depend on the speed of an appliance's Internet connection and the speed at which the power utility updated its energy forecast. You can assume it's going to be random within some bounds, but the price of being wrong on that is very high...
Just a note on De-ionized water, anyone who ever worked with it knows it's very corrosive. It tries to bond with ions in anything it can get it's hands on. It dosn't stay deionized for very long if it's in contact with any metals.
"Deionized water is corrosive" is a commonly held misconception, but it's absolutely false. Distilled water (or de-ionized water, whatever you want to call it), is non-conductive. It doesn't "want to" or "try to" do anything... but it's a fact that lots of stuff is soluble in water to some extent, and once that happens the water's conductivity goes way up and then electrolytic action is possible.
Slashdot Mirror
For you, the EC certification organization rules things just like the FCC does in the US and Industry Canada does in the Great White North. There is no place on the planet (or, in fact, within about 40,000 km of its surface) that there isn't a wireless standards compliance organization that claims control of the airwaves. One of the reasons that radio works at all as a commercially available communications medium, is that everyone designing and deploying the transmitters is playing by a cooperative set of rules. It would not take too many folks deciding that their transmissions were more important to significantly degrade the utility of wireless systems.
The same thing applies generally to power output levels. Sophisticated radios have some spare margin in the transmitter power output, and the actual output power level is calibrated at manufacturing time and then set in a FLASH based lookup table. The output power is then controlled using the embedded micro, driving a DAC. In this system, having open code on the embedded micro means that an uncaring individual could just crank the power output without regard for the FCC requirements.
You can say what you want about the motivations and ethics of the OpenBSD team members - if the source is out there, there will be others that take advantage of any "gains" they could make by tweaking some tuning parameters beyond the design or regulatory limits.
Ask Theo de Raadt how long it took him to get from his buffer-overrun Sun console hacking days to where he is now - almost everyone goes through a phase where "Just because I can" is sufficient justification to do poorly thought out things.
It's wrong because the sculpture encodes four puzzles. The solutions to the first three parts are required to solve the fourth part.
Generally, the left lane is for people that wish to pass other traffic. Most places (not Alberta, but we have signs proclaiming "keep right except to pass" or some such thing) have laws that prohibit you from passing on the right. In that case, someone traveling at whatever speed in the left lane presents a legal obstruction to anyone else on the road. Suppose they have a defective speedometer and they think they're doing the limit when they're actually doing ten under?
When I tow my camping trailer on the highway, I travel at about ten under, just to keep the fuel costs somewhat under control. Accordingly, I keep to the right lane. If someone wants to pass me and they stick to the speed limit, then it will take them about ten to 15 seconds to go by. However, if they speed up so that they're going ten over the limit, then their exposure time in the left lane is cut in half, and this frees up the left lane for other traffic. Staying out of the way of other traffic as long as doing so doesn't put you in danger somehow, is just good manners.
Examples include: Proper adjustment of the seat and headrests for best control and protection; proper wearing of the seatbelt; proper use of child-safety seats; keeping signal lights in proper function and using the turning signals; Taking new drivers on a real high-speed driving course where they actually do accident avoidance maneuvers; teaching new drivers how to recognize treacherous road conditions; more emphasis on cooperative driving instead of purely "defensive driving" (which quickly turns into a passive-aggressive "I can be in the left lane because I'm doing the speed limit" game).
The sun produces blackbody radiation, but the full-spectrum energy gets produced only at the core and radiates out from there. It gets filtered by pretty much the entire sun's radius worth of helium and hydrogen, which produces the spectrum absorption lines. Yes, it's still nearly a continuous spectrum, but the sun's color temperature can be nearly approximated (at least perceptually) by a proper combination of different colored LEDs. There are several patents out there on using the combined output of blue/UV LEDs with fluorescent material (to produce broad spectrum "white" illumination) and backfilling the gaps in the spectrum using red/yellow/green LEDs at the appropriate intensity.
You don't understand... the power of DNF is such that anything related to it, even press releases and Slashdot stories, show up late.
But that's the point... you want to create code that either uses a native feature found on certain CPUs (maybe something that PowerPC architecture is optimal for, as compared to the Pentium architecture), or else something that you KNOW causes bad behaviour under certain compilers. As a long-time embedded software designer, I can tell you that with embedded hardware, OS and compiler suites, there is a BIG difference from one system to the next on the level of optimization. About 10 years ago we were doing competitive analysis on various embedded (or embeddable) CPUs, using standard benchmarks as well as a few processing tasks of our own. If you increased the task complexity a critical amount, you'd cause one CPU to start cache thrashing, and the other CPU, with a slightly bigger cache or better reuse strategy, would be fine. Under the rules of the contest, this would be exactly the kind of thing to exploit.
From the poster:
However, while I'm far from l33t, I've several years more experience than my partner. Are there effective techniques for pair programming with a wide gap in talent?
Equating "talent" with "experience" is going to get him into trouble... anyone that lacks talent (at whatever task) will have a tough time either understanding what a more experienced mentor is trying to get across, or they'll have a problem adopting a suggestion from a brilliant protege.
In some arenas, the technology already exists. Roomba vacuums are fully functional independent robots. You can get (for a price, and with limited capability) robot lawn mowers. Some subway systems use automated trains; they're fully functional and independent within the constraints of their designed task. Fully automated aircraft landing systems have been demonstrated, but they require infrastructure investment and some psychological buy-in by the travelling public. Autopilots (especially as implemented in cruise missiles) are essentially independent survival machines with a dedicated goal.
You can see that the main issue with robotic systems is to get them to have some consideration for human existence, if the mechanical system that they operate is large enough to injure or kill them. Remove that constraint, and it's a lot easier.
Klaatu! Borada! Nikto! AAAAAAAAAIIIGHGH
OOP needs to be taught at the start, not as an optional add-on.
If beginners shouldn't be dealing with pointers, then don't teach that part until they've grasped all the other aspects of writing procedural code.
Pointers don't point to memory... they point to things. If you're using pointers to randomly traverse your machine's guts then you deserve what you're getting. There are some things (such as linked lists) that are far easier to construct using pointers than by doing it by maintaining array indices (for example).
OOP is good for object-oriented tasks. The biggest problem that I see is that when people use C++ they suddenly feel the need to approach everything from an object-oriented perspective, and they begin by picking the wrong objects with the wrong attributes. To pick good object properties, you don't need to understand OOP, you need to understand the problem you're trying to solve and have a clear idea of how you're going to approach it. The key to OOP is design, not the language you're using to do it.
Sounds like Clerks... It was the best thing to hit the big screen in a long time, for a lot of reasons. With the advances in CG animation and home production software, there is no reason a small studio or group of individuals couldn't put together a movie that challenges the big guys on either the storyline or effects fronts - unless you assume that quantity will always outweigh quality.
without a backup. As mentioned by lots of other respondents, RF reception can be affected by any number of external factors, and you'd never know unless you continuously checked your phone's received signal strength indication. Does your phone alert you when it goes into "no service"? No? Better sue the phone maker for putting you at risk of being without a lifeline... or else read your service contract, and the phone's manual, carefully. If you need 100% communication reliability with someone, better stay within arm's reach. Nothing else is totally reliable.
GPS receivers (at 1575 MHz and 1227 MHz) are typically not affected by emissions from cellular equipment (which operates at 800, 900, 1800, and 1900 MHz for most of the European and North american systems) unless you happened to drop your phone directly on top of the GPS antenna.
It's 1.609344 kilometers per mile. If you're going to be pedantic, do it right.
Going just to geosynchronous orbit wouldn't hold up the cable. The center of mass of the cable and counterweight need to be past geosynchronous altitude. Going just to 62 miles wouldn't accomplish anything - there isn't enough atmospheric density there to allow a balloon to be used to provide the cable tensioning force, and orbital velocity at that altitude is something like 20,000 mph.
Oops. My Aa key is sticky ;)
There was an article in Analog (WAAAAY back when) on the math behind space elevator cables, and they indicated that unless a material such as carbon fibers (nanotubes and the like weren't even on the horizon then) were developed to commercial viability then the required strength to weight ratio would make the cable waaay too wide at its halfway point.
The best thing to do is have everyone agree on the code development method, not the specific language. You can always document your design using the same templates - a function is a function is a function, and you should always have an interface description doc as well as something that describes the code's behavior in more abstract terms than what the source provides.
Another great book is "Engineer to Win" by the late Carroll Smith. Even if you're not a racing car nut, this book presents a thorough overview of applied materials science and failure analysis, in some very plain language. Get it at any good speed shop.
The idea was (first of all) to try to prove or disprove what the hypothetical truckdriver was supposed to have done - which would not have entailed drilling a hole in the cement. After that failed, the point was to make the biggest bang possible. And they succeeded beyond all expectation - the sound even coming over the TV speakers was incredible. I agree that it would have been interesting to do any number of other experiments, but with explosives you only get one successful shot at it.
The article summary mentioned, among other things, the appliances getting price-of-power and system load information over a broadband Internet connection. So that's where my Internet reference came from. Having the devices use local frequency change information is possible only if they have access to a long-term-stable frequency reference, and even then their reaction time and their local environment would influence the stability of the control loop.
The function of the DC-DC converter is to take the 12V (+/- some tolerance) input, and turn it into regulated 1.8V, 3.3V, 5V, and -12 Volts (or whatever) at much higher current levels. Since it's 96% efficient at doing that, you'll only generate about 5 watts of heat even when you're pumping 115 watts into the CPU, hard drive, and motherboard. Finding or building a 115VAC to 12VDC power brick is pretty easy by comparison, and it's also subject to a lot of regulatory requirements that the DC to DC converter itself isn't. There is a lot of merit to separating out the two parts of the problem, especially since cars and RV's (for example) don't need the 115VAC to 12V step in the first place.
My only question would be, as others have already asked... is the 12V input tolerant of the automotive environment? SAE has a standard (J1211? Can't remember...) that specifies the typical extremes for voltage spikes due to boosting screwups, alternator load dump, and various motor load transients. If this module was designed to survive that stuff, then that would be great.
Two things that together determine the stability of a feedback control system are the loop gain and the loop phase delay. High gain and a long delay in the loop make for a very jittery system and one that's easily driven into oscillation. In the power control system described, adding more and more 'smart' devices would progressively increase the gain, while the delay would be somewhat unpredictable, since it would depend on the speed of an appliance's Internet connection and the speed at which the power utility updated its energy forecast. You can assume it's going to be random within some bounds, but the price of being wrong on that is very high...
"Deionized water is corrosive" is a commonly held misconception, but it's absolutely false. Distilled water (or de-ionized water, whatever you want to call it), is non-conductive. It doesn't "want to" or "try to" do anything... but it's a fact that lots of stuff is soluble in water to some extent, and once that happens the water's conductivity goes way up and then electrolytic action is possible.