There is a reason that most of the Desktop Environments are popular. GUI *is* important for many use-cases. And many of those that you mention aren't good choices. xfce and LXDE, however, ARE good choices. (WRT trinity, the times that I've tried to use it, it hasn't worked. Others, however, report reasonable to good success. So YMMV.)
Desktop software is a complex ecosystem, and small groups can't keep it working. So I have my doubts about the long-term viability of MATE. Cinnamon, however, seems a worthy choice, though not as good as Gnome2 was. Note that xfce is being rebased on the Qt toolkit. This is because much of the Gnome2 underpinnings are unmaintained. (For that matter, IIUC, Razor-Qt is being merged into xfce, though I don't know that this means that the projects are being merged rather than just sharing a common code-base for their underpinnings. Perhaps MATE could also use that code-base, and thus survive. I admit to worrying about the long-term viability of Qt, as it's quasi-proprietary, but KDE has an agreement with the company [as an inheritor from Troll-tech] that should require the availability of the code...but doesn't specify what design changes will be acceptable. Ouch. Gnome2 is still available in that sense.)
I gave up on the Mac when they included that line that read (approximately) "We have the right to add, modify, change, copy, or remove any file on your computer" to a security update.
Prior to that I had used and recommended Apple for 2 decades. (Well, some of the time I used MSWind, due to work constraints, but I *never* recommended it.) Since then I no longer use or recommend Apple. I've still got an old machine, but it needs to be disconnected from the internet, because I can't accept the security updates. (I think that was around OS 10.4, but I'd need to go into another room and plug in the computer to find out for sure.) At least MS made no bones about being a fascist company out for the last drop of your blood. Apple pretended to be a nice company...well, except for the lock-in that they worked so vigorously to maintain.
IIUC, Mate is only a short-term solution because the underlying applications are no longer being developed. Cinnamon is the better long-term solution.
Unfortunately, when I've tried either Mate or Cinnamon they've been too unresponsive to continue using. I'm not entirely sure why, but they are much less responsive than Gnome2 was, and are even less responsive than KDE4. Still, either is far better than Gnome3.
My real hope is that xfce will develop a bit. Or possibly LXDE. (I'm not really after Lightweight, but I don't have a real problem with it, either, as long as I can supplement.)
Unfortunately, one real requirement is that electricsheep run. Currently that appears to limit me to KDE4. I presume that this will eventually be addressed by its developers. (Yes, it's a silly requirement. My wife really likes the way it looks. So it's a requirement.)
Sorry, but I've tried Gnome3 repeatedly. (Really don't like KDE4 either, and I kept hoping they'd make it usable.) They didn't. They actually kept making it worse.
I'd use xfce, but my wife doesn't like it. I'd prefer to use KDE3. Gnome2 was a good alternative. Now I've got KDE4, which is sufficient, if not good. (KDE3 was good leaning towards excellent.)
I originally assumed that there were underlying technological problems that caused the change, but apparently the designers just decided they didn't like what people were doing.
1) KDE4's issues over KDE3 were fewer and smaller than those of Gnome3, and they still drove me to Gnome2.
2) KDE4 is still not as good as KDE3 was, but I'm now using KDE4 to avoid Gnome3.
3) Given the problems I have with both of them, I'd prefer to be using xfce, but my wife doesn't like it as well. (I'd really prefer KDE3.)
4) I don't really like fidding with my machine. I have other things I want to be doing. And Gnome3 gratuitously breaks adaptations between versions, so I would need to WANT to be constantly fiddling with it to find it at all usable.
Perhaps there are others with other work flows that feel differently. (Actually that's pretty obviously true.) But to me Gnome3 is mainly about trashing Gnome2, to the point where I have several times suspected intentional sabotage by the designers.
I don't know Haskell, but in Erlang, which has semantics similar to those you show, maintaining locally accessible mutable state requries fighting the language. You *can* do it, and fairly simply, but all the sources tell you "Don't do this!", so my suspicion is that if I wrote anything sizeable it would lead to difficult to trace problems.
But mutable state is a part of what many applications need. They just don't need globally visible mutable state.
To be a little bit more precise, I could do things safely in Erlang (i.e., without violating strong recommendations) by storing changes in a database. But that would slow things down tremendously. "volatile" state doesn't usually need to be saved, since it's just going to change again anyway. But it does need to be able to be changed.
Note that anything that can be calculated using mutable state that is safe to express, can be calculated in a pure functional language, if you don't concern yourself with memory and time. But the same it true of a Turing machine. For some classes of problems, pure functional languages work well. That fibonnacci example is a nice example of this. (IIUC that example calculates each small value of the function many times in the course of calculating larger values. Not ideal.) For this reason most functional languages have "escapes" which make them not-pure-fuctional..
OTOH, it's easier to interface other languages to libraries written in C. And Qt is owned by Noika, which isn't currently a big improvement over Oracle. (Trolltech was, and was dependable. I'm not at all convinced that Noika is. OTOH, they currently seem to be less actively antagonistic towards end users than do the Gnome developers...though I will grant you this is purely a personal perception, and not objective.)
Well, penicillin is basically a kind of bread mold, so the bacterial competion it's facing isn't heavily affected by our use of it as a medicine. Less so, in fact, than the soil bacteria that make tetracycline are by our use of *its* antibiotic.
Penicillin is probably more affected by BHA and BHT and various other things that are added to bread to keep it from molding.
I agree, they *ought* to be good at parallel. But often they aren't, even if I don't know why. E.g. Racket Scheme has wonderful parallel constructs, but if you read the documentation carefully you discover that those constructs actually only run in one thread. (I'm particularly thinking about "futures" here.) And if I want to start separate isolated processes...I can do that in Ruby or Python or C or...well, anything that can handle network connections to the same machine.
Usually, I'll admit, the documentation isn't good enough to say that they are running these fancy parallel constructs in a single thread. But I don't find poor documentation convincing that there's a good implementation.
FWIW, I don't use blockers/add-ins/extensions. Of course, that means I find MANY web sites so obnoxious I only go there once. And that's without haveing flash installed.
ISTM that the basic idea is good, but it should, itself, be targetable. I.e., you should be able to "greenlight" certain web-sites, and to "red-light" certain extensions. This would, of course, interfere with it's anonymizing feature, but not, I feel excessively.
C is great for small pieces of code. It gets increasingly awkwards as the size increases. So you need to modularize. Which is what Object Oriented languages do. Also what functional languages do, though they do it differently. I don't think either of those is the best choice for a MPU heavy environment. To me that sounds like a dataflow language would be best. But I can't think of any extant that aren't either moribund or so narrowly specialize that they might as well be. (Few languages are actually dead so far. I suspect that you can even find Snobol running somewhere. I know you can still find ICON.)
Snopes, and debunkers generall, are unreliable. They're so interested in debunking that explaining away one case is treated as explaining all cases.
N.B.: This doesn't mean that they are always wrong. That would be a form of reliability. Just that they give (and believe?) glib explanations that aren't necessarily correct. I can easily believe that one particular instance of that was a humor column. That sure doesn't mean that's the explanation of all such reports.
Sorry, there ARE real differences between languages. It's not just a matter of taste. You don't use Python when you need speed. And handling unicode in C or C++ is a cast-iron drag. My favorite languages are Python and D (D for when I need speed). I don't like either C or C++ because of all the wild pointers and unchecked conversions. Ada has it's points, be it's extremely verbose...and hard to document decently. The language I'd like to use is often Vala, but the libraries are essentially undocumented. (The name of a routine doesn't count as documentation, even if you include the parameter list.) I've never found a good reason to use Scheme. (If I did, I'd probably choose Racket Scheme, because it seems well supported and decently documented...but it's also explicitly not parallel...which I could tell because it had decent documentation.)
What's really needed is a decent dataflow language, sort of like Prograf attempted to be back in the days of the Apple ][, But it needs to have a text representation, as graphics make understanding anything sizeable impossible (because they take up too much space). Perhaps a smarter editor could solve that problem. But dataflow seems to me to be the best way to handle multi-processors.
Still, libraries are EXTREMELY important. One of the big limitations of D is that there aren't very many libraries. (It can link with C libraries, but things aren't straightforwards, as it doesn't understand the macros in C header files....so you need to translate by hand. And this generally means you need to already know how to use the library in C. Compare this to Python or Ruby.)
The main problem with C++ is the template system. There are other problems (like unrestricted casting of pointers and variables), but compared to the template system they are trivial. And it probably can't ever be fixed, because fixing what's broken would break a huge amount of code.
I don't know about the Keys in particular, but many places where we have pumped either oil or water out of underground resivoirs are sinking. Usually, but not always, slowly. (Undergound coal mining has the same effect, but the collapses tend to be more sudden and dramatic.)
Now parts of the Gulf have had lots of oil pumped out of them. Probably not near the Keys, but I don't know for sure. (It certainly affected New Orleans.) Agriculture has also extracted lots of underground water from many areas. IIUC, this is a part of the reasons that the Everglades is drying up, but the aquifer could also extend a considerable distance underground...perhaps as far as the Keys.
Additionally, islands generally subside over time. Look at the sizes of the Hawaiian Islands, as you move backwards from the most recent (still building) island of Hawaii eastwards and northerly the islands grow older and smaller. This is because they have worn away over time. And the Hawaiian Islands are volcanic rock, not the mess of largely compacted sand that is the Florida Keys. (Not knowing, I suspect coral to have played a large part in the creation of the Florida Keys. But corals are having a hard time as the oceans become more acidic. Additionally invasive species (from the pacific) are destroying Atlantic corals. The Florida Keys may be too far North for that to be affecting them, but I'm not sure.
So there's LOTS of reasons to expect the Keys to be unstable. And none to speak of to expect them to be stable.
I must have misunderstood the damage caused by Lithium mining...unless it was the refining that I was remembering. (The alternative is that I was confusing it with Cadmium.)
I also seem to remember that Lithium is already in short supply, but I suppose this could also be wrong.
The GGP was talking about battery life, and that was what I was responding to. Yeah, electric motors can be pretty durable. Batteries, not so much so. Problems with the electrodes and recharging. And he was specificly saying that "High Quality LiON batteries" were sufficiently efficient. Those haven't been around long enough to say that they are durable, and similar batteries in the past have had problems with their electrodes corroding.
But think of the consequences of having to take immuno-suppressive drugs for the rest of your life. They aren't good.
OTOH, there was another article today (yesterday?) that proclaimed "Mouse cloned from blood cell!" (But I do wonder if they've solved the "Dolly" problems.)
FWIW, the backdoor would have been put it by Microsoft. Did they? I don't know. I have no reason to doubt it, given their general sleazy business ethics, but the only reason to believe it is that they titled a particular thing "NSAKey". (And the name was assigned by Microsoft, so NSAs sneakiness about such things doesn't apply.)
For all I know the name could have stood for "No Software Algorithm" and been documentation of something they needed to write. (And, no, I don't trust their public explanations. Not even enough to remember more than that they existed.) But I've no particular reason to believe that that particular "key" was anything special. My feeling at the time that I first heard about it was "Is somebody sabotaging MS attempt to cooperate with the NSA?", but, again, no evidence. Certainly no trustworthy evidence. Nor since.
The idea is that you DON'T have a trusted C compiler. You have two apparently good C compilers that were developed independant of each other. So you use one to compile the other's source code, and then you use that second one to compile the first ones source code. Then you can probably trust the first one. (If two steps doesn't suffice, use a chain of three.)
Note that this only works if the compilers are developed independantly of each other, and if they recognize particular chunks of code that the special case when recompiling themselves. Other backdoors would require other counters.
Do you have ANY idea of how much work you are asking to be repeated? Or how many of the contributors to Linux wouldn't really care?
How do you attract coders to the new rebooted FOSS OS?
Your answer is theoretically possible, but implausible. I would, however, expect people to be noisy about it. But already many people don't take even reasonably simple security steps. (I often can't explain to people why installing flash is a bad idea.) For that matter, I have been known to compile and install software from sites that aren't secure.
Having a separate implementation for communication between the military isn't believable. Too many boneheads. (The details wouldn't leak, but I would expect the fact of it's existence to leak.)
Having a separate implementation for communication between NSA and their allies *is* believable. I don't feel it's probable, but it's certainly possible. (Probably the easiest way to do this is to use a layered encryption, with different algorithms at the different layers. Perhaps use that elliptic thingy on the internal layer., a ROT-93 in an intermediate layer, and SSH (or equivalent) on the external layer. (The purpose of the ROT-93 is to make it more difficult to tell what kind of incryption is used on the internal layer.)
That said, if you're serious about security, and don't trust the encryption, and are only dealing with your allies, then you should use a one-time pad. That's not even theoretically breakable. So I still don't believe it...except, possibly, to agents in the field. And for that anything beyond SSH is just calling attention to them. So I still don't believe it. Agents in the field should just use some popular book as a one-time pad, so you don't need to expose the one you use for serious matters. And for most things you just limit your conversation to "harmless" topics. And remember how much meta-data mining is going on.
Coal won't run out for a very long time. High grade coal, however, has already become scarce and expensive. So power plants usually burn bituminous coal...and some even lower grades. These are less efficient, except in very carefully designed plants. (OTOH, efficiency is a cost reduction strategy at this point of the process, so easy ways to increase efficiency are eagerly sought after. Unfortunately emission reduction is guaranteed to increase costs, so effort is put into avoiding emission controls.)
The net result is that coal is already burned as efficiently as is easily possible, but emission controls are generally skimped on...or just avoided. (FWIW, I'm *really* skeptical about "Carbon Capture" techniques. Most of the one's I've seen look like "delay the release, and make it difficult to trace to us". I hope I'm being overly skeptical, but so far it doesn't matter, since even that approach will drastically increase costs, so everyone is avoiding it.)
Slashdot Mirror
There is a reason that most of the Desktop Environments are popular. GUI *is* important for many use-cases. And many of those that you mention aren't good choices. xfce and LXDE, however, ARE good choices. (WRT trinity, the times that I've tried to use it, it hasn't worked. Others, however, report reasonable to good success. So YMMV.)
Desktop software is a complex ecosystem, and small groups can't keep it working. So I have my doubts about the long-term viability of MATE. Cinnamon, however, seems a worthy choice, though not as good as Gnome2 was. Note that xfce is being rebased on the Qt toolkit. This is because much of the Gnome2 underpinnings are unmaintained. (For that matter, IIUC, Razor-Qt is being merged into xfce, though I don't know that this means that the projects are being merged rather than just sharing a common code-base for their underpinnings. Perhaps MATE could also use that code-base, and thus survive. I admit to worrying about the long-term viability of Qt, as it's quasi-proprietary, but KDE has an agreement with the company [as an inheritor from Troll-tech] that should require the availability of the code...but doesn't specify what design changes will be acceptable. Ouch. Gnome2 is still available in that sense.)
I gave up on the Mac when they included that line that read (approximately) "We have the right to add, modify, change, copy, or remove any file on your computer" to a security update.
Prior to that I had used and recommended Apple for 2 decades. (Well, some of the time I used MSWind, due to work constraints, but I *never* recommended it.) Since then I no longer use or recommend Apple. I've still got an old machine, but it needs to be disconnected from the internet, because I can't accept the security updates. (I think that was around OS 10.4, but I'd need to go into another room and plug in the computer to find out for sure.) At least MS made no bones about being a fascist company out for the last drop of your blood. Apple pretended to be a nice company...well, except for the lock-in that they worked so vigorously to maintain.
IIUC, Mate is only a short-term solution because the underlying applications are no longer being developed. Cinnamon is the better long-term solution.
Unfortunately, when I've tried either Mate or Cinnamon they've been too unresponsive to continue using. I'm not entirely sure why, but they are much less responsive than Gnome2 was, and are even less responsive than KDE4. Still, either is far better than Gnome3.
My real hope is that xfce will develop a bit. Or possibly LXDE. (I'm not really after Lightweight, but I don't have a real problem with it, either, as long as I can supplement.)
Unfortunately, one real requirement is that electricsheep run. Currently that appears to limit me to KDE4. I presume that this will eventually be addressed by its developers. (Yes, it's a silly requirement. My wife really likes the way it looks. So it's a requirement.)
Sorry, but I've tried Gnome3 repeatedly. (Really don't like KDE4 either, and I kept hoping they'd make it usable.) They didn't. They actually kept making it worse.
I'd use xfce, but my wife doesn't like it. I'd prefer to use KDE3. Gnome2 was a good alternative. Now I've got KDE4, which is sufficient, if not good. (KDE3 was good leaning towards excellent.)
I originally assumed that there were underlying technological problems that caused the change, but apparently the designers just decided they didn't like what people were doing.
1) KDE4's issues over KDE3 were fewer and smaller than those of Gnome3, and they still drove me to Gnome2.
2) KDE4 is still not as good as KDE3 was, but I'm now using KDE4 to avoid Gnome3.
3) Given the problems I have with both of them, I'd prefer to be using xfce, but my wife doesn't like it as well. (I'd really prefer KDE3.)
4) I don't really like fidding with my machine. I have other things I want to be doing. And Gnome3 gratuitously breaks adaptations between versions, so I would need to WANT to be constantly fiddling with it to find it at all usable.
Perhaps there are others with other work flows that feel differently. (Actually that's pretty obviously true.) But to me Gnome3 is mainly about trashing Gnome2, to the point where I have several times suspected intentional sabotage by the designers.
I don't know Haskell, but in Erlang, which has semantics similar to those you show, maintaining locally accessible mutable state requries fighting the language. You *can* do it, and fairly simply, but all the sources tell you "Don't do this!", so my suspicion is that if I wrote anything sizeable it would lead to difficult to trace problems.
But mutable state is a part of what many applications need. They just don't need globally visible mutable state.
To be a little bit more precise, I could do things safely in Erlang (i.e., without violating strong recommendations) by storing changes in a database. But that would slow things down tremendously. "volatile" state doesn't usually need to be saved, since it's just going to change again anyway. But it does need to be able to be changed.
Note that anything that can be calculated using mutable state that is safe to express, can be calculated in a pure functional language, if you don't concern yourself with memory and time. But the same it true of a Turing machine. For some classes of problems, pure functional languages work well. That fibonnacci example is a nice example of this. (IIUC that example calculates each small value of the function many times in the course of calculating larger values. Not ideal.) For this reason most functional languages have "escapes" which make them not-pure-fuctional..
Have you ever tried nedit on non-ASCII utf8 files?
OTOH, it's easier to interface other languages to libraries written in C. And Qt is owned by Noika, which isn't currently a big improvement over Oracle. (Trolltech was, and was dependable. I'm not at all convinced that Noika is. OTOH, they currently seem to be less actively antagonistic towards end users than do the Gnome developers...though I will grant you this is purely a personal perception, and not objective.)
n/t
Well, penicillin is basically a kind of bread mold, so the bacterial competion it's facing isn't heavily affected by our use of it as a medicine. Less so, in fact, than the soil bacteria that make tetracycline are by our use of *its* antibiotic.
Penicillin is probably more affected by BHA and BHT and various other things that are added to bread to keep it from molding.
I agree, they *ought* to be good at parallel. But often they aren't, even if I don't know why. E.g. Racket Scheme has wonderful parallel constructs, but if you read the documentation carefully you discover that those constructs actually only run in one thread. (I'm particularly thinking about "futures" here.) And if I want to start separate isolated processes...I can do that in Ruby or Python or C or ...well, anything that can handle network connections to the same machine.
Usually, I'll admit, the documentation isn't good enough to say that they are running these fancy parallel constructs in a single thread. But I don't find poor documentation convincing that there's a good implementation.
FWIW, I don't use blockers/add-ins/extensions. Of course, that means I find MANY web sites so obnoxious I only go there once. And that's without haveing flash installed.
ISTM that the basic idea is good, but it should, itself, be targetable. I.e., you should be able to "greenlight" certain web-sites, and to "red-light" certain extensions. This would, of course, interfere with it's anonymizing feature, but not, I feel excessively.
Context is important.
C is great for small pieces of code. It gets increasingly awkwards as the size increases. So you need to modularize. Which is what Object Oriented languages do. Also what functional languages do, though they do it differently. I don't think either of those is the best choice for a MPU heavy environment. To me that sounds like a dataflow language would be best. But I can't think of any extant that aren't either moribund or so narrowly specialize that they might as well be. (Few languages are actually dead so far. I suspect that you can even find Snobol running somewhere. I know you can still find ICON.)
Snopes, and debunkers generall, are unreliable. They're so interested in debunking that explaining away one case is treated as explaining all cases.
N.B.: This doesn't mean that they are always wrong. That would be a form of reliability. Just that they give (and believe?) glib explanations that aren't necessarily correct. I can easily believe that one particular instance of that was a humor column. That sure doesn't mean that's the explanation of all such reports.
It may not make any sense. (If it does, nobody has ever explained it to me.) But IIUC that's the way that patent law, unlike copyright law, reads.
Sorry, there ARE real differences between languages. It's not just a matter of taste. You don't use Python when you need speed. And handling unicode in C or C++ is a cast-iron drag. My favorite languages are Python and D (D for when I need speed). I don't like either C or C++ because of all the wild pointers and unchecked conversions. Ada has it's points, be it's extremely verbose...and hard to document decently. The language I'd like to use is often Vala, but the libraries are essentially undocumented. (The name of a routine doesn't count as documentation, even if you include the parameter list.) I've never found a good reason to use Scheme. (If I did, I'd probably choose Racket Scheme, because it seems well supported and decently documented...but it's also explicitly not parallel...which I could tell because it had decent documentation.)
What's really needed is a decent dataflow language, sort of like Prograf attempted to be back in the days of the Apple ][, But it needs to have a text representation, as graphics make understanding anything sizeable impossible (because they take up too much space). Perhaps a smarter editor could solve that problem. But dataflow seems to me to be the best way to handle multi-processors.
Still, libraries are EXTREMELY important. One of the big limitations of D is that there aren't very many libraries. (It can link with C libraries, but things aren't straightforwards, as it doesn't understand the macros in C header files....so you need to translate by hand. And this generally means you need to already know how to use the library in C. Compare this to Python or Ruby.)
The main problem with C++ is the template system. There are other problems (like unrestricted casting of pointers and variables), but compared to the template system they are trivial. And it probably can't ever be fixed, because fixing what's broken would break a huge amount of code.
This doesn't follow from the quotation, however:
I don't know about the Keys in particular, but many places where we have pumped either oil or water out of underground resivoirs are sinking. Usually, but not always, slowly. (Undergound coal mining has the same effect, but the collapses tend to be more sudden and dramatic.)
Now parts of the Gulf have had lots of oil pumped out of them. Probably not near the Keys, but I don't know for sure. (It certainly affected New Orleans.) Agriculture has also extracted lots of underground water from many areas. IIUC, this is a part of the reasons that the Everglades is drying up, but the aquifer could also extend a considerable distance underground...perhaps as far as the Keys.
Additionally, islands generally subside over time. Look at the sizes of the Hawaiian Islands, as you move backwards from the most recent (still building) island of Hawaii eastwards and northerly the islands grow older and smaller. This is because they have worn away over time. And the Hawaiian Islands are volcanic rock, not the mess of largely compacted sand that is the Florida Keys. (Not knowing, I suspect coral to have played a large part in the creation of the Florida Keys. But corals are having a hard time as the oceans become more acidic. Additionally invasive species (from the pacific) are destroying Atlantic corals. The Florida Keys may be too far North for that to be affecting them, but I'm not sure.
So there's LOTS of reasons to expect the Keys to be unstable. And none to speak of to expect them to be stable.
I must have misunderstood the damage caused by Lithium mining...unless it was the refining that I was remembering. (The alternative is that I was confusing it with Cadmium.)
I also seem to remember that Lithium is already in short supply, but I suppose this could also be wrong.
The GGP was talking about battery life, and that was what I was responding to. Yeah, electric motors can be pretty durable. Batteries, not so much so. Problems with the electrodes and recharging. And he was specificly saying that "High Quality LiON batteries" were sufficiently efficient. Those haven't been around long enough to say that they are durable, and similar batteries in the past have had problems with their electrodes corroding.
But think of the consequences of having to take immuno-suppressive drugs for the rest of your life. They aren't good.
OTOH, there was another article today (yesterday?) that proclaimed "Mouse cloned from blood cell!" (But I do wonder if they've solved the "Dolly" problems.)
FWIW, the backdoor would have been put it by Microsoft. Did they? I don't know. I have no reason to doubt it, given their general sleazy business ethics, but the only reason to believe it is that they titled a particular thing "NSAKey". (And the name was assigned by Microsoft, so NSAs sneakiness about such things doesn't apply.)
For all I know the name could have stood for "No Software Algorithm" and been documentation of something they needed to write. (And, no, I don't trust their public explanations. Not even enough to remember more than that they existed.) But I've no particular reason to believe that that particular "key" was anything special. My feeling at the time that I first heard about it was "Is somebody sabotaging MS attempt to cooperate with the NSA?", but, again, no evidence. Certainly no trustworthy evidence. Nor since.
The idea is that you DON'T have a trusted C compiler. You have two apparently good C compilers that were developed independant of each other. So you use one to compile the other's source code, and then you use that second one to compile the first ones source code. Then you can probably trust the first one. (If two steps doesn't suffice, use a chain of three.)
Note that this only works if the compilers are developed independantly of each other, and if they recognize particular chunks of code that the special case when recompiling themselves. Other backdoors would require other counters.
Do you have ANY idea of how much work you are asking to be repeated? Or how many of the contributors to Linux wouldn't really care?
How do you attract coders to the new rebooted FOSS OS?
Your answer is theoretically possible, but implausible. I would, however, expect people to be noisy about it. But already many people don't take even reasonably simple security steps. (I often can't explain to people why installing flash is a bad idea.) For that matter, I have been known to compile and install software from sites that aren't secure.
Having a separate implementation for communication between the military isn't believable. Too many boneheads. (The details wouldn't leak, but I would expect the fact of it's existence to leak.)
Having a separate implementation for communication between NSA and their allies *is* believable. I don't feel it's probable, but it's certainly possible. (Probably the easiest way to do this is to use a layered encryption, with different algorithms at the different layers. Perhaps use that elliptic thingy on the internal layer., a ROT-93 in an intermediate layer, and SSH (or equivalent) on the external layer. (The purpose of the ROT-93 is to make it more difficult to tell what kind of incryption is used on the internal layer.)
That said, if you're serious about security, and don't trust the encryption, and are only dealing with your allies, then you should use a one-time pad. That's not even theoretically breakable. So I still don't believe it...except, possibly, to agents in the field. And for that anything beyond SSH is just calling attention to them. So I still don't believe it. Agents in the field should just use some popular book as a one-time pad, so you don't need to expose the one you use for serious matters. And for most things you just limit your conversation to "harmless" topics. And remember how much meta-data mining is going on.
Coal won't run out for a very long time. High grade coal, however, has already become scarce and expensive. So power plants usually burn bituminous coal...and some even lower grades. These are less efficient, except in very carefully designed plants. (OTOH, efficiency is a cost reduction strategy at this point of the process, so easy ways to increase efficiency are eagerly sought after. Unfortunately emission reduction is guaranteed to increase costs, so effort is put into avoiding emission controls.)
The net result is that coal is already burned as efficiently as is easily possible, but emission controls are generally skimped on...or just avoided. (FWIW, I'm *really* skeptical about "Carbon Capture" techniques. Most of the one's I've seen look like "delay the release, and make it difficult to trace to us". I hope I'm being overly skeptical, but so far it doesn't matter, since even that approach will drastically increase costs, so everyone is avoiding it.)