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

Google shifts goo.gl policy: Inactive links deactivated, active links preserved

blog.google

Post reply on HN
Print view View original

131–140 of 194 posts

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#131

Post by x0x0 »

franga2000 wrote: post #77
jerlam wrote: post #70

Earlier quoted context omitted.

Goo.gl didn't have customers, it had users. Customers pay , either with money or their personal data, now or the future. Goo.gl did not make any money or have a plan to do so in the future.

The monetary value of the goodwill and mindshare generated by such a free service is hard to calculate, but definitely significant. I wouldn't be surprised if it was more than it costs to run.

And also the ongoing demonstration of why you should never trust Google.

"Here's a permanent (*) link".

[*] Definitions of permanent may vary wildly.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#132

Post by kmeisthax »

neilv wrote: post #42

"Actively used" criteria scrods that critical old document you found, in which someone trusted it was safe to use a Google link. Not knowing all the details motivating this surprising decision, from the outside, I'd expect this to be an easy "Don't Be Evil" call: "If we don't want to make new links, we can stop taking them (with advance warning, for any automation clients). But we mustn't throw away this information…

> Oddly, maybe even with less effort than shutting it down would take.

Google has a number of internal processes that effectively make it impossible to run legacy code without an engineering team just to integrate breaking upstream API changes, of which there are many. Imagine Google as an OS, and every few years you need to upgrade from, say, Google 8 to Google 9, and there's zero API or ABI stability so you have to rewrite every app built on Google. Everyone is on an upgrade treadmill. And you can't decide not to get on that treadmill either because everything built at Google is expected to launch at scale on Google's shitty[0]-ass infrastructure.

[0] In the same sense that Intel's EDA tools were absolutely fantastic when they made them and are holding the company back now

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#133

Post by dundarious »

xp84 wrote: post #93
dundarious wrote: post #87

Earlier quoted context omitted.

In this little story, what's the difference if the direct ACME URL was used? What does the goo.gl indirection have to do with anything?

Goo.gl was a terrible idea in the first place because it lends Google's apparent legitimacy (in the eyes of the average "noob") to unmoderated content that could be malicious. That's probably why they at least stopped allowing new ones to be made. By allowing old ones, they can't rule out the Google brand being used to scam and phish. e.g. Imagine SMS or email saying "We've received your request to delete your Google…

This reputational risk argument makes sense. The post I was replying to seemed to be making a flawed argument about capabilities.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#134

Post by drc500free »

pimlottc wrote: post #102
troupo wrote: post #80

Earlier quoted context omitted.

> How did they think the links were being used? Can't dig this document up right now, but in their Chrome dev process they say something along these lines: "even if a ferie is used by 0.01% of users, at scale that's a lot of users . Don't remove until you've made solely due impost is negligible". At Google scale I'm surprised [1] this is not applied everywhere. [1] Well, not that surprised

A “ferie”?

It makes solely due impost.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#135

Post by hackernudes »

Polizeiposaune wrote: post #130
simonw wrote: post #92

Earlier quoted context omitted.

"How much of a burden could this really be?" My understanding from conversations I've seen about Google Reader is that the problem with Google is that every few years they have a new wave of infrastructure, which necessitates upgrading a bunch of things about all of their products. I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previ…

My understanding is that (at least at one point) binaries older than about six months were not allowed to run in production. But APIs are "evolving" irregularly so the longer you go between builds the more likely something is going to break. You really need a continuous build going to stay on top of it. Best analogy I can think of is log-rolling (as in the lumberjack competition).

Google is famously a monorepo and is basically the gold standard of CI/CD.

What does happen is APIs are constantly upgraded and rewritten and deprecated. Eventually projects using the deprecated APIs need to be upgraded or dropped. I don't really understand why developers LOVE to deprecate shit that has users but it's a fact of life.

Second hand info about Google only so take it with a grain of salt.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#136

Post by aspenmayer »

mixdup wrote: post #95
aspenmayer wrote: post #60

Earlier quoted context omitted.

Capital inputs are one part of the equation. The human cost of mental and contextual overhead cannot be reduced to dollars and cents.

Sure it can. It takes X people Y hours a day/month/week to perform tasks, including planning and digging up the context behind, related to this service. Those X people make Z dollars per year. It's an extremely simple math equation

Emotional labor doesn’t show up on a balance sheet.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#137

Post by saagarjha »

cogman10 wrote: post #67
Aurornis wrote: post #41

Earlier quoted context omitted.

The Google URL shortener stopped accepting new links around 2018. It has been deprecated for a long time. I doubt it was a cost-driven decision on the basis of running the servers. My guess would be that it was a security and maintenance burden that nobody wanted. They also might have wanted to use the domain for something else.

How much of a burden could this really be? The nature of something like this is that the cost to run it naturally goes down over time. Old links get clicked less so the hardware costs would be basically nothing. As for the actual software security, it's a URL shortener. They could rewrite the entire thing in almost no time with just a single dev. Especially since it's strictly hosting static links at this point. It p…

I assume the general problem is people using these links for bad purposes and having to deal with needing to moderate them.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#138

Post by fragmede »

mbac32768 wrote: post #124
chrisjj wrote: post #114

Earlier quoted context omitted.

> I guess that might be things like some new version of BigTable or whatever coming along, so you need to migrate everything from the previous versions. Arrival of new does not neccessitate migration. Only departure of old does.

They deprecate internal infrastructure stuff zealously and tell teams they need to be off of such and such by this date. But it's worse than that because they'll bring up whole new datacenters without ever bringing the deprecated service up, and they also retire datacenters with some regularity. So if you run a service that depends on deprecated services you could quickly find yourself in a situation where you have t…

> If you were an engineer would you want to be assigned this project?

If you're high flying, trying to be the next Urs or Jeff Dean or Ian Goodfellow, you wouldn't, but I'm sure there's are many thousands of people who are able to do the job that would just love to work for Google and collect a paycheck on a $150k/yr job and do that for the rest of their lives.

Re: Google shifts goo.gl policy: Inactive links deactivated, active links preserved

#139

Post by zdragnar »

hackernudes wrote: post #135
Polizeiposaune wrote: post #130

Earlier quoted context omitted.

My understanding is that (at least at one point) binaries older than about six months were not allowed to run in production. But APIs are "evolving" irregularly so the longer you go between builds the more likely something is going to break. You really need a continuous build going to stay on top of it. Best analogy I can think of is log-rolling (as in the lumberjack competition).

Google is famously a monorepo and is basically the gold standard of CI/CD. What does happen is APIs are constantly upgraded and rewritten and deprecated. Eventually projects using the deprecated APIs need to be upgraded or dropped. I don't really understand why developers LOVE to deprecate shit that has users but it's a fact of life. Second hand info about Google only so take it with a grain of salt.

Simple: you don't get promoted for maintaining legacy stuff. You do get promoted for providing something new that people adopt.

As such, developing a new API gets more brownie points than rebuilding a service that does a better job of providing an existing API.

To be more charitable, having learned lessons from an existing API, a new one might incorporate those lessons learned and be able to do a better job serving various needs. At some point, it stops making sense to support older versions of an API as multiple versions with multiple sets of documentation can be really confusing.

I'm personally cynical enough to believe more in the less charitable version, but it's not impossible.

Post reply on HN