HN user

Shooti

1,154 karma
Posts10
Comments137
View on HN

The difference is ChatGPT Pro/Plus plans have one shared pool of token limits shared across all use cases.

In contrast Google's AI plans give you at least three seperate pools of token usage limits: Gemini App + Antigravity/Other Code Assist tools like Android Studio + AI Studio free usage limits.

Google limit the context of where you can use their tokens but in exchange they give you substantially more.

o changes are being made to the .tflite file extension or format. Conversion tools will continue to output .tflite flatbuffer files, and .tflite files will be readable by LiteRT.

Odd choice since it strongly undermines the stated purpose of the rebrand in the first place: to break it away from the Tensorflow brand and emphasise it being model/framework agnostic. Working with ".tflite" files more or less immortalises what they're trying to get away from.

Would've made more sense to bite the bullet and launch with a ".litert" format which is identical to ".tflite", but continue to work with the later. That would remove the conceptual integrity issue without breaking any compatibility.

They'll probably continue to co-exist: Flutter is a Declarative UI product by the Dart team, Jetpack Compose is a Declarative UI product by the Android org. Google has no problem having multiple competing products by different orgs unless one org manages to absorb the other.

Dart has survived this long so that doesn't seem on the cards.

There is/was no such thing as an assistant called "Google Now". That was an illusion/poor branding.

There's "Voice Search", typing into the Google search box with your voice.

VS Assistant, a Google's chatbot interface.

The Dropcam Team 10 years ago

No HomeKit integration, of course, now that Google has purchased them.

Probably completely unrelated since Nest doesn't even support Google's Brillo/Weave. They're going forward with their own "Nest Weave" which despite the name is a completely separate platform/ecosystem from Google's stuff.

Wouldn't be surprised if Homekit support is actually on the cards but it's stuck in their super slow release cycle.

I don't get it... Google clearly has more than enough in house talent to get those things right. Why aren't they? Why don't they seem to care?

I think it's because "Google" aren't involved at all. Google has it's own approach to IOT called Brillo/Weave that they're focused on. Nest is doing its own isolated thing.

Old Way: Two separate concepts called the same thing. Google+ (Unified profile/account/sharing system across services) and Google+ (Social network).

This backfired because what people made the natural inference that the purpose of the former was to force use of the later when the opposite was what Google was aiming for. The purpose of the social network was to promote the unified login, but instead it poisoned the well.

New way: Concept of a "Google+ account" has been folded into the main Google Account as a new cross-service "About Me" account https://aboutme.google.com/ . Google+ (Social Network) is now just a client of the former, so the G+ website is shedding all the features related to its old dual system integrator role.

That's what I can make out, anyway.

We also use personal information to help us create, develop, operate, deliver, and improve our products, services, content and advertising, and for loss prevention and anti-fraud purposes.

We may also use personal information for internal purposes such as auditing, data analysis, and research to improve Apple’s products, services, and customer communications.

https://www.apple.com/legal/privacy/en-ww/

No time limit specified = No time limit

They already do according to the Google Wallet FAQ:

"Google Wallet stores your credit and debit cards on secure servers and encrypts your payment information with industry-standard SSL (secure socket layer) technology. Your full credit and debit card information is never shown in the app and won't be shared with the merchant. In addition, access to Google Wallet is protected by password or PIN. We also recommend locking your phone with a passcode for additional security."

"Your actual credit card number is not stored. Only the Google Wallet Virtual Card is stored, and Android's native access policies prevent malicious applications from obtaining the data. Even if the data is compromised, Wallet uses dynamically rotating credentials that change with each transaction and are usable for a single payment only. Finally, all transactions are monitored in real-time with Google’s risk and fraud detection systems."

https://www.google.com/wallet/faq.html#tab=faq-security

Keep in mind "Tokenization" has existed in the NFC industry for years, the only thing which changed last year is that the EMV standards body agreed and released a standardized way to do it in March 2014. Apple Pay is a branded solution over that.

So what it really boils down to is whether or not you take Google's word for it that their independent solution is secure. If not, you owe it to yourself to not be using a Google Android phone in the first place.

Chrome Sidebar API 11 years ago

