I was hoping that developing a large game in Blender might motivate the Blender game engine people to rethink the design so that it scaled better. The Blender "circuit diagram" approach might work if it had higher-level abstractions, like components made from other components, or "objects". LabView, which is also a "wiring" oriented programming system, has something like that, and it scales moderately well.
It's too bad they're not using Blender's own game engine. Blender has an integrated 3D animation system and game engine.
The trouble with the Blender game engine is that it doesn't scale well.
The Blender game engine can be used "without programming", but what that really means is that you have to draw connection diagrams with hundreds or thousands of connections. Then you get to debug the wiring. For a non-trivial game, it's painfully difficult to debug.
It's an occasional fantasy of programmers that wiring visually functional blocks together is easier than programming. Engineers who wire up real hardware know better. That's why we have VHDL.
Fortunately, you can extend the Blender game engine in Python. Unfortunately, it's CPython, which is 60x slower than C. This isn't a hit you can afford in most games.
Historically, Microsoft has moved widely needed functions into their operating system and thereby eliminated the market for alternatives. When they did that for disk compression, Stacker went out of business. When they did it for TCP/IP networking, Trumpet Winsock disappeared. When they did it for email, Eudora stopped being a viable business. When they did it for browsers, Netscape Inc. went from a dot-com success to collapse.
Right now, they're doing it for anti-virus tools, which threatens McAfee, and desktop search, which threatens Google. They'll probably win on both of those, because there's little incentive to install a competitor's tools if those come bundled with the operating system, and because those tools can be tightly integrated with the operating system.
We went through this before, with Bonded Spammer, which wanted spam filters to let their stuff through. I dump Bonded Spammer email into a separate folder, and it's almost all spam. It looks like we'll have to set our filters to recognize this new stuff, and dump it into the "bulk" folder. So how do you check for these new guys?
We've had to face a similar problem as Avvo with SiteTruth, which rates web sites. The answer seems to have two parts - integrity and transparency. This means looking at information that comes from reliable sources other than the thing being rated, and showing the information from which the ranking is derived.
Avvo is trying to do this. Avvo's information comes partly from external sources, like legal directories and records of disciplinary actions. That's less game-able than traditional web search. And Avvo shows that information, so they have transparency.
Google is slowly coming around to this point of view. Originally, Google rankings were opaque, but now they've put in various "Webmaster Console" features to show some of the information that drives their algorithm.
Google faces the problem that some of their metrics for detecting junk web sites are heuristic, and rely on "security through obscurity". They don't want to say exactly how obscure text can be before it's considered "hidden text", or exactly what they consider a "link farm", or they'll be spammed right up to the allowed limit. So they can't have full transparency. They're inherently limited by the approach of primarily looking at the web site itself, which the site operator can change freely, to rate the site.
Google does look at some external non-Web information, but mostly things like how long a domain has been registered.
Avvo has user ratings of lawyers, which probably aren't that useful. User ratings are most valuable when the universe of raters is much larger than the number of things being rated. So it's good for major movies, where there are tens of new movies and millions of fans, marginal for hotels, and weak for businesses few people have heard of. There aren't enough clients per lawyer to get a statistically valid result, and it's too easy to game when the number of raters is small.
You can also read the court decision. (Look for "22. GATEWAY COMPANIES v. SHEEHAN PC-20070134"):
"The court finds that based on the evidence submitted, the respondent has met his burden to prove there was no agreement to arbitrate the subject dispute. The petition (to compel arbitration) is denied."
So the case will be decided in small claims court.
Read the actual article. (The Slashdot poster didn't get it.) The issue is that the customer did not agree to the EULA because the computer was too broken to display it. Thus, the customer has not waived the right to sue.
The last thing we need is a phone that takes both hands to operate.
In California, using a non-hands-free phone while driving becomes a moving violation in mid-2008. Washington State is doing this too. (That was enacted right after a 5-car collision caused by a Blackberry user.) I've had my truck rear-ended twice by people on cell phones. One said to the cop, afterwards, "I was just finishing my call". Had a near miss two weeks ago; someone pulling out of a parking space on a busy street was using a phone, so they couldn't turn the wheel fast enough and drove across two lanes of traffic before straightening out.
Remember the iDrive, from BMW? That was a disaster, hated by many owners. Too much "head down" time, looking at the display instead of the road.
The idea here is that they're looking for sites that have a privacy policy expressed in XML, something that's been working since 2002 but never really caught on.
Even the few sites that use that have problems. Check out Bankrate.com. According to PrivacyFinder, their policy, from the XML, can be summarized as "BankRate.com may share your information with: Companies that help this site fulfill your requests (for example, shipping a product to you), but these companies must not use your information for any other purpose". Sounds good, and Privacy Finder gives them a high rating.
But their privacy text associated with the XML says "Bankrate uses your personally identifiable information to customize the advertising and content you see on our Web pages, to fulfill your requests for certain products and services and if you permit us, to contact you about special offers and new products. Unless you are entering one of our sweepstakes, Bankrate does not currently share, loan, rent or sell your personally identifiable information."
Their privacy policy text page lets them do even more: " Bankrate uses your personally identifiable information as follows:... to contact you and deliver information to you that, in some cases, is targeted to your interests, such as targeted banner advertisements, administrative notices, product offerings, and communications relevant to your use of www.bankrate.com." The text policy is far less restrictive than the one associated with the XML.
The interesting research results have to do with control strategies for providing good ride quality. Biped walking machines have been around for some years now, but usually jounce around too much. They've addressed that problem. One more step towards robust biped machines.
Now the question is whether they can get the stride length up. That's when it starts to get hard. The linear approximations they're using start to diverge from reality too much.
The latest generation of hobbyist robots from Japan are almost good enough for serious research work. They need inertial units, more compute power, and better comm links, but the mechanics look quite good. Hobbyist robotics is about at the Apple I point - there's decent hardware advanced hobbyists can buy, but it's not quite ready for prime time. The academics tend to have good theory but expensive, one-off hardware, while the hobbyists have mass produced hardware but primitive software. It's like computing in 1976. Two more years and this stuff will really start to work.
There's a lot of academic theory that needs to be moved into the hobbyist robots, which tend to have really dumb controllers, and not due to lack of compute power. The hobby robotics people are going to have to learn more math, much as game developers did when games went from 2D to 3D.
We know how to do serious security. Programs have to be divided into big parts that are untrusted, and small parts that are trusted. Only the latter get much in the way of privileges. The key concept is that only a small fraction of the code is trusted, and you make that code simple, paranoid, and well reviewed.
That's the application model for which SELinux is designed. This was all figured out in the early 1980s and used in a few systems in the DoD community, but the commercial community wasn't worried about security back then. Which is how we got into the mess we have now.
Complicating the problem is that these separate parts have to intercommunicate, and interprocess communication on Linux/Unix still isn't very good after thirty years. Pipes and FIFOs are too limited, and shared memory breaks security boundaries. System V IPC is the best mechanism for communication across a security boundary, and it's well supported in SELinux, but almost nobody uses it.
First off, it's a Roland the Plogger story, so you know it's clueless. Roland the Plogger is just regurgitating a press release.
Here's an actual paper about the thing. Even that's kind of vague. The general idea, though, seems to be to insert a layer of code-patching middleware between the application and the hardware. The middleware has access to CPU instrumentation info about cache misses, power management activity, and CPU temperature. When it detects that the program is doing things that are causing problems at the CPU level, it tries to tweak the code to make it not do so much bad stuff. See Power Virus in Wikipedia for an explaination of "bad stuff". The paper reports results on a simulated CPU with a simulated test program, not real programs on real hardware.
Some CPUs now power down sections of the CPU, like the floating point unit, when they haven't been used for a while. A program which uses the FPU periodically, but with intervals longer than the power-off timer, is apparently troublesome, because the thing keeps cycling on and off, causing voltage regulation problems. This technique patches the code to make that stop happening. That's what they've actually done so far.
Intel's interest seems to be because this was a problem with some Centrino parts.
So this is something of a specialized fix. It's a software workaround for some problems with power management.
It's probably too much software machinery for that problem. On-the-fly patching of code is an iffy proposition. Some code doesn't work well when patched - game code being checked for cheats, DRM code, code being used by multiple CPUs, code being debugged, and Microsoft Vista with its "tilt bits". Making everything compatible with an on the fly patcher would take some work.
A profiling tool to detect program sections that have this problem might be more useful.
It's a reasonable piece of work on an annoying problem in chip design.
The real technical paper is titled "Eliminating voltage emergencies
via microarchitectural voltage control feedback and dynamic
optimization." (International Symposium on Low-Power Electronics
and Design, August 2004). If you're really into this, see this paper on detecting the problem during chip design, from the India Institute of Technology in Madras. Intel also funded that work.
On the thermal front, back in 2000, at the Intel Developer Forum the keynote speaker after Intel's CEO spoke, discussing whether CPUs should be designed for the thermal worst case or for something between the worst case and the average case: "Now, when you design a system, what you typically want to do is make sure the thermal of the system are okay, so even at the most power-hungry application, you will contain -- so the heat of the system will be okay. So this is called thermal design power, the maximum, which is all the way to your right. A lot of people, most people design to that because something like a power virus will cause the system to operate at very, very maximum power. It doesn't do any work, but that's -- you know, occasionally, you could run into that.
The other one is, probably a little more reasonable, is you don't have the power virus, but what the most -- the most power consuming application would run, and that's what you put the TDP typical."
From that talk, you can kind of see how Intel got into this hole. They knew it was a problem, though, so they put in temperature detection to slow down the CPU when it gets too hot. This prevents damage,
When I first saw the title, I thought this was about reputations for web sites or online businesses, but no, it's about reputations for, well, bloggers. Where it doesn't really matter all that much. It matters for eBay, but most of the sellers on eBay are businesses. It's been a long time since eBay was individual to individual.
Dating sites have struggled with this. True wants to see an image of your driver's license. With the controversy over Myspace, we may see them going that way, at least for parents.
Wikipedia doesn't care much about identity, except as regards vandal blocking. Even admins and ArbComm members are anonymous. All Wikipedia needs is some way to slow down unlimited generation of new identities.
I once suggested that one way to do that would be to require some easily available, no-cost, unique, verifiable physical token to register. Like an AOL disk.
One approach to identity verification, which I'd like to see used for domain registration, is simply mailing out a card by postal mail. When you register a domain, a letter should be sent to the address listed for the domain. When you get the letter, you type in the password printed in the letter postcard, and the domain registration completes. That would really improve WHOIS data quality and cut down on scams. The cost of sending out customized mailing pieces is under about US$0.50 each when you have a bulk mailing house do it, so it's quite feasible at current domain prices.
I have long been of the understanding that an original, by-ear transcription of a song, which is a duplicate of no copyrighted work and which generally deviates substantially from the work on which it is based is the property of its transcriber, and not the original composer of the song.
Where did he get that weird idea? If that were the case, composers would never get paid anything.
Remember, this isn't about a copyright of the performance, which is what the RIAA is about. It's about a copyright of the original composition, the composer's and songwriter's copyright.
Yes. Try to find information on the web about the language "C+@". It's real, and it was developed at Bell Labs some years ago back in the Plan 9 era, but it's unsearchable.
"High definition microphone". Right. For low bit rate voice over IP?
There are interesting things to do in the microphone space for VoIP, like using multiple microphones for noise cancellation and beam steering, but this is just hype.
This is a flood-damaged property, in New Orleans, right? So you need:
Reinforced flood walls or a berm all the way around the property.
Trash pumps that can pump muddy water out.
Redundant generators and fuel tanks for the pumps and other systems.
Plenty of emergency food and water storage.
Emergency water filtration system.
Emergency toilet system.
Steel and reinforced concrete construction.
Window shutters.
Fire sprinkler system with backup water tanks.
Ham radio system for emergency communications.
Satellite link for backup data comm.
Then you're ready to start thinking about control gear for all this, so that if a big storm comes when you're not there, shutters close, pumps start if needed, power is cut in wet areas to prevent shorts, gas valves close, water lines are isolated to prevent contamination...
We, and everybody else in the DARPA Grand Challenge, had big red EMERGENCY STOP buttons all over the vehicle. Everybody with robots of non-trivial size uses those things.
According to Wikipedia, burning coal will yield around 1.5% of its mass in gallium.
That may be bogus information. It comes from Wikipedia, which got it from LANL's periodic table.
But sources that talk about commercial recovery of gallium from fly ash have far lower numbers.
See U.S. Patent #4,686,031, "Beneficiation of gallium in fly ash", which talks about starting from concentrations in the 100ppm (0.01%) range. The state of West Virginia says that the mean concentration of gallium in West Virginia coals is 6.45 ppm. Fly ash is more concentrated than coal, of course, because burning removes the carbon but leaves the non burnable minerals.
If fly ash, which is cheap, contained 1.5% gallium, nobody would be bothering with extracting it from bauxite.
It's another gallium-based technology. That's going to limit it. There's just not that much gallium available. 30%+ efficient cells using gallium have been around for a few years, but other than on spacecraft, and the Stanford Solar Car, they're too expensive to be useful. They talk about "concentrator cells", but that means mirrors and trackers, running up the system cost.
Citation: King, R. R., Law, D. C., Edmondson, K. M., Fetzer, C. M., Kinsey, G. S., Yoon, H., Sherif, R. A., and Karam, N. H. "40% efficient metamorphic GaInP/GaInAs/Ge multijunction solar cells." Applied Physics Letters 90, 183516 (2007).
Slashdot Mirror
This is proof that communist power > capitalist power.
As Lenin put it, "The West will sell us the rope to hang them with."
Blatant advertising. There's even a click-to-order link.
I was hoping that developing a large game in Blender might motivate the Blender game engine people to rethink the design so that it scaled better. The Blender "circuit diagram" approach might work if it had higher-level abstractions, like components made from other components, or "objects". LabView, which is also a "wiring" oriented programming system, has something like that, and it scales moderately well.
It's too bad they're not using Blender's own game engine. Blender has an integrated 3D animation system and game engine.
The trouble with the Blender game engine is that it doesn't scale well. The Blender game engine can be used "without programming", but what that really means is that you have to draw connection diagrams with hundreds or thousands of connections. Then you get to debug the wiring. For a non-trivial game, it's painfully difficult to debug.
It's an occasional fantasy of programmers that wiring visually functional blocks together is easier than programming. Engineers who wire up real hardware know better. That's why we have VHDL.
Fortunately, you can extend the Blender game engine in Python. Unfortunately, it's CPython, which is 60x slower than C. This isn't a hit you can afford in most games.
Historically, Microsoft has moved widely needed functions into their operating system and thereby eliminated the market for alternatives. When they did that for disk compression, Stacker went out of business. When they did it for TCP/IP networking, Trumpet Winsock disappeared. When they did it for email, Eudora stopped being a viable business. When they did it for browsers, Netscape Inc. went from a dot-com success to collapse.
Right now, they're doing it for anti-virus tools, which threatens McAfee, and desktop search, which threatens Google. They'll probably win on both of those, because there's little incentive to install a competitor's tools if those come bundled with the operating system, and because those tools can be tightly integrated with the operating system.
We went through this before, with Bonded Spammer, which wanted spam filters to let their stuff through. I dump Bonded Spammer email into a separate folder, and it's almost all spam. It looks like we'll have to set our filters to recognize this new stuff, and dump it into the "bulk" folder. So how do you check for these new guys?
We've had to face a similar problem as Avvo with SiteTruth, which rates web sites. The answer seems to have two parts - integrity and transparency. This means looking at information that comes from reliable sources other than the thing being rated, and showing the information from which the ranking is derived.
Avvo is trying to do this. Avvo's information comes partly from external sources, like legal directories and records of disciplinary actions. That's less game-able than traditional web search. And Avvo shows that information, so they have transparency.
Google is slowly coming around to this point of view. Originally, Google rankings were opaque, but now they've put in various "Webmaster Console" features to show some of the information that drives their algorithm.
Google faces the problem that some of their metrics for detecting junk web sites are heuristic, and rely on "security through obscurity". They don't want to say exactly how obscure text can be before it's considered "hidden text", or exactly what they consider a "link farm", or they'll be spammed right up to the allowed limit. So they can't have full transparency. They're inherently limited by the approach of primarily looking at the web site itself, which the site operator can change freely, to rate the site.
Google does look at some external non-Web information, but mostly things like how long a domain has been registered.
Avvo has user ratings of lawyers, which probably aren't that useful. User ratings are most valuable when the universe of raters is much larger than the number of things being rated. So it's good for major movies, where there are tens of new movies and millions of fans, marginal for hotels, and weak for businesses few people have heard of. There aren't enough clients per lawyer to get a statistically valid result, and it's too easy to game when the number of raters is small.
The link to the article on Internet openness leads to a page where you have to agree to an EULA to read the article. Openness. Right.
There are already bacteria living in active zones of nuclear reactors. ... ECC in their DNA in addition to RAID1 that we currently have.
Those bacteria have quadruple-strand DNA. and an extra error-correction loop.
You can also read the court decision. (Look for "22. GATEWAY COMPANIES v. SHEEHAN PC-20070134"):
"The court finds that based on the evidence submitted, the respondent has met his burden to prove there was no agreement to arbitrate the subject dispute. The petition (to compel arbitration) is denied."
So the case will be decided in small claims court.
Read the actual article. (The Slashdot poster didn't get it.) The issue is that the customer did not agree to the EULA because the computer was too broken to display it. Thus, the customer has not waived the right to sue.
The last thing we need is a phone that takes both hands to operate.
In California, using a non-hands-free phone while driving becomes a moving violation in mid-2008. Washington State is doing this too. (That was enacted right after a 5-car collision caused by a Blackberry user.) I've had my truck rear-ended twice by people on cell phones. One said to the cop, afterwards, "I was just finishing my call". Had a near miss two weeks ago; someone pulling out of a parking space on a busy street was using a phone, so they couldn't turn the wheel fast enough and drove across two lanes of traffic before straightening out.
Remember the iDrive, from BMW? That was a disaster, hated by many owners. Too much "head down" time, looking at the display instead of the road.
The future is hands-free, not two-handed.
The idea here is that they're looking for sites that have a privacy policy expressed in XML, something that's been working since 2002 but never really caught on.
Even the few sites that use that have problems. Check out Bankrate.com. According to PrivacyFinder, their policy, from the XML, can be summarized as "BankRate.com may share your information with: Companies that help this site fulfill your requests (for example, shipping a product to you), but these companies must not use your information for any other purpose". Sounds good, and Privacy Finder gives them a high rating.
But their privacy text associated with the XML says "Bankrate uses your personally identifiable information to customize the advertising and content you see on our Web pages, to fulfill your requests for certain products and services and if you permit us, to contact you about special offers and new products. Unless you are entering one of our sweepstakes, Bankrate does not currently share, loan, rent or sell your personally identifiable information."
Their privacy policy text page lets them do even more: " Bankrate uses your personally identifiable information as follows: ... to contact you and deliver information to you that, in some cases, is targeted to your interests, such as targeted banner advertisements, administrative notices, product offerings, and communications relevant to your use of www.bankrate.com." The text policy is far less restrictive than the one associated with the XML.
Similarly, check out Wachovia Financial Services. The XML says they don't share your personal information, but their text privacy page says they can share, say, your loan information with their brokerage, insurance, and credit card units for marketing purposes.
This isn't looking good. And those are major legitimate companies. Further down the food chain, it looks much worse.
Cute.
The interesting research results have to do with control strategies for providing good ride quality. Biped walking machines have been around for some years now, but usually jounce around too much. They've addressed that problem. One more step towards robust biped machines.
Now the question is whether they can get the stride length up. That's when it starts to get hard. The linear approximations they're using start to diverge from reality too much.
The latest generation of hobbyist robots from Japan are almost good enough for serious research work. They need inertial units, more compute power, and better comm links, but the mechanics look quite good. Hobbyist robotics is about at the Apple I point - there's decent hardware advanced hobbyists can buy, but it's not quite ready for prime time. The academics tend to have good theory but expensive, one-off hardware, while the hobbyists have mass produced hardware but primitive software. It's like computing in 1976. Two more years and this stuff will really start to work.
There's a lot of academic theory that needs to be moved into the hobbyist robots, which tend to have really dumb controllers, and not due to lack of compute power. The hobby robotics people are going to have to learn more math, much as game developers did when games went from 2D to 3D.
We know how to do serious security. Programs have to be divided into big parts that are untrusted, and small parts that are trusted. Only the latter get much in the way of privileges. The key concept is that only a small fraction of the code is trusted, and you make that code simple, paranoid, and well reviewed.
That's the application model for which SELinux is designed. This was all figured out in the early 1980s and used in a few systems in the DoD community, but the commercial community wasn't worried about security back then. Which is how we got into the mess we have now.
Complicating the problem is that these separate parts have to intercommunicate, and interprocess communication on Linux/Unix still isn't very good after thirty years. Pipes and FIFOs are too limited, and shared memory breaks security boundaries. System V IPC is the best mechanism for communication across a security boundary, and it's well supported in SELinux, but almost nobody uses it.
First off, it's a Roland the Plogger story, so you know it's clueless. Roland the Plogger is just regurgitating a press release.
Here's an actual paper about the thing. Even that's kind of vague. The general idea, though, seems to be to insert a layer of code-patching middleware between the application and the hardware. The middleware has access to CPU instrumentation info about cache misses, power management activity, and CPU temperature. When it detects that the program is doing things that are causing problems at the CPU level, it tries to tweak the code to make it not do so much bad stuff. See Power Virus in Wikipedia for an explaination of "bad stuff". The paper reports results on a simulated CPU with a simulated test program, not real programs on real hardware.
Some CPUs now power down sections of the CPU, like the floating point unit, when they haven't been used for a while. A program which uses the FPU periodically, but with intervals longer than the power-off timer, is apparently troublesome, because the thing keeps cycling on and off, causing voltage regulation problems. This technique patches the code to make that stop happening. That's what they've actually done so far.
Intel's interest seems to be because this was a problem with some Centrino parts. So this is something of a specialized fix. It's a software workaround for some problems with power management.
It's probably too much software machinery for that problem. On-the-fly patching of code is an iffy proposition. Some code doesn't work well when patched - game code being checked for cheats, DRM code, code being used by multiple CPUs, code being debugged, and Microsoft Vista with its "tilt bits". Making everything compatible with an on the fly patcher would take some work. A profiling tool to detect program sections that have this problem might be more useful.
It's a reasonable piece of work on an annoying problem in chip design. The real technical paper is titled "Eliminating voltage emergencies via microarchitectural voltage control feedback and dynamic optimization." (International Symposium on Low-Power Electronics and Design, August 2004). If you're really into this, see this paper on detecting the problem during chip design, from the India Institute of Technology in Madras. Intel also funded that work.
On the thermal front, back in 2000, at the Intel Developer Forum the keynote speaker after Intel's CEO spoke, discussing whether CPUs should be designed for the thermal worst case or for something between the worst case and the average case: "Now, when you design a system, what you typically want to do is make sure the thermal of the system are okay, so even at the most power-hungry application, you will contain -- so the heat of the system will be okay. So this is called thermal design power, the maximum, which is all the way to your right. A lot of people, most people design to that because something like a power virus will cause the system to operate at very, very maximum power. It doesn't do any work, but that's -- you know, occasionally, you could run into that. The other one is, probably a little more reasonable, is you don't have the power virus, but what the most -- the most power consuming application would run, and that's what you put the TDP typical."
From that talk, you can kind of see how Intel got into this hole. They knew it was a problem, though, so they put in temperature detection to slow down the CPU when it gets too hot. This prevents damage,
When I first saw the title, I thought this was about reputations for web sites or online businesses, but no, it's about reputations for, well, bloggers. Where it doesn't really matter all that much. It matters for eBay, but most of the sellers on eBay are businesses. It's been a long time since eBay was individual to individual.
Dating sites have struggled with this. True wants to see an image of your driver's license. With the controversy over Myspace, we may see them going that way, at least for parents.
Wikipedia doesn't care much about identity, except as regards vandal blocking. Even admins and ArbComm members are anonymous. All Wikipedia needs is some way to slow down unlimited generation of new identities. I once suggested that one way to do that would be to require some easily available, no-cost, unique, verifiable physical token to register. Like an AOL disk.
One approach to identity verification, which I'd like to see used for domain registration, is simply mailing out a card by postal mail. When you register a domain, a letter should be sent to the address listed for the domain. When you get the letter, you type in the password printed in the letter postcard, and the domain registration completes. That would really improve WHOIS data quality and cut down on scams. The cost of sending out customized mailing pieces is under about US$0.50 each when you have a bulk mailing house do it, so it's quite feasible at current domain prices.
I have long been of the understanding that an original, by-ear transcription of a song, which is a duplicate of no copyrighted work and which generally deviates substantially from the work on which it is based is the property of its transcriber, and not the original composer of the song.
Where did he get that weird idea? If that were the case, composers would never get paid anything.
Remember, this isn't about a copyright of the performance, which is what the RIAA is about. It's about a copyright of the original composition, the composer's and songwriter's copyright.
So how does Google know to tailor its results for C, C++, and C#, which all return results specific to the requested language, but not for C+@?
Manually implemented special cases, perhaps. Or Google may not consider the possibility that "@" can be part of a word, which is likely.
Yes. Try to find information on the web about the language "C+@". It's real, and it was developed at Bell Labs some years ago back in the Plan 9 era, but it's unsearchable.
"High definition microphone". Right. For low bit rate voice over IP?
There are interesting things to do in the microphone space for VoIP, like using multiple microphones for noise cancellation and beam steering, but this is just hype.
Then you're ready to start thinking about control gear for all this, so that if a big storm comes when you're not there, shutters close, pumps start if needed, power is cut in wet areas to prevent shorts, gas valves close, water lines are isolated to prevent contamination...
We, and everybody else in the DARPA Grand Challenge, had big red EMERGENCY STOP buttons all over the vehicle. Everybody with robots of non-trivial size uses those things.
According to Wikipedia, burning coal will yield around 1.5% of its mass in gallium.
That may be bogus information. It comes from Wikipedia, which got it from LANL's periodic table.
But sources that talk about commercial recovery of gallium from fly ash have far lower numbers. See U.S. Patent #4,686,031, "Beneficiation of gallium in fly ash", which talks about starting from concentrations in the 100ppm (0.01%) range. The state of West Virginia says that the mean concentration of gallium in West Virginia coals is 6.45 ppm. Fly ash is more concentrated than coal, of course, because burning removes the carbon but leaves the non burnable minerals.
If fly ash, which is cheap, contained 1.5% gallium, nobody would be bothering with extracting it from bauxite.
It's another gallium-based technology. That's going to limit it. There's just not that much gallium available. 30%+ efficient cells using gallium have been around for a few years, but other than on spacecraft, and the Stanford Solar Car, they're too expensive to be useful. They talk about "concentrator cells", but that means mirrors and trackers, running up the system cost.
Citation: King, R. R., Law, D. C., Edmondson, K. M., Fetzer, C. M., Kinsey, G. S., Yoon, H., Sherif, R. A., and Karam, N. H. "40% efficient metamorphic GaInP/GaInAs/Ge multijunction solar cells." Applied Physics Letters 90, 183516 (2007).