Live data from Hacker News

Google Kills Cloud Print

support.google.com

501–510 of 567 posts

Re: Google Kills Cloud Print

#501

Earlier quoted context omitted.

This is the right move though because moving towards "Driverless printing" will solve the overall problem in a simpler way: https://openprinting.github.io/driverless/ Google is pro-adapting to change. And it is painful but it is usually the right thing.

Until there's more competition in the printer space: good luck. Printer companies want to differentiate and upsell. The best way of doing that is via software which means first party "drivers" (which is really this huge bundle of bloat and ads at this point). If anyone has recently installed a consumer inkjet for a family member will know what I am talking about. It is basically adware. Those of us sticking to our ni…

Printer manufacturers don’t care about up selling. They want to sell high margins ink/toner. All consumer printers support iOS and MacOS that don’t require drivers.

Re: Google Kills Cloud Print

#502

Google has the corporate equivalent of ADHD. Having talked with ex-googlers and current googlers, the problem seems to be deeply baked into their culture. The incentive structures seem to favor the sexy over the boring, making it much more likely that someone will get promoted for launching products versus growing one. The fix seems to be obvious, create a separate path, a maintenance and growth hacker path, where pe…

I don't disagree with your assertions. But I want to point out that other tech giants sunset stuff all the time too. It some ways, it's endemic to the industry. Here's a list of everything Microsoft shut down over the years. It's a big list. https://www.versionmuseum.com/history-of/discontinued-micros...

Many of those products were cut down consumer products with a clear migration path (Outlook Express, Works, Personal Webserver, etc) or products that were declining in popularity (the older languages).

They were also mostly software that you could run practically forever without MS support because MS strives for backwards compatibility. Once Google subsets a service, you can’t use it anymore.

Re: Google Kills Cloud Print

#503

Earlier quoted context omitted.

Champing at the bit. https://grammarist.com/usage/champing-chomping-at-the-bit/

Did you read your own link? Chomping at the bit has the same meaning.

"Still, if you’re writing for school or for readers who are versed in English, champing at the bit is probably the safer choice."

Re: Google Kills Cloud Print

#504
post #10

Of all the free services to kill, this one really hurts. I just got my parents migrated to using Cloud Print with their Chromebooks and iStuff. As I am providing the usual family-plan IT advice from several timezones away, Cloud Print solved the biggest headache of getting their current project printed to their house or office from wherever they are (or me, if I am helping them). Supporting local printers was a time…

Expect Chromebooks to get killed as well.

"In Q4 of 2018, Chromebooks made up 21% of all notebooks sold in the US"

https://chromeunboxed.com/chromebooks-make-big-strides-in-sa...

Re: Google Kills Cloud Print

#505
So, why these companies can't look for other avenues then just killing products?

Alternatives:

- Put it in maintenance mode and outsource it. A 5 person team offshore for this mode would cost ~$250K.

- Open source it

- Sell it to a startup

- Sell it to an equity firm

- Make a cloud service out of it

- Add advertising/data collection to it that might benefit other products/AI efforts (with user agreement)

I am of the firm believer that all code that gets written should be preserved. Someone out there sometime would be looking for it.

Re: Google Kills Cloud Print

#506

Earlier quoted context omitted.

Did you read your own link? Chomping at the bit has the same meaning.

"Still, if you’re writing for school or for readers who are versed in English, champing at the bit is probably the safer choice."

..said nobody but an English major.

Re: Google Kills Cloud Print

#507
post #432

Earlier quoted context omitted.

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

A much easier to use tool that works using inotify is incron. It's basically like cron except for inotify events. I have a one-liner that OCRs all of my incoming scans, and it's immensely helpful.

Re: Google Kills Cloud Print

#508

Earlier quoted context omitted.

"Still, if you’re writing for school or for readers who are versed in English, champing at the bit is probably the safer choice."

..said nobody but an English major.

Neither productive, insightful, nor accurate, just FYI.

Re: Google Kills Cloud Print

#509
post #381

Earlier quoted context omitted.

Google Maps was not an in-house project. Google assembled it by acquiring mapping companies Where 2 Technologies and Keyhole.

I should have checked Wikipedia at least, who link to a 2005 CNET story on the Where 2 acquisition. - https://www.cnet.com/news/google-mapper-take-browsers-to-the... It looks like a talent acquisition: the Where 2 codebase was a C++ app, nothing to do with the Ajax implementation they rolled out. I'd be interested in learning more about this story.

Good news! :) Bill Kilday, a founder at Keyhole, wrote a book about Keyhole, Where 2, and Google Earth and Maps: "Never Lost Again: The Google Mapping Revolution That Sparked New Industries and Augmented Our Reality". It's not very technical, but it has a lot of interesting history about the products' development and internal Google politics.

https://www.amazon.com/dp/0062673041

Re: Google Kills Cloud Print

#510
post #242

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…

> 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." That's not exactly possible with a monorepo that has no branches and everything has to be maintained 'in step'. Any time a library breaks API, all dependents must pass tests, and/or be fixed so that they do. Any time a runtime API breaks (think things li…

that’s a problem, yes, but orthogonal to it being in a monorepo. the google monorepo is NOTHING like a git monorepo
Post reply on HN