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…
Google Kills Cloud Print
501–510 of 567 posts
Re: Google Kills Cloud Print
#502Google 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...
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
#503Earlier 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.
Re: Google Kills Cloud Print
#504Of 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.
https://chromeunboxed.com/chromebooks-make-big-strides-in-sa...
Re: Google Kills Cloud Print
#505Alternatives:
- 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
#506Re: Google Kills Cloud Print
#507Earlier 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
Re: Google Kills Cloud Print
#508Re: Google Kills Cloud Print
#509Earlier 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.
Re: Google Kills Cloud Print
#510Earlier 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…