I think the title to this should've been something more descriptive like "Google willing to accept Chrome Sidebar API patches" as that seems to be the main reason it was reopened.

Is Google Maps really that better than OpenStreetMap or Apple Maps or Bing Maps, or do people just use it because it's a default result in Google?

I think its more nuanced: In-line maps are a better search result to location queries than a plain blue link, but to some degree the only way to offer that UX is to control that functionality from the ground up. Explicit integration comes with reliability/speed/technical costs while implicit integration comes with fair use/scraping costs.

While search boosts the integrated properties (Maps, News, Finance etc) much of the value to Google may actually be the reverse: integrated verticals give people less reason to switch away from Google's generalized Search to more specialized, domain-specific search engine.

There's an argument to be made that there's utility in a Jack-of-all trades engine.

More wood behind arrows or not they could at least update the black bar so Scholar could be pinned to the users App Launcher. And no reason for it to still have the old Google Logo.

It doesn't have to feel abandoned just because its niche.

Nexus Player 12 years ago

I think the difference is Google TV was built by the Youtube division, Android TV was built by the Android division.

I think it's the reverse: the main purpose of G+ was to integrate all the services together, being a Facebook competitor was just the icing. The integration wasn't a means, it was the end itself.

They haven't really lost since they still got what they needed out of it in the end: the majority of accounts have a unified profile across services, even though G+ the site is unused.

Not sure you can draw such a hard line between audio/video since all the rumors point to this subscription service essentially being both:

http://www.androidpolice.com/2013/11/27/apk-teardown-youtube...

i.e. By enabling the Android/iOS Youtube app to background (which they've gone out of their way to disable up until this point), it essentially becomes an audio streaming service with the same interface.

Plus according to the FT, the problem the indie labels have isn't with the subscription rate per se, its how the new ad tier is set up:

"One label boss said the big problem with YouTube’s new licensing agreement was not to do with the paid tier, but rather that it allowed YouTube to make substantial enhancements to its free tier. His fear is that YouTube’s free tier will become so attractive that it will reduce the number of people willing to pay for subscription services such as Spotify or Deezer."

Plausible breakdown of Google/YT's side of the story:

1. Youtube wants to offer users a subscription service with no ads.

2. Youtube needs to update its licensing/terms with artists: If a video plays for a subscriber they see no ads, artist gets money from subscription pool. If a video plays for a non-subscriber they see ads, artist gets money from ads pool.

3. Artists need to explicitly agree to these terms because it changes how and how much they'll get paid.

4. It doesn't seem fair for a user to pay a subscription, expect to see no ads, and then see ads for some video's because that artist/distributor did not agree to new terms. This is why Google wants all or nothing.

Surface Pro 3 12 years ago

'Courier was much more than a clever vision. The team, which had more than 130 Microsoft employees contributing to it, had created several prototypes that gave a clear sense about the type of experience users would get. There were still tough hardware and software issues to resolve when Microsoft pulled the plug. But an employee who worked on Courier said the project was far enough along that the remaining work could have been completed in months if the company had added more people to the team. "There was extensive work done on the business, the technology and the experience," said a member of the Courier team. "It was very complete, not a whim."'

http://www.cnet.com/uk/news/the-inside-story-of-how-microsof...

Actually it doesn't. You don't need a G+ Profile to connect a Youtube channel to a G+ Page.

That's the crux of the whole problem, G+ is so heavily associated with being a social network connected to real identity that having it manage the profile system is untenable.

I think, in the end, the reason it got banned was down to some clause in their terms of use that required them to use web technology in their implementation, which would have horribly crippled the app, and was not particularly feasible to implement in any reasonable amount of time. Not because Microsoft refused to display ads.

There are already public APIs for building a full fledged Youtube client:

Youtube Data: https://developers.google.com/youtube/v3/ Youtube Playback: https://developers.google.com/youtube/iframe_api_reference

The issue was that Windows Phone 7 & 8 webview didnt support inline video playback, so they couldn't use the public playback API so were asking for access to Google's private APIs. Google declined

This has been rectified in Windows Phone 8.1: http://www.wpcentral.com/windows-phone-81-improved-youtube-e...

So they can now use the public API to build their client.