Printers are standardizing on a thing called "driverless printing," based on having some common Page Description Languages (or having the printer have support for handling a PDF directly): https://wiki.debian.org/CUPSDriverlessPrinting#Driverless_Pr... Each printer having its own driver is sort of like ... each terminal having its own escape sequences. When printers and terminals were purpose-built electronics with l…
You mean like Postscript 20 years ago?
Can you elaborate on the similarities? I don't really understand PS, CUPS, or GCP, but I think an overview of how they relate would be really interesting.
Sadly not for all printers, my printer requires an awful app that does everything itself. Not acceptable! But yeah, Cloud Print doesn't seem to have been particularly widely used or supported.
Try out the "Mopria print service" (mobile printing alliance), most big manufacturers are part of it. They provide a generic driver app for Android that works for mobile printing with models from multiple manufacturers.
Thanks for sharing, good to hear this is being democratized a little.
I use cloud print weekly to print off some homework for my child on the Chromebook. What is the alternative?
ChromeOS has native print capabilities: https://support.google.com/chromebook/answer/7225252?hl=en I use it all the time.
Does this work on older Chromebooks? The only way I was able to get a two-year-old Asus chromebook to print was to share the printer via cloud print from a raspberry pi.
Printers are standardizing on a thing called "driverless printing," based on having some common Page Description Languages (or having the printer have support for handling a PDF directly): https://wiki.debian.org/CUPSDriverlessPrinting#Driverless_Pr... Each printer having its own driver is sort of like ... each terminal having its own escape sequences. When printers and terminals were purpose-built electronics with l…
You mean like Postscript 20 years ago?
It's not a big deal now that embedded machines with a half a gig of RAM/multicore processors and open-source postscript rendering software is common, but postscript traditionally came with a heavy price in compute resources and software licensing fees. For a long time the RIP in the printer was a more capable system than the PC driving it, and printers that handled it were correspondingly premium products.
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…
This is the right move though because moving towards "Driverless printing" will solve the overall problem in a simpler way:
Nothing about Google killing products is quiet anymore. People have noticed, and I wonder if Google is really aware of the extent of the brand damage that headlines like this cause.
Printing is the most corporate thing I can imagine, and even though it is not directly related, as a G Suite customer, this would make me extremely nervous.
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.
Count up the collective hours spent figuring out why your printer no longer works and finding a new solution.
The vast majority of people using it won't see this news.
If Google doesn't make the Chromebook transition seamless and invisible, it'll be even worse.
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…
My guess is these things are generally unprofitable because their internal costs are so used to operating as a near monopoly they simply can’t do anything on the cheap. Which ends up killing off seemingly viable products. It’s much like how bell labs invented so much great technology, but could never make the transition to new producers themselves.
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 be logical to abandon a bunch of seemingly profitable products. Bad for PR and for getting folks to trust you on new projects, and you'd need to bake that cost into the calculation, but still potentially the right call.
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…
Sorry I can’t remember where I recently read this - but as I worked for a large company with one, entrenched major revenue stream it rang true to me:
Sometimes it’s in the best interests of the company to only have one major revenue stream!
They receive press and seem as innovators/bandwagon jumpers simply by entering the ‘flavour of the month’.