Lucene has the same abilities as FAST and is a lot more efficient , its used by most of the ediscovery vendors and its free in it base format
yes you will have to do some work on the interface and other support areas but its the solution to MS ditching Linux support for search
You clearly know less, or assume more, than you think you do.
Lucene is a great search engine. But neither it nor its commercial add-ons can touch what FAST can do in its entirety. When you have hundreds of millions of document to search, tens of millions of those documents to update throughout a single day, a requirement to deliver any single updated document within minutes of the update to an end user, and keep it all running 7x24, you don't want to use Lucene.
Sure, you could "do some work on the interface and other support areas" and make it work. Eventually. I could probably write something much faster myself, in hand-coded assembler. But I, like a lot of other people out there, have better things to do with my time.
Face it: Every news outlet filters and edits, so what you see or hear is at the very least a subset of the reported item. Even if a news outlet just regurgitates a syndicated column or wire report, someone did the original filtering and editing.
Every journalist spin a story a different way. Whether to sensationalize it, make it fit a more conservative or liberal viewpoint, or even just to make a printed story fit into a certain column length or a video fit into a certain time segment. We never hear the whole story from a single news outlet.
What I want is an aggregation of viewpoints. For a given issue, I want to read the just-the-facts story, the liberal newspaper's story, and the version that appeared in Hey, I'm a Wacko, Too monthly. Ideally, some magical technology will gather all those different versions and sift the contents, remove the duplicated stuff (even opinions!), then present me with a single chunk of news to digest. Properly annotated, of course, so I know which news outlet reported what. Even Fox News' stuff could be included, for hilarity if nothing else.
To be truly informed about the "important issue" I would need to see all the angles. I can do what I described above myself, manually, but it takes so much time that I usually don't bother unless the issue is truly important to me. So yes, I want my "personalized news" and I think it would better than what I see now.
Scientists addressed the problem over the summer of 2009, and concluded that the energy used in networks could be reduced by a factor of up to 10,000 without breaking fundamental laws such as the Shannon Limit, but it would require a fundamental rethink to achieve a massive reduction, said [Gee Rittenhouse, vice president and head of research at Bell Labs]: "Today's networks are optimised for performance and simplicity".
...
The technology produced would be commercially viable and would naturally replace existing networks, as it will be backwards compatible, [consortium] members assured the audience.
Emphasis mine. There's a lot more crap in there that I didn't bother copying and pasting.
This "announcement" reads a lot like a snake-oil advertisement. This consortium will likely produce only one thing: An efficient mechanism for extracting money from investors (government or otherwise).
... 97% of today's coders don't have any idea what they've missed out on and just accept what they've got....
My apologies for snipping such a large portion of your reply, but that one sentence from your post nicely sums up so many of the problems with new coders it deserves calling out.
Disclaimer: I'm an old fart when it comes to programming. I admit it. I like bare metal programming, high-performance applications with minimal footprint, and elegant solutions to non-trivial problems. I don't avoid kernel-level threads; they're a useful tool.
The company I work for has hired a large number of programmers over the last year in order to replace a number of aging systems. I've interviewed a lot of these people, and I've worked with most of the ones that have we've hired on various parts of the overall project. The newer programmers know quite a lot about available frameworks and their general capabilities. They've been taught the 80/20 rule early on, and they embraced it: When faced with a new task, these people find something that already exists and set about modifying it. All that is fine for applications that are of a certain size. A size that, apparently, is about the size of school projects and therefore succeeds admirably when graded.
So what I've seen coming through the door are people who can put Lego blocks together. They're used to that type of problem solving. They've been taught to download 80% of the solution, then "fix it" so it also does the other 20%. This type of problem solving works well when you're building Lego-block-shaped solutions. That fails to happen much of the time, however. Most real-world solutions -- you know, the kind that are complex enough that someone is willing to pay an actual salary to solve -- don't look like a collection of Lego blocks. The amount of custom code grows and grows as more and more Lego blocks are added. Interoperability problems between the Lego blocks start encompassing the majority of coding effort. The overall system gains complexity at an alarming rate. Things start to suck, both from the programmer's perspective as well as from a systems perspective.
The bad part of this, and to bring things back to my original point, is that these newer programmers expect it to be that way. What's worse, at least from my point of view, is that this entire mentality has been around long enough for these programmers to stop coding and start managing other programmers. So now we have people who build things that suck, and managers who expect it to suck. Expectations are lowered and, unfortunately, met.
Google and Apple seem unafraid to break this cycle, albeit in different ways. So hope is not entirely lost. Maybe that's the 3% you alluded to in your original post.
... in a presentation from the 30th Workshop on Gravitation and Numerical Relativity at Jungwon University. It's a PDF version of a PowerPoint deck, so it's not exactly easy to read.
I wonder how much of this is due to lack of app discoverability? The Android Marketplace website is pretty much useless, and who wants to use their phone for shopping? I know the techies might love that you can download Android apps off the web and install them on memory cards, but the rest of society doesn't think this way. They want an Android version of iTunes to sync their phone with music, video, photos and apps. That's why the App Store for the iPhone works. That's also why Napster was so popular, despite the availability of free MP3s elsewhere like IRC and newsgroups.
Apple's App Store is better than the competitions' but it still has a ways to go. The biggest problem, I think, is that the App Store is really a distribution mechanism, not a marketing tool, but everyone believes it to be one. The App Store was a marketing tool when it was shiny and new and there were few applications. The tiny tools Apple provided the customer (Top 25 Free and Paid categories, limited searching, etc.) actually worked, and developers used them to garner more downloads. But now, with 100K applications, thousands of developers and millions of customers, those tiny tools just don't scale.
What iPhone users need -- what all smartphone users need, really -- are sites dedicated to marketing mobile applications. Central distribution of the apps in one corner and marketing in another. Separate, but linked. A single marketing site could cater to iPhone and Android apps both, and Blackberry, too. Track sales, provide feedback, the whole thing. Customers could actually find what they need, developers deal with marketing tools actually designed for the job, and whoever is hosting the apps could just concentrate on keeping their infrastructure alive.
One Iteration Planning Meeting (minimum four hours in duration)
One Integration Planning Meeting, to schedule changes with all other changes (minimum three hours in duration)
Twenty Stand-up Meetings (two per day for ten days) so everyone can tell each other why they're behind on the planned changes
Two scheduled Backlog Meetings to reschedule the planned changes that won't make it into this iteration
Six presentations to the Senior Management Team of at least one hour each to communicate our effective Change Management Strategy
At least three Tag-Up Meetings, called spontaneously, because some people still just don't get it, originally scheduled for 30 minutes each but extended to 60 minutes because exactly one person in the room wanted to argue
One Retrospective Meeting, which no one wants to attend because they're already behind on the backlog tasks
By observing a program's normal behavior and assigning a set of rules, ClearView detects certain types of errors, particularly those caused when an attacker injects malicious input into a program. When something goes wrong, ClearView detects the anomaly and identifies the rules that have been violated. It then comes up with several potential patches designed to force the software to follow the violated rules. (The patches are applied directly to the binary, bypassing the source code.) ClearView analyzes these possibilities to decide which are most likely to work, then installs the top candidates and tests their effectiveness. If additional rules are violated, or if a patch causes the system to crash, ClearView rejects it and tries another.
So, when ClearView finds something wrong it magics up a patch, using some analysis based on previous execution path behavior or something (waves hand dismissively), then installs the patch directly into the application code.
Maybe I'm just oversimplifying things, but what about just taking a snapshot of the application and replacing the whole thing, shotgun-style, from read-only media when the binary changes unexpectedly? Wouldn't that be a hell of a lot simpler? A Perl-based daemon wielding the mighty md5 utility could do that in, what, 100 lines of code and comments?
Those that simply have to stay connected to others at all times in order to feel validated and important will love Google Wave. Right there in front of you is evidence that people are connected to you! In real time! Better than texting! It's so amazingly interactive! It's like... like... a telephone!
To clarify, SideWiki requires the Google Toolbar, which itself requires IE6 (or later) or Firefox 2 (or later).
The headline on Google's Get Google Sidewiki page reads, "Contribute helpful information to any web page." Yet this is being released to the general public, which is the same group that is responsible for most of the crap already on the internet. SideWiki should probably be renamed to Creeping Crud (hello, Wizardry fans) to more accurately describe the end result. But hey, you have to run SideWiki in order to see other SideWiki users' crud, so I guess it's a closed universe and therefore okay.
Grand Central Dispatch (GCD) is a revolutionary approach to multicore computing that is woven throughout the fabric of Mac OS X version 10.6 Snow Leopard. GCD combines an easy-to-use programming model with highly-efficient system services to radically simplify the code needed to make best use of multiple processors. The technologies in GCD improve the performance, efficiency, and responsiveness of Snow Leopard out of the box, and will deliver even greater benefits as more developers adopt them.
libdispatch is the open source implementation of GCD.
Want to work in a business environment? That means that sales is king. You may support sales, you may even support your customers, but driving business through the door is the most privileged role. Those customers won't, for the most part, want an arrogant prick who's always right; they'll want an accommodating, amiable fellow who's right more than half the time.
You're absolutely correct that sales is king. No dispute, there. A business has to have income in order to survive.
What I do think is wrong, however, is that management oftentimes downplays or ignores IT's recommendations in an effort to chase the short-term sale. As the original article pointed out, "IT Pros" typically don't make recommendations that are without merit. A business that sells an IT-based product (for instance) should listen closely to the people creating that product, but that doesn't seem to happen often enough. A development or architecture team will lay out an optimal plan for producing a product, but the business side will force everyone down a different path in order to meet arbitrary release dates, please one big customer, or meet some goal sitting on a vice-president's last review. The final product winds up being something no one is happy with, and that causes problems down the road for everyone.
So no, a narrow focus on technical solutions is not the right way to go about things. But neither is chasing potential income while eroding your technical base.
IT pros are sensitive to logic -- that's what you pay them for. When things don't add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event.
If only I could get my current manager to understand that. Perhaps then he'd understand why our department reacts the way it does to policies handed down from the parent organization.
I thought the article was basically ego-stroking but at the same time, most of it was spot-on. Why is it that so many writers understand this stuff, while so many IT management organizations do not?
... They were never taught how to work hard to learn, how to challenge themselves....
That statement struck a chord with me, in my experience as a parent.
My own son, who is now a sophomore in college, was "gifted." By that, I mean that he is intelligent, he found schoolwork to be extremely easy for many years, and he seemed to have talents in certain areas "beyond his years." He coasted through school, found it extremely boring and filled with (what he perceived to be) dummies at both ends of the classroom.
The thing is, he eventually ran into school material that he could not immediately understand. At that point, after so many years of coasting, he had no idea how to go about solving this new problem of his. It took him years to figure out how to really work at that kind of stuff. He did, and along the way he realized that he wasn't quite as bright as he thought he was.
I've seen other kids follow the same path, but sometimes with different results. Some do what my son managed to do -- figure it out and learn from it -- while others seemed to just give up and focus on the things that they can do well without effort. Some of the kids in that latter group will succeed, but a lot of them will wind up disappointed with their lives down the road. The stuff that happens to you is rarely just what you want or like, and you have to deal with it. The former group will deal with it, but the latter group will consistently either turn to help, ignore the problem or run away.
All generalizations are bad, I know. I'm just making a point.
From a technology viewpoint, we -- the tech leaders of the world, from whatever country -- seem to be focused on iterative improvements more than anything else.
Following the money trail, this almost certainly goes back to the people holding the purse strings and their (relatively) myopic, short-term desire to bet only on a sure thing. Game-changing technology isn't researched and brought into production because the monetary risk is too high for the short term. The focus is simply on "shipping" incremental improvements to existing tech sooner to keep the money flowing and the budget guys happy.
This is pretty sad, for several reasons. Sticking to an always-incremental approach trains people to accept that approach as normal. Minor improvements are lauded as fantastic innovations. Thinking "outside the box" falls by the wayside and is considered radical. Only goals that can be met in the short term are actually set. And "the bar" drops lower and lower.
I know full well that there is some excellent research and science going on around the world, and it's contributing to our general knowledge every day. That's fantastic. What we need, however, is more innovating applications of that technology.
... created the new material by mixing salmon DNA with two types of dye, then pumping the solution from a fine needle while a voltage is applied between the needle tip and a grounded copper plate covered with a glass slide. As the liquid jet comes out, it dries and forms long nanofibers that are deposited on the glass slide as a mat. The researchers then spin this nanofiber mat directly on the surface of an ultraviolet LED to make a white-light emitter.
I did this by accident once, while trying to make breakfast.
Really? Am I the only person that found it interesting that Lucene, the only non C/C++ implementation, gave some pretty impressive stats? I mean, it's written in Java and although it has a slower index time its search time, index size and relevancy are impressive.
Lucene is a great search tool. As TFA pointed out, however, if you're looking for a "search solution" rather than "search engine" then you should check out Solr instead. Lucene is a toolkit that you build on top of, not something you really want to deploy by itself. Solr is that thing built on top of Lucene.
Be aware that while Lucene/Solr has made terrific progress, it is not quite in the "enterprise search" category. For superscale implementations you'll still likely need to look at a high-priced product like FAST.
Microsoft purchased FAST Search and Transfer last year (here is a 'welcome page' for existing FAST customers). I had assumed that Bing is a specific implementation of the FAST technology, but I could very well be wrong. But if I'm right, then Sergey Brin doesn't have a whole lot of homework to do.
The article states that this finding was the result of a study where a few hundred drives (300+) were purchased from various places and then scanned.
A spokesman for BT said they found 34 per cent of the hard disks scrutinised contained 'information of either personal data that could be identified to an individual or commercial data identifying a company or organisation.'
Later:
For a very large proportion of the disks we looked at we found enough information to expose both individuals and companies to a range of potential crimes such as fraud, blackmail and identity theft.
Where are the corresponding crimes? If a third of the used hard drives on the market really contain such detailed personal or business information, wouldn't you think that at least one group of criminals would be buying as many of these drives as possible? Granted that there would be capital outlay, but a lot of that is recovered by selling the drives again through the vary same channels, and the risk of getting caught would be extremely low. Quantity of information is lower than with network-based methods (eg, keyloggers, sniffers, etc.) or other information-gathering methods, but I would think the quality of the gathered data would be much, much higher. Good enough to resell for a relatively high amount.
It seems, to me, that there is a bit of hyperbole going on here.
... I am starting to prefer using my Ubuntu "Jaunty Jackalope" desktop over the similarly slick Windows 7 beta (which I am currently running full-time on one desktop) and Mac OS X Leopard operating systems, which I also use regularly.
Ubuntu 9.0.4 might have the slickest interface on the planet, but comparing it to Windows 7 beta is hardly a recommendation. Kind of the opposite, for some people.
At the risk of being flamed as a troll and getting modded to hell, I'd like to point out that F5's response is exactly the same kind of thing one hears when comparing special-purpose (or custom-written) software to the integration of COTS applications, libraries or frameworks. Sure, with the latter option you get something that works, eventually, but at what cost to maintainability and performance?
I say this after coming out of a meeting where a large Rube Goldberg system of Java tools was presented as the best solution to a high-volume ETL problem that has particular performance and distribution requirements. The resemblance is uncanny.
I'm all for not reinventing the wheel, but if that's what is required, then just do it.
And even if you're still willing to pay extra-- sometimes a lot extra -- for cool -- that diaphanous,
ephemeral quality -- the coolness gap will largely evaporate this year when Windows 7 is introduced.
Already Windows 7 is showing itself to be a far more worthy competitor for Mac OS X than Vista was.
In beta now, speculation is that Windows 7 may release to market in early summer, perhaps soon
enough to ship on machines by back-to-school season and certainly by holiday. At that point, the
Apple premium will come into greater focus.
There are so many things to pick at Kay's article, but that one point is a decent representative example. "Apple has done something we haven't been able to duplicate yet, but we think we've got it this time. Really! Not like last time, not at all."
Slashdot Mirror
Lucene has the same abilities as FAST and is a lot more efficient , its used by most of the ediscovery vendors and its free in it base format yes you will have to do some work on the interface and other support areas but its the solution to MS ditching Linux support for search
You clearly know less, or assume more, than you think you do.
Lucene is a great search engine. But neither it nor its commercial add-ons can touch what FAST can do in its entirety. When you have hundreds of millions of document to search, tens of millions of those documents to update throughout a single day, a requirement to deliver any single updated document within minutes of the update to an end user, and keep it all running 7x24, you don't want to use Lucene.
Sure, you could "do some work on the interface and other support areas" and make it work. Eventually. I could probably write something much faster myself, in hand-coded assembler. But I, like a lot of other people out there, have better things to do with my time.
Face it: Every news outlet filters and edits, so what you see or hear is at the very least a subset of the reported item. Even if a news outlet just regurgitates a syndicated column or wire report, someone did the original filtering and editing.
Every journalist spin a story a different way. Whether to sensationalize it, make it fit a more conservative or liberal viewpoint, or even just to make a printed story fit into a certain column length or a video fit into a certain time segment. We never hear the whole story from a single news outlet.
What I want is an aggregation of viewpoints. For a given issue, I want to read the just-the-facts story, the liberal newspaper's story, and the version that appeared in Hey, I'm a Wacko, Too monthly. Ideally, some magical technology will gather all those different versions and sift the contents, remove the duplicated stuff (even opinions!), then present me with a single chunk of news to digest. Properly annotated, of course, so I know which news outlet reported what. Even Fox News' stuff could be included, for hilarity if nothing else.
To be truly informed about the "important issue" I would need to see all the angles. I can do what I described above myself, manually, but it takes so much time that I usually don't bother unless the issue is truly important to me. So yes, I want my "personalized news" and I think it would better than what I see now.
Emphasis mine. There's a lot more crap in there that I didn't bother copying and pasting.
This "announcement" reads a lot like a snake-oil advertisement. This consortium will likely produce only one thing: An efficient mechanism for extracting money from investors (government or otherwise).
... 97% of today's coders don't have any idea what they've missed out on and just accept what they've got. ...
My apologies for snipping such a large portion of your reply, but that one sentence from your post nicely sums up so many of the problems with new coders it deserves calling out.
Disclaimer: I'm an old fart when it comes to programming. I admit it. I like bare metal programming, high-performance applications with minimal footprint, and elegant solutions to non-trivial problems. I don't avoid kernel-level threads; they're a useful tool.
The company I work for has hired a large number of programmers over the last year in order to replace a number of aging systems. I've interviewed a lot of these people, and I've worked with most of the ones that have we've hired on various parts of the overall project. The newer programmers know quite a lot about available frameworks and their general capabilities. They've been taught the 80/20 rule early on, and they embraced it: When faced with a new task, these people find something that already exists and set about modifying it. All that is fine for applications that are of a certain size. A size that, apparently, is about the size of school projects and therefore succeeds admirably when graded.
So what I've seen coming through the door are people who can put Lego blocks together. They're used to that type of problem solving. They've been taught to download 80% of the solution, then "fix it" so it also does the other 20%. This type of problem solving works well when you're building Lego-block-shaped solutions. That fails to happen much of the time, however. Most real-world solutions -- you know, the kind that are complex enough that someone is willing to pay an actual salary to solve -- don't look like a collection of Lego blocks. The amount of custom code grows and grows as more and more Lego blocks are added. Interoperability problems between the Lego blocks start encompassing the majority of coding effort. The overall system gains complexity at an alarming rate. Things start to suck, both from the programmer's perspective as well as from a systems perspective.
The bad part of this, and to bring things back to my original point, is that these newer programmers expect it to be that way. What's worse, at least from my point of view, is that this entire mentality has been around long enough for these programmers to stop coding and start managing other programmers. So now we have people who build things that suck, and managers who expect it to suck. Expectations are lowered and, unfortunately, met.
Google and Apple seem unafraid to break this cycle, albeit in different ways. So hope is not entirely lost. Maybe that's the 3% you alluded to in your original post.
... until they plugged the ansatz into the Horava’s action to produce the reduced Lagrangian.
Huh. I didn't get that far. And I'm pretty sure that whatever it that is, it's illegal in Texas.
... in a presentation from the 30th Workshop on Gravitation and Numerical Relativity at Jungwon University. It's a PDF version of a PowerPoint deck, so it's not exactly easy to read.
I wonder how much of this is due to lack of app discoverability? The Android Marketplace website is pretty much useless, and who wants to use their phone for shopping? I know the techies might love that you can download Android apps off the web and install them on memory cards, but the rest of society doesn't think this way. They want an Android version of iTunes to sync their phone with music, video, photos and apps. That's why the App Store for the iPhone works. That's also why Napster was so popular, despite the availability of free MP3s elsewhere like IRC and newsgroups.
Apple's App Store is better than the competitions' but it still has a ways to go. The biggest problem, I think, is that the App Store is really a distribution mechanism, not a marketing tool, but everyone believes it to be one. The App Store was a marketing tool when it was shiny and new and there were few applications. The tiny tools Apple provided the customer (Top 25 Free and Paid categories, limited searching, etc.) actually worked, and developers used them to garner more downloads. But now, with 100K applications, thousands of developers and millions of customers, those tiny tools just don't scale.
What iPhone users need -- what all smartphone users need, really -- are sites dedicated to marketing mobile applications. Central distribution of the apps in one corner and marketing in another. Separate, but linked. A single marketing site could cater to iPhone and Android apps both, and Blackberry, too. Track sales, provide feedback, the whole thing. Customers could actually find what they need, developers deal with marketing tools actually designed for the job, and whoever is hosting the apps could just concentrate on keeping their infrastructure alive.
So, when ClearView finds something wrong it magics up a patch, using some analysis based on previous execution path behavior or something (waves hand dismissively), then installs the patch directly into the application code.
Maybe I'm just oversimplifying things, but what about just taking a snapshot of the application and replacing the whole thing, shotgun-style, from read-only media when the binary changes unexpectedly? Wouldn't that be a hell of a lot simpler? A Perl-based daemon wielding the mighty md5 utility could do that in, what, 100 lines of code and comments?
Those that simply have to stay connected to others at all times in order to feel validated and important will love Google Wave. Right there in front of you is evidence that people are connected to you! In real time! Better than texting! It's so amazingly interactive! It's like... like... a telephone!
To clarify, SideWiki requires the Google Toolbar, which itself requires IE6 (or later) or Firefox 2 (or later).
The headline on Google's Get Google Sidewiki page reads, "Contribute helpful information to any web page." Yet this is being released to the general public, which is the same group that is responsible for most of the crap already on the internet. SideWiki should probably be renamed to Creeping Crud (hello, Wizardry fans) to more accurately describe the end result. But hey, you have to run SideWiki in order to see other SideWiki users' crud, so I guess it's a closed universe and therefore okay.
Habitual Multitaskers Do It Badly.
Dumbass.
From the first paragraph:
Grand Central Dispatch (GCD) is a revolutionary approach to multicore computing that is woven throughout the fabric of Mac OS X version 10.6 Snow Leopard. GCD combines an easy-to-use programming model with highly-efficient system services to radically simplify the code needed to make best use of multiple processors. The technologies in GCD improve the performance, efficiency, and responsiveness of Snow Leopard out of the box, and will deliver even greater benefits as more developers adopt them.
libdispatch is the open source implementation of GCD.
Want to work in a business environment? That means that sales is king. You may support sales, you may even support your customers, but driving business through the door is the most privileged role. Those customers won't, for the most part, want an arrogant prick who's always right; they'll want an accommodating, amiable fellow who's right more than half the time.
You're absolutely correct that sales is king. No dispute, there. A business has to have income in order to survive.
What I do think is wrong, however, is that management oftentimes downplays or ignores IT's recommendations in an effort to chase the short-term sale. As the original article pointed out, "IT Pros" typically don't make recommendations that are without merit. A business that sells an IT-based product (for instance) should listen closely to the people creating that product, but that doesn't seem to happen often enough. A development or architecture team will lay out an optimal plan for producing a product, but the business side will force everyone down a different path in order to meet arbitrary release dates, please one big customer, or meet some goal sitting on a vice-president's last review. The final product winds up being something no one is happy with, and that causes problems down the road for everyone.
So no, a narrow focus on technical solutions is not the right way to go about things. But neither is chasing potential income while eroding your technical base.
IT pros are sensitive to logic -- that's what you pay them for. When things don't add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event.
If only I could get my current manager to understand that. Perhaps then he'd understand why our department reacts the way it does to policies handed down from the parent organization.
I thought the article was basically ego-stroking but at the same time, most of it was spot-on. Why is it that so many writers understand this stuff, while so many IT management organizations do not?
... They were never taught how to work hard to learn, how to challenge themselves....
That statement struck a chord with me, in my experience as a parent.
My own son, who is now a sophomore in college, was "gifted." By that, I mean that he is intelligent, he found schoolwork to be extremely easy for many years, and he seemed to have talents in certain areas "beyond his years." He coasted through school, found it extremely boring and filled with (what he perceived to be) dummies at both ends of the classroom.
The thing is, he eventually ran into school material that he could not immediately understand. At that point, after so many years of coasting, he had no idea how to go about solving this new problem of his. It took him years to figure out how to really work at that kind of stuff. He did, and along the way he realized that he wasn't quite as bright as he thought he was.
I've seen other kids follow the same path, but sometimes with different results. Some do what my son managed to do -- figure it out and learn from it -- while others seemed to just give up and focus on the things that they can do well without effort. Some of the kids in that latter group will succeed, but a lot of them will wind up disappointed with their lives down the road. The stuff that happens to you is rarely just what you want or like, and you have to deal with it. The former group will deal with it, but the latter group will consistently either turn to help, ignore the problem or run away.
All generalizations are bad, I know. I'm just making a point.
From a technology viewpoint, we -- the tech leaders of the world, from whatever country -- seem to be focused on iterative improvements more than anything else.
Following the money trail, this almost certainly goes back to the people holding the purse strings and their (relatively) myopic, short-term desire to bet only on a sure thing. Game-changing technology isn't researched and brought into production because the monetary risk is too high for the short term. The focus is simply on "shipping" incremental improvements to existing tech sooner to keep the money flowing and the budget guys happy.
This is pretty sad, for several reasons. Sticking to an always-incremental approach trains people to accept that approach as normal. Minor improvements are lauded as fantastic innovations. Thinking "outside the box" falls by the wayside and is considered radical. Only goals that can be met in the short term are actually set. And "the bar" drops lower and lower.
I know full well that there is some excellent research and science going on around the world, and it's contributing to our general knowledge every day. That's fantastic. What we need, however, is more innovating applications of that technology.
[citation needed]
I did this by accident once, while trying to make breakfast.
Really? Am I the only person that found it interesting that Lucene, the only non C/C++ implementation, gave some pretty impressive stats? I mean, it's written in Java and although it has a slower index time its search time, index size and relevancy are impressive.
Lucene is a great search tool. As TFA pointed out, however, if you're looking for a "search solution" rather than "search engine" then you should check out Solr instead. Lucene is a toolkit that you build on top of, not something you really want to deploy by itself. Solr is that thing built on top of Lucene.
Be aware that while Lucene/Solr has made terrific progress, it is not quite in the "enterprise search" category. For superscale implementations you'll still likely need to look at a high-priced product like FAST.
Microsoft purchased FAST Search and Transfer last year (here is a 'welcome page' for existing FAST customers). I had assumed that Bing is a specific implementation of the FAST technology, but I could very well be wrong. But if I'm right, then Sergey Brin doesn't have a whole lot of homework to do.
Later:
Where are the corresponding crimes? If a third of the used hard drives on the market really contain such detailed personal or business information, wouldn't you think that at least one group of criminals would be buying as many of these drives as possible? Granted that there would be capital outlay, but a lot of that is recovered by selling the drives again through the vary same channels, and the risk of getting caught would be extremely low. Quantity of information is lower than with network-based methods (eg, keyloggers, sniffers, etc.) or other information-gathering methods, but I would think the quality of the gathered data would be much, much higher. Good enough to resell for a relatively high amount.
It seems, to me, that there is a bit of hyperbole going on here.
Ubuntu 9.0.4 might have the slickest interface on the planet, but comparing it to Windows 7 beta is hardly a recommendation. Kind of the opposite, for some people.
At the risk of being flamed as a troll and getting modded to hell, I'd like to point out that F5's response is exactly the same kind of thing one hears when comparing special-purpose (or custom-written) software to the integration of COTS applications, libraries or frameworks. Sure, with the latter option you get something that works, eventually, but at what cost to maintainability and performance?
I say this after coming out of a meeting where a large Rube Goldberg system of Java tools was presented as the best solution to a high-volume ETL problem that has particular performance and distribution requirements. The resemblance is uncanny.
I'm all for not reinventing the wheel, but if that's what is required, then just do it.
There are so many things to pick at Kay's article, but that one point is a decent representative example. "Apple has done something we haven't been able to duplicate yet, but we think we've got it this time. Really! Not like last time, not at all."