Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The next Google

dkb.io

Post reply on HN
Print view View original

291–300 of 561 posts

Re: The next Google

#291

Post by simion314 »

notriddle wrote: post #230
simion314 wrote: post #131

Earlier quoted context omitted.

>I don't know where this persistent myth comes from that people love choice and tinkering, because they clearly don't. People want to accomplish stuff, this means they need tools to do stuff and if a tool can be customized to do the stuff faster or better people want the customization. At my job we have paying users that requests features that indeed are work related(not moving shit around). I know GNOME-minded peopl…

The biggest problem with GNOME, and with Mozilla, and with almost everyone who's commenting on their choices, is that all of them are shuffling deck chairs around on the Titanic. The Titanic didn't sink because of the arrangement of deck chairs, and Mozilla didn't sink because of any features they did or didn't provide (and GNOME didn't fail to achieve significant market share in the first place because of features e…

The issue in open source is with projects with not a strong leader ship , then you get some wanna be designer copying Apple because they read some book and now he thinks that shit needs to look and feel different. Then you have developers that want to work on new cool stuff and not maintain existing code, so every few years you get a full reset but because of inexperience or incompetence the new version is buggy for a few years, it gets fixed but then the developers are bored and want to rewrite it using some new ideas/tech.

What would work IMO is someone with money paying the developers and the designer but force them do do customer support, you don't play with the new shit until most tickets are resolved and customers waiting for response are satisfied. maybe a paid support would help too.

Re: The next Google

#292

Post by richardsocher »

Ennea wrote: post #257
richardsocher wrote: post #240

Earlier quoted context omitted.

We found similar issues at https://you.com a while back. We just had to be good for more query families. Now we have both the walmart locations in a map app, eg https://you.com/search?q=walmart and coding related useful results, eg. https://you.com/search?q=how%20do%20I%20find%20all%20files%2... or https://you.com/search?q=pyspark%20filter%20array%20element

Too bad you.com does not work in Firefox with the "beacon" function disabled (beacon.enabled set to false in about:config).

Hi Ennea, Can you help me understand why you make this particular change in the config?

Re: The next Google

#293

Post by nojs »

marginalia_nu wrote: post #231
sdoering wrote: post #204

Earlier quoted context omitted.

> Get rid of that noise and your hardware goes a lot longer. What qualifies? What defines signal, what noise? I agree, that a lot (probably nearly all) pages will receive very, very little traffic/search requests. But are these therefore not relevant? > I'm running a search engine on consumer hardware out of my living room that can index 100 million documents. That's extremely cool. I would love to know more. To me a…

I think I was editing the comment while you were replying. Sorry about that. I was just adding to it though, didn't really rug pull on your response so I think it's fine. > What qualifies? What defines signal, what noise? I agree, that a lot (probably nearly all) pages will receive very, very little traffic/search requests. But are these therefore not relevant? Now this is a proper difficult problem with (probably) f…

> Building a search engine index is not something Java is at all suitable for

Worth pointing out that Lucene/Solr, the biggest open source player, is also Java!

Re: The next Google

#294

Post by amelius »

educaysean wrote: post #105
davidkunz wrote: post #9

> The next Google can’t just be an input box that spits out links. An input box that spits out links is _exactly_ what I want.

Your answer reminded me of the Ford quote: "If I had asked people what they wanted, they would have said faster horses." I don't mean that in a derogatory sense, I just strongly believe that in 20 years we'll look back at our Googling years and wonder how we managed to find anything at all. Who know what the next pattern of information retrieval will be, but I personally think it'll be an even bigger jump than the ju…

Faster horses could have been better for the planet than cars.

https://horses.extension.org/what-is-the-carbon-footprint-of...

> The digestive process of horses produces far less methane than the digestive system of cattle and sheep. (...)

Re: The next Google

#296

Post by marginalia_nu »

nojs wrote: post #293
marginalia_nu wrote: post #231

Earlier quoted context omitted.

I think I was editing the comment while you were replying. Sorry about that. I was just adding to it though, didn't really rug pull on your response so I think it's fine. > What qualifies? What defines signal, what noise? I agree, that a lot (probably nearly all) pages will receive very, very little traffic/search requests. But are these therefore not relevant? Now this is a proper difficult problem with (probably) f…

> Building a search engine index is not something Java is at all suitable for Worth pointing out that Lucene/Solr, the biggest open source player, is also Java!

This is some of the nonsense you are dealing with implementing a search index in Java:

* You can only allocate on-heap arrays of 2 billion items.

* On-heap arrays have a massive size overhead in terms of GC book-keeping.

* You can only allocate off-heap memory map 2 Gb at a time.

* This also goes for memory mapped areas.

* You have no control over the lifecycle of mapped memory and off-heap memory. They get cleared if and when the GC feels like it.

* You have no madvise capabilities

* The language barely acknowledges unsigned types

Re: The next Google

#297

Post by darinf »

jsnell wrote: post #140
darinf wrote: post #73

Earlier quoted context omitted.

Actually, you are spot on. One simple feature of the Neeva app is that it shows inline search results as you type into the URL bar. This is because we aren't trying to show you ads, so we don't need you to visit the search results page (where Google and others show you those ads). We just show you the results straight away in the suggest experience. Now, this isn't going to show you everything you care about and you…

But that is exactly how Google searches worked on desktop platforms for more than half a decade (Instant Search), not some kind of a new idea. Given how long they kept that feature on, it seems pretty obvious that it can't have been the kind of revenue killer you suggest. If you can serve and display search results for a given possibly partial query, you can obviously serve ads too.

I was talking about mobile. As for desktop, Instant Search was serving up full page results instantly, which included ads. That's a different thing altogether, and of course, in the case of Instant Search there was plenty of room for both sponsored results as well as real results. On mobile there isn't.

Re: The next Google

#298

Post by darinf »

twobitshifter wrote: post #284
darinf wrote: post #81

Earlier quoted context omitted.

Actually, just taking the ads out of the experience can make for a simpler and better search experience. I think the google founders knew this too ( https://www.reddit.com/r/degoogle/comments/rzr2n3/the_founde... ). They just couldn't hold back the avalanche of revenue that search ads yields. I work for Neeva, and this is a big part of why I left Google to join Neeva. There has to be a better experience, and it doesn…

To be fair to Google, they do have the I’m feeling lucky button, which will take you directly to Amazon (example from the article) rather than showing you links.

Exactly. Notice how "I'm feeling lucky" is only on the home page and not part of the search experience when using Chrome or any modern browser where you search from the URL bar? Wonder if that is intention? Not a wonder at all.

The "I'm feeling lucky" button would never be added to Google if it didn't already exist. It was grandfathered in.

Re: The next Google

#299

Post by MuffinFlavored »

I don't think displaying data in different fashions is enough to come even remotely close to dethroning Google. It's their data, how much of it they have, and the algorithm that sits in between the search input box and the delivering you results that makes them the best.

Re: The next Google

#300

Post by jfoster »

mostlysimilar wrote: post #74
Barrin92 wrote: post #45

I think 'more customization' which is a theme with a lot of these alternatives is a fundamental dead end. I don't know where this persistent myth comes from that people love choice and tinkering, because they clearly don't. There's a huge cost associated with having to make choices, and one feature of successful modern apps is that they're frictionless. That's why TikTok is so successful. There's no login, no user ch…

> a simple box where you put a question in and it gives you answers Google is very good at this, but this is exactly what I _don't_ want in the "Next Google". I want a _search engine_ for the web, not an answers engine that tries to know what I want better than I do. Search the web. Give me links to websites. This seems obvious to me, but everyone is trying to be like Google. I'm convinced the death of the web and in…

Google used to be this. It was great back then.

The "we answer your question" thing could be useful, but:

1. It should be in addition to (not instead of) the web search results.

2. The answers can't be wrong. Google often gives such a low quality answer that I no longer want to use it for this, besides asking about the weather and sunset/sunrise.

Post reply on HN