Live data from Hacker News

Google Kills Cloud Print

support.google.com

471–480 of 567 posts

Re: Google Kills Cloud Print

#471
post #392

It’s unfortunate that Cloud Print will be shutting down. It was a convenient and useful utility. It couldn’t have cost that much to run. Perhaps the shutdown has something to do with the product possibly being based on Google Talk? The port requirements for the print server include: “5222 TCP (XMPP, using STARTTLS), with a persistent connection to: talk.google.com.” [1] [1]: https://support.google.com/a/answer/317917…

Please don't post duplicate comments to HN! It lowers signal-noise ratio and makes it hard to merge threads. Now that the threads are merged, I have to go find the other copies and kill them, and if they have replies, move the replies to the surviving copy. That takes quite a lot of REPL work. Here's what to do instead: when you notice that a discussion has forked and your comment is languishing in the losing branch,…

[deleted]

Re: Google Kills Cloud Print

#472

Earlier quoted context omitted.

Do you use cloud print?

The more relevant question is: for a new service by Google for which you are a target market would you have any reluctance to use it based on your perceived likelihood that Google will kill in the future?

Based on them killing a service like Cloud Print? No.

Re: Google Kills Cloud Print

#473

Earlier quoted context omitted.

I said install both , not downgrade . Admittedly I presumed (perhaps wrongly) that most people here know what dual booting is.

You still can't. You cannot boot a version of macOS earlier than the supplied one, for any particular machine.

Ah - I was of the impression that the 16-inch MBP initially ran Mojave, even though you buy them with Catalina installed. Probably from the crop of rumours last month?

In that case yeah, a partition with Linux might be your best bet if you want to use 32-bit apps, unfortunately.

Re: Google Kills Cloud Print

#474

Earlier quoted context omitted.

Orders of magnitude faster than JavaScriptCore in 2008?

Yes, it depends on what benchmarks you ran though. Example: https://www.zdnet.com/article/google-chrome-is-insanely-fast...

I specifically asked about JavaScriptCore - the (open source) JS engine part of Safari.

Re: Google Kills Cloud Print

#475
post #254

I am quick to complain when Google kills a useful project - but I am not mad about this. It was originally created because Chromebooks couldn't print. Chromebooks have been able to print natively for a while now so that is no longer needed. They are also giving over a year of warning. That's plenty of time for people to migrate to a new service or figure out how to implement an alternative. Again I know the Google Gr…

The main reason I used Cloud Print was the ability to print remotely and securely to my home printer without having to worry much about the security implication. I don't really need it that much I guess..

plus, not having to worry about drivers. I had it running on a raspberry pi connected to a Brother 3 in 1 printer for couple of years. it worked and worked well from every single device I printed from.

Re: Google Kills Cloud Print

#476

Earlier quoted context omitted.

It's not free to run and it is not generating revenues. Have printer manufacturers pay for it's maintenance, then it's a reasonable argument for jut keeping it up.

I saw it as a counterpoint to AirPrint. I'd like to know what changed that made Google think they don't really need this anymore. Maybe they think WiFi Direct is going to be the future?

Local wifi-based printing and printer discovery (same as Airprint) is already available on Google devices. No Cloudprint required.

Re: Google Kills Cloud Print

#478

Earlier quoted context omitted.

They might not be wrong. Engineers who could be maintaining mildly profitable products could be invented new products that have some percentage chance of being much more profitable. If someone did the math and said the expected value of "engineer working on new projects" was bigger than the expected value of of the the profits of an existing project divided by the number of engineers needed to maintain it, then it'd…

> Engineers...could be invent[ing] new products that have some percentage chance of being much more profitable Doubtful. The successful products to come out of Google are Search, GMail, and GCP. They bought Adwords, Doubleclick, Android, Youtube, and Nest and Fitbit, I suppose. GCP is their only recent win, but it's a me-too late entrant in a market Google should have invented .

I'm not sure it was profitable, but Orkut, at its peak, had 300 million users, and that purely a result of an experiment by an engineer.

Re: Google Kills Cloud Print

#479
post #432

Earlier quoted context omitted.

Probably easy enough to throw this together in python and host it on your choice of cheap, lower power hardware (Raspberry pi, etc).

It'd also be very trivial to script with a Mac using Folder Actions and a 5 line AppleScript. (I wish Linux had an equivalent to Folder Actions. They’re really nifty.)

The Linux equivalent of Folder Actions would probably either be inotify¹ or inotify-tools².

1:https://linux.die.net/man/7/inotify

2:https://github.com/rvoicilas/inotify-tools/wiki

Re: Google Kills Cloud Print

#480
post #459

Earlier quoted context omitted.

> 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 ne…

> Those printers are not getting updates, either. Nobody is changing the printer side of this Of course things change. Security protocols get upgraded. New attack vectors are discovered in protocols and need to be fixed. New devices with new capabilities are created and need API integration. That all requires human effort to make happen. All of that has to be worth the cost of maintaining the project. > CUPS still ne…

> Of course things change.

Except they don't. The clients are frozen in time forever. There's no change happening here. It doesn't matter if they should be changed, they aren't being changed. Printer firmware does not get updates.

> New attack vectors are discovered in protocols and need to be fixed.

IF that ever happens, which is super duper unlikely, then kill it since the clients are unfixable. But this is not an ongoing cost. There's no continuous change aspect to that at all.

> New devices with new capabilities are created and need API integration.

That's not change, that's new features. As I said, simply tell those things to go do their own thing. That's unrelated to leaving Cloud Print on life support.

Post reply on HN