Inactive links? There is no such thing. Research papers written a decade ago, you read, and want to click. Now you cannot, unless the data is popular.
If they're keeping the service alive, then keep it alive.
171–180 of 194 posts
Inactive links? There is no such thing. Research papers written a decade ago, you read, and want to click. Now you cannot, unless the data is popular.
If they're keeping the service alive, then keep it alive.
Earlier quoted context omitted.
i read in an earlier thread for this on HN - "this is a classic example of data driven product decision" aka we can reduce costs by $x if we just stopped goo.gl links. Instead of actually wondering how this would impact the customers. Also helps that they are in a culture which does not mind killing services on a whim.
Hard to imagine costs were ever a factor. For company running GCP and giving things like Colab TPUs free the costs of running a URL service would be trivial rounding number at best
I've handled far more traffic on single machines 20 years ago.
What amazes me is that this wasn't the original plan. What product manager thinks "the best thing for our customers is to delete their data!". > We understand these links are embedded in countless documents, videos, posts and more, and we appreciate the input received. How did they think the links were being used?
One that is operating in an environment where strict privacy laws exist. User data stuck in legacy systems is a liability. Not only are things evolving internally within Google, laws are evolving externally and must be followed.
Earlier quoted context omitted.
> 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.
I'd like to encourage you consider the following two perspectives -- 1. A senior Google leader telling the shareholders "we've asked 1% of our engineers, that's 270 people, costing $80M/year, to work on services that produce no revenue whatsoever." I don't think it would pass that well. 2. A Google middle manager trying to figure out if an engineer working exclusively on non-revenue projects is actually being useful…
The business case for this is that Google lose a bunch of money in b2b (cloud mostly, potentially AI in future) because professional users (developers etc) don't believe that products will be supported. Every time Google shut down a service like this, this perception is re-inforced. We're investing this money into these services to change our brand perception and help us make more money in future.
As a bonus, this kind of cultural change would also force them to rebuild their engineering systems (and promotional systems) to make this easier. This may not have mattered for Search/Ads but it will matter if they actually care about winning in cloud and AI.
Earlier quoted context omitted.
i read in an earlier thread for this on HN - "this is a classic example of data driven product decision" aka we can reduce costs by $x if we just stopped goo.gl links. Instead of actually wondering how this would impact the customers. Also helps that they are in a culture which does not mind killing services on a whim.
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.
It's a strange thing to consider 'since 2018' "a long time". Only in tech circles is this so, not in normal life.
Earlier quoted context omitted.
I interpreted "inactive" as the link that the shortener is linking to is not responding.
No. Inactive means that the short URL hasn't been accessed in a while.
Earlier quoted context omitted.
Yes I did address that part but honestly I can use the time of when it was sent into blockchain / transaction id which is generally really short as I said in the comment. I will hack a prototype tomorrow.
It is the long URL that also needs to be stored, not just the short URL. If you want to use blockchain for this, I advise properly using a dedicated new blockchain, not spamming the Nano network.
The funny part is that I was thinking about creating a dedicated new blockchain but I felt "spamming" (honestly fair critique) was easier and more practical and currently more decentralized.
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”?
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
I guess the number of people who use Chrome to access files via FTP must be below 0.01% then. https://www.auslogics.com/en/articles/is-it-bad-that-google-...