Fuel cells heat up a lot during operation. What do you think happens when hydrogen combines with oxygen, in those cells?
No, they don't. In an ideal fuel cell, the chemical energy of hydrogen and oxygen is converted directly into electricity. They can't be 90% efficient and still get hot, can they?
Besides, not even electric motors are more than 90% efficient. There is no free lunch.
*Much* more efficient? 46% isn't really *much* more than ~33% efficiency. Add to that that electrolysing, purifying and liquefying hydrogen cost more than twice as much energy than ends up in the hydrogen itself, remember that the car's electric system won't be more than 90% efficient (I doubt it's even that much) and that a fossil powered car can be heated by waste heat while a fuel cell car has to be heated electrically, and suddenly the fuel cell car is *much* *less* efficient at no more than 20% overall effenciency. Also hydrogen cannot be stored perfectly, it's slowly heating and evaporates and it even creeps *through* metal, which is adding to the losses.
No, even if nuclear power is scaled up massively, hydrogen is a damn stupid storage technology. Synthetic methanol or metallic fuels (boron or zinc) sound much more promising.
You're describing Fresco, formerly Berlin, and Fresco before that and Interviews even further before. Somehow it didn't catch on under any of those names. What a shame.
Who's fighting? All those distros are happily coexisting and synergistically feeding to each other. Don't make it sound as if violence was involved.
Besides, there *is* a de-facto stand to install apllications:./configure;make;make install. Works everytime. Works beautifully in conjunction with stow. And contrary to popular belief a compiler is not a dangerous creature.
Folks, mind the distinction between Free Software and Open Source Software. Despite ESR's efforts to convince the public that they are the same.
Free Software is all about protecting the freedom of the user.
Open Source Software is about a supposedly superiour development model.
See the difference? Open Source has no ideals. Therefore you cannot "exemplify OS ideals" and you cannot argue about them.
So what about the ideals of Free Software? Well, you are not protecting user's rights if you are tying them even more to a proprietary platform, while a good Free alternative exists. Do whatever you like, but obviously you don't deserve respect from the Free Software community for what you're doing. And please shut up about ideals, you don't have any.
For the uninitiated, KDE is not "free" on the Windows platform, nor is it even LGPL on any platform.
Pure FUD. KDE has always been under the GPL or LGPL. The combination of Qt and KDE could not be distributed in the early days, due to the incompatibility between Qt's license and the GPL.
Since Qt3, KDE+Qt were GPL or LGPL. Completely. This combination didn't run on Windows and nobody cared. Since Qt4, even the Windows version is GPL'd. You may also buy a commercial license for Qt.
This means it is easier and cheaper to write and deploy software for Microsoft Windows than KDE.
No, it isn't. All development tools for KDE are free. It may be cheaper to write and sell software using whatever on Windows instead of Qt. But who cares? If you want to be paid for programming, you have to pay others for their work, too. Deal with it.
And what's there to learn? If anything, this could be memoized. Your coworkers have learned that to open something, you double-click it. You single-click to select. This is completely accurate -- and then URLs are different all of a sudden. You single-click to open and you cannot select or drag anymore. The inconsistency makes understanding the machine's behaviour needlessly hard, so it's no wonder people give give up early and resort to rote memoization.
Compare this with the Unix command line, an editor like Vim and text processing tools like *roff. What you learned once, stays valid and carries over to most other tools. This isn't "harder to understand", rather it can be understood *at*all*.
1. Installshield supposedly is something else than package management?
2. Debian doesn't. Almost. You need to set the basics (language, keyboard layout, desktop/server/custom installation, installation target), everything else is automatic. Even less configuration work, and you'd bitch about how it steamrollered your Windows install you wanted to keep for some reason.
3. Pointless. Were "System" and "Applications" more seperate (whatever the distinction, *I* find a good seperation between/bin and/sbin), you'd bemoan the insufficient integration.
4&5. Linux doesn't. KDE does. Don't use it if you don't like it. Instead, use something completely different, like wmi.
6. All errors *are* reported in plain English (or any of a large number of other natural languages)! Dunno what you're using, I never see "error codes".
7. Have a look at Vim and/or Emacs. You'll like one of them and never want to go back to an Windows-style IDE.
8. They do. OpenOffice is not the only software that runs on Linux (GIMP has already been mentioned).
9(sic!). No, most people use MS Word at home, often a "borrowed" copy. Those emails with.doc attachments aren't written on notepad, you know?
And seriously, your obsession with package management is... disturbing. You can install without package management (configure/make/make install), only deinstallation becomes harder. As soon as new software has to integrate with something (startup script, logfile rotation, class registry, linking documentation) you need to do more than just drop a file into place on installation. Package managers just organize what is needed anyway, and they work well. Dependency tracking is also a great win. It doesn't completely prevent "DLL Hell", but *if* things break, they don't break silently. Have a closer look at dpkg/apt before writing it off as a design error.
You didn't get it, did you? It's not about regexes being *bad*, it's about regexes being *wrong* and by extension insecure, but the *right* solution, context free expressions or something exquivalent, is prohibitively expensive due to the B&D language chosen.
To make code secure, a language that makes Doing The Right Thing easy is needed, not a language that makes doing some specific wrong things hard or impossible. And that is wrong with Java, it doesn't make anything easy, it only eliminates wild pointers from C++. No better abstractions, no improved syntax. No sharp edges to cut yourself (or anything) with, either.
BTW, I don't care much that my pet language wasn't considered. But I *do* find it disturbing that only two (very similar) languages are looked at when there are dozens to choose from. That tells a lot about the sad state of the software industry.
...didn't do half the things a proper XML parser should do...
Oh, are you saying, XML isn't a universal, light-weight format that an average CS student could implement in three weeks, after all? Are you implying that it is rather a bloated, inefficient, underspecified format that nobody could implement completely and correctly, let alone in three weeks, and which is also either unsuitable or overengineered for most tasks?
You're a wise man, dude.
Besides, the name "XML parser" is wrong. A SAX parser is just a lexer, a DOM parser parses an LL(0) grammar, which is trivial. All this should be easier. It probably is, if you use something sane instead of XML.
Nonsense. Some cycles wasted by suboptimal code can never match the magnitude of bloat caused by a single XML parser. The problem isn't that people think at higher abstraction levels, it's rather that people have stopped thinking at all.
Web ads works by having *my* computer request the picture and *my* computer displaying it with the power of *my* cpu. My browser is configured to just not do that.
Therefore, I'm not blocking ads that "come naturally" to my computer, I'm just not helping them to get there in the first place. Advertisers have no right to my computer, and language should reflect this fact.
So to ask the correct question: "Do you browse ads?" -- "No. Why should I?"
You know, there are already some entire nuclear reactors lying on the sea floor. They can't melt, since the water cools them and their radiation doesn't get further than a few meters. Compared to some thousand tonnes of oil they are completely harmless.
In C, it requires almost no thought at all to write insecure code
Well, this is true of any language. Just think of Perl: buffer overflows are impossible, since strings and arrays grow when needed. People still manage to write swaths of code with shell or SQL injection vulnerabilities, despite taint checking. Piling language features onto each other to make a factory for secure programs will always be an uphill battle. What is really needed are competent programmers (which are in pitifully short supply).
Therefore the real question is not whether a language is more secure or if this or that runtime is more likely to contain bugs itself. The only question is: "How much does this language help writing secure code?" but also: "How much does this language help writing correct code in a reasonable amount of time?"
Whenever it is clear how to write code the right way, but it takes herculean effort compared to the Q&D solution (for example: prevent code injection bugs by parsing, interpreting an AST and pretty printing instead of some regexes), it will not be done. Java is unfortunately not of much more help here than C, unless you happen to find a suitable library.
Functional languages are better, but as always, they are not even considered in passing. That was actually my gut reaction to the tag line of the article: "What moron stated the choice was between C and Java only?!"
Except you are wrong. The compiler can optimize zilch here, because:
public double getDistanceFrom(Component other) { Point otherLocation = other.getLocation();
`other' may be of any subclass of `Component' and therefore may override `getLocation' in any ways it sees fit. The same goes for `otherLocation' if `other' decides to create something of a subclass of `Point'. Particularly, `getLocation' might keep a reference to the newly created `Point', thereby making the cited stack allocation invalid, and it might return a class with more data, making your unfolding invalid. In short, the compiler needs global information (the dynamic type of `other') to optimize anything, and due to seperate compilation and dynamic linking, this information is unavailable in principle.
The JVM may have this information, as the article states, but only when `getDistanceFrom' is actually called. At this point it could either check the dynamic type of `other' and dispatch to a statically optimized version (which is probably useless, considering that in Java nearly everything is expressed in terms of interfaces and not concrete classes) or dynamically inline `getLocation' and then optimize. Stack allocation however is still impossible if anything after `getLocation' is called with `otherLocation' as parameter, unless that too is inlined and (statically!) "escape analyzed". But all this inlining and analysing amount to somewhat more work than a heap allocation. Add to that, that after inlining the code block may be unwieldy large and too complex to analyze, making all this effort completely useless.
In short, all these optimizations may be possible, but always at a cost. The cost may be negligible, but that depends on the application. A micro benchmark is no application. I believe all this propaganda, when I see a Java application that feels fast. I've seen enough that feel sluggish. (Anyone remember Corel Office? Yeah, that was a fast Java application. It disappeared very quickly because of its outrageous demands regarding CPU power and memory.)
BTW, I just love Haskell. Naively programmed it is very elegant, but incurs a performance cost. Yeah, yeah, a sufficently smart compiler could cure cancer and turn lead into gold, blah blah. Bullshit, it's mostly theoretical, exactly as theoretical as the "smart JVM". In reality, fast code is possible, but takes work and is often at odds with elegant code. If the Java advocates only acknowledged that the magic JVM is no silver bullet and that other technologies might have their niches, too, I might even take them seriously.
In Java, the auto garbage collection is as good as Perl's
It's just that Perl doesn't have GC, but shoddy reference counting, which is easily confused by cyclic references. If Java is as "good" as Perl there, that's not the best of advertisements.
"Able to be self referential" is different from "indeed self referential", which is again different from "equivalent to a Gödel sentence and therefore undecidable".
Thanks a lot for understanding nothing and throwing buzzwords around.
Software development is still an art, and may always be one.
And that would certainly be romantic, wouldn't it?
No company has ever demonstrated a methodology that is guaranteed to deliver high quality, maintainable software in a predictable amount of time.
That is because it's impossible. Every program is new, by construction. You never write a program twice, you reuse and customize the old one. Everything that is new is a bit unpredictable, so the "predictable amount of time" is simply unachievable. That, however, doesn't make software design an "art". A civil engineer likewise cannot predict how long the design of a daring building will take, but he is still an engineer.
Mostly, because he doesn't ship the building until his calculations show that it will support itself. It's that part where software engineers fail.
But not to the extent many think. Whether it is Gödel or Turing doesn't make much difference, at the core, both theorems say almost the same: Given a arbitrary program or proposition, you cannot decide some of its key properties.
However, you are never given "an arbitrary program". You write it, and as long as you write by some other methodology than randomly punching keys, you have a sketchy proof of how it will work in your head. For these programs, halting is decidable, and all properties can be proved. Gödel has no say in the matter, because no one writes self referential programs.
Truly, philosophers and incompetent programmers made Gödel's Incompleteness Theorem the most abused theorem of all of mathematics.
In principle, every software patent is bad. However, we cannot infer that the company behind the patent is evil, because that's simply the way the game is played. Software patents exists (for you poor americans at least), and if Google doesn't apply for them, someone else does it.
Then again, if they start enforcing their patents or if they start arguing for software patents, then it is bad. Eolas did the former (in the US), which is bad. This is still bad, even though the Evil Empire was on the receiving end. Microsoft did the latter (here in Europe), which is bad, too. And Google? We'll see...
I've been hearing this very mantra out of the Linux/open source community for years.
No, you haven't. You're confusing the community with journalistic loudmouths. While the loudmouths will claim loads of bullshit of Linux dethroning Windows and what not just to sell more ads, if you ask a programmer, a real member of the community, about Windows, he'll probably reply "Windows? Yeah, it's crap. Don't bother me, I'm coding." Most of the community is invisible. They have better things to do than spout political nonsense.
Now the same Linux crowd...
No, absolutely not. Just the same dimwits writing for same cheap magazines. They would love it if Microsoft fell, if only to have a chance to write about something else for a change. Why they seem to think their stupid blabbering will help them is beyond me. But this is not some Linux crowd!
Really, Billg is not that important. He's good for amusement. His Linux-bashing pamphlets regularly make for a good laugh, as do his henchmen ("Developers! Developers! Developers!"). That's all. Linux is here to stay, Billg cannot take it away or buy it out, he can only ridicule it (which he certainly tries).
As a Linux user I have no reason to hate Billg. He doesn't get my money and I don't use his software. Simple, isn't it? As a Windows user I'd hate him. I'd have paid for his crap, would have to put up with it, all kinds of creepy things would infest my PC and I'd not even get any warranty in return. To me it seems, it's the Windows crowd who desperately wants the evil empire to fall. They have my wholehearted compassion.
You, on the other hand, are a genuine nuisance. Your rant doesn't add anything of value and makes people you don't even know appear in a bad light. Could you do me a favor and go somewhere quiet to simply die? Thanks a lot.
We could build clean energy supply stations where they will be most effective (say the desert for example) and then contain and ship that energy anywhere using fuel cells.
No, we can't. Fuel cells and electrolysis have finite efficiencies, shipping has it's cost, too. If you envision hydrogen as fuel, purifying and liquefying it doubles its cost in term of energy. If you think of methanol or something, then extracting CO2 from the atmosphere adds to the cost as well.
it would allow for what I believe is the greatest hindrance to this technology, true energy competition.
"There's a huge establishment conspiracy against free energy for everyone!"
If I read correctly, he advocates putting the components of a PC and some networking equipment into a box and then connect the mobile to said box via USB. Hm. How does connecting a PC and mobile make the mobile into a replacement for the PC? Or alternatively, how does that make the PC any easier to use? How is this any different from a PC, a mobile and synchronization software?!
Oh yeah, there's also the rant how a PC's OS is too complicated for his granny. Guess what, Phil, your granny can't use her mobile either. She can barely remember how to punch in a number and then press GREEN to phone and RED to end the call. She will lose her documents in any environment, and being able to lose them either on the PC or the mobile doesn't change the fact that they are still lost.
A more complicated design will not makes things simpler. No matter how many buzzwords you put into it.
Fuel cells heat up a lot during operation. What do you think happens when hydrogen combines with oxygen, in those cells?
No, they don't. In an ideal fuel cell, the chemical energy of hydrogen and oxygen is converted directly into electricity. They can't be 90% efficient and still get hot, can they?
Besides, not even electric motors are more than 90% efficient. There is no free lunch.
*Much* more efficient? 46% isn't really *much* more than ~33% efficiency. Add to that that electrolysing, purifying and liquefying hydrogen cost more than twice as much energy than ends up in the hydrogen itself, remember that the car's electric system won't be more than 90% efficient (I doubt it's even that much) and that a fossil powered car can be heated by waste heat while a fuel cell car has to be heated electrically, and suddenly the fuel cell car is *much* *less* efficient at no more than 20% overall effenciency. Also hydrogen cannot be stored perfectly, it's slowly heating and evaporates and it even creeps *through* metal, which is adding to the losses.
No, even if nuclear power is scaled up massively, hydrogen is a damn stupid storage technology. Synthetic methanol or metallic fuels (boron or zinc) sound much more promising.
You're describing Fresco, formerly Berlin, and Fresco before that and Interviews even further before. Somehow it didn't catch on under any of those names. What a shame.
Who's fighting? All those distros are happily coexisting and synergistically feeding to each other. Don't make it sound as if violence was involved.
./configure;make;make install. Works everytime. Works beautifully in conjunction with stow. And contrary to popular belief a compiler is not a dangerous creature.
Besides, there *is* a de-facto stand to install apllications:
Folks, mind the distinction between Free Software and Open Source Software. Despite ESR's efforts to convince the public that they are the same.
Free Software is all about protecting the freedom of the user.
Open Source Software is about a supposedly superiour development model.
See the difference? Open Source has no ideals. Therefore you cannot "exemplify OS ideals" and you cannot argue about them.
So what about the ideals of Free Software? Well, you are not protecting user's rights if you are tying them even more to a proprietary platform, while a good Free alternative exists. Do whatever you like, but obviously you don't deserve respect from the Free Software community for what you're doing. And please shut up about ideals, you don't have any.
For the uninitiated, KDE is not "free" on the Windows platform, nor is it even LGPL on any platform.
Pure FUD. KDE has always been under the GPL or LGPL. The combination of Qt and KDE could not be distributed in the early days, due to the incompatibility between Qt's license and the GPL.
Since Qt3, KDE+Qt were GPL or LGPL. Completely. This combination didn't run on Windows and nobody cared. Since Qt4, even the Windows version is GPL'd. You may also buy a commercial license for Qt.
This means it is easier and cheaper to write and deploy software for Microsoft Windows than KDE.
No, it isn't. All development tools for KDE are free. It may be cheaper to write and sell software using whatever on Windows instead of Qt. But who cares? If you want to be paid for programming, you have to pay others for their work, too. Deal with it.
haven't even learned not to double-click URLs.
And what's there to learn? If anything, this could be memoized. Your coworkers have learned that to open something, you double-click it. You single-click to select. This is completely accurate -- and then URLs are different all of a sudden. You single-click to open and you cannot select or drag anymore. The inconsistency makes understanding the machine's behaviour needlessly hard, so it's no wonder people give give up early and resort to rote memoization.
Compare this with the Unix command line, an editor like Vim and text processing tools like *roff. What you learned once, stays valid and carries over to most other tools. This isn't "harder to understand", rather it can be understood *at*all*.
1. Installshield supposedly is something else than package management?
/bin and /sbin), you'd bemoan the insufficient integration.
.doc attachments aren't written on notepad, you know?
2. Debian doesn't. Almost. You need to set the basics (language, keyboard layout, desktop/server/custom installation, installation target), everything else is automatic. Even less configuration work, and you'd bitch about how it steamrollered your Windows install you wanted to keep for some reason.
3. Pointless. Were "System" and "Applications" more seperate (whatever the distinction, *I* find a good seperation between
4&5. Linux doesn't. KDE does. Don't use it if you don't like it. Instead, use something completely different, like wmi.
6. All errors *are* reported in plain English (or any of a large number of other natural languages)! Dunno what you're using, I never see "error codes".
7. Have a look at Vim and/or Emacs. You'll like one of them and never want to go back to an Windows-style IDE.
8. They do. OpenOffice is not the only software that runs on Linux (GIMP has already been mentioned).
9(sic!). No, most people use MS Word at home, often a "borrowed" copy. Those emails with
And seriously, your obsession with package management is... disturbing. You can install without package management (configure/make/make install), only deinstallation becomes harder. As soon as new software has to integrate with something (startup script, logfile rotation, class registry, linking documentation) you need to do more than just drop a file into place on installation. Package managers just organize what is needed anyway, and they work well. Dependency tracking is also a great win. It doesn't completely prevent "DLL Hell", but *if* things break, they don't break silently. Have a closer look at dpkg/apt before writing it off as a design error.
You didn't get it, did you? It's not about regexes being *bad*, it's about regexes being *wrong* and by extension insecure, but the *right* solution, context free expressions or something exquivalent, is prohibitively expensive due to the B&D language chosen.
To make code secure, a language that makes Doing The Right Thing easy is needed, not a language that makes doing some specific wrong things hard or impossible. And that is wrong with Java, it doesn't make anything easy, it only eliminates wild pointers from C++. No better abstractions, no improved syntax. No sharp edges to cut yourself (or anything) with, either.
BTW, I don't care much that my pet language wasn't considered. But I *do* find it disturbing that only two (very similar) languages are looked at when there are dozens to choose from. That tells a lot about the sad state of the software industry.
What a shame. You would have been right.
...didn't do half the things a proper XML parser should do...
Oh, are you saying, XML isn't a universal, light-weight format that an average CS student could implement in three weeks, after all? Are you implying that it is rather a bloated, inefficient, underspecified format that nobody could implement completely and correctly, let alone in three weeks, and which is also either unsuitable or overengineered for most tasks?
You're a wise man, dude.
Besides, the name "XML parser" is wrong. A SAX parser is just a lexer, a DOM parser parses an LL(0) grammar, which is trivial. All this should be easier. It probably is, if you use something sane instead of XML.
Nonsense. Some cycles wasted by suboptimal code can never match the magnitude of bloat caused by a single XML parser. The problem isn't that people think at higher abstraction levels, it's rather that people have stopped thinking at all.
Web ads works by having *my* computer request the picture and *my* computer displaying it with the power of *my* cpu. My browser is configured to just not do that.
Therefore, I'm not blocking ads that "come naturally" to my computer, I'm just not helping them to get there in the first place. Advertisers have no right to my computer, and language should reflect this fact.
So to ask the correct question: "Do you browse ads?" -- "No. Why should I?"
You know, there are already some entire nuclear reactors lying on the sea floor. They can't melt, since the water cools them and their radiation doesn't get further than a few meters. Compared to some thousand tonnes of oil they are completely harmless.
In C, it requires almost no thought at all to write insecure code
Well, this is true of any language. Just think of Perl: buffer overflows are impossible, since strings and arrays grow when needed. People still manage to write swaths of code with shell or SQL injection vulnerabilities, despite taint checking. Piling language features onto each other to make a factory for secure programs will always be an uphill battle. What is really needed are competent programmers (which are in pitifully short supply).
Therefore the real question is not whether a language is more secure or if this or that runtime is more likely to contain bugs itself. The only question is: "How much does this language help writing secure code?" but also: "How much does this language help writing correct code in a reasonable amount of time?"
Whenever it is clear how to write code the right way, but it takes herculean effort compared to the Q&D solution (for example: prevent code injection bugs by parsing, interpreting an AST and pretty printing instead of some regexes), it will not be done. Java is unfortunately not of much more help here than C, unless you happen to find a suitable library.
Functional languages are better, but as always, they are not even considered in passing. That was actually my gut reaction to the tag line of the article: "What moron stated the choice was between C and Java only?!"
Except you are wrong. The compiler can optimize zilch here, because:
public double getDistanceFrom(Component other) {
Point otherLocation = other.getLocation();
`other' may be of any subclass of `Component' and therefore may override `getLocation' in any ways it sees fit. The same goes for `otherLocation' if `other' decides to create something of a subclass of `Point'. Particularly, `getLocation' might keep a reference to the newly created `Point', thereby making the cited stack allocation invalid, and it might return a class with more data, making your unfolding invalid. In short, the compiler needs global information (the dynamic type of `other') to optimize anything, and due to seperate compilation and dynamic linking, this information is unavailable in principle.
The JVM may have this information, as the article states, but only when `getDistanceFrom' is actually called. At this point it could either check the dynamic type of `other' and dispatch to a statically optimized version (which is probably useless, considering that in Java nearly everything is expressed in terms of interfaces and not concrete classes) or dynamically inline `getLocation' and then optimize. Stack allocation however is still impossible if anything after `getLocation' is called with `otherLocation' as parameter, unless that too is inlined and (statically!) "escape analyzed". But all this inlining and analysing amount to somewhat more work than a heap allocation. Add to that, that after inlining the code block may be unwieldy large and too complex to analyze, making all this effort completely useless.
In short, all these optimizations may be possible, but always at a cost. The cost may be negligible, but that depends on the application. A micro benchmark is no application. I believe all this propaganda, when I see a Java application that feels fast. I've seen enough that feel sluggish. (Anyone remember Corel Office? Yeah, that was a fast Java application. It disappeared very quickly because of its outrageous demands regarding CPU power and memory.)
BTW, I just love Haskell. Naively programmed it is very elegant, but incurs a performance cost. Yeah, yeah, a sufficently smart compiler could cure cancer and turn lead into gold, blah blah. Bullshit, it's mostly theoretical, exactly as theoretical as the "smart JVM". In reality, fast code is possible, but takes work and is often at odds with elegant code. If the Java advocates only acknowledged that the magic JVM is no silver bullet and that other technologies might have their niches, too, I might even take them seriously.
In Java, the auto garbage collection is as good as Perl's
It's just that Perl doesn't have GC, but shoddy reference counting, which is easily confused by cyclic references. If Java is as "good" as Perl there, that's not the best of advertisements.
So what?!
"Able to be self referential" is different from "indeed self referential", which is again different from "equivalent to a Gödel sentence and therefore undecidable".
Thanks a lot for understanding nothing and throwing buzzwords around.
And still there's nothing more practical than a sound theory, someone else added.
Software development is still an art, and may always be one.
And that would certainly be romantic, wouldn't it?
No company has ever demonstrated a methodology that is guaranteed to deliver high quality, maintainable software in a predictable amount of time.
That is because it's impossible. Every program is new, by construction. You never write a program twice, you reuse and customize the old one. Everything that is new is a bit unpredictable, so the "predictable amount of time" is simply unachievable. That, however, doesn't make software design an "art". A civil engineer likewise cannot predict how long the design of a daring building will take, but he is still an engineer.
Mostly, because he doesn't ship the building until his calculations show that it will support itself. It's that part where software engineers fail.
Godel applies, as always.
But not to the extent many think. Whether it is Gödel or Turing doesn't make much difference, at the core, both theorems say almost the same: Given a arbitrary program or proposition, you cannot decide some of its key properties.
However, you are never given "an arbitrary program". You write it, and as long as you write by some other methodology than randomly punching keys, you have a sketchy proof of how it will work in your head. For these programs, halting is decidable, and all properties can be proved. Gödel has no say in the matter, because no one writes self referential programs.
Truly, philosophers and incompetent programmers made Gödel's Incompleteness Theorem the most abused theorem of all of mathematics.
Is this good or bad?
Neither, it's just ugly.
In principle, every software patent is bad. However, we cannot infer that the company behind the patent is evil, because that's simply the way the game is played. Software patents exists (for you poor americans at least), and if Google doesn't apply for them, someone else does it.
Then again, if they start enforcing their patents or if they start arguing for software patents, then it is bad. Eolas did the former (in the US), which is bad. This is still bad, even though the Evil Empire was on the receiving end. Microsoft did the latter (here in Europe), which is bad, too. And Google? We'll see...
But seen as a whole, it's just an ugly mess.
I've been hearing this very mantra out of the Linux/open source community for years.
No, you haven't. You're confusing the community with journalistic loudmouths. While the loudmouths will claim loads of bullshit of Linux dethroning Windows and what not just to sell more ads, if you ask a programmer, a real member of the community, about Windows, he'll probably reply "Windows? Yeah, it's crap. Don't bother me, I'm coding." Most of the community is invisible. They have better things to do than spout political nonsense.
Now the same Linux crowd...
No, absolutely not. Just the same dimwits writing for same cheap magazines. They would love it if Microsoft fell, if only to have a chance to write about something else for a change. Why they seem to think their stupid blabbering will help them is beyond me. But this is not some Linux crowd!
Really, Billg is not that important. He's good for amusement. His Linux-bashing pamphlets regularly make for a good laugh, as do his henchmen ("Developers! Developers! Developers!"). That's all. Linux is here to stay, Billg cannot take it away or buy it out, he can only ridicule it (which he certainly tries).
As a Linux user I have no reason to hate Billg. He doesn't get my money and I don't use his software. Simple, isn't it? As a Windows user I'd hate him. I'd have paid for his crap, would have to put up with it, all kinds of creepy things would infest my PC and I'd not even get any warranty in return. To me it seems, it's the Windows crowd who desperately wants the evil empire to fall. They have my wholehearted compassion.
You, on the other hand, are a genuine nuisance. Your rant doesn't add anything of value and makes people you don't even know appear in a bad light. Could you do me a favor and go somewhere quiet to simply die? Thanks a lot.
Do you really buy into this web app noise?
Hell, no! They're a crutch compared to X.
We could build clean energy supply stations where they will be most effective (say the desert for example) and then contain and ship that energy anywhere using fuel cells.
No, we can't. Fuel cells and electrolysis have finite efficiencies, shipping has it's cost, too. If you envision hydrogen as fuel, purifying and liquefying it doubles its cost in term of energy. If you think of methanol or something, then extracting CO2 from the atmosphere adds to the cost as well.
it would allow for what I believe is the greatest hindrance to this technology, true energy competition.
"There's a huge establishment conspiracy against free energy for everyone!"
If I read correctly, he advocates putting the components of a PC and some networking equipment into a box and then connect the mobile to said box via USB. Hm. How does connecting a PC and mobile make the mobile into a replacement for the PC? Or alternatively, how does that make the PC any easier to use? How is this any different from a PC, a mobile and synchronization software?!
Oh yeah, there's also the rant how a PC's OS is too complicated for his granny. Guess what, Phil, your granny can't use her mobile either. She can barely remember how to punch in a number and then press GREEN to phone and RED to end the call. She will lose her documents in any environment, and being able to lose them either on the PC or the mobile doesn't change the fact that they are still lost.
A more complicated design will not makes things simpler. No matter how many buzzwords you put into it.