Your point is absolutely valid. On public sites with user supplied information there's never a guarantee for good quality.
Still practically this does not seem to hinder many projects, IMHO for the great social effects in such open environments (believe it, or not). As far as my personal experience goes, for example Wikipedia articles have always been correct and well written.
The same argument could be applied to open source development, where the situation is much the same: a lot of code is contributed to big projects where quality control happens as collaborative mechanism.
IMHO the Wiki concept is a revolution that's not comparable to any other development since the invention of the Web itself by Sir Lee... Think of Wikipedia or the original c2.com wiki, both examples of the success of this idea. These sites are driven by the users themselves, and are able to gather astonishing amounts of high quality information.
The beautiful thing about Wikis is that they scale to any size. I use Wiki for personal information management. My company uses Wiki as a kind of rapid CMS (which effectively replaced Lotus Notes in that function btw), as do the big sites I've mentioned with millions of users.
Some custom extensions can turn Wiki into tech unbeatable by any commercial product - because the concept just works (tm)...
A question that occured to me while reading the article:
Why are C++ compilers normally using string comparison on type checking? The taken approach of pointer comparison seems to be the logic choice in the first place, so I wonder why this is often done the other way.
I remember something about linking and shared libraries, but an obvious problem doesn't come to mind...
You are absolutely correct that the main problems with compiled C++ lie in the current implementations. But this is a pretty theoretical thing to say, as I don't see this getting much better in near future. C++ compilers have only recently reached a level of full standard compliance, and optimization is surely not yet on par with the things possible for C compilers. C++ is a more complicated language which means it is more difficult to optimize for the compiler, and it is probably not ever possible to optimize to a level that can be reached for C or simpler languages.
As an example, Windows has a modified microkernel architecture and is a (non-pure) object oriented operating system, so by design it would be logical to implement this in an object oriented language. Still it is no coincidence that most parts of it are written in assembler and C - you just cannot afford to waste percentages of performance for critical kernel sections because of the choice of language, which is not avoidable either, no matter how well you use C++ or optimize with the compiler. And unfortunately most kernel sections are pretty performance critical...
Btw note that I talk about problems occuring when using the full range of C++ features that make it the beautiful language it is... I ofter hear people talking about C++ matching C performance, but when you look under the hood they are basically using C with some syntactic sugar. This is not of much use, as such designs can be (and are) mostly implemented in C in the same fashion either, as e.g. the object orientism of the Windows kernel I spoke of.
Don't underestimate the pressure of foreign law for international organizations. Think of the problems Yahoo had with selling Nazi artefacts to France on their international site, which they where actually forbidden to do in a court ruling. Although I do absolutely not agree with the idea that web content providers should have to abide to law everywhere on our globe (imagine what this could mean if getting common case), I do understand that this may not only be a matter of "trying to please other governments".
I really hope that Project Gutenberg will win this case (which surely is in it's favor), as they are doing a fantastic thing, both for spreading the very idea of free literature and providing the huge library.
While the concept is the same, the application goes way further than t9. This is where I see such ideas bound to failure.
t9 is a great technology because the vocabulary used writing SMS is pretty narrow. After entering the first few characters of a word, the contextual information in the dictionary is good enough (most of the times) to suggest the wanted word very fast. t9 is even able to dereive this information without the user specifying the exact characters but rather just one of the 3-4 on any mobile key.
As said this is possible because of the small dictionary of probable words and the good contextual information for characters and their position in words.
Extending this tech (or event better methods) to larger domains makes the problem much harder very fast, by my feeling I would even say that increase to be exponential in the mathematical sense.
There may be a small, well defined set of possible mathematical formulaes, if you divide the things into small enough junks. Saying the same about XML documents or even native language text (beyond the character/word level) is imho foolish.
I would like to stress that such technologies are very important and promising to lower the input barriers for disabled people, as they already work in the same sense for anyone on very limited devices (like mobile keyboards). On the other side I don't think such things to change the way most of the people already put information into their computers.
The 5.x branch is not targeted at production use before it's first stable release.
As an other poster already said, the unstable and rc branches contain debugging code that cost performance. Don't let the stability of 5.x fool you into thinking it to be a final system yet. The team did a great job introducing loads of new features, pushing FreeBSD on top of current technology again, but polishing these new features (which actually should bring 5.x to beat 4.x performance wise afterwards) will mainly happen in the end of the release cycle, after all those nasty showstopper bugs have been fixed.
If you really need drivers or features only present in 5.x, you are in an unlucky situation for the next months. Otherwise stay with 4.10, the fastest ia32 desktop operating system in existance...
The future will bring us 4.11 with selected feature backports of 5.x and 4.x lightning speed, and soon afterwards a 5.x that will rock the CPUs like current stable branch does...:)
The study sheds light into a little studied phenomenon, and therefor shows interesting facts. It shows that the difference between black-hat-discovery and white-hat-discovery basically reduces to the number of exploits between discovery and public disclosure of a bug, which is negible compared to the total number of exploits during the lifecycle of a bug.
That may hold true and make sense if you study the total number of exploitable systems on the net, but totally ignores the fact that there are a very large number of systems with little priority for security while only a few depend on 100% system security.
Those few high security sites have the need and pay for resources to fix known flaws or patch their software asap. It are those who gain from the knowledge of a security flaw before the black-hat guys do. They cannot live with even the shortest vulnerability timeframes and usually patch exploits as soon as they get published on public security channels.
It may hold true that the work put into security auditing does not pay out on whole, taking all software users into account, but for those few who really care about security it surely does...
openoffice is neither assimilated by gnome or part of it. there still is gnome office consisting of gnumeric, abiword and co...
if openoffice gets installed instead that's ok. it integrates into gnome, where's the problem? (besides some ui inconsistencies which are to be corrected)
this case is not about microsoft employees violating human right, its a matter of microsoft doing business with people who massively abuse human rights, whenever possible.
there is a difference between mr communist downloading software from my homepage and abusing it, or me earning big cash from mr communist because i sell him software which knowing exactly what he is doing.
would you do business with terrorists threatening your own people? no - why then do business with terrorists threatening other people?
i know that a comparison of the technological state of these two desktops is difficult. but let me try to explain why i think it's actually gnome that's leading the field...
the fundemantal difference between the kde and gnome crowd is the development style. there are two kinds of open source developers: the 'depth first'- and the 'breadth first' people.
kde surely falls into the second category. whenever someone arguments for kde it's the same point: feature richness. (compare kde vs. gnome to emacs vs. vi;).
gnome, on the other hand, can be seen in the 'depth first' camp. it's progressing more slowly because a lot of things get tweaked and fixed before developers move on to much requested new features.
you can have a look at the base libraries too, it's the same developing wise: qt has always been more rich than gtk, and also felt nicer to work with... but please have a look at how the qt (programming) interface developed since 1.0, and then compare an early libgtk to libgtk--. latter is now one of the most powerful toolkits available, even if i'd still consider it unfinished. qt has everything you can think of, but unfortunately people at trolltech seem to ignore recent c++ features, still relying on moc to patch language problems which are long gone...
have a look at kde vs. gnome two years ago. bad game for gnome. have a look at both now. gnome catched up huge!
just extrapolate with a little fantasy: in another two years there will be kde 4.0, the everything but a kitchen sink (tm) desktop manager, and gnome 4.0, if still lacking one or the other bleeding edge feature, a mature, polished software bundle...
this is where the true advantage of gnome over kde is. it's ui guidelines make sense and are used and direct manipulation and consistency are guaranteed everywhere.
besides osx the only really user friendly interface is gnome - and its developing fast.;)
i am not trying to be a troll, but isn't it pretty naive to think that there might be finally showing up brain cells in the patent office?
we hear stupid patents getting approved every other day, and now they play the ball into microsofts hands...
it's just another issue of economics forcing a governmental body to it's will... the patent system, already killing the small business in favour of the big 0wner, will widen the gap even more.
the advantages rfid's as a new tech holds led to a widespread distribution in the last years. your 2-3 years time frame may hold true.
unfortunately rfid's pose a great deal of problems concerning surveillance possibilities. currently it is easy to track your reading habits. soon it will be easy to track your shopping habits.
now connect item level cloth tracking (you personally get uniquely identifieable at every rfid reader) with all the other things you could carry around which hold an rfid...
you will be running around like a radio station broadcasting all your personal habits. orwell is greeting...
there has been an interesting talk at 20c3, the chaos communication congress about this topic. transcript available on homepage...
the parent poster is absolutely correct... there are applications where the source code analog af a real world problem can be more expressively written if different cases are enforced.
to be able to differentiate macros/template parameters/any syntactic special cases is nice too.
i do mostly c++ development and only write lower case code. that excludes only macros and templates, both which are processed before the actual compilation by a pre-processor. this allows me to quickly catch the 'meta' programming snippets which are prone to errors and conceptually on a different level of programming. all usual code is nicely formatted with color by my editor, so adding case to it just makes it more difficult to read...
my proposal: get strict, enforce lower case in languages! btw, have i already mentioned that i support dropping case in any language?:)
when you are speaking about gnome having catched up to kde, you should not forget the backend.
while the original gtk+ core is c code, which gives good performance but makes developing bigger apps painful, the now really mature gtk-- library is a modern c++ toolkit. it does not depend on language extensions and preprocessors like moc, but rather uses modern c++ language features and programming techniques to fulfill the same requirements.
that's why i think gnome is the better desktop from a programming point of view, and that just because of this will continue to develop faster than kde (as it did in the recent time).
reinventing the wheel is never the best choice. it's far more efficient to improve existing wheels... khtml may still be superiour to gecko in terms of footprint, but gecko is part of a massive project with much support and is constantly improving, with or without gnome. resources can be used better than rewriting existing code...
KDE is not a non-cooperating group riddled with NIH.
that's not what i've talked about. still i think that gnome focuses on widespread compatibility, more so than kde does.
corba is a widely accepted
standard for developing distributed componenents, which include desktop components. a lot of developers that know and use corba can easily adapt to orbit.
same goes for the signal/slot design. i appreciate the way the qt c++ extension integrate into the language, but why develop another preprocessor when there are macros and templates? that adds a dependency to the qt tools (i.e. moc).
by the way, that is exactly what icaza's mono project is about - language independent = maximum compatibility. i like that general focus in the gnome project.
you are right that the c code base of gnome might influence decisions where kde c++ code would be more difficult to incooperate into existing software.
but this is just one reason. the kde crew generally ignores widely accepted standards for reasons of quality (just see orbit vs. dcop, gtk signals vs. qt c++ extensions,...). these people like to look innovative...:) that they mainly distribute as huge monolithic packages doesn't help either. what many users dislike about gnome, it's dozens of lib dependencies is a holy grail of (often) lightweight service providers for every developer.
this is not a gnome vs. kde rant, i rather want to point out that while kde provides (imho) an easier development model it suffers the former 'mozilla' disease - be everything at once to keep things simple. gnome, on the other hand, follows the unix tradition of maximum flexibility and inter-operatibility - which may sometimes make things a little bit more difficult to understand, but pay out in the long run.
it's a sad thing that everyone seems to be so confident in their latest super secure linux setup, the power of fast and often patched open source software or the openess in such issues - so much that nobody takes these problems serious enough.
for every exploit known (and fixed) publically you can bet there are two yet undisclosed and maybe in the hands of the wrong people...
concepts like public key crypto (ssh, ssl), stack guarding (say no to buffer overflows) or process jail (try to escalate privileges from there) are thus essential to implement real security. still ease of setup or performance seems to be more important than safe networking.
perhaps the big desaster has to happen before people understand that projects like openbsd or selinux are not your tinfoil-hat wearing neighbor's business but the only serious choice for any public, responsible service provider.
You are right, this quantum teleportation allows the transfer of particle states over distance. This is not about transporting matter. This will not allow us to build teleporters.
Further information and links at the
research group from Austria that ran the first experimental verification of quantum teleportation.
Google's approach is novel; make the web pages rank themselves. If more people link to your site, it's probably a better site. If few enough people link to it, it probably isn't and besides that it'll probably never be found.
Web site creators have to do the legwork to get their sites recognized, and going to a general search engine to do it isn't the way. If someone makes a site and tells their friends about it, and their friends like it and link to it, it'll get picked up; that's the way of the web. (At least, it'll get picked up by crawlers like Google, and even ranked highly if enough people link to it).
I agree with you that this approach makes Google a useful search engine to get good hits about a specific topic.
The problem that many people oversee is, there are many great, informative web pages about topics that just don't draw enough attention to get linked very often. Advanced scientific sites, seldom occuring computer issues and the like don't get linked because there are not many people interested in that kind of stuff...
The same with mailing list archives. I guess that most software issues have already been discussed and solved, and answers wait to be read in the archives, but then try finding the solution to "extra seldom compilation problem X on quite popular program Y with special system configuration Z"
As soon as your search involves popular keywords your result gets overranked thousands of often-linked results about the wrong stuff. (And no, there is not always that "great" combination of keywords to reduce results to
I love Google as anyone else does, but it surely has its limitations...
Slashdot Mirror
Your point is absolutely valid. On public sites with user supplied information there's never a guarantee for good quality.
:)
Still practically this does not seem to hinder many projects, IMHO for the great social effects in such open environments (believe it, or not). As far as my personal experience goes, for example Wikipedia articles have always been correct and well written.
The same argument could be applied to open source development, where the situation is much the same: a lot of code is contributed to big projects where quality control happens as collaborative mechanism.
So...Reality proves different.
IMHO the Wiki concept is a revolution that's not comparable to any other development since the invention of the Web itself by Sir Lee... Think of Wikipedia or the original c2.com wiki, both examples of the success of this idea. These sites are driven by the users themselves, and are able to gather astonishing amounts of high quality information.
The beautiful thing about Wikis is that they scale to any size. I use Wiki for personal information management. My company uses Wiki as a kind of rapid CMS (which effectively replaced Lotus Notes in that function btw), as do the big sites I've mentioned with millions of users.
Some custom extensions can turn Wiki into tech unbeatable by any commercial product - because the concept just works (tm)...
A question that occured to me while reading the article:
Why are C++ compilers normally using string comparison on type checking? The taken approach of pointer comparison seems to be the logic choice in the first place, so I wonder why this is often done the other way.
I remember something about linking and shared libraries, but an obvious problem doesn't come to mind...
You are absolutely correct that the main problems with compiled C++ lie in the current implementations. But this is a pretty theoretical thing to say, as I don't see this getting much better in near future. C++ compilers have only recently reached a level of full standard compliance, and optimization is surely not yet on par with the things possible for C compilers. C++ is a more complicated language which means it is more difficult to optimize for the compiler, and it is probably not ever possible to optimize to a level that can be reached for C or simpler languages.
As an example, Windows has a modified microkernel architecture and is a (non-pure) object oriented operating system, so by design it would be logical to implement this in an object oriented language. Still it is no coincidence that most parts of it are written in assembler and C - you just cannot afford to waste percentages of performance for critical kernel sections because of the choice of language, which is not avoidable either, no matter how well you use C++ or optimize with the compiler. And unfortunately most kernel sections are pretty performance critical...
Btw note that I talk about problems occuring when using the full range of C++ features that make it the beautiful language it is... I ofter hear people talking about C++ matching C performance, but when you look under the hood they are basically using C with some syntactic sugar. This is not of much use, as such designs can be (and are) mostly implemented in C in the same fashion either, as e.g. the object orientism of the Windows kernel I spoke of.
Don't underestimate the pressure of foreign law for international organizations. Think of the problems Yahoo had with selling Nazi artefacts to France on their international site, which they where actually forbidden to do in a court ruling. Although I do absolutely not agree with the idea that web content providers should have to abide to law everywhere on our globe (imagine what this could mean if getting common case), I do understand that this may not only be a matter of "trying to please other governments".
I really hope that Project Gutenberg will win this case (which surely is in it's favor), as they are doing a fantastic thing, both for spreading the very idea of free literature and providing the huge library.
While the concept is the same, the application goes way further than t9. This is where I see such ideas bound to failure.
t9 is a great technology because the vocabulary used writing SMS is pretty narrow. After entering the first few characters of a word, the contextual information in the dictionary is good enough (most of the times) to suggest the wanted word very fast. t9 is even able to dereive this information without the user specifying the exact characters but rather just one of the 3-4 on any mobile key.
As said this is possible because of the small dictionary of probable words and the good contextual information for characters and their position in words.
Extending this tech (or event better methods) to larger domains makes the problem much harder very fast, by my feeling I would even say that increase to be exponential in the mathematical sense.
There may be a small, well defined set of possible mathematical formulaes, if you divide the things into small enough junks. Saying the same about XML documents or even native language text (beyond the character/word level) is imho foolish.
I would like to stress that such technologies are very important and promising to lower the input barriers for disabled people, as they already work in the same sense for anyone on very limited devices (like mobile keyboards). On the other side I don't think such things to change the way most of the people already put information into their computers.
The 5.x branch is not targeted at production use before it's first stable release.
:)
As an other poster already said, the unstable and rc branches contain debugging code that cost performance. Don't let the stability of 5.x fool you into thinking it to be a final system yet. The team did a great job introducing loads of new features, pushing FreeBSD on top of current technology again, but polishing these new features (which actually should bring 5.x to beat 4.x performance wise afterwards) will mainly happen in the end of the release cycle, after all those nasty showstopper bugs have been fixed.
If you really need drivers or features only present in 5.x, you are in an unlucky situation for the next months.
Otherwise stay with 4.10, the fastest ia32 desktop operating system in existance...
The future will bring us 4.11 with selected feature backports of 5.x and 4.x lightning speed, and soon afterwards a 5.x that will rock the CPUs like current stable branch does...
No need to be hasty, younglings...
The study sheds light into a little studied phenomenon, and therefor shows interesting facts. It shows that the difference between black-hat-discovery and white-hat-discovery basically reduces to the number of exploits between discovery and public disclosure of a bug, which is negible compared to the total number of exploits during the lifecycle of a bug.
That may hold true and make sense if you study the total number of exploitable systems on the net, but totally ignores the fact that there are a very large number of systems with little priority for security while only a few depend on 100% system security.
Those few high security sites have the need and pay for resources to fix known flaws or patch their software asap. It are those who gain from the knowledge of a security flaw before the black-hat guys do. They cannot live with even the shortest vulnerability timeframes and usually patch exploits as soon as they get published on public security channels.
It may hold true that the work put into security auditing does not pay out on whole, taking all software users into account, but for those few who really care about security it surely does...
openoffice is neither assimilated by gnome or part of it. there still is
gnome office consisting of gnumeric, abiword and co...
if openoffice gets installed instead that's ok. it integrates into gnome, where's the problem? (besides some ui inconsistencies which are to be corrected)
*ouch* :)
you're right, something went wrong way back on the road that such a 'project' can delay for years(!).
imo still just one negative exception in an otherwise fast progressing project.
*smacks gtk developers on their heads*
"get up you lazy bunch - where is our file selector?"
this case is not about microsoft employees violating human right, its a matter of microsoft doing business with people who massively abuse human rights, whenever possible.
there is a difference between mr communist downloading software from my homepage and abusing it, or me earning big cash from mr communist because i sell him software which knowing exactly what he is doing.
would you do business with terrorists threatening your own people? no - why then do business with terrorists threatening other people?
i know that a comparison of the technological state of these two desktops is difficult. but let me try to explain why i think it's actually gnome that's leading the field...
;).
:)
the fundemantal difference between the kde and gnome crowd is the development style. there are two kinds of open source developers: the 'depth first'- and the 'breadth first' people.
kde surely falls into the second category. whenever someone arguments for kde it's the same point: feature richness. (compare kde vs. gnome to emacs vs. vi
gnome, on the other hand, can be seen in the 'depth first' camp. it's progressing more slowly because a lot of things get tweaked and fixed before developers move on to much requested new features.
you can have a look at the base libraries too, it's the same developing wise: qt has always been more rich than gtk, and also felt nicer to work with... but please have a look at how the qt (programming) interface developed since 1.0, and then compare an early libgtk to libgtk--. latter is now one of the most powerful toolkits available, even if i'd still consider it unfinished. qt has everything you can think of,
but unfortunately people at trolltech seem to ignore recent c++ features, still relying on moc to patch language problems which are long gone...
have a look at kde vs. gnome two years ago. bad game for gnome.
have a look at both now. gnome catched up huge!
just extrapolate with a little fantasy: in another two years there will be kde 4.0, the everything but a kitchen sink (tm) desktop manager, and gnome 4.0, if still lacking one or the other bleeding edge feature, a mature, polished software bundle...
that's my prophecy: see it coming true...
this is where the true advantage of gnome over kde is. it's ui guidelines make sense and are used and direct manipulation and consistency are guaranteed everywhere.
;)
besides osx the only really user friendly interface is gnome - and its developing fast.
don't forget all those updates and patches that are added after installing from an (probably safe) cd...
as long as there is no wide ranging crypto tech working in software distribution, talking about security is nonsense.
i am not trying to be a troll, but isn't it pretty naive to think that there might be finally showing up brain cells in the patent office?
we hear stupid patents getting approved every other day, and now they play the ball into microsofts hands...
it's just another issue of economics forcing a governmental body to it's will... the patent system, already killing the small business in favour of the big 0wner, will widen the gap even more.
the advantages rfid's as a new tech holds led to a widespread distribution in the last years. your 2-3 years time frame may hold true.
unfortunately rfid's pose a great deal of problems concerning surveillance possibilities. currently it is easy to track your reading habits. soon it will be easy to track your shopping habits.
now connect item level cloth tracking (you personally get uniquely identifieable at every rfid reader) with all the other things you could carry around which hold an rfid...
you will be running around like a radio station broadcasting all your personal habits. orwell is greeting...
there has been an interesting talk at 20c3, the
chaos communication congress about this topic. transcript available on homepage...
the parent poster is absolutely correct... there are applications where the source code analog af a real world problem can be more expressively written if different cases are enforced.
:)
to be able to differentiate macros/template parameters/any syntactic special cases is nice too.
i do mostly c++ development and only write lower case code. that excludes only macros and templates, both which are processed before the actual compilation by a pre-processor. this allows me to quickly catch the 'meta' programming snippets which are prone to errors and conceptually on a different level of programming. all usual code is nicely formatted with color by my editor, so adding case to it just makes it more difficult to read...
my proposal: get strict, enforce lower case in languages! btw, have i already mentioned that i support dropping case in any language?
when you are speaking about gnome having catched up to kde, you should not forget the backend.
while the original gtk+ core is c code, which gives good performance but makes developing bigger apps painful, the now really mature gtk-- library is a modern c++ toolkit. it does not depend on language extensions and preprocessors like moc, but rather uses modern c++ language features and programming techniques to fulfill the same requirements.
that's why i think gnome is the better desktop from a programming point of view, and that just because of this will continue to develop faster than kde (as it did in the recent time).
reinventing the wheel is never the best choice. it's far more efficient to improve existing wheels... khtml may still be superiour to gecko in terms of footprint, but gecko is part of a massive project with much support and is constantly improving, with or without gnome. resources can be used better than rewriting existing code...
that's not what i've talked about. still i think that gnome focuses on widespread compatibility, more so than kde does.
corba is a widely accepted standard for developing distributed componenents, which include desktop components. a lot of developers that know and use corba can easily adapt to orbit.
same goes for the signal/slot design. i appreciate the way the qt c++ extension integrate into the language, but why develop another preprocessor when there are macros and templates? that adds a dependency to the qt tools (i.e. moc).
by the way, that is exactly what icaza's mono project is about - language independent = maximum compatibility. i like that general focus in the gnome project.
you are right that the c code base of gnome might influence decisions where kde c++ code would be more difficult to incooperate into existing software.
...). these people like to look innovative... :) that they mainly distribute as huge monolithic packages doesn't help either. what many users dislike about gnome, it's dozens of lib dependencies is a holy grail of (often) lightweight service providers for every developer.
but this is just one reason. the kde crew generally ignores widely accepted standards for reasons of quality (just see orbit vs. dcop, gtk signals vs. qt c++ extensions,
this is not a gnome vs. kde rant, i rather want to point out that while kde provides (imho) an easier development model it suffers the former 'mozilla' disease - be everything at once to keep things simple. gnome, on the other hand, follows the unix tradition of maximum flexibility and inter-operatibility - which may sometimes make things a little bit more difficult to understand, but pay out in the long run.
it's a sad thing that everyone seems to be so confident in their latest super secure linux setup, the power of fast and often patched open source software or the openess in such issues - so much that nobody takes these problems serious enough.
for every exploit known (and fixed) publically you can bet there are two yet undisclosed and maybe in the hands of the wrong people...
concepts like public key crypto (ssh, ssl), stack guarding (say no to buffer overflows) or process jail (try to escalate privileges from there) are thus essential to implement real security. still ease of setup or performance seems to be more important than safe networking.
perhaps the big desaster has to happen before people understand that projects like openbsd or selinux are not your tinfoil-hat wearing neighbor's business but the only serious choice for any public, responsible service provider.
...
Further information and links at the research group from Austria that ran the first experimental verification of quantum teleportation.
I agree with you that this approach makes Google a useful search engine to get good hits about a specific topic.
The problem that many people oversee is, there are many great, informative web pages about topics that just don't draw enough attention to get linked very often. Advanced scientific sites, seldom occuring computer issues and the like don't get linked because there are not many people interested in that kind of stuff...
The same with mailing list archives. I guess that most software issues have already been discussed and solved, and answers wait to be read in the archives, but then try finding the solution to "extra seldom compilation problem X on quite popular program Y with special system configuration Z"
As soon as your search involves popular keywords your result gets overranked thousands of often-linked results about the wrong stuff. (And no, there is not always that "great" combination of keywords to reduce results to I love Google as anyone else does, but it surely has its limitations...