Live data from Hacker News

Google Kills Cloud Print

support.google.com

441–450 of 567 posts

Re: Google Kills Cloud Print

#441
post #360

Earlier quoted context omitted.

> As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google. That's Google's problem, and it's a problem they might want to look into solving if they want to turn around their reputation for killing products.

Google pays their engineers a lot and they’d need to recruit a lot more of them if they were going to keep running everything they ever killed. That, or stop launching so many new products.

I know it's beside the point, but you stepped on one of my peeves. Google doesn't have to pay their engineers "a lot". They don't have to keep sucking more and more wealthy people into a concentrated corner of California. They could open a modest office in Nebraska and pay some 5-figure salaries.

They could hire some run-of-the-mill college grads to work on a "dead" project. They could cut their teeth on low-profile stuff within Google and perhaps demonstrate abilities that move them up the ladder.

I'm not saying that Google should do this to keep everything they've ever touched alive. But spreading the talent around geographically would solve a lot of problems for Google and for California and for the world. Same for all FAANGs.

Quit earmarking $billions to solve the housing crisis in SF. Spend $1M in St. Louis and move 100 employees out of SF. Then spend $1M in Amarillo, and $1M in Sioux Falls. Shucks, maybe splurge and spend $20M here and there. $250M to build up 10 offices around the continent will do more to solve the housing crisis in CA than $1B spent in CA. And it would cut FAANG costs in half at the same time.

Re: Google Kills Cloud Print

#442
People rely on a lot of "free" Google services, but don't realize that it takes an enormous amount of people to keep things running without security issues. Another point is that, it takes hundreds of thousands of paying customers to get something to a point it is self sustainable. Just because a few random users are ready to pay $50 for the service, if at all, does not make it successful for Google or any other company.

Short of "regulating" these companies to open-source or sell the infra to a caretaker entity when services are shutdown, there is no other option. Even then, it is a massive ask of Google (that every service be separable from anything proprietary Google infra provides), and it also unrealistic to expect another company / governing body to run it without issues.

At this point, it is what it is. If you use a free service, expect it to die at some point in the future. This happens to many services where the entire company disappears. The fact that Google survived 20 years shouldn't be held against them if products went down and the company didn't. Numbers are enough to sway the stats and make Google the bad company that shuts-down services too often.

Re: Google Kills Cloud Print

#443
post #398

Earlier quoted context omitted.

This. Someone has to be in OWNERS and it’s difficult to find people willing to do this because fixing breakage due to API changes isn’t going to be on anyone’s OKRs. And if it’s not on your OKRs, it’s not contributing to your promo.

Which proves the futility of these OKR metrics. Once the metric becomes the objective, it loses any usefulness, indeed it becomes the opposite

How is that true? The OKR explicitly doesn't include cloud print because it is deemed not important to Google, and so cloud print is not worked on. Seems to be WAI?

Re: Google Kills Cloud Print

#444

My business includes printing, signing, and mailing certain documents, so it was crucial for our efficiency to automate the process of printing. Our first "fancy" printer included support for Google Cloud Print - except it would periodically "deauthenticate" and require manual setup, which in turn would change certain printer IDs that we needed to send jobs to the printer. Our next "fancy" printer from Xerox also inc…

Can also state I had good experience with them and that it's worth looking into. Needed a way to print custom labels and packing slips dynamically and Google Cloud Print was pretty obtuse comparitively.

Re: Google Kills Cloud Print

#445

The product has been around 10 years, and they're giving over a year notice before killing it. Sure, Google kills off another product... But the comments here are a bit silly.

Isn't Google Cloud Print built into some printers? So some people may have had a purchase decision based on a feature thats going away in a year. Seems like a reason to be upset even with a year's notice.

Re: Google Kills Cloud Print

#446
post #3

I'm confused on what the replacement is. Historically, ChromeOS hasn't been able to print at all unless using Google Cloud Print in some form. To my knowledge there are two existing forms: * a Google Cloud Print-ready printer, or * a computer that can run Chrome and bridge non-Google Cloud Print-ready printers to Google Cloud Print.[0] So the ancient WPS printer in my garage is entirely unsupported without deploying…

