Okay, this will happen if you deliberately allow it. Every "boiler" (the name is not true, because the water shouldn't boil) has a pressure relief valve. If that it stuck close, it will already crack when heating the water, way before boiling, so no further pressure can build up. To get a steam explosion, you need a very strong vessel and you must boil the water despite the pressure building up (which is a far cry from the 55C you usually aim for).
That thing rupturing would really be no nice thing to have around. Actually, those nasty steam explosions were quite common in the days of the steam engine. In those days steel wasn't as strong as it is today, and they really wanted superheated steam, not just warm water.
You can't heat water up quickly enough with conventional resistance-based electric elements, as it would require huge amount of electricity.
Christ people, what do you think the microwave thingayamajig will use to heat the water? Will it take Free Energy from the Tachyon Field Of The Earth or something? What do you/. editors use for a brain, huh?
A resistive electric heater converts the whole electric energy it takes in into heat. No losses at all! You cannot put out the same amount of heat using less electricity, no matter what Rube Goldberg device you concoct to do it.
The disadvantage is that if this tank, which is under pressure, ever blows up, it takes the house with it.
Water tanks cannot blow up unless they contain an air bubble. They can only leak. This is because water is incompressible and so won't store energy when being pressurized.
Re:What about diode lasers?
on
First Silicon Laser
·
· Score: 2, Informative
Diode lasers use silicon, or at least compounds of silicon.
They don't, unless you are willing to call the laser diode in your CD player a "plastic laser" because it's mounting in a plastic casing. The semiconductor in light emitting diodes is usually GaAs and never silicon, mainly because silicon diodes just won't emit light (no even infrared).
Oh come on, it wasn't me who brought up the supposedly heavyweight C++ runtime. The whole point is, printf is braindead, iostreams are sane.
You'll catch it doing braindead stuff like inserting data into the stream one byte at a time.
No, you don't. You catch it putting single bytes into a buffer (yes, I did look at the code). And these calls can be inlined (while printf("%c",...) cannot). Any more strawmen you want to put up?
You don't do it by coding the way they tell you to in CS school
I wish that was true. They don't tell you about coding in CS school at all, which is a shame. Sometimes they throw buzzwords at you and call that coding, which is even worse. So yes, due to lack of any serious programming being taught, writing robust/working/efficient, basically just good software takes a background in CS and then lots of experience.
C...C++...Java
Was that supposed to be an exhaustive list of all programming languages? I certainly hope not. Imnsho, Java belongs more to the problem set than the solution set, C++ is kind of always the second best tool, but rever really suited, and C is good for simple logic that has to be very efficient or close to the metal. More complex logic quickly gets messy in C, and in C++ as well.
I was actually thinking of Lisp, Scheme, Erlang, Lua and some others. Erlang shines in realtime embedded applications (an ATM switch does count, doesn't it?), the others are available as tiny and powerful interpreters that work well with some pieces done in C.
If you have a function and you pass it an object, it it going to call the constructor once?
It calls the copy constructor exactly once. If you pass a constant reference instead, nothing is called. But of course, if you *do* pass by value, you know what you're doing.
Unless of course you're a dimwitted Java programmer retrofitted to crank C++ because the JVM was larger than the available RAM and you thought, you could code anything that had curly braces.
(Returning an object by value calls the copy constructor at most once. If that turns out to be a problem, you return an std::auto_ptr or something similar, or you do black magic with template meta programs like in Blitz++.)
templates are generally a lose for embedded. The reason is that generating n versions of the template classes/functions ends up costing way too much in ROM (which is generally tighter than even RAM). Instead you write a single version that uses void* pointers and a size field in the node, saving Ks of ram.
No, you don't (even if the proponents of Java generics don't seem to ever get tired of lambasting the evil code bloat in C++ from use of templates). You write the goddamn template, give it a specialization for (void*), then partially specialize it for (T*) and implement that in terms of (void*). You get all the fun at no extra cost, you just have to know what you're doing.
Even more important is the use of templates in the STL: yes, you generate n versions of std::list for all sorts of usually small objects. That amounts to exactly no code, because all functions defined on it are so tiny, they get inlined. After inlining, everything is ordinary static structures with constant offsets. The (void*) could never match that performance, neither in memory consumption nor in execution time....qsort...
Well, most STL implementation actually use shell sort. But that's beside the point, because STL works well with user supplied algorithms. By comparison, any generic sort in C is dog slow, because it has to call out to the predicate through a function pointer. The template version in C++ can inline the predicate.
when storage is minimal the CRT wins everytime over the C++ runtime
No, it doesn't. C++ doesn't need much runtime, basically just memory management (same as in C) and some support for exception handling (optional, but worth it, imho). The rest is the standard library, and there you only pay for what you use, as in C.
If you compare specific parts of the two libraries, C++ wins. Most striking example: C printf (ever written a program without it?) need to include all the formatting code for dealing with integers, floats, string, formatting flags, locales. How could it leave something out, for the compiler cannot see that you never use %f. C++ iostreams only need the formatting code that is actually called. You will often get rid of the floating point output, because you never output floats. You may have a single, trivial locale in your program, so you get rid of that code, too. Also, stream operations can be inlined, printf cannot.
However, commercial C++ runtimes are often implemented as a layer on top of the C runtime. This adds to the size, of course.
One problem is that it's often desirable for embedded applications to behave predictably.
Strange. This could be construed to mean that it doesn't matter whether or not a full blown desktop or server application behaves predictably. Since nobody seems to think this is wrong, something is seriously broken in this industry.
Another problem is that embedded systems need to be very reliable over long periods of time with no user intervention.
This is next to impossible in C, the reality of the software industry proves this day in and day out. Dynamic allocation or not, a reliable system in C takes competent programmers (at least two, one has to keep an eye on the blind spot of the other), lots of time and many iterations until the bugs are ironed out. We see this on the desktop and server, too: software simply is unreliable, and if the bugs aren't introduced by faulty memory management, there are still buffer overflows and the like.
So I'd say it doesn't matter whether you use malloc. If reliability is that important, don't use C.
So I don't see why Sony is violating the LGPL here. As you can download the LGPLed library from sourceforge, its freely accesssible, no?
1) They don't attach a copy of the LGPL and they erased the copyright notice on the libraries in question. This is unconditionally a violation of copyright law.
2) Lame ist not attached verbatim, but in parts. That constitutes a "work based on the library", therfore has to be licensed under the LGPL or GPL, and machine readable source code or a written offer to provide it has to be included, neither of which has been done. This is a violation of the LGPL.
3) Two libraries have been statically linked into an OCX. While the OCX could be considered a shared library, the OCX itself must be LGPL'd, and source must be included and so on. Again, this is a violation of the LGPL.
4) Whether source code is freely available somewhere, is of no importance. You are allowed to link with a verbatim copy of the library (has not been done here) without providing source. In all other cases you are required to provide the source code at least on request. Pointing to someone who already does this, doesn't count.
the FOSS community in paticular has dropped the ball on XQuery applications.
And rightly so, because it's crap. Since XML has no regular structure, any XQuery involves a linear scan. Unless some sound theory behind XQuery is discovered and a way to index XML documents, XQuery is useless.
Berkeley DB XML claims to index XML documents. I tested it on a large document. A trivial query took a GB of memory without returning anything but an error. What's the point of this "technology"? It should have been given up on back in 1996.
Whenever you are optimizing, the first thing to do is to use a smarter algorithm or an advanced data structure. No amount of bit twiddling will gain as much as an improvement from say O(n^2) to O(n log n) does. Coding an advanced algorithm on top of low level "performance tuned" code is next to impossible. Therefore, write high level, portable code. After tuning, it is still high level, still portable, and it also performs.
If performance still is not adequate (don't guess, ask the profiler), isolate the ugly bits behind a clean interface, then code machine specific implementations if there's something to be gained.
However, this statement alone
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
tells me that you're far from "seeing it". If you're counting bits, your code will be slow despite being non-portable.
I believe you should shut up, stop relying on hearsay and read the license. Section 4 most clearly states:
You may copy and distribute the Library [...] in object code or executable form [...] provided that you accompany it with the complete corresponding machine-readable source code
A while ago I heard of a German prototype for a practical electric car. You're right, there's no complex ICE, no transmission, but simple electric motors. You can even get all wheel drive and traction control basically for free. Motors can work as generators, so brakes can be simpler.
The big problem is energy storage. Capacitors have low energy density, but can be charged and decharged in fractions of a second. NiMH batteries have better power density and survive many charge cycles at reasonably high amperages. But as primary storage they are still bulky and heavy.
The aforementioned prototype used a supercap, a NiMH battery and a zinc-air battery. The supercap is short term storage for regenerative braking and quickstarts, the NiMH battery smoothes out varying demand and gives power when quickly accelerating, and the zinc-air battery is the primary storage, which is only capable of giving a moderate and constant power output, but has reasonable energy density. Switching regulators shuffle electricity back and forth as needed.
Now you should see the problems: Four switchers with high power ratings, three batteries, all completely different, and the main battery is experimental technology. This is a complex system, it is still in its infancy and there was not enough economic incentive to develop this further. No need to resort to conspiracy theories for an explanation.
Besides all that, the electricity, which is stored with losses, has to come from somewhere. Obviously, there's no advantage to burning oil in power plants instead of ICEs, and there's little advantage if the oil is replaced by coal. The electricity has to come from somewhere else, which is still not the case, and so battery powered vehicles are not interesting yet.
A license to sell software would probably be enough. Moreover, holding someone responsible for damage caused by software would do the trick. This would normally be the vendor, but if no vendor was paid, it might be an administrator.
A license to own a compiler would be a bad thing. We all know that Microsoft, Oracle, SAP would immediately buy... err... apply for licenses, and we also know how competent their coders are.
Nonono, that's not what I said. If you give someone your software, you also give him permission to use it. What else would be the point? Give someone software to fill his harddrive so his other useless software doesn't feel lonely? Even your stupid American lawmakers who gave you the DMCA can see that.
If you want to control who uses your software, simply keep it. Don't provide a download, don't sell it. Oh, ans Microsoft can cry as much as they want, their EULA which forbids you to write office application with your bought copy of their devstudio, is simply void. They sold it, you can use it for whatever you like.
I predict, you will again refuse to read the GPL, and I predict that you will predict something even more retarded, too. Your turn.
Well, you get an implicit license to use when you buy software or legally download it. If simple use is enough, you don't need anything explicit. BTW, now would be a good time to actually read the GPL (any version you like).
This is almost correct. Plant life makes a great carbon sink, if and only if it is provided with sunlight and is prevented from decaying and is instead buried.
Plants on land are no carbon sink, because they decay completely within a few years. Not even tropic forests bind carbon, the whole biomass is recycled within a year.
Plants in the deep sea are no carbon sink, because there is no light, and therefore actually no plants. In a depth of 800m it is simply pitch black, and the only energy source for plant-like life there are hot sulphuric springs. They don't provide much useful energy.
The only significant carbon sink working right now is phytoplankton in shallow oceans. Most of it is still eaten by fish, not much sinks to the ocean floor and stays there.
While ideas in principle are a good thing, this one is still stupid. The CO2 doesn't go away, it will come back to the surface sooner or later. Separating and liquefying CO2 costs energy, which comes from burning yet more coal, which produces yet more CO2 which has to be put away. Estimates go around 50% more emissions for this stupid plan.
Add to that that this scheme is only feasible for large power plants, and one wonders how blind one has to be to promote such a stupid plan while dismissing clean nuclear power out of hand. Nuclear wastes at least decay and don't pop out in huge bubbles that swallow ships and asphyxiate whole cities. And as an aside, if both concentrated CO2 and plenty of heat (nuclear or possibly solar) were available, one could produce synthetic fuel (by creating H2 through the sulfur-iodine-process followed by Fischer-Tropsch-Synthesis). But no, we have to bury the CO2./me shakes head.
No, it's not. You do not need an explicit license just to use software. Software is made to be used, therefore you can expect that you are allowed to use software you bought or were allowed to download, therefore you are allowed to use it. Although software vendors keep telling you that you aren't buying software, merely licensing it for use, it still looks like an ordinary sale. If it looks like a sale, it is a sale, therefore you bought it, therefore you can use it.
Full stop. Read that again: Yo do not need a license to use legally acquired software. Now read the GPL-2, check what they tell you about whether you need to accept it to use the software. See? And the GPL-3 cannot change one iota about that, because it's the law. You only need to accept an explicit license to distribute software.
Now please try reading up more and predicting less on this subject.
APIs cannot be copyrighted. You don't need a license to call a published API. Using an API does not (usually) make your program a derived work, and that is decided by copyright law, not by the FSF.
You do need a license to #include copyrighted headers or compile copyrighted.idl files or whatever. Even that could be considered mere use (for which you never need an explicit license!), which probably depends on the exact nature of the program/library in question and the mood of the judge.
BTW, I quite like the idea of the new GPL, and the FSF should do everything they can to make it have the most impact. And you should get a clue, nuthead.
I predict it will be draconian, specifying that people who merely interoperate with GPL3 SW will have to publish source code.
This isn't even legally possible. Sure, Moglen could write such crap into the license, but it wouldn't stand up in court anymore than SCO's "All your Unix are belong to us" claim.
Whatever the FSF decides, some people will not like it and use another license. This is a Good Thing (though there are already enough almost identical Open Source Certified licences).
If on the other hand the GPL-3 is constructed by popular vote, it will be subtly broken, and it will include so many compromises that nobody will like it and so everybody will use a different license.
Yes, but that choice is left up to the viewer if you specify "or later".
This really boils down to whether you trust the FSF to Do The Right Thing. If you think so, you put the "or later" clause in and allow your program to be "upgraded" to a recent version of the GPL, thereby retaining licensing compatibility with newer software. If you don't trust them, you don't put an "or later" there.
If so, why not just go for a BSD licence?
Because decapitating youself just to be sure nobody else can do it is not a very sane strategy?
Really, with the BSD license, you're powerless to begin with. With the standard version of the GPL, the FSF might screw you. Come on, how realistic is that? St. Ignucius gives up on his ideals no sooner than hell freezes over.
Slashdot Mirror
Okay, this will happen if you deliberately allow it. Every "boiler" (the name is not true, because the water shouldn't boil) has a pressure relief valve. If that it stuck close, it will already crack when heating the water, way before boiling, so no further pressure can build up. To get a steam explosion, you need a very strong vessel and you must boil the water despite the pressure building up (which is a far cry from the 55C you usually aim for).
That thing rupturing would really be no nice thing to have around. Actually, those nasty steam explosions were quite common in the days of the steam engine. In those days steel wasn't as strong as it is today, and they really wanted superheated steam, not just warm water.
You can't heat water up quickly enough with conventional resistance-based electric elements, as it would require huge amount of electricity.
/. editors use for a brain, huh?
Christ people, what do you think the microwave thingayamajig will use to heat the water? Will it take Free Energy from the Tachyon Field Of The Earth or something? What do you
A resistive electric heater converts the whole electric energy it takes in into heat. No losses at all! You cannot put out the same amount of heat using less electricity, no matter what Rube Goldberg device you concoct to do it.
The disadvantage is that if this tank, which is under pressure, ever blows up, it takes the house with it.
Water tanks cannot blow up unless they contain an air bubble. They can only leak. This is because water is incompressible and so won't store energy when being pressurized.
Diode lasers use silicon, or at least compounds of silicon.
They don't, unless you are willing to call the laser diode in your CD player a "plastic laser" because it's mounting in a plastic casing. The semiconductor in light emitting diodes is usually GaAs and never silicon, mainly because silicon diodes just won't emit light (no even infrared).
Oh come on, it wasn't me who brought up the supposedly heavyweight C++ runtime. The whole point is, printf is braindead, iostreams are sane.
You'll catch it doing braindead stuff like inserting data into the stream one byte at a time.
No, you don't. You catch it putting single bytes into a buffer (yes, I did look at the code). And these calls can be inlined (while printf("%c",...) cannot). Any more strawmen you want to put up?
You don't do it by coding the way they tell you to in CS school
I wish that was true. They don't tell you about coding in CS school at all, which is a shame. Sometimes they throw buzzwords at you and call that coding, which is even worse. So yes, due to lack of any serious programming being taught, writing robust/working/efficient, basically just good software takes a background in CS and then lots of experience.
C...C++...Java
Was that supposed to be an exhaustive list of all programming languages? I certainly hope not. Imnsho, Java belongs more to the problem set than the solution set, C++ is kind of always the second best tool, but rever really suited, and C is good for simple logic that has to be very efficient or close to the metal. More complex logic quickly gets messy in C, and in C++ as well.
I was actually thinking of Lisp, Scheme, Erlang, Lua and some others. Erlang shines in realtime embedded applications (an ATM switch does count, doesn't it?), the others are available as tiny and powerful interpreters that work well with some pieces done in C.
If you have a function and you pass it an object, it it going to call the constructor once?
...qsort...
It calls the copy constructor exactly once. If you pass a constant reference instead, nothing is called. But of course, if you *do* pass by value, you know what you're doing.
Unless of course you're a dimwitted Java programmer retrofitted to crank C++ because the JVM was larger than the available RAM and you thought, you could code anything that had curly braces.
(Returning an object by value calls the copy constructor at most once. If that turns out to be a problem, you return an std::auto_ptr or something similar, or you do black magic with template meta programs like in Blitz++.)
templates are generally a lose for embedded. The reason is that generating n versions of the template classes/functions ends up costing way too much in ROM (which is generally tighter than even RAM). Instead you write a single version that uses void* pointers and a size field in the node, saving Ks of ram.
No, you don't (even if the proponents of Java generics don't seem to ever get tired of lambasting the evil code bloat in C++ from use of templates). You write the goddamn template, give it a specialization for (void*), then partially specialize it for (T*) and implement that in terms of (void*). You get all the fun at no extra cost, you just have to know what you're doing.
Even more important is the use of templates in the STL: yes, you generate n versions of std::list for all sorts of usually small objects. That amounts to exactly no code, because all functions defined on it are so tiny, they get inlined. After inlining, everything is ordinary static structures with constant offsets. The (void*) could never match that performance, neither in memory consumption nor in execution time.
Well, most STL implementation actually use shell sort. But that's beside the point, because STL works well with user supplied algorithms. By comparison, any generic sort in C is dog slow, because it has to call out to the predicate through a function pointer. The template version in C++ can inline the predicate.
when storage is minimal the CRT wins everytime over the C++ runtime
No, it doesn't. C++ doesn't need much runtime, basically just memory management (same as in C) and some support for exception handling (optional, but worth it, imho). The rest is the standard library, and there you only pay for what you use, as in C.
If you compare specific parts of the two libraries, C++ wins. Most striking example: C printf (ever written a program without it?) need to include all the formatting code for dealing with integers, floats, string, formatting flags, locales. How could it leave something out, for the compiler cannot see that you never use %f. C++ iostreams only need the formatting code that is actually called. You will often get rid of the floating point output, because you never output floats. You may have a single, trivial locale in your program, so you get rid of that code, too. Also, stream operations can be inlined, printf cannot.
However, commercial C++ runtimes are often implemented as a layer on top of the C runtime. This adds to the size, of course.
One problem is that it's often desirable for embedded applications to behave predictably.
Strange. This could be construed to mean that it doesn't matter whether or not a full blown desktop or server application behaves predictably. Since nobody seems to think this is wrong, something is seriously broken in this industry.
Another problem is that embedded systems need to be very reliable over long periods of time with no user intervention.
This is next to impossible in C, the reality of the software industry proves this day in and day out. Dynamic allocation or not, a reliable system in C takes competent programmers (at least two, one has to keep an eye on the blind spot of the other), lots of time and many iterations until the bugs are ironed out. We see this on the desktop and server, too: software simply is unreliable, and if the bugs aren't introduced by faulty memory management, there are still buffer overflows and the like.
So I'd say it doesn't matter whether you use malloc. If reliability is that important, don't use C.
So I don't see why Sony is violating the LGPL here. As you can download the LGPLed library from sourceforge, its freely accesssible, no?
1) They don't attach a copy of the LGPL and they erased the copyright notice on the libraries in question. This is unconditionally a violation of copyright law.
2) Lame ist not attached verbatim, but in parts. That constitutes a "work based on the library", therfore has to be licensed under the LGPL or GPL, and machine readable source code or a written offer to provide it has to be included, neither of which has been done. This is a violation of the LGPL.
3) Two libraries have been statically linked into an OCX. While the OCX could be considered a shared library, the OCX itself must be LGPL'd, and source must be included and so on. Again, this is a violation of the LGPL.
4) Whether source code is freely available somewhere, is of no importance. You are allowed to link with a verbatim copy of the library (has not been done here) without providing source. In all other cases you are required to provide the source code at least on request. Pointing to someone who already does this, doesn't count.
On a side note, have you heard about that amazing ability called reading? You might try it sometime at http://www.gnu.org/licenses/lgpl.html.
the FOSS community in paticular has dropped the ball on XQuery applications.
And rightly so, because it's crap. Since XML has no regular structure, any XQuery involves a linear scan. Unless some sound theory behind XQuery is discovered and a way to index XML documents, XQuery is useless.
Berkeley DB XML claims to index XML documents. I tested it on a large document. A trivial query took a GB of memory without returning anything but an error. What's the point of this "technology"? It should have been given up on back in 1996.
Whenever you are optimizing, the first thing to do is to use a smarter algorithm or an advanced data structure. No amount of bit twiddling will gain as much as an improvement from say O(n^2) to O(n log n) does. Coding an advanced algorithm on top of low level "performance tuned" code is next to impossible. Therefore, write high level, portable code. After tuning, it is still high level, still portable, and it also performs.
If performance still is not adequate (don't guess, ask the profiler), isolate the ugly bits behind a clean interface, then code machine specific implementations if there's something to be gained.
However, this statement alone
One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit.
tells me that you're far from "seeing it". If you're counting bits, your code will be slow despite being non-portable.
I believe you should shut up, stop relying on hearsay and read the license. Section 4 most clearly states:
A while ago I heard of a German prototype for a practical electric car. You're right, there's no complex ICE, no transmission, but simple electric motors. You can even get all wheel drive and traction control basically for free. Motors can work as generators, so brakes can be simpler.
The big problem is energy storage. Capacitors have low energy density, but can be charged and decharged in fractions of a second. NiMH batteries have better power density and survive many charge cycles at reasonably high amperages. But as primary storage they are still bulky and heavy.
The aforementioned prototype used a supercap, a NiMH battery and a zinc-air battery. The supercap is short term storage for regenerative braking and quickstarts, the NiMH battery smoothes out varying demand and gives power when quickly accelerating, and the zinc-air battery is the primary storage, which is only capable of giving a moderate and constant power output, but has reasonable energy density. Switching regulators shuffle electricity back and forth as needed.
Now you should see the problems: Four switchers with high power ratings, three batteries, all completely different, and the main battery is experimental technology. This is a complex system, it is still in its infancy and there was not enough economic incentive to develop this further. No need to resort to conspiracy theories for an explanation.
Besides all that, the electricity, which is stored with losses, has to come from somewhere. Obviously, there's no advantage to burning oil in power plants instead of ICEs, and there's little advantage if the oil is replaced by coal. The electricity has to come from somewhere else, which is still not the case, and so battery powered vehicles are not interesting yet.
A license to sell software would probably be enough. Moreover, holding someone responsible for damage caused by software would do the trick. This would normally be the vendor, but if no vendor was paid, it might be an administrator.
A license to own a compiler would be a bad thing. We all know that Microsoft, Oracle, SAP would immediately buy... err... apply for licenses, and we also know how competent their coders are.
Nonono, that's not what I said. If you give someone your software, you also give him permission to use it. What else would be the point? Give someone software to fill his harddrive so his other useless software doesn't feel lonely? Even your stupid American lawmakers who gave you the DMCA can see that.
If you want to control who uses your software, simply keep it. Don't provide a download, don't sell it. Oh, ans Microsoft can cry as much as they want, their EULA which forbids you to write office application with your bought copy of their devstudio, is simply void. They sold it, you can use it for whatever you like.
I predict, you will again refuse to read the GPL, and I predict that you will predict something even more retarded, too. Your turn.
Well, you get an implicit license to use when you buy software or legally download it. If simple use is enough, you don't need anything explicit. BTW, now would be a good time to actually read the GPL (any version you like).
This is almost correct. Plant life makes a great carbon sink, if and only if it is provided with sunlight and is prevented from decaying and is instead buried.
Plants on land are no carbon sink, because they decay completely within a few years. Not even tropic forests bind carbon, the whole biomass is recycled within a year.
Plants in the deep sea are no carbon sink, because there is no light, and therefore actually no plants. In a depth of 800m it is simply pitch black, and the only energy source for plant-like life there are hot sulphuric springs. They don't provide much useful energy.
The only significant carbon sink working right now is phytoplankton in shallow oceans. Most of it is still eaten by fish, not much sinks to the ocean floor and stays there.
While ideas in principle are a good thing, this one is still stupid. The CO2 doesn't go away, it will come back to the surface sooner or later. Separating and liquefying CO2 costs energy, which comes from burning yet more coal, which produces yet more CO2 which has to be put away. Estimates go around 50% more emissions for this stupid plan.
/me shakes head.
Add to that that this scheme is only feasible for large power plants, and one wonders how blind one has to be to promote such a stupid plan while dismissing clean nuclear power out of hand. Nuclear wastes at least decay and don't pop out in huge bubbles that swallow ships and asphyxiate whole cities. And as an aside, if both concentrated CO2 and plenty of heat (nuclear or possibly solar) were available, one could produce synthetic fuel (by creating H2 through the sulfur-iodine-process followed by Fischer-Tropsch-Synthesis). But no, we have to bury the CO2.
It's a license to use the software
No, it's not. You do not need an explicit license just to use software. Software is made to be used, therefore you can expect that you are allowed to use software you bought or were allowed to download, therefore you are allowed to use it. Although software vendors keep telling you that you aren't buying software, merely licensing it for use, it still looks like an ordinary sale. If it looks like a sale, it is a sale, therefore you bought it, therefore you can use it.
Full stop. Read that again: Yo do not need a license to use legally acquired software. Now read the GPL-2, check what they tell you about whether you need to accept it to use the software. See? And the GPL-3 cannot change one iota about that, because it's the law. You only need to accept an explicit license to distribute software.
Now please try reading up more and predicting less on this subject.
APIs cannot be copyrighted. You don't need a license to call a published API. Using an API does not (usually) make your program a derived work, and that is decided by copyright law, not by the FSF.
.idl files or whatever. Even that could be considered mere use (for which you never need an explicit license!), which probably depends on the exact nature of the program/library in question and the mood of the judge.
You do need a license to #include copyrighted headers or compile copyrighted
BTW, I quite like the idea of the new GPL, and the FSF should do everything they can to make it have the most impact. And you should get a clue, nuthead.
I predict it will be draconian, specifying that people who merely interoperate with GPL3 SW will have to publish source code.
This isn't even legally possible. Sure, Moglen could write such crap into the license, but it wouldn't stand up in court anymore than SCO's "All your Unix are belong to us" claim.
Whatever the FSF decides, some people will not like it and use another license. This is a Good Thing (though there are already enough almost identical Open Source Certified licences).
If on the other hand the GPL-3 is constructed by popular vote, it will be subtly broken, and it will include so many compromises that nobody will like it and so everybody will use a different license.
Yes, but that choice is left up to the viewer if you specify "or later".
This really boils down to whether you trust the FSF to Do The Right Thing. If you think so, you put the "or later" clause in and allow your program to be "upgraded" to a recent version of the GPL, thereby retaining licensing compatibility with newer software. If you don't trust them, you don't put an "or later" there.
If so, why not just go for a BSD licence?
Because decapitating youself just to be sure nobody else can do it is not a very sane strategy?
Really, with the BSD license, you're powerless to begin with. With the standard version of the GPL, the FSF might screw you. Come on, how realistic is that? St. Ignucius gives up on his ideals no sooner than hell freezes over.