> So the ancient WPS printer in my garage is entirely unsupported without deploying a computer running Windows or macOS, installing Chrome, and registering a "classic printer" I think the support text is wrong—you could do this on Linux as well. It'll be a moot point though when Cloud Print shuts down. > Why is CUPS gimped so badly on ChromeOS? Have you tried recently? I don't think it is anymore. Yesterday my Chrome…

I have not tried recently. The new support articles I've uncovered seem to suggest that the situation has vastly improved. I'm still salty though, and I've put too much work into my Python script to really be concerned about switching to the more "correct" process that was previously denied to me.

The sad fact is that once a consumer realizes the device they've bought is encumbered with artificial limitations, they might not trust it even when (if!) these limitations are lifted later.

Re: Google Kills Cloud Print

#447

Earlier quoted context omitted.

Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it." After all, the whole pitch of elastic compute is you only pay for what you use. It's not like resources are being freed up for other things here. The software industry is always on this treadmill of churn, leading to stable products continuing to have a co…

A lot of the responses to the parent are things along the lines of "well it needs to be owned by a team" and all the usual valid cost-related reasons why [x] can't be maintained, and of course that doing so is boring. Isn't this the kind of project that should be reserved for people in explicit learning states such as (for example) novice hires, new hires, and aspiring mangers who haven't done any management before?…

I think if they release it as OSS some people would eventually fork it and maintain it.

Re: Google Kills Cloud Print

#448
post #4

Wow, that's a real shame, because Google Cloud Print was one of those nice little services that did ONE THING amazingly. I loved that I could print stuff from anywhere and it would be sitting on my printer when I got home. If I am working at a coffee shop, or out of town and bought something that needed to print a receipt, or a confirmation, or anything else. I could print it through Google Cloud Print and it would b…

end of an era

Re: Google Kills Cloud Print

#449

Earlier quoted context omitted.

As of this writing, that list contains about 270 items over about 35 years (from the first closure). The "Killed by Google" list contains 191 over 13 years.

It would be interesting to know total lunched products to closed products ratio, pretty sure MS looks better in this aspect as well

That would be an interesting analysis. Just keep in mind that "products" are nuanced; it's not always apples to apples. Both companies have some products that are free and some that cost lots of money. Some items are full blown enterprise applications, and some are just labs-style projects. All these different types of products are weighted the same in these lists.

But I don't necessarily think they have the same weight, so to speak. For example, the majority of products Google shut down were free, and the majority of Microsoft's were not. How should that be evaluated? I don't really know! It would be interesting to look at this.

Re: Google Kills Cloud Print

#450
post #332

Earlier quoted context omitted.

Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it." After all, the whole pitch of elastic compute is you only pay for what you use. It's not like resources are being freed up for other things here. The software industry is always on this treadmill of churn, leading to stable products continuing to have a co…

> Silo it off and just leave it be. Not really possible. It's an internet service that talks to large number of different printers from different manufacturers. Besides the code management issues others have mentioned, services like this require a great deal of product and partner coordination and testing effort to ensure that even small security patches don't break the heterogeneous ecosystem of devices. More import…

> Not really possible. It's an internet service that talks to large number of different printers from different manufacturers.

Of course it's possible. Those printers are not getting updates, either. Nobody is changing the printer side of this. And if they were it'd be a change in the protocol. It's easy to just freeze the protocol (which already happened years ago), and if any printer manufacturer wants something new then can go fork off and do their own thing. That's very different from breaking something old which is what's happening here.

> More importantly, CUPS and driverless printing standards have solved the problem (os-specific print drivers) that cloud print was designed to work around.

CUPS still needs printer-specific drivers to do the actual printing part. And how widespread are driverless printing standards? Do such printers actually exist in consumer households? My Dell printer from just a few years ago certainly isn't.

Post reply on